From: Dan Carpenter <error27@gmail.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org,
Bjorn Helgaas <helgaas@kernel.org>,
kernel test robot <lkp@intel.com>
Subject: Re: drivers/pci/pcie/../pci.h:325:17: sparse: sparse: cast from restricted pci_channel_state_t
Date: Wed, 1 Mar 2023 07:51:25 +0300 [thread overview]
Message-ID: <Y/7ZzYyisv1ylrho@kadam> (raw)
In-Reply-To: <Y/7YN7U9Q2iqNDFo@kadam>
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; \
})
next prev parent reply other threads:[~2023-03-01 4:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-28 20:39 kernel test robot
2023-02-28 21:33 ` Lukas Wunner
2023-03-01 4:44 ` Dan Carpenter
2023-03-01 4:51 ` Dan Carpenter [this message]
2023-12-03 16:59 ` Lukas Wunner
2023-12-04 14:09 ` Luc Van Oostenryck
2023-11-30 19:39 kernel test robot
2024-01-04 9:46 kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y/7ZzYyisv1ylrho@kadam \
--to=error27@gmail.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lukas@wunner.de \
--cc=oe-kbuild-all@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®