linux-kernel - Re: x86/mce: suspicious RCU usage in 4.13.4

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171016182843.wrtcelsqf2y2onze@intel.com>
Date:   Mon, 16 Oct 2017 11:28:43 -0700
From:   "Luck, Tony" <tony.luck@...el.com>
To:     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>,
        Laura Abbott <labbott@...hat.com>
Subject: Re: x86/mce: suspicious RCU usage in 4.13.4

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???

-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);
 	}