linux-kernel - Re: linux-next: manual merge of the block tree with the tree

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131108083251.GA20121@infradead.org>
Date:	Fri, 8 Nov 2013 00:32:51 -0800
From:	Christoph Hellwig <hch@...radead.org>
To:	Kent Overstreet <kmo@...erainc.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Dave Kleikamp <dave.kleikamp@...cle.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Jens Axboe <axboe@...nel.dk>, linux-next@...r.kernel.org,
	linux-kernel@...r.kernel.org, Zach Brown <zab@...bo.net>,
	Olof Johansson <olof@...om.net>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: linux-next: manual merge of the block tree with the  tree

On Fri, Nov 08, 2013 at 12:17:37AM -0800, Kent Overstreet wrote:
> The core issue isn't whether the IO is going to a block based filesystem
> (but thanks for pointing out that that's not necessarily true!) but
> whether we want to work with pinned pages or not. If pinned pages are ok
> for everything, then bios as a common interface work - likely evolving
> them a bit to be more general (it's just bi_bdev and bi_sector that's
> actually block specific) - and IMO that would be far preferable to this
> abstraction layer.
> 
> If OTOH we need a common interface that's also for places where we can't
> afford the overhead of pinning user pages - that's a different story,
> and maybe we do need all this infrastructure then. That's why I'm asking
> about the stuff you meantioned, I'm honestly not sure.

For both of them we will deal with kernel-allocated pages that are never
mapped to userspace.  This is likely to be true for all the consumers
of in-kernel aio/dio as the existing interfaces handle user pages just
fine.

> What I'm working towards though is a clean separation between buffered
> and direct code paths, so that buffered IO can continue work with iovs
> and for O_DIRECT the first thing you do is fill out a bio with pinned
> pages and send it down to filesystem code or wherever it's going to go.

I don't think pushing bios above the fs interface is a good idea. Note
that the iovecs come from userspace for the user pages cases, so there
is little we can do about that, and non-bio based direct I/O
implementations generally work directly at just that level and never
even touch the direct-io.c code.

If you want to redo the ->direct_IO address_space operation and
generic_file_direct_write and the direct I/O side of
generic_file_aio_read (both of which aren't anywhere near as generic as
the name claims) I'm all for it, but it really won't affect the consumer
of the in-kernel aio/dio code.

> That make sense? I can show you more concretely what I'm working on if
> you want. Or if I'm full of crap and this is useless for what you guys
> want I'm sure you'll let me know :)

It sounds interesting, but also a little confusing at this point, at
least from the non-block side of view.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/