linux-ext4 - Re: [PATCH 3/3] ext4: clean up error handling in __ext4_fill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <674b4a87-6367-46c9-61de-af3b3db2de66@huawei.com>
Date:   Fri, 28 Apr 2023 14:08:22 +0800
From:   Jason Yan <yanaijie@...wei.com>
To:     Theodore Ts'o <tytso@....edu>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
CC:     Andreas Dilger <adilger@...ger.ca>
Subject: Re: [PATCH 3/3] ext4: clean up error handling in __ext4_fill_super()

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@...wei.com>