[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D5CC7C52-1F08-401E-BDCA-DF617909BB9D@lca.pw>
Date: Tue, 14 Jan 2020 16:40:49 -0500
From: Qian Cai <cai@....pw>
To: Michal Hocko <mhocko@...nel.org>
Cc: David Hildenbrand <david@...hat.com>, akpm@...ux-foundation.org,
sergey.senozhatsky.work@...il.com, pmladek@...e.com,
rostedt@...dmis.org, peterz@...radead.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next] mm/hotplug: silence a lockdep splat with printk()
> On Jan 14, 2020, at 4:02 PM, Michal Hocko <mhocko@...nel.org> wrote:
>
> Yeah, that was a long discussion with a lot of lockdep false positives.
> I believe I have made it clear that the console code shouldn't depend on
> memory allocation because that is just too fragile. If that is not
> possible for some reason then it has to be mentioned in the changelog.
> I really do not want us to add kludges to the MM code just because of
> printk deficiencies unless that is absolutely inevitable.
I don’t know how to convince you, but both random number generator and printk() maintainers agreed to get ride of printk() with zone->lock held as you can see in the approved commit mentioned in this patch description because it is a whac-a-mole to fix other places. In other word, the patch alone fixes quite a few false positives and potential real deadlocks. Maybe Andrew please has a look at this directly?
Powered by blists - more mailing lists