From: Christoph Hellwig <hch@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Hellwig <hch@infradead.org>,
Mateusz Guzik <mjguzik@gmail.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Christian Brauner <brauner@kernel.org>,
Leon Romanovsky <leon@kernel.org>,
pr-tracker-bot@kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] vfs mount
Date: Mon, 7 Apr 2025 22:06:33 -0700 [thread overview]
Message-ID: <Z_Su2cIL2U27mZ-N@infradead.org> (raw)
In-Reply-To: <CAHk-=wgtKqZoQZB6VzJr+EQNfsT1r1A9U2zxOrGFb+pqtkTXFA@mail.gmail.com>
On Mon, Apr 07, 2025 at 09:00:10AM -0700, Linus Torvalds wrote:
> On Mon, 7 Apr 2025 at 01:51, Christoph Hellwig <hch@infradead.org> wrote:
> >
> > The scoped one with proper indentation is fine. The non-scoped one is
> > the one that is really confusing and odd.
>
> Ahh, I misunderstood you.
>
> You're obviously right in a "visually obvious" way - even if it was
> the scoped one that caused problems.
>
> But the non-scoped one is *so* convenient when you have a helper
> function that just wants to run with some local (or RCU) held.
I wish we'd just hage a way to run an existing scope, especially a
funtion fun with a lock, e.g.
int some_helper(....)
scoped_lock(&some_mutex)
{
...
}
which would give you that with a much more obvious and redable
syntax. Not taking the resource in the middle of the block and
releasing it at the end will also fix tons of bugs for non-obvious
behavior.
next prev parent reply other threads:[~2025-04-08 5:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-22 10:13 [GIT PULL] vfs mount Christian Brauner
2025-03-24 21:00 ` pr-tracker-bot
2025-04-01 17:07 ` Leon Romanovsky
2025-04-03 8:29 ` Christian Brauner
2025-04-03 15:15 ` Christian Brauner
2025-04-03 15:34 ` James Bottomley
2025-04-03 17:21 ` Mateusz Guzik
2025-04-03 18:09 ` Linus Torvalds
2025-04-03 19:17 ` Mateusz Guzik
2025-04-04 8:28 ` Christoph Hellwig
2025-04-04 14:19 ` Linus Torvalds
2025-04-07 8:51 ` Christoph Hellwig
2025-04-07 16:00 ` Linus Torvalds
2025-04-08 5:06 ` Christoph Hellwig [this message]
2025-04-07 11:22 ` Christian Brauner
2025-04-03 18:24 ` Leon Romanovsky
2025-04-03 19:18 ` Linus Torvalds
2025-04-03 19:45 ` Christian Brauner
2025-04-03 19:55 ` Christian Brauner
2025-04-04 6:16 ` Leon Romanovsky
2025-04-03 19:38 ` James Bottomley
-- strict thread matches above, loose matches on Subject: below --
2025-01-18 13:06 Christian Brauner
2025-01-20 0:10 ` Sasha Levin
2025-01-20 12:21 ` Christian Brauner
2025-01-20 18:59 ` pr-tracker-bot
2024-09-13 14:41 Christian Brauner
2024-09-14 2:33 ` Stephen Rothwell
2024-09-16 11:09 ` pr-tracker-bot
2024-05-10 11:46 Christian Brauner
2024-05-13 19:38 ` pr-tracker-bot
2023-06-23 11:03 [GIT PULL] vfs: mount Christian Brauner
2023-06-26 17:34 ` pr-tracker-bot
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=Z_Su2cIL2U27mZ-N@infradead.org \
--to=hch@infradead.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=brauner@kernel.org \
--cc=leon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=pr-tracker-bot@kernel.org \
--cc=torvalds@linux-foundation.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.