Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [PATCH 3/3] ext4: clean up error handling in __ext4_fill_super()
To:     Theodore Ts'o <tytso@mit.edu>,
        Ext4 Developers List <linux-ext4@vger.kernel.org>
CC:     Andreas Dilger <adilger@dilger.ca>
References: <20230428031602.242297-1-tytso@mit.edu>
 <20230428031602.242297-4-tytso@mit.edu>
From:   Jason Yan <yanaijie@huawei.com>
Message-ID: <674b4a87-6367-46c9-61de-af3b3db2de66@huawei.com>
Date:   Fri, 28 Apr 2023 14:08:22 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <20230428031602.242297-4-tytso@mit.edu>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2023/4/28 11:16, Theodore Ts'o wrote:
> There were two ways to return an error code; one was via setting the
> 'err' variable, and the second, if err was zero, was via the 'ret'
> variable.  This was both confusing and fragile, and when code was
> factored out of __ext4_fill_super(), some of the error codes returned
> by the original code was replaced by -EINVAL, and in one case, the
> error code was placed by 0, triggering a kernel null pointer
> dereference.
> 
> Clean this up by removing the 'ret' variable, leaving only one way to
> setfthe error code to be returned, and restore the errno codes that

setfthe -> set the? Otherwise looks good to me:

Reviewed-by: Jason Yan <yanaijie@huawei.com>