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: <aaa26dbb-e3b5-42a3-aac0-1cb594a272b6@suse.cz>
Date: Tue, 14 Jan 2025 10:20:28 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Michal Hocko <mhocko@...e.com>, Andrew Morton <akpm@...ux-foundation.org>
Cc: Chen Ridong <chenridong@...weicloud.com>, hannes@...xchg.org,
 yosryahmed@...gle.com, roman.gushchin@...ux.dev, shakeel.butt@...ux.dev,
 muchun.song@...ux.dev, davidf@...eo.com, handai.szj@...bao.com,
 rientjes@...gle.com, kamezawa.hiroyu@...fujitsu.com,
 RCU <rcu@...r.kernel.org>, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 cgroups@...r.kernel.org, chenridong@...wei.com, wangweiyang2@...wei.com
Subject: Re: [PATCH v3] memcg: fix soft lockup in the OOM process

On 1/14/25 09:40, Michal Hocko wrote:
> On Mon 13-01-25 19:45:46, Andrew Morton wrote:
>> On Mon, 13 Jan 2025 14:51:55 +0800 Chen Ridong <chenridong@...weicloud.com> wrote:
>> 
>> > >> @@ -430,10 +431,15 @@ static void dump_tasks(struct oom_control *oc)
>> > >>  		mem_cgroup_scan_tasks(oc->memcg, dump_task, oc);
>> > >>  	else {
>> > >>  		struct task_struct *p;
>> > >> +		int i = 0;
>> > >>  
>> > >>  		rcu_read_lock();
>> > >> -		for_each_process(p)
>> > >> +		for_each_process(p) {
>> > >> +			/* Avoid potential softlockup warning */
>> > >> +			if ((++i & 1023) == 0)
>> > >> +				touch_softlockup_watchdog();
>> > > 
>> > > This might suppress the soft lockup, but won't a rcu stall still be detected?
>> > 
>> > Yes, rcu stall was still detected.

"was" or "would be"? I thought only the memcg case was observed, or was that
some deliberate stress test of the global case? (or the pr_info() console
stress test mentioned earlier, but created outside of the oom code?)

>> > For global OOM, system is likely to struggle, do we have to do some
>> > works to suppress RCU detete?
>> 
>> rcu_cpu_stall_reset()?
> 
> Do we really care about those? The code to iterate over all processes
> under RCU is there (basically) since ever and yet we do not seem to have
> many reports of stalls? Chen's situation is specific to memcg OOM and
> touching the global case was mostly for consistency reasons.

Then I'd rather not touch the global case then if it's theoretical? It's not
even exactly consistent, given it's a cond_resched() in the memcg code (that
can be eventually automatically removed once/if lazy preempt becomes the
sole implementation), but the touch_softlockup_watchdog() would remain,
while doing only half of the job?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ