Messages in this thread |  | | | From | KOSAKI Motohiro <> | | Subject | Re: [PATCH] mlock: revert the optimization for dirtying pages and triggering writeback. | | Date | Mon, 31 Jan 2011 20:43:14 +0900 (JST) |
| |
> On Sat, Jan 29, 2011 at 11:15 PM, Tao Ma <tm@tao.ma> wrote: > > buf = mmap(NULL, file_len, PROT_WRITE, MAP_SHARED, fd, 0); > > if (buf == MAP_FAILED) { > > perror("mmap"); > > goto out; > > } > > > > if (mlock(buf, file_len) < 0) { > > perror("mlock"); > > goto out; > > } > > Thanks Tao for tracing this to an individual change. I can reproduce > this on my system. The issue is that the file is mapped without the > PROT_READ permission, so mlock can't fault in the pages. Up to 2.6.37 > this worked because mlock was using a write. > > The test case does show there was a behavior change; however it's not > clear to me that the tested behavior is valid. > > I can see two possible resolutions:
Please don't ignore bug port anytime.
> 1- do nothing, if we can agree that the test case is invalid > > 2- restore the previous behavior for writable, non-readable, shared > mappings while preserving the optimization for read/write shared > mappings. The test would then look like: > if ((vma->vm_flags & VM_WRITE) && (vma->vm_flags & (VM_READ | > VM_SHARED)) != VM_SHARED) > gup_flags |= FOLL_WRITE;
Maybe two separate conditiions are cleaner more. Like this,
/* * We want to touch writable mappings with a write fault in order * to break COW, except for shared mappings because these don't COW * and we would not want to dirty them for nothing. */ if ((vma->vm_flags & (VM_WRITE | VM_SHARED)) == VM_WRITE) gup_flags |= FOLL_WRITE; /* * We don't have writable permission. Therefore we can't use read operation * even though it's faster. */ if ((vma->vm_flags & (VM_READ|VM_WRITE)) == VM_WRITE) gup_flags |= FOLL_WRITE;
Thanks.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |