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: <20131108081737.GA27885@kmo-pixel>
Date:	Fri, 8 Nov 2013 00:17:37 -0800
From:	Kent Overstreet <kmo@...erainc.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	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:02:21AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2013 at 11:56:17PM -0800, Kent Overstreet wrote:
> > So, I don't think the iov_iter stuff is the right approach for solving
> > the loop issue; it's an ugly hack and after immutable biovecs we're
> > pretty close to a better solution and some major cleanups too.
> 
> All the consumers aren't limited to a block-based filesystem backing,
> including loop.  So we need a file-ops based approach for in-kernel
> dio/aio.  If you have a counter proposal please at least describe it.

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.

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.

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 :)
--
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/