lkml.org 
[lkml]   [2022]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 3/9] brcmfmac: firmware: Do not crash on a NULL board_type
From
Date
On 20/01/2022 06.45, Andy Shevchenko wrote:
> On Mon, Jan 17, 2022 at 4:30 PM Hector Martin <marcan@marcan.st> wrote:
>>
>> This unbreaks support for USB devices, which do not have a board_type
>> to create an alt_path out of and thus were running into a NULL
>> dereference.
>
> In v5.16 we have two call sites:
>
> 1.
> if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
> ...
> alt_path = brcm_alt_fw_path(cur->path, fwctx->req->board_type);
>
> 2.
> alt_path = brcm_alt_fw_path(first->path, fwctx->req->board_type);
> if (alt_path) {
> ...
>
> Looking at them I would rather expect to see (as a quick fix, the
> better solution is to unify those call sites by splitting out a common
> helper):
>
> if (fwctx->req->board_type) {
> alt_path = brcm_alt_fw_path(first->path, fwctx->req->board_type);
> else
> alt_path = NULL;
> ...
>

Since brcm_alt_fw_path can fail anyway, and its return value is already
NULL-checked, it makes sense to propagate the NULL board_path there
rather than doing it at all the callsites. That's a common pattern, e.g.
the entire DT API is designed to accept NULL nodes. That does mean that
the first callsite has a redundant NULL check, yes, but that doesn't hurt.

This is all going to change with subsequent patches anyway; the point of
this patch is just to fix the regression.

--
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

\
 
 \ /
  Last update: 2022-09-17 16:12    [W:0.109 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site