[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210902055635.GA17629@duo.ucw.cz>
Date: Thu, 2 Sep 2021 07:56:35 +0200
From: Pavel Machek <pavel@...x.de>
To: "Keller, Jacob E" <jacob.e.keller@...el.com>
Cc: Pavel Machek <pavel@...x.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
"Brelinski, TonyX" <tonyx.brelinski@...el.com>,
"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
Jakub Kicinski <kuba@...nel.org>,
Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.10 026/103] ice: do not abort devlink info if board
identifier cant be found
Hi!
> >>> The devlink dev info command reports version information about the
> >>> device and firmware running on the board. This includes the "board.id"
> >>> field which is supposed to represent an identifier of the board design.
> >>> The ice driver uses the Product Board Assembly identifier for this.
> >>>
> >>> In some cases, the PBA is not present in the NVM. If this happens,
> >>> devlink dev info will fail with an error. Instead, modify the
> >>> ice_info_pba function to just exit without filling in the context
> >>> buffer. This will cause the board.id field to be skipped. Log a dev_dbg
> >>> message in case someone wants to confirm why board.id is not showing up
> >>> for them.
> >>
> >> Will it cause field to be skipped? I believe buffer will not be
> >> initialized which will result in some confusion...
> >
> > IOW I believe this is good idea.
>
> It's not necessary, but I agree its not obvious without the full
> context. The caller of ice_info_pba memsets the buffer before calling
> each info reporter. Its already a known semantics that leaving the
> buffer alone will skip the entry.
>
> See the code below for what we do.
>
> > memset(ctx->buf, 0, sizeof(ctx->buf));
> >
> > err = ice_devlink_versions[i].getter(pf, ctx);
> > if (err) {
> > NL_SET_ERR_MSG_MOD(extack, "Unable to obtain version info");
> > goto out_free_ctx;
> > }
That memset is not present in 5.10 I was reviewing. I agree that
backporting the memset to 5.10 is better then my patch.
> We memset the buffer, call the getter, and if that doesn't modify the
> buffer, we call the fallack, and then check again if its still empty.
>
> Because we memset each time, we don't need to assign *buf = 0.
>
> I guess its more clear that we're doing the correct thing here, but
> these functions are build-for-purpose to use as pointers in this API and
> aren't public, so I think it is fine to leave it as is.
Yes, code is okay in mainline, but the memset is not present in
5.10-stable.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists