Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp4713693ybl; Mon, 26 Aug 2019 14:51:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqxqhAaJGRdv5Gc2VBHPwlsDQWjSJO49GCSgZWdpSkBZk3RQWFYgyjJn0Y3sd/xfJe/MKrJr X-Received: by 2002:a62:26c4:: with SMTP id m187mr23247475pfm.49.1566856317997; Mon, 26 Aug 2019 14:51:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566856317; cv=none; d=google.com; s=arc-20160816; b=GPxOlu1pAnd5zxR26IVjTXCLrrNOpjUI2RuuRPgvdTktnr8H9HnB2f5i+DCaxhRrm8 AlozifQQRE8Cs1MtB6HcPlp7JhBHzfW35cH+WAghMoOjNL32oH1JkW9KTsPx/3DvFyPl Z1rIH6CI6i+icDhwYOyaSRfQuZVTmbpc5H1iLb/l8HGOEkJ2VdO4l2/8HUyFGiLXi8MU N9YfM2Mv0+2vHPGgDc3yYuVM+lTZLzo8osXI5Z3w/CSuh7Hp+vqNNRqzl47STXF4UinP j49l6+kGhFj9GsEI3IsRmmx6zPH6hWPpagbXZ2mYyyLLmBVbmXCjprcpnh4P1qqXXJEu rkbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Hvc+94UsrSo0dvtxcfDnaVeEmPfhp0JVZ15+D+5kcxs=; b=I2Fkgc37KSZv75Biz9DVOX+NXZXKrg5CViFtA23T8OHZp3SvoHpHxpkr1xGHG6n1Ky FFcy92qBxs5BytnwD87CFOMTpLJfgYyKYqxdyusbwBqs3Eo66QcSyqdGl/xUvsGBAi+d 8275LHYMNeKe8I2v4uQnwIRuuL086aF/Zw7cbzDHOIg2LbzFh72PjEPq5Nmns+7ir4zu zPa7wf7Gx5wpHEYPb/IEttAdN+TGk/8WsJ0n+OlOcdSBm/EayPWVC9n12rn0gki45JNu pRkJvZNFpwLVcueQ4y3xS12qaF7oCCCStcVkQIkqjShSmbUU+JAt6AVaTYXfLBw4G4c6 uWXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=VFNW6E8S; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v20si10794297plo.394.2019.08.26.14.51.42; Mon, 26 Aug 2019 14:51:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=VFNW6E8S; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388035AbfHZUOk (ORCPT + 99 others); Mon, 26 Aug 2019 16:14:40 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:41481 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388014AbfHZUOh (ORCPT ); Mon, 26 Aug 2019 16:14:37 -0400 Received: by mail-ed1-f66.google.com with SMTP id w5so28140213edl.8 for ; Mon, 26 Aug 2019 13:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Hvc+94UsrSo0dvtxcfDnaVeEmPfhp0JVZ15+D+5kcxs=; b=VFNW6E8Sf5IO/vio8FpctFWFmv5uJj0ggZOq4v0zfOgDSSsylE0MV0cDqxpUJ0O3+J jJbfISI7yr3sm+aoIHAjZ4ksh6Ts3a0rodKmpkYQuExF0IXSOGXHenwQjq/PFnh2xjem JCdCkwAuhHfBH1F/2PAMX7b12BePRCojTK8VM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Hvc+94UsrSo0dvtxcfDnaVeEmPfhp0JVZ15+D+5kcxs=; b=iDV4Sa7bxvbuzBAQFq+1Up3PB3pmr3cPpNhL2/MWbVGGFb8hjRnI4VECR5lOGnsA4T 0iYCvN3lWKpy/Z2UE9Z911gbTFaaiwFMc95GCtG0Mc/cRCK+i/oJ4V6AL6VPNnPfhj+M iKcvAg7Tm9sNFkAcK02xW5QkwdkmB4CM5oeFPPSgUskKkCcR+jUdhLbQPJmdXgLU0HjY FEnXXFcMze6SW3ajYUhFxjgbIKEXGR3MWIXpgkn9mcufOTJtYOa3N0/68Y6Bdh5MihyA wi1bjqJHFZx3AfFeMJZwoounAztpOvuYnlW1rft1gR6zXEs93DEFU4PkHq0ROtWbq8Wl WUtg== X-Gm-Message-State: APjAAAXXxa/Uj6gDmCu7AGZNNP163RUTUjpy0/7SLrS/2dROOyl3U6yK WLP5k3VlZRj7BCm5WNXkT1qGe1aHLlgUEA== X-Received: by 2002:a17:906:3b09:: with SMTP id g9mr18654098ejf.297.1566850475866; Mon, 26 Aug 2019 13:14:35 -0700 (PDT) Received: from phenom.ffwll.local (212-51-149-96.fiber7.init7.net. [212.51.149.96]) by smtp.gmail.com with ESMTPSA id j25sm3000780ejb.49.2019.08.26.13.14.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Aug 2019 13:14:35 -0700 (PDT) From: Daniel Vetter To: LKML Cc: Linux MM , DRI Development , Daniel Vetter , Jason Gunthorpe , Peter Zijlstra , Ingo Molnar , Andrew Morton , Michal Hocko , David Rientjes , =?UTF-8?q?Christian=20K=C3=B6nig?= , =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= , Masahiro Yamada , Wei Wang , Andy Shevchenko , Thomas Gleixner , Jann Horn , Feng Tang , Kees Cook , Randy Dunlap , Daniel Vetter Subject: [PATCH 3/5] kernel.h: Add non_block_start/end() Date: Mon, 26 Aug 2019 22:14:23 +0200 Message-Id: <20190826201425.17547-4-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20190826201425.17547-1-daniel.vetter@ffwll.ch> References: <20190826201425.17547-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In some special cases we must not block, but there's not a spinlock, preempt-off, irqs-off or similar critical section already that arms the might_sleep() debug checks. Add a non_block_start/end() pair to annotate these. This will be used in the oom paths of mmu-notifiers, where blocking is not allowed to make sure there's forward progress. Quoting Michal: "The notifier is called from quite a restricted context - oom_reaper - which shouldn't depend on any locks or sleepable conditionals. The code should be swift as well but we mostly do care about it to make a forward progress. Checking for sleepable context is the best thing we could come up with that would describe these demands at least partially." Peter also asked whether we want to catch spinlocks on top, but Michal said those are less of a problem because spinlocks can't have an indirect dependency upon the page allocator and hence close the loop with the oom reaper. Suggested by Michal Hocko. v2: - Improve commit message (Michal) - Also check in schedule, not just might_sleep (Peter) v3: It works better when I actually squash in the fixup I had lying around :-/ v4: Pick the suggestion from Andrew Morton to give non_block_start/end some good kerneldoc comments. I added that other blocking calls like wait_event pose similar issues, since that's the other example we discussed. Cc: Jason Gunthorpe Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Andrew Morton Cc: Michal Hocko Cc: David Rientjes Cc: "Christian König" Cc: Daniel Vetter Cc: "Jérôme Glisse" Cc: linux-mm@kvack.org Cc: Masahiro Yamada Cc: Wei Wang Cc: Andy Shevchenko Cc: Thomas Gleixner Cc: Jann Horn Cc: Feng Tang Cc: Kees Cook Cc: Randy Dunlap Cc: linux-kernel@vger.kernel.org Acked-by: Christian König (v1) Acked-by: Peter Zijlstra (Intel) Signed-off-by: Daniel Vetter --- include/linux/kernel.h | 25 ++++++++++++++++++++++++- include/linux/sched.h | 4 ++++ kernel/sched/core.c | 19 ++++++++++++++----- 3 files changed, 42 insertions(+), 6 deletions(-) diff --git a/include/linux/kernel.h b/include/linux/kernel.h index 4fa360a13c1e..82f84cfe372f 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -217,7 +217,9 @@ extern void __cant_sleep(const char *file, int line, int preempt_offset); * might_sleep - annotation for functions that can sleep * * this macro will print a stack trace if it is executed in an atomic - * context (spinlock, irq-handler, ...). + * context (spinlock, irq-handler, ...). Additional sections where blocking is + * not allowed can be annotated with non_block_start() and non_block_end() + * pairs. * * This is a useful debugging help to be able to catch problems early and not * be bitten later when the calling function happens to sleep when it is not @@ -233,6 +235,25 @@ extern void __cant_sleep(const char *file, int line, int preempt_offset); # define cant_sleep() \ do { __cant_sleep(__FILE__, __LINE__, 0); } while (0) # define sched_annotate_sleep() (current->task_state_change = 0) +/** + * non_block_start - annotate the start of section where sleeping is prohibited + * + * This is on behalf of the oom reaper, specifically when it is calling the mmu + * notifiers. The problem is that if the notifier were to block on, for example, + * mutex_lock() and if the process which holds that mutex were to perform a + * sleeping memory allocation, the oom reaper is now blocked on completion of + * that memory allocation. Other blocking calls like wait_event() pose similar + * issues. + */ +# define non_block_start() \ + do { current->non_block_count++; } while (0) +/** + * non_block_end - annotate the end of section where sleeping is prohibited + * + * Closes a section opened by non_block_start(). + */ +# define non_block_end() \ + do { WARN_ON(current->non_block_count-- == 0); } while (0) #else static inline void ___might_sleep(const char *file, int line, int preempt_offset) { } @@ -241,6 +262,8 @@ extern void __cant_sleep(const char *file, int line, int preempt_offset); # define might_sleep() do { might_resched(); } while (0) # define cant_sleep() do { } while (0) # define sched_annotate_sleep() do { } while (0) +# define non_block_start() do { } while (0) +# define non_block_end() do { } while (0) #endif #define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0) diff --git a/include/linux/sched.h b/include/linux/sched.h index b6ec130dff9b..e8bb965f5019 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -980,6 +980,10 @@ struct task_struct { struct mutex_waiter *blocked_on; #endif +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP + int non_block_count; +#endif + #ifdef CONFIG_TRACE_IRQFLAGS unsigned int irq_events; unsigned long hardirq_enable_ip; diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 45dceec209f4..0d01c7994a9a 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3752,13 +3752,22 @@ static noinline void __schedule_bug(struct task_struct *prev) /* * Various schedule()-time debugging checks and statistics: */ -static inline void schedule_debug(struct task_struct *prev) +static inline void schedule_debug(struct task_struct *prev, bool preempt) { #ifdef CONFIG_SCHED_STACK_END_CHECK if (task_stack_end_corrupted(prev)) panic("corrupted stack end detected inside scheduler\n"); #endif +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP + if (!preempt && prev->state && prev->non_block_count) { + printk(KERN_ERR "BUG: scheduling in a non-blocking section: %s/%d/%i\n", + prev->comm, prev->pid, prev->non_block_count); + dump_stack(); + add_taint(TAINT_WARN, LOCKDEP_STILL_OK); + } +#endif + if (unlikely(in_atomic_preempt_off())) { __schedule_bug(prev); preempt_count_set(PREEMPT_DISABLED); @@ -3870,7 +3879,7 @@ static void __sched notrace __schedule(bool preempt) rq = cpu_rq(cpu); prev = rq->curr; - schedule_debug(prev); + schedule_debug(prev, preempt); if (sched_feat(HRTICK)) hrtick_clear(rq); @@ -6641,7 +6650,7 @@ void ___might_sleep(const char *file, int line, int preempt_offset) rcu_sleep_check(); if ((preempt_count_equals(preempt_offset) && !irqs_disabled() && - !is_idle_task(current)) || + !is_idle_task(current) && !current->non_block_count) || system_state == SYSTEM_BOOTING || system_state > SYSTEM_RUNNING || oops_in_progress) return; @@ -6657,8 +6666,8 @@ void ___might_sleep(const char *file, int line, int preempt_offset) "BUG: sleeping function called from invalid context at %s:%d\n", file, line); printk(KERN_ERR - "in_atomic(): %d, irqs_disabled(): %d, pid: %d, name: %s\n", - in_atomic(), irqs_disabled(), + "in_atomic(): %d, irqs_disabled(): %d, non_block: %d, pid: %d, name: %s\n", + in_atomic(), irqs_disabled(), current->non_block_count, current->pid, current->comm); if (task_stack_end_corrupted(current)) -- 2.23.0