From: Hannes Reinecke <hare@suse.de>
To: Jakub Kicinski <kuba@kernel.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
netdev@vger.kernel.org, Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: Decline to manipulate the refcount on a slab page
Date: Tue, 11 Mar 2025 16:46:45 +0100 [thread overview]
Message-ID: <4fc21641-e258-474b-9409-4949fe2fda2d@suse.de> (raw)
In-Reply-To: <20250311111511.2531b260@kernel.org>
On 3/11/25 11:15, Jakub Kicinski wrote:
> On Mon, 10 Mar 2025 14:35:24 +0000 Matthew Wilcox (Oracle) wrote:
>> Long-term, networking needs to stop taking a refcount on the pages that
>> it uses and rely on the caller to hold whatever references are necessary
>> to make the memory stable.
>
> TBH I'm not clear on who is going to fix this.
> IIRC we already told NVMe people that sending slab memory over sendpage
> is not well supported. Plus the bug is in BPF integration, judging by
> the stack traces (skmsg is a BPF thing). Joy.
Hmm. Did you? Seem to have missed it.
We make sure to not do it via the 'sendpage_ok()' call; but other than
that it's not much we can do.
And BPF is probably not the culprit; issue here is that we have a kvec,
package it into a bio (where it gets converted into a bvec),
and then call an iov iterator in tls_sw to get to the pages.
But at that stage we only see the bvec iterator, and the information
that it was an kvec to start with has been lost.
All wouldn't be so bad if we wouldn't call get_page/put_page (the caller
holds the reference, after all), but iov iterators and the skmsg code
insists upon.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
next prev parent reply other threads:[~2025-03-11 15:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-10 14:35 [PATCH] mm: Decline to manipulate the refcount on a slab page Matthew Wilcox (Oracle)
2025-03-10 14:37 ` Vlastimil Babka
2025-03-10 14:50 ` Matthew Wilcox
2025-03-11 10:15 ` Jakub Kicinski
2025-03-11 15:46 ` Hannes Reinecke [this message]
2025-03-11 16:59 ` Matthew Wilcox
2025-03-12 5:48 ` Christoph Hellwig
2025-03-13 7:22 ` Hannes Reinecke
2025-03-13 7:36 ` Christoph Hellwig
2025-03-13 8:34 ` Hannes Reinecke
2025-03-13 8:44 ` Christoph Hellwig
2025-03-13 8:52 ` Hannes Reinecke
2025-03-13 9:15 ` Christoph Hellwig
2025-03-12 5:47 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2025-03-10 14:27 Matthew Wilcox (Oracle)
2025-03-10 16:57 ` Hannes Reinecke
2025-03-10 18:28 ` Matthew Wilcox
2025-03-11 7:05 ` Hannes Reinecke
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=4fc21641-e258-474b-9409-4949fe2fda2d@suse.de \
--to=hare@suse.de \
--cc=akpm@linux-foundation.org \
--cc=kuba@kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=vbabka@suse.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).