Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp550006iob; Wed, 4 May 2022 02:52:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxozj71gINy9KpSZzFwjB9p0JbuJ2JqfZFxMRyZHo01LE7KAI/qOq1AXkk+WCKnB8Da/IRn X-Received: by 2002:a17:902:9001:b0:156:a567:2683 with SMTP id a1-20020a170902900100b00156a5672683mr20692395plp.164.1651657971350; Wed, 04 May 2022 02:52:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651657971; cv=none; d=google.com; s=arc-20160816; b=NUAsQeq9XtAkK+kyjDTWj3Z19vLLYajM+ANrRBkeaOhdqA3AHXtslIoBj/fvfgql+I 48V3SRVx387NYAJxDuIo0jGf3ST1e5pShT8zrIUnL3nQ29Nz2p2yphOV1j2HdPXinyjA faGFttQSIzT4yj3nnWYCRTiVToXTrDH5askjgtacTWhpGDLC+t+YkYL0qRnKZV0OZ5ur RwPS8EysjmN8s1OpMRCDT3plHtL/zywuyy10WVpHwP9UAq5LrUB6VsnmxkqNzKgWAJlg zqgs5J7sKE++c3xnwgn0gVh4e1VhDG2O0E2gD5W9qCLB9qIPHhvddfTtNglJTjYs2bzb Qd4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=6MODaKHBQC2jmoOcp2lHXrPyXm0zMYwKkyqMwJH8hpc=; b=yoaw1GKwWjVkjne/Yjjw3ZNjMWSBe1LBDbFRwYyppU3y7VzSBSTX5rjmeNaFdu96jH SXeqHHntix6TFvo7VMoG4xwXFY4/hevJZ5KzEvaq4qi5rDBo7Jzir62S2hcbts49OnaM pzM88dDvIZey+4GnGcEMy2a9Wh7lormB7Rx02XWFJVhLDtpUpmYjRFf2abf24K+xSQoH mTOPPD3IWGwxEBHF0DKglX8mEwRxSzCJwNlK3XyyS9FEliS+y3KihYOjeKK6P+0ci79x o+yUJmRFMShHohhd/z3efXzRcUdbKcjIsyQCIpaEZyLRpi131bdSWZTnDTp/p9ORxKRj 9yVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o12-20020a170902d4cc00b001582e0ac939si7457356plg.450.2022.05.04.02.52.30; Wed, 04 May 2022 02:52:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346620AbiEDI4O (ORCPT + 99 others); Wed, 4 May 2022 04:56:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346836AbiEDIxq (ORCPT ); Wed, 4 May 2022 04:53:46 -0400 Received: from lgeamrelo11.lge.com (lgeamrelo13.lge.com [156.147.23.53]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7553625C6E for ; Wed, 4 May 2022 01:49:23 -0700 (PDT) Received: from unknown (HELO lgeamrelo01.lge.com) (156.147.1.125) by 156.147.23.53 with ESMTP; 4 May 2022 17:19:22 +0900 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: byungchul.park@lge.com Received: from unknown (HELO localhost.localdomain) (10.177.244.38) by 156.147.1.125 with ESMTP; 4 May 2022 17:19:22 +0900 X-Original-SENDERIP: 10.177.244.38 X-Original-MAILFROM: byungchul.park@lge.com From: Byungchul Park To: torvalds@linux-foundation.org Cc: damien.lemoal@opensource.wdc.com, linux-ide@vger.kernel.org, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org, peterz@infradead.org, will@kernel.org, tglx@linutronix.de, rostedt@goodmis.org, joel@joelfernandes.org, sashal@kernel.org, daniel.vetter@ffwll.ch, chris@chris-wilson.co.uk, duyuyang@gmail.com, johannes.berg@intel.com, tj@kernel.org, tytso@mit.edu, willy@infradead.org, david@fromorbit.com, amir73il@gmail.com, bfields@fieldses.org, gregkh@linuxfoundation.org, kernel-team@lge.com, linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@kernel.org, minchan@kernel.org, hannes@cmpxchg.org, vdavydov.dev@gmail.com, sj@kernel.org, jglisse@redhat.com, dennis@kernel.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, vbabka@suse.cz, ngupta@vflare.org, linux-block@vger.kernel.org, paolo.valente@linaro.org, josef@toxicpanda.com, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, jack@suse.cz, jack@suse.com, jlayton@kernel.org, dan.j.williams@intel.com, hch@infradead.org, djwong@kernel.org, dri-devel@lists.freedesktop.org, airlied@linux.ie, rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com, hamohammed.sa@gmail.com, 42.hyeyoo@gmail.com Subject: [PATCH RFC v6 21/21] dept: Unstage wait when tagging a normal sleep wait Date: Wed, 4 May 2022 17:17:49 +0900 Message-Id: <1651652269-15342-22-git-send-email-byungchul.park@lge.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1651652269-15342-1-git-send-email-byungchul.park@lge.com> References: <1651652269-15342-1-git-send-email-byungchul.park@lge.com> X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Staging a wait and commit have been introduced to handle conditional sleeps that can be determined in __schedule() whether it actually goes to sleep or not. With this feature, actual wait tagging is delayed until __schedule(). Unfortunately, an ambiguity arises when a normal sleep wait that doesn't require staging and commit, is involved in the middle of handling a conditional sleep e.g. between prepare_to_wait_*() and __schedule(), which is a very rare case tho. So let it give up handling the conditional sleep by unstaging it unconditionally when a normal sleep wait gets involved, to avoid the ambiguity. Signed-off-by: Byungchul Park --- kernel/dependency/dept.c | 55 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 40 insertions(+), 15 deletions(-) diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c index 14dc33b..ce6d5b3 100644 --- a/kernel/dependency/dept.c +++ b/kernel/dependency/dept.c @@ -2166,6 +2166,21 @@ static void __dept_wait(struct dept_map *m, unsigned long w_f, } } +static inline void stage_map(struct dept_task *dt, struct dept_map *m) +{ + dt->stage_m = m; +} + +static inline void unstage_map(struct dept_task *dt) +{ + dt->stage_m = NULL; +} + +static inline struct dept_map *staged_map(struct dept_task *dt) +{ + return dt->stage_m; +} + void dept_wait(struct dept_map *m, unsigned long w_f, unsigned long ip, const char *w_fn, int ne, bool sleep) { @@ -2183,27 +2198,24 @@ void dept_wait(struct dept_map *m, unsigned long w_f, unsigned long ip, flags = dept_enter(); + /* + * There's no way to distinguish between a staged wait and this + * one, in the middle of handling a wait that requires staging + * and commit in __schedule(). + * + * The wait that has been tagged dept_wait() with sleep == true + * should ignore the staged wait in __schedule() if it exists, + * to avoid the ambiguity. It can be done by unstaging it. + */ + if (sleep) + unstage_map(dt); + __dept_wait(m, w_f, ip, w_fn, ne, sleep); dept_exit(flags); } EXPORT_SYMBOL_GPL(dept_wait); -static inline void stage_map(struct dept_task *dt, struct dept_map *m) -{ - dt->stage_m = m; -} - -static inline void unstage_map(struct dept_task *dt) -{ - dt->stage_m = NULL; -} - -static inline struct dept_map *staged_map(struct dept_task *dt) -{ - return dt->stage_m; -} - void dept_stage_wait(struct dept_map *m, unsigned long w_f, const char *w_fn, int ne) { @@ -2565,6 +2577,19 @@ void dept_wait_split_map(struct dept_map_each *me, flags = dept_enter(); + /* + * There's no way to distinguish between a staged wait and this + * one, in the middle of handling a wait that requires staging + * and commit in __schedule(). + * + * The wait that has been tagged dept_wait_split_map() with + * sleep == true should ignore the staged wait in __schedule() + * if it exists, to avoid the ambiguity. It can be done by + * unstaging it. + */ + if (sleep) + unstage_map(dt); + k = mc->keys ?: &mc->keys_local; c = check_new_class(&mc->keys_local, k, 0, 0UL, mc->name); if (c) -- 1.9.1