From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2992723AbcB1ATg (ORCPT ); Sat, 27 Feb 2016 19:19:36 -0500 Received: from e28smtp05.in.ibm.com ([125.16.236.5]:50113 "EHLO e28smtp05.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2992461AbcB1ATf (ORCPT ); Sat, 27 Feb 2016 19:19:35 -0500 X-IBM-Helo: d28relay04.in.ibm.com X-IBM-MailFrom: zohar@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Message-ID: <1456618761.4065.261.camel@linux.vnet.ibm.com> Subject: Re: log spammed with "loading xx failed with error -2" since commit e40ba6d56b [replace call to fw_read_file_contents() with kernel version] From: Mimi Zohar To: "Luis R. Rodriguez" Cc: Heiner Kallweit , James Morris , Ming Lei , Greg Kroah-Hartman , Kees Cook , linux-kernel@vger.kernel.org Date: Sat, 27 Feb 2016 19:19:21 -0500 In-Reply-To: <20160227231559.GW25240@wotan.suse.de> References: <56D1D3A2.70605@gmail.com> <20160227231559.GW25240@wotan.suse.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 16022800-0017-0000-0000-00000A4BEA67 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2016-02-28 at 00:15 +0100, Luis R. Rodriguez wrote: > On Sat, Feb 27, 2016 at 05:49:38PM +0100, Heiner Kallweit wrote: > > Since this commit my system log is spammed with firmware load errors. One example: > > > > loading /lib/firmware/updates/4.5.0-rc5-next-20160226/iwlwifi-3160-16.ucode failed with error -2 > > loading /lib/firmware/updates/iwlwifi-3160-16.ucode failed with error -2 > > loading /lib/firmware/4.5.0-rc5-next-20160226/iwlwifi-3160-16.ucode failed with error -2 > > -> finally load attempt from /lib/firmware/iwlwifi-3160-16.ucode succeeds > > > > Before this commit, when a load from one path in fw_path failed, silently the next path was tried. > > Only if all attempts failed an error message was printed. > > Now for each single failed attempt an error message is printed what doesn't make sense. > > To be clear, this is an issue on linux-next, due to the latest merge > of Mimi's common kernel file loader pulled recently by James. It looks like commit "3e358ac firmware: Be a bit more verbose about direct firmware loading failure", made the change. Then commit ed04630 "firmware: simplify dev_*() print messages for generic helper" modified the message. Mimi > Heiner, thanks for the report, this patch fixes that. I'll be submitting that > now. James, should this go through your tree? Please note I've been meaning to > add myself to MAINTAINERS for FIRMWARE_CLASS as requested by Greg at kernel > summit as I've been helping with cleanup there but I hadn't done so as I had > some pending patches with a full new functionality added. With Mimi's changes > merged on linux-next though and the common kernel file loader now done I can > follow up with my series of changes after this. > > Luis > > From 92e2bd76bf1abb3ce381b8d54ba5486a295af1a9 Mon Sep 17 00:00:00 2001 > From: "Luis R. Rodriguez" > 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, to let users > warn or not warn. For instance request_firmware_direct() > does not warn as this can be used for optional firmware > as it has no usermode helper fallback. In the future we > may want to change this, given everyone is disabling the > usermode helper anyway now, but for now keep reporting > only as was designed. request_firmware_direct() will > continue to not report errors as it was designed not to. > > Reported-by: Heiner Kallweit > Cc: Heiner Kallweit > Cc: Mimi Zohar > Cc: Kees Cook > Signed-off-by: Luis R. Rodriguez > --- > drivers/base/firmware_class.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c > index 1cff832ab74e..b1cf4d61ffc9 100644 > --- a/drivers/base/firmware_class.c > +++ b/drivers/base/firmware_class.c > @@ -328,7 +328,7 @@ 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", > + dev_dbg(device, "loading %s failed with error %d\n", > path, rc); > continue; > }