> -----Original Message----- > From: Intel-wired-lan <[email protected]> On Behalf Of > Aleksandr Loktionov > Sent: Wednesday, April 8, 2026 6:12 AM > To: [email protected]; Nguyen, Anthony L > <[email protected]>; Loktionov, Aleksandr > <[email protected]> > Cc: [email protected] > Subject: [Intel-wired-lan] [PATCH iwl-next v2 7/8] ixgbe: use GFP_KERNEL in > ixgbe_fcoe_ddp_setup() > > ixgbe_fcoe_ddp_setup() is always called from process context (FCoE offload > setup paths) and never from an atomic context. Using GFP_ATOMIC is therefore > unnecessarily restrictive and wastes memory > allocator headroom reserved for genuine atomic callers. > > The previous attempt to change this to GFP_KERNEL placed the allocation > inside the get_cpu()/put_cpu() section, which disables preemption. > GFP_KERNEL can sleep under direct reclaim regardless of whether the caller is > in process context, which triggers a BUG() with preemption disabled. > > Restructure the function to split the get_cpu()/put_cpu() usage into two > narrow critical sections: > > 1. A short initial section that reads the per-CPU pool pointer and > validates it, then immediately calls put_cpu() before any allocation. > The pool pointer is saved in a local variable for use after the pin > is dropped. > > 2. A second section after the allocation that re-pins the CPU solely to > update per-CPU counters (noddp, noddp_ext_buff) inside the SG loop. > > The DMA mapping and pool allocation sit between these two sections with > preemption enabled, making GFP_KERNEL safe. The pool pointer saved from > section 1 remains valid because per-CPU DMA pools are > only destroyed during > interface teardown under RTNL, not during normal operation. > > Suggested-by: Sebastian Basierski <[email protected]> > Signed-off-by: Aleksandr Loktionov <[email protected]> > --- > v1 -> v2: > - Move dma_pool_alloc() outside the get_cpu()/put_cpu() section; > split into two narrow preempt-off regions so GFP_KERNEL is safe. > > drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 51 +++++++++++--------- > 1 file changed, 35 insertions(+), 18 deletions(-)
Tested-by: Alexander Nowlin <[email protected]>
