Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v2] f2fs: use EINVAL for superblock with invalid magic
To:     Icenowy Zheng <icenowy@aosc.io>, Jaegeuk Kim <jaegeuk@kernel.org>
CC:     <linux-f2fs-devel@lists.sourceforge.net>,
        <linux-kernel@vger.kernel.org>
References: <20190725030852.33161-1-icenowy@aosc.io>
From:   Chao Yu <yuchao0@huawei.com>
Message-ID: <07060e23-bc6f-5d35-a7f3-e75c8ebb3b65@huawei.com>
Date:   Thu, 25 Jul 2019 11:15:01 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20190725030852.33161-1-icenowy@aosc.io>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2019/7/25 11:08, Icenowy Zheng wrote:
> The kernel mount_block_root() function expects -EACESS or -EINVAL for a
> unmountable filesystem when trying to mount the root with different
> filesystem types.
> 
> However, in 5.3-rc1 the behavior when F2FS code cannot find valid block
> changed to return -EFSCORRUPTED(-EUCLEAN), and this error code makes
> mount_block_root() fail when trying to probe F2FS.
> 
> When the magic number of the superblock mismatches, it has a high
> probability that it's just not a F2FS. In this case return -EINVAL seems
> to be a better result, and this return value can make mount_block_root()
> probing work again.
> 
> Return -EINVAL when the superblock has magic mismatch, -EFSCORRUPTED in
> other cases (the magic matches but the superblock cannot be recognized).
> 
> Fixes: 10f966bbf521 ("f2fs: use generic EFSBADCRC/EFSCORRUPTED")
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Reviewed-by: Chao Yu <yuchao0@huawei.com>

Thanks,