linux-kernel - Re: [PATCH v2] PCI: qcom: Use __be16 for catching cpu_to

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] [day] [month] [year] [list]

Message-ID: <20211130154351.GA2738262@bhelgaas>
Date:   Tue, 30 Nov 2021 09:43:51 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Krzysztof Wilczyński <kw@...ux.com>
Cc:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        lorenzo.pieralisi@....com, bhelgaas@...gle.com,
        svarbanov@...sol.com, bjorn.andersson@...aro.org, robh@...nel.org,
        linux-pci@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v2] PCI: qcom: Use __be16 for catching cpu_to_be16()
 return instead of u16

On Tue, Nov 30, 2021 at 09:12:14AM +0100, Krzysztof Wilczyński wrote:
> Hello!
> 
> [...]
> > > > cpu_to_be16() returns __be16 value but the driver uses u16 and that's
> > > > incorrect. Fix it by using __be16 as the datatype of bdf_be variable.
> > > 
> > > It would be "data type" in the above.
> > > 
> > > Not really a requirement to do so, but you could include the actual
> > > warning, as sometimes this is useful for reference later, as per:
> > > 
> > >   drivers/pci/controller/dwc/pcie-qcom.c:1346:30: warning: incorrect type in initializer (different base types)
> > >   drivers/pci/controller/dwc/pcie-qcom.c:1346:30:    expected unsigned short [usertype] bdf_be
> > >   drivers/pci/controller/dwc/pcie-qcom.c:1346:30:    got restricted __be16 [usertype]
> > > 
> > 
> > I usually do but as per Bjorn's comment I thought it is not recommended for PCI
> > subsystem (or maybe I misread his comments). Will add.
> 
> Ah right.  I must have missed his comment too.  I usually include warnings
> myself, where applicable.  Let's wait for what Bjorn says, just in case, so
> that we avoid adding something he does not want to have included in the
> commit message.

I think it's nice to include the warning in the commit log (and even
the way to *generate* the warning if it's more complicated than
"make") because that helps others verify the commit.

I just don't want the warning to be the *reason* for the commit
because it's too easy to focus on quickly removing the warning without
fully understanding whether there is an underlying defect.

Bjorn