linux-kernel - Re: [PATCH v2 0/2] remove workarounds for gcc bug wrt unnamed fields in initializers

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: <20200624170811.GA396203@localhost.localdomain>
Date:   Wed, 24 Jun 2020 17:08:12 +0000
From:   Niklas Cassel <Niklas.Cassel@....com>
To:     Christoph Hellwig <hch@....de>
CC:     Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...com>,
        Sagi Grimberg <sagi@...mberg.me>,
        Chaitanya Kulkarni <Chaitanya.Kulkarni@....com>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/2] remove workarounds for gcc bug wrt unnamed fields
 in initializers

On Wed, Jun 24, 2020 at 07:02:11PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 24, 2020 at 04:57:48PM +0000, Niklas Cassel wrote:
> > On Wed, Jun 24, 2020 at 06:44:41PM +0200, Christoph Hellwig wrote:
> > > This looks good to me, but I'd rather wait a few releases to
> > > avoid too mush backporting pain.
> > 
> > Chaitanya made me realize that about half of the nvme functions
> > are using "struct nvme_command c" on the stack, and then memsets
> > it, and half of the nvme functions are using an initializer.
> > 
> > IMHO, using an initializer is more clear.
> > 
> > memset has to be used if the function needs to reset an
> > existing struct, but in none of the functions that I've seen,
> > are we given an existing nvme_command that we need to reset.
> > All the functions that I've seen declares a new nvme_command
> > on the stack (so an initializer makes more sense).
> > 
> > What do you think about me unifying this later on?
> 
> I like the initializers a lot.  But as I said I'd rather wait a
> bit for now.

Just to be clear:
Even with these patches, about half of the nvme functions are using
memset rather than initializers.

But sure, I'll wait a couple of releases, and then rebase this,
and additionally convert the "struct nvme_command c" memset users
to use initializers.


Kind regards,
Niklas