From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Dipendra Khadka <kdipendra88@gmail.com>,
tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
mjguzik@gmail.com, ira.weiny@intel.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: Fixes warning: cast removes address space '__user' of expression in uaccess_64.h
Date: Tue, 23 Jan 2024 22:08:24 -0800 [thread overview]
Message-ID: <ZbCpWDQuymTbdgz5@google.com> (raw)
In-Reply-To: <3ff3e05a-8377-4b38-84ae-be24b6cae6a4@intel.com>
On Fri, Nov 17, 2023 at 07:19:12AM -0800, Dave Hansen wrote:
> On 11/16/23 09:38, Dipendra Khadka wrote:
> > Sparse has identified a warning as follows:
> >
> > ./arch/x86/include/asm/uaccess_64.h:88:24: warning: cast removes address space '__user' of expression.
> >
> > Since the valid_user_address(x) macro implicitly casts the argument
> > to long and compares the converted value of x to zero, casting ptr
> > to unsigned long has no functional impact and does not trigger a
> > Sparse warning either.
>
> Why does sparse complain about a cast to 'long' but not 'unsigned long'?
> Both remove the '__user' address space from the expression. Were there
> just so many __user pointers being cast to 'unsigned long' that there's
> an exception in sparse for 'void __user *' => 'unsigned long'?
Yes, unsigned long is special:
commit 7816e4c4a2dba6fef24c9a52c6b17a8cde0c8138
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Mon May 31 13:18:57 2004 -0700
Allow casting of user pointers to "unsigned long".
It's reasonably common to do special pointer arithmetic
in unsigned long, and making people force the cast just
adds noise.
I wonder if we should have:
#define valid_user_address(x) ((__force long)(x) >= 0)
or
#define valid_user_address(x) ((long)(unsigned long)(x) >= 0)
Thanks.
--
Dmitry
prev parent reply other threads:[~2024-01-24 6:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-16 17:38 [PATCH] x86: Fixes warning: cast removes address space '__user' of expression in uaccess_64.h Dipendra Khadka
2023-11-17 15:19 ` Dave Hansen
[not found] ` <CAEKBCKNsw60QM=Ay6CH2Kuh-L8YdjVB5yScjG9pTZUXcBrsf5w@mail.gmail.com>
2023-11-17 19:31 ` Dipendra Khadka
2023-11-17 19:47 ` Dipendra Khadka
2023-12-23 9:07 ` Dipendra Khadka
2024-01-24 6:08 ` Dmitry Torokhov [this message]
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=ZbCpWDQuymTbdgz5@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=ira.weiny@intel.com \
--cc=kdipendra88@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mjguzik@gmail.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.