From: "Michael S. Tsirkin" <mst@redhat.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
linux-arch@vger.kernel.org
Subject: Re: [PATCH 00/18] uaccess: fix sparse warning on get_user for bitwise types
Date: Mon, 15 Dec 2014 12:22:27 +0200 [thread overview]
Message-ID: <20141215102227.GA26178@redhat.com> (raw)
In-Reply-To: <1418604052.19970.6.camel@ellerman.id.au>
On Mon, Dec 15, 2014 at 11:40:52AM +1100, Michael Ellerman wrote:
> On Sun, 2014-12-14 at 18:51 +0200, Michael S. Tsirkin wrote:
> > At the moment, if p and x are both tagged as bitwise types,
> > get_user(x, p) produces a sparse warning on many architectures.
> > This is because *p on these architectures is loaded into long
> > (typically using asm), then cast back to typeof(*p).
> >
> > When typeof(*p) is a bitwise type (which is uncommon), such a cast needs
> > __force, otherwise sparse produces a warning.
>
> What does __force actually mean? Force the cast even though it's a bitfield? Or
> does it mean more than that?
It's not a bitfield = it's a bitwise integer.
Once you tag a typedef as bitwise, casts to and from
an untypedefed integer cause sparse warnings.
> ie. are we loosing the ability to detect any actual errors by adding force?
>
> cheers
I think we aren't:
get_user(x, p) should be equivalent to x = *p except it
validates the pointer is to userspace memory,
and can handle pagefaults.
Sparse warnings are triggered because these macros use
an untyped integer internally.
Note that we are casting to typeof(*p) not typeof(x).
Even with the cast, if x and *p are of different types we should get the
warning, so I think we are not loosing the ability to detect any actual
errors.
--
MST
next prev parent reply other threads:[~2014-12-15 10:22 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-14 16:51 [PATCH 00/18] uaccess: fix sparse warning on get_user for bitwise types Michael S. Tsirkin
2014-12-14 16:51 ` [PATCH 01/18] x86/uaccess: fix sparse errors Michael S. Tsirkin
2014-12-14 16:51 ` Michael S. Tsirkin
2014-12-16 16:47 ` Michael S. Tsirkin
2014-12-14 16:52 ` [PATCH 02/18] alpha/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` [PATCH 03/18] arm64/uaccess: " Michael S. Tsirkin
2014-12-15 11:17 ` Will Deacon
2014-12-15 11:23 ` Russell King - ARM Linux
2014-12-15 11:29 ` Michael S. Tsirkin
2014-12-15 12:54 ` Michael S. Tsirkin
2014-12-14 16:52 ` [PATCH 04/18] avr32/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` Michael S. Tsirkin
2014-12-14 20:35 ` Hans-Christian Egtvedt
2014-12-14 16:52 ` [PATCH 05/18] blackfin/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` Michael S. Tsirkin
2014-12-18 3:11 ` Steven Miao
2014-12-14 16:52 ` [PATCH 06/18] cris/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` Michael S. Tsirkin
2014-12-14 16:52 ` [PATCH 07/18] ia64/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` Michael S. Tsirkin
2014-12-14 16:52 ` [PATCH 08/18] m32r/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` [PATCH 09/18] metag/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` Michael S. Tsirkin
2014-12-14 16:52 ` [PATCH 10/18] microblaze/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` Michael S. Tsirkin
2014-12-14 16:52 ` [PATCH 11/18] openrisc/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` Michael S. Tsirkin
2014-12-14 16:52 ` [PATCH 12/18] parisc/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` [PATCH 13/18] powerpc/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` Michael S. Tsirkin
2014-12-15 0:05 ` Benjamin Herrenschmidt
2014-12-15 1:37 ` Benjamin Herrenschmidt
2014-12-16 16:47 ` Michael S. Tsirkin
2014-12-16 23:50 ` Michael Ellerman
2014-12-17 0:52 ` Benjamin Herrenschmidt
2014-12-17 10:53 ` Arnd Bergmann
2014-12-17 11:05 ` Benjamin Herrenschmidt
2014-12-14 16:52 ` [PATCH 14/18] sh/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` Michael S. Tsirkin
2014-12-14 16:52 ` [PATCH 15/18] sparc/uaccess: " Michael S. Tsirkin
2014-12-14 16:52 ` Michael S. Tsirkin
2014-12-14 16:53 ` [PATCH 16/18] " Michael S. Tsirkin
2014-12-14 16:53 ` Michael S. Tsirkin
2014-12-14 16:53 ` [PATCH 17/18] xtensa/uaccess: " Michael S. Tsirkin
2014-12-14 16:53 ` Michael S. Tsirkin
2014-12-14 16:53 ` [PATCH 18/18] m68k/uaccess: " Michael S. Tsirkin
2014-12-14 16:53 ` Michael S. Tsirkin
2014-12-15 0:40 ` [PATCH 00/18] uaccess: fix sparse warning on get_user for bitwise types Michael Ellerman
2014-12-15 10:22 ` Michael S. Tsirkin [this message]
2014-12-15 10:22 ` Michael S. Tsirkin
2014-12-16 23:49 ` Michael Ellerman
2014-12-15 10:03 ` LF.Tan
2014-12-15 10:17 ` Michael S. Tsirkin
2014-12-16 6:06 ` Ley Foon Tan
2014-12-16 6:57 ` Michael S. Tsirkin
2014-12-16 16:45 ` Michael S. Tsirkin
2014-12-18 6:54 ` Ley Foon Tan
2014-12-18 6:54 ` Ley Foon Tan
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=20141215102227.GA26178@redhat.com \
--to=mst@redhat.com \
--cc=arnd@arndb.de \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpe@ellerman.id.au \
/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;
as well as URLs for NNTP newsgroup(s).