On Mon, Jul 27, 2020 at 05:59:17PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 12:31:49PM -0400, Alan Stern wrote:
> > On Mon, Jul 27, 2020 at 04:28:27PM +0100, Matthew Wilcox wrote:
> > > On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote:
> > > > Given a type "T", an object x
On Mon, Jul 27, 2020 at 12:31:49PM -0400, Alan Stern wrote:
> On Mon, Jul 27, 2020 at 04:28:27PM +0100, Matthew Wilcox wrote:
> > On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote:
> > > Given a type "T", an object x of type pointer-to-T, and a function
> > > "func" that takes various
On Mon, Jul 27, 2020 at 04:28:27PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote:
> > Given a type "T", an object x of type pointer-to-T, and a function
> > "func" that takes various arguments and returns a pointer-to-T, the
> > accepted API for calling
On Mon, Jul 27, 2020 at 04:28:27PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote:
> > Given a type "T", an object x of type pointer-to-T, and a function
> > "func" that takes various arguments and returns a pointer-to-T, the
> > accepted API for calling
On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote:
> Given a type "T", an object x of type pointer-to-T, and a function
> "func" that takes various arguments and returns a pointer-to-T, the
> accepted API for calling func once would be to create once_func() as
> follows:
>
> T
On Fri, Jul 17, 2020 at 10:28:18PM -0700, Eric Biggers wrote:
> I'm still not sure this is the best API.
I cast my vote for something along the following lines. It's simple,
easily understood and easily used. The approach has two variants: One
that returns an integer and one that returns a
On Fri, Jul 17, 2020 at 06:02:47PM -0700, Eric Biggers wrote:
> On Fri, Jul 17, 2020 at 01:51:38PM -0400, Alan Stern wrote:
> > On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> > > On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > ...
> > > > + /* on
On Mon, Jul 20, 2020 at 06:48:50PM +0200, pet...@infradead.org wrote:
> On Mon, Jul 20, 2020 at 09:04:34AM -0700, Paul E. McKenney wrote:
> > 2. If we were to say "unlock" instead of "release", consistency
> > would demand that we also say "lock" instead of "acquire".
> > But "lock" is
On Mon, Jul 20, 2020 at 09:04:34AM -0700, Paul E. McKenney wrote:
> 2.If we were to say "unlock" instead of "release", consistency
> would demand that we also say "lock" instead of "acquire".
> But "lock" is subtlely different than "acquire", and there is
> a history of
On Mon, Jul 20, 2020 at 10:52:11AM -0400, Alan Stern wrote:
> On Mon, Jul 20, 2020 at 11:33:20AM +1000, Dave Chinner wrote:
> > On Sat, Jul 18, 2020 at 10:08:11AM -0400, Alan Stern wrote:
> > > > This is one of the reasons that the LKMM documetnation is so damn
> > > > difficult to read and
On Mon, Jul 20, 2020 at 10:52:11AM -0400, Alan Stern wrote:
> On Mon, Jul 20, 2020 at 11:33:20AM +1000, Dave Chinner wrote:
> > On Sat, Jul 18, 2020 at 10:08:11AM -0400, Alan Stern wrote:
> > > > This is one of the reasons that the LKMM documetnation is so damn
> > > > difficult to read and
On Mon, Jul 20, 2020 at 04:39:11PM +0100, Matthew Wilcox wrote:
> Honestly, even the term "release semantics" trips me up _every_ time.
> It's a barrier to understanding because I have to translate it into "Oh,
> he means it's like an unlock". Why can't you just say "unlock semantics"?
It's not
On Mon, Jul 20, 2020 at 04:39:11PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 20, 2020 at 10:52:11AM -0400, Alan Stern wrote:
> > On Mon, Jul 20, 2020 at 11:33:20AM +1000, Dave Chinner wrote:
> > > On Sat, Jul 18, 2020 at 10:08:11AM -0400, Alan Stern wrote:
> > > > > This is one of the reasons
On Mon, Jul 20, 2020 at 11:33:20AM +1000, Dave Chinner wrote:
> On Sat, Jul 18, 2020 at 10:08:11AM -0400, Alan Stern wrote:
> > > This is one of the reasons that the LKMM documetnation is so damn
> > > difficult to read and understand: just understanding the vocabulary
> > > it uses requires a
On Mon, Jul 20, 2020 at 12:07:31PM +1000, Dave Chinner wrote:
> The whole serialisation/atomic/ordering APIs have fallen badly off
> the macro cliff, to the point where finding out something as simple
> as the order of parameters passed to cmpxchg and what semantics it
> provides requires
On Fri, Jul 17, 2020 at 10:28:18PM -0700, Eric Biggers wrote:
> What do people think about the following instead? (Not proofread / tested
> yet,
> so please comment on the high-level approach, not minor mistakes :-) )
No huge long macros, please.
We don't accept people writing long complex
On Sat, Jul 18, 2020 at 10:08:11AM -0400, Alan Stern wrote:
> > This is one of the reasons that the LKMM documetnation is so damn
> > difficult to read and understand: just understanding the vocabulary
> > it uses requires a huge learning curve, and it's not defined
> > anywhere. Understanding the
On Fri, Jul 17, 2020 at 10:28:18PM -0700, Eric Biggers wrote:
> /**
> * INIT_ONCE() - do one-time initialization
> * @done: pointer to a 'bool' flag that tracks whether initialization has been
> * done yet or not. Must be false by default.
> * @mutex: pointer to a mutex to use to
On Sat, Jul 18, 2020 at 12:00:01PM +1000, Dave Chinner wrote:
> Recipes are aimed at people who simply don't understand any of that
> goobledegook. This won't help them -write correct code-.
Indeed. Perhaps this writeup belongs in a different document (with a
pointer from the recipes file), and
> This is one of the reasons that the LKMM documetnation is so damn
> difficult to read and understand: just understanding the vocabulary
> it uses requires a huge learning curve, and it's not defined
> anywhere. Understanding the syntax of examples requires a huge
> learning curve, because it's
On Sat, Jul 18, 2020 at 03:13:04AM +0100, Matthew Wilcox wrote:
> On Fri, Jul 17, 2020 at 06:38:39PM -0700, Eric Biggers wrote:
> > On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> > > On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > > > +If that doesn't apply,
On Fri, Jul 17, 2020 at 06:38:39PM -0700, Eric Biggers wrote:
> On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> > On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > > +If that doesn't apply, you'll have to implement one-time init yourself.
> > > +
> > > +The
On Fri, Jul 17, 2020 at 09:25:55PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> > On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > > +the more
On Fri, Jul 17, 2020 at 09:25:55PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> > On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > > +the more
On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The "one-time init" pattern is implemented incorrectly in various places
> in the kernel. And when people do try to implement it correctly, it is
> unclear what to use. Try to give some proper guidance.
>
>
On Fri, Jul 17, 2020 at 09:25:55PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> > On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > > +the more
On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > +If that doesn't apply, you'll have to implement one-time init yourself.
> > +
> > +The simplest implementation just uses a mutex and an 'inited' flag.
> > +This
On Fri, Jul 17, 2020 at 05:58:57PM -0700, Eric Biggers wrote:
> On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > > +There are also cases in which the smp_load_acquire() can be replaced by
> > > +the more lightweight READ_ONCE(). (smp_store_release() is still
> > > +required.)
On Fri, Jul 17, 2020 at 01:51:38PM -0400, Alan Stern wrote:
> On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> > On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> ...
> > > + /* on success, pairs with smp_load_acquire() above and below */
> > > + if
On Fri, Jul 17, 2020 at 01:53:40PM -0700, Darrick J. Wong wrote:
> > +There are also cases in which the smp_load_acquire() can be replaced by
> > +the more lightweight READ_ONCE(). (smp_store_release() is still
> > +required.) Specifically, if all initialized memory is transitively
> >
On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > +If that doesn't apply, you'll have to implement one-time init yourself.
> > +
> > +The simplest implementation just uses a mutex and an 'inited' flag.
> > +This
On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> > +If that doesn't apply, you'll have to implement one-time init yourself.
> > +
> > +The simplest implementation just uses a mutex and an 'inited' flag.
> > +This
On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The "one-time init" pattern is implemented incorrectly in various places
> in the kernel. And when people do try to implement it correctly, it is
> unclear what to use. Try to give some proper guidance.
>
>
On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
...
> > + /* on success, pairs with smp_load_acquire() above and below */
> > + if (cmpxchg_release(, NULL, p) != NULL) {
>
> Why do we have
On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> +If that doesn't apply, you'll have to implement one-time init yourself.
> +
> +The simplest implementation just uses a mutex and an 'inited' flag.
> +This implementation should be used where feasible:
I think some syntactic sugar
On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
...
> +Note that when the cmpxchg_release() fails due to another task already
> +having done it, a second smp_load_acquire() is required, since we still
> +need to acquire the data that the other task released.
When people talk about
On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> +The simplest implementation just uses a mutex and an 'inited' flag.
There's a perfectly good real word "initialised" / initialized.
https://chambers.co.uk/search/?query=inited=21st
> +For the single-pointer case, a further
On Fri, Jul 17, 2020 at 6:48 AM Eric Biggers wrote:
>
> From: Eric Biggers
...
> This is motivated by the discussion at
> https://lkml.kernel.org/linux-fsdevel/2020071300.205104-1-ebigg...@kernel.org/T/#u
...
> +In where cases where taking the mutex in the "already initialized" case
"In
From: Eric Biggers
The "one-time init" pattern is implemented incorrectly in various places
in the kernel. And when people do try to implement it correctly, it is
unclear what to use. Try to give some proper guidance.
This is motivated by the discussion at
39 matches
Mail list logo
