Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp739494imm; Thu, 13 Sep 2018 07:04:56 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZERzLWLE24hhsIebUA6OfKoeG6qvZHJ1+5o8cVVhgiGZJiJlj5x0tMV8NtAhwmtWN7Lo0H X-Received: by 2002:a63:fd52:: with SMTP id m18-v6mr7424196pgj.304.1536847496909; Thu, 13 Sep 2018 07:04:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536847496; cv=none; d=google.com; s=arc-20160816; b=x441fJvIrAVWJ3z7s3HPqwpsXEKd6nZuz/4zx0HKJC33PkiDgE6Vdskz9mhyatcGmH V7D1LviCOXS0B5xjer/L/2bR8QHUx0IA+mw2zQkfs+r1JY2UpsrWjhFViLzJWcw4v4be jXSNqIQnnK/Vy6BdFCLXTVmLlKEHIfsYugq05mcJeMqAcCKr1MFqCjf5CfLjbLVh/aou DiJNq+qXit9JrxWO7eRD++7hfXaOq8IDiSeLuroFYA0GKlmBv4BlMMHH/SgGskm3molq vgCofUfuzBWKAauUCChHaKabxw5LYBRNAWMDUtT1KIgMs+KB1oYEQ8lpP+BBe8a1Zisy CATQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from; bh=EdzIQfVh+yKR3M80sAPBkBLKhACd0LwWQGaafgfJNwU=; b=AmKCqsC3HUUut5nxyuwFscMBUxKVSmK6xMHlqLRoQRKP7kau+syzHY0vhTWtILGG4G EBxjU2h48xV3oCYDU7E7b7IDuTexiVyOeIVjTimKhUbfjtlxb4C+0iVhxNgBZIS2lIcS IiHgg1l8b2y8TuttY2uVqDCE3kNiHXaROUOIBoyu/tI9UjW4lwVSOuSiAKAX4cvYRopP bM7iYxLnslmZj62mRpsn8bOcNNP62hfDffK9f5TQ1ct9Lw+jZdrkrA1yERwB3xOgH0rV Oo/w00aP4pcVNKNKdETCwTsRgdHq9ymZ//2JnaR/btzvd+XQEQZuTDC2e+7odIJ6F5wM nFdw== 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 k10-v6si4138205pfe.41.2018.09.13.07.04.37; Thu, 13 Sep 2018 07:04:56 -0700 (PDT) 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 S1731726AbeIMTMJ (ORCPT + 99 others); Thu, 13 Sep 2018 15:12:09 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:35234 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731008AbeIMTMI (ORCPT ); Thu, 13 Sep 2018 15:12:08 -0400 Received: from localhost (ip-213-127-77-73.ip.prioritytelecom.net [213.127.77.73]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id CA723D2F; Thu, 13 Sep 2018 14:02:29 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dmitry Vyukov , Dmitry Torokhov , Sasha Levin Subject: [PATCH 4.18 109/197] Input: do not use WARN() in input_alloc_absinfo() Date: Thu, 13 Sep 2018 15:30:58 +0200 Message-Id: <20180913131845.908607038@linuxfoundation.org> X-Mailer: git-send-email 2.19.0 In-Reply-To: <20180913131841.568116777@linuxfoundation.org> References: <20180913131841.568116777@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Dmitry Torokhov [ Upstream commit 100294cee9a98bfd4d6cb2d1c8a8aef0e959b0c4 ] 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 Acked-by: Dmitry Vyukov Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/input/input.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) --- a/drivers/input/input.c +++ b/drivers/input/input.c @@ -480,11 +480,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);