linux-kernel - Re: [tip:timers/vdso 12/14] net/rds/ib_cm.c:96:35: sparse: sparse: incorrect type in argument 1 (different modifiers)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <871pjrj36d.ffs@tglx>
Date: Wed, 14 Jan 2026 22:27:06 +0100
From: Thomas Gleixner <tglx@...nel.org>
To: Ian Rogers <irogers@...gle.com>
Cc: kernel test robot <lkp@...el.com>, oe-kbuild-all@...ts.linux.dev,
 linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [tip:timers/vdso 12/14] net/rds/ib_cm.c:96:35: sparse: sparse:
 incorrect type in argument 1 (different modifiers)

On Wed, Jan 14 2026 at 13:03, Ian Rogers wrote:
> On Wed, Jan 14, 2026 at 12:04 PM Thomas Gleixner <tglx@...nel.org> wrote:
>> > My preference would be 1 as I have a suspicion I played 2 and thought
>> > the non-const cast was best (hence it being in the patch) given other
>> > issues.
>>
>> Preferences based on suspicions are not really usefull. Please go and
>> figure out what's going on and either fix it in the kernel code or tell
>> the sparse folks what they are missing.
>>
>> Leaving it unresolved and handwaved away is not an option.
>
> I'd like to call this option, play a bunch of wac-a-mole but then

I'm not familiar enough with internet slang, but to my limited knowledge
it's spelled 'Whack-a-mole'. That aside:

     "Whack-a-mole" without a real conclusive explanation is really a
      lame excuse, actually it's beyond lame.

> still don't really progress. I had tried out I believe all the options
> 6 months ago where the builds were clean. There's always 1 more tool
> that's going to raise its head and complain about types, my motivation
> remains clang and gcc for user space copies of this code so we don't
> need to propagate -fno-strict-aliasing into places like perf.

So because your motivation ends there and other tools which raise their
ugly heads are not relevant to you ...

> Tbh, I'm not going to be able to look at this for a while so I'd
> suggest just dropping the patches.

... everything stays with the status quo, i.e. unresolved.

That makes a lot of sense - NOT!

Thanks for wasting my time to deal with your patches and welcome to my
extremly short ignore list!

Your's grumpy

       Thomas