linux-kernel - Re: [0/4] overlayfs: Adjustments for ovl_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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1df4916d-421c-4c87-8503-5a36934d03d8@web.de>
Date: Wed, 10 Jan 2024 14:33:04 +0100
From: Markus Elfring <Markus.Elfring@....de>
To: Amir Goldstein <amir73il@...il.com>, linux-unionfs@...r.kernel.org,
 kernel-janitors@...r.kernel.org
Cc: Miklos Szeredi <miklos@...redi.hu>, cocci@...ia.fr,
 LKML <linux-kernel@...r.kernel.org>, Christian Brauner <brauner@...nel.org>
Subject: Re: [0/4] overlayfs: Adjustments for ovl_fill_super()

>>>> See also:
>>>> https://lore.kernel.org/cocci/87b65f8e-abde-2aff-4da8-df6e0b464677@web.de/
>>>> https://sympa.inria.fr/sympa/arc/cocci/2023-03/msg00115.html
>>>
>>> I will queue cleanup patches 1-2,
>>
>> Thanks for this positive feedback.
>
> Sorry, these patches do not apply to master branch and patch 1
> is no longer correct in master branch and the new mount api changes.

Do you want that I adapt the linked development ideas to the current situation
a bit more?


>>>                                   but I do not like patches 3/4 and 4/4.
>>> I do not think that they make the code better to read or maintain.
>>
>> I would appreciate if the details for such change reluctance can be clarified better.
>
> patch 3:
> I much rather a single error handling label that takes care of
> all the cleanups - it is harder to make mistakes and jump to
> the wrong label when adding new error conditions.

There are different coding style preferences involved.

See also:
https://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consider+using+a+goto+chain+when+leaving+a+function+on+error+when+using+and+releasing+resources


> patch 4:
> Overlayfs uses this coding style all over the place
>
>   err = -ENOMEM;
>   ofs->creator_cred = cred = prepare_creds();
>   if (!cred)
>       goto out_free_ofs;
>
> I don't see the benefit in making err = -ENOMEM conditional.
> I don't see the style after your patch as clearly better than before.

Can it be nicer to set error codes only in exceptional data processing situations?

Regards,
Markus