[PATCH v6 11/11] arm64: annotate user pointers casts detected by sparse

On 03/09/18 13:34, Andrey Konovalov wrote:

On Fri, Aug 31, 2018 at 3:42 PM, Al Viro [off-list ref] wrote:

quoted

On Fri, Aug 31, 2018 at 10:11:24AM +0200, Luc Van Oostenryck wrote:

quoted

On Thu, Aug 30, 2018 at 01:41:16PM +0200, Andrey Konovalov wrote:

quoted

This patch adds __force annotations for __user pointers casts detected by
sparse with the -Wcast-from-as flag enabled (added in [1]).

[1] https://github.com/lucvoo/sparse-dev/commit/5f960cb10f56ec2017c128ef9d16060e0145f292

Hi,

It would be nice to have some explanation for why these added __force
are useful.

I'll add this in the next version, thanks!

quoted

        It would be even more useful if that series would either deal with
the noise for real ("that's what we intend here, that's what we intend there,
here's a primitive for such-and-such kind of cases, here we actually
ought to pass __user pointer instead of unsigned long", etc.) or left it
unmasked.

        As it is, __force says only one thing: "I know the code is doing
the right thing here".  That belongs in primitives, and I do *not* mean the
#define cast_to_ulong(x) ((__force unsigned long)(x))
kind.

        Folks, if you don't want to deal with that - leave the warnings be.
They do carry more information than "someone has slapped __force in that place".

Al, very annoyed by that kind of information-hiding crap...

This patch only adds __force to hide the reports I've looked at and
decided that the code does the right thing. The cases where this is
not the case are handled by the previous patches in the patchset. I'll
this to the patch description as well. Is that OK?

I think as well that we should make explicit the information that
__force is hiding.
A possible solution could be defining some new address spaces and use
them where it is relevant in the kernel. Something like:

# define __compat_ptr __attribute__((noderef, address_space(5)))
# define __tagged_ptr __attribute__((noderef, address_space(6)))

In this way sparse can still identify the casting and trigger a warning.

We could at that point modify sparse to ignore these conversions when a
specific flag is passed (i.e. -Wignore-compat-ptr, -Wignore-tagged-ptr)
to exclude from the generated warnings the ones we have already dealt
with.

What do you think about this approach?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Regards,
Vincenzo