[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191115003821.raskzlj7hscz7vax@ltop.local>
Date: Fri, 15 Nov 2019 01:38:21 +0100
From: Luc Van Oostenryck <luc.vanoostenryck@...il.com>
To: Alex Kogan <alex.kogan@...cle.com>
Cc: kbuild test robot <lkp@...el.com>, linux-sparse@...r.kernel.org,
kbuild-all@...ts.01.org, linux@...linux.org.uk,
Peter Zijlstra <peterz@...radead.org>, mingo@...hat.com,
will.deacon@....com, arnd@...db.de, longman@...hat.com,
linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, tglx@...utronix.de, bp@...en8.de,
hpa@...or.com, x86@...nel.org, guohanjun@...wei.com,
jglauber@...vell.com, steven.sistare@...cle.com,
daniel.m.jordan@...cle.com, dave.dice@...cle.com,
rahul.x.yadav@...cle.com
Subject: Re: [PATCH v6 3/5] locking/qspinlock: Introduce CNA into the slow
path of qspinlock
On Thu, Nov 14, 2019 at 03:57:34PM -0500, Alex Kogan wrote:
> + linux-sparse mailing list
>
> It seems like a bug in the way sparse handles “pure” functions that return
> a pointer.
Yes, it's a bug in sparse.
> The warnings can be eliminated by adding an explicit cast, e.g.:
>
> node = (struct mcs_spinlock *)grab_mcs_node(node, idx);
>
> but this seems wrong (unnecessary) to me.
Indeed, it would be wrong.
Thanks for analyzing and reporting this,
-- Luc
Powered by blists - more mailing lists