[5/5] fix rootfstype=tmpfs

  Wire up rootfstype=tmpfs to force rootfs to be tmpfs even when you specify root=

Initramfs automatically uses tmpfs (if available) when you DON'T specify a
root= fallback root to mount over initramfs, but some people can't NOT do
that for some reason (old bootloaders), so let rootfstype=tmpfs override it.

My original code tried to do this 10 years ago but got the test wrong,
and nobody's corrected it since, so here you go...

Signed-off-by: Rob Landley <rob@landley.net>

See https://lkml.iu.edu/hypermail/linux/kernel/2207.3/06939.html
---
 init/do_mounts.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
  

On 2/21/23 16:04, Rob Landley wrote:
> Wire up rootfstype=tmpfs to force rootfs to be tmpfs even when you specify root=
> 
> Initramfs automatically uses tmpfs (if available) when you DON'T specify a
> root= fallback root to mount over initramfs, but some people can't NOT do
> that for some reason (old bootloaders), so let rootfstype=tmpfs override it.
> 
> My original code tried to do this 10 years ago but got the test wrong,
> and nobody's corrected it since, so here you go...
> 
> Signed-off-by: Rob Landley <rob@landley.net>

I would like to be able to have this for some work with OpenBMC and 
ideally it would propagate to one of the recent kernels with a Fixes tag 
like this?

Fixes: 6e19eded3684 ("initmpfs: use initramfs if rootfstype= or root= 
specified")

Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>

> 
> See https://lkml.iu.edu/hypermail/linux/kernel/2207.3/06939.html
> ---
>   init/do_mounts.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index 811e94daf0a8..01d80fb828fd 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -665,7 +665,7 @@ struct file_system_type rootfs_fs_type = {
>   
>   void __init init_rootfs(void)
>   {
> -	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
> -		(!root_fs_names || strstr(root_fs_names, "tmpfs")))
> +	if (IS_ENABLED(CONFIG_TMPFS) && (!root_fs_names ? !saved_root_name[0] :
> +		!!strstr(root_fs_names, "tmpfs")))
>   		is_tmpfs = true;
>   }
  

On 11/1/23 09:10, Stefan Berger wrote:
> 
> 
> On 2/21/23 16:04, Rob Landley wrote:
>> Wire up rootfstype=tmpfs to force rootfs to be tmpfs even when you 
>> specify root=
>>
>> Initramfs automatically uses tmpfs (if available) when you DON'T 
>> specify a
>> root= fallback root to mount over initramfs, but some people can't NOT do

can't NOT -> cannot

>> that for some reason (old bootloaders), so let rootfstype=tmpfs 
>> override it.
>>
>> My original code tried to do this 10 years ago but got the test wrong,
>> and nobody's corrected it since, so here you go...

I think this sentence can be dropped.

>>
>> Signed-off-by: Rob Landley <rob@landley.net>
> 
> I would like to be able to have this for some work with OpenBMC and 
> ideally it would propagate to one of the recent kernels with a Fixes tag 
> like this?
> 

Can you repost this patch or should I do it?

Regards,
    Stefan

> Fixes: 6e19eded3684 ("initmpfs: use initramfs if rootfstype= or root= 
> specified")
> 
> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
> Tested-by: Stefan Berger <stefanb@linux.ibm.com>


> 
>>
>> See https://lkml.iu.edu/hypermail/linux/kernel/2207.3/06939.html
>> ---
>>   init/do_mounts.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/init/do_mounts.c b/init/do_mounts.c
>> index 811e94daf0a8..01d80fb828fd 100644
>> --- a/init/do_mounts.c
>> +++ b/init/do_mounts.c
>> @@ -665,7 +665,7 @@ struct file_system_type rootfs_fs_type = {
>>   void __init init_rootfs(void)
>>   {
>> -    if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
>> -        (!root_fs_names || strstr(root_fs_names, "tmpfs")))
>> +    if (IS_ENABLED(CONFIG_TMPFS) && (!root_fs_names ? 
>> !saved_root_name[0] :
>> +        !!strstr(root_fs_names, "tmpfs")))
>>           is_tmpfs = true;
>>   }
  

On 11/8/23 16:05, Stefan Berger wrote:
> On 11/1/23 09:10, Stefan Berger wrote:
>> On 2/21/23 16:04, Rob Landley wrote:
>>> Wire up rootfstype=tmpfs to force rootfs to be tmpfs even when you 
>>> specify root=
>>>
>>> Initramfs automatically uses tmpfs (if available) when you DON'T 
>>> specify a
>>> root= fallback root to mount over initramfs, but some people can't NOT do
> 
> can't NOT -> cannot

The double negative was intentional for emphasis, hence the capitalization. They
are unable to refrain from doing. "Could you just... not do that?" "No, I cannot
not do that."

But if you want to phrase it differently, go ahead.

>>> that for some reason (old bootloaders), so let rootfstype=tmpfs 
>>> override it.
>>>
>>> My original code tried to do this 10 years ago but got the test wrong,
>>> and nobody's corrected it since, so here you go...
> 
> I think this sentence can be dropped.

If you like.

>>>
>>> Signed-off-by: Rob Landley <rob@landley.net>
>> 
>> I would like to be able to have this for some work with OpenBMC and 
>> ideally it would propagate to one of the recent kernels with a Fixes tag 
>> like this? 
> 
> Can you repost this patch or should I do it?

They're more likely to listen to you.

Rob
  

On 11/9/23 10:42, Rob Landley wrote:
> On 11/8/23 16:05, Stefan Berger wrote:
>> Can you repost this patch or should I do it?
> 
> They're more likely to listen to you.

P.S. I have a pile of local kernel patches (accidentally attached to the
_previous_ message, but decided this part was not good to post to lkml) that
I've despaired of upstream ever being interested in, and have "rebase/test them
all on 6.6 kernel for the ~dozen architectures I track"
(https://landley.net/bin/mkroot/latest/) as a local todo item I haven't gotten
to yet. It's on the "list of things I feel guilty about not having done yet".
Speaking of which:

Hi Andrew! I'm sorry I didn't reply to your last email on the list (and instead
just blogged about it, https://landley.net/notes-2023.html#24-02-2023 and
blogged about feeling guilty about still having not replied on April 11 and June
25), but is I cc'd the people scripts/get_maintainer.pl said to, and if that's
no longer enough I don't even _pretend_ to understand the process here anymore,
but don't know how to say that without being political.

Take this reposting thing: clearly you HAVE the patch. That's not the issue. And
it's not a The-SCO-Lawsuit-scared-us-by: permission-to-use issue either, because
I posted it to the list with all the paperwork filled out as best I know how,
which I _think_ was recently acknowledged by the person multiple steps up the
chain of the approval process.

I'm _guessing_ the issue here is the need to refile the paperwork to officially
restart a multi-step bureaucratic process, with nothing actually having changed
since last time that I can tell. Possibly just put the expired form back in the
inbox and let literally the same one go through again like a janky dollar bill
scanner.

I'm very bad at sticking the form in the slot and hoping someone will eventually
see it, with the form getting lost vs being denied looking exactly the same for
an indeterminate period of time. I travel to places in person and wait in long
lines and show ID to get to talk to a human where possible. Linux-kernel hasn't
really provided that option for quite a while.

And I didn't want to say _that_ either. It seems impolite. You are full-time
kernel developers, and I am not. I'm not here to criticize your process, I've
just been unable to meaningfully participate in the impersonal bureaucracy it's
become since... I think I gave up in 2017? https://lkml.org/lkml/2017/9/17/1 is
still in my patch list. I'd happily drop it if upstream had fixed it a different
way, but it's been 8 years. That "all bugs are shallow" open source code review
stuff demonstrably stopped working for this project quite some time ago.

Rob
  

On 11/9/23 10:46, Rob Landley wrote:
> On 11/9/23 10:42, Rob Landley wrote:
>> On 11/8/23 16:05, Stefan Berger wrote:
>>> Can you repost this patch or should I do it?
>> 
>> They're more likely to listen to you.
> 
> P.S. I have a pile of local kernel patches (accidentally attached to the
> _previous_ message, but decided this part was not good to post to lkml)

Thank you, Thunderbird, for not actually updating the "to" list with changes
you've made until you click away to give focus to a different GUI field, and
clicking "send" does not count.

Rob