Re: [PATCH v4 00/17] xfs: mount API patch series

[Eric Sandeen <sandeen@sandeen.net>]

On 10/4/19 3:25 AM, Ian Kent wrote:
> 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.
> 

Oh, crud, I see now that it's the same upstream.  :(  Sorry for the noise.

-Eric