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 33DA1C05027 for ; Mon, 6 Feb 2023 13:10:16 +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:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8Br9JbfDhhmfdjHdyyMFWE8TNi5w4O2OZivLxtZmqTI=; b=UEGjxSfVkzCdaM zgAtXRbuWyor1fCoVXle+fBjfMXz80c/m+spYy76MOnDgOrb+o51ndjVu3f+6UNTy1IwswgB3AyvB KloWk7wBN574AiV3Sz1v3HfPame30O5kfRnLLOxqljN7SZiGJmRtLMy6Dvb2YETp0iW2Za04TlFxB mG2WhR8F4RhkpMUXVdm7Jo9ZAteDY/yS/lXUP4scQ2zYEogDYFLzeOwVAEfWyQgofQgT4dymPxyXA Jb88F4DZQ1TbKY+gjcpc7G0JaGwNSZ7N5AGtUhWOJRhI/KsLPRJcRJngjtVJclrKPUHb5kTor8gJe Arkvcqo6/gw+pPGJJAbg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pP1FC-008anm-5f; Mon, 06 Feb 2023 13:09:14 +0000 Received: from galois.linutronix.de ([2a0a:51c0:0:12e:550::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pP1F5-008alP-C8 for linux-arm-kernel@lists.infradead.org; Mon, 06 Feb 2023 13:09:12 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1675688943; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=K3nPz9+q4/7C6EI88CTICsEZBDsn6LekqjWFJbLJ6j0=; b=pq4j5maCCj/8vJzyRsgGTYJTpzH9DVI2EVrcl9dwliEGq04DolNhT+ydJZQTgOXxpK4blP /Eds3vEctyDKtP+rf/qe3YgPlsSTSE/pKqN/k7+Wif1lasOwkqa6jUg+LPKq4mDF5umVl/ 19dbkgJAa//vTWGR89joTOtqj4HkIYuT0VTvRqIDQ7b59PsiGzhLp1Bj4owPLuwUnMtR17 VOQsUiGD1nc6sRLlmM9GeB003/OEbWS4qeoFj4eflDPKk+TEjsXGGSvE/kq5DMfVwTNts2 twv3TBcjY75gXibJAQCheXJ5xW+CQ2RZVehbVNLFPpMSZhzB8Ex8BIIGT9NcLQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1675688943; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=K3nPz9+q4/7C6EI88CTICsEZBDsn6LekqjWFJbLJ6j0=; b=pWA3gd8FT2NxyX9+dxM7BnuxNSnxGCqJfF7pVY7up13yIORFckVEIPQY7ncimJF+Ti9Zjw 7Fdt0rwVU7CD10CA== To: Johan Hovold Cc: Johan Hovold , Marc Zyngier , x86@kernel.org, platform-driver-x86@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, Hsin-Yi Wang , Mark-PK Tsai Subject: Re: [PATCH v4 06/19] irqdomain: Drop revmap mutex In-Reply-To: References: <20230116135044.14998-1-johan+linaro@kernel.org> <20230116135044.14998-7-johan+linaro@kernel.org> <871qnslut3.ffs@tglx> <87r0vshu1y.ffs@tglx> Date: Mon, 06 Feb 2023 14:09:02 +0100 Message-ID: <87zg9rx7o1.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230206_050907_592493_305EAD91 X-CRM114-Status: GOOD ( 10.14 ) 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 Wed, Jan 18 2023 at 14:10, Johan Hovold wrote: > On Wed, Jan 18, 2023 at 02:05:29PM +0100, Thomas Gleixner wrote: >> You can do this in a two step approach. >> >> 1) Add the new locking and ensure that the lock is held when >> the functions are called > > But the new locking has nothing to do with these functions. They are > added because they fix various races elsewhere. Adding lockdep > assertions in unrelated function as part of those fixes doesn't really > make much sense. Seriously? The point is that revmap_mutex is not protecting against any of the races which you are trying to protect against. Ergo, any callsite which does not hold the irqdomain mutex is part of the problem you are trying to solve, no? The removal of the revmap_mutex becomes possible due to the overall protection scheme rework _after_ you established that all callers hold the irqdomain mutex. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel