From patchwork Thu Jan 25 06:14:27 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Zhang, Rui" X-Patchwork-Id: 10183675 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7E66460233 for ; Thu, 25 Jan 2018 06:14:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 680B528712 for ; Thu, 25 Jan 2018 06:14:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5BFD7289ED; Thu, 25 Jan 2018 06:14:34 +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=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI 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 0C03828712 for ; Thu, 25 Jan 2018 06:14:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750824AbeAYGOb (ORCPT ); Thu, 25 Jan 2018 01:14:31 -0500 Received: from mga07.intel.com ([134.134.136.100]:57874 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750769AbeAYGOb (ORCPT ); Thu, 25 Jan 2018 01:14:31 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 22:14:30 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,409,1511856000"; d="scan'208";a="196116912" Received: from wqi-mobl2.ccr.corp.intel.com (HELO rzhang1-surface.ccr.corp.intel.com) ([10.255.31.143]) by orsmga005.jf.intel.com with ESMTP; 24 Jan 2018 22:14:28 -0800 From: Zhang Rui To: rjw@rjwysocki.net Cc: linux-acpi@vger.kernel.org, pmenzel+bugzilla.kernel.org@molgen.mpg.de Subject: [PATCH] ACPI: use bitmap helper for masked GPEs Date: Thu, 25 Jan 2018 14:14:27 +0800 Message-Id: <1516860867-6391-1-git-send-email-rui.zhang@intel.com> X-Mailer: git-send-email 2.7.4 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP "acpi_mask_gpe=" kernel parameter is introduced to mask one or more GPEs at boot stage, to prevent GPE flooding. Currently, a maximum of 128 GPEs (from GPE 0x00 to GPE 0x7f) are allowed to be masked by this kernel parameter, but only one u64 variant is used as the bitmap for the masked GPEs in kernel. This is bogus and makes some GPEs masked unexpected when masking a GPE larger than 0x40. For example, with CONFIG_UBSAN=y, when "acpi_mask_gpe=0x6f" is parsed, we get [ 0.039669] ACPI: Masking GPE 0x2f. [ 0.039681] ================================================================================ [ 0.039684] UBSAN: Undefined behaviour in drivers/acpi/sysfs.c:846:33 [ 0.039688] shift exponent 64 is too large for 64-bit type 'long long unsigned int' [ 0.039692] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-UBSAN-check+ #37 [ 0.039695] Hardware name: Microsoft Corporation Surface Pro 4/Surface Pro 4, BIOS 106.1281.768 08/01/2016 [ 0.039698] Call Trace: [ 0.039704] dump_stack+0x64/0x91 [ 0.039709] ubsan_epilogue+0xd/0x40 [ 0.039712] __ubsan_handle_shift_out_of_bounds+0xf6/0x140 [ 0.039716] ? do_syscall_64+0x1e6/0x760 [ 0.039720] ? acpi_ev_mask_gpe+0x141/0x14c [ 0.039724] acpi_gpe_apply_masked_gpes+0x41/0x8a [ 0.039727] ? acpi_gpe_apply_masked_gpes+0x41/0x8a [ 0.039731] acpi_scan_init+0x14d/0x2df [ 0.039734] acpi_init+0x32d/0x379 [ 0.039737] ? acpi_sleep_proc_init+0x2a/0x2a [ 0.039740] do_one_initcall+0x116/0x1d0 [ 0.039743] kernel_init_freeable+0x304/0x39a [ 0.039746] ? rest_init+0xf0/0xf0 [ 0.039749] kernel_init+0xf/0x120 [ 0.039752] ? rest_init+0xf0/0xf0 [ 0.039756] ret_from_fork+0x25/0x30 [ 0.039758] ================================================================================ [ 0.039762] ACPI: Masking GPE 0x6f. Fix this by using the bitmap helper, for declaring, testing and setting the bitmap. Link: https://bugzilla.kernel.org/show_bug.cgi?id=198481 Reported-and-tested-by: Paul Menzel Signed-off-by: Zhang Rui Cc: 4.10+ # 4.10+ --- drivers/acpi/sysfs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c index 0fd57bf..f0d1163 100644 --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -820,7 +820,7 @@ static ssize_t counter_set(struct kobject *kobj, */ #define ACPI_MASKABLE_GPE_MAX 0x80 -static u64 __initdata acpi_masked_gpes; +static __initdata DECLARE_BITMAP(acpi_masked_gpes, ACPI_MASKABLE_GPE_MAX); static int __init acpi_gpe_set_masked_gpes(char *val) { @@ -828,7 +828,7 @@ static int __init acpi_gpe_set_masked_gpes(char *val) if (kstrtou8(val, 0, &gpe) || gpe > ACPI_MASKABLE_GPE_MAX) return -EINVAL; - acpi_masked_gpes |= ((u64)1<