public inbox for [email protected]
 help / color / mirror / Atom feed
From: Mark Brown <[email protected]>
To: Christian Brauner <[email protected]>
Cc: [email protected], Jan Kara <[email protected]>,
	Christoph Hellwig <[email protected]>, Jens Axboe <[email protected]>,
	Alexander Viro <[email protected]>,
	Dave Chinner <[email protected]>,
	[email protected], Aishwarya TCV <[email protected]>
Subject: Re: [PATCH v2] fs: claw back a few FMODE_* bits
Date: Wed, 3 Apr 2024 22:12:45 +0100	[thread overview]
Message-ID: <[email protected]> (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/[email protected]
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 --]

  parent reply	other threads:[~2024-04-03 21:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28 12:27 [PATCH v2] fs: claw back a few FMODE_* bits Christian Brauner
2024-03-28 13:08 ` Christoph Hellwig
2024-04-02 10:51 ` Jan Kara
2024-04-02 12:59 ` Jens Axboe
2024-04-03 21:12 ` Mark Brown [this message]
2024-04-04  9:12   ` Jan Kara
2024-04-04 11:43     ` Mark Brown
2024-04-05 10:27       ` Christian Brauner
2024-04-05 11:12         ` Mark Brown
2024-04-04  0:18 ` Al Viro
2024-04-05 10:06   ` Christian Brauner
2024-04-06  6:10 ` Al Viro
2024-04-06  6:16   ` Al Viro
2024-04-09  9:12     ` Christian Brauner

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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