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: <20160524140809.GG20829@redhat.com> Date: Tue, 24 May 2016 16:08:09 +0200 From: Andrea Arcangeli <aarcange@...hat.com> To: Mika Westerberg <mika.westerberg@...ux.intel.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, linux-kernel@...r.kernel.org Subject: Re: v4.6 kernel BUG at mm/rmap.c:1101! On Tue, May 24, 2016 at 11:12:23AM +0300, Mika Westerberg wrote: > Hmm, the kernel shipped with Fedora 23 has that enabled: > > lahna % grep CONFIG_DEBUG_VM /boot/config-4.4.9-300.fc23.x86_64 > CONFIG_DEBUG_VM=y > # CONFIG_DEBUG_VM_VMACACHE is not set > # CONFIG_DEBUG_VM_RB is not set Yes, it would have been more accurate to say "enterprise", not just "production". It's great to run Fedora with CONFIG_DEBUG_VM=y and I'd recommend to keep it that way, so it contributes to stronger runtime validation of the VM invariants. I keep CONFIG_DEBUG_VM=y on all my systems too of course. Also note the RHEL debug kernel has CONFIG_DEBUG_VM=y also enabled, but only the debug kernel. In general while testing new kernels with new VM modifications it's good idea to set CONFIG_DEBUG_VM=y, if you can afford the occasional false positive like in this case and it's not an enterprise production kernel, where clearly all testing should have already happened before that become "enterprise" ready in the first place, so we can save a few cycles. Lately we got VM_WARN_ON too and I added to my tree recently: +#define VM_WARN_ON_PAGE(cond, page) \ + do { \ + if (unlikely(cond)) { \ + dump_page(page, "VM_WARN_ON_PAGE(" __stringify(cond)")");\ + __WARN(); \ + } \ + } while (0) So we could convert some... to reduce the pain of a false positive, but in cases like the one that triggered I'm not sure it'd be good idea to switch it to a WARN_ON as it may be a sign of memory corruption if the assert fails (after the patch) and keeping going after memory corruption can actually do more harm than good. One thing to keep =n however is CONFIG_DEBUG_VM_RB=n, that one is expensive and that's why it has its own separate knob to be able to disable it while keeping CONFIG_DEBUG_VM=y. IIRC I kept originally under #if 0... so I wouldn't recommend to enable VM_RB on production (it's too much overhead), that's a nice validation but for development only. Thanks, Andrea
Powered by blists - more mailing lists