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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EACBDC25B0E for ; Tue, 16 Aug 2022 17:02:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Tu7bMbLsJ7ShGjbDIBCGsoiqY+Lxf8/QFxYLk7DqfCk=; b=emWz3y+Yg4I+cE BMgWChV84zrfOtQmXOzjCGNPCKTNGxzrnKe0a7197pchhMwEcCixz+1hOH2Q/1gG9jPOwtji6aQnr ag5+ywQ3HbgEvtmwUoMsZF1aod8V/YOTOWLR898tJT3XWqyGOT+/GWZc+sj1IDdReaqhTPrjkuCkg Tm1pJhkzvL85ZMkkJwOdiBOc72kKJJ964fRFNfVk70h92B5hsGETetYyd101yNbhSpeFBOSMTE3kW 5gnd6Z+tt8Ss4F0NxcRckVRtndzLZxwyIPOUq6pXjcJznDMVhm0crAGoj28FSg+CRvuWMx3wGuV/3 Uw+V4YkyzWug9d9AhDcg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oNzwT-004xOI-KT; Tue, 16 Aug 2022 17:01:25 +0000 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oNzwO-004xDN-PF for linux-arm-kernel@lists.infradead.org; Tue, 16 Aug 2022 17:01:22 +0000 Received: by mail-pj1-x1030.google.com with SMTP id c19-20020a17090ae11300b001f2f94ed5c6so1598728pjz.1 for ; Tue, 16 Aug 2022 10:01:20 -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=DSgs9FXvT0o0PS270q9G9zIUeRmTOeFz5O3WONwu3Mk=; b=cVYr3H5SygxO+XmAclLhhXc7RtFloxydR//dRTs4yJGOtAqMVsO899vZ6hxX+VMRaO UUpwA56b/35VyN63TGCZwUT01AtbQw7nTWErn/GlAu2E3gVxW6m+Irjki4x4rwPWsrLc sOOXKvn33jURA2xT84NFPjPR1dmmxLCiflfjtStrZx3cu/VEmz+s928EWHnUU4fElYYM Da65Em2BrchCTE/RLAuR3W0tW5NsLuYOl+N/+nsdXR97aIgRbxRaSeSPkuwt09Xc7uNz qSlP8MhplPw8KeWy5WbM8qmfFIpxooVZzuPDVVC9e6WXrwDDspC8l5XBoBlrCm+sXPaV fWpw== 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=DSgs9FXvT0o0PS270q9G9zIUeRmTOeFz5O3WONwu3Mk=; b=1osihEhUea05xWeTzBtZ/ElmnyrArHq3rkjVfkjiVxIo9GRI0v8kV88U5IHmV03eK+ pqtsrNKuF0Dc16lZMzCj9Ku2DlTYY9NghPyaJEoa4/2Dt87j+R+8njdOz4vyybofxfNe 7xTrYfhLjkmualIZXWQAgewXQOCl0qk+XXjWf8/Amn+FzXcw+4qX8Bod6C8XnKu1GF7K amsdfq2Y+KBkKMJu5BHNUy76/XirYmVRawTeivStXJLFDQIGl4R18TpNbZd+QI88Sluf muzzBSL6ELRbjAUSR7HIhOnfjJ4Vvdxc8YS0Qyde6IDQKqDLZXG48ZX/j8Z4av1FhmtI NlSA== X-Gm-Message-State: ACgBeo04hyHgEfkqc5XHXZz+3p+ICEHRbnMOepGkC9JtmIN2gTEgKI51 S/68b8lZ4z7rIrALhXx8Y20oiv0A1ZE= X-Google-Smtp-Source: AA6agR5cNmTS7DV8fDmfAQnwCliasLqsFugEiciNPzXT4UUDQ0TfkEogwl0eiMTrZNWEkpL/8s/SNg== X-Received: by 2002:a17:90b:1389:b0:1f3:a782:ab28 with SMTP id hr9-20020a17090b138900b001f3a782ab28mr23804741pjb.181.1660669279541; Tue, 16 Aug 2022 10:01:19 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:7229]) by smtp.gmail.com with ESMTPSA id x6-20020a170902a38600b0017150330889sm9285711pla.189.2022.08.16.10.01.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Aug 2022 10:01:18 -0700 (PDT) Date: Tue, 16 Aug 2022 07:01:17 -1000 From: Tejun Heo To: Will Deacon Cc: Linus Torvalds , Herbert Xu , marcan@marcan.st, peterz@infradead.org, jirislaby@kernel.org, maz@kernel.org, mark.rutland@arm.com, boqun.feng@gmail.com, catalin.marinas@arm.com, oneukum@suse.com, roman.penyaev@profitbricks.com, asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] workqueue: Fix memory ordering race in queue_work*() Message-ID: References: <20220816134156.GB11202@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220816134156.GB11202@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220816_100120_878683_F94DBEFC X-CRM114-Status: GOOD ( 19.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello, Will. On Tue, Aug 16, 2022 at 02:41:57PM +0100, Will Deacon wrote: > /** > * test_and_set_bit - Set a bit and return its old value > * @nr: Bit to set > * @addr: Address to count from > * > * This operation is atomic and cannot be reordered. > * It may be reordered on other architectures than x86. > * It also implies a memory barrier. > */ > > so while Peter and I were trying to improve the documentation for > atomics and memory barriers we clearly ended up making the wrong call > trying to treat this like e.g. a cmpxchg() (which has the > unordered-on-failure semantics). I think the doc can be improved here. atomic_t.txt says under ORDERING: - RMW operations that have a return value are fully ordered; - RMW operations that are conditional are unordered on FAILURE, otherwise the above rules apply. But nothing spells out what's conditional. Maybe it's okay to expect people to read this doc and extrapolate how it applies, but I think it'd be better if we spell out clearly per operaiton so that readers can search for a speicific operation and then follow what the rules are from there. It bothers me that there doesn't seem to be a comprehensive operation-indexed doc on the subject. memory-barrier.txt doesn't cover which operations do what barriers. atomic_t.txt and atomic_bitops.txt cover the atomic_t operations but not in a comprehensive or searchable manner (e.g. does test_and_set_bit() return 0 or 1 on success?) and it's not clear where to look for non-atomic_t atomic operations. I guess it's implied that they follow the same rules as atomic_t counterparts but I can't seem to find that spelled out anywhere. The source code docs are layered and dispersed for generic and arch implemetnations making them difficult to follow. It'd be awesome if the documentation situation can be improved. Thanks. -- tejun _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel