All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
	Mateusz Guzik <mjguzik@gmail.com>,
	viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, oleg@redhat.com,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH] fs: use __fput_sync in close(2)
Date: Tue, 08 Aug 2023 12:48:05 -0500	[thread overview]
Message-ID: <87ttt9ctnu.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <CAHk-=whiKJGTF2_oKOKMi9FzWSzcBkL_hYxOuvG-=Gc_C1JfFg@mail.gmail.com> (Linus Torvalds's message of "Tue, 8 Aug 2023 10:22:18 -0700")

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Tue, 8 Aug 2023 at 10:15, Christian Brauner <brauner@kernel.org> wrote:
>>
>> I think you're at least missing the removal of the PF_KTHREAD check
>
> Yup.
>
>>                 It'd be neat to leave that in so
>> __fput_sync() doesn't get proliferated to non PF_KTHREAD without us
>> noticing. So maybe we just need a tiny primitive.
>
> Considering that over the decade we've had this, we've only grown two
> cases of actually using it, I think we're fine.

That and two cases of flush_delayed_fput() followed by task_work_run().

That combined with a maintainer who was actively against any new
calls to __fput_sync and a version of __fput_sync that called BUG_ON
if you used it.

So I am not 100% convinced that there were so few calls to __fput_sync
simply because people couldn't think of a need for it.

Eric



      reply	other threads:[~2023-08-08 18:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-06 23:06 [PATCH] fs: use __fput_sync in close(2) Mateusz Guzik
2023-08-07  3:18 ` Matthew Wilcox
2023-08-08  5:56 ` Eric W. Biederman
2023-08-08  7:32   ` Mateusz Guzik
2023-08-08  8:13   ` Christian Brauner
2023-08-08  8:23     ` Mateusz Guzik
2023-08-08  8:40       ` Christian Brauner
2023-08-08  9:21         ` Mateusz Guzik
2023-08-08 15:07           ` [PATCH v2 (kindof)] " Mateusz Guzik
2023-08-08 16:30             ` Christian Brauner
2023-08-08 17:00               ` Christian Brauner
2023-08-08 17:05               ` Linus Torvalds
2023-08-08 17:06                 ` Christian Brauner
2023-08-09  9:03                 ` David Laight
2023-08-08 16:57   ` [PATCH] " Linus Torvalds
2023-08-08 17:10     ` Mateusz Guzik
2023-08-08 17:18       ` Linus Torvalds
2023-08-08 17:24         ` Mateusz Guzik
2023-08-08 17:35           ` Christian Brauner
2023-08-08 17:48             ` Linus Torvalds
2023-08-08 17:15     ` Christian Brauner
2023-08-08 17:22       ` Linus Torvalds
2023-08-08 17:48         ` Eric W. Biederman [this message]

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=87ttt9ctnu.fsf@email.froward.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjguzik@gmail.com \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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.