linux-kernel - Re: platform/x86/thinkpad_acpi: Adjustments for four function implementations

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: <20180103001034.GC24794@fury>
Date:   Tue, 2 Jan 2018 16:10:34 -0800
From:   Darren Hart <dvhart@...radead.org>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:     Henrique de Moraes Holschuh <hmh@....eng.br>,
        ibm-acpi-devel@...ts.sourceforge.net,
        platform-driver-x86@...r.kernel.org,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Andy Shevchenko <andy@...radead.org>,
        Henrique de Moraes Holschuh <ibm-acpi@....eng.br>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: platform/x86/thinkpad_acpi: Adjustments for four function
 implementations

On Sat, Dec 23, 2017 at 08:12:21AM +0100, SF Markus Elfring wrote:
> >> Do you find the Linux allocation failure report insufficient in this case?
> > 
> > Leave those pr_ messages alone, please,
> 
> Have you got special software development concerns?
> 
> 
> > unless they are really causing some sort of issue (which?).
> 
> Can the code be redundant here?
> 
> 
> > Doing it just for "compliance" with a doc isn't nearly good enough reason.
> 
> Do you give only a low value to coding style guidelines in this use case?

Hi Markus,

Thanks for submitting the patch. I understand it can be frustrating to
encounter different policies across kernel maintainers. You'll even run
in to this with maintainers of the same subsystem from time to time.
While we try to be as consistent as possible, and to document policy as
we resolve vague areas, this is unfortunately still part of kernel
development.

I'm supportive of cleaning up old code in general, and we routinely
apply such patches as these developed with cocci. We have also had them
fail in unexpected ways.

Andy and Henrique raised a few reasons why these patches should not be
accepted:

1. This is init code )so any space savings is short lived)
2. There is no functional fix, and the change is to code which supports
   a lot of unique platforms, most of which we have no way to test. We are
   particularly cautious with drivers such as the thinkpad driver for this
   reason.

So it isn't that we place a low value on coding style guidelines, but
rather we place higher value on not perturbing code we can't fully test
without a demonstrable functional reasons to do so.

Thanks,

-- 
Darren Hart
VMware Open Source Technology Center