From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB194C04A68 for ; Thu, 28 Jul 2022 16:40:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229768AbiG1QkW (ORCPT ); Thu, 28 Jul 2022 12:40:22 -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-Google-Smtp-Source: AGRyM1tZ1pnd3F9tbC8QoL0a4vTAHzymeZgopSUWAUT4pebjLdSRFhjRLDGyKW4vEunps4Zs/YAB6w== 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> 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