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]
Date:   Fri, 5 Mar 2021 10:11:32 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Tim Chen <tim.c.chen@...ux.intel.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Ying Huang <ying.huang@...el.com>, linux-mm@...ck.org,
        cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] mm: Fix dropped memcg from mem cgroup soft limit
 tree

On Thu 04-03-21 09:35:08, Tim Chen wrote:
> 
> 
> On 2/18/21 11:13 AM, Michal Hocko wrote:
> 
> > 
> > Fixes: 4e41695356fb ("memory controller: soft limit reclaim on contention")
> > Acked-by: Michal Hocko <mhocko@...e.com>
> > 
> > Thanks!
> >> ---
> >>  mm/memcontrol.c | 6 +++++-
> >>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> >> index ed5cc78a8dbf..a51bf90732cb 100644
> >> --- a/mm/memcontrol.c
> >> +++ b/mm/memcontrol.c
> >> @@ -3505,8 +3505,12 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order,
> >>  			loop > MEM_CGROUP_MAX_SOFT_LIMIT_RECLAIM_LOOPS))
> >>  			break;
> >>  	} while (!nr_reclaimed);
> >> -	if (next_mz)
> >> +	if (next_mz) {
> >> +		spin_lock_irq(&mctz->lock);
> >> +		__mem_cgroup_insert_exceeded(next_mz, mctz, excess);
> >> +		spin_unlock_irq(&mctz->lock);
> >>  		css_put(&next_mz->memcg->css);
> >> +	}
> >>  	return nr_reclaimed;
> >>  }
> >>  
> >> -- 
> >> 2.20.1
> > 
> 
> Mel,
> 
> Reviewing this patch a bit more, I realize that there is a chance that the removed
> next_mz could be inserted back to the tree from a memcg_check_events
> that happen in between.  So we need to make sure that the next_mz
> is indeed off the tree and update the excess value before adding it
> back.  Update the patch to the patch below.

This scenario is certainly possible but it shouldn't really matter much
as __mem_cgroup_insert_exceeded bails out when the node is on the tree
already.
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ