linux-kernel - Re: log spammed with "loading xx failed with error -2" since commit e40ba6d56b [replace call to fw_read_file

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Feb 2016 09:07:27 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	Kees Cook <keescook@...omium.org>,
	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	James Morris <jmorris@...ei.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: log spammed with "loading xx failed with error -2" since commit
 e40ba6d56b [replace call to fw_read_file_contents() with kernel version]

On Mon, Feb 29, 2016 at 4:57 AM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
> On Sun, Feb 28, 2016 at 10:10:57PM +0800, Ming Lei wrote:


>
> OK then this:
>
> From e63d19975787c0e237a47c17efd01e41b2a8e2fa Mon Sep 17 00:00:00 2001
> From: "Luis R. Rodriguez" <mcgrof@...nel.org>
> Date: Sat, 27 Feb 2016 14:58:08 -0800
> Subject: [PATCH] firmware: change kernel read fail to dev_dbg()
>
> When we now use the new kernel_read_file_from_path() we
> are reporting a failure when we iterate over all the paths
> possible for firmware. Before using kernel_read_file_from_path()
> we only reported a failure once we confirmed a file existed
> with filp_open() but failed with fw_read_file_contents().
>
> With kernel_read_file_from_path() both are done for us and
> we obviously are now reporting too much information given that
> some optional paths will always fail and clutter the logs.
>
> fw_get_filesystem_firmware() already has a check for failure
> and uses an internal flag, FW_OPT_NO_WARN, but this does not
> let us capture other unxpected errors. This enables that
> as changed by Neil via commit:
>
> "firmware: Be a bit more verbose about direct firmware loading failure"
>
> Reported-by: Heiner Kallweit <hkallweit1@...il.com>
> Cc: Neil Horman <nhorman@...driver.com>
> Cc: Heiner Kallweit <hkallweit1@...il.com>
> Cc: Mimi Zohar <zohar@...ux.vnet.ibm.com>
> Cc: Kees Cook <keescook@...omium.org>
> Signed-off-by: Luis R. Rodriguez <mcgrof@...nel.org>
> ---
>  drivers/base/firmware_class.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 1cff832ab74e..9503a88b189b 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -328,8 +328,12 @@ static int fw_get_filesystem_firmware(struct device *device,
>                 rc = kernel_read_file_from_path(path, &buf->data, &size,
>                                                 INT_MAX, READING_FIRMWARE);
>                 if (rc) {
> -                       dev_warn(device, "loading %s failed with error %d\n",
> -                                path, rc);
> +                       if (rc == -ENOENT)
> +                               dev_dbg(device, "loading %s failed with error %d\n",
> +                                        path, rc);
> +                       else
> +                               dev_warn(device, "loading %s failed with error %d\n",
> +                                        path, rc);
>                         continue;
>                 }
>                 dev_dbg(device, "direct-loading %s\n", buf->fw_id);

Acked-by: Ming Lei <ming.lei@...onical.com>

Thanks,