[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whynVDmGUG0qNLhGboUKXbTCnKudEr4R=GN5mH-Bz9gLg@mail.gmail.com>
Date: Mon, 31 Oct 2022 12:07:36 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Jann Horn <jannh@...gle.com>, Miklos Szeredi <mszeredi@...hat.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Will Deacon <will@...nel.org>
Subject: Re: [PATCH v2] fs: use acquire ordering in __fget_light()
On Mon, Oct 31, 2022 at 11:48 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Anyway, it's unrelated to the patch itself. I'm fine with it in the current
> form. Will apply for the next merge window, unless Linus wants it in right
> now.
It doesn't strike me as hugely critical, so I'm fine with it being put
in any random pile of "fixes to be applied" as long as it doesn't get
lost entirely. But if y ou have a "fixes" branch that may end up
coming to me before this release is over, that's not the wrong place
either.
I would tend to agree with Jann that the re-ordering doesn't look very
likely because it's the same cacheline, so even an aggressively
out-of-order core really doesn't seem to be very likely to trigger any
issues. So you have a really unlikely situation to begin with, and
even less reason for it then triggering the re-ordering.
The "original situation is unlikely" can probably be made quite likely
with an active attack, but that active attacker would then also also
have to rely on "that re-ordering looks sketchy", and actively hunt
for hardware where it can happen.
And said hardware may simply not exist, even if the race is certainly
theoretically possible on any weakly ordered CPU.
Linus
Powered by blists - more mailing lists