Re: [PATCH] kobject: avoid blocking allocation while holding uevent_sock_mutex

[Tao Yu <tao1.yu@intel.com>]

Hi Greg,

Thanks for the review.

Nothing changed in USB enumeration itself. What syzbot appears to be
hitting is a long-standing latency problem in the untagged uevent path,
not a recent USB-specific regression.

The blocked task is in:

  usb_set_configuration()
    -> device_add()
    -> kobject_uevent_env()
    -> uevent_net_broadcast_untagged()

so the contention point is the global untagged-uevent broadcast path in
lib/kobject_uevent.c.

Looking at the history, the locked allocation/broadcast pattern appears
to date back to 16dff336b33d ("kobject: add kobject_uevent_net_broadcast()").
Because of that, I did not add a Fixes tag or cc stable in v1. I do not
have evidence that this is a recent regression, so I would rather not
add those tags without a stronger justification.

You are also right about the race in my listener pre-check. A listener
can appear after the first unlock, so that part of v1 is not correct.
I will drop that approach in the next revision.

I also should have included the syzbot link and testing details. The
report is here:
https://syzkaller.appspot.com/bug?extid=c22bb42560ec86726aba

syzbot has now tested the proposed patch and reported that the
reproducer did not trigger the issue:
https://groups.google.com/g/syzkaller-bugs/c/q6wmyA-hG6E/m/rLDsbLC-AQAJ

So the patch now has:
Tested-by: syzbot+c22bb42560ec86726aba@syzkaller.appspotmail.com

I also compile-tested it with:
  make lib/kobject_uevent.o

Given the race in v1, I will respin this as a narrower fix and include
the proper Link/Tested-by information.

Thanks,
Tao