From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756560AbdJPS2q (ORCPT ); Mon, 16 Oct 2017 14:28:46 -0400 Received: from mga09.intel.com ([134.134.136.24]:55432 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754947AbdJPS2o (ORCPT ); Mon, 16 Oct 2017 14:28:44 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,387,1503385200"; d="scan'208";a="1025756511" Date: Mon, 16 Oct 2017 11:28:43 -0700 From: "Luck, Tony" To: 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" , Laura Abbott Subject: Re: x86/mce: suspicious RCU usage in 4.13.4 Message-ID: <20171016182843.wrtcelsqf2y2onze@intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171015094046.6477zglnee3s75lc@pd.tnic> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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); }