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 13B31EE4993 for ; Fri, 18 Aug 2023 18:24:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356488AbjHRSYJ (ORCPT ); Fri, 18 Aug 2023 14:24:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379439AbjHRSYF (ORCPT ); Fri, 18 Aug 2023 14:24:05 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 334A82D58 for ; Fri, 18 Aug 2023 11:24:04 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id E0A4D2188D; Fri, 18 Aug 2023 18:24:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1692383042; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SX+D2sM86o3QGpOyvkgvl+QwlBYRKQsPyzgbZzO4nyA=; b=q/qgiyfrEHdFU6TeGd0d+esDu0V4IHfuBebB/dN6UmXgoNUHpwOvKBuvrAF1Bm1s5OUjlp EyogPYXQOvdheT2V079uiUZBNJNnL73SRGY+umBuy5vMnWnEPhqC5u+4IMM1tqdMAzMoUS sg0o5v+/uEcwrvtb0tzecD+40YV0mHA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1692383042; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SX+D2sM86o3QGpOyvkgvl+QwlBYRKQsPyzgbZzO4nyA=; b=YKUqdP3ZLE7Qh/O516Dsfs9/jy5m5Zx2mbBdxa48rO+L5tyVr+KSNcuqxNGifZn44HG6Jv 5GhILpJ6bE5CvYAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 988CE13441; Fri, 18 Aug 2023 18:24:02 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id CB0NJEK332SqMAAAMHmgww (envelope-from ); Fri, 18 Aug 2023 18:24:02 +0000 Date: Fri, 18 Aug 2023 20:24:01 +0200 From: Joerg Roedel To: Jason Gunthorpe Cc: Marek Szyprowski , iommu@lists.linux.dev, Joerg Roedel , Len Brown , linux-acpi@vger.kernel.org, "Rafael J. Wysocki" , Robin Murphy , Will Deacon , Lu Baolu , Kevin Tian , Chen-Yu Tsai Subject: Re: [PATCH v2 0/4] Fix device_lock deadlock on two probe() paths Message-ID: References: <0-v2-d2762acaf50a+16d-iommu_group_locking2_jgg@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Fri, Aug 18, 2023 at 01:06:43PM -0300, Jason Gunthorpe wrote: > On Fri, Aug 18, 2023 at 05:56:20PM +0200, Joerg Roedel wrote: > > On Thu, Aug 17, 2023 at 03:33:16PM -0300, Jason Gunthorpe wrote: > > > Bascially.. Yikes! > > > > Hmm, that is a difficult situation. Even if the problem is a misuse of > > the APIs we can not just blindly break other drivers by our core > > changes. > > They are not broken, they just throw a lockdep warning and keep going > as before. This is what triggers: > > static inline void device_lock_assert(struct device *dev) > { > lockdep_assert_held(&dev->mutex); > } > > So non-debug builds won't even see anything. But this still means that a function is called without holding the proper lock. > Historically we've tolerated lockdep warnings as a way to motivate > people who care to fix their stuff properly. eg the Intel VT-D had a > lockdep warning at kernel boot for many releases before it was fixed. There is a difference between knowingly introducing new lockdep warnings into upstream and letting warnings discovered upstream rot for a while. I can't send anything with known problems upstream. Regards, -- Jörg Rödel jroedel@suse.de SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman