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 67A3BC00140 for ; Mon, 15 Aug 2022 19:26:14 +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=LCTQcV8ET9tN+IrNWLYZexiNpDE0xhjZBFaU4ZppECM=; b=Fux1YWEwe1Vdc7 34jCYcQa0E3byzFy6M87CwAzXvNN/GCmkmCmOXrvr0tl9hE7ChfA+eL9DnZAr+Jg7/nIrkIx0cwwW yUmx4zZSN1zNwjqsSnQQavBxq0akqvFIMhdP/s8sh32eqWjoYYEL1gY1tQpAScyAyhuLxlI+YqVLu zdJuKES0OBXm8H1M4DTPo+bUPOaKPd+k/7lQ3rodGOVZFLn3Gxg8roQB8KncLDlikIuOJDVUXx8H4 PGiuHFtfsE4G9xO9Jt++RXgdPkgyQ+zuVMkHg/N+wOOY2i4WkLjCcAl9OBhay2Vv7uWaJIIGju0GT mZ30Cs24ObYC6voGDA4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oNfhs-003z2r-4s; Mon, 15 Aug 2022 19:25:00 +0000 Received: from mail-qt1-x82a.google.com ([2607:f8b0:4864:20::82a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oNfhp-003yyL-0h for linux-arm-kernel@lists.infradead.org; Mon, 15 Aug 2022 19:24:58 +0000 Received: by mail-qt1-x82a.google.com with SMTP id h4so6192449qtj.11 for ; Mon, 15 Aug 2022 12:24:54 -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:feedback-id:from:to:cc; bh=7Lq5uY6NcpMHsM7UKQ9h0OJStqfzG9LSnTMaqGwvJLg=; b=UNcd4p8niNhaUE93dbrFIADoy/Kbsml1WPNWq3nwJb4mzICVh6rxmV8GA/5NsZaktI pKf3zcH2AO/o1xhoyBNoCm4mEwUa0u1WSL+2bO1oyy7xmXCpL9ozdfSLhZ4bNhR6iWza A8GHTyqmzlb7NO6KWQxySjCoY+eYFHbLSf/j4cfLi20T4FneLXSi8+2fwz6BSfV4Shzk 5sz/t6+4eLMEsfyguZzjNQ14Q3K/JQz4Q0tSCKddsd/SK07enoubpe/uYO8D3iYo5FTJ kjZdFiPV7bLuoaTm1xvXztpvbTduS8JTS3VMu88gKdi2v7dcaKwUthvURvd8xLNZ/kPL xKTQ== 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:feedback-id:x-gm-message-state:from:to:cc; bh=7Lq5uY6NcpMHsM7UKQ9h0OJStqfzG9LSnTMaqGwvJLg=; b=QnsAJiKUYvKNxKiGAPlQAk7G/Y5u+K6wjcFFgfrY9m96gX325dASACAU1asd7xmM1o pB3dxiwA2G7epQ3EkkvtLGBKKGtEvB3Xhx7tUHLSZZ0TKvhw+u38m9DcQuldNQUJnoU3 nzSmXUzKxGGzB+DDOV5VxTV3jk2mPQLhQFQdYPggPm0YlW2p0HvCf8COIfNBdrCExy3F +Sgug6/8NSV4HfEYYiYPdEvCgM9/JLXgOEQpvTacS9olenPbEM7Z7ezwJ90NrKSnwJWl +nGAnwToiSsklYoA34bIFKHF/tOKi1Pho4NP9w6rTLZR3s/f7mKHOYbHSK6L6GIfMbb+ ZElA== X-Gm-Message-State: ACgBeo3vk7SkiPkLAnUF22LYSP/BGd1sf8Tz9NPabpLp6SGOBNv2r8lS 7PKKB1EojTLO9dMnjf2LXSI= X-Google-Smtp-Source: AA6agR5UW2sc5l5oTuJUVUZm8ScMn++xPnoAFjuNLF7dmLJMJf+uqdhWzeiR9lA7l00dOooMshXUow== X-Received: by 2002:a05:622a:2c1:b0:343:550e:d7fb with SMTP id a1-20020a05622a02c100b00343550ed7fbmr15263748qtx.286.1660591493643; Mon, 15 Aug 2022 12:24:53 -0700 (PDT) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com. [66.111.4.228]) by smtp.gmail.com with ESMTPSA id o4-20020a05620a2a0400b006ba9b2167a2sm8799525qkp.16.2022.08.15.12.24.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Aug 2022 12:24:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailauth.nyi.internal (Postfix) with ESMTP id B3C6E27C0054; Mon, 15 Aug 2022 15:24:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 15 Aug 2022 15:24:52 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdehvddgudefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhq uhhnucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrf grthhtvghrnhephedugfduffffteeutddvheeuveelvdfhleelieevtdeguefhgeeuveei udffiedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epsghoqhhunhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqieelvdeghedt ieegqddujeejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepghhmrghilhdrtghomhesfh higihmvgdrnhgrmhgv X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 Aug 2022 15:24:51 -0400 (EDT) Date: Mon, 15 Aug 2022 12:24:39 -0700 From: Boqun Feng To: Hector Martin Cc: Will Deacon , Linux ARM , Greg KH , jirislaby@kernel.org, Marc Zyngier , Mark Rutland , Peter Zijlstra , Catalin Marinas , Asahi Linux , Oliver Neukum , LKML Subject: Re: Debugging a TTY race condition on M1 (memory ordering dragons) Message-ID: References: <6c089268-4f2c-9fdf-7bcb-107b611fbc21@marcan.st> <20220815134711.GA10374@willie-the-truck> <63cd54a8-3c48-d1b9-406a-c521bd02ee4a@marcan.st> <8ccfdd2d-ef77-4586-e50c-985e1d13726a@marcan.st> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220815_122457_084558_2F935AEA X-CRM114-Status: GOOD ( 23.15 ) 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 On Tue, Aug 16, 2022 at 04:15:00AM +0900, Hector Martin wrote: > On 16/08/2022 03.58, Boqun Feng wrote: > > I agree this is handy, but an unconditional full barrier may be costy to > > some users, and probably unnecessary if the users periodically queue > > the work. In that case, some successful enqueue will eventually make all > > memory accesses observable. Also if workqueue users use their own > > locking in work function, then the barrier is also unnecessary. > > > > The document part of course needs some help to clear things up. But I'm > > not sure "strengthen"ing the ordering guarantee of queue_work() is a > > good idea. Maybe a dedicated API, like: > > > > // More work is needed for the @work, it has the same semantics as > > // queue_work() if the @work is not pending. If the @work is pending, > > // this ensures the work function observes all memory access before > > // this. > > void queue_more_work(struct work_struct *work) > > { > > smp_mb(); > > queue_work(work); > > } > > > > Regards, > > Boqun > > FWIW, I didn't actually use a full barrier in my patch. I just replaced > the test_and_set_bit() with the underlying atomic op, sans early exit path. > > Personally though, I think it makes more sense to have the default > function provide the guarantees, and if someone *really* needs the > performance gain from eliding the implicit barrier, they could use an > alternate API for that (after they show useful gains). This stuff is too > subtle to expect every caller to wrap their head around memory ordering, > and having queue_work() always provide order with prior stores *feels* > intuitive. > Fair enough. It's just that when you know something about memory ordering and atomics, you kinda want to play the game to save as many barrier as you can ;-) It's a curse of knowledge. > But let's see what the workqueue folks say :) > Looks like they agree with you ;-) Nice work! Regards, Boqun > - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel