On Fri, 2019-10-04 at 14:57 +0800, Ian Kent wrote: > On Thu, 2019-10-03 at 18:30 -0500, Eric Sandeen wrote: > > On 10/3/19 5:25 AM, Ian Kent wrote: > > > This patch series add support to xfs for the new kernel mount API > > > as described in the LWN article at > > > https://lwn.net/Articles/780267/ > > > . > > > > > > In the article there's a lengthy description of the reasons for > > > adopting the API and problems expected to be resolved by using > > > it. > > > > > > The series has been applied to the repository located at > > > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git, and built and > > > some simple tests run on it along with the generic xfstests. > > > > > > Other things that continue to cause me concern: > > > > > > - Message logging. > > > > ... > > > > Haven't actually reviewed yet, but just playing with it, I noticed > > an > > oddity; > > > > # mount -o loop,allocsize=abc fsfile mnt > > > > fails as expected, but with no dmesg to be found. Is that a known > > behavior? > > That's interesting. But it's not actually. > > I'll see if I can work out what path that is taking though the > kernel, don't think it's getting to the xfs options handling. In the original xfs code, if there's a failure in xfs_parseargs() such as in this case when suffix_kstrtoint() fails, probably at kstrtoint(), the -EINVAL is returned to xfs_fs_fill_super() which subsequently returns that to the VFS. The VFS itself doesn't log a failure message, it just returns the error to user space. With the patch series applied, xfs_parse_param() does essentially the same thing and because it returns other than -ENOPARAM to the VFS the error is returned, without the VFS logging an error, to user space. There are a few cases in xfs options handling where this happens. The series hasn't tried to change this. > > > -Eric
