Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero
Hajime Tazaki <[email protected]>
| Newsgroups | org.kernel.vger.linux-fsdevel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
Hello Greg, thank you for your time to look at this patch. On Thu, 13 Aug 2026 21:19:47 +0900, Greg Kroah-Hartman wrote: > > On Thu, Aug 13, 2026 at 03:33:58PM +0900, Hajime Tazaki wrote: > > Upon a private file mapping request to /dev/zero, it calls > > kernel_read() in do_mmap_private(), getting a failure with the message > > like: "kernel reads not supported for file /dev/zero", which is because > > zero_fops defined in drivers/char/mem.c has both .read and .read_iter > > definitions. > > Do you actually use a no-mmu system? yes, and wish to use in future. I'm going to make a long story short; nommu kernel is originally for embedded devices but I wish to use for virtualization. I gave a talk to explain this motivation below (which you also had a keynote remotely). I'm not make a summary for this talk in this email, but am happy to explain again if needed. https://www.netdevconf.info/0x1A/sessions/talk/improving-debuggability-of-nommu-code-with-uml.html https://speakerdeck.com/thehajime/nommu-uml-netdev-0x1a/ > > Even fixing this issue, the map request to /dev/zero works fine without > > errors but the allocated vma isn't marked with anonymous because > > mmap_zero_prepare() isn't called under nommu platform, resulting > > vma_desc_set_anonymous() isn't called either. > > > > This commit fixes those issues by: > > 1) use vfs_iter_read() instead to avoid failure at kernel_read() > > 2) calls .mmap_prepare on private mapping in do_mmap() so that required > > preparations are done even in private mapping. > > > > Cc: Arnd Bergmann <[email protected]> > > Cc: Greg Kroah-Hartman <[email protected]> > > Cc: "Matthew Wilcox (Oracle)" <[email protected]> > > Cc: Jan Kara <[email protected]> > > Cc: Andrew Morton <[email protected]> > > Cc: "Liam R. Howlett" <[email protected]> > > Cc: Lorenzo Stoakes <[email protected]> > > Cc: Vlastimil Babka <[email protected]> > > Cc: Jann Horn <[email protected]> > > Cc: Pedro Falcato <[email protected]> > > Cc: [email protected] > > Cc: [email protected] (open list:PAGE CACHE) > > Fixes: 4d03e3cc5982 ("fs: don't allow kernel reads and writes without iter ops") > > Given the age of this issue, I don't think anyone uses no-mmu systems > anymore :( I tend to agree; nommu systems does have less users than others. but I believe this doesn't mean there are no users. I should also explain more, but I found this issue via a Sashiko review, which pointed me as a different comment, but when I tried to reproduce that case pointed by the review, which is about the use of check `vma->vm_file` v.s., `vma_is_anonymous(vma)`, I found that /dev/zero is not able to map on nommu kernel. https://sashiko.dev/#/patchset/20260710054648.924005-1-thehajime%40gmail.com https://sashiko.dev/#/message/m2cxwvti7z.wl-thehajime%40gmail.com The alternate path of open()=>read() of /dev/zero works fine as it doesn't use kernel_read(). I also understand what you feel from the age of this issue (almost 6 years old), and that is exactly why I start implementing test cases in kselftest, which is currently not able to run (even build) for nommu platforms. This series also includes the extension to kselftest ([4,5,6/6] patches are for that). > > - if (!file) { > > + /* private and file mapping will be marked anonymous later (do_mmap_private()). > > + * and /dev/zero is marked by them at .mmap_prepare, > > + * which should be _before_ this point. > > + */ > > Wrong coding style for the comment, which is very typical of > LLM-generated stuff. Always rewrite the output of these tools to > actually be sane. this is my fault. As I mentioned in the Assisted-by tag, I indeed used an AI review system (which is cubic.dev), but I wrote this comment by my hand. Because I thought this part is not easy to follow and felt that I need additional explanation rather than just showing diff. since checkpatch.pl doesn't complain this, I didn't carefully look at the style of this comment block. I will update this (as well as bunch of comments from Sashiko). thanks, -- Hajime