linux-kernel - Re: 回复: [PATCH v2] kvfree_rcu: Release page cache under memory pressure

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: <20210130112152.GA1977@pc636>
Date:   Sat, 30 Jan 2021 12:21:52 +0100
From:   Uladzislau Rezki <urezki@...il.com>
To:     "Zhang, Qiang" <Qiang.Zhang@...driver.com>
Cc:     Uladzislau Rezki <urezki@...il.com>,
        "paulmck@...nel.org" <paulmck@...nel.org>,
        "joel@...lfernandes.org" <joel@...lfernandes.org>,
        "rcu@...r.kernel.org" <rcu@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: 回复: [PATCH v2] kvfree_rcu:
 Release page cache under memory pressure

On Sat, Jan 30, 2021 at 06:47:31AM +0000, Zhang, Qiang wrote:
> 
> 
> ________________________________________
> 发件人: Uladzislau Rezki <urezki@...il.com>
> 发送时间: 2021年1月29日 22:19
> 收件人: Zhang, Qiang
> 抄送: urezki@...il.com; paulmck@...nel.org; joel@...lfernandes.org; rcu@...r.kernel.org; linux-kernel@...r.kernel.org
> 主题: Re: [PATCH v2] kvfree_rcu: Release page cache under memory pressure
> 
> [Please note: This e-mail is from an EXTERNAL e-mail address]
> 
> On Fri, Jan 29, 2021 at 04:04:42PM +0800, qiang.zhang@...driver.com wrote:
> > From: Zqiang <qiang.zhang@...driver.com>
> >
> > Add free per-cpu existing krcp's page cache operation, when
> > the system is under memory pressure.
> >
> > Signed-off-by: Zqiang <qiang.zhang@...driver.com>
> > ---
> >  kernel/rcu/tree.c | 25 +++++++++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index c1ae1e52f638..ec098910d80b 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -3571,17 +3571,40 @@ void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
> >  }
> >  EXPORT_SYMBOL_GPL(kvfree_call_rcu);
> >
> > +static int free_krc_page_cache(struct kfree_rcu_cpu *krcp)
> > +{
> > +     unsigned long flags;
> > +     struct kvfree_rcu_bulk_data *bnode;
> > +     int i;
> > +
> > +     for (i = 0; i < rcu_min_cached_objs; i++) {
> > +             raw_spin_lock_irqsave(&krcp->lock, flags);
> >I am not sure why we should disable IRQs. I think it can be >avoided.
> 
> Suppose in multi CPU system, the kfree_rcu_shrink_scan function is runing on CPU2,
> and we just traverse to CPU2, and then call free_krc_page_cache function,
> if not disable irq, a interrupt may be occurs on CPU2 after the CPU2 corresponds to krcp variable 's lock be acquired,  if the interrupt or softirq handler function to call kvfree_rcu function, in this function , acquire CPU2 corresponds to krcp variable 's lock , will happen deadlock.
> Or in single CPU scenario.
> 
Right. Deadlock scenario. It went away from my head during writing that :)

Thanks!

--
Vlad Rezki