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: <20180106012634.GB5260@fury>
Date:   Fri, 5 Jan 2018 17:26:34 -0800
From:   Darren Hart <dvhart@...radead.org>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:     ibm-acpi-devel@...ts.sourceforge.net,
        platform-driver-x86@...r.kernel.org,
        Henrique de Moraes Holschuh <hmh@....eng.br>,
        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 Wed, Jan 03, 2018 at 09:41:04AM +0100, SF Markus Elfring wrote:
> > I understand it can be frustrating to encounter different policies
> > across kernel maintainers.
> 
> The change acceptance is varying for special transformation patterns.
> 
> 
> > You'll even run in to this with maintainers of the same subsystem
> > from time to time.
> 
> Interesting, isn't it?
> 
> 
> > I'm supportive of cleaning up old code in general,
> 
> Nice.
> 
> 
> > and we routinely apply such patches as these developed with cocci.
> 
> Good to know …
> 
> 
> > 1. This is init code )so any space savings is short lived)
> 
> Would you dare to achieve another small improvement there?
> 
> 
> > So it isn't that we place a low value on coding style guidelines,
> > but rather we place higher value on not perturbing code
> 
> I can follow this view in principle.
> 
> 
> > we can't fully test without a demonstrable functional reasons to do so.
> 
> How do you think about to get a bit nicer run time characteristics?

If this was code that affected all systems, the impact would be greater
- and it would be much easier to test. As it applies only to Thinkpad
systems, far fewer total systems are affected, and it is much harder to
test/verify. For something like this, we (Andy and I) will typically
defer to the driver-specific maintainer. Henrique has declined the
patch, and I think the reasoning is defensible.

If you feel that is the wrong call, you will need to present convincing
evidence to Henrique that this is worth the risk. From what I've seen of
the patch series thus far... I don't think the advantages can be argued
to outweigh the risks - or that it would be worth the effort.

Henrique, I'm going to stop there and let you chime in if you feel
differently about any of the above.

-- 
Darren Hart
VMware Open Source Technology Center