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: <6c5bf4d7-3f9d-a05e-78f4-a4a46868a311@redhat.com>
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);
>  	}
>