Thread (38 messages) 38 messages, 7 authors, 2016-10-20

Re: [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

From: Michal Hocko <mhocko@kernel.org>
Date: 2016-10-19 08:13:52
Also in: ceph-devel, dri-devel, intel-gfx, kvm, linux-alpha, linux-arm-kernel, linux-fsdevel, linux-media, linux-mips, linux-mm, linux-rdma, linux-s390, linux-samsung-soc, linux-scsi, linux-sh, linuxppc-dev, lkml, netdev, sparclinux

On Wed 19-10-16 09:59:03, Jan Kara wrote:
On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
quoted
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 <redacted>
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?

Anyway I would rather see the flag explicit and used at more places than
hidden behind a helper function.
-- 
Michal Hocko
SUSE Labs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help