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: <CAP-5=fWgReuXY5im5-qCMBmryZHkRcZCLTkU6YzOSGJwufnYJg@mail.gmail.com>
Date: Wed, 14 Jan 2026 13:42:06 -0800
From: Ian Rogers <irogers@...gle.com>
To: Thomas Gleixner <tglx@...nel.org>
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 1:27 PM Thomas Gleixner <tglx@...nel.org> wrote:
>
> 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!

The patches have been through 5 versions with considerable hurdles
jumped, testing my ending, both kernel building and user space tool
building and running with sanitizers, etc. My work commitments mean I
can't just leap up and say I'm going to explore the ramifications of
moving the (void*) to (const void*) in all these combinations again,
but as a a const lover (even having published papers on it [1]) I
doubt the choice of using "void*" rather than "const void*" is likely
no accident. Even if I come up with a new series, waiting months for
any kind of review, merging, feedback, .. I'm just left in limbo and I
lose the context that I've built up and we end up here. In perf
changes we often end up with good patches vs perfect patches and I
don't believe with these patches we'll ever get perfect, hence saying
we should move forward even with the sparse regression that may only
be fixable with #ifdef DOING_A_SPARSE_BUILD... Given the bar seems to
be perfect, I'm recommending just dropping the patches.

Sorry to be on your ignore list,
Ian

[1] https://research.manchester.ac.uk/en/publications/constraint-based-optimization-of-stationary-fields/

> Your's grumpy
>
>        Thomas
>
>
>