netdev - Re: [PATCH net-next v8 0/6] net: Split ndo_set_rx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAPrAcgNhpK-cOVenrtw+-t9CV7bb6V+4b-R=_0m9Tv0C7U0ecw@mail.gmail.com>
Date: Fri, 16 Jan 2026 11:28:47 +0530
From: I Viswanath <viswanathiyyappan@...il.com>
To: edumazet@...gle.com, horms@...nel.org, sdf@...ichev.me, kuba@...nel.org, 
	andrew+netdev@...n.ch, pabeni@...hat.com, jasowang@...hat.com, 
	eperezma@...hat.com, mst@...hat.com, xuanzhuo@...ux.alibaba.com, 
	przemyslaw.kitszel@...el.com, anthony.l.nguyen@...el.com, 
	ronak.doshi@...adcom.com, pcnet32@...ntier.com
Cc: bcm-kernel-feedback-list@...adcom.com, intel-wired-lan@...ts.osuosl.org, 
	virtualization@...ts.linux.dev, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v8 0/6] net: Split ndo_set_rx_mode into snapshot
 and deferred write

Patch 1:

> If netif_alloc_rx_mode_ctx() succeeds but ndo_open() subsequently fails,
does this leak the rx_mode_ctx allocation? The error path only clears
__LINK_STATE_START but does not appear to free the rx_mode_ctx. (Yes,
There is a leak)
> Would it make sense to add netif_free_rx_mode_ctx(dev) to the error path,
or perhaps check if dev->rx_mode_ctx is already allocated before calling
netif_alloc_rx_mode_ctx()?

This framework should accommodate future ndo s requiring deferred work.
Therefore, the best course of action would be to schedule the cleanup
work. If we reuse it, we would have a memory leak in case __dev_open
never succeeds as the cleanup is in __dev_close_many

Does it make sense to move

+ if (!ret && dev->needs_cleanup_work) {
+ if (!dev->cleanup_work)
+ ret = netif_alloc_cleanup_work(dev);
+ else
+ flush_work(&dev->cleanup_work->work);
+ }
+
+ if (!ret && ops->ndo_write_rx_mode)
+ ret = netif_alloc_rx_mode_ctx(dev);
+
to a new function netif_alloc_deferred_ctx() and rename
netif_cleanup_work_fn() to netif_free_deferred_ctx()?

Patch 3:

First of all, Does it make sense to call e1000_set_rx_mode when the
netif is down?

Second of all, I am not dealing with the cases where I/O should be
illegal but the netif is still up correctly.
For this, I am thinking of adding netif_enable_deferred_ctx() and
netif_disable_deferred_ctx()

netif_disable_deferred_ctx() will be called in the PM suspend
callbacks and in the PCI shutdown callback while
netif_enable_deferred_ctx() will be called in the PM resume callbacks.

I know this will be a lot of work but this is a one time thing that
other deferred work ndo s can use for free.

Correct me if I have missed any cases.

Patch 6:

This was stupid on my part. I will add back netif_wake_queue(dev) in
the next version.