linux-kernel - Re: [GIT PULL] vfs mount

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wjksLMWq8At_atu6uqHEY9MnPRu2EuRpQtAC8ANGg82zw@mail.gmail.com>
Date: Thu, 3 Apr 2025 11:09:41 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: James Bottomley <James.Bottomley@...senpartnership.com>, 
	Christian Brauner <brauner@...nel.org>, Leon Romanovsky <leon@...nel.org>, pr-tracker-bot@...nel.org, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] vfs mount

On Thu, 3 Apr 2025 at 10:21, Mateusz Guzik <mjguzik@...il.com> wrote:
>
> I would argue it would be best if a language wizard came up with a way
> to *demand* explicit use of { } and fail compilation if not present.

I tried to think of some sane model for it, but there isn't any good syntax.

The only way to enforce it would be to also have a "end" marker, ie do
something like

        scoped_guard(x) {
                ...
        } end_scoped_guard;

and that you could more-or-less enforce by having

    #define scoped_guard(..) ... real guard stuff .. \
                do {

    #define end_scope } while (0)

where in addition we could add some dummy variable declaration inside
scoped_guard(), and have a dummy use of that variable in the
end_scope, just to further make sure the two pair up.

It does have the advantage of allowing more flexibility with fewer
tricks when you can define your scope in the macros. Right now
"scoped_guard()" plays some rather ugly games internally, just in
order to avoid this pattern.

And that pattern isn't actually new. We *used* to have this pattern in

        do_each_thread(g, t) {
                ...
        } while_each_thread(g, t);

and honestly, people seemed to hate it.

(Also, sparse has that pattern as

        FOR_EACH_PTR(filelist, file) {
                ...
        } END_FOR_EACH_PTR(file);

and it actually works quite well and once you get used to it it's
nice, but I do think people tend to find it really really odd)

> This would also provide a nice side effect of explicitly delineating
> what's protected.

Sadly, I think we have too many uses for this to be worth it any more.
And I do suspect people would hate the odd "both beginning and end"
thing even if it adds some safety.

I dunno. I personally don't mind the "delineate both the beginning and
the end", but we don't have a great history of it.

               Linus