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
| ||
|
Message-ID: <20170614125524.qxg3dkfbcaqxscp3@thunk.org> Date: Wed, 14 Jun 2017 08:55:24 -0400 From: Theodore Ts'o <tytso@....edu> To: Ramin Farajpour Cami <ramin.blackhat@...il.com> Cc: adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org, syzkaller@...glegroups.com Subject: Re: CRASH : RCU detected stall On Wed, Jun 14, 2017 at 10:02:00AM +0430, Ramin Farajpour Cami wrote: > > Unfortunately it's not reproducible. do you have idea about it? Nope. Note that this isn't necessarily an ext4 bug. We have two complaints about an rcu_sched thread getting staved and an NMI handler getting taking too long to run: rcu_sched kthread starved for 22270 jiffies! g2951 c2950 f0x0 INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 2.762 msecs We also happened be doing writeback on another CPU and the ext4 thread was doing a slab allocation. What ultimiately caused the RCU starvation is not at all clear. Were we spinning inside the slab allocator, or not? Getting some magic-sysrq triggers to see if the PC was always in the slab allocator would be useful. And if that's the case, it's not clear what might have caused us to spinning in the slab allocator. It could be due to some slab state getting corrupted by a previous system call, and ext4 was just unlucky enough to do the slab allocation which caused it to go for a loop. We just don't have enough information to do any kind of useful investigation. - Ted
Powered by blists - more mailing lists