linux-kernel - Re: [PATCH 3/4] char/tpm: Improve a size determination in nine functions

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: <20171020090139.l4igyucqxqmgrq7l@linux.intel.com>
Date:   Fri, 20 Oct 2017 12:01:39 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Alexander.Steffen@...ineon.com
Cc:     andriy.shevchenko@...ux.intel.com, elfring@...rs.sourceforge.net,
        linux-integrity@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        benh@...nel.crashing.org, clabbe.montjoie@...il.com,
        jgunthorpe@...idianresearch.com, jsnitsel@...hat.com,
        kgold@...ux.vnet.ibm.com, mpe@...erman.id.au,
        nayna@...ux.vnet.ibm.com, paulus@...ba.org, PeterHuewe@....de,
        stefanb@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
        kernel-janitors@...r.kernel.org
Subject: Re: [PATCH 3/4] char/tpm: Improve a size determination in nine
 functions

On Thu, Oct 19, 2017 at 04:58:23PM +0000, Alexander.Steffen@...ineon.com wrote:
> > On Tue, Oct 17, 2017 at 11:50:05AM +0000, Alexander.Steffen@...ineon.com
> > wrote:
> > > > > Replace the specification of data structures by pointer dereferences
> > > > > as the parameter for the operator "sizeof" to make the corresponding
> > > > > size
> > > > > determination a bit safer according to the Linux coding style
> > > > > convention.
> > > >
> > > >
> > > > This patch does one style in favor of the other.
> > >
> > > I actually prefer that style, so I'd welcome this change :)
> > >
> > > > At the end it's Jarkko's call, though I would NAK this as I think some
> > > > one already told this to you for some other similar patch(es).
> > > >
> > > >
> > > > I even would suggest to stop doing this noisy stuff, which keeps people
> > > > busy for nothing.
> > >
> > > Cleaning up old code is also worth something, even if does not change
> > > one bit in the assembly output in the end...
> > >
> > > Alexander
> > 
> > Quite insignificant clean up it is that does more harm that gives any
> > benefit as any new change adds debt to backporting.
> > 
> > Anyway, this has been a useful patch set for me in the sense that I have
> > clearer picture now on discarding/accepting commits.
> 
> Indeed. I have now a better understanding for why some code looks as
> ugly as it does.
> 
> > One line minor
> > clean up will be from now on automatic NAK unless it causes a compiler
> > warning or some other visible side-effect.
> 
> Not a nice policy, but at least a policy. I have deleted the tasks
> that I had still planned for other cleanup activities.
> 
> Alexander

1/4 and 2/4 are sensible clean ups as long as the commit message is
refined.

Moving more functions to use tpm_buf instead of nasty tpm_cmd_t are
also welcome changes.

Documenting functions (exported mainly) is also welcome. Or refining
documentation.

It's really case by case. The important thing in small clean ups is
a clearly written commit message that explains rationale.

/Jarkko