linux-kernel - Re: [PATCH 14/19] VFS: Ensure no async updates happening in directory being removed.

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHk-=whEbj9p33Cn_P4PawBqkav8zQq5+WjtzqYCK0o621p1kw@mail.gmail.com>
Date: Sat, 8 Feb 2025 14:30:39 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: NeilBrown <neilb@...e.de>, Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, 
	Jeff Layton <jlayton@...nel.org>, Dave Chinner <david@...morbit.com>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 14/19] VFS: Ensure no async updates happening in directory
 being removed.

On Sat, 8 Feb 2025 at 14:06, Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > OK, I realize that it compiles, but it should've raised all
> > kinds of red flags for anyone reading that.

Well, it's literally just missing a ';' so, the "red flag" is "oops,
nobody noticed the typo".

> > return + <newline> is
> > already fishy, but having the next line indented *less* than that
> > return is firmly in the "somebody's trying to hide something nasty
> > here" territory, even without parsing the damn thing.

Sadly, there are probably no sane way to do semi-automated indentation checks.

> Incidentally, that's where lockdep warnings you've mentioned are
> coming from...

Yeah, so because of the missing ';', and because gcc allows a 'return
<voidfn>()" in a void function (which is actually a useful syntax
extension, so I'm not really complaining), it compiles cleanly but the
lock_acquire_exclusive() is done in *exactly* the wrong situation.

Do we have any useful indentation checkers that might have caught
things like this?

gcc does have a "-Wmisleading-indentation" option, but afaik it only
warns about a few very specific things because anything more
aggressive results in way too many false positives.

I've never used clang-format, but I do know it supports those kinds of
extensions, since I see them in the kernel config file.

                  Linus