Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3224856imu; Sat, 24 Nov 2018 00:31:03 -0800 (PST) X-Google-Smtp-Source: AFSGD/UNnHxgU/OJSxw3DTu7e05rNAKbo+G5r5jPNZxKB2HmNUAEMiXnhLGndS4HHZhzguJyy7/7 X-Received: by 2002:a65:5a4c:: with SMTP id z12mr17273374pgs.188.1543048263136; Sat, 24 Nov 2018 00:31:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543048263; cv=none; d=google.com; s=arc-20160816; b=SEIyPqMyB92XrAR9/qr2uX6W5/QIoYWTBe/FnSlHdoOwe19qAdFf68oOrVwIiKAu4v N9utMHAtCHzNw1MF7Do0BZ84hsOYRckd1a8PJpI28zMWwAeM6ClcPtGp2a8AOwcbRvu3 rPubf37xfr2khuH+zkAzn+6KAmwSVA+EZXKIfjfy0zaNhCWa2K1hdHxcG2shiejeYFXN 6pfRSBN585P35d60jctxt8oroVwBShcOyaLhsiYCGjme7GhXBXj2anJAqFXm9CCQzUs1 mMbwjnLDdcfk3dvoXkajnrKVVa0Gs6jXd4ARgQ3P5X7Qwqn08WGzmESdCvE0DMi/XTLy J4Yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=kWzcTltt25S0fd/itrBGR5Mf9eQZub5B3OysvO5aqFA=; b=k/TuqDGGz4th/8/FzNLJRxCImJQ8Mqi/z16dQgdpVVPQLp4semnmvwYdC65ndQ2S+f mtG/IWWO667elsu7g5jspsk6OREw9KOa+sLvHfs1FO+ZrR7q3pQ3f8O00mKMgRRo0yoB E5VMq0kNXuddKGtfuaxg6FxA022F12RbLQvNh5qIKm7Xx9ljqOOK6CdGVaLoff/RxUXy RDvO3cOMtupzglTwCWFtpdEt9icjMMZeHNft7PXwj7bnaWM4seI+/HgUB7kpGMYc42mc LcvcMVQE1/dkaGIWw/tRtzwLg2y3FsPvNZCfqfthw/TSInEGw75xZ+n8MGudVZc04Fru Ik8Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 126si25542778pff.77.2018.11.24.00.30.48; Sat, 24 Nov 2018 00:31:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2409745AbeKWWxG (ORCPT + 99 others); Fri, 23 Nov 2018 17:53:06 -0500 Received: from www.osadl.org ([62.245.132.105]:57932 "EHLO www.osadl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388020AbeKWWxG (ORCPT ); Fri, 23 Nov 2018 17:53:06 -0500 Received: from debian01.hofrr.at (178.115.242.59.static.drei.at [178.115.242.59]) by www.osadl.org (8.13.8/8.13.8/OSADL-2007092901) with ESMTP id wANC4eM0032110; Fri, 23 Nov 2018 13:04:40 +0100 From: Nicholas Mc Guire To: Tomi Valkeinen Cc: David Airlie , Laurent Pinchart , Sebastian Reichel , Peter Ujfalusi , "Andrew F. Davis" , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Nicholas Mc Guire Subject: [PATCH] drm/omap: dss: do not allow devm_kasprintf() to fail Date: Fri, 23 Nov 2018 13:01:35 +0100 Message-Id: <1542974495-12387-1-git-send-email-hofrat@osadl.org> X-Mailer: git-send-email 2.1.4 X-Spam-Status: No, score=-1.9 required=6.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on www.osadl.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org omapdss_display_init() is called by multiple drivers and does not expect a return value so without changing all call-sites the low-probability failure of devm_kasprintf() can not be reported up the call stack. As the amount allocated here is very small (<= 16 bytes) and it is an initialization function that most likely will be called during system initialization it should be OK to use __GFP_NOFAIL here to prevent devm_kasprintf() from returning NULL. Signed-off-by: Nicholas Mc Guire Fixes: 36c61ae2b755 ("drm/omap: dss: Remove display ordering from dss/display.c") --- Problem located with experimental coccinelle script While the use of __GFP_NOFAIL is to be limited (small infrequent allocations) this case does seems suitable as it is rare and small (initialization) .As all the current drivers using omapdss_display_init() currently seem not to initialize dssdev->name prior to calling omapdss_display_init() and the unlikely failure case can not be reasonably responded (returns void) not allowing a allocation failure here should be acceptable. Patch was compile tested with: omap2plus_defconfig (implies OMAP_DSS_BASE=m) Patch is against 4.20-rc3 (localversion-next is next-20181123) drivers/gpu/drm/omapdrm/dss/display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/display.c b/drivers/gpu/drm/omapdrm/dss/display.c index 34b2a4e..7dbe874 100644 --- a/drivers/gpu/drm/omapdrm/dss/display.c +++ b/drivers/gpu/drm/omapdrm/dss/display.c @@ -45,7 +45,8 @@ void omapdss_display_init(struct omap_dss_device *dssdev) of_property_read_string(dssdev->dev->of_node, "label", &dssdev->name); if (dssdev->name == NULL) - dssdev->name = devm_kasprintf(dssdev->dev, GFP_KERNEL, + dssdev->name = devm_kasprintf(dssdev->dev, + GFP_KERNEL | __GFP_NOFAIL, "display%u", id); } EXPORT_SYMBOL_GPL(omapdss_display_init); -- 2.1.4