linux-kernel - Re: [PATCH v3 08/10] selftests/mm: Skip gup

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Z8mYG8eQnMsOA4c1@google.com>
Date: Thu, 6 Mar 2025 12:42:03 +0000
From: Brendan Jackman <jackmanb@...gle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Shuah Khan <shuah@...nel.org>, Dev Jain <dev.jain@....com>,
	linux-mm@...ck.org, linux-kselftest@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 08/10] selftests/mm: Skip gup_longerm tests on weird
 filesystems

On Thu, Mar 06, 2025 at 10:28:09AM +0100, David Hildenbrand wrote:
> On 28.02.25 17:54, Brendan Jackman wrote:
> > Some filesystems don't support funtract()ing unlinked files. They return
> > ENOENT. In that case, skip the test.
> > 
> 
> That's not documented in the man page, so is this a bug of these
> filesystems?

Um...

unlink(2) does say:

  If the name was the last link to a file but any processes still have
  the file open, the file will remain in existence until the last file
  descriptor referring to it is closed.

And POSIX says

  If one or more processes have the file open when the last link is
  removed, the link shall be removed before unlink() returns, but the
  removal of the file contents shall be postponed until all references
  to the file are closed

I didn't call it a bug in the commit message because my impression was
always that filesystem semantics are broadly determined by vibes. But
looking at the above I do feel more confident that the "unlink isn't
delete" thing is actually a pretty solid expectation.

> What are examples for these weird filesystems?

My experience of the issue is with 9pfs. broonie reported on #mm that
NFS can display similar issues but I haven't hit it myself.

> As we have the fstype available, we could instead simply reject more
> filesystems earlier. See fs_is_unknown().

Oh. I didn't know this was so easy, I thought that checking the
filesystem type would require some awful walk to find the mountpoint
and join it against the mount list. (Now I think about it, I should
have recorded this rationale in the commit message, so you could
easily see my bogus reasoning).

If there's a syscall to just say "what FS is this file on please?"
we should just do that and explicitly denylist the systems that are
known to have issues. I will just do 9pfs for now. Maybe we can log
warning if the error shows up on systems that aren't listed, then if
someone does run into it on NFS they should get a strong clue about
what the problem is.

Thanks!