All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Malte Skarupke <malteskarupke@web.de>
Cc: tglx@linutronix.de, mingo@redhat.com, dvhart@infradead.org,
	linux-kernel@vger.kernel.org, malteskarupke@fastmail.fm
Subject: Re: [PATCH] futex: Support smaller futexes of one byte or two byte size.
Date: Fri, 6 Dec 2019 18:37:05 +0100	[thread overview]
Message-ID: <20191206173705.GE2871@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20191206153129.GI2844@hirez.programming.kicks-ass.net>

On Fri, Dec 06, 2019 at 04:31:29PM +0100, Peter Zijlstra wrote:
> > +		case FUTEX_WAKE:
> > +		case FUTEX_REQUEUE:
> > +			/*
> > +			 * these instructions work with sized mutexes, but you
> > +			 * don't need to pass the size. we could silently
> > +			 * ignore the size argument, but the code won't verify
> > +			 * that the correct size is used, so it's preferable
> > +			 * to make that clear to the caller.
> > +			 *
> > +			 * for requeue the meaning would also be ambiguous: do
> > +			 * both of them have to be the same size or not? they
> > +			 * don't, and that's clearer when you just don't pass
> > +			 * a size argument.
> > +			 */
> > +			return -EINVAL;
> 
> Took me a while to figure out this relies on FUTEX_NONE to avoid the
> alignment tests.

And thikning more on that, I really _realy_ hate this.

You're basically saying WAKE is size-less, but that means we must
consider what it means to have a u32 WAIT on @ptr, and a u8 WAKE on
@ptr+1. If the wake really is size-less that should match.

I'd be much happier with requiring strict sizing. Because conversely,
what happens if you have a u32-WAIT at @ptr paired with a u8-WAKE at
@ptr? If we demand strict size we can say that should not match. This
does however mean we should include the size in the hash-match function.

Your Changelog did not consider these implications at all.

  reply	other threads:[~2019-12-06 17:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 23:52 [PATCH] futex: Support smaller futexes of one byte or two byte size Malte Skarupke
2019-12-06 15:31 ` Peter Zijlstra
2019-12-06 17:37   ` Peter Zijlstra [this message]
2019-12-08 22:18     ` Malte Skarupke
2019-12-11 13:44       ` Peter Zijlstra
2019-12-11 19:48         ` Malte Skarupke
2019-12-20 19:08 ` Malte Skarupke
2019-12-20 19:09   ` Malte Skarupke
2019-12-20 19:09     ` Malte Skarupke
2019-12-21 15:56       ` Malte Skarupke
2019-12-21 15:56         ` Malte Skarupke

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=20191206173705.GE2871@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=dvhart@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=malteskarupke@fastmail.fm \
    --cc=malteskarupke@web.de \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.