Messages in this thread Patch in this message | | | Date | Wed, 1 Mar 2023 07:51:25 +0300 | From | Dan Carpenter <> | Subject | Re: drivers/pci/pcie/../pci.h:325:17: sparse: sparse: cast from restricted pci_channel_state_t |
| |
On Wed, Mar 01, 2023 at 07:44:39AM +0300, Dan Carpenter wrote: > > It seems they are only reported for architectures whose arch_xchg() > > and arch_cmpxchg() macros cast the argument to an unsigned long. > > Archictures such as x86 don't do that, but a number of others do. > > The 0-day report, reproduced below in full, is for loongarch. > > > > I'm wondering why the cast is necessary at all. Digging in the > > git history, I noticed that it has existed at least on arm since > > forever. I suspect that its use on newer arches such as loongarch > > may be due to cargo-culting. > > > > Speaking as an absolutely newbie and ignoramous, I can't see any point > to the cast in arch_xchg(). But I am also surprised that silences the > warning. I would have thought that removing the cast would change the > warning from "warning: cast from restricted my_type_t" to > "warning: incorrect type in argument 1 (different base types)".
Your other option would be to add a __force to the cast. I don't know if this is a good option. I guess first figure out if the __bit_wise is really required.
regards, dan carpenter
diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h index 497acf134d99..387c6af01941 100644 --- a/arch/arm64/include/asm/cmpxchg.h +++ b/arch/arm64/include/asm/cmpxchg.h @@ -93,7 +93,7 @@ __XCHG_GEN(_mb) ({ \ __typeof__(*(ptr)) __ret; \ __ret = (__typeof__(*(ptr))) \ - __xchg##sfx((unsigned long)(x), (ptr), sizeof(*(ptr))); \ + __xchg##sfx((__force unsigned long)(x), (ptr), sizeof(*(ptr))); \ __ret; \ })
| |