On Mon, 2017-09-18 at 10:55 -0400, Mimi Zohar wrote:
> On Mon, 2017-09-18 at 12:13 +0200, Jan Kara wrote:
> > On Mon 18-09-17 10:19:25, Steven Whitehouse wrote:
> > > On 17/09/17 17:38, Al Viro wrote:
> > > >On Sun, Sep 17, 2017 at 09:34:01AM -0700, Linus Torvalds wrote:
> > > >>Now, I suspect most
On Mon, 2017-09-18 at 12:13 +0200, Jan Kara wrote:
> On Mon 18-09-17 10:19:25, Steven Whitehouse wrote:
> > On 17/09/17 17:38, Al Viro wrote:
> > >On Sun, Sep 17, 2017 at 09:34:01AM -0700, Linus Torvalds wrote:
> > >>Now, I suspect most (all?) do, but that's a historical artifact rather
> > >>than
On Mon 18-09-17 10:19:25, Steven Whitehouse wrote:
> On 17/09/17 17:38, Al Viro wrote:
> >On Sun, Sep 17, 2017 at 09:34:01AM -0700, Linus Torvalds wrote:
> >>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
Hi,
On 17/09/17 17:38, Al Viro wrote:
On Sun, Sep 17, 2017 at 09:34:01AM -0700, Linus Torvalds wrote:
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 requiremen
On Sun, Sep 17, 2017 at 09:34:01AM -0700, Linus Torvalds wrote:
> 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 s
On Sun, Sep 17, 2017 at 9:15 AM, Mimi Zohar 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
On Sun, 2017-09-17 at 08:28 -0700, Linus Torvalds wrote:
> On Sun, Sep 17, 2017 at 8:17 AM, Christoph Hellwig wrote:
> >
> > Only for direct I/O, and IMA and direct I/O don't work together.
> > From ima_collect_measurement:
> >
> > if (file->f_flags & O_DIRECT) {
> >
On Sun, Sep 17, 2017 at 08:28:40AM -0700, Linus Torvalds wrote:
> The issue is that somebody else can come in - using direct IO - at the
> same time as the first person is collecting measurements, and thus
> race with the collector.
>
> So now the measurements are not trustworthy any more.
Yes. A
On Sun, Sep 17, 2017 at 8:17 AM, Christoph Hellwig wrote:
>
> Only for direct I/O, and IMA and direct I/O don't work together.
> From ima_collect_measurement:
>
> if (file->f_flags & O_DIRECT) {
> audit_cause = "failed(directio)";
> r
On Sat, Sep 16, 2017 at 11:20:47AM -0700, Linus Torvalds wrote:
> Sure, generic_file_write_iter() does take that lock exclusively, but
> not everybody uses generic_file_write_iter() at all for writing.
>
> For example, xfs still uses that i_rwsem, but for block-aligned writes
> it will only get it
On Sat, 2017-09-16 at 11:20 -0700, Linus Torvalds wrote:
> On Fri, Sep 15, 2017 at 1:25 PM, Mimi Zohar wrote:
> >
> > To resolve this locking problem, this patch defines a new
> > ->integrity_read file operation method, which is equivalent to
> > ->read_iter, except that it will not take the i_rws
On Fri, Sep 15, 2017 at 1:25 PM, Mimi Zohar wrote:
>
> To resolve this locking problem, this patch defines a new
> ->integrity_read file operation method, which is equivalent to
> ->read_iter, except that it will not take the i_rwsem lock, but will
> be called with the i_rwsem held exclusively.
>
From: Christoph Hellwig
Writing extended attributes requires exclusively taking the i_rwsem
lock. To synchronize the file hash calculation and writing the file
hash as security.ima xattr, IMA-appraisal takes the i_rwsem lock
exclusively before calculating the file hash. (Once the file hash
is c
On Fri, Sep 15, 2017 at 2:04 AM, Mimi Zohar wrote:
> On Thu, 2017-09-14 at 22:50 -0700, Linus Torvalds wrote:
>> This is still wrong.
>>
>> (a) there is no explanation for why we need that exclusive lock in the
>> first place
>
>> Why should a read need exclusive access? You'd think shared is suff
On Fri, 2017-09-15 at 07:49 -0700, Christoph Hellwig wrote:
> On Thu, Sep 14, 2017 at 10:50:27PM -0700, Linus Torvalds wrote:
> > This is still wrong.
> >
> > (a) there is no explanation for why we need that exclusive lock in the
> > first place
> >
> > Why should a read need exclusive access? Yo
On Thu, Sep 14, 2017 at 10:50:27PM -0700, Linus Torvalds wrote:
> This is still wrong.
>
> (a) there is no explanation for why we need that exclusive lock in the
> first place
>
> Why should a read need exclusive access? You'd think shared is sufficient.
> But regardless, it needs *explanation*.
On Fri, 2017-09-15 at 05:04 -0400, Mimi Zohar wrote:
> On Thu, 2017-09-14 at 22:50 -0700, Linus Torvalds wrote:
> > This is still wrong.
> >
> > (a) there is no explanation for why we need that exclusive lock in the
> > first place
>
> > Why should a read need exclusive access? You'd think shared
On Thu, 2017-09-14 at 22:50 -0700, Linus Torvalds wrote:
> This is still wrong.
>
> (a) there is no explanation for why we need that exclusive lock in the
> first place
> Why should a read need exclusive access? You'd think shared is sufficient.
True, reading a file shouldn't require an exclusiv
From: Christoph Hellwig
Add a new ->integrity_read file operation to read data for integrity
hash collection. This is defined to be equivalent to ->read_iter,
except that it will be called with the i_rwsem held exclusively.
(Based on Christoph's original patch.)
Signed-off-by: Christoph Hellwi
19 matches
Mail list logo
