[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871rkallqk.fsf@nanos.tec.linutronix.de>
Date: Thu, 13 Aug 2020 15:27:15 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Michal Hocko <mhocko@...e.com>, Uladzislau Rezki <urezki@...il.com>
Cc: paulmck@...nel.org, LKML <linux-kernel@...r.kernel.org>,
RCU <rcu@...r.kernel.org>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Matthew Wilcox <willy@...radead.org>,
"Theodore Y . Ts'o" <tytso@....edu>,
Joel Fernandes <joel@...lfernandes.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Oleksiy Avramchenko <oleksiy.avramchenko@...ymobile.com>
Subject: Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
Michal Hocko <mhocko@...e.com> writes:
> On Thu 13-08-20 11:58:40, Uladzislau Rezki wrote:
> [...]
>> Sorry for jumping in. We can rely on preemptable() for sure, if CONFIG_PREEMPT_RT
>> is enabled, something like below:
>>
>> if (IS_ENABLED_RT && preemptebale())
>
> Sure. I thought this was an RT specific thing that would be noop
> otherwise.
Well, even if RT specific it would be still something returning either
true or false unconditionally.
And guarding it with RT is not working either because then you are back
to square one with the problem which triggered the discussion in the
first place:
raw_spin_lock()
alloc()
if (RT && !preemptible()) <- False because RT == false
goto bail;
spin_lock(&zone->lock) --> LOCKDEP complains
So either you convince Paul not to do that or you need to do something
like I suggested in my other reply.
Thanks,
tglx
Powered by blists - more mailing lists