| 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
| ||
|
Message-ID:
<BY3PR18MB470761F0063CA2AA4481DF7CA0D12@BY3PR18MB4707.namprd18.prod.outlook.com>
Date: Tue, 11 Mar 2025 08:57:22 +0000
From: Sai Krishna Gajula <saikrishnag@...vell.com>
To: Simon Horman <horms@...nel.org>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com"
<edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"netdev@...r.kernel.org"
<netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
Sunil Kovvuri Goutham <sgoutham@...vell.com>,
Geethasowjanya Akula <gakula@...vell.com>,
Linu Cherian
<lcherian@...vell.com>, Jerin Jacob <jerinj@...vell.com>,
Hariprasad Kelam
<hkelam@...vell.com>,
Subbaraya Sundeep Bhatta <sbhatta@...vell.com>,
"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
Bharat Bhushan
<bbhushan2@...vell.com>,
"nathan@...nel.org" <nathan@...nel.org>,
"ndesaulniers@...gle.com" <ndesaulniers@...gle.com>,
"morbo@...gle.com"
<morbo@...gle.com>,
"justinstitt@...gle.com" <justinstitt@...gle.com>,
"llvm@...ts.linux.dev" <llvm@...ts.linux.dev>,
kernel test robot
<lkp@...el.com>
Subject: Re: [net-next PATCH v2] octeontx2-af: fix build warnings flagged by
clang, sparse ,kernel test robot
> -----Original Message-----
> From: Simon Horman <horms@...nel.org>
> Sent: Thursday, March 6, 2025 10:13 PM
> To: Sai Krishna Gajula <saikrishnag@...vell.com>
> Cc: davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> pabeni@...hat.com; netdev@...r.kernel.org; linux-kernel@...r.kernel.org;
> Sunil Kovvuri Goutham <sgoutham@...vell.com>; Geethasowjanya Akula
> <gakula@...vell.com>; Linu Cherian <lcherian@...vell.com>; Jerin Jacob
> <jerinj@...vell.com>; Hariprasad Kelam <hkelam@...vell.com>; Subbaraya
> Sundeep Bhatta <sbhatta@...vell.com>; andrew+netdev@...n.ch; Bharat
> Bhushan <bbhushan2@...vell.com>; nathan@...nel.org;
> ndesaulniers@...gle.com; morbo@...gle.com; justinstitt@...gle.com;
> llvm@...ts.linux.dev; kernel test robot <lkp@...el.com>
> Subject: Re: [net-next PATCH v2] octeontx2-af: fix build warnings
> flagged by clang, sparse ,kernel test robot
>
> On Wed, Mar 05, 2025 at 03: 16: 23PM +0530, Sai Krishna wrote: > This
> cleanup patch avoids build warnings flagged by clang, > sparse, kernel test
> robot. > > Warning reported by clang: >
> drivers/net/ethernet/marvell/octeontx2/af/rvu. c: 2993: 47:
> On Wed, Mar 05, 2025 at 03:16:23PM +0530, Sai Krishna wrote:
> > This cleanup patch avoids build warnings flagged by clang, sparse,
> > kernel test robot.
> >
> > Warning reported by clang:
> > drivers/net/ethernet/marvell/octeontx2/af/rvu.c:2993:47:
> > warning: arithmetic between different enumeration types ('enum
> > rvu_af_int_vec_e' and 'enum rvu_pf_int_vec_e')
> > [-Wenum-enum-conversion]
> > 2993 | return (pfvf->msix.max >= RVU_AF_INT_VEC_CNT +
> > RVU_PF_INT_VEC_CNT) &&
>
> Hi Sai,
>
> I think it would be good to address each set of errors in separate patches.
> And in each case include a report of the errors the tools reported.
>
> And I think that the subject(s) could be tightened up a bit.
> E.g.:
>
> Subject: octeontx2-af: correct __iomem annotations
>
> Sparse flags a number of inconsistent usage of __iomem annotations:
>
> .../otx2_pf.c:611:24: sparse: expected void [noderef] __iomem
> *hwbase
> .../otx2_pf.c:611:24: sparse: got void *
> .../otx2_pf.c:620:56: sparse: sparse: cast removes address space
> '__iomem' of expression
> .../otx2_pf.c:671:35: sparse: sparse: incorrect type in argument 1
> (different address spaces) @@ expected void volatile [noderef] __iomem
> *addr @@ got void *hwbase @@
> .../otx2_pf.c:671:35: sparse: expected void volatile [noderef] __iomem
> *addr
> .../otx2_pf.c:671:35: sparse: got void *hwbase
> .../otx2_pf.c:1344:21: sparse: sparse: incorrect type in assignment
> (different address spaces) @@ expected unsigned long long [usertype] *ptr
> @@ got void [noderef] __iomem * @@
> .../otx2_pf.c:1344:21: sparse: expected unsigned long long [usertype]
> *ptr
> .../otx2_pf.c:1344:21: sparse: got void [noderef] __iomem *
> .../otx2_pf.c:1383:21: sparse: sparse: incorrect type in assignment
> (different address spaces) @@ expected unsigned long long [usertype] *ptr
> @@ got void [noderef] __iomem * @@
> .../otx2_pf.c:1383:21: sparse: expected unsigned long long [usertype]
> *ptr
> .../otx2_pf.c:1383:21: sparse: got void [noderef] __iomem *
> .../otx2_pf.c: note: in included file (through .../mbox.h,
> .../otx2_common.h):
>
> Address this by, ...
>
> Reported-by: ...
> ...
>
Ack, will submit separate patches(V3) inline with the review comments
> >
> > Reported-by: kernel test robot <lkp@...el.com>
> > Closes:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_o
> > e-2Dkbuild-2Dall_202410221614.07o9QVjo-2Dlkp-
> 40intel.com_&d=DwIBAg&c=n
> > KjWec2b6R0mOyPaz7xtfQ&r=c3MsgrR-U-HFhmFd6R4MWRZG-
> 8QeikJn5PkjqMTpBSg&m=
> >
> ZRaxGaucMplgEgMUkRbXRrEQcd1pdXjKonN2_LRPrXqdhovwf1Byu3KcxVLZr2
> zr&s=xnV
> > HrpqVN46FMyWamv4vgtFbV05b4GjT6yDQcACN2gA&e=
> > Signed-off-by: Sai Krishna <saikrishnag@...vell.com>
> > ---
> > drivers/net/ethernet/marvell/octeontx2/af/common.h | 2 +-
> > drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 14 ++++++++------
> > .../ethernet/marvell/octeontx2/nic/otx2_common.c | 10 +++++-----
> > .../net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 9 ++++-----
> > 4 files changed, 18 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/common.h
> > b/drivers/net/ethernet/marvell/octeontx2/af/common.h
> > index 406c59100a35..8a08bebf08c2 100644
> > --- a/drivers/net/ethernet/marvell/octeontx2/af/common.h
> > +++ b/drivers/net/ethernet/marvell/octeontx2/af/common.h
> > @@ -39,7 +39,7 @@ struct qmem {
> > void *base;
> > dma_addr_t iova;
> > int alloc_sz;
> > - u16 entry_sz;
> > + u32 entry_sz;
> > u8 align;
> > u32 qsize;
> > };
>
> Further to my point above, I am unsure what problem this is addressing.
Ack, will submit V3 separate patch mentioning the reason for this fix.
>
> > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> > b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> > index cd0d7b7774f1..c850ea5d1960 100644
> > --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> > +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> > @@ -591,7 +591,7 @@ static void rvu_check_min_msix_vec(struct rvu
> > *rvu, int nvecs, int pf, int vf)
> >
> > check_pf:
> > if (pf == 0)
> > - min_vecs = RVU_AF_INT_VEC_CNT + RVU_PF_INT_VEC_CNT;
> > + min_vecs = (int)RVU_AF_INT_VEC_CNT +
> (int)RVU_PF_INT_VEC_CNT;
> > else
> > min_vecs = RVU_PF_INT_VEC_CNT;
> >
>
> I think that in the light of Linus's feedback and the subsequent patch that
> demoted -Wenum-enum-conversion from W=1 to W=1 this is not necessary.
Ack, will ignore these changes which are flagged by -Wenum-enum-conversion
>
> [1] https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lore.kernel.org_all_CAHk-2D-
> 3DwjMux0w49bTdSbC3DOoc9FRctDrRvaqFUS4KFTmkbtKWg-
> 40mail.gmail.com_&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=c3MsgrR-
> U-HFhmFd6R4MWRZG-
> 8QeikJn5PkjqMTpBSg&m=ZRaxGaucMplgEgMUkRbXRrEQcd1pdXjKonN2_LRP
> rXqdhovwf1Byu3KcxVLZr2zr&s=SbA5_pKyReJi7lYN-OtFzRqw0T-
> nxqE1XFOaSZcoNm8&e=
> [2] 8f6629c004b1 ("kbuild: Move -Wenum-enum-conversion to W=2")
>
> > @@ -819,13 +819,14 @@ static int rvu_fwdata_init(struct rvu *rvu)
> > goto fail;
> >
> > BUILD_BUG_ON(offsetof(struct rvu_fwdata, cgx_fw_data) >
> FWDATA_CGX_LMAC_OFFSET);
> > - rvu->fwdata = ioremap_wc(fwdbase, sizeof(struct rvu_fwdata));
> > + rvu->fwdata = (__force struct rvu_fwdata *)
> > + ioremap_wc(fwdbase, sizeof(struct rvu_fwdata));
>
> I am concerned that this and similar changes in this patch are masking
> problems. In my view __iomem annotations are there for a reason, to help use
> the correct access mechanism for iomem. So my question is why is that not
> the case for fwdata?
>
> Similarly for other cases in this patch where __iomem is cast or cast-away.
Ack, will fix and submit V3 patch inline with review comments.
>
> ...
Powered by blists - more mailing lists