Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1465676 > unrolled thread

Re: [PATCH v5 3/3] locking/mutex: Ensure forward progress of waiter-spinner

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v5 3/3] locking/mutex: Ensure forward progress of  waiter-spinner Peter Zijlstra <peterz@infradead.org> - 2016-08-19 03:00 +0200
    Re: [PATCH v5 3/3] locking/mutex: Ensure forward progress of  waiter-spinner Peter Zijlstra <peterz@infradead.org> - 2016-08-19 03:00 +0200
    Re: [PATCH v5 3/3] locking/mutex: Ensure forward progress of  waiter-spinner Imre Deak <imre.deak@intel.com> - 2016-08-19 04:40 +0200
    Re: [PATCH v5 3/3] locking/mutex: Ensure forward progress of  waiter-spinner Jason Low <jason.low2@hpe.com> - 2016-08-19 06:10 +0200

#1465676 — Re: [PATCH v5 3/3] locking/mutex: Ensure forward progress of waiter-spinner

On Thu, Aug 11, 2016 at 11:01:27AM -0400, Waiman Long wrote:
> The following is the updated patch that should fix the build error in
> non-x86 platform.
> 

This patch was whitespace challenged, but I think I munged it properly.

I've also stuck something based on Jason's patch on top. Please have a
look at:

  https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/log/?h=locking/core

compile tested only so far..

[toc] | [next] | [standalone]

#1465682

On Thu, Aug 18, 2016 at 11:04:40AM -0700, Jason Low wrote:
> On Thu, 2016-08-18 at 17:58 +0200, Peter Zijlstra wrote:
> > On Thu, Aug 11, 2016 at 11:01:27AM -0400, Waiman Long wrote:
> > > The following is the updated patch that should fix the build error in
> > > non-x86 platform.
> > > 
> > 
> > This patch was whitespace challenged, but I think I munged it properly.
> > 
> > I've also stuck something based on Jason's patch on top. Please have a
> > look at:
> > 
> >   https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/log/?h=locking/core
> 
> Should we convert the flags back to type 'bool'? 

No,

> We're using them as
> booleans and we could also leave unneeded space available in case we
> ever need to squeeze some more variable(s) in the structure.

Because sizeof(bool) is undefined, that then leaves sizeof(struct mutex)
and alignof(struct mutex) and its exact layout also undefined.

Never use bool in aggregate types.

Of course, an actual implementation needs a sizeof(bool) to translate
things, but these are defined in the architecture ABI, not in the
language. And having struct mutex change depending on whatever an
architecture ABI chooses is very bad form.

[toc] | [prev] | [next] | [standalone]

#1465915

On to, 2016-08-18 at 17:58 +0200, Peter Zijlstra wrote:
> On Thu, Aug 11, 2016 at 11:01:27AM -0400, Waiman Long wrote:
> > The following is the updated patch that should fix the build error
> > in
> > non-x86 platform.
> > 
> 
> This patch was whitespace challenged, but I think I munged it
> properly.
> 
> I've also stuck something based on Jason's patch on top. Please have
> a
> look at:
> 
>   https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/log/?
> h=locking/core
> 
> compile tested only so far..

It works for me and fixes my test case.

Nitpick: "Try-acquire now that we got woken at the head of the queue."
would be more accurate by also adding "or received a signal."

--Imre

[toc] | [prev] | [next] | [standalone]

#1465976

On Thu, 2016-08-18 at 17:58 +0200, Peter Zijlstra wrote:
> On Thu, Aug 11, 2016 at 11:01:27AM -0400, Waiman Long wrote:
> > The following is the updated patch that should fix the build error in
> > non-x86 platform.
> > 
> 
> This patch was whitespace challenged, but I think I munged it properly.
> 
> I've also stuck something based on Jason's patch on top. Please have a
> look at:
> 
>   https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/log/?h=locking/core

Should we convert the flags back to type 'bool'? We're using them as
booleans and we could also leave unneeded space available in case we
ever need to squeeze some more variable(s) in the structure.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web