linux-kernel - Re: [PATCH v2 1/8] lib/find_bit.c: Add find_last_zero

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]

Message-ID: <CAM7-yPSPxTz8CmVfD2vC=P4RW6yBXsYiH+YfKQtd4PzPj=ocvA@mail.gmail.com>
Date:   Sun, 6 Dec 2020 17:39:16 +0900
From:   Yun Levi <ppbuk5246@...il.com>
To:     gregkh@...uxfoundation.org
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Yury Norov <yury.norov@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        richard.weiyang@...ux.alibaba.com, christian.brauner@...ntu.com,
        Arnd Bergmann <arnd@...db.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>, changbin.du@...el.com,
        rdunlap@...radead.org, masahiroy@...nel.org, peterz@...radead.org,
        peter.enderborg@...y.com, krzk@...nel.org,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Kees Cook <keescook@...omium.org>, broonie@...nel.org,
        matti.vaittinen@...rohmeurope.com, mhiramat@...nel.org,
        jpa@....mail.kapsi.fi, nivedita@...m.mit.edu,
        Alexander Potapenko <glider@...gle.com>, orson.zhai@...soc.com,
        Takahiro Akashi <takahiro.akashi@...aro.org>, clm@...com,
        Josef Bacik <josef@...icpanda.com>, dsterba@...e.com,
        dushistov@...l.ru,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch@...r.kernel.org, linux-btrfs@...r.kernel.org
Subject: Re: [PATCH v2 1/8] lib/find_bit.c: Add find_last_zero_bit

> This, and the change above this, are not related to this patch so you
> might not want to include them.
>
> Also, why is this patch series even needed?  I don't see a justification
> for it anywhere, only "what" this patch is, not "why".

A little part of codes are trying to find the last zero bit using
for_each_clear_bit.
For example in fs/btrfs/free-space-cache.c' s
steal_from_bitmap_to_front function
which I changed in the 8'th patch.
I think it has some overhead to find the last clear bit (it start to
find from 0 bit to specified index),
so I try to add the find_last_zero_bit function to improve this.

Maybe I have a lack explanation in the message.

Sorry to make noise.

Thanks.
Levi.



On Sun, Dec 6, 2020 at 5:31 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Sun, Dec 06, 2020 at 03:46:24PM +0900, Levi Yun wrote:
> > Inspired find_next_*_bit and find_last_bit, add find_last_zero_bit
> > And add le support about find_last_bit and find_last_zero_bit.
> >
> > Signed-off-by: Levi Yun <ppbuk5246@...il.com>
> > ---
> >  lib/find_bit.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++--
> >  1 file changed, 62 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/find_bit.c b/lib/find_bit.c
> > index 4a8751010d59..f9dda2bf7fa9 100644
> > --- a/lib/find_bit.c
> > +++ b/lib/find_bit.c
> > @@ -90,7 +90,7 @@ unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
> >  EXPORT_SYMBOL(find_next_zero_bit);
> >  #endif
> >
> > -#if !defined(find_next_and_bit)
> > +#ifndef find_next_and_bit
> >  unsigned long find_next_and_bit(const unsigned long *addr1,
> >               const unsigned long *addr2, unsigned long size,
> >               unsigned long offset)
> > @@ -141,7 +141,7 @@ unsigned long find_last_bit(const unsigned long *addr, unsigned long size)
> >  {
> >       if (size) {
> >               unsigned long val = BITMAP_LAST_WORD_MASK(size);
> > -             unsigned long idx = (size-1) / BITS_PER_LONG;
> > +             unsigned long idx = (size - 1) / BITS_PER_LONG;
> >
> >               do {
> >                       val &= addr[idx];
>
> This, and the change above this, are not related to this patch so you
> might not want to include them.
>
> Also, why is this patch series even needed?  I don't see a justification
> for it anywhere, only "what" this patch is, not "why".
>
> thanks
>
> greg k-h