linux-kernel - Re: [PATCH] hugetlbfs: rework calculation code of Hugepage size in hugetlbfs_show

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]

Date:   Mon, 1 Feb 2021 19:19:38 +0800
From:   Miaohe Lin <linmiaohe@...wei.com>
To:     David Hildenbrand <david@...hat.com>
CC:     <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
        <akpm@...ux-foundation.org>, <mike.kravetz@...cle.com>
Subject: Re: [PATCH] hugetlbfs: rework calculation code of Hugepage size in
 hugetlbfs_show_options()

Hi:
On 2021/2/1 18:56, David Hildenbrand wrote:
> On 01.02.21 09:23, Miaohe Lin wrote:
>> Rework calculation code of the Hugepage size to make it more readable and
>> straightforward.
>>
>> Signed-off-by: Miaohe Lin <linmiaohe@...wei.com>
>> ---
>>   fs/hugetlbfs/inode.c | 9 +++++----
>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>> index 3a08fbae3b53..1be18de4b537 100644
>> --- a/fs/hugetlbfs/inode.c
>> +++ b/fs/hugetlbfs/inode.c
>> @@ -1014,11 +1014,12 @@ static int hugetlbfs_show_options(struct seq_file *m, struct dentry *root)
>>       if (sbinfo->max_inodes != -1)
>>           seq_printf(m, ",nr_inodes=%lu", sbinfo->max_inodes);
>>   -    hpage_size /= 1024;
>> -    mod = 'K';
>> -    if (hpage_size >= 1024) {
>> -        hpage_size /= 1024;
>> +    if (hpage_size >= SZ_1M) {
>> +        hpage_size /= SZ_1M;
>>           mod = 'M';
>> +    } else {
>> +        hpage_size /= SZ_1K;
>> +        mod = 'K';
>>       }
>>       seq_printf(m, ",pagesize=%lu%c", hpage_size, mod);
>>       if (spool) {
>>
> 
> Looks correct but I am not convinced the old code was that complicated to understand.
> 

The old code is not complicated but I think it may be better to use macro instead of well-known "magic number".
Many thanks for review.:)