Re: [PATCH v2 0/2] usb: gadget: Fix g_ncm regression and atomic sleep in f_ncm

[Kuen-Han Tsai]

Hi David, Greg,

Thanks for testing. I'm sorry the patches are causing trouble on your setup.

On Sun, Mar 1, 2026 at 5:03 AM David Heidelberg <david@xxxxxxx> wrote:
>
> Hello Kuen-Han,
>
> sadly this series is not enough to fully fix the usb issue encountered
> on qcom sdm845 platform (namely Pixel 3, OnePlus 6/6T etc.).
>
> I didn't debugged deeply, but without these patches interface (indicated
> by NM icon) goes on/off/on/off indefinitely. With your patches it seems
> stable, but I'm not getting the DHCP address from the phone, which isn't
> issue at all when I revert the 56a512a9b4107079f68701e7d55da8507eb963d9
> ("usb: gadget: f_ncm: align net_device lifecycle with bind/unbind").
>
> I think reverting the original patch would make more sense and then
> follow up with new one.

The net_device lifecycle change puts us in a dilemma:

1. If we revert the original patch entirely, the NULL pointer
dereference and dangling sysfs references come back on Android.

2. If we only clear the parent gadget pointer during unbind without
unregistering the net_device, the sysfs entries still dangle.

3. If we clear the pointer and unregister the net_device without
freeing it, the device cannot be re-registered unless it is
uninitialized.

4. If we fully unregister and recreate the net_device on each bind, it
breaks DHCP on your setup.

Greg, do you have any thoughts on the best way to untangle this? I am
fully willing to submit a revert for this series to restore the
expected behavior while we figure out a proper architectural fix.

>
> Feel free to add me into CC and I'll happily test on the sdm845 mobile
> devices for you.
>
> David

David, could you share exactly what OS you are using (e.g.,
postmarketOS with an sdm845/6.18-dev tree)? Also, could you provide
some instructions on how to build the code and reproduce this problem
on a Pixel 3? If you have the time, it would be incredibly helpful if
you could dive into this a bit deeper on your device to see exactly
how the DHCP daemon is failing.

Regards,
Kuen-Han


>
> On 21/02/2026 15:48, Kuen-Han Tsai wrote:
> > Commit 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle
> > with bind/unbind") addressed a lifetime mismatch where the network
> > interface outlived the parent gadget. However, this introduced two
> > regressions:
> >
> > 1. A NULL pointer dereference in the legacy g_ncm driver. The legacy
> >     driver attempts to access the net_device during its binding process
> >     before the NCM function driver is fully initialized.
> >
> > 2. A "sleeping function called from atomic context" error in f_ncm.
> >     The current implementation holds a mutex which might sleep within
> >     an atomic context.
> >
> > To resolve these, store the configuration parameters (qmult, host_addr,
> > dev_addr) in opts_net until the network device is ready for g_ncm.
> > Additionally, remove the net_device pointer from the f_ncm_opts
> > structure. This eliminates the race condition with configfs and allows
> > dropping the mutex, preventing the atomic sleep issue.
> >
> > Signed-off-by: Kuen-Han Tsai <khtsai@xxxxxxxxxx>
> > ---
> > Changes in v2:
> > - Remove the RFC tag.
> > - Fix NPE in gncm reported by the kernel test bot.
> > - Fix a "sleeping function called from atomic context" error.
> > - Link to v1: https://lore.kernel.org/r/20260214-legacy-ncm-v1-1-139c5bcc6636@xxxxxxxxxx
> >
> > ---
> > Kuen-Han Tsai (2):
> >        usb: legacy: ncm: Fix NPE in gncm_bind
> >        usb: gadget: f_ncm: Fix atomic context locking issue
> >
> >   drivers/usb/gadget/function/f_ncm.c            | 29 +++++++++++---------------
> >   drivers/usb/gadget/function/u_ether_configfs.h | 11 +---------
> >   drivers/usb/gadget/function/u_ncm.h            |  1 -
> >   drivers/usb/gadget/legacy/ncm.c                | 13 +++++++++---
> >   4 files changed, 23 insertions(+), 31 deletions(-)
> > ---
> > base-commit: da87d45b195148d670ab995367d52aa9e8a9a1fa
> > change-id: 20260214-legacy-ncm-8c001295b343
> >
> > Best regards,
>
> --
> David Heidelberg
>