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>] [day] [month] [year] [list]
Message-ID: <20150703144635.GE9456@thunk.org>
Date:	Fri, 3 Jul 2015 10:46:35 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	nick <xerofoify@...il.com>
Cc:	Michal Hocko <mhocko@...e.cz>, akpm@...ux-foundation.org,
	mgorman@...e.de, n-horiguchi@...jp.nec.com, sasha.levin@...cle.com,
	Yalin.Wang@...ymobile.com, jmarchan@...hat.com,
	kirill@...temov.name, rientjes@...gle.com, vbabka@...e.cz,
	aneesh.kumar@...ux.vnet.ibm.com, ebru.akagunduz@...il.com,
	hannes@...xchg.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH] mm:Make the function zap_huge_pmd bool

On Thu, Jul 02, 2015 at 12:08:36PM -0400, nick wrote:
> I looked into that patch further and would were correct it was wrong.
> However here is a bug fix for the drm driver code that somebody else
> stated was right but haven gotten a reply to from the maintainer and
> have tried resending.

Hi Nick,

Don't bother sending more low-value patches like this; they don't
impress me.  Send me a patch that fixes a deep bug, where you can
demonstrate that you understand the underlying design of the code, can
point out a flaw, and then explain why your patch is an improvement,
and documents how you tested it.  Or do something beyond changing
return values or return types, and optimize some performance-critical
part of the kernel, and in the commit description, explain why it
improves things, how you measured the performance improvement, and why
this is applicable in a real-life situation.

Even a broken clock can be right twice a day, and the fact that it is
possible that you can author a correct patch isn't all that
impressive.  You need to understand deep understanding of the code you
are modifying, and or else it's not worth my time to go through a
large number of low-value patches that don't really improve the code
base much, when the risk that you have accidentally introduced a bug
is high given that (a) you've demonstrated an inability to explain
some of your patches, and (b) in many cases, you have no fear about
sending patches that you can't personally test.  These two
shortcomings in combination are fatal.

If you can demonstrate that you can become a thoughtful and careful
coder, I would be most pleased to argue to Greg K-H that you have
turned over a new leaf.  To date, however, you have not demonstrated
any of the above, and you've made me regret that I've tried to waste
time looking at your patches that you've sent me in the hopes of
convincing me that you've really changed --- when it's clear you
haven't.  I do hope that, one day, you will be able to be a good
coder.  But that day is clearly not today.

Best regards,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ