linux-kernel - Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

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: <alpine.LRH.2.00.1804162221320.26111@gjva.wvxbf.pm>
Date:   Mon, 16 Apr 2018 22:33:16 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     Steven Rostedt <rostedt@...dmis.org>,
        Sasha Levin <Alexander.Levin@...rosoft.com>,
        Pavel Machek <pavel@....cz>, Petr Mladek <pmladek@...e.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Mel Gorman <mgorman@...e.de>, Michal Hocko <mhocko@...nel.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Peter Zijlstra <peterz@...radead.org>, Jan Kara <jack@...e.cz>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Byungchul Park <byungchul.park@....com>,
        Tejun Heo <tj@...nel.org>, Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and
 waiter logic to load balance console writes

On Mon, 16 Apr 2018, Linus Torvalds wrote:

> The ones who should matter most for that discussion is the distros,
> since they are the actual users of stable (as well as the people doing
> the work, of course - ie Sasha and Greg and the rest of the stable
> gang).
> 
> And I suspect that they actually do want all the noise, and all the
> stuff that isn't "critical". That's often the _easy_ choice. It's the
> stuff that I suspect the stable maintainers go "this I don't even have
> to think about", because it's a new driver ID or something.

So I am a maintainer of SUSE enterprise kernel, and I can tell you I 
personally really don't want all the noise, simply because

	(a) noone asked us to distribute it (if they did, we would do so)
	(b) the risk of regressions

We've always been very cautious about what is coming from stable, and 
actually filtering out patches we actively don't want for one reason or 
another.

And yes, there is also a history of regressions caused by stable updates 
that were painful for us ... I brought this up a multiple times at 
ksummit-discuss@ over past years.

So with the upcoming release, we've actually abandonded stable and are 
relying more on auto-processing the Fixes: tag.

That is not perfect in both ways (it doesn't cover everything, and we can 
miss complex semantical dependencies between patches even though they 
"apply"), but we didn't base our decision this time on aligning our 
schedule with stable, and so far we don't seem to be suffering. And we 
have much better overview / control over what is landing in our enterprise 
tree (of course this all is shepherded by machinery around processing 
Fixes: tag, which then though has to be *actively* acted upon, depending 
on a case-by-case human assessment of how critical it actually is).

> Because the bulk of stable tends to be driver updates, afaik. Which 
> distros very much tend to want.

For "community" distros (like Fedora, openSUSE), perhaps, yeah.

For "enterprise" kernels, quite frankly, we much rather get the driver 
updates/backports from the respective HW vedndors we're cooperating with, 
as they have actually tested and verified the backport on the metal.

> The critical stuff is hopefully a tiny tiny percentage.

But quite frankly, that's the only thing we as distro *really* want -- to 
save our users from hitting the critical issues with all the consequences 
(data loss, unbootable systems, etc). All the rest we can easily handle on 
a reactive basis, which heavily depends on the userbase spectrum (and 
that's probably completely different for each -stable tree consumer 
anyway).

This is a POV of me as an distro kernel maintainer, but mileage of others 
definitely can / will vary of course.

Thanks,

-- 
Jiri Kosina
SUSE Labs