linux-kernel - Re: [PATCH v5 1/6] mm: Adjust shuffle code to allow for future coalescing

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Aug 2019 15:24:09 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     nitesh@...hat.com, KVM list <kvm@...r.kernel.org>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        David Hildenbrand <david@...hat.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Michal Hocko <mhocko@...nel.org>,
        Linux MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        virtio-dev@...ts.oasis-open.org,
        Oscar Salvador <osalvador@...e.de>, yang.zhang.wz@...il.com,
        Pankaj Gupta <pagupta@...hat.com>,
        Rik van Riel <riel@...riel.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        lcapitulino@...hat.com, "Wang, Wei W" <wei.w.wang@...el.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Alexander Duyck <alexander.h.duyck@...ux.intel.com>
Subject: Re: [PATCH v5 1/6] mm: Adjust shuffle code to allow for future coalescing

On Mon, Aug 12, 2019 at 2:33 PM Alexander Duyck
<alexander.duyck@...il.com> wrote:
>
> From: Alexander Duyck <alexander.h.duyck@...ux.intel.com>
>
> This patch is meant to move the head/tail adding logic out of the shuffle

s/This patch is meant to move/Move/

> code and into the __free_one_page function since ultimately that is where
> it is really needed anyway. By doing this we should be able to reduce the
> overhead

Is the overhead benefit observable? I would expect the overhead of
get_random_u64() dominates.

> and can consolidate all of the list addition bits in one spot.

This sounds the better argument.

[..]
> diff --git a/mm/shuffle.h b/mm/shuffle.h
> index 777a257a0d2f..add763cc0995 100644
> --- a/mm/shuffle.h
> +++ b/mm/shuffle.h
> @@ -3,6 +3,7 @@
>  #ifndef _MM_SHUFFLE_H
>  #define _MM_SHUFFLE_H
>  #include <linux/jump_label.h>
> +#include <linux/random.h>
>
>  /*
>   * SHUFFLE_ENABLE is called from the command line enabling path, or by
> @@ -43,6 +44,32 @@ static inline bool is_shuffle_order(int order)
>                 return false;
>         return order >= SHUFFLE_ORDER;
>  }
> +
> +static inline bool shuffle_add_to_tail(void)
> +{
> +       static u64 rand;
> +       static u8 rand_bits;
> +       u64 rand_old;
> +
> +       /*
> +        * The lack of locking is deliberate. If 2 threads race to
> +        * update the rand state it just adds to the entropy.
> +        */
> +       if (rand_bits-- == 0) {
> +               rand_bits = 64;
> +               rand = get_random_u64();
> +       }
> +
> +       /*
> +        * Test highest order bit while shifting our random value. This
> +        * should result in us testing for the carry flag following the
> +        * shift.
> +        */
> +       rand_old = rand;
> +       rand <<= 1;
> +
> +       return rand < rand_old;
> +}

This function seems too involved to be a static inline and I believe
each compilation unit that might call this routine gets it's own copy
of 'rand' and 'rand_bits' when the original expectation is that they
are global. How about leave this bit to mm/shuffle.c and rename it
coin_flip(), or something more generic, since it does not
'add_to_tail'? The 'add_to_tail' action is something the caller
decides.