linux-kernel - Re: [alsa-devel] [PATCH] ALSA: ac97c: Fix an error handling path in 'atmel_ac97c

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: <s5h1snsjaey.wl-tiwai@suse.de>
Date:   Thu, 31 Aug 2017 12:31:33 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     "Mark Brown" <broonie@...nel.org>
Cc:     "Alexandre Belloni" <alexandre.belloni@...e-electrons.com>,
        <alsa-devel@...a-project.org>, <garsilva@...eddedor.com>,
        <arvind.yadav.cs@...il.com>, <bhumirks@...il.com>,
        <andriy.shevchenko@...ux.intel.com>, <nicolas.ferre@...rochip.com>,
        <perex@...ex.cz>, <kernel-janitors@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        "Christophe JAILLET" <christophe.jaillet@...adoo.fr>
Subject: Re: [alsa-devel] [PATCH] ALSA: ac97c: Fix an error handling path in 'atmel_ac97c_probe()'

On Thu, 31 Aug 2017 12:19:03 +0200,
Mark Brown wrote:
> 
> On Thu, Aug 31, 2017 at 10:10:21AM +0200, Alexandre Belloni wrote:
> 
> > And here is the fallout of the stupid, brainless "fixing" of issues
> > reported by static analysis tools.
> 
> > This clk_prepare_enable will never fail. If it was going to fail, the
> > platform would never boot to a point were it is able to execute that
> > code. It is really annoying to have so much churn for absolutely 0
> > benefit.
> 
> It may currently be the case that the SoCs you're looking at happen to
> make this clock essential but that doesn't mean that it's not going to
> be different in some future SoC, nor that we can't have a software bug
> that this will detect.  Being consistent with our error checking also
> means that we can spot places where it might practically be a problem
> more easily, it's even easier if the error checking is there first time
> but it's still worth it to go back later.

... yes, but only when it's done correctly.

This is again a typical problem by such a trivial fix patch: the code
looks as if it were trivial and correct, buried in a patch series that
easily leads to the oversight by the maintainer's review.


thanks,

Takashi