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
| ||
|
Date: Wed, 18 Jan 2017 10:55:50 +0100 From: Michal Hocko <mhocko@...nel.org> To: Vlastimil Babka <vbabka@...e.cz> 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 Wed 18-01-17 10:48:55, Vlastimil Babka wrote: > 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") ... If reverting that patch makes the problem go away and it is applicable for the stable I would rather go that way for stable and take a deep breath and rethink the whole cpuset and nodemask manipulation in the allocation path for a better long term solution. -- Michal Hocko SUSE Labs
Powered by blists - more mailing lists