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: <CAFTL4hxPSp1fs4=2g0yFs0d5nFisfUsfDAA9bHWcu+-+tO_ySw@mail.gmail.com>
Date:	Wed, 28 Nov 2012 13:55:42 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Li Zhong <zhong@...ux.vnet.ibm.com>
Cc:	linux-next list <linux-next@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, paulmck@...ux.vnet.ibm.com,
	sasha.levin@...cle.com, gleb@...hat.com, avi@...hat.com
Subject: Re: [RFC PATCH v2] Add rcu user eqs exception hooks for async page fault

2012/11/28 Li Zhong <zhong@...ux.vnet.ibm.com>:
> Thank you all for the review and education.
>
> Below are my current understandings and an update version. Would you
> please help to review it again and give your comments?
>
> Thanks, Zhong
>
> Now it seems to me that it is legal to call rcu_irq_exit/enter() without
> a matching rcu_irq_enter/exit() if the cpu is in non rcu idle state.
>
> As opposite, it is illegal to call rcu_irq_exit() without a matching
> rcu_irq_enter() if the cpu is in rcu idle state.
>
> But it seems legal to call rcu_irq_enter() without a matching
> rcu_irq_exit() if the cpu is in rcu idle state, regarding the
> dynticks_nesting value.   However, it seems not good to exit the rcu
> idle state, if we are actually entering into idle mode, so maybe it's
> better to call a matching rcu_irq_exit() before actually idle?
>
> As Frederic pointed out, we need a rcu_user_exit() to exit the user eqs
> (if we are in this state) in the beginning. But after some more
> thinking, I guess we might also need to call rcu_user_enter() after the
> waiting, if we get this page fault from user space. So maybe it's better
> to use rcu user eqs exception hooks here?

Makes sense.

>
> With rcu_user_exit() at the beginning, now rcu_irq_enter() only protects
> the cpu idle eqs, but it's not good to call rcu_irq_exit() after the cpu
> halt and the page ready.

Hmm, why is it not good?

>
> So I still want to remove it. And later if it shows that we really needs
> rcu somewhere in this code path, maybe we could use RCU_NONIDLE() to
> protect it. ( The suspicious RCU usage reported in commit
> c5e015d4949aa665 seems related to schedule(), which is not in the code
> path if we are in cpu idle eqs )

Yes but if rcu_irq_*() calls are fine to be called there, and I
believe they are because exception_enter() exits the user mode, we
should start to protect there right now instead of waiting for a
potential future warning of illegal RCU use.

>
> I think we still need Gleb's patch about the idle check in
> kvm_async_pf_task_wait(), and maybe another patch for the
> exit_idle()/enter_idle() issue.

Right.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ