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]

Message-ID: <20101015141141.GA4359@amd>
Date:	Sat, 16 Oct 2010 01:11:41 +1100
From:	Nick Piggin <npiggin@...nel.dk>
To:	Nick Piggin <npiggin@...nel.dk>
Cc:	Dave Chinner <david@...morbit.com>,
	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 17/18] fs: icache remove inode_lock

On Sat, Oct 16, 2010 at 12:03:00AM +1100, Nick Piggin wrote:
> On Fri, Oct 15, 2010 at 09:59:43PM +1100, Dave Chinner wrote:
> > On Fri, Oct 15, 2010 at 05:41:50PM +1100, Nick Piggin wrote:
> > > - inode io lists and locking made per-bdi
> > 
> > And I've pulled that in done that, too while dropping all the messy
> > list manipulation loops as the wrong bdi problem is fixed upstream now.
> > 
> > Nothing I've done prevents RCU-ising the inode cache, but I've
> > discovered some issues that you've missed in moving straight to
> > fine-grained per-zone LRU lists and locking. I think the code is
> > cleaner (no trylocks or loops to get locks out of order), the series
> > is cleaner and it has gone through a couple of rounds of review
> > already.  This is why I'd like you to try rebasing your tree on top
> > of it to determine if my assertions that there are no inhernet
> > problems are correct....
> 
> You have it upside down, I think. I've got way more work sitting
> here that has been tested and in my opinion has the better set
> of steps to transform the locking.

I mean, come on. You've done 2 _whole_ weeks of work on this,
(how many hours of testing, how many workloads, what sizes of
machines? google? intel? people who are actually reporting real
world problems?) and you want _me_ to rebase my entire tree on
some bits of yours that I don't even entirely agree with, and you
want me to tell you if you've stuffed anything up and that I
should go away and retest the whole stack and ask everyone else
to redo their testing results again? 

What do you want here? Do you think it's actually going to give
some results more quickly to go through with that?

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