From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754711AbdKAO4Z (ORCPT ); Wed, 1 Nov 2017 10:56:25 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:49898 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753119AbdKAO4Y (ORCPT ); Wed, 1 Nov 2017 10:56:24 -0400 X-Google-Smtp-Source: ABhQp+TtY7helybatIfOnriExo6e34tUcTpAZElzGWGXNT3uzf6V0wXEbURejwOLhW9cjYmuwMN5ag== Subject: Re: x86/mce: suspicious RCU usage in 4.13.4 To: "Luck, Tony" , Borislav Petkov Cc: Andi Kleen , Jeremy Cline , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86@kernel.org" , "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <9840bf0d-6756-75eb-1a2d-d3aace235244@redhat.com> <20171010194426.s7keveirclglx6vh@pd.tnic> <20171010200841.uhniuwc7pulqgmic@intel.com> <871smasqux.fsf@linux.intel.com> <20171011115020.i4gkcy5pjifh2zsm@pd.tnic> <3908561D78D1C84285E8C5FCA982C28F770038E5@ORSMSX114.amr.corp.intel.com> <20171015094046.6477zglnee3s75lc@pd.tnic> <20171016182843.wrtcelsqf2y2onze@intel.com> From: Laura Abbott Message-ID: <6c5bf4d7-3f9d-a05e-78f4-a4a46868a311@redhat.com> Date: Wed, 1 Nov 2017 07:56:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171016182843.wrtcelsqf2y2onze@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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); > } >