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] [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

Powered by Openwall GNU/*/Linux Powered by OpenVZ