[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwG65-1DZGLkxWzXiPHECjVvY+WHa0ihRq6MbJ4yrX-Sg@mail.gmail.com>
Date: Sun, 1 Oct 2017 11:41:48 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Dave Chinner <david@...morbit.com>,
LSM List <linux-security-module@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Christoph Hellwig <hch@...radead.org>,
"Theodore Ts'o" <tytso@....edu>, Jan Kara <jack@...e.cz>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-integrity@...r.kernel.org
Subject: Re: [RFC PATCH 3/3] fs: detect that the i_rwsem has already been
taken exclusively
On Sun, Oct 1, 2017 at 5:08 AM, Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:
>
> Right, re-introducing the iint->mutex and a new i_generation field in
> the iint struct with a separate set of locks should work. It will be
> reset if the file metadata changes (eg. setxattr, chown, chmod).
Note that the "inner lock" could possibly be omitted if the
invalidation can be just a single atomic instruction.
So particularly if invalidation could be just an atomic_inc() on the
generation count, there might not need to be any inner lock at all.
You'd have to serialize the actual measurement with the "read
generation count", but that should be as simple as just doing a
smp_rmb() between the "read generation count" and "do measurement on
file contents".
Of course, if you do something more complex in invalidation, you may
end up needing a real lock.
Linus
Powered by blists - more mailing lists