From patchwork Mon Aug 6 22:18:34 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Torokhov X-Patchwork-Id: 10557979 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0696E14E2 for ; Mon, 6 Aug 2018 22:18:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E17B52956A for ; Mon, 6 Aug 2018 22:18:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D1E682958B; Mon, 6 Aug 2018 22:18:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 746D12956A for ; Mon, 6 Aug 2018 22:18:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732355AbeHGA3r (ORCPT ); Mon, 6 Aug 2018 20:29:47 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:46637 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732106AbeHGA3r (ORCPT ); Mon, 6 Aug 2018 20:29:47 -0400 Received: by mail-pg1-f193.google.com with SMTP id f14-v6so6308422pgv.13; Mon, 06 Aug 2018 15:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=7OufTL9uIyO71Njch/UbCGdSbo/gh+FH/4qlnwRVFOw=; b=R5FjXRTZ5nrvZCjDTJsdhOXMDh4xjB3iKpouf+KcHWc42kIX2ZOCy6iDxqyBz8dLK6 bK3Z5m18ipx+jTUpnDcs4kBdvb3rMqTl0CSOCiVWLuxQ73rbHTDH/7KjqbZv71OBIysX O+aAlXgrvb/5BYBt4HPdSzT73VlrVCHsqVosoQLOAy2XsqkVP5/tn59OIwEzzBW78HcF z68QX4jmOsExTc5EzA0VZo643RWNCGuByOATOzLeHtsSWoZdHa1XPookrKLtPWP63RJC Ix+A8u7+mSfA/GKKDbn0nkYkwRZjto+guUB4gIflgMyTKvy7gQjL+0CFsEtZYw85a/qI TSOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=7OufTL9uIyO71Njch/UbCGdSbo/gh+FH/4qlnwRVFOw=; b=qu0GkaP4Ssz5Zm9ikwFmDACQ3lLr068RmRIEXUB3JjD6of0TJLWKHQOmt5U8zo1SWq 2Ul77Lm5wWeGba4WNi9O9fhDWVn29iPW/VrsYKfTWUiXjAO96CQDTMa+vrBkkY/u5NOj YuKrUv9Z+t2yyDuXHySQOLCCd0PTeuGJAsw7AKkxam2zsPangvNsJWYC2M676miLOwPo FgFJBBg63d3zvGP1WIBtwDoWaRHSMIs5TKn+7qoJsZVOcrUwGSSmx8GNseT0qa3IVRp4 yoMhiKF8HH8Grr8fM0bl2KSS+My+sEy2frWtiPq26jMhjxyqwH1pMVGDWi2orXw5417a SHyA== X-Gm-Message-State: AOUpUlGzhL0MIg21ItFYYOobS6RNTk10qO7dhrrbyj0r3JYEMo646mq/ Y1JkmYk5PC9ouLM9pFk6tHCXoVLZ X-Google-Smtp-Source: AAOMgpe4vEfRgzSSt7jcgUsou/oJ9+tzWt5EfqvJV88tAiMZ20Fee4FXYCataVX5vFbrCPdQClsOhg== X-Received: by 2002:a65:4849:: with SMTP id i9-v6mr16078836pgs.350.1533593917678; Mon, 06 Aug 2018 15:18:37 -0700 (PDT) Received: from dtor-ws ([2620:15c:202:201:3adc:b08c:7acc:b325]) by smtp.gmail.com with ESMTPSA id l27-v6sm25232084pfi.180.2018.08.06.15.18.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 Aug 2018 15:18:36 -0700 (PDT) Date: Mon, 6 Aug 2018 15:18:34 -0700 From: Dmitry Torokhov To: linux-input@vger.kernel.org Cc: Dmitry Vyukov , Henrik Rydberg , linux-kernel@vger.kernel.org Subject: [PATCH] Input: do not use WARN() in input_alloc_absinfo() Message-ID: <20180806221834.GA140172@dtor-ws> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Some of fuzzers set panic_on_warn=1 so that they can handle WARN()ings the same way they handle full-blown kernel crashes. We used WARN() in input_alloc_absinfo() to get a better idea where memory allocation failed, but since then kmalloc() and friends started dumping call stack on memory allocation failures anyway, so we are not getting anything extra from WARN(). Because of the above, let's replace WARN with dev_err(). We use dev_err() instead of simply removing message and relying on kcalloc() to give us stack dump so that we'd know the instance of hardware device to which we were trying to attach input device. Reported-by: Dmitry Vyukov Signed-off-by: Dmitry Torokhov Acked-by: Dmitry Vyukov --- drivers/input/input.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/input/input.c b/drivers/input/input.c index 90453e2ab6cf..260f00ebe34d 100644 --- a/drivers/input/input.c +++ b/drivers/input/input.c @@ -481,11 +481,19 @@ EXPORT_SYMBOL(input_inject_event); */ void input_alloc_absinfo(struct input_dev *dev) { - if (!dev->absinfo) - dev->absinfo = kcalloc(ABS_CNT, sizeof(*dev->absinfo), - GFP_KERNEL); + if (dev->absinfo) + return; - WARN(!dev->absinfo, "%s(): kcalloc() failed?\n", __func__); + dev->absinfo = kcalloc(ABS_CNT, sizeof(*dev->absinfo), GFP_KERNEL); + if (!dev->absinfo) { + dev_err(dev->dev.parent ?: &dev->dev, + "%s: unable to allocate memory\n", __func__); + /* + * We will handle this allocation failure in + * input_register_device() when we refuse to register input + * device with ABS bits but without absinfo. + */ + } } EXPORT_SYMBOL(input_alloc_absinfo);