linux-kernel - Re: [PATCH v2 4/4] mm/hugetl.c: warn out if expected count of huge pages adjustment is not achieved

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: <89039447-f2f6-1c5e-f8c0-10314a002069@oracle.com>
Date:   Tue, 11 Aug 2020 16:11:36 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     Baoquan He <bhe@...hat.com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, david@...hat.com,
        akpm@...ux-foundation.org
Subject: Re: [PATCH v2 4/4] mm/hugetl.c: warn out if expected count of huge
 pages adjustment is not achieved

On 8/11/20 12:24 AM, Michal Hocko wrote:
> 
> My opinion is that the warning is too late to add at this stage. It
> would have been much better if the user interface has provided a
> reasonable feedback on how much the request was sucessful. But this
> is not the case (except for few error cases) and we have to live with
> the interface where the caller has to read the value after writing to
> it. Lame but a reality.
> 
> I have heard about people making an opportunistic attempt to grab as
> many hugetlb pages as possible and they do expect the failure and scale
> the request size down. I do not think those would appreciate warnings.
> 
> That being said I would rather keep the existing behavior even though it
> is suboptimal. It is just trivial to add the check in the userspace
> without risking complains by other users. Besides the warning is not
> really telling us much more than a subsequent read anyway. You are not
> going to learn why the allocation has failed because that one is done
> (intentionaly) as __GFP_NOWARN.
> 

Thanks Michal.

As previously stated, I do not have a strong opinion about this.  Because of
this, let's just leave things as they are and not add the message.

It is pretty clear that a user needs to read the value after writing to
determine if all pages were allocated.  The log message would add little
benefit to the end user.
-- 
Mike Kravetz