search

ktls / af_ktls

Linux Kernel TLS/DTLS Module
GNU General Public License v2.0
157 stars 25 forks source link

possible lock inversion surrounding splice #68

Closed lancerchao closed 8 years ago

lancerchao commented 8 years ago

tls_splice_read acquires locks in the order: 1) tsk->rx_lock 2) lock_sock(tsk) 3) pipe_lock (called in splice_to_pipe)

tls_sendpage acquires lock in the order: 1) pipe_lock (called in splice_from_pipe) 2) tsk_rx_lock 3) lock_sock(tsk)

Kernel warns about possible deadlock http://pastebin.com/tYCk0bxy

In practice I don't think this is much of an issue since I don't think you'd ever splice to and from the same pipe.

fridex commented 8 years ago

In practice I don't think this is much of an issue since I don't think you'd ever splice to and from the same pipe.

I'm not sure here. Is the synchronization in other parts of the kernel left to user space as well?

djwatson commented 8 years ago

Is this still relevant? It looks fixed to me. I ran with lockdep and didn't see the error.

It looks like tls_sock_splice calls relase_sock so only pipe_lock is held, similar to the other socket implementations I looked at. rx_lock is gone entirely.

Closing unless someone thinks otherwise...