From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CA6DC43334 for ; Mon, 11 Jul 2022 18:24:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC42D940013; Mon, 11 Jul 2022 14:24:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E739D940010; Mon, 11 Jul 2022 14:24:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3B51940013; Mon, 11 Jul 2022 14:24:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C3768940010 for ; Mon, 11 Jul 2022 14:24:54 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9AAA2337EC for ; Mon, 11 Jul 2022 18:24:54 +0000 (UTC) X-FDA: 79675645308.16.652E7DF Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by imf11.hostedemail.com (Postfix) with ESMTP id 206A340094 for ; Mon, 11 Jul 2022 18:24:53 +0000 (UTC) Received: by mail-vs1-f52.google.com with SMTP id s1so2204722vsr.12 for ; Mon, 11 Jul 2022 11:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hYm81WINPrMZthIUaIjVabJcBqoap/pn/CVPWFtAPRc=; b=jP00e8WXgNi59EPBq786OXRY48TLcrtJvIpnSus2fEJx2vRONRr4ho2d6LWdhGbnU6 ErYOMAhG3FYx7KgPoY4DAXWOX9ZA7jhKd1Fi1XvNscDdKZN24FsKU2SPJgRJ4W5/ygEx ymdjIzvQ+StwQH7aoZnZQjl0Epw762jEt924cMmyjrZ80Y5skk7a0+FsddSS79RuUB6S UC8QGFAao3O9xB1cMJWQjPEAw1XkN/WqaD5OeCCjgVkG+SGYEACqQJYqE/hnroiluG1y zLYDElPeBFpwdPVIJJhxFOP6zpxmbxLq5LdEhrp6+e6gmx1ypr4TnmyVYJPhljoST2Wz 5PEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hYm81WINPrMZthIUaIjVabJcBqoap/pn/CVPWFtAPRc=; b=w2s8UVwG8nCizKayHZy/drLBO7fsUVsNzvn5qQTNHmKXXFfW8KzssdQb8Vj3SaLD7V Lk23jJLOakTwZxUZ6tu31aHljZd4uOFWjiUwl8nRBX4uHVPDR90+b4N/q3YopC4uq5Nl vbH0lv4pi0xJ1xzwnyXKkyCDxE6VqWWAWDErIKBBJ9kG0Mb9uM+vEL/0EVcqZBZix8Tw S8M893NyjILiM1hqcRIuab+0ERLON3VfJJnBGDs0TjDmW/VK+7RRw+lip0cRPhzuU1WH GwcWEDFaA8sRbUhV4Ti3miqlsYAKeKvmzOm+1ogUvyXDQzxKjyjM6nHlfat8060G8GaL XaFQ== X-Gm-Message-State: AJIora8fiJcFnPMU/DNNr5mBHZOuC285LDpCkZPA0OjktXoNT25kVzXq lMCVqCJxD9eVgUbLlsqa3oKhFb1jsWwZCeq2WMc= X-Google-Smtp-Source: AGRyM1vYccBjI43XWDxR+KjpZwEhVKtFCtA5PQ33fPzH9ISwl6oFUXJpVSx8kZOE1FgIRQS/yP/gH23zsbPlDHra4Eg= X-Received: by 2002:a05:6102:2387:b0:34b:9f6d:10da with SMTP id v7-20020a056102238700b0034b9f6d10damr7447669vsr.28.1657563893068; Mon, 11 Jul 2022 11:24:53 -0700 (PDT) MIME-Version: 1.0 References: <20220711161341.21605-1-alexandr.lobakin@intel.com> In-Reply-To: <20220711161341.21605-1-alexandr.lobakin@intel.com> From: Yury Norov Date: Mon, 11 Jul 2022 11:24:42 -0700 Message-ID: Subject: Re: [bitops] 0e862838f2: BUG:KASAN:wild-memory-access_in_dmar_parse_one_rhsa To: Alexander Lobakin Cc: Andy Shevchenko , kernel test robot , Mark Rutland , LKML , Linux Memory Management List , linux-alpha@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-arch@vger.kernel.org, lkp@lists.01.org, lkp@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657563894; a=rsa-sha256; cv=none; b=kk042JL/3RNmhIAYLWTjw7aIZhcWUGiA4a0jkz/Ve3ILixFh1Q0Mw1DRPHutXtkgo8Awhd /GdhbtA+OKjX5HdRK+PUg8+chmaJJwC56Nq8oKOucCjeqHkLmC5UfjdUzNjPlM2FOkGUsG uF/YPY9Au6RoRIqQkkDukoxg63Bslq0= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=jP00e8WX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of yury.norov@gmail.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=yury.norov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657563894; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hYm81WINPrMZthIUaIjVabJcBqoap/pn/CVPWFtAPRc=; b=pgdrce97vGkcjSJgKzYyEV/O3Zj1PNOmKOEpej6ykj296BwzFOEHzoaT2nQZAdxzagQ9Vg vyfdRyZPdvA7Z+Ndb1tmhKGYJrft2663Lq9kotHWAnspnnE2a0kf0gtiMeahn9RNERoZ2O jMgOKHZhgFriIyL78uPlmdP3jEUK6Pw= Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=jP00e8WX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of yury.norov@gmail.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=yury.norov@gmail.com X-Stat-Signature: m5gffmy1x354y4j5stcdstofbt8nc8mp X-Rspamd-Queue-Id: 206A340094 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1657563893-802737 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jul 11, 2022 at 9:15 AM Alexander Lobakin wrote: > > From: Andy Shevchenko > Date: Fri, 8 Jul 2022 15:17:40 +0300 > > > On Thu, Jul 07, 2022 at 10:10:20PM +0800, kernel test robot wrote: > > > > > > (please be noted we reported > > > "[bitops] 001bea109d: BUG:KASAN:wild-memory-access_in_dmar_parse_one= _rhsa" > > > on > > > https://lore.kernel.org/all/YrnGLtDXAveqXGok@xsang-OptiPlex-9020/ > > > now we noticed this commit has already been merged into linux-next/ma= ster, > > > and the issue is still existing. report again FYI) > > > > > > Greeting, > > > > > > FYI, we noticed the following commit (built with gcc-11): > > > > > > commit: 0e862838f290147ea9c16db852d8d494b552d38d ("bitops: unify non-= atomic bitops prototypes across architectures") > > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git mast= er > > > > > > in testcase: xfstests > > > version: xfstests-x86_64-c1144bf-1_20220627 > > > with following parameters: > > > > > > disk: 2pmem > > > fs: ext4 > > > test: ext4-dax > > > ucode: 0x700001c > > > > > > test-description: xfstests is a regression test suite for xfs and oth= er files ystems. > > > test-url: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git > > > > > > > > > on test machine: 16 threads 1 sockets Intel(R) Xeon(R) CPU D-1541 @ 2= .10GHz with 48G memory > > > > > > caused below changes (please refer to attached dmesg/kmsg for entire = log/backtrace): > > > > > > > > > > > > If you fix the issue, kindly add following tag > > > Reported-by: kernel test robot > > > > > > > > > [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhs= a (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 incl= ude/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask= .h:415 drivers/iommu/intel/dmar.c:497) > > > [ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by tas= k swapper/0/0 > > > [ 4.683454][ T0] > > > [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19= .0-rc3-00004-g0e862838f290 #1 > > > [ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SD= V-8C-TLN4F, BIOS 1.1 03/02/2016 > > > [ 4.703196][ T0] Call Trace: > > > [ 4.706334][ T0] > > > [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h= :214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumen= ted-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.= c:497) > > > [ 4.714272][ T0] dump_stack_lvl (lib/dump_stack.c:107 (discriminator = 1)) > > > [ 4.718632][ T0] kasan_report (mm/kasan/report.c:162 mm/kasan/report.= c:493) > > > [ 4.722903][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h= :214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumen= ted-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.= c:497) > > > [ 4.728042][ T0] kasan_check_range (mm/kasan/generic.c:190) > > > [ 4.732750][ T0] dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:2= 14 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumente= d-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:= 497) > > > [ 4.737715][ T0] dmar_walk_remapping_entries (drivers/iommu/intel/dma= r.c:609) > > > [ 4.743375][ T0] parse_dmar_table (drivers/iommu/intel/dmar.c:671) > > > [ 4.748079][ T0] ? dmar_table_detect (drivers/iommu/intel/dmar.c:633) > > > [ 4.752872][ T0] ? dmar_free_dev_scope (drivers/iommu/intel/dmar.c:40= 8) > > > [ 4.758010][ T0] ? init_dmars (drivers/iommu/intel/iommu.c:3359) > > > [ 4.762370][ T0] ? iommu_resume (drivers/iommu/intel/iommu.c:3419) > > > [ 4.766903][ T0] ? dmar_walk_dsm_resource+0x300/0x300 > > > [ 4.772909][ T0] ? dmar_acpi_insert_dev_scope (drivers/iommu/intel/dm= ar.c:466) > > > [ 4.778655][ T0] ? dmar_check_one_atsr (drivers/iommu/intel/iommu.c:3= 521) > > > [ 4.783795][ T0] dmar_table_init (drivers/iommu/intel/dmar.c:846) > > > [ 4.788239][ T0] intel_prepare_irq_remapping (drivers/iommu/intel/irq= _remapping.c:742) > > > [ 4.793811][ T0] irq_remapping_prepare (drivers/iommu/irq_remapping.c= :102) > > > [ 4.798778][ T0] enable_IR_x2apic (arch/x86/kernel/apic/apic.c:1928) > > > [ 4.803395][ T0] default_setup_apic_routing (arch/x86/kernel/apic/pro= be_64.c:25 (discriminator 1)) > > > [ 4.808883][ T0] apic_intr_mode_init (arch/x86/kernel/apic/apic.c:144= 6) > > > [ 4.813761][ T0] x86_late_time_init (arch/x86/kernel/time.c:101) > > > [ 4.818467][ T0] start_kernel (init/main.c:1101) > > > [ 4.822827][ T0] secondary_startup_64_no_verify (arch/x86/kernel/head= _64.S:358) > > > > Seems like related to nodemask APIs. > > It points to arch_test_bit() (node_online() -> test_bit()), > converted from a macro to a function, more precisely, to > variable_test_bit(), which I didn't touch. > > ...oh ok I got it! > > pxm_to_node() can return %NUMA_NO_NODE which equals to -1. The > mentioned commit converts the macro to the function which now takes > `unsigned long` as @nr (bit number). So I guess it gets converted to > %ULONG_MAX - 1. > > Now the question is: what should a bitop do if we have negative bit > number? Because there are 2 solutions: > > 1. (I prefer it) A caller must check that bitop arguments are valid. > UB for negative (=3D=3D too big) bit numbers. > dmar_parse_one_rhsa() must be fixed so that it will check return > value of pxm_to_node(): > > int node =3D pxm_to_node(rhsa->proximity_domain); > > - if (!node_online(node)) > + if (node !=3D NUMA_NO_NODE && !node_online(node)) Would it make sense to check it inside node_online()? > node =3D NUMA_NO_NODE; > > 2. My code is broken, I shouldn't change `long` to `unsigned long` > or should change it for {constant,variable}_test_bit() as well > or do something else and let it behave as it was previously > (it wasn't crashing probably due to a good luck or...). This is definitely a NUMA problem. Bitmap has 2 kernel-wide users: cpumasks and numa nodes. Both use negative indexes for their reasons, which is dangerous, as we can see from here, because bitmaps don't support them and don't handle it properly... Can you please send a fix dmar_parse_one_rhsa() as you suggested, so that I'll add the fix before the beginning of next merge window? Regarding a general path, this is what I'm thinking on (for a while): - #define NUMA_NO_NODE MAX_NUMNODES; - stronger typechecking, like you did in your series; - introduce CONFIG_DEBUG_BITMAP to catch bad arguments on-the-fly; I'm working on DEBUG_BITMAP, hopefully submit it for next merge cycle. Thanks, Yury