[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8bbc1658-03b2-f64e-d11a-153da3eb723a@virtuozzo.com>
Date: Tue, 10 Aug 2021 14:04:07 +0300
From: Vasily Averin <vvs@...tuozzo.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, kernel@...nvz.org
Subject: Re: [PATCH] mm: use in_task() in __gfp_pfmemalloc_flags()
On 8/9/21 9:24 PM, Andrew Morton wrote:
> On Mon, 9 Aug 2021 11:23:29 +0300 Vasily Averin <vvs@...tuozzo.com> wrote:
>
>> obsoleted in_interrupt() include task context with disabled BH,
>> it's better to use in_task() instead.
>
> Are these just blind conversions, or have you verified in each case
> that it is correct to newly take these code paths inside
> local_bh_disable()?
>
> If "yes" then please provide the reasoning in each changelog?
I cannot say that it is blind conversion.
In all fixed patches in_interrupt() is used to identify task context and access current.
it is incorrect because in_interrupt() include task context with disabled BH
Recently I hit some bug and spend a lot of time for its investigation.
Right now I investigate some other issue in neighborhood, noticed sadly familiar pattern
and decided fix them too. Then noticed few more similar places.
In fact I would like to replace all such places in mm in one patch.
Do you want to consider each of these cases separately?
In this particular case in_interrupt() is used to prevent current access.
I think it is safe to look at current->flags and call oom_reserves_allowed()
for tasks with disabled BH and I believe this should provide more correct result.
Historically this check was added to handle interrupt context and said nothing
special about task context with disabled BH.
Could you please clarify wich kind of arguments should I provide?
Thank you,
Vasily Averin
Powered by blists - more mailing lists