linux-ext4 - [PATCH 0/1] iomap: Direct I/O for inline data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20180627003906.15571-1-agruenba@redhat.com>
Date:   Wed, 27 Jun 2018 02:39:05 +0200
From:   Andreas Gruenbacher <agruenba@...hat.com>
To:     Christoph Hellwig <hch@....de>
Cc:     cluster-devel@...hat.com, linux-ext4@...r.kernel.org,
        linux-fsdevel@...r.kernel.org,
        Andreas Gruenbacher <agruenba@...hat.com>
Subject: [PATCH 0/1] iomap: Direct I/O for inline data

Here's a patch that implements direct I/O for inline data.  Direct I/O
to inline data is a bit weird because it's not direct in the usual
sense, but since Christoph's been asking for it ...

The usual alignment restrictions to the logical block size of the
underlying block device still apply.  I don't see a reason for changing
that; the resulting behavior would only become very weird for no
benefit.

I've tested this against a hacked-up version of gfs2.  However, the
"real" gfs2 will keep falling back to buffered I/O for writes to inline
data: gfs2 takes a shared lock during direct I/O, and writing to the
inode under that shared lock is not allowed.  Ext4 may become the first
actual user of this part of the patch.

Thanks,
Andreas

Andreas Gruenbacher (1):
  iomap: Direct I/O to inline data

 fs/iomap.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

-- 
2.17.1