On Fri, Aug 3, 2018 at 5:09 PM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
>> On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote:
>> > On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
>> >> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>> >>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote:
>> >>> So the checker reports ~100 different places where a __user pointer
>> >>> being casted. I've looked through them and found 3 places where we
>> >>> need to add untagging. Source code lines below come from 4.18-rc2+
>> >>> (6f0d349d).
>> >> [...]
>> >>> I'll add the 3 patches with fixes to v5 of this patchset.
>> >>
>> >> Thanks for investigating. You can fix those three places in your code
>> >
>> > OK, will do.
>> >
>> >> but I was rather looking for a way to check such casting in the future
>> >> for newly added code. While for the khwasan we can assume it's a debug
>> >> option, the tagged user pointers are ABI and we need to keep it stable.
>> >>
>> >> We could we actually add some macros for explicit conversion between
>> >> __user ptr and long and silence the warning there (I guess this would
>> >> work better for sparse). We can then detect new ptr to long casts as
>> >> they appear. I just hope that's not too intrusive.
>> >>
>> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
>> >
>> > Haven't look at that sparse patch yet myself, but sounds doable.
>> > Should these macros go into this patchset or should they go
>> > separately?
>>
>> Started looking at this. When I run sparse with default checks enabled
>> (make C=1) I get countless warnings. Does anybody actually use it?
>
> Try using a more up-to-date version of sparse. Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...
>
> greg k-h
>
Quoting Linus in [1]:
Honestly, I'd like to just encourage people to get the sparse update
from Luc Van Oostenryck instead.
For a while there it looked like Chris Li would just pull from Luc,
and we'd have timely releases, but that really doesn't seem to have
ended up happening after all. So right now it's probably just best to
get Luc's tree instead from
https://github.com/lucvoo/sparse-dev
which also ends up fixing a lot of other issues.
[1] https://lore.kernel.org/lkml/CA+55aFzYEnZR2GZLR-DwpONjMNYGYoDy+6AWLCVNayWiaZuqoA@xxxxxxxxxxxxxx/T/#u
