Message ID | 20160126202829.GA21250@node.shutemov.name (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
On Tue, 26 Jan 2016 22:28:29 +0200 "Kirill A. Shutemov" <kirill@shutemov.name> wrote: > The patch below fixes the issue for me, but this bug makes me wounder how > many bugs like this we have in kernel... :-/ > > Looks like we are too permissive about which VMA is migratable: > vma_migratable() filters out VMA by VM_IO and VM_PFNMAP. > I think VM_DONTEXPAND also correlate with VMA which cannot be migrated. > > $ git grep VM_DONTEXPAND drivers | grep -v '\(VM_IO\|VM_PFNMAN\)' | wc -l > 33 > > Hm.. :-| > > It worth looking on them closely... And I wouldn't be surprised if some > VMAs without all of these flags are not migratable too. > > Sigh.. Any thoughts? Sigh indeed. I think that both VM_DONTEXPAND and VM_DONTDUMP are pretty good signs that mbind() should not be mucking with this vma. If such a policy sometimes results in mbind failing to set a policy then that's not a huge loss - something runs a bit slower maybe. I mean, we only really expect mbind() to operate against regular old anon/pagecache memory, yes? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 26 Jan 2016 22:28:29 +0200 "Kirill A. Shutemov" <kirill@shutemov.name> wrote: > Let's mark the VMA as VM_IO to indicate to mm core that the VMA is > migratable. > > ... > > --- a/drivers/scsi/sg.c > +++ b/drivers/scsi/sg.c > @@ -1261,7 +1261,7 @@ sg_mmap(struct file *filp, struct vm_area_struct *vma) > } > > sfp->mmap_called = 1; > - vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP; > + vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; > vma->vm_private_data = sfp; > vma->vm_ops = &sg_mmap_vm_ops; > return 0; I'll put cc:stable on this - I don't think we recently did anything to make this happen? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 26, 2016 at 12:49:16PM -0800, Andrew Morton wrote: > On Tue, 26 Jan 2016 22:28:29 +0200 "Kirill A. Shutemov" <kirill@shutemov.name> wrote: > > > Let's mark the VMA as VM_IO to indicate to mm core that the VMA is > > migratable. > > > > ... > > > > --- a/drivers/scsi/sg.c > > +++ b/drivers/scsi/sg.c > > @@ -1261,7 +1261,7 @@ sg_mmap(struct file *filp, struct vm_area_struct *vma) > > } > > > > sfp->mmap_called = 1; > > - vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP; > > + vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; > > vma->vm_private_data = sfp; > > vma->vm_ops = &sg_mmap_vm_ops; > > return 0; > > I'll put cc:stable on this - I don't think we recently did anything to make > this happen? The VM_BUG_ON is new bb5b8589767a ("mm: make sure isolate_lru_page() is never called for tail page"), but I don't think it changes the picture much.
On Tue, Jan 26, 2016 at 12:48:23PM -0800, Andrew Morton wrote: > On Tue, 26 Jan 2016 22:28:29 +0200 "Kirill A. Shutemov" <kirill@shutemov.name> wrote: > > > The patch below fixes the issue for me, but this bug makes me wounder how > > many bugs like this we have in kernel... :-/ > > > > Looks like we are too permissive about which VMA is migratable: > > vma_migratable() filters out VMA by VM_IO and VM_PFNMAP. > > I think VM_DONTEXPAND also correlate with VMA which cannot be migrated. > > > > $ git grep VM_DONTEXPAND drivers | grep -v '\(VM_IO\|VM_PFNMAN\)' | wc -l > > 33 > > > > Hm.. :-| > > > > It worth looking on them closely... And I wouldn't be surprised if some > > VMAs without all of these flags are not migratable too. > > > > Sigh.. Any thoughts? > > Sigh indeed. I think that both VM_DONTEXPAND and VM_DONTDUMP are > pretty good signs that mbind() should not be mucking with this vma. If > such a policy sometimes results in mbind failing to set a policy then > that's not a huge loss - something runs a bit slower maybe. > > I mean, we only really expect mbind() to operate against regular old > anon/pagecache memory, yes? Well, it can work fine too if driver itself uses page tables to find out which pages it should to operate on. I don't think it's a common case.
On 26.1.2016 21:28, Kirill A. Shutemov wrote: > From 396ad132be07a2d2b9ec5d1d6ec9fe2fffe8105e Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> > Date: Tue, 26 Jan 2016 22:59:16 +0300 > Subject: [PATCH] sg: mark VMA as VM_IO to prevent migration > > Reduced testcase: > > #include <fcntl.h> > #include <unistd.h> > #include <sys/mman.h> > #include <numaif.h> > > #define SIZE 0x2000 > > int main() > { > int fd; > void *p; > > fd = open("/dev/sg0", O_RDWR); > p = mmap(NULL, SIZE, PROT_EXEC, MAP_PRIVATE | MAP_LOCKED, fd, 0); > mbind(p, SIZE, 0, NULL, 0, MPOL_MF_MOVE); > return 0; > } > > We shouldn't try to migrate pages in sg VMA as we don't have a way to > update Sg_scatter_hold::pages accordingly from mm core. > > Let's mark the VMA as VM_IO to indicate to mm core that the VMA is > migratable. ^ not migratable. Acked-by: Vlastimil Babka <vbabka@suse.cz> > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Reported-by: Dmitry Vyukov <dvyukov@google.com> > --- > drivers/scsi/sg.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c > index 503ab8b46c0b..5e820674432c 100644 > --- a/drivers/scsi/sg.c > +++ b/drivers/scsi/sg.c > @@ -1261,7 +1261,7 @@ sg_mmap(struct file *filp, struct vm_area_struct *vma) > } > > sfp->mmap_called = 1; > - vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP; > + vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; > vma->vm_private_data = sfp; > vma->vm_ops = &sg_mmap_vm_ops; > return 0; > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c index 503ab8b46c0b..5e820674432c 100644 --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -1261,7 +1261,7 @@ sg_mmap(struct file *filp, struct vm_area_struct *vma) } sfp->mmap_called = 1; - vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_private_data = sfp; vma->vm_ops = &sg_mmap_vm_ops; return 0;