Received: by 2002:ac0:e34a:0:0:0:0:0 with SMTP id g10csp591557imn; Thu, 28 Jul 2022 09:49:16 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vAbAeZ4Axij4nvQXj7VFU+1L+CE8GBrdif6Td+7fDNqxbb/tKtIR9lJRm4ppQiQuqL+ydB X-Received: by 2002:a63:db0c:0:b0:41a:6c14:a81f with SMTP id e12-20020a63db0c000000b0041a6c14a81fmr24081812pgg.33.1659026956400; Thu, 28 Jul 2022 09:49:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659026956; cv=none; d=google.com; s=arc-20160816; b=hP1c9d1mchUDTqs90ewmfwpa+oFoAkvchuinXqmansMZxbgok6rcRPd6BCrvplx7nF 2MpvUhL+6AKoSHBPI2hhfdax8iisETcWn4GT1BC2TxIwyc6Mt5B4SUwO0jvgofStzjhe J/QaHu8K5NJQzTGSWCH8c8ImT5hHkRNH6BoSGzc4NDzDqZoLatHOL8ii5VD+LptYNZg8 +CdzqZH6/KrhyZk4y205LVbjSozNg4CmE0V3F914rYGfPw2Z+xSe72gyknpR7kva4hyi zV/cMxy73PdxBoKDnJNu2Lxow9JJ5FHGlsxtOBtSffm7HBERI8bUDZ3seObLWzlJpvSC ap1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=Jx3fjLO5Rw80zgj8Pe6hN2gdWGaZqNpaZHeq5jpljnY=; b=dT6FkQj2JX0+UCtQcp0sCjojhgPSVZMrqTMVjgR175fFCUuKFst3R0dX6JPEu8dtGP JycEWJNxplf4dhOVSsbx7u51R4zQKQ+tUi+Z5Hye/86Ot+k0LACUY5OKWLUuyi2YXu55 9Hf2H5fn0RukDLgV1HFt3afOB+/QgvD7szNi8LlGPXxNqnkF2TyjoaxyaikXBS8GVgEA byExqadOjy/CL/w4FW+B+tNWUoAPnJAgwi29wO73HTeh96VhsqKI8+OX1coEAF0VFpRP 1VBfq7b3HuGfeTa9N+1IRBNGtT8zOr0JEU7VvZ/5YcblOuMix37NXMMOiBY9MC9pjGol 9/KA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=TRYbBxtV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n13-20020a65488d000000b0041212cbc60bsi1565413pgs.373.2022.07.28.09.49.00; Thu, 28 Jul 2022 09:49:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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; dkim=pass header.i=@gmail.com header.s=20210112 header.b=TRYbBxtV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229708AbiG1QkV (ORCPT + 99 others); Thu, 28 Jul 2022 12:40:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54202 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229625AbiG1QkU (ORCPT ); Thu, 28 Jul 2022 12:40:20 -0400 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED72465CC for ; Thu, 28 Jul 2022 09:40:18 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id 6so1928191pgb.13 for ; Thu, 28 Jul 2022 09:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc; bh=Jx3fjLO5Rw80zgj8Pe6hN2gdWGaZqNpaZHeq5jpljnY=; b=TRYbBxtVyplJA8c381OUhjCudBIy3CkwpJnag+ockqvRwYZTrqXv65PA6Xav+hVY8o 4ru8WTL0ywTxTmmsgepswvra1JSVZPiRs1pMfiV3CKh80RS2HsD2x5smATwqseBmxrkn pjBb0wr6c6d6Ajkv/38kncH0y23tixmfImWFz+4GNC9Zm9/IONkq9UAMZpDH2ntf+88g 4fQYfFLFPBHq0OJaW+dfxC1TZ+7e/ulYLCLNFzioX/TcMJQ2uv99ZXJu/7jSijlbY/RS /+7Zzj395UXWLaKIkibX6HwBZa2c0g9OuV2m16DQNOTLrOlo+Y3/jJEZdovJk1y9WIKA MPDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc; bh=Jx3fjLO5Rw80zgj8Pe6hN2gdWGaZqNpaZHeq5jpljnY=; b=E0nwyGhv956Cxv2CUmobzaLnGFaNqviwtJQCFRlaY4iVuTeHJL9PCO1z6ho8y45SuE soe+0/VIL0ZCaxO6P99xTuS88Rl/cHEhU2hHSOpjlpJdhUsoALGAysKCmlH+I0vILtbX j6cznPC7qBBkS3qPPWMAP/hQSz93SnTKHMnbe9PqaRRvZGUPTsxgD+zpWuiwE/ZyvP2C nFm6m230JvcOgQyiwEZsiJmk+oQoH96NdhKaQKiQE7/FKx4daSKo9ntYK1iDMQSEpQX3 gURCYHWlmQlBwJ7ANOjZqAUiUDlz0uFFGXyd46N94voqHdtZZyfRXptBJqa7peeA1uBi L/fA== X-Gm-Message-State: AJIora+u+9EOEuRmzKGUprIv22Pn5FyCgHEFukATlNC9EyOI6eNxS5jY KVv7V0y+yBotYSX3bvMuEFKkFQO3c2I= X-Received: by 2002:a63:4c61:0:b0:416:1e62:953c with SMTP id m33-20020a634c61000000b004161e62953cmr23130767pgl.24.1659026418308; Thu, 28 Jul 2022 09:40:18 -0700 (PDT) Received: from localhost (2603-800c-1a02-1bae-a7fa-157f-969a-4cde.res6.spectrum.com. [2603:800c:1a02:1bae:a7fa:157f:969a:4cde]) by smtp.gmail.com with ESMTPSA id d12-20020a170902e14c00b0016be368fb30sm1460501pla.212.2022.07.28.09.40.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Jul 2022 09:40:17 -0700 (PDT) Sender: Tejun Heo Date: Thu, 28 Jul 2022 06:40:16 -1000 From: Tejun Heo To: Tetsuo Handa Cc: Lai Jiangshan , Johannes Berg , Hillf Danton , LKML Subject: Re: [PATCH] workqueue: don't skip lockdep wq dependency in cancel_work_sync() Message-ID: References: <21b9c1ac-64b7-7f4b-1e62-bf2f021fffcd@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21b9c1ac-64b7-7f4b-1e62-bf2f021fffcd@I-love.SAKURA.ne.jp> X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS autolearn=no 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-kernel@vger.kernel.org On Thu, Jul 28, 2022 at 09:23:25PM +0900, Tetsuo Handa wrote: > Like Hillf Danton mentioned > > syzbot should have been able to catch cancel_work_sync() in work context > by checking lockdep_map in __flush_work() for both flush and cancel. > > in [1], being unable to report an obvious deadlock scenario shown below is > broken. From locking dependency perspective, sync version of cancel request > should behave as if flush request, for it waits for completion of work if > that work has already started execution. > > ---------- > #include > #include > static DEFINE_MUTEX(mutex); > static void work_fn(struct work_struct *work) > { > schedule_timeout_uninterruptible(HZ / 5); > mutex_lock(&mutex); > mutex_unlock(&mutex); > } > static DECLARE_WORK(work, work_fn); > static int __init test_init(void) > { > schedule_work(&work); > schedule_timeout_uninterruptible(HZ / 10); > mutex_lock(&mutex); > cancel_work_sync(&work); > mutex_unlock(&mutex); > return -EINVAL; > } > module_init(test_init); > MODULE_LICENSE("GPL"); > ---------- > > Link: https://lkml.kernel.org/r/20220504044800.4966-1-hdanton@sina.com [1] > Reported-by: Hillf Danton > Fixes: d6e89786bed977f3 ("workqueue: skip lockdep wq dependency in cancel_work_sync()") Tetsuo, you gotta explain why this is okay w.r.t. the spurious warnings that the above commit addressed. You can't just state that there are cases which are missed and then revert it. Thanks. -- tejun