linux-kernel - Re: [PATCH 01/11] sched/wait: Introduce wait_var

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAPcyv4hu+6-dO+ncM0U4EHwUW_TyoNu1zngVzne0x8rVEa0p2w@mail.gmail.com>
Date:   Mon, 19 Mar 2018 09:45:54 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        Daniel Vetter <daniel.vetter@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        Chris Mason <clm@...com>,
        Anna Schumaker <anna.schumaker@...app.com>,
        Joel Becker <jlbec@...lplan.org>,
        James Hogan <jhogan@...nel.org>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        George Spelvin <linux@...encehorizons.net>
Subject: Re: [PATCH 01/11] sched/wait: Introduce wait_var_event()

On Thu, Mar 15, 2018 at 5:19 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> As a replacement for the wait_on_atomic_t() API provide the
> wait_var_event() API.
>
> The wait_var_event() API is based on the very same hashed-waitqueue
> idea, but doesn't care about the type (atomic_t) or the specific
> condition (atomic_read() == 0). IOW. it's much more widely
> applicable/flexible.
>
> It shares all the benefits/disadvantages of a hashed-waitqueue
> approach with the existing wait_on_atomic_t/wait_on_bit() APIs.
>
> The API is modeled after the existing wait_event() API, but instead of
> taking a wait_queue_head, it takes an address. This addresses is
> hashed to obtain a wait_queue_head from the bit_wait_table.
>
> Similar to the wait_event() API, it takes a condition expression as
> second argument and will wait until this expression becomes true.
>
> The following are (mostly) identical replacements:
>
>   wait_on_atomic_t(&my_atomic, atomic_t_wait, TASK_UNINTERRUPTIBLE);
>   wake_up_atomic_t(&my_atomic);
>
>   wait_var_event(&my_atomic, !atomic_read(&my_atomic));
>   wake_up_var(&my_atomic);
>
> The only difference is that wake_up_var() is an unconditional wakeup
> and doesn't check the previously hard-coded (atomic_read() == 0)
> condition here. This is of little concequence, since most callers are
> already conditional on atomic_dec_and_test() and the ones that are
> not, are trivial to make so.
>
> Cc: David Howells <dhowells@...hat.com>
> Tested-by: Dan Williams <dan.j.williams@...el.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> ---
>  include/linux/wait_bit.h |   70 +++++++++++++++++++++++++++++++++++++++++++++++
>  kernel/sched/wait_bit.c  |   48 ++++++++++++++++++++++++++++++++
>  2 files changed, 118 insertions(+)

Hi Peter,

Is this commit ready to hit tip/sched/core? I'm looking for an
immutable branch that I can use as a basis for the "dax vs dma vs
truncate" fix series.

Thanks in advance.