public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Hou Tao <houtao1@huawei.com>
To: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2] xfs: add online uevent for mount operation
Date: Fri, 1 Sep 2017 13:11:09 +0800	[thread overview]
Message-ID: <4cc94844-e154-c002-04b8-9e006bad4750@huawei.com> (raw)
In-Reply-To: <20170901020643.GY10621@dastard>

Hi Dave,

On 2017/9/1 10:06, Dave Chinner wrote:
> On Fri, Sep 01, 2017 at 09:26:08AM +0800, Hou Tao wrote:
>> Hi,
>>
>> On 2017/9/1 7:34, Dave Chinner wrote:
>>>>> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
>>>>> index 3a3812b4..6f8351c 100644
>>>>> --- a/fs/xfs/xfs_super.c
>>>>> +++ b/fs/xfs/xfs_super.c
>>>>> @@ -70,6 +70,11 @@ static struct kset *xfs_kset;		/* top-level xfs sysfs dir */
>>>>>  static struct xfs_kobj xfs_dbg_kobj;	/* global debug sysfs attrs */
>>>>>  #endif
>>>>>  
>>>>> +enum {
>>>>> +	XFS_UEVENT_ENV_CNT = 2,
>>>>
>>>> XFS_UEVENT_MAX_ENV_COUNT ?
>>>
>>> Why 2 when there's only one environment string passed?
>> Will fix them, I take the last NULL pointer into account, and
>> Yes, "XFS_UEVENT_MAX_ENV_COUNT" is a better name.
>>
>>>>> +	XFS_UEVENT_UUID_LEN = UUID_STRING_LEN + 6,
>>>
>>> And the magic number needs a comment.
>>>
>>> Actually, I think it needs more than this - it's tightly bound to
>>> the implementation in xfs_fs_uevent(), so this enum should be
>>> defined there, not as a global all this distance away.....
>> OK, I will move it into xfs_fs_uevent().
>>
>>>>> +};
>>>>> +
>>>>>  /*
>>>>>   * Table driven mount option parser.
>>>>>   */
>>>>> @@ -1530,6 +1535,28 @@ xfs_destroy_percpu_counters(
>>>>>  	percpu_counter_destroy(&mp->m_fdblocks);
>>>>>  }
>>>>>  
>>>>> +static void
>>>>> +xfs_fs_uevent(
>>>>> +	struct xfs_mount	*mp,
>>>>> +	enum kobject_action	action)
>>>>> +{
>>>>> +	int err;
>>>>> +	char *envp[XFS_UEVENT_ENV_CNT];
>>>>> +	int i = 0;
>>>
>>> Indent the variables to match the function declaration.
>> I will fix them. I didn't event notice the indentations of these variables before.
>>
>>>>> +
>>>>> +	if (!uuid_is_null(&mp->m_super->s_uuid)) {
>>>
>>> This will never be false. XFS filesystems should always have a valid
>>> UUID.
>> A null uuid is possible if we use "nouuid" to mount a XFS filesystem, so
>> the check is still needed.
> 
> The "nouuid" mount option means "don't check if there is already a
> filesystem ialready mounted with the same uuid as the one we are
> mounting". It does not mean the filesystem does not have a UUID.
> 
> Indeed, in xfs_uuid_mount():
> 
> xfs_uuid_mount(
>         struct xfs_mount        *mp)
> {
>         uuid_t                  *uuid = &mp->m_sb.sb_uuid;
>         int                     hole, i;
> 
>         /* Publish UUID in struct super_block */
>         uuid_copy(&mp->m_super->s_uuid, uuid);
> 
>         if (mp->m_flags & XFS_MOUNT_NOUUID)
>                 return 0;
> 
> We copy the filesystem's uuid into the VFS superblock before we
> check the nouuid mount option flag. Hence a mounted XFS filesystem
> always has a valid UUID in the superblock s_uuid field.
Maybe you miss the following "uuid_is_null(uuid)" check in xfs_uuid_mount() ?

xfs_uuid_mount(
    struct xfs_mount    *mp)
{

    if (mp->m_flags & XFS_MOUNT_NOUUID)
        return 0;

    if (uuid_is_null(uuid)) {
        xfs_warn(mp, "Filesystem has null UUID - can't mount");
        return -EINVAL;
    }

And we can clear the uuid of a XFS filesystem, and mount it with "nouuid" option successfully.
$ xfs_admin -U nil /dev/vda
$ mount -t xfs -o nouuid /dev/vda /tmp/vda

So I still think the null check in xfs_fs_uevent is needed.

Regards,

Tao


  reply	other threads:[~2017-09-01  5:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-31 14:17 [PATCH v2] xfs: add online uevent for mount operation Hou Tao
2017-08-31 15:03 ` Darrick J. Wong
2017-08-31 23:34   ` Dave Chinner
2017-09-01  1:26     ` Hou Tao
2017-09-01  2:06       ` Dave Chinner
2017-09-01  5:11         ` Hou Tao [this message]
2017-09-01 15:20           ` Darrick J. Wong
2017-09-01 21:52             ` Dave Chinner
2017-09-04  0:03               ` Darrick J. Wong
2017-09-04  4:01                 ` Hou Tao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4cc94844-e154-c002-04b8-9e006bad4750@huawei.com \
    --to=houtao1@huawei.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox