From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754404AbcGHJrI (ORCPT ); Fri, 8 Jul 2016 05:47:08 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:33607 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751815AbcGHJq5 (ORCPT ); Fri, 8 Jul 2016 05:46:57 -0400 Date: Fri, 8 Jul 2016 11:46:53 +0200 From: Ingo Molnar To: Borislav Petkov Cc: LKML , Yazen Ghannam , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra Subject: Re: [PATCH 3/6] x86/mce: Add support for new MCA_SYND register Message-ID: <20160708094653.GC13849@gmail.com> References: <1467968983-4874-1-git-send-email-bp@alien8.de> <1467968983-4874-4-git-send-email-bp@alien8.de> <20160708092659.GB13849@gmail.com> <20160708093731.GC3808@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160708093731.GC3808@pd.tnic> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Borislav Petkov wrote: > On Fri, Jul 08, 2016 at 11:26:59AM +0200, Ingo Molnar wrote: > > So why does neither the changelog nor the code comment actually _explain_ this and > > give aa bit of a background about what 'syndrome information' is and why we want > > to have kernel support for it? > > > > This is why I hate kernel tooling that is not part of the kernel tree - the mcelog > > patch (hopefully ...) would tell us more about all this - but it's separate and > > this patch does not tell us anything ... > > Ah, this is one of those omissions where we forgot to explain, sorry. > How about this: > > "The syndrome value is used to uniquely identify which bits of a > reported ECC error are corrupted." I'm not sure I can parse that: how can a reported error have bits corrupted? Or is this about various details about the location of the error (normally contained in a 'struct mce' entry), and the 'syndrome value' further qualifies that information by telling us which fields of those records are reliable? I.e. a bit more context would be nice. You cannot go wrong if you assume that readers of changelogs (and maintainers in particular) have the attention span of a slightly retarded golden retriever. > Do you want it as a comment in the code or in the commit message or both? I'm fine with an add-on patch that adds a good explanation for all this to the code. Thanks, Ingo