[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250623-absetzbar-barzahlung-3d124847a2b4@brauner>
Date: Mon, 23 Jun 2025 13:50:20 +0200
From: Christian Brauner <brauner@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: Andrew Lunn <andrew@...n.ch>, Eric Dumazet <edumazet@...gle.com>,
"David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
David Hildenbrand <david@...hat.com>, John Hubbard <jhubbard@...dia.com>,
Christoph Hellwig <hch@...radead.org>, willy@...radead.org, Al Viro <viro@...iv.linux.org.uk>,
Miklos Szeredi <mszeredi@...hat.com>, torvalds@...ux-foundation.org, netdev@...r.kernel.org,
linux-mm@...ck.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: AF_UNIX/zerocopy/pipe/vmsplice/splice vs FOLL_PIN
On Mon, May 12, 2025 at 03:51:30PM +0100, David Howells wrote:
> I'm looking at how to make sendmsg() handle page pinning - and also working
> towards supporting the page refcount eventually being removed and only being
> available with certain memory types.
>
> One of the outstanding issues is in sendmsg(). Analogously with DIO writes,
> sendmsg() should be pinning memory (FOLL_PIN/GUP) rather than simply getting
> refs on it before it attaches it to an sk_buff. Without this, if memory is
> spliced into an AF_UNIX socket and then the process forks, that memory gets
> attached to the child process, and the child can alter the data, probably by
> accident, if the memory is on the stack or in the heap.
>
> Further, kernel services can use MSG_SPLICE_PAGES to attach memory directly to
> an AF_UNIX pipe (though I'm not sure if anyone actually does this).
I would possible be interested in using this for the coredump af_unix socket.
Powered by blists - more mailing lists