linux-kernel - Re: [PATCH] EDAC/dmc520: Don't print an error for each unconfigured interrupt line

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]

Date:   Wed, 19 Jan 2022 10:17:52 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Borislav Petkov <bp@...en8.de>,
        Tyler Hicks <tyhicks@...ux.microsoft.com>
Cc:     Sasha Levin <sashal@...nel.org>, Lei Wang <lewan@...rosoft.com>,
        Tony Luck <tony.luck@...el.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Sinan Kaya <okaya@...nel.org>,
        Shiping Ji <shiping.linux@...il.com>,
        James Morse <james.morse@....com>,
        Robert Richter <rric@...nel.org>, linux-edac@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] EDAC/dmc520: Don't print an error for each unconfigured
 interrupt line

On Tue, Jan 18, 2022 at 10:04:30PM +0100, Borislav Petkov wrote:
> On Tue, Jan 18, 2022 at 01:54:01PM -0600, Tyler Hicks wrote:
> > On 2022-01-18 18:28:16, Borislav Petkov wrote:
> > > On Tue, Jan 18, 2022 at 09:28:16AM -0600, Tyler Hicks wrote:
> > > > KERN_ERR messages trip log scanners and cause concern that the
> > > > kernel/hardware is not configured or working correctly. They also add a
> > > > little big of ongoing stress into kernel maintainer's lives, as we
> > > > prepare and test kernel updates, since they show up as red text in
> > > > journalctl output that we have to think about regularly. Multiple
> > > > KERN_ERR messages, 8 in this case, can also be considered a little worse
> > > > than a single error message.
> > > 
> > > It sounds to me like you wanna read
> > > 
> > > Documentation/process/stable-kernel-rules.rst
> > > 
> > > first.
> > 
> > I'm familiar with it and the sort of commits that flow into stable.
> > 
> > > > I feel like this trivial fix is worth taking into stable rather than
> > > > suppressing these errors (mentally and in log scanners) for years.
> > > 
> > > Years? 
> > 
> > Yes, years. v5.10 is supported through 2026.
> > 
> > > In any case, sorry, no, I don't consider this stable material.
> > 
> > The bar varies by subsystem maintainer but this wouldn't be the first
> > logging fix that made it into a stable branch. From the linux-5.10.y
> > branch of linux-stable:
> > 
> >  ddb13ddacc60 scsi: pm80xx: Fix misleading log statement in pm8001_mpi_get_nvmd_resp()
> >  526261c1b706 amd/display: downgrade validation failure log level
> >  9a3f52f73c04 bnxt_en: Improve logging of error recovery settings information.
> >  5f7bda9ba8d7 leds: lm3697: Don't spam logs when probe is deferred
> >  8b195380cd07 staging: fbtft: Don't spam logs when probe is deferred
> >  ...
> 
> Well, lemme add the stable folks for comment then - they might have had
> their reasons.
> 
> ( Or Sasha's AI went nuts. Which I've witnessed a bunch of times
> already.)
> 
> If I look at the stable-kernel-rules.rst file, the only rule that
> *maybe*, *probably* applies here is
> 
> "- It must fix a real bug that bothers people"
> 
> But this one is formulated so broadly so that it makes me wanna ignore
> it. Because *anything* can bother people - even spelling mistakes but
> then a later rule says no spelling fixes.
> 
> Don't get me wrong - I don't mind having the stable tag where really
> needed. But here it is questionable. And we have those stable rules for
> a reason - if we start bending them and ignoring them then we might
> just as well backport everything that applies and have parallel kernel
> streams where the version means nothing. Basically a distro kernel. :-P
> 
> So let's see what the stable folks say first.

I will be glad to take these types of patches if the subsystem
maintainer thinks it will help things out, or if they are tired of
getting emails about the misleading messages.  In this case, I don't
think either of those things is relevant, so I don't see why the patch
should be backported.

For this specific change, I do NOT think it should be backported at all,
mostly for the reason that people are still arguing over the whole
platform_get_*_optional() mess that we currently have.  Let's not go and
backport anything right now to stable trees until we have all of that
sorted out, as it looks like it all might be changing again.  See:
	https://lore.kernel.org/r/20220110195449.12448-1-s.shtylyov@omp.ru
for all of the gory details and the 300+ emails written on the topic so
far.

Tyler, feel free to jump in to that thread if you want, it's a mess...

thanks,

greg k-h