From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752211AbcAERVr (ORCPT ); Tue, 5 Jan 2016 12:21:47 -0500 Received: from arcturus.aphlor.org ([188.246.204.175]:33734 "EHLO arcturus.aphlor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751859AbcAERVk (ORCPT ); Tue, 5 Jan 2016 12:21:40 -0500 Date: Tue, 5 Jan 2016 12:21:36 -0500 From: Dave Jones To: Michal Hocko Cc: Linux Kernel , linux-mm@kvack.org, David Rientjes Subject: Re: [4.4-rc7] spinlock recursion while oom'ing. Message-ID: <20160105172136.GA28066@codemonkey.org.uk> Mail-Followup-To: Dave Jones , Michal Hocko , Linux Kernel , linux-mm@kvack.org, David Rientjes References: <20160103222728.GA11973@codemonkey.org.uk> <20160105163535.GD15594@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160105163535.GD15594@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "arcturus.aphlor.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Tue, Jan 05, 2016 at 05:35:36PM +0100, Michal Hocko wrote: > [CCing David] > > On Sun 03-01-16 17:27:28, Dave Jones wrote: > > This is an odd one.. > > > > Out of memory: Kill process 5861 (trinity-c10) score 504 or sacrifice child > > BUG: spinlock recursion on CPU#1, trinity-c8/8828 > > lock: 0xffff8800a3635410, .magic: dead4ead, .owner: trinity-c8/8828, .owner_cpu: 1 > > CPU: 1 PID: 8828 Comm: trinity-c8 Not tainted 4.4.0-rc7-gelk-debug+ #3 > > 00000000000001f8 ffff8800968d7808 ffffffff9a4d4451 ffff8800a3635410 > > ffff8800968d7838 ffffffff9a117b36 ffff8800a3635410 ffff8800a3635420 > > ffff8800a3635410 ffff8800a3635398 ffff8800968d7870 ffffffff9a117d63 > > Call Trace: > > [] dump_stack+0x4e/0x7d > > [] spin_dump+0xc6/0x130 > > [] do_raw_spin_lock+0x163/0x1a0 > > [] _raw_spin_lock+0x1f/0x30 > > [] find_lock_task_mm+0x5b/0xd0 > > [] oom_kill_process+0x2a0/0x660 > > [] out_of_memory+0x45d/0x4b0 > > Hmm, this is indeed weird. We are certainly not holding task_lock during > the allocation AFAICS (if yes that would be a GFP_KERNEL allocation with > a spinlock so I would assume a blow up earlier than when entering OOM). > > oom_badness unlocks in all paths AFAICS. oom_kill_process will lock the > victim again but it releases the lock as well. dump_tasks the same. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 05, 2016 at 05:35:36PM +0100, Michal Hocko wrote: > [CCing David] > > On Sun 03-01-16 17:27:28, Dave Jones wrote: > > This is an odd one.. > > > > Out of memory: Kill process 5861 (trinity-c10) score 504 or sacrifice child > > BUG: spinlock recursion on CPU#1, trinity-c8/8828 > > lock: 0xffff8800a3635410, .magic: dead4ead, .owner: trinity-c8/8828, .owner_cpu: 1 > > CPU: 1 PID: 8828 Comm: trinity-c8 Not tainted 4.4.0-rc7-gelk-debug+ #3 > > 00000000000001f8 ffff8800968d7808 ffffffff9a4d4451 ffff8800a3635410 > > ffff8800968d7838 ffffffff9a117b36 ffff8800a3635410 ffff8800a3635420 > > ffff8800a3635410 ffff8800a3635398 ffff8800968d7870 ffffffff9a117d63 > > Call Trace: > > [] dump_stack+0x4e/0x7d > > [] spin_dump+0xc6/0x130 > > [] do_raw_spin_lock+0x163/0x1a0 > > [] _raw_spin_lock+0x1f/0x30 > > [] find_lock_task_mm+0x5b/0xd0 > > [] oom_kill_process+0x2a0/0x660 > > [] out_of_memory+0x45d/0x4b0 > > Hmm, this is indeed weird. We are certainly not holding task_lock during > the allocation AFAICS (if yes that would be a GFP_KERNEL allocation with > a spinlock so I would assume a blow up earlier than when entering OOM). > > oom_badness unlocks in all paths AFAICS. oom_kill_process will lock the > victim again but it releases the lock as well. dump_tasks the same. sorry, turned out to be a (broken) leftover debugging patch that I'd had applied that I thought I'd dropped but hadn't.. Dave