linux-kernel - Re: [PATCH 1/4] Remove redundant return value check

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: <ZUO7xUuZmIVp06sw@kekkonen.localdomain>
Date:   Thu, 2 Nov 2023 15:09:57 +0000
From:   Sakari Ailus <sakari.ailus@...ux.intel.com>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Alexandra Diupina <adiupina@...ralinux.ru>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andy Shevchenko <andy@...nel.org>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>, linux-media@...r.kernel.org,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
        lvc-project@...uxtesting.org
Subject: Re: [PATCH 1/4] Remove redundant return value check

Hi Hans, Alexandra,

On Thu, Nov 02, 2023 at 03:21:04PM +0100, Hans de Goede wrote:
> Hi Alexandra,
> 
> On 11/2/23 15:11, Alexandra Diupina wrote:
> > media_entity_pads_init() will not return 0 only if the
> > 2nd parameter >= MEDIA_ENTITY_MAX_PADS (512), but 1 is
> > passed, so checking the return value is redundant
> 
> Generally speaking functions which can fail should always be
> error-checked even if their invocation today happen to be
> such that they will not fail.
> 
> Either the invocation or the function itself my change
> causing it to fail in the future. Which is why we want
> to keep the error checks.
> 
> But maybe media_entity_pads_init() is special and
> does not need to be error checked.
> 
> Sakari, Laurent do you have any opinion on this ?
> 
> > Found by Linux Verification Center (linuxtesting.org) with SVACE.
> 
> This feels like a false positive of the tool to me,
> but lets wait and see what Sakari or Laurent have
> to say.

I agree with Hans: this function today may not fail with the parameters
passed to it but it may happen in the future. In general it's good to check
a return value of a function that returns one: if that function is changed,
no-one will go through the callers as long as the arguments and the return
value remain the same.

-- 
Regards,

Sakari Ailus