linux-kernel - Re: [PATCH 11/46] fs: dcache scale hash

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: <20101210090126.GH8259@dastard>
Date:	Fri, 10 Dec 2010 20:01:26 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Nick Piggin <npiggin@...nel.dk>
Cc:	Nick Piggin <npiggin@...il.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 11/46] fs: dcache scale hash

On Fri, Dec 10, 2010 at 01:35:20PM +1100, Nick Piggin wrote:
> On Fri, Dec 10, 2010 at 10:42:58AM +1100, Dave Chinner wrote:
> > On Thu, Dec 09, 2010 at 11:53:27PM +1100, Nick Piggin wrote:
> > > Necessary changes to prevent bad ugliness resulting, or preventing
> > > repeated steps for the particular changes, etc. of course. Killing un
> > > related functions no.
> > 
> > Ok, I get the picture. You don't want a code review, you want a
> > rubber stamp. Find someone else to get it from.
> 
> Of course I want code review. I am not going to just do everything
> you say that I don't agree with, but I will explain why every time
> (as I have done to all your points).

Which generally comes down to "I disagree with you". That's hard to
argue against because you aren't willing to compromise.

So, to address your next comment, I'll restate what I was proposing.
That is, to ensure all the d_flags accesses protected by d_lock as
an initial patch rather than cleaning it up in an ad-hoc fashion
later on, such as this later patch in your series:

[PATCH 14/46] fs: dcache scale d_unhashed

which has the description:

	Protect d_unhashed(dentry) condition with d_lock.

which illustrates my point that not all accesses to d_flags are
currently protected by d_lock as you are asserting. Hence:

> I would prefer more in-depth review than from someone who doesn't know
> d_lock protects d_flags,

Your implication about my competence is incorrect and entirely
inappropriate.  Ad hominen attacks don't improve your argument or
encourage other people to review your code.

> but any and all help is welcome. Even minor
> nitpicking or cleanups are welcome if they are relevant to the patches.

If _you_ decide they are relevant.

Nick, in the past couple of months you've burnt everyone who has
tried to review your changes in any meaningful way. Nobody wants to
engage with you because you've aggressively disagreed with every
significant change that has been requested. You have shown no desire
to compromise, instead you argue that you are right until you've had
the last word, and you have frequently resorted to condesending and
disrespectful attacks on reviewers. You would do well to keep that
in mind next time you wonder why nobody is stepping up to review
your code.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/