linux-kernel - Re: First kernel patch (optimization)

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:	Fri, 18 Sep 2015 22:26:24 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Josh Boyer <jwboyer@...oraproject.org>,
	Eric Curtin <ericcurtin17@...il.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Steve Calfee <stevecalfee@...il.com>,
	Valentina Manea <valentina.manea.m@...il.com>,
	Shuah Khan <shuah.kh@...sung.com>,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: First kernel patch (optimization)

On Fri, Sep 18, 2015 at 12:42:48AM -0700, Greg KH wrote:
> So don't take cleanup patches for your code, that's fine, and I totally
> understand why _you_ don't want to do that.  But to blow off the effort
> as being somehow trivial and not worthy of us, that's totally missing
> the point, and making things harder on yourself in the end.

It's not that I think cleanup patches are "trivial and not worthy of
us", although I'll note that cleanup patches can end up causing real
bug fixes (including possibly fixes that address security problems) to
not apply to stable kernels, which means someone needs to deal with
failed patches --- or what is much more likely, the failed patch gets
bounced back to the overworked maintainer who then drops the patch
because he or she doesn't have the bandwidth to manually backport the
patch to N different stable trees, and then we all suffer.  So cleanup
patches *do* have a cost.

Rather, what concerns me is that we aren't pushing people to go
*beyond* cleanup patches.  We have lots of tutorials about how to
create perfectly formed patches; but we don't seem to have patches
about how to do proper benchmarking.  Or how to check system call and
ioctl interfaces to make sure the code is doing appropriate input
checking.  So I don't want to pre-reject these people; but to rather
push them and to help them to try their hand at more substantive work.

What surprises me is the apparent assumption that people need a huge
amount of hand-holding on how to properly form a patch, but that
people will be able to figure out how to do proper benchmarking, or
design proper abstractions, etc., as skills that will magically appear
full-formed into the new kernel programmer's mind without any help or
work on our part.

> So don't be a jerk, and spout off as to how we only need "skilled"
> people contributing.  Of course we need that, but the way we get those
> people is to help them become skilled, not requiring them to show up
> with those skills automatically.

I think where we disagree is in how to make them become skilled.  I
don't think just focusing on contents of SubmittingPatches is
sufficient, and there seems to be a "Step 2: And then a miracle
occurs" between the SubmittingPatches step and the "skilled
contributor" end goal.

Cheers,

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