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] [day] [month] [year] [list]
Message-ID: <20161026085547.GA3737@lucifer>
Date:   Wed, 26 Oct 2016 09:55:47 +0100
From:   Lorenzo Stoakes <lstoakes@...il.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     linux-mm@...ck.org, Linus Torvalds <torvalds@...ux-foundation.org>,
        Jan Kara <jack@...e.cz>, Hugh Dickins <hughd@...gle.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Rik van Riel <riel@...hat.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly
 pass FOLL_* flags

On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
>I am wondering whether we can go further. E.g. it is not really clear to
>me whether we need an explicit FOLL_REMOTE when we can in fact check
>mm != current->mm and imply that. Maybe there are some contexts which
>wouldn't work, I haven't checked.
>
>Then I am also wondering about FOLL_TOUCH behavior.
>__get_user_pages_unlocked has only few callers which used to be
>get_user_pages_unlocked before 1e9877902dc7e ("mm/gup: Introduce
>get_user_pages_remote()"). To me a dropped FOLL_TOUCH seems
>unintentional. Now that get_user_pages_unlocked has gup_flags argument I
>guess we might want to get rid of the __g-u-p-u version altogether, no?
>
>__get_user_pages is quite low level and imho shouldn't be exported. It's
>only user - kvm - should rather pull those two functions to gup instead
>and export them. There is nothing really KVM specific in them.

I believe I've attacked each of these, other than the use of explicit
FOLL_REMOTE which was explained by Dave.

> I also cannot say I would be entirely thrilled about get_user_pages_locked,
> we only have one user which can simply do lock g-u-p unlock AFAICS.

The principle difference here seems to be the availability of VM_FAULT_RETRY
behaviour (by passing a non-NULL locked argument), and indeed the comments in
gup.c recommends using get_user_pages_locked() if possible (though it seems not
to have been heeded too much :), so I'm not sure if this would be a fruitful
refactor, let me know!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ