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  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:	Sun, 21 Apr 2013 13:34:47 -0700
From:	"Paul E. McKenney" <>
To:	Borislav Petkov <>
Cc:	x86-ml <>, lkml <>,
Subject: Re: irq 16: nobody cared

On Sun, Apr 21, 2013 at 09:06:55PM +0200, Borislav Petkov wrote:
> On Sun, Apr 21, 2013 at 11:56:09AM -0700, Paul E. McKenney wrote:
> > CONFIG_RCU_FAST_NO_HZ will definitely change the timing, for example,
> > increasing grace-period durations by up to a factor of four.
> >
> > One way to figure out if this is the problem would be to either (1)
> > apply the following patch (assuming you have no more than a few tens
> > of CPUs)
> Only 8 - I'm modest that way :)

;-) ;-) ;-)

> > or (2) setting the sysfs rcutree.rcu_expedited variable to 1 just before
> > suspending the system.
> > 
> > Either approach will force RCU to always use the faster expedited
> > grace periods for synchronize_rcu() and friends.  They will -not- help
> > if someone has open-coded synchronize_rcu() in terms of call_rcu(),
> > though.
> Right,
> # echo 1 > /sys/kernel/rcu_expedited
> helped.
> No warning, no delay, 2 suspend/resume cycles back-to-back. So, a
> probable fix could be to force-enable the expedited grace periods during
> suspend...?

Fix for the slowness, for sure!

For the irq warning, it is most likely simply hiding the problem.

Still, speeding up suspend sounds valuable.  The connection between
suspending and expediting grace periods probably needs to be in
the kernel -- people will undoubtedly want to expedite them for short
periods of time at runtime, like when starting wireshark, and it would
be good to minimize unnecessary dependency on scripting.

It would not be hard to provide an in-kernel primitive for expediting.

Hmmm...  When you resume, is the expediting still set?  (Can't see why
it would not be.)  If so, it would be good to have some way of disabling
it after boot completes.  Which, as noted in another thread, requires
that RCU be informed of when boot completes.  ;-)

							Thanx, Paul

> Hmmm.
> Thanks.
> -- 
> Regards/Gruss,
>     Boris.
> Sent from a fat crate under my desk. Formatting is fine.
> --

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists