All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.com>,
	Jeff Layton <jlayton@kernel.org>,
	Josef Bacik <josef@toxicpanda.com>, Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH RFC 18/20] fs: add f_pipe
Date: Wed, 4 Sep 2024 15:21:40 +0100	[thread overview]
Message-ID: <20240904142140.GH1049718@ZenIV> (raw)
In-Reply-To: <20240830-vfs-file-f_version-v1-18-6d3e4816aa7b@kernel.org>

On Fri, Aug 30, 2024 at 03:04:59PM +0200, Christian Brauner wrote:
> Only regular files with FMODE_ATOMIC_POS and directories need
> f_pos_lock. Place a new f_pipe member in a union with f_pos_lock
> that they can use and make them stop abusing f_version in follow-up
> patches.

Not sure I like that - having lseek(2) use a separate primitive
instead of fdget_pos(), grabbing ->f_pos_lock for _everything_ that
has FMODE_LSEEK, directory or no directory, would simplify quite
a few things.  OTOH, that will affect only the explanation of validity -
pipes do *not* have FMODE_LSEEK, so it becomes "fdget_pos() and
fdget_seek() are the only things that might want ->f_pos_lock, and
neither touch it for pipes - fdget_pos() because FMODE_ATOMIC_POS
is not there and fdget_seek() because FMODE_LSEEK isn't".

Oh, well...

  parent reply	other threads:[~2024-09-04 14:21 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-30 13:04 [PATCH RFC 00/20] file: remove f_version Christian Brauner
2024-08-30 13:04 ` [PATCH RFC 01/20] file: remove pointless comment Christian Brauner
2024-09-03 10:28   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 02/20] adi: remove unused f_version Christian Brauner
2024-09-03 10:30   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 03/20] ceph: " Christian Brauner
2024-09-03 10:30   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 04/20] s390: " Christian Brauner
2024-09-03 10:31   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 05/20] fs: add vfs_setpos_cookie() Christian Brauner
2024-09-03 11:35   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 06/20] fs: add must_set_pos() Christian Brauner
2024-09-03 11:32   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 07/20] fs: use must_set_pos() Christian Brauner
2024-09-03 11:30   ` Jan Kara
2024-09-03 11:41     ` Christian Brauner
2024-08-30 13:04 ` [PATCH RFC 08/20] fs: add generic_llseek_cookie() Christian Brauner
2024-09-03 11:34   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 09/20] affs: store cookie in private data Christian Brauner
2024-09-03 13:26   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 10/20] ext2: " Christian Brauner
2024-09-03 11:42   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 11/20] ext4: " Christian Brauner
2024-09-01 19:36   ` Theodore Ts'o
2024-09-03 11:37   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 12/20] input: remove f_version abuse Christian Brauner
2024-09-03 11:40   ` Jan Kara
2024-09-12  2:52   ` Lai, Yi
2024-09-12 10:02     ` Christian Brauner
2024-08-30 13:04 ` [PATCH RFC 13/20] ocfs2: store cookie in private data Christian Brauner
2024-09-03 13:27   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 14/20] proc: " Christian Brauner
2024-09-03 11:34   ` Christian Brauner
2024-09-03 13:35     ` Jan Kara
2024-09-03 14:00       ` Christian Brauner
2024-09-04 14:16         ` Jan Kara
2024-09-05  9:28           ` Christian Brauner
2024-09-03 13:33   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 15/20] udf: " Christian Brauner
2024-09-03 13:37   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 16/20] ufs: " Christian Brauner
2024-09-03 13:38   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 17/20] ubifs: " Christian Brauner
2024-09-03 13:39   ` Jan Kara
2024-08-30 13:04 ` [PATCH RFC 18/20] fs: add f_pipe Christian Brauner
2024-09-03 13:50   ` Jan Kara
2024-09-03 14:31     ` Christian Brauner
2024-09-04 14:08       ` Jan Kara
2024-09-04 14:21   ` Al Viro [this message]
2024-08-30 13:05 ` [PATCH RFC 19/20] pipe: use f_pipe Christian Brauner
2024-09-03 13:45   ` Jan Kara
2024-08-30 13:05 ` [PATCH RFC 20/20] fs: remove f_version Christian Brauner
2024-09-03 13:45   ` Jan Kara
2024-08-30 14:04 ` [PATCH RFC 00/20] file: " Jeff Layton

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 \
    --in-reply-to=20240904142140.GH1049718@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.com \
    --cc=jlayton@kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.