linux-kernel - Re: [PATCH 17/18] fs: icache remove inode

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]

Date:	Wed, 13 Oct 2010 08:20:02 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Nick Piggin <npiggin@...nel.dk>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Dave Chinner <david@...morbit.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 17/18] fs: icache remove inode_lock

On Wed, Oct 13, 2010 at 11:03:07PM +1100, Nick Piggin wrote:
> On Wed, Oct 13, 2010 at 07:28:27AM -0400, Christoph Hellwig wrote:
> > On Wed, Oct 13, 2010 at 06:27:01PM +1100, Nick Piggin wrote:
> > > I'm happy to help to port the top of the patch set onto changes in
> > > earlier parts of it, but I would like the chance to do this really. I'm
> > > back in action now, so I can spend a lot of time catching up.
> > 
> > That's all good and fine, but it's really no reason for delaying getting
> > the most important bits in.
> 
> Really? I *really* think I can be given the chance to review what's
> happened, catch up, and make sure it's foward compatible with the
> rest of my tree.

Please go and review it, the more eyes core code gets the better.  But
don't assume you have carte blanche to delay things again just for the
fun of it.  Other patches in your tree will need at least as many
changes as the inode bits did, so they will need some major work anyway.
Holding the splitup now for things that will take at least another half
a year to hit the tree is rather pointless.

> The most important bits are, in fact, mostly my
> patches anyway unless there is a fundamentally different approach to
> take. And so either way I don't think it is ready for 2.6.37 if it
> hasn't been in vfs for testing and review by fs people -- that's what
> we agreed I thought for the inode and dcache lock splitups.

fs and vfs people have been reviewing the code for the last couple of
weeks, and we're almost done.  Unless we'll find anoher issue it
should go into the vfs tree.  Given that we don't even have a vfs
tree for .37 yet there's no way we could have put it in earlier anyay..

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