All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: NeilBrown <neilb@suse.de>
Cc: Ingo Molnar <mingo@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-block@vger.kernel.org
Subject: Re: [PATCH 2/7] sched: change wake_up_bit() and related function to expect unsigned long *
Date: Mon, 16 Sep 2024 20:18:17 +0200	[thread overview]
Message-ID: <20240916181817.GF4723@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <172648729127.17050.15543415823867299910@noble.neil.brown.name>

On Mon, Sep 16, 2024 at 09:48:11PM +1000, NeilBrown wrote:
> On Mon, 16 Sep 2024, Peter Zijlstra wrote:
> > On Mon, Aug 26, 2024 at 04:30:59PM +1000, NeilBrown wrote:
> > > wake_up_bit() currently allows a "void *".  While this isn't strictly a
> > > problem as the address is never dereferenced, it is inconsistent with
> > > the corresponding wait_var_event() which requires "unsigned long *" and
> > > does dereference the pointer.
> > 
> > I'm having trouble parsing this. The way I read it, you're contradicting
> > yourself. Where does wait_var_event() require 'unsigned long *' ?
> 
> Sorry, that is meant so as "the corresponding wait_on_bit()".
> 
> 
> > 
> > > And code that needs to wait for a change in something other than an
> > > unsigned long would be better served by wake_up_var().
> > 
> > This, afaict the whole var thing is size invariant. It only cares about
> > the address.
> > 
> 
> Again - wake_up_bit().  Sorry - bits are vars were swimming around my
> brain and I didn't proof-read properly.
> 
> This patch is all "bit", no "var".

OK :-)

Anyway, other than that the patches look fine, but given we're somewhat
in the middle of the merge window and all traveling to get into Vienna
and have a few beers, I would much prefer merging these patches after
-rc1, that okay?

  reply	other threads:[~2024-09-16 18:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-26  6:30 [PATCH 0/7 v2 RFC] Make wake_up_{bit,var} less fragile NeilBrown
2024-08-26  6:30 ` [PATCH 1/7] block: change wait on bd_claiming to use a var_waitqueue, not a bit_waitqueue NeilBrown
2024-09-17  3:12   ` Jens Axboe
2024-09-17 21:54     ` NeilBrown
2024-09-17  3:13   ` (subset) " Jens Axboe
2024-08-26  6:30 ` [PATCH 2/7] sched: change wake_up_bit() and related function to expect unsigned long * NeilBrown
2024-09-16 11:28   ` Peter Zijlstra
2024-09-16 11:48     ` NeilBrown
2024-09-16 18:18       ` Peter Zijlstra [this message]
2024-09-16 20:37         ` NeilBrown
2024-08-26  6:31 ` [PATCH 3/7] sched: Improve documentation for wake_up_bit/wait_on_bit family of functions NeilBrown
2024-08-26  6:31 ` [PATCH 4/7] sched: Document wait_var_event() family of functions and wake_up_var() NeilBrown
2024-08-26  6:31 ` [PATCH 5/7] sched: Add test_and_clear_wake_up_bit() and atomic_dec_and_wake_up() NeilBrown
2024-08-26  6:31 ` [PATCH 6/7] sched: Add wait/wake interface for variable updated under a lock NeilBrown
2024-08-26  6:31 ` [PATCH 7/7] Block: switch bd_prepare_to_claim to use wait_var_event_mutex() NeilBrown
2024-09-15 23:52 ` [PATCH 0/7 v2 RFC] Make wake_up_{bit,var} less fragile NeilBrown

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=20240916181817.GF4723@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=neilb@suse.de \
    --cc=torvalds@linux-foundation.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 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.