On Wed 19-10-16 09:40:45, Lorenzo Stoakes wrote:
On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote:
On Wed 19-10-16 09:59:03, Jan Kara wrote:
On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
This patch removes the write parameter from __access_remote_vm() and replaces it with a gup_flags parameter as use of this function previously _implied_ FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
We make this explicit as use of FOLL_FORCE can result in surprising behaviour (and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes lstoakes@gmail.com
So I'm not convinced this (and the following two patches) is actually helping much. By grepping for FOLL_FORCE we will easily see that any caller of access_remote_vm() gets that semantics and can thus continue search
I am really wondering. Is there anything inherent that would require FOLL_FORCE for access_remote_vm? I mean FOLL_FORCE is a really non-trivial thing. It doesn't obey vma permissions so we should really minimize its usage. Do all of those users really need FOLL_FORCE?
I wonder about this also, for example by accessing /proc/self/mem you trigger access_remote_vm() and consequently get_user_pages_remote() meaning FOLL_FORCE is implied and you can use /proc/self/mem to override any VMA permissions. I
yes this is the desirable and expected behavior.
wonder if this is desirable behaviour or whether this ought to be limited to ptrace system calls. Regardless, by making the flag more visible it makes it easier to see that this is happening.
mem_open already enforces PTRACE_MODE_ATTACH