[v4,1/1] test_fimware: return -ENOMEM instead of -ENOSPC on failed memory allocation
Message ID | 20230812054346.168223-1-mirsad.todorovac@alu.unizg.hr |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b824:0:b0:3f2:4152:657d with SMTP id z4csp1539645vqi; Fri, 11 Aug 2023 22:57:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEFy4A+AKMWRbprzhJzG6/rKtHxHiWmA0kiP70jXM1JxwOyBZAHDfD+1A8mbGCFcecIu49U X-Received: by 2002:a05:6870:eca0:b0:1c0:219b:17f4 with SMTP id eo32-20020a056870eca000b001c0219b17f4mr4611075oab.5.1691819866076; Fri, 11 Aug 2023 22:57:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691819866; cv=none; d=google.com; s=arc-20160816; b=MpYWwXec9d3twk6+RbuxcFMk+RBzKgNxi4mrzv/TuBA1Vrtyq8e6MrffMm/NvtSV+p OWczRQ+Ph/aQxx9CywSTBVWDfMMBnumRGl9k4toNdHSkZNtg5RYPnNuPv8opLd2d/o7v 6MmaxSdvn7thmbA3cKhe8UidjjyJ6AVdZddY7fDcqJcMTG9j2NUX2s7x03QY1Sf5dQJk dvdeKI/bS0DH1oQg7rlo8+Wpz6MCCQZMBvFNXqAvKBiQAPubiKkLQbl9QJo6lM6w6970 eqnC8qyJ+V5M5PqlEc+0OZyI+WTSgDuAmqDOe3soWrXcPX8eS/xhf768ovW7F3Lk3lGV DKHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature:dkim-signature; bh=9hXTmzMLZ9dCZb8h34mj3Z7s+rYXt96zg1px+JhMdtI=; fh=RV8yYhM1c3saQodyFDnv7ypfdxgbmHytZEV/59A5jn0=; b=WbL7Pw1HkGgSMAFfBq928XUdmWy7HfyySABhnUcnOVHNp997ljkfgwmxaZfthKUjqE tNf4Ltrsh7WSGQJG3hewWwbUJu0969n/U1iK+8wycmIjpgbi4WrfC7RoaBBIlKVuX3zt XEAgJgQF/iToTYEgpZUHPYyXrDV62kgvdHbBvDHmdPsgOA4f3C/Qi2s8wajFZnijXPqV xTu5RMwgx6zNLcb/vvgl3N/xGXCpsjbJb7oXEXh8YhCMF9FVWJJboVbQ3PBdlyFkcnzc aRkID8WhzIfTNi0kZ45cMoD68jkkZokGQ/7nVJ954uRRfXi8paxS+o3/eKn/vfQVOS/M nijA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@alu.unizg.hr header.s=mail header.b=XAcW+GJl; dkim=fail header.i=@alu.unizg.hr header.s=mail header.b=i3gCIaL+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alu.unizg.hr Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s7-20020a634507000000b0056546b5fef6si4431413pga.231.2023.08.11.22.57.33; Fri, 11 Aug 2023 22:57:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@alu.unizg.hr header.s=mail header.b=XAcW+GJl; dkim=fail header.i=@alu.unizg.hr header.s=mail header.b=i3gCIaL+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alu.unizg.hr Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233662AbjHLFqr (ORCPT <rfc822;lanlanxiyiji@gmail.com> + 99 others); Sat, 12 Aug 2023 01:46:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229670AbjHLFqq (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 12 Aug 2023 01:46:46 -0400 Received: from domac.alu.hr (domac.alu.unizg.hr [IPv6:2001:b68:2:2800::3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 963322712; Fri, 11 Aug 2023 22:46:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by domac.alu.hr (Postfix) with ESMTP id 5A0E16015E; Sat, 12 Aug 2023 07:46:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alu.unizg.hr; s=mail; t=1691819203; bh=YZBcXmmJnd5USNFvIod8cr+dIcpfsOLq31FsgTOIxVg=; h=From:To:Cc:Subject:Date:From; b=XAcW+GJlv7E0K+7kajDHdHF7LTeDnB1AUTq43mcSREkdhZYi3tnHwSJORb37gKpOb jJvTic/GjeRhtpsvwHmFIYa6GgwXhM972OFw9kI2q5cFYUyOj3drdPcTE39us7YR5E bIDQBNf/VT/Oq563dSBwQcsvULauOUTaGmN5eE4/7CuVNE8rkml7a8Ve4FUf5ab1S3 OU6SpnNc+PdpNc6dOaJbkKEfr6z2dRkWoyx3Z6rAS/fn2tK89VMyxSYkylScjZYeIA Fj764HFUe45P3d6I+b8LZ3UHEkfy5pS6NeqLLuEdYMCfK8kKMJ0nXlq1A3+SSmBqRC MQ7PZKny/l1vg== X-Virus-Scanned: Debian amavisd-new at domac.alu.hr Received: from domac.alu.hr ([127.0.0.1]) by localhost (domac.alu.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xud7GHiPjFbs; Sat, 12 Aug 2023 07:46:40 +0200 (CEST) Received: from defiant.. (unknown [94.250.191.183]) by domac.alu.hr (Postfix) with ESMTPSA id 821A46015F; Sat, 12 Aug 2023 07:46:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alu.unizg.hr; s=mail; t=1691819200; bh=YZBcXmmJnd5USNFvIod8cr+dIcpfsOLq31FsgTOIxVg=; h=From:To:Cc:Subject:Date:From; b=i3gCIaL+iUSwCLda2vi/oe85P9G1sGUWf8UNZwUrUZ8i/Mr5togCSvC4iV/YwD05e n8xW2pBE92h7L7ZwlfZliMFJuuaeKzQc8eOM4PxWjP8RVW3cU9QDNeL++H9Mf9ezdv ADbCOjA9iN5PDuYzhk4CIeoWKgU9lqoFxbJKDFTp0HphEFWVGn5pkOXSxbb+AvQp9v HUR9uS0v6d31ptiOS/CLFuiHS42PyA9bhg323b/NAvDMvj6n9sLpyGDhWCnllDcKZa HQA4WUQEPB4gBW0yErKeePT070/Iv1RW9Otd76bAM5GVrJysOxHXbFN7VSZ9Ws5Qvv FZ2XUoZ6drotg== From: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr> To: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>, linux-kernel@vger.kernel.org Cc: Dan Carpenter <error27@gmail.com>, Takashi Iwai <tiwai@suse.de>, Kees Cook <keescook@chromium.org>, "Luis R . Rodriguez" <mcgrof@kernel.org>, Brian Norris <computersforpeace@gmail.com>, stable@vger.kernel.org Subject: [PATCH v4 1/1] test_fimware: return -ENOMEM instead of -ENOSPC on failed memory allocation Date: Sat, 12 Aug 2023 07:43:47 +0200 Message-Id: <20230812054346.168223-1-mirsad.todorovac@alu.unizg.hr> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FILL_THIS_FORM,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1774001707767271793 X-GMAIL-MSGID: 1774001707767271793 |
Series |
[v4,1/1] test_fimware: return -ENOMEM instead of -ENOSPC on failed memory allocation
|
|
Commit Message
Mirsad Todorovac
Aug. 12, 2023, 5:43 a.m. UTC
[ Upstream commit 7dae593cd226a0bca61201cf85ceb9335cf63682 ]
In a couple of situations like
name = kstrndup(buf, count, GFP_KERNEL);
if (!name)
return -ENOSPC;
the error is not actually "No space left on device", but "Out of memory".
It is semantically correct to return -ENOMEM in all failed kstrndup()
and kzalloc() cases in this driver, as it is not a problem with disk
space, but with kernel memory allocator failing allocation.
The semantically correct should be:
name = kstrndup(buf, count, GFP_KERNEL);
if (!name)
return -ENOMEM;
Cc: Dan Carpenter <error27@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: stable@vger.kernel.org # 4.14
Fixes: c92316bf8e948 ("test_firmware: add batched firmware tests")
Fixes: 0a8adf584759c ("test: add firmware_class loader test")
Fixes: eb910947c82f9 ("test: firmware_class: add asynchronous request trigger")
Fixes: 061132d2b9c95 ("test_firmware: add test custom fallback trigger")
Link: https://lore.kernel.org/all/20230606070808.9300-1-mirsad.todorovac@alu.unizg.hr/
Signed-off-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>
[ This is the backport of the patch to 4.19 and 4.14 branches. There are no ]
[ semantic differences in the commit. Backport is provided for completenes sake ]
[ so it would apply to all of the supported LTS kernels ]
---
v3 -> v4:
no changes. resubmitting for 4.14 because the patchwork didn't apply to the 4.14 tree.
v2 -> v3:
minor clarifications with the versioning for the patchwork. no change to commit.
v1 -> v2:
removed the Reviewed-by: and Acked-by tags, as this is a slightly different patch and
those need to be reacquired
lib/test_firmware.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Comments
On Sat, Aug 12, 2023 at 07:43:47AM +0200, Mirsad Todorovac wrote: > [ Upstream commit 7dae593cd226a0bca61201cf85ceb9335cf63682 ] > > In a couple of situations like > > name = kstrndup(buf, count, GFP_KERNEL); > if (!name) > return -ENOSPC; > > the error is not actually "No space left on device", but "Out of memory". > > It is semantically correct to return -ENOMEM in all failed kstrndup() > and kzalloc() cases in this driver, as it is not a problem with disk > space, but with kernel memory allocator failing allocation. > > The semantically correct should be: > > name = kstrndup(buf, count, GFP_KERNEL); > if (!name) > return -ENOMEM; > > Cc: Dan Carpenter <error27@gmail.com> > Cc: Takashi Iwai <tiwai@suse.de> > Cc: Kees Cook <keescook@chromium.org> > Cc: Luis R. Rodriguez <mcgrof@kernel.org> > Cc: Brian Norris <computersforpeace@gmail.com> > Cc: stable@vger.kernel.org # 4.14 > Fixes: c92316bf8e948 ("test_firmware: add batched firmware tests") > Fixes: 0a8adf584759c ("test: add firmware_class loader test") > Fixes: eb910947c82f9 ("test: firmware_class: add asynchronous request trigger") > Fixes: 061132d2b9c95 ("test_firmware: add test custom fallback trigger") > Link: https://lore.kernel.org/all/20230606070808.9300-1-mirsad.todorovac@alu.unizg.hr/ > Signed-off-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr> > > [ This is the backport of the patch to 4.19 and 4.14 branches. There are no ] > [ semantic differences in the commit. Backport is provided for completenes sake ] > [ so it would apply to all of the supported LTS kernels ] This commit is already in the 4.19.291 release, does it need to be included in there again for some reason? thanks, greg k-h
On 8/12/23 09:29, Greg KH wrote: > On Sat, Aug 12, 2023 at 07:43:47AM +0200, Mirsad Todorovac wrote: >> [ Upstream commit 7dae593cd226a0bca61201cf85ceb9335cf63682 ] >> >> In a couple of situations like >> >> name = kstrndup(buf, count, GFP_KERNEL); >> if (!name) >> return -ENOSPC; >> >> the error is not actually "No space left on device", but "Out of memory". >> >> It is semantically correct to return -ENOMEM in all failed kstrndup() >> and kzalloc() cases in this driver, as it is not a problem with disk >> space, but with kernel memory allocator failing allocation. >> >> The semantically correct should be: >> >> name = kstrndup(buf, count, GFP_KERNEL); >> if (!name) >> return -ENOMEM; >> >> Cc: Dan Carpenter <error27@gmail.com> >> Cc: Takashi Iwai <tiwai@suse.de> >> Cc: Kees Cook <keescook@chromium.org> >> Cc: Luis R. Rodriguez <mcgrof@kernel.org> >> Cc: Brian Norris <computersforpeace@gmail.com> >> Cc: stable@vger.kernel.org # 4.14 >> Fixes: c92316bf8e948 ("test_firmware: add batched firmware tests") >> Fixes: 0a8adf584759c ("test: add firmware_class loader test") >> Fixes: eb910947c82f9 ("test: firmware_class: add asynchronous request trigger") >> Fixes: 061132d2b9c95 ("test_firmware: add test custom fallback trigger") >> Link: https://lore.kernel.org/all/20230606070808.9300-1-mirsad.todorovac@alu.unizg.hr/ >> Signed-off-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr> >> >> [ This is the backport of the patch to 4.19 and 4.14 branches. There are no ] >> [ semantic differences in the commit. Backport is provided for completenes sake ] >> [ so it would apply to all of the supported LTS kernels ] > > This commit is already in the 4.19.291 release, does it need to be > included in there again for some reason? Hi Mr. Greg, I think the patchwork did not apply the commit to the 4.14 stable tree. Only the 19be3eccd000 ("test_firmware: fix a memory leak with reqs buffer" propagated to 4.14.322. I would like to have us this chapter (backporting) completed before moving on. Kind regards, Mirsad Todorovac
On Sat, Aug 12, 2023 at 10:06:53AM +0200, Mirsad Todorovac wrote: > > > On 8/12/23 09:29, Greg KH wrote: > > On Sat, Aug 12, 2023 at 07:43:47AM +0200, Mirsad Todorovac wrote: > > > [ Upstream commit 7dae593cd226a0bca61201cf85ceb9335cf63682 ] > > > > > > In a couple of situations like > > > > > > name = kstrndup(buf, count, GFP_KERNEL); > > > if (!name) > > > return -ENOSPC; > > > > > > the error is not actually "No space left on device", but "Out of memory". > > > > > > It is semantically correct to return -ENOMEM in all failed kstrndup() > > > and kzalloc() cases in this driver, as it is not a problem with disk > > > space, but with kernel memory allocator failing allocation. > > > > > > The semantically correct should be: > > > > > > name = kstrndup(buf, count, GFP_KERNEL); > > > if (!name) > > > return -ENOMEM; > > > > > > Cc: Dan Carpenter <error27@gmail.com> > > > Cc: Takashi Iwai <tiwai@suse.de> > > > Cc: Kees Cook <keescook@chromium.org> > > > Cc: Luis R. Rodriguez <mcgrof@kernel.org> > > > Cc: Brian Norris <computersforpeace@gmail.com> > > > Cc: stable@vger.kernel.org # 4.14 > > > Fixes: c92316bf8e948 ("test_firmware: add batched firmware tests") > > > Fixes: 0a8adf584759c ("test: add firmware_class loader test") > > > Fixes: eb910947c82f9 ("test: firmware_class: add asynchronous request trigger") > > > Fixes: 061132d2b9c95 ("test_firmware: add test custom fallback trigger") > > > Link: https://lore.kernel.org/all/20230606070808.9300-1-mirsad.todorovac@alu.unizg.hr/ > > > Signed-off-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr> > > > > > > [ This is the backport of the patch to 4.19 and 4.14 branches. There are no ] > > > [ semantic differences in the commit. Backport is provided for completenes sake ] > > > [ so it would apply to all of the supported LTS kernels ] > > > > This commit is already in the 4.19.291 release, does it need to be > > included in there again for some reason? > > Hi Mr. Greg, > > I think the patchwork did not apply the commit to the 4.14 stable tree. > Only the 19be3eccd000 ("test_firmware: fix a memory leak with reqs buffer" propagated to 4.14.322. > > I would like to have us this chapter (backporting) completed before moving on. That's fine, but your comment here said that this is for 4.19, but this is already in 4.19, so I'm confused. I'll queue this up for 4.14.y now... thanks, greg k-h
On 8/12/23 10:12, Greg KH wrote: > On Sat, Aug 12, 2023 at 10:06:53AM +0200, Mirsad Todorovac wrote: >> >> >> On 8/12/23 09:29, Greg KH wrote: >>> On Sat, Aug 12, 2023 at 07:43:47AM +0200, Mirsad Todorovac wrote: >>>> [ Upstream commit 7dae593cd226a0bca61201cf85ceb9335cf63682 ] >>>> >>>> In a couple of situations like >>>> >>>> name = kstrndup(buf, count, GFP_KERNEL); >>>> if (!name) >>>> return -ENOSPC; >>>> >>>> the error is not actually "No space left on device", but "Out of memory". >>>> >>>> It is semantically correct to return -ENOMEM in all failed kstrndup() >>>> and kzalloc() cases in this driver, as it is not a problem with disk >>>> space, but with kernel memory allocator failing allocation. >>>> >>>> The semantically correct should be: >>>> >>>> name = kstrndup(buf, count, GFP_KERNEL); >>>> if (!name) >>>> return -ENOMEM; >>>> >>>> Cc: Dan Carpenter <error27@gmail.com> >>>> Cc: Takashi Iwai <tiwai@suse.de> >>>> Cc: Kees Cook <keescook@chromium.org> >>>> Cc: Luis R. Rodriguez <mcgrof@kernel.org> >>>> Cc: Brian Norris <computersforpeace@gmail.com> >>>> Cc: stable@vger.kernel.org # 4.14 >>>> Fixes: c92316bf8e948 ("test_firmware: add batched firmware tests") >>>> Fixes: 0a8adf584759c ("test: add firmware_class loader test") >>>> Fixes: eb910947c82f9 ("test: firmware_class: add asynchronous request trigger") >>>> Fixes: 061132d2b9c95 ("test_firmware: add test custom fallback trigger") >>>> Link: https://lore.kernel.org/all/20230606070808.9300-1-mirsad.todorovac@alu.unizg.hr/ >>>> Signed-off-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr> >>>> >>>> [ This is the backport of the patch to 4.19 and 4.14 branches. There are no ] >>>> [ semantic differences in the commit. Backport is provided for completenes sake ] >>>> [ so it would apply to all of the supported LTS kernels ] >>> >>> This commit is already in the 4.19.291 release, does it need to be >>> included in there again for some reason? >> >> Hi Mr. Greg, >> >> I think the patchwork did not apply the commit to the 4.14 stable tree. >> Only the 19be3eccd000 ("test_firmware: fix a memory leak with reqs buffer" propagated to 4.14.322. >> >> I would like to have us this chapter (backporting) completed before moving on. > > That's fine, but your comment here said that this is for 4.19, but this > is already in 4.19, so I'm confused. I'll queue this up for 4.14.y > now... I will not contradict, however, it is the verbatim same patch as for the 4.19 stable tree. I know that you have to quick pick among hundreds of patches each day, because I follow the commit log. So I try to guess what would be the best, but I am still kinda newbie to the patch submission process. :-) I think we got it sorted out right this time. I will cooperate with the required number of iterations, as I understood this is an incremental development. However, please note that I could not boot the 4.14 kernel, it was only built properly. There is no reason for this change to work, but the actual test is always preferred, of course. Kind regards, Mirsad Todorovac
diff --git a/lib/test_firmware.c b/lib/test_firmware.c index 5318c5e18acf..34210306ea66 100644 --- a/lib/test_firmware.c +++ b/lib/test_firmware.c @@ -159,7 +159,7 @@ static int __kstrncpy(char **dst, const char *name, size_t count, gfp_t gfp) { *dst = kstrndup(name, count, gfp); if (!*dst) - return -ENOSPC; + return -ENOMEM; return count; } @@ -459,7 +459,7 @@ static ssize_t trigger_request_store(struct device *dev, name = kstrndup(buf, count, GFP_KERNEL); if (!name) - return -ENOSPC; + return -ENOMEM; pr_info("loading '%s'\n", name); @@ -500,7 +500,7 @@ static ssize_t trigger_async_request_store(struct device *dev, name = kstrndup(buf, count, GFP_KERNEL); if (!name) - return -ENOSPC; + return -ENOMEM; pr_info("loading '%s'\n", name); @@ -543,7 +543,7 @@ static ssize_t trigger_custom_fallback_store(struct device *dev, name = kstrndup(buf, count, GFP_KERNEL); if (!name) - return -ENOSPC; + return -ENOMEM; pr_info("loading '%s' using custom fallback mechanism\n", name);