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 for Android: free password hash cracker in your pocket

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

Message-ID: <20131108075617.GB17807@kmo-pixel>
Date:	Thu, 7 Nov 2013 23:56:17 -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 Thu, Nov 07, 2013 at 11:44:45PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2013 at 11:39:59PM -0800, Kent Overstreet wrote:
> > On Thu, Nov 07, 2013 at 11:33:24PM -0800, Christoph Hellwig wrote:
> > > The changes for direct I/O from kernel space have been in for a long
> > > time, and they are blocking multiple consumers of the interface from
> > > getting submitted for about a year now.  Even if the guts of the
> > > direct-io code will get a write based on another patchset from Kent
> > > that will go on top of the immutable iovec changes we need the
> > > interfaces now and not another year down the road.
> > 
> > What else is blocked on this patch series? Honest question.
> 
> 
> From me alone:
>   Support for ecryptfs to not double cache.
>   AIO support for target_core_file.
> 
> To replace code in staging:
>   Removal of the lustre-specific loop driver.
> 
> And I remember others claiming to want to submit bits, too.

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.

I don't know about ecryptfs and AIO for target, though - are there
patches for those you could point me at so I can have a look? I can
believe the iov_iter stuff is necessary for those, but I'd like to
convince myself there isn't a cleaner solution.

Regardless, I don't want to be blocking anyone else's work; if we do
want the iov_iter stuff in now (I'm not arguing one way or the other
till I look at the issues you pointed out) I can write a small patch to
correctly merge with immutable bvecs; I looked at it today and it's
pretty straightforward (if somewhat ugly).
--
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/