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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 27 Jan 2018 14:43:29 -0800 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Dave Jones <davej@...emonkey.org.uk>, Linux Kernel <linux-kernel@...r.kernel.org>, linux-mm <linux-mm@...ck.org>, Network Development <netdev@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org> Subject: Re: [4.15-rc9] fs_reclaim lockdep trace On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones <davej@...emonkey.org.uk> wrote: > On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: > > Just triggered this on a server I was rsync'ing to. > > Actually, I can trigger this really easily, even with an rsync from one > disk to another. Though that also smells a little like networking in > the traces. Maybe netdev has ideas. Is this new to 4.15? Or is it just that you're testing something new? If it's new and easy to repro, can you just bisect it? And if it isn't new, can you perhaps check whether it's new to 4.14 (ie 4.13 being ok)? Because that fs_reclaim_acquire/release() debugging isn't new to 4.15, but it was rewritten for 4.14.. I'm wondering if that remodeling ended up triggering something. Adding PeterZ to the participants list in case he has ideas. I'm not seeing what would be the problem in that call chain from hell. Linus
Powered by blists - more mailing lists