Drop the setting of WQ_FLAG_EXCLUSIVE from add_wait_queue_priority() to
differentiate it from add_wait_queue_priority_exclusive().  The one and
only user add_wait_queue_priority(), Xen privcmd's irqfd_wakeup(),
unconditionally returns '0', i.e. doesn't actually operate in exclusive
mode.

Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 kernel/sched/wait.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index 03252badb8e8..b8f6502372b0 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -40,7 +40,7 @@ void add_wait_queue_priority(struct wait_queue_head *wq_head, struct wait_queue_
 {
 	unsigned long flags;
 
-	wq_entry->flags |= WQ_FLAG_EXCLUSIVE | WQ_FLAG_PRIORITY;
+	wq_entry->flags |= WQ_FLAG_PRIORITY;
 	spin_lock_irqsave(&wq_head->lock, flags);
 	__add_wait_queue(wq_head, wq_entry);
 	spin_unlock_irqrestore(&wq_head->lock, flags);
@@ -82,7 +82,7 @@ EXPORT_SYMBOL(remove_wait_queue);
  * the non-exclusive tasks. Normally, exclusive tasks will be at the end of
  * the list and any non-exclusive tasks will be woken first. A priority task
  * may be at the head of the list, and can consume the event without any other
- * tasks being woken.
+ * tasks being woken if it's also an exclusive task.
  *
  * There are circumstances in which we can try to wake a task which has already
  * started to run but is not in state TASK_RUNNING. try_to_wake_up() returns
-- 
2.49.0.1101.gccaa498523-goog

On Mon, May 19, 2025 at 11:55:10AM -0700, Sean Christopherson wrote:
> Drop the setting of WQ_FLAG_EXCLUSIVE from add_wait_queue_priority() to
> differentiate it from add_wait_queue_priority_exclusive().  The one and
> only user add_wait_queue_priority(), Xen privcmd's irqfd_wakeup(),
> unconditionally returns '0', i.e. doesn't actually operate in exclusive
> mode.

I find:

drivers/hv/mshv_eventfd.c:      add_wait_queue_priority(wqh, &irqfd->irqfd_wait);
drivers/xen/privcmd.c:  add_wait_queue_priority(wqh, &kirqfd->wait);

I mean, it might still be true and all, but hyperv seems to also use
this now.

On Tue, May 20, 2025, Peter Zijlstra wrote:
> On Mon, May 19, 2025 at 11:55:10AM -0700, Sean Christopherson wrote:
> > Drop the setting of WQ_FLAG_EXCLUSIVE from add_wait_queue_priority() to
> > differentiate it from add_wait_queue_priority_exclusive().  The one and
> > only user add_wait_queue_priority(), Xen privcmd's irqfd_wakeup(),
> > unconditionally returns '0', i.e. doesn't actually operate in exclusive
> > mode.
> 
> I find:
> 
> drivers/hv/mshv_eventfd.c:      add_wait_queue_priority(wqh, &irqfd->irqfd_wait);
> drivers/xen/privcmd.c:  add_wait_queue_priority(wqh, &kirqfd->wait);
> 
> I mean, it might still be true and all, but hyperv seems to also use
> this now.

Oh FFS, another "heavily inspired by KVM".  I should have bribed someone to take
this series when I had the chance.  *sigh*

Unfortunately, the Hyper-V code does actually operate in exclusive mode.  Unless
you have a better idea, I'll tweak the series to:

  1. Drop WQ_FLAG_EXCLUSIVE from add_wait_queue_priority() and have the callers
     explicitly set the flag, 
  2. Add a patch to drop WQ_FLAG_EXCLUSIVE from Xen privcmd entirely.
  3. Introduce add_wait_queue_priority_exclusive() and switch KVM to use it.

That has an added bonus of introducing the Xen change in a dedicated patch, i.e.
is probably a sequence anyways.

Alternatively, I could rewrite the Hyper-V code a la the KVM changes, but I'm not
feeling very charitable at the moment (the complete lack of documentation for
their ioctl doesn't help).

On 21.05.25 00:20, Sean Christopherson wrote:
> On Tue, May 20, 2025, Peter Zijlstra wrote:
>> On Mon, May 19, 2025 at 11:55:10AM -0700, Sean Christopherson wrote:
>>> Drop the setting of WQ_FLAG_EXCLUSIVE from add_wait_queue_priority() to
>>> differentiate it from add_wait_queue_priority_exclusive().  The one and
>>> only user add_wait_queue_priority(), Xen privcmd's irqfd_wakeup(),
>>> unconditionally returns '0', i.e. doesn't actually operate in exclusive
>>> mode.
>>
>> I find:
>>
>> drivers/hv/mshv_eventfd.c:      add_wait_queue_priority(wqh, &irqfd->irqfd_wait);
>> drivers/xen/privcmd.c:  add_wait_queue_priority(wqh, &kirqfd->wait);
>>
>> I mean, it might still be true and all, but hyperv seems to also use
>> this now.
> 
> Oh FFS, another "heavily inspired by KVM".  I should have bribed someone to take
> this series when I had the chance.  *sigh*
> 
> Unfortunately, the Hyper-V code does actually operate in exclusive mode.  Unless
> you have a better idea, I'll tweak the series to:
> 
>    1. Drop WQ_FLAG_EXCLUSIVE from add_wait_queue_priority() and have the callers
>       explicitly set the flag,
>    2. Add a patch to drop WQ_FLAG_EXCLUSIVE from Xen privcmd entirely.
>    3. Introduce add_wait_queue_priority_exclusive() and switch KVM to use it.
> 
> That has an added bonus of introducing the Xen change in a dedicated patch, i.e.
> is probably a sequence anyways.

Works for me.


Juergen

> 
> Alternatively, I could rewrite the Hyper-V code a la the KVM changes, but I'm not
> feeling very charitable at the moment (the complete lack of documentation for
> their ioctl doesn't help).

On Tue, May 20, 2025 at 03:20:00PM -0700, Sean Christopherson wrote:
> On Tue, May 20, 2025, Peter Zijlstra wrote:
> > On Mon, May 19, 2025 at 11:55:10AM -0700, Sean Christopherson wrote:
> > > Drop the setting of WQ_FLAG_EXCLUSIVE from add_wait_queue_priority() to
> > > differentiate it from add_wait_queue_priority_exclusive().  The one and
> > > only user add_wait_queue_priority(), Xen privcmd's irqfd_wakeup(),
> > > unconditionally returns '0', i.e. doesn't actually operate in exclusive
> > > mode.
> > 
> > I find:
> > 
> > drivers/hv/mshv_eventfd.c:      add_wait_queue_priority(wqh, &irqfd->irqfd_wait);
> > drivers/xen/privcmd.c:  add_wait_queue_priority(wqh, &kirqfd->wait);
> > 
> > I mean, it might still be true and all, but hyperv seems to also use
> > this now.
> 
> Oh FFS, another "heavily inspired by KVM".  I should have bribed someone to take
> this series when I had the chance.  *sigh*
> 
> Unfortunately, the Hyper-V code does actually operate in exclusive mode.  Unless
> you have a better idea, I'll tweak the series to:
> 
>   1. Drop WQ_FLAG_EXCLUSIVE from add_wait_queue_priority() and have the callers
>      explicitly set the flag, 
>   2. Add a patch to drop WQ_FLAG_EXCLUSIVE from Xen privcmd entirely.
>   3. Introduce add_wait_queue_priority_exclusive() and switch KVM to use it.
> 
> That has an added bonus of introducing the Xen change in a dedicated patch, i.e.
> is probably a sequence anyways.
> 
> Alternatively, I could rewrite the Hyper-V code a la the KVM changes, but I'm not
> feeling very charitable at the moment (the complete lack of documentation for
> their ioctl doesn't help).

Works for me. Michael is typically very responsive wrt hyperv (but you
probably know this).