lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 1 Nov 2017 07:56:20 -0700 From: Laura Abbott <labbott@...hat.com> To: "Luck, Tony" <tony.luck@...el.com>, Borislav Petkov <bp@...en8.de> Cc: Andi Kleen <ak@...ux.intel.com>, Jeremy Cline <jcline@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>, "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: x86/mce: suspicious RCU usage in 4.13.4 On 10/16/2017 11:28 AM, Luck, Tony wrote: > On Sun, Oct 15, 2017 at 11:40:46AM +0200, Borislav Petkov wrote: >> On Wed, Oct 11, 2017 at 09:34:22PM +0000, Luck, Tony wrote: >>>> here's a second attempt at a more rigorous simplification: RCU stuff is >>>> gone and only a single loop scans through the elements. >>> >>> The dev_mce_log() changes look good now. >>> >>> You can apply the axe to more bits of mce_chrdev_read() though. Like that >> >> That provoked a very serious axing. Please check whether I went too far. Hunk >> below is ontop of what got axed already: > > I think a few more lines can go. Almost everything relating to the "finished" > element. dev_mce_log() must still set it (because the user mode mcelog(8) > daemon will grumble if we give it records that don't have it set). But > since everything is protected by mce_chrdev_read_mutex we can't have > "Old left over entries" to skip. Nor is there any way that finished can't > be set for an entry in 0..mcelog.next when it comes to mce_chrdev_read(). > > This patch on top of your two??? > Did these get queued up somewhere? I know last week was OSSEU/Ksummit so people may still be playing catch-up. Thanks, Laura > -Tony > > diff --git a/arch/x86/kernel/cpu/mcheck/dev-mcelog.c b/arch/x86/kernel/cpu/mcheck/dev-mcelog.c > index 17d2bab25720..7f85b76f43bc 100644 > --- a/arch/x86/kernel/cpu/mcheck/dev-mcelog.c > +++ b/arch/x86/kernel/cpu/mcheck/dev-mcelog.c > @@ -49,11 +49,7 @@ static int dev_mce_log(struct notifier_block *nb, unsigned long val, > > mutex_lock(&mce_chrdev_read_mutex); > > - for (entry = mcelog.next; entry < MCE_LOG_LEN; entry++) { > - /* Old left over entry. Skip: */ > - if (mcelog.entry[entry].finished) > - continue; > - } > + entry = mcelog.next; > > /* > * When the buffer fills up discard new entries. Assume that the > @@ -231,9 +227,6 @@ static ssize_t mce_chrdev_read(struct file *filp, char __user *ubuf, > for (i = 0; i < next; i++) { > struct mce *m = &mcelog.entry[i]; > > - if (!m->finished) > - continue; > - > err |= copy_to_user(buf, m, sizeof(*m)); > buf += sizeof(*m); > } >
Powered by blists - more mailing lists