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
| ||
|
Date: Mon, 28 Jan 2019 12:11:54 -0500 From: Sasha Levin <sashal@...nel.org> To: "Paul E. McKenney" <paulmck@...ux.ibm.com> Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org Subject: Re: [PATCH AUTOSEL 4.20 028/304] srcu: Prevent __call_srcu() counter wrap with read-side critical section On Mon, Jan 28, 2019 at 08:23:18AM -0800, Paul E. McKenney wrote: >On Mon, Jan 28, 2019 at 10:39:05AM -0500, Sasha Levin wrote: >> From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> >> >> [ Upstream commit 0607ba8403c4cdb253f8c5200ecf654dfb7790cc ] >> >> Ever since cdf7abc4610a ("srcu: Allow use of Tiny/Tree SRCU from >> both process and interrupt context"), it has been permissible >> to use SRCU read-side critical sections in interrupt context. >> This allows __call_srcu() to use SRCU read-side critical sections to >> prevent a new SRCU grace period from ending before the call to either >> srcu_funnel_gp_start() or srcu_funnel_exp_start completes, thus preventing >> SRCU grace-period counter overflow during that time. >> >> Note that this does not permit removal of the counter-wrap checks in >> srcu_gp_end(). These check are necessary to handle the case where >> a given CPU does not interact at all with SRCU for an extended time >> period. >> >> This commit therefore adds an SRCU read-side critical section to >> __call_srcu() in order to prevent grace period counter wrap during >> the funnel-locking process. >> >> Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com> >> Signed-off-by: Sasha Levin <sashal@...nel.org> > >Hello, Sasha, > >I recommend -against- backporting this one. It is a theoretical bug >that requires rather long preemption, so the risk of backporting likely >greatly exceeeds the risk of the bug actually happening, especially on >64-bit systems. I'll drop it, thanks Paul! -- Thanks, Sasha
Powered by blists - more mailing lists