From: Peter Zijlstra <peterz@infradead.org>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
Eric Biggers <ebiggers@kernel.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Will Deacon <will@kernel.org>,
Elena Reshetova <elena.reshetova@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Anna-Maria Gleixner <anna-maria@linutronix.de>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-sparse@vger.kernel.org
Subject: Re: [PATCH] locking/refcount: add sparse annotations to dec-and-lock functions
Date: Mon, 6 Jan 2020 16:41:19 +0100 [thread overview]
Message-ID: <20200106154119.GV2810@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20191230233814.2fgmsgtnhruhklnu@ltop.local>
On Tue, Dec 31, 2019 at 12:38:14AM +0100, Luc Van Oostenryck wrote:
> On Mon, Dec 30, 2019 at 11:32:31AM -0800, Kees Cook wrote:
> > On Mon, Dec 30, 2019 at 01:15:47PM -0600, Eric Biggers wrote:
> > >
> > > The annotation needs to go in the .h file, not the .c file, because sparse only
> > > analyzes individual translation units.
> > >
> > > It needs to be a wrapper macro because it needs to tie the acquisition of the
> > > lock to the return value being true. I.e. there's no annotation you can apply
> > > directly to the function prototype that means "if this function returns true, it
> > > acquires the lock that was passed in parameter N".
> >
> > Gotcha. Well, I guess I leave it to Will and Peter to hash out...
> >
> > Is there a meaningful proposal anywhere for sparse to DTRT here? If
> > not, it seems best to use what you've proposed until sparse reaches the
> > point of being able to do this on its own.
>
> What "Right Thing" are you thinking about?
> One of the simplest situation with these conditional locks is:
>
> if (test)
> lock();
>
> do_stuff();
>
> if (test)
> unlock();
>
> No program can check that the second test gives the same result than
> the first one, it's undecidable. I mean, it's undecidable even on
> if single threaded and without interrupts. The best you can do is
> to simulate the whole thing (and be sure your simulation will halt).
Not quite what we're talking about. Instead consider this:
The normal flow would be something like:
extern void spin_lock(spinlock_t *lock) __acquires(lock);
extern void spin_unlock(spinlock_t *lock) __releases(lock);
extern bool _spin_trylock(spinlock_t *lock) __acquires(lock);
#define __cond_lock(x, c) ((c) ? ({ __acquire(x); 1; }) : 0)
#define spin_trylock(lock) __cond_lock(lock, _spin_lock)
if (spin_trylock(lock)) {
/* do crap */
spin_unlock();
}
So the proposal here:
https://markmail.org/message/4obybcgqscznnx63
would have us write:
extern bool spin_trylock(spinlock_t *lock) __attribute__((context(lock, 0, spin_trylock(lock));
Basically have sparse do a transform on its own expression tree and
inject the very same crud we now do manually. This avoids cluttering the
kernel tree with this nonsense.
next prev parent reply other threads:[~2020-01-06 15:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191226152922.2034-1-ebiggers@kernel.org>
[not found] ` <20191228114918.GU2827@hirez.programming.kicks-ass.net>
[not found] ` <201912301042.FB806E1133@keescook>
[not found] ` <20191230191547.GA1501@zzz.localdomain>
[not found] ` <201912301131.2C7C51E8C6@keescook>
2019-12-30 23:38 ` [PATCH] locking/refcount: add sparse annotations to dec-and-lock functions Luc Van Oostenryck
2020-01-03 1:35 ` Linus Torvalds
2020-01-03 2:18 ` Luc Van Oostenryck
2020-01-03 12:55 ` Dan Carpenter
2020-01-06 15:41 ` Peter Zijlstra [this message]
2020-01-06 17:54 ` Luc Van Oostenryck
2020-01-07 9:29 ` Peter Zijlstra
2020-01-06 15:26 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200106154119.GV2810@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=anna-maria@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=ebiggers@kernel.org \
--cc=elena.reshetova@intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).