On Mon, 2017-10-02 at 08:09 -0400, Mimi Zohar wrote:
> On Mon, 2017-10-02 at 15:35 +1100, Dave Chinner wrote:
> > On Sun, Oct 01, 2017 at 07:42:42PM -0400, Mimi Zohar wrote:
> > > On Mon, 2017-10-02 at 09:34 +1100, Dave Chinner wrote:
> > > > On Sun, Oct 01, 2017 at 11:41:48AM -0700, Linus Torvalds
On Sun, 2017-10-01 at 22:25 -0500, Eric W. Biederman wrote:
> Mimi Zohar writes:
> > There should be no open writers in ima_check_last_writer(), so the
> > file shouldn't be changing.
>
> This is slightly tangential but I think important to consider.
> What do you do about distributed filesystem
On Mon, 2017-10-02 at 15:35 +1100, Dave Chinner wrote:
> On Sun, Oct 01, 2017 at 07:42:42PM -0400, Mimi Zohar wrote:
> > On Mon, 2017-10-02 at 09:34 +1100, Dave Chinner wrote:
> > > On Sun, Oct 01, 2017 at 11:41:48AM -0700, Linus Torvalds wrote:
> > > > On Sun, Oct 1, 2017 at 5:08 AM, Mimi Zohar
On Sun, Oct 01, 2017 at 07:42:42PM -0400, Mimi Zohar wrote:
> On Mon, 2017-10-02 at 09:34 +1100, Dave Chinner wrote:
> > On Sun, Oct 01, 2017 at 11:41:48AM -0700, Linus Torvalds wrote:
> > > On Sun, Oct 1, 2017 at 5:08 AM, Mimi Zohar
> > > wrote:
> > > >
> > > > Right, re-introducing the iint->mu
On Sun, Oct 01, 2017 at 04:15:07PM -0700, Linus Torvalds wrote:
> On Sun, Oct 1, 2017 at 3:34 PM, Dave Chinner wrote:
> >
> > We already have a change counter on the inode, which is modified on
> > any data or metadata write (i_version) under filesystem locks. The
> > i_version counter has well d
Mimi Zohar writes:
> On Mon, 2017-10-02 at 09:34 +1100, Dave Chinner wrote:
>> On Sun, Oct 01, 2017 at 11:41:48AM -0700, Linus Torvalds wrote:
>> > On Sun, Oct 1, 2017 at 5:08 AM, Mimi Zohar
>> > wrote:
>> > >
>> > > Right, re-introducing the iint->mutex and a new i_generation field in
>> > > t
On Sun, 2017-10-01 at 15:20 -0700, Linus Torvalds wrote:
> On Sun, Oct 1, 2017 at 3:06 PM, Eric W. Biederman
> wrote:
> >
> > Unless I misread something it was being pointed out there are some vfs
> > operations today on which ima writes an ima xattr as a side effect. And
> > those operations ho
On Mon, 2017-10-02 at 09:34 +1100, Dave Chinner wrote:
> On Sun, Oct 01, 2017 at 11:41:48AM -0700, Linus Torvalds wrote:
> > On Sun, Oct 1, 2017 at 5:08 AM, Mimi Zohar wrote:
> > >
> > > Right, re-introducing the iint->mutex and a new i_generation field in
> > > the iint struct with a separate set
On Sun, Oct 1, 2017 at 3:34 PM, Dave Chinner wrote:
>
> We already have a change counter on the inode, which is modified on
> any data or metadata write (i_version) under filesystem locks. The
> i_version counter has well defined semantics - it's required by
> NFSv4 to increment on any metadata o
On Sun, Oct 01, 2017 at 11:41:48AM -0700, Linus Torvalds wrote:
> On Sun, Oct 1, 2017 at 5:08 AM, Mimi Zohar 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
On Sun, Oct 1, 2017 at 3:06 PM, Eric W. Biederman wrote:
>
> Unless I misread something it was being pointed out there are some vfs
> operations today on which ima writes an ima xattr as a side effect. And
> those operations hold the i_sem. So perhaps I am misunderstanding
> things or writing th
Linus Torvalds writes:
> On Sep 30, 2017 18:33, "Eric W. Biederman" wrote:.
>
> That would require a task_work or another kind of work callback so that
> the writes of the xattr are not synchronous with the vfs callback
> correct?
>
> No, why?
>
> You should just invalidate the IMA on xattr w
On Sun, Oct 1, 2017 at 5:08 AM, Mimi Zohar 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 p
On Sat, 2017-09-30 at 18:56 -0700, Linus Torvalds wrote:
> On Sep 30, 2017 18:33, "Eric W. Biederman" wrote:.
>
>
> That would require a task_work or another kind of work callback so that
> the writes of the xattr are not synchronous with the vfs callback
> correct?
>
>
> No, why?
>
> You sho
Linus Torvalds writes:
> On Thu, Sep 28, 2017 at 6:53 PM, Mimi Zohar wrote:
>>
>> The locking issue isn't with validating the file hash, but with the
>> setxattr, chmod, chown syscalls. Each of these syscalls takes the
>> i_rwsem exclusively before IMA (or EVM) is called.
>
> Read my email agai
On Thu, Sep 28, 2017 at 6:53 PM, Mimi Zohar wrote:
>
> The locking issue isn't with validating the file hash, but with the
> setxattr, chmod, chown syscalls. Each of these syscalls takes the
> i_rwsem exclusively before IMA (or EVM) is called.
Read my email again.
> In setxattr, chmod, chown sy
On Thu, 2017-09-28 at 17:33 -0700, Linus Torvalds wrote:
> On Thu, Sep 28, 2017 at 5:12 PM, Mimi Zohar wrote:
> >
> > Originally IMA did define it's own lock, prior to IMA-appraisal. IMA-
> > appraisal introduced writing the file hash as an xattr, which required
> > taking the i_mutex. process_m
On Thu, Sep 28, 2017 at 5:12 PM, Mimi Zohar wrote:
>
> Originally IMA did define it's own lock, prior to IMA-appraisal. IMA-
> appraisal introduced writing the file hash as an xattr, which required
> taking the i_mutex. process_measurement() and ima_file_free() took
> the iint->mutex first and t
On Thu, 2017-09-28 at 16:39 -0700, Linus Torvalds wrote:
> On Thu, Sep 28, 2017 at 3:02 PM, Dave Chinner wrote:
> > On Thu, Sep 28, 2017 at 08:39:33AM -0400, Mimi Zohar wrote:
> >> Don't attempt to take the i_rwsem, if it has already been taken
> >> exclusively.
> >>
> >> Signed-off-by: Mimi Zoha
On Thu, Sep 28, 2017 at 3:02 PM, Dave Chinner wrote:
> On Thu, Sep 28, 2017 at 08:39:33AM -0400, Mimi Zohar wrote:
>> Don't attempt to take the i_rwsem, if it has already been taken
>> exclusively.
>>
>> Signed-off-by: Mimi Zohar
>
> That's bloody awful.
>
> The locking in filesystem IO paths is
On Thu, Sep 28, 2017 at 08:39:33AM -0400, Mimi Zohar wrote:
> Don't attempt to take the i_rwsem, if it has already been taken
> exclusively.
>
> Signed-off-by: Mimi Zohar
That's bloody awful.
The locking in filesystem IO paths is already complex enough without
adding a new IO path semantic tha
Don't attempt to take the i_rwsem, if it has already been taken
exclusively.
Signed-off-by: Mimi Zohar
---
fs/ext2/file.c| 6 --
fs/ext4/file.c| 8 +---
fs/xfs/xfs_file.c | 10 ++
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/fs/ext2/file.c b/fs/ext2/
22 matches
Mail list logo
