On Thu, Nov 19, 2015 at 02:33:45PM -0800, Shaohua Li wrote: > Hi, > > There is plan to support write protect fault into userfaultfd before, but it's > not implemented yet. I'm working on a library to support different types of > buffer like compressed buffer and file buffer, something like a page cache > implementation in userspace. The buffer enables userfaultfd and does something > like decompression in userfault handler. When memory size exceeds a > threshold, madvise is used to reclaim memory. The problem is data can be > corrupted in reclaim without memory protection support. > > For example, in the compressed buffer case, reclaim does: > 1. compress memory range and store compressed data elsewhere > 2. madvise the memory range > > But if the memory is changed before 2, new change is lost. memory write > protection can solve the issue. With it, the reclaim does: > 1. write protect memory range > 2. compress memory range and store compressed data elsewhere > 3. madvise the memory range > 4. undo write protect memory range and wakeup tasks waiting in write protect > fault. > If a task changes memory before 3, write protect fault will be triggered. we > can put the task into sleep till step 4 runs for example. In this way memory > changes will not be lost. While i understand the whole concept of write protection while doing compression. I do not see valid usecase for this. Inside the kernel we already have thing like zswap that already does what you seem to want to do (ie compress memory range and transparently uncompress it on next CPU access). I fail to see a usecase where we would realy would like to do this in userspace. > > This patch set add write protect support for userfaultfd. One issue is write > protect fault can happen even without enabling write protect in userfault. For > example, a write to address backed by zero page. There is no way to distinguish > if this is a write protect fault expected by userfault. This patch just blindly > triggers write protect fault to userfault if corresponding vma enables > VM_UFFD_WP. Application should be prepared to handle such write protect fault. > > Thanks, > Shaohua > > > Shaohua Li (8): > userfaultfd: add helper for writeprotect check > userfaultfd: support write protection for userfault vma range > userfaultfd: expose writeprotect API to ioctl > userfaultfd: allow userfaultfd register success with writeprotection > userfaultfd: undo write proctection in unregister > userfaultfd: hook userfault handler to write protection fault > userfaultfd: fault try one more time > userfaultfd: enabled write protection in userfaultfd API >From organization point of view, i would put the "expose writeprotect API to ioctl" as the last patch in the serie after all the plumbing is done. This would make "enabled write protection in userfaultfd API" useless and avoid akward changes in some of the others patches where you add commented/disabled code. Also you want to handle GUP, like you want the write protection to fails if there is GUP and you want GUP to force breaking write protection, otherwise this will be broken if anyone mix it with something that trigger GUP. Cheers, Jérôme -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>