Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp3552285ima; Mon, 4 Feb 2019 00:57:08 -0800 (PST) X-Google-Smtp-Source: ALg8bN4678rv+gIeKqyQ6dlyMz+JyvJt7qwR8/hNkXY0KOpgs6NndtTJcuU+CR5qee3U476OtTX+ X-Received: by 2002:a17:902:a58c:: with SMTP id az12mr43637637plb.299.1549270628345; Mon, 04 Feb 2019 00:57:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549270628; cv=none; d=google.com; s=arc-20160816; b=DhutBPxN6CS+6KhBJ5OH2cVD6pHW4lqmrLxQQTfgZuNqiADujurKyNNc7Oil5TCiet s5yw9kzKAach0fyx20Cbg21/xmK+m66rHvRcrq3BzKp8eBAcgXqXjTa7tXZgSlOe7Vh9 ewBkGcLyRU3XO8tpPEUnGM6EdiUjM9Ictan5u/Q0DlOv3eCGSeDybjvOZZGEssfmEo4U d9U7X+gRqggh+TZS5Bar6pml3qPKnR5m719F0jGhVPWMamjY7wuV+RPh+3RnR7g8gP+0 WnGRY1ox8hMG1ubx6NB75wFYBMD1yvs8+R4CXhl5j4GlIPRY+bS7eUVeGKJlz32NK8He dEGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:mime-version:robot-unsubscribe:robot-id :git-commit-id:subject:to:references:in-reply-to:reply-to:cc :message-id:from:date; bh=YgMRJJDb2oqgE9HLxrvzDMCM9kIOaHjHZPiEHMQe2FU=; b=LX7R7AnH0xLBlGOoD6vpXx+nuAZyV8o2SKYVEZ7KuIQz4iNFAyUtL36m3Ri2rjpX8b Pgvtz7Me9tcoxpYcAP2yCFr9XkdAmZRuxIdtOXhda34NDJ0p9tAxsR7fVyaSPnftwMc4 CtoEXOAL6l+KEDsxs3H714jvMn7TH8chntGPW8nIeBsadkygSufjTFb2wGtNTDokGUf7 UPMI6jesHIqX2Jp+zsR/swM6jEE5+2UP589dycvTC0cqBLisb3psg1ZYUlC9MHOOu7Hw Z7sxMhxxfO+sqfBOnjvdUZTPngWFPkNsAWDI7IsscbnzwDIvEo0lK9ePsfECn4XEiaB0 7VJg== ARC-Authentication-Results: i=1; mx.google.com; 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 a8si14283233pgi.359.2019.02.04.00.56.52; Mon, 04 Feb 2019 00:57:08 -0800 (PST) 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; 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 S1728679AbfBDI4h (ORCPT + 99 others); Mon, 4 Feb 2019 03:56:37 -0500 Received: from terminus.zytor.com ([198.137.202.136]:38927 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728648AbfBDI4g (ORCPT ); Mon, 4 Feb 2019 03:56:36 -0500 Received: from terminus.zytor.com (localhost [127.0.0.1]) by terminus.zytor.com (8.15.2/8.15.2) with ESMTPS id x148uLut358076 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Feb 2019 00:56:21 -0800 Received: (from tipbot@localhost) by terminus.zytor.com (8.15.2/8.15.2/Submit) id x148uLfD358073; Mon, 4 Feb 2019 00:56:21 -0800 Date: Mon, 4 Feb 2019 00:56:21 -0800 X-Authentication-Warning: terminus.zytor.com: tipbot set sender to tipbot@zytor.com using -f From: tip-bot for Elena Reshetova Message-ID: Cc: tglx@linutronix.de, torvalds@linux-foundation.org, elena.reshetova@intel.com, mingo@kernel.org, hpa@zytor.com, peterz@infradead.org, keescook@chromium.org, dwindsor@gmail.com, ishkamiel@gmail.com, linux-kernel@vger.kernel.org, andrea.parri@amarulasolutions.com, efault@gmx.de Reply-To: linux-kernel@vger.kernel.org, andrea.parri@amarulasolutions.com, efault@gmx.de, tglx@linutronix.de, elena.reshetova@intel.com, torvalds@linux-foundation.org, mingo@kernel.org, peterz@infradead.org, hpa@zytor.com, keescook@chromium.org, ishkamiel@gmail.com, dwindsor@gmail.com In-Reply-To: <1547814450-18902-6-git-send-email-elena.reshetova@intel.com> References: <1547814450-18902-6-git-send-email-elena.reshetova@intel.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:sched/core] sched/core: Convert task_struct.stack_refcount to refcount_t Git-Commit-ID: f0b89d3958d73cd0785ec381f0ddf8efb6f183d8 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline X-Spam-Status: No, score=-0.8 required=5.0 tests=ALL_TRUSTED,BAYES_00, FREEMAIL_FORGED_REPLYTO,T_DATE_IN_FUTURE_96_Q autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on terminus.zytor.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: f0b89d3958d73cd0785ec381f0ddf8efb6f183d8 Gitweb: https://git.kernel.org/tip/f0b89d3958d73cd0785ec381f0ddf8efb6f183d8 Author: Elena Reshetova AuthorDate: Fri, 18 Jan 2019 14:27:30 +0200 Committer: Ingo Molnar CommitDate: Mon, 4 Feb 2019 08:53:56 +0100 sched/core: Convert task_struct.stack_refcount to refcount_t atomic_t variables are currently used to implement reference counters with the following properties: - counter is initialized to 1 using atomic_set() - a resource is freed upon counter reaching zero - once counter reaches zero, its further increments aren't allowed - counter schema uses basic atomic operations (set, inc, inc_not_zero, dec_and_test, etc.) Such atomic variables should be converted to a newly provided refcount_t type and API that prevents accidental counter overflows and underflows. This is important since overflows and underflows can lead to use-after-free situation and be exploitable. The variable task_struct.stack_refcount is used as pure reference counter. Convert it to refcount_t and fix up the operations. ** Important note for maintainers: Some functions from refcount_t API defined in lib/refcount.c have different memory ordering guarantees than their atomic counterparts. The full comparison can be seen in https://lkml.org/lkml/2017/11/15/57 and it is hopefully soon in state to be merged to the documentation tree. Normally the differences should not matter since refcount_t provides enough guarantees to satisfy the refcounting use cases, but in some rare cases it might matter. Please double check that you don't have some undocumented memory guarantees for this variable usage. For the task_struct.stack_refcount it might make a difference in following places: - try_get_task_stack(): increment in refcount_inc_not_zero() only guarantees control dependency on success vs. fully ordered atomic counterpart - put_task_stack(): decrement in refcount_dec_and_test() only provides RELEASE ordering and control dependency on success vs. fully ordered atomic counterpart Suggested-by: Kees Cook Signed-off-by: Elena Reshetova Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: David Windsor Reviewed-by: Hans Liljestrand Reviewed-by: Andrea Parri Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: akpm@linux-foundation.org Cc: viro@zeniv.linux.org.uk Link: https://lkml.kernel.org/r/1547814450-18902-6-git-send-email-elena.reshetova@intel.com Signed-off-by: Ingo Molnar --- include/linux/init_task.h | 1 + include/linux/sched.h | 2 +- include/linux/sched/task_stack.h | 2 +- init/init_task.c | 2 +- kernel/fork.c | 6 +++--- 5 files changed, 7 insertions(+), 6 deletions(-) diff --git a/include/linux/init_task.h b/include/linux/init_task.h index a7083a45a26c..6049baa5b8bc 100644 --- a/include/linux/init_task.h +++ b/include/linux/init_task.h @@ -13,6 +13,7 @@ #include #include #include +#include #include #include #include diff --git a/include/linux/sched.h b/include/linux/sched.h index 9d14d6864ca6..628bf13cb5a5 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1194,7 +1194,7 @@ struct task_struct { #endif #ifdef CONFIG_THREAD_INFO_IN_TASK /* A live task holds one reference: */ - atomic_t stack_refcount; + refcount_t stack_refcount; #endif #ifdef CONFIG_LIVEPATCH int patch_state; diff --git a/include/linux/sched/task_stack.h b/include/linux/sched/task_stack.h index 6a841929073f..2413427e439c 100644 --- a/include/linux/sched/task_stack.h +++ b/include/linux/sched/task_stack.h @@ -61,7 +61,7 @@ static inline unsigned long *end_of_stack(struct task_struct *p) #ifdef CONFIG_THREAD_INFO_IN_TASK static inline void *try_get_task_stack(struct task_struct *tsk) { - return atomic_inc_not_zero(&tsk->stack_refcount) ? + return refcount_inc_not_zero(&tsk->stack_refcount) ? task_stack_page(tsk) : NULL; } diff --git a/init/init_task.c b/init/init_task.c index aca34c89529f..46dbf546264d 100644 --- a/init/init_task.c +++ b/init/init_task.c @@ -61,7 +61,7 @@ struct task_struct init_task = { #ifdef CONFIG_THREAD_INFO_IN_TASK .thread_info = INIT_THREAD_INFO(init_task), - .stack_refcount = ATOMIC_INIT(1), + .stack_refcount = REFCOUNT_INIT(1), #endif .state = 0, .stack = init_stack, diff --git a/kernel/fork.c b/kernel/fork.c index 3f7e192e29f2..77059b211608 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -429,7 +429,7 @@ static void release_task_stack(struct task_struct *tsk) #ifdef CONFIG_THREAD_INFO_IN_TASK void put_task_stack(struct task_struct *tsk) { - if (atomic_dec_and_test(&tsk->stack_refcount)) + if (refcount_dec_and_test(&tsk->stack_refcount)) release_task_stack(tsk); } #endif @@ -447,7 +447,7 @@ void free_task(struct task_struct *tsk) * If the task had a separate stack allocation, it should be gone * by now. */ - WARN_ON_ONCE(atomic_read(&tsk->stack_refcount) != 0); + WARN_ON_ONCE(refcount_read(&tsk->stack_refcount) != 0); #endif rt_mutex_debug_task_free(tsk); ftrace_graph_exit_task(tsk); @@ -867,7 +867,7 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node) tsk->stack_vm_area = stack_vm_area; #endif #ifdef CONFIG_THREAD_INFO_IN_TASK - atomic_set(&tsk->stack_refcount, 1); + refcount_set(&tsk->stack_refcount, 1); #endif if (err)