From: "Zhang, Qiang" <Qiang.Zhang@windriver.com> To: Dmitry Vyukov <dvyukov@google.com> Cc: Russell King - ARM Linux <linux@armlinux.org.uk>, Andrew Morton <akpm@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, syzkaller-bugs <syzkaller-bugs@googlegroups.com> Subject: 回复: [PATCH] ARM: Fix incorrect use of smp_processor_id() by syzbot report Date: Fri, 12 Mar 2021 07:50:50 +0000 [thread overview] Message-ID: <BYAPR11MB2632B2128CAA2EDC34B79C52FF6F9@BYAPR11MB2632.namprd11.prod.outlook.com> (raw) In-Reply-To: <CACT4Y+ZS5ehyHrm0i-4fAX-Zk6OUN5PqGs0ZT_RC5K=fFgst5w@mail.gmail.com> ________________________________________ 发件人: Dmitry Vyukov <dvyukov@google.com> 发送时间: 2021年3月12日 14:30 收件人: Zhang, Qiang 抄送: Russell King - ARM Linux; Andrew Morton; LKML; Linux ARM; syzkaller-bugs 主题: Re: [PATCH] ARM: Fix incorrect use of smp_processor_id() by syzbot report [Please note: This e-mail is from an EXTERNAL e-mail address] On Fri, Mar 12, 2021 at 5:13 AM <qiang.zhang@windriver.com> wrote: > > From: Zqiang <qiang.zhang@windriver.com> > > BUG: using smp_processor_id() in preemptible [00000000] code: > syz-executor.0/15841 > caller is debug_smp_processor_id+0x20/0x24 > lib/smp_processor_id.c:64 > > The smp_processor_id() is used in a code segment when > preemption has been disabled, otherwise, when preemption > is enabled this pointer is usually no longer useful > since it may no longer point to per cpu data of the > current processor. > > Reported-by: syzbot <syzbot+a7ee43e564223f195c84@syzkaller.appspotmail.com> > Fixes: f5fe12b1eaee ("ARM: spectre-v2: harden user aborts in kernel space") > Signed-off-by: Zqiang <qiang.zhang@windriver.com> > --- > arch/arm/include/asm/system_misc.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h > index 66f6a3ae68d2..61916dc7d361 100644 > --- a/arch/arm/include/asm/system_misc.h > +++ b/arch/arm/include/asm/system_misc.h > @@ -21,8 +21,10 @@ typedef void (*harden_branch_predictor_fn_t)(void); > DECLARE_PER_CPU(harden_branch_predictor_fn_t, harden_branch_predictor_fn); > static inline void harden_branch_predictor(void) > { > + preempt_disable(); > harden_branch_predictor_fn_t fn = per_cpu(harden_branch_predictor_fn, > smp_processor_id()); > + preempt_enable(); > if (fn) > fn(); > } >Hi Qiang, > >If the CPU can change here, what if it changes right after >preempt_enable()? >Disabling preemption just around reading the callback looks like a >no-op. Shouldn't we disable preemption at least around reading and >calling the callback? Hi dvyukov Oh, I'm confused, we should call preempt_enable after calling callback function, to make sure callback function is called on current processor . thank you for your remind. > >On the second look, the fn seems to be const after init, so maybe we >need to use raw_smp_processor_id() instead with an explanatory >comment?
WARNING: multiple messages have this Message-ID (diff)
From: "Zhang, Qiang" <Qiang.Zhang@windriver.com> To: Dmitry Vyukov <dvyukov@google.com> Cc: Russell King - ARM Linux <linux@armlinux.org.uk>, Andrew Morton <akpm@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, syzkaller-bugs <syzkaller-bugs@googlegroups.com> Subject: 回复: [PATCH] ARM: Fix incorrect use of smp_processor_id() by syzbot report Date: Fri, 12 Mar 2021 07:50:50 +0000 [thread overview] Message-ID: <BYAPR11MB2632B2128CAA2EDC34B79C52FF6F9@BYAPR11MB2632.namprd11.prod.outlook.com> (raw) In-Reply-To: <CACT4Y+ZS5ehyHrm0i-4fAX-Zk6OUN5PqGs0ZT_RC5K=fFgst5w@mail.gmail.com> ________________________________________ 发件人: Dmitry Vyukov <dvyukov@google.com> 发送时间: 2021年3月12日 14:30 收件人: Zhang, Qiang 抄送: Russell King - ARM Linux; Andrew Morton; LKML; Linux ARM; syzkaller-bugs 主题: Re: [PATCH] ARM: Fix incorrect use of smp_processor_id() by syzbot report [Please note: This e-mail is from an EXTERNAL e-mail address] On Fri, Mar 12, 2021 at 5:13 AM <qiang.zhang@windriver.com> wrote: > > From: Zqiang <qiang.zhang@windriver.com> > > BUG: using smp_processor_id() in preemptible [00000000] code: > syz-executor.0/15841 > caller is debug_smp_processor_id+0x20/0x24 > lib/smp_processor_id.c:64 > > The smp_processor_id() is used in a code segment when > preemption has been disabled, otherwise, when preemption > is enabled this pointer is usually no longer useful > since it may no longer point to per cpu data of the > current processor. > > Reported-by: syzbot <syzbot+a7ee43e564223f195c84@syzkaller.appspotmail.com> > Fixes: f5fe12b1eaee ("ARM: spectre-v2: harden user aborts in kernel space") > Signed-off-by: Zqiang <qiang.zhang@windriver.com> > --- > arch/arm/include/asm/system_misc.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h > index 66f6a3ae68d2..61916dc7d361 100644 > --- a/arch/arm/include/asm/system_misc.h > +++ b/arch/arm/include/asm/system_misc.h > @@ -21,8 +21,10 @@ typedef void (*harden_branch_predictor_fn_t)(void); > DECLARE_PER_CPU(harden_branch_predictor_fn_t, harden_branch_predictor_fn); > static inline void harden_branch_predictor(void) > { > + preempt_disable(); > harden_branch_predictor_fn_t fn = per_cpu(harden_branch_predictor_fn, > smp_processor_id()); > + preempt_enable(); > if (fn) > fn(); > } >Hi Qiang, > >If the CPU can change here, what if it changes right after >preempt_enable()? >Disabling preemption just around reading the callback looks like a >no-op. Shouldn't we disable preemption at least around reading and >calling the callback? Hi dvyukov Oh, I'm confused, we should call preempt_enable after calling callback function, to make sure callback function is called on current processor . thank you for your remind. > >On the second look, the fn seems to be const after init, so maybe we >need to use raw_smp_processor_id() instead with an explanatory >comment? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-12 7:51 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-12 4:12 [PATCH] ARM: Fix incorrect use of smp_processor_id() by syzbot report qiang.zhang 2021-03-12 4:12 ` qiang.zhang 2021-03-12 6:30 ` Dmitry Vyukov 2021-03-12 6:30 ` Dmitry Vyukov 2021-03-12 7:50 ` Zhang, Qiang [this message] 2021-03-12 7:50 ` 回复: " Zhang, Qiang 2021-03-12 6:32 ` kernel test robot 2021-03-12 6:32 ` kernel test robot 2021-03-12 6:32 ` kernel test robot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=BYAPR11MB2632B2128CAA2EDC34B79C52FF6F9@BYAPR11MB2632.namprd11.prod.outlook.com \ --to=qiang.zhang@windriver.com \ --cc=akpm@linux-foundation.org \ --cc=dvyukov@google.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=syzkaller-bugs@googlegroups.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.