From: Pedro Falcato <pfalcato@suse.de>
To: Daniel Palmer <daniel@thingy.jp>
Cc: Lorenzo Stoakes <ljs@kernel.org>,
akpm@linux-foundation.org, liam@infradead.org,
vbabka@kernel.org, jannh@google.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mm/nommu: Implement just enough vmap that compressed erofs can be mounted
Date: Wed, 20 May 2026 21:45:22 +0200 [thread overview]
Message-ID: <ag4OcGs7SkJAYsby@pedro-suse> (raw)
In-Reply-To: <CAFr9PXnAMAAwnPkY=KJjSmpE5w+daoTo+zKkOFwaGq7yZTq0=g@mail.gmail.com>
On Thu, May 21, 2026 at 02:22:25AM +0900, Daniel Palmer wrote:
> Hi Lorenzo, (and Pedro),
>
> On Thu, 21 May 2026 at 02:05, Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > For some reason this iddn't arrive in my inbox properly... strange? Maybe
> > missing To:?
>
> Sorry, I CC'd everyone hoping I wouldn't get grilled for the silly patch.
>
> > > Did I miss anything massive that is going to come back and bite me?
> > > Maybe it would have made more sense just to change the erofs
> > > code so on !CONFIG_MMU it doesn't use vmap?
> >
> > I think that'd probably be better honestly. I think faking out vmalloc is more
> > trouble than it's worth, and it'd probably have to be everything-or-nothing.
>
> That makes sense.
> Do you think it'd be acceptable to maybe return NULL from these
> functions instead of crashing the kernel?
I suspect the reason for this is simple: calling these functions in !mmu
configs is a programming mistake, and we want it to blow up loudly instead
of having slightly/very broken behavior.
Maybe in 2026 we'd have picked WARN_ON() + return NULL. But I don't think
it makes too much sense here, honestly.
>
> > But yeah would gently point you towards doing something on the fs end I think
> > here :)
>
> Noted. I think I'll at least send them a patch to make compression
> support depend on CONFIG_MMU.
Awesome! (note: since you're space restricted you may actually want that
compression :p)
--
Pedro
prev parent reply other threads:[~2026-05-20 19:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 16:34 [RFC PATCH] mm/nommu: Implement just enough vmap that compressed erofs can be mounted Daniel Palmer
2026-05-20 17:00 ` Pedro Falcato
2026-05-20 17:05 ` Lorenzo Stoakes
2026-05-20 17:22 ` Daniel Palmer
2026-05-20 19:45 ` Pedro Falcato [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ag4OcGs7SkJAYsby@pedro-suse \
--to=pfalcato@suse.de \
--cc=akpm@linux-foundation.org \
--cc=daniel@thingy.jp \
--cc=jannh@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox