On Wed, Jan 18, 2017 at 1:17 AM, Dmitry Vyukov wrote: > On Tue, Jan 17, 2017 at 10:21 PM, Cong Wang wrote: >> On Mon, Jan 16, 2017 at 1:32 AM, Dmitry Vyukov wrote: >>> On Fri, Dec 9, 2016 at 7:41 AM, Al Viro wrote: >>>> On Thu, Dec 08, 2016 at 10:32:00PM -0800, Cong Wang wrote: >>>> >>>>> > 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. >>>> >>>> Yes, I've noticed. What I'm asking is what in there needs autobind triggered >>>> on sendmsg and why doesn't the same need affect the SOCK_STREAM case? >>>> >>>>> I guess some lock, perhaps the u->bindlock could be dropped before >>>>> acquiring the next one (sb_writer), but I need to double check. >>>> >>>> Bad idea, IMO - do you *want* autobind being able to come through while >>>> bind(2) is busy with mknod? >>> >>> >>> Ping. This is still happening on HEAD. >>> >> >> Thanks for your reminder. Mind to give the attached patch (compile only) >> a try? I take another approach to fix this deadlock, which moves the >> unix_mknod() out of unix->bindlock. Not sure if there is any unexpected >> impact with this way. > > > I instantly hit: > Oh, sorry about it, I forgot to initialize struct path... Attached is the updated version, I just did a boot test, no crash at least. ;) Thanks!