All of lore.kernel.org
 help / color / mirror / Atom feed
From: Byungchul Park <byungchul@sk.com>
To: "Loktionov, Aleksandr" <aleksandr.loktionov@intel.com>
Cc: Pavel Begunkov <asml.silence@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kernel_team@skhynix.com" <kernel_team@skhynix.com>,
	"harry.yoo@oracle.com" <harry.yoo@oracle.com>,
	"david@redhat.com" <david@redhat.com>,
	"willy@infradead.org" <willy@infradead.org>,
	"toke@redhat.com" <toke@redhat.com>,
	"almasrymina@google.com" <almasrymina@google.com>,
	"Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
	"Kitszel, Przemyslaw" <przemyslaw.kitszel@intel.com>,
	"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>
Subject: Re: [Intel-wired-lan] [PATCH net-next] ice: access @pp through netmem_desc instead of page
Date: Thu, 18 Dec 2025 09:40:33 +0900	[thread overview]
Message-ID: <20251218004033.GB15390@system.software.com> (raw)
In-Reply-To: <IA3PR11MB898609A6FA1E75B5C87C27C2E5ABA@IA3PR11MB8986.namprd11.prod.outlook.com>

On Wed, Dec 17, 2025 at 02:34:14PM +0000, Loktionov, Aleksandr wrote:
> > -----Original Message-----
> > From: Pavel Begunkov <asml.silence@gmail.com>
> > Sent: Wednesday, December 17, 2025 2:16 PM
> > To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Byungchul
> > Park <byungchul@sk.com>; netdev@vger.kernel.org; kuba@kernel.org
> > Cc: linux-kernel@vger.kernel.org; kernel_team@skhynix.com;
> > harry.yoo@oracle.com; david@redhat.com; willy@infradead.org;
> > toke@redhat.com; almasrymina@google.com; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> > <przemyslaw.kitszel@intel.com>; andrew+netdev@lunn.ch;
> > davem@davemloft.net; edumazet@google.com; pabeni@redhat.com; intel-
> > wired-lan@lists.osuosl.org
> > Subject: Re: [Intel-wired-lan] [PATCH net-next] ice: access @pp
> > through netmem_desc instead of page
> >
> > On 12/17/25 11:46, Loktionov, Aleksandr wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On
> > Behalf
> > >> Of Byungchul Park
> > >> Sent: Tuesday, December 16, 2025 5:07 AM
> > >> To: netdev@vger.kernel.org; kuba@kernel.org
> > >> Cc: linux-kernel@vger.kernel.org; kernel_team@skhynix.com;
> > >> harry.yoo@oracle.com; david@redhat.com; willy@infradead.org;
> > >> toke@redhat.com; asml.silence@gmail.com; almasrymina@google.com;
> > >> Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> > >> <przemyslaw.kitszel@intel.com>; andrew+netdev@lunn.ch;
> > >> davem@davemloft.net; edumazet@google.com; pabeni@redhat.com; intel-
> > >> wired-lan@lists.osuosl.org
> > >> Subject: [Intel-wired-lan] [PATCH net-next] ice: access @pp through
> > >> netmem_desc instead of page
> > >>
> > >> To eliminate the use of struct page in page pool, the page pool
> > users
> > >> should use netmem descriptor and APIs instead.
> > >>
> > >> Make ice driver access @pp through netmem_desc instead of page.
> > >>
> > > Please add test info: HW/ASIC + PF/VF/SR-IOV, kernel version/branch,
> > exact repro steps, before/after results (expected vs. observed).
> > >
> > >> Signed-off-by: Byungchul Park <byungchul@sk.com>
> > >> ---
> > >>   drivers/net/ethernet/intel/ice/ice_ethtool.c | 2 +-
> > >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > >> b/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > >> index 969d4f8f9c02..ae8a4e35cb10 100644
> > >> --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > >> +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > >> @@ -1251,7 +1251,7 @@ static int ice_lbtest_receive_frames(struct
> > >> ice_rx_ring *rx_ring)
> > >>            rx_buf = &rx_ring->rx_fqes[i];
> > >>            page = __netmem_to_page(rx_buf->netmem);
> > >>            received_buf = page_address(page) + rx_buf->offset +
> > >> -                         page->pp->p.offset;
> > >> +                         pp_page_to_nmdesc(page)->pp->p.offset;
> > > If rx_buf->netmem is not backed by a page pool (e.g., fallback
> > allocation), pp will be NULL and this dereferences NULL.
> > > I think the loopback test runs in a controlled environment, but the
> > code must verify pp is valid before dereferencing.
> > > Isn't it?
> >
> > Considering "page->pp->p.offset" poking into the pool, if that can
> > happen it's a pre-existing problem, which should be fixed first.
> >
> > --
> > Pavel Begunkov
> 
> 
> Good day, Hi Byungchul, Pavel,

Hi,

> Thanks for pushing the driver toward netmem — I fully support removing direct struct page accesses from the networking stack.
> 
> Regarding this change in ice_lbtest_receive_frames():
> 
>         received_buf = page_address(page) + rx_buf->offset +
>                 pp_page_to_nmdesc(page)->pp->p.offset;
> 
> Pavel, you're right that if page->pp could be NULL, it's a pre-existing bug that should be fixed.
> However, looking at the loopback test path, I'm concerned this code doesn't handle non-page-pool allocations safely.
> 
> The netmem model explicitly allows for buffers that aren't page-pool backed.
> While the loopback test likely runs in a controlled environment, the code should verify pp is valid before dereferencing,
> or use the netmem helpers that handle this gracefully:

If it's true, yeah, it definitely should be fixed but in a separate
patch since it's a different issue.  Let's try with a follow-up patch on
top after :-)

>         struct netmem_desc *ndesc = __netmem_to_nmdesc(rx_buf->netmem);
>         void *addr = netmem_address(rx_buf->netmem);
>         struct page_pool *pp;
> 
>         if (!addr)
>                 continue; /* unreadable netmem */
> 
>         pp = __netmem_get_pp(ndesc);
>         received_buf = addr + rx_buf->offset + (pp ? pp->p.offset : 0);
> 
> Alternatively, guard the existing code with page_pool_page_is_pp(page) before calling pp_page_to_nmdesc().
> 
> This would complete the netmem conversion while fixing the unsafe dereference,
> aligning with Matthew's earlier suggestion to use descriptor/address accessors.

Pavel's opinion is that the current way is more appropriate.  Which one
should it go for?

> Also, please add test details to the commit message:

This patch is more like a cleaning patch rather than a performance one.
Please tell me in more detail if you have any test to ask me to perform
for some reasons.

> HW/ASIC (e.g., E810/E823)
> PF vs VF, SR-IOV configuration
> Kernel tree/commit (net-next @ <sha>)
> Repro steps: ethtool -t $dev offline
> Before/after behavior
> Happy to review v2 with these changes.

Thanks for the review comment!

	Byungchul

> Best regards,
> Alex

      reply	other threads:[~2025-12-18  0:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-16  4:07 [Intel-wired-lan] [PATCH net-next] ice: access @pp through netmem_desc instead of page Byungchul Park
2025-12-16  4:07 ` Byungchul Park
2025-12-16  4:20 ` [Intel-wired-lan] " Matthew Wilcox
2025-12-16  4:20   ` Matthew Wilcox
2025-12-17 13:11   ` [Intel-wired-lan] " Pavel Begunkov
2025-12-17 13:11     ` Pavel Begunkov
2026-01-08 15:59     ` [Intel-wired-lan] " Alexander Lobakin
2025-12-17 11:46 ` Loktionov, Aleksandr
2025-12-17 11:46   ` Loktionov, Aleksandr
2025-12-17 13:15   ` Pavel Begunkov
2025-12-17 14:34     ` Loktionov, Aleksandr
2025-12-17 14:34       ` Loktionov, Aleksandr
2025-12-18  0:40       ` Byungchul Park [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251218004033.GB15390@system.software.com \
    --to=byungchul@sk.com \
    --cc=aleksandr.loktionov@intel.com \
    --cc=almasrymina@google.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=asml.silence@gmail.com \
    --cc=davem@davemloft.net \
    --cc=david@redhat.com \
    --cc=edumazet@google.com \
    --cc=harry.yoo@oracle.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kernel_team@skhynix.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=toke@redhat.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.