On Thu, Dec 8, 2016 at 5:32 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, Dec 08, 2016 at 04:08:27PM -0800, Cong Wang wrote: >> On Thu, Dec 8, 2016 at 8:30 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: >> > Chain exists of: >> > Possible unsafe locking scenario: >> > >> > CPU0 CPU1 >> > ---- ---- >> > lock(sb_writers#5); >> > lock(&u->bindlock); >> > lock(sb_writers#5); >> > lock(&pipe->mutex/1); >> >> This looks false positive, probably just needs lockdep_set_class() >> to set keys for pipe->mutex and unix->bindlock. > > I'm afraid that it's not a false positive at all. Right, I was totally misled by the scenario output of lockdep, the stack traces actually are much more reasonable. The deadlock scenario is easy actually, comparing with the netlink one which has 4 locks involved, it is: unix_bind() path: u->bindlock ==> sb_writer do_splice() path: sb_writer ==> pipe->mutex ==> u->bindlock *** DEADLOCK *** > > Why do we do autobind there, anyway, and why is it conditional on > SOCK_PASSCRED? Note that e.g. for SOCK_STREAM we can bloody well get > to sending stuff without autobind ever done - just use socketpair() > to create that sucker and we won't be going through the connect() > at all. In the case Dmitry reported, unix_dgram_sendmsg() calls unix_autobind(), not SOCK_STREAM. I guess some lock, perhaps the u->bindlock could be dropped before acquiring the next one (sb_writer), but I need to double check. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
