netdev - Re: MSG_ZEROCOPY and the O

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 for Android: free password hash cracker in your pocket

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

Message-ID: <63d93fc8-874f-4620-8df3-160cb24edc0c@redhat.com>
Date: Fri, 2 May 2025 15:48:06 +0200
From: David Hildenbrand <david@...hat.com>
To: David Howells <dhowells@...hat.com>, Andrew Lunn <andrew@...n.ch>
Cc: John Hubbard <jhubbard@...dia.com>, "David S. Miller"
 <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
 willy@...radead.org, netdev@...r.kernel.org, linux-mm@...ck.org
Subject: Re: MSG_ZEROCOPY and the O_DIRECT vs fork() race

On 02.05.25 15:41, David Howells wrote:
> Andrew Lunn <andrew@...n.ch> wrote:
> 
>>> I'm looking into making the sendmsg() code properly handle the 'DIO vs
>>> fork' issue (where pages need pinning rather than refs taken) and also
>>> getting rid of the taking of refs entirely as the page refcount is going
>>> to go away in the relatively near future.
>>
>> Sorry, new to this conversation, and i don't know what you mean by DIO
>> vs fork.
> 
> As I understand it, there's a race between O_DIRECT I/O and fork whereby if
> you, say, start a DIO read operation on a page and then fork, the target page
> gets attached to child and a copy made for the parent (because the refcount is
> elevated by the I/O) - and so only the child sees the result.  This is made
> more interesting by such as AIO where the parent gets the completion
> notification, but not the data.
> 
> Further, a DIO write is then alterable by the child if the DMA has not yet
> happened.
> 
> One of the things mm/gup.c does is to work around this issue...  However, I
> don't think that MSG_ZEROCOPY handles this - and so zerocopy sendmsg is, I
> think, subject to the same race.

If it's using FOLL_PIN it works. If not, it's still to be fixed.

-- 
Cheers,

David / dhildenb