linux-kernel - Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.