[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4e9e20f3-6908-4969-90ee-8eb6b6d53e3f@gmail.com>
Date: Mon, 28 Apr 2025 14:11:55 +0530
From: "Nirjhar Roy (IBM)" <nirjhar.roy.lists@...il.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: linux-xfs@...r.kernel.org, linux-ext4@...r.kernel.org,
fstests@...r.kernel.org, ritesh.list@...il.com, ojaswin@...ux.ibm.com,
djwong@...nel.org, zlang@...nel.org, david@...morbit.com
Subject: Re: [PATCH v1] xfs: Fail remount with noattr2 on a v5 xfs with
CONFIG_XFS_SUPPORT_V4=y
On 4/25/25 18:35, Christoph Hellwig wrote:
> Hi Nirjhar,
>
> sorry for the delay, I dropped the ball while on vacation.
>
> On Wed, Apr 16, 2025 at 01:05:46PM +0530, Nirjhar Roy (IBM) wrote:
>> Yes, we need a second pass and I think that is already being done by
>> xfs_finish_flags() in xfs_fs_fill_super(). However, in xfs_fs_reconfigure(),
>> we still need a check to make a transition from /* attr2 -> noattr2 */ and
>> /* noattr2 -> attr2 */ (only if it is permitted to) and update
>> mp->m_features accordingly, just like it is being done for inode32 <->
>> inode64, right?
> Yes.
Okay.
>
>> Also, in your previous reply[1], you did suggest moving the
>> crc+noattr2 check to xfs_fs_validate_params() - Are you suggesting to add
>> another optional (NULLable) parameter "new_mp" to xfs_fs_validate_params()
>> and then moving the check to xfs_fs_validate_params()?
> No, let's skip that.
>
> But we really should share the code for the validation. So while a lot
> of the checks in xfs_finish_flags are uselss in remount, it might still
> be a good idea to just use that for the option validation so that we
> don't miss checks in remount.
Okay. I will make the changes in v2. Thank you for your suggestions.
--NR
>
--
Nirjhar Roy
Linux Kernel Developer
IBM, Bangalore
Powered by blists - more mailing lists