Regression in squashfs mount option handling in v5.4

Regression in squashfs mount option handling in v5.4

[Jeremi Piotrowski]

Hi,

I'm working on an embedded project which uses 'rauc' as an updater. rauc mounts
a squashfs image using

  mount -t squashfs -o ro,loop,sizelimit=xxx squashfs.img /mnt

On my system mount is busybox, and busybox does not know the sizelimit
parameter, so it simply passes it on to the mount syscall. The syscall
arguments end up being:

  mount("/dev/loop0", "dir", "squashfs", MS_RDONLY|MS_SILENT, "sizelimit=xxx")

Until kernel 5.4 this worked, since 5.4 this returns EINVAL and dmesg contains
the line "squashfs: Unknown parameter 'sizelimit'". I believe this has to do
with the conversion of squashfs to the new mount api. 

This is an unfortunate regression, and it does not seem like this can be simply
reverted. What is the suggested course of action?

Please cc me on replies, I'm not subscribed to the list.

Thanks,
Jeremi

Re: Regression in squashfs mount option handling in v5.4

[Randy Dunlap]

[adding Cc-s]

On 11/30/19 10:15 AM, Jeremi Piotrowski wrote:
> Hi,
> 
> I'm working on an embedded project which uses 'rauc' as an updater. rauc mounts
> a squashfs image using
> 
>   mount -t squashfs -o ro,loop,sizelimit=xxx squashfs.img /mnt
> 
> On my system mount is busybox, and busybox does not know the sizelimit
> parameter, so it simply passes it on to the mount syscall. The syscall
> arguments end up being:
> 
>   mount("/dev/loop0", "dir", "squashfs", MS_RDONLY|MS_SILENT, "sizelimit=xxx")
> 
> Until kernel 5.4 this worked, since 5.4 this returns EINVAL and dmesg contains
> the line "squashfs: Unknown parameter 'sizelimit'". I believe this has to do
> with the conversion of squashfs to the new mount api. 
> 
> This is an unfortunate regression, and it does not seem like this can be simply
> reverted. What is the suggested course of action?
> 
> Please cc me on replies, I'm not subscribed to the list.
> 
> Thanks,
> Jeremi
> 


-- 
~Randy
Reported-by: Randy Dunlap <rdunlap@infradead.org>

Re: Regression in squashfs mount option handling in v5.4

[Jeremi Piotrowski]

On Sat, Nov 30, 2019 at 10:56:47AM -0800, Randy Dunlap wrote:
> [adding Cc-s]
> 
> On 11/30/19 10:15 AM, Jeremi Piotrowski wrote:
> > Hi,
> > 
> > I'm working on an embedded project which uses 'rauc' as an updater. rauc mounts
> > a squashfs image using
> > 
> >   mount -t squashfs -o ro,loop,sizelimit=xxx squashfs.img /mnt
> > 
> > On my system mount is busybox, and busybox does not know the sizelimit
> > parameter, so it simply passes it on to the mount syscall. The syscall
> > arguments end up being:
> > 
> >   mount("/dev/loop0", "dir", "squashfs", MS_RDONLY|MS_SILENT, "sizelimit=xxx")
> > 
> > Until kernel 5.4 this worked, since 5.4 this returns EINVAL and dmesg contains
> > the line "squashfs: Unknown parameter 'sizelimit'". I believe this has to do
> > with the conversion of squashfs to the new mount api. 
> > 
> > This is an unfortunate regression, and it does not seem like this can be simply
> > reverted. What is the suggested course of action?
> > 
> > Please cc me on replies, I'm not subscribed to the list.
> > 
> > Thanks,
> > Jeremi
> > 
> 
> 
> -- 
> ~Randy
> Reported-by: Randy Dunlap <rdunlap@infradead.org>

Ping. This is preventing me from updating the kernel on my systems.

Re: Regression in squashfs mount option handling in v5.4

[Laura Abbott]

On 12/10/19 1:50 PM, Jeremi Piotrowski wrote:
> On Sat, Nov 30, 2019 at 10:56:47AM -0800, Randy Dunlap wrote:
>> [adding Cc-s]
>>
>> On 11/30/19 10:15 AM, Jeremi Piotrowski wrote:
>>> Hi,
>>>
>>> I'm working on an embedded project which uses 'rauc' as an updater. rauc mounts
>>> a squashfs image using
>>>
>>>    mount -t squashfs -o ro,loop,sizelimit=xxx squashfs.img /mnt
>>>
>>> On my system mount is busybox, and busybox does not know the sizelimit
>>> parameter, so it simply passes it on to the mount syscall. The syscall
>>> arguments end up being:
>>>
>>>    mount("/dev/loop0", "dir", "squashfs", MS_RDONLY|MS_SILENT, "sizelimit=xxx")
>>>
>>> Until kernel 5.4 this worked, since 5.4 this returns EINVAL and dmesg contains
>>> the line "squashfs: Unknown parameter 'sizelimit'". I believe this has to do
>>> with the conversion of squashfs to the new mount api.
>>>
>>> This is an unfortunate regression, and it does not seem like this can be simply
>>> reverted. What is the suggested course of action?
>>>
>>> Please cc me on replies, I'm not subscribed to the list.
>>>
>>> Thanks,
>>> Jeremi
>>>
>>
>>
>> -- 
>> ~Randy
>> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> 
> Ping. This is preventing me from updating the kernel on my systems.
> 

Fedora is hitting a similar issue https://bugzilla.redhat.com/show_bug.cgi?id=1781863

Dec 10 10:04:06 kernel: squashfs: version 4.0 (2009/01/31) Phillip Lougher
Dec 10 10:04:06 kernel: squashfs: Unknown parameter 'errors'

I don't think squashfs ever actually supported the errors parameter
but it was just silently ignored. It turns out you could can pass
whatever nonsense you want for parameters so I don't think we can
reject parameters in the generic case

diff --git a/fs/fs_context.c b/fs/fs_context.c
index 138b5b4d621d..7ec20b1f8a53 100644
--- a/fs/fs_context.c
+++ b/fs/fs_context.c
@@ -160,8 +160,7 @@ int vfs_parse_fs_param(struct fs_context *fc, struct fs_parameter *param)
  		return 0;
  	}
  
-	return invalf(fc, "%s: Unknown parameter '%s'",
-		      fc->fs_type->name, param->key);
+	return 0;
  }
  EXPORT_SYMBOL(vfs_parse_fs_param);