Re: [PATCH v2] fs: claw back a few FMODE_* bits

From: Mark Brown <broonie@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>,
	Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Dave Chinner <david@fromorbit.com>,
	io-uring@vger.kernel.org, Aishwarya TCV <Aishwarya.TCV@arm.com>
Subject: Re: [PATCH v2] fs: claw back a few FMODE_* bits
Date: Wed, 3 Apr 2024 22:12:45 +0100	[thread overview]
Message-ID: <9bb5e9ad-d788-441e-96f3-489a031bb387@sirena.org.uk> (raw)
In-Reply-To: <20240328-gewendet-spargel-aa60a030ef74@brauner>

[-- Attachment #1: Type: text/plain, Size: 4195 bytes --]

On Thu, Mar 28, 2024 at 01:27:24PM +0100, Christian Brauner wrote:
> There's a bunch of flags that are purely based on what the file
> operations support while also never being conditionally set or unset.
> IOW, they're not subject to change for individual files. Imho, such
> flags don't need to live in f_mode they might as well live in the fops
> structs itself. And the fops struct already has that lonely
> mmap_supported_flags member. We might as well turn that into a generic
> fop_flags member and move a few flags from FMODE_* space into FOP_*
> space. That gets us four FMODE_* bits back and the ability for new
> static flags that are about file ops to not have to live in FMODE_*
> space but in their own FOP_* space. It's not the most beautiful thing
> ever but it gets the job done. Yes, there'll be an additional pointer
> chase but hopefully that won't matter for these flags.

For the past couple of days several LTP tests (open_by_handle_at0[12]
and name_to_handle_at01) have been failing on all the arm64 platforms
we're running these tests on.  I ran a bisect which came back to this
commit which is in -next as 80a07849c0b8d8a2e839c8.  I didn't verify a
revert against -next due to conflicts and it being pretty late but I'm a
little suspicous this report is misdrected, the commit doesn't look
obviously relevant but equally I'm totally unfamiliar with this bit of
the code.  

We use a NFS root for our testing.  The last pass was next-20240328 and
while the bisect was run on yesterday's -next things still look bad
today.

Bisect log:

git bisect start
# bad: [c0b832517f627ead3388c6f0c74e8ac10ad5774b] Add linux-next specific files for 20240402
git bisect bad c0b832517f627ead3388c6f0c74e8ac10ad5774b
# good: [0fc83069bcaee78f60b8511d9453a9441963a072] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git
git bisect good 0fc83069bcaee78f60b8511d9453a9441963a072
# bad: [784b758e641c4b36be7ef8ab585bea834099b030] Merge branch 'for-linux-next' of https://gitlab.freedesktop.org/drm/misc/kernel.git
git bisect bad 784b758e641c4b36be7ef8ab585bea834099b030
# good: [8b8b4dca2ddd82d3ae7e2a6a2fc7d49e511ceae7] Merge branch 'dev' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat.git
git bisect good 8b8b4dca2ddd82d3ae7e2a6a2fc7d49e511ceae7
# bad: [2c20b30ed316f5cb8773e5f99c02cd997f2374b7] Merge branch 'main' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
git bisect bad 2c20b30ed316f5cb8773e5f99c02cd997f2374b7
# bad: [bbe99111e156e6838845511debc03f4ef5041f1a] Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
git bisect bad bbe99111e156e6838845511debc03f4ef5041f1a
# bad: [7e4f9465775837c3af79501698b0bb5ce28ffb11] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git
git bisect bad 7e4f9465775837c3af79501698b0bb5ce28ffb11
# good: [a2b4cab9da7746c42f87c13721d305baf0085a20] Merge branch 'for-6.10' into for-next
git bisect good a2b4cab9da7746c42f87c13721d305baf0085a20
# bad: [35c44ac8370af87614db9d0727da06a07d5436a2] Merge branch 'vfs.mount.api' into vfs.all
git bisect bad 35c44ac8370af87614db9d0727da06a07d5436a2
# good: [16634c0975ba6569991274e7a4ccbb15766e31d3] Merge patch series 'fs: aio: more folio conversion' of https://lore.kernel.org/r/20240321131640.948634-1-wangkefeng.wang@huawei.com
git bisect good 16634c0975ba6569991274e7a4ccbb15766e31d3
# bad: [276832a7ef840783bf867abe680db0eb6b3d4655] Merge branch 'vfs.misc' into vfs.all
git bisect bad 276832a7ef840783bf867abe680db0eb6b3d4655
# good: [1b43c4629756a2c4bbbe4170eea1cc869fd8cb91] fs: Annotate struct file_handle with __counted_by() and use struct_size()
git bisect good 1b43c4629756a2c4bbbe4170eea1cc869fd8cb91
# good: [22650a99821dda3d05f1c334ea90330b4982de56] fs,block: yield devices early
git bisect good 22650a99821dda3d05f1c334ea90330b4982de56
# bad: [80a07849c0b8d8a2e839c83cea939c2e1cd7800b] fs: claw back a few FMODE_* bits
git bisect bad 80a07849c0b8d8a2e839c83cea939c2e1cd7800b
# first bad commit: [80a07849c0b8d8a2e839c83cea939c2e1cd7800b] fs: claw back a few FMODE_* bits

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]