lkml.org 
[lkml]   [2017]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 3/3] ima: use fs method to read integrity data (updated patch description)
On Sun, Sep 17, 2017 at 9:15 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
>
> Unless I'm missing something, that would only be possible with an IMA
> policy rule that permits direct IO (eg. permit_directio). Otherwise
> the direct IO is denied.

Note that the "XFS and directio" was only an example.

There is absolutely nothing that says that a filesystem has to use
i_rwsem for IO serialization at all. Even for the regular write path.

Now, I suspect most (all?) do, but that's a historical artifact rather
than "design". In particular, the VFS layer used to do the locking for
the filesystems, to guarantee the POSIX requirements (POSIX requires
that writes be seen atomically).

But that lock was pushed down into the filesystems, since some
filesystems really wanted to have parallel writes (particularly for
direct IO, where that POSIX serialization requirement doesn't exist).

That's all many years ago, though. New filesystems are likely to have
copied the pattern from old ones, but even then..

Also, it's worth noting that "inode->i_rwlock" isn't even well-defined
as a lock. You can have the question of *which* inode gets talked
about when you have things like eoverlayfs etc. Normally it would be
obvious, but sometimes you'd use "file->f_mapping->host" (which is the
same thing in the simple cases), and sometimes it really wouldn't be
obvious at all..

So... I'm really not at all convinced that i_rwsem is sensible. It's
one of those things that are "mostly right for the simple cases",
but...

Linus

\
 
 \ /
  Last update: 2017-09-17 18:34    [W:1.130 / U:0.148 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site