linux-kernel - Re: [PATCH 1/2] perpcu: correct pcpu_find_block

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: <20190304191344.GB17970@dennisz-mbp.dhcp.thefacebook.com>
Date:   Mon, 4 Mar 2019 14:13:44 -0500
From:   Dennis Zhou <dennis@...nel.org>
To:     Peng Fan <peng.fan@....com>
Cc:     "tj@...nel.org" <tj@...nel.org>, "cl@...ux.com" <cl@...ux.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "van.freenix@...il.com" <van.freenix@...il.com>
Subject: Re: [PATCH 1/2] perpcu: correct pcpu_find_block_fit comments

On Mon, Mar 04, 2019 at 10:33:52AM +0000, Peng Fan wrote:
> pcpu_find_block_fit is not find block index, it is to find
> the bitmap off in a chunk.
> 
> Signed-off-by: Peng Fan <peng.fan@....com>
> ---
> 
> V1:
>   Based on https://patchwork.kernel.org/cover/10832459/ applied linux-next
> 
>  mm/percpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/percpu.c b/mm/percpu.c
> index 7f630d5469e8..5ee90fc34ea3 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -1061,7 +1061,7 @@ static bool pcpu_is_populated(struct pcpu_chunk *chunk, int bit_off, int bits,
>  }
>  
>  /**
> - * pcpu_find_block_fit - finds the block index to start searching
> + * pcpu_find_block_fit - finds the offset in chunk bitmap to start searching
>   * @chunk: chunk of interest
>   * @alloc_bits: size of request in allocation units
>   * @align: alignment of area (max PAGE_SIZE bytes)
> -- 
> 2.16.4
> 

So really the block index is encoded in the bit offset. I'm not super
happy with either wording because the point of the function really is to
find a block(s) that can support this allocation and it happens the
output is a chunk offset.

Thanks,
Dennis