All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.com>,
	 Al Viro <viro@zeniv.linux.org.uk>,
	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: Tue, 3 Sep 2024 16:31:28 +0200	[thread overview]
Message-ID: <20240903-ernst-besiedeln-e6c9e3f47ef6@brauner> (raw)
In-Reply-To: <20240903135055.jhcusfiopheb2jej@quack3>

On Tue, Sep 03, 2024 at 03:50:55PM GMT, Jan Kara wrote:
> On Fri 30-08-24 15:04:59, 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.
> > 
> > Signed-off-by: Christian Brauner <brauner@kernel.org>
> 
> What makes me a bit uneasy is that we do mutex_init() on the space in
> struct file and then pipe_open() will clobber it. And then we eventually
> call mutex_destroy() on the clobbered mutex. I think so far this does no

We don't call mutex_destroy() on it and don't need to. And calling
mutex_init() is fine precisely because pipes do use it. It would be
really ugly do ensure that mutex_init() isn't called for pipes. But I'll
add a comment.

  reply	other threads:[~2024-09-03 14:31 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 [this message]
2024-09-04 14:08       ` Jan Kara
2024-09-04 14:21   ` Al Viro
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=20240903-ernst-besiedeln-e6c9e3f47ef6@brauner \
    --to=brauner@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.