linux-kernel - Re: [RFC 3/4] mm, page_alloc: move cpuset seqcount checking to slowpath

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:   Wed, 18 Jan 2017 10:48:55 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Mel Gorman <mgorman@...hsingularity.net>,
        Ganapatrao Kulkarni <gpkulkarni@...il.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC 3/4] mm, page_alloc: move cpuset seqcount checking to
 slowpath

On 01/18/2017 10:40 AM, Michal Hocko wrote:
> On Tue 17-01-17 23:16:09, Vlastimil Babka wrote:
>> This is a preparation for the following patch to make review simpler. While
>> the primary motivation is a bug fix, this could also save some cycles in the
>> fast path.
>
> I cannot say I would be happy about this patch :/ The code is still very
> confusing and subtle. I really think we should get rid of
> synchronization with the concurrent cpuset/mempolicy updates instead.
> Have you considered that instead?

Not so thoroughly yet, but I already suspect it would be intrusive for stable. 
We could make copies of nodemask and mems_allowed and protect just the copying 
with seqcount, but that would mean overhead and stack space. Also we might try 
revert 682a3385e773 ("mm, page_alloc: inline the fast path of the zonelist 
iterator") ...