linux-kernel - Re: [PATCH v1] ieee802154: at86rf230: Simplify with dev_err

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: <20240830183337.GF1368797@kernel.org>
Date: Fri, 30 Aug 2024 19:33:37 +0100
From: Simon Horman <horms@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Shen Lichuan <shenlichuan@...o.com>, alex.aring@...il.com,
	stefan@...enfreihafen.org, miquel.raynal@...tlin.com,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, linux-wpan@...r.kernel.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	opensource.kernel@...o.com
Subject: Re: [PATCH v1] ieee802154: at86rf230: Simplify with dev_err_probe()

On Fri, Aug 30, 2024 at 08:27:02PM +0200, Krzysztof Kozlowski wrote:
> On 30/08/2024 20:16, Simon Horman wrote:
> > On Fri, Aug 30, 2024 at 07:43:30PM +0200, Krzysztof Kozlowski wrote:
> >> On 30/08/2024 18:02, Simon Horman wrote:
> >>> On Fri, Aug 30, 2024 at 04:14:02PM +0800, Shen Lichuan wrote:
> >>>> Use dev_err_probe() to simplify the error path and unify a message
> >>>> template.
> >>>>
> >>>> Using this helper is totally fine even if err is known to never
> >>>> be -EPROBE_DEFER.
> >>>>
> >>>> The benefit compared to a normal dev_err() is the standardized format
> >>>> of the error code, it being emitted symbolically and the fact that
> >>>> the error code is returned which allows more compact error paths.
> >>>>
> >>>> Signed-off-by: Shen Lichuan <shenlichuan@...o.com>
> >>>
> >>> ...
> >>>
> >>>> @@ -1576,9 +1574,8 @@ static int at86rf230_probe(struct spi_device *spi)
> >>>>  
> >>>>  	lp->regmap = devm_regmap_init_spi(spi, &at86rf230_regmap_spi_config);
> >>>>  	if (IS_ERR(lp->regmap)) {
> >>>> -		rc = PTR_ERR(lp->regmap);
> >>>> -		dev_err(&spi->dev, "Failed to allocate register map: %d\n",
> >>>> -			rc);
> >>>> +		dev_err_probe(&spi->dev, PTR_ERR(lp->regmap),
> >>>> +			      "Failed to allocate register map\n");
> >>>>  		goto free_dev;
> >>>
> >>> After branching to dev_free the function will return rc.
> >>> So I think it still needs to be set a in this error path.
> >>
> >> Another bug introduced by @vivo.com.
> >>
> >> Since ~2 weeks there is tremendous amount of trivial patches coming from
> >> vivo.com. I identified at least 5 buggy, where the contributor did not
> >> understand the code.
> >>
> >> All these "trivial" improvements should be really double-checked.
> > 
> > Are you concerned about those that have been accepted?
> 
> Yes, both posted and accepted. I was doing brief review (amazingly
> useless 2 hours...) what's on the list and so far I think there are 6
> cases of wrong/malicious dev_err_probe(). One got accepted, I sent a revert:
> https://lore.kernel.org/all/20240830170014.15389-1-krzysztof.kozlowski@linaro.org/

Thanks, I see that.

> But the amount of flood from vivo.com started somehow around 20th of
> August (weirdly after I posted set of cleanups and got review from
> Jonathan...), is just over-whelming. And many are just ridiculously
> split, like converting one dev_err->dev_err_probe in the driver, leaving
> rest untouched.

Yes, I have also noticed a significant number of patches.

> I think this was some sort of trivial automation, thus none of the
> patches were actually reviewed before posting.

Interesting theory.