On Tue, 2019-06-25 at 07:47 +0800, Ian Kent wrote: > + default: > > > + return invalf(fc, "XFS: unknown mount option [%s].", param- > > > > key); > > > > What do these messages end up looking like in dmesg? > > > > The reason I ask is that today when mount option processing fails we log > > the device name in the error message: > > > > # mount /dev/sda1 /mnt -o gribblegronk > > [64010.878477] XFS (sda1): unknown mount option [gribblegronk]. > > > > AFAICT using invalf (instead of xfs_warn) means that now we don't report > > the device name, and all you'd get is: > > > > "[64010.878477] XFS: unknown mount option [gribblegronk]." > > > > which is not as helpful... > > Yes, I thought that might be seen as a problem. > > The device name was obtained from the super block in the the > original code and the super block isn't available at this > point. > > Not sure what to do about it but I'll have a look. > It turns out that I also made a mistake with the error string. The above would actually print (something like): [64010.878477] xfs: XFS: unknown mount option [gribblegronk]." I can change the case of the struct fs_parameter_description .name and leave out the "XFS" in the error string to fix that. But, because the parameter parsing is done before super block creation, there's no bdev to get a device name from. There should be a source (block device path) filed set in the fs context and I could dup the last component of that or walk the path to resolve symlinks and dup the path dentry d_name which should give (something like) the device name. But the printk %pg format is a bit different in the way it constructs the name from the bdev so it could well be different. That could lead to confusion too. Also, if an error is occurs in the VFS the message won't have the device name either. So I'm not sure what to do about this one, suggestions? Ian
