> On Jun 19, 2019, at 6:13 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 18 Jun 2019 21:48:16 +0000 Song Liu <songliubraving@xxxxxx> wrote: > >>> I'm wondering if this limitation can be abused in some fashion: mmap a >>> file to which you have read permissions, run madvise(MADV_HUGEPAGE) and >>> thus prevent the file's owner from being able to modify the file? Or >>> something like that. What are the issues and protections here? >> >> In this case, the owner need to make a copy of the file, and then remove >> and update the original file. >> >> In this version, we want either split huge page on writes, or fail the >> write when we cannot split. However, the huge page information is only >> available at page level, and on the write path, page level information >> is not available until write_begin(). So it is hard to stop writes at >> earlier stage. Therefore, in this version, we leverage i_mmap_writable, >> which is at address_space level. So it is easier to stop writes to the >> file. >> >> This is a temporary behavior. And it is gated by the config. So I guess >> it is OK. It works well for our use cases though. Once we have better >> write support, we can remove the limitation. >> >> If this is too weird, I am also open to suggestions. > > Well, it's more than weird? This permits user A to deny service to > user B? User A can, maliciously or accidentally, prevent user B from > modifying a file which user B has permission to modify? Such as, umm, > /etc/hosts? I have removed this behavior in v3. I think we really don't need this. Thanks, Song
