netdev - Re: [PATCH net-next 0/4] net: ipa: kill IPA

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: <5b97f7b1-f65f-617e-61b4-2fdc5f08bc3e@linaro.org>
Date:   Tue, 27 Jul 2021 07:34:41 -0500
From:   Alex Elder <elder@...aro.org>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     davem@...emloft.net, kuba@...nel.org, bjorn.andersson@...aro.org,
        evgreen@...omium.org, cpratapa@...eaurora.org,
        subashab@...eaurora.org, elder@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 0/4] net: ipa: kill IPA_VALIDATION

On 7/27/21 6:16 AM, Leon Romanovsky wrote:
> On Mon, Jul 26, 2021 at 12:40:06PM -0500, Alex Elder wrote:
>> A few months ago I proposed cleaning up some code that validates
>> certain things conditionally, arguing that doing so once is enough,
>> thus doing so always should not be necessary.
>>   https://lore.kernel.org/netdev/20210320141729.1956732-1-elder@linaro.org/
>> Leon Romanovsky felt strongly that this was a mistake, and in the
>> end I agreed to change my plans.
> 
> <...>
> 
>> The second patch fixes a bug that wasn't normally exposed because of
>> the conditional compilation (a reason Leon was right about this).
> 
> Thanks Alex,
> 
> If you want another anti pattern that is very popular in netdev, the following pattern is
> wrong by definition :):
> if (WARN_ON(...))
>   return ...

I understand this reasoning.

I had it return an error if the WARN_ON() condition was true in cases
where the function returned a value and callers already handled errors.
I looked back at the patch and here is one of those cases:

gsi_channel_trans_alloc()
- If too many TREs are requested we do not want to allocate them
  from the pool, or it will cause further breakage.  By returning
  early, no transaction will be filled or committed, and an error
  message will (often) be reported, which will indicate the source
  of the error.  If any error occurs during initialization, we fail
  that whole process and everything should be cleaned up.  So in
  this case at least, returning if this ever occurred is better
  than allowing control to continue into the function.

In any case I take your point.  I will now add to my task list
a review of these spots.  I'd like to be sure an error message
*is* reported at an appropriate level up the chain of callers so
I can always identify the culprit in the a WARN_ON() fires (even
though it should never
 happen).  And in each case I'll evaluate
whether returning is better than not.

Thanks.

					-Alex

> The WARN_*() macros are intended catch impossible flows, something that
> shouldn't exist. The idea that printed stack to dmesg and return to the
> caller will fix the situation is a very naive one. That stack already
> says that something very wrong in the system.
> 
> If such flow can be valid use "if(...) return ..", if not use plain
> WARN_ON(...).
> 
> Thanks
>