linux-kernel - Re: [PATCH v3] firmware: log name & outcome of loaded firmware

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] [day] [month] [year] [list]

Message-ID: <20191118175312.GA602012@kroah.com>
Date:   Mon, 18 Nov 2019 18:53:12 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Robin H. Johnson" <robbat2@...too.org>
Cc:     mcgrof@...nel.org, linux-kernel@...r.kernel.org, sir@...wn.com,
        ~sircmpwn/public-inbox@...ts.sr.ht, rafael@...nel.org
Subject: Re: [PATCH v3] firmware: log name & outcome of loaded firmware

On Sun, Nov 17, 2019 at 03:47:34PM -0800, Robin H. Johnson wrote:
> It's non-trivial to figure out names of firmware that was actually
> loaded, add a debug statement at the end of _request_firmware that logs
> the name & result of each firmware.
> 
> This is esp. valuable early in boot, before logging of UEVENT is
> available.
> 
> v3:
> - Log at dev_dbg level per maintainer.
> - HOWTO: Enable at boot via kernel boot param
>   dyndbg="func _request_firmware +p"
> - Credit to Drew DeVault for parallel creation and help promoting the
>   idea.

These "v3.." lines need to go below the --- line.

> 
> Alternate-Creation: Drew DeVault <sir@...wn.com>

Is that a valid tag?  You can have co-developed-by (or something like
that, read the documentation for the real name), but I have never seen
this one before.

> Signed-off-by: Robin H. Johnson <robbat2@...too.org>
> ---
>  drivers/base/firmware_loader/main.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
> index bf44c79beae9..84a879608ca4 100644
> --- a/drivers/base/firmware_loader/main.c
> +++ b/drivers/base/firmware_loader/main.c
> @@ -791,6 +791,13 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
>  		fw = NULL;
>  	}
>  
> +	/* Provide a consistent way to capture the result of trying to load any
> +	 * firmware. As a potential future improvement, this might include
> +	 * persistent state that firmware is loaded (or failed to load for some
> +	 * reason). See Message-ID: <20191113205010.GY11244@...do-not-panic.com>

Just provide a lore link with the message id if you really want this.

But really, this type of thing belongs in the changelog text, not in a
comment, right?

> +	 * for background */
> +	dev_dbg(device, "%s %s ret=%d\n", __func__, name, ret);

That does not provide any real information as to what is going on, why
doesn't ftrace suffice for this?

thanks,

greg k-h