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
| ||
|
Message-ID: <5807AC2B.4090208@linux.intel.com> Date: Wed, 19 Oct 2016 10:23:55 -0700 From: Dave Hansen <dave.hansen@...ux.intel.com> To: Michal Hocko <mhocko@...nel.org> Cc: Lorenzo Stoakes <lstoakes@...il.com>, linux-mm@...ck.org, Linus Torvalds <torvalds@...ux-foundation.org>, Jan Kara <jack@...e.cz>, Hugh Dickins <hughd@...gle.com>, Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...hsingularity.net>, Andrew Morton <akpm@...ux-foundation.org>, adi-buildroot-devel@...ts.sourceforge.net, ceph-devel@...r.kernel.org, dri-devel@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org, kvm@...r.kernel.org, linux-alpha@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-cris-kernel@...s.com, linux-fbdev@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-ia64@...r.kernel.org, linux-kernel@...r.kernel.org, linux-media@...r.kernel.org, linux-mips@...ux-mips.org, linux-rdma@...r.kernel.org, linux-s390@...r.kernel.org, linux-samsung-soc@...r.kernel.org, linux-scsi@...r.kernel.org, linux-security-module@...r.kernel.org, linux-sh@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, netdev@...r.kernel.org, sparclinux@...r.kernel.org, x86@...nel.org Subject: Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags On 10/19/2016 10:01 AM, Michal Hocko wrote: > The question I had earlier was whether this has to be an explicit FOLL > flag used by g-u-p users or we can just use it internally when mm != > current->mm The reason I chose not to do that was that deferred work gets run under a basically random 'current'. If we just use 'mm != current->mm', then the deferred work will sometimes have pkeys enforced and sometimes not, basically randomly. We want to be consistent with whether they are enforced or not, so we explicitly indicate that by calling the remote variant vs. plain.
Powered by blists - more mailing lists