From patchwork Thu Nov 9 21:22:52 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Johannes Berg X-Patchwork-Id: 16434 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b129:0:b0:403:3b70:6f57 with SMTP id q9csp722496vqs; Thu, 9 Nov 2023 13:40:03 -0800 (PST) X-Google-Smtp-Source: AGHT+IGIwAOATGa7GrUuV9Bh5DeM4PGPAwUwZP58YWbBdAcG/8KhcH6MyCoXYu9hIQJZP8RgHI8n X-Received: by 2002:a05:6a00:398e:b0:6be:30f1:45f8 with SMTP id fi14-20020a056a00398e00b006be30f145f8mr6819796pfb.20.1699566002782; Thu, 09 Nov 2023 13:40:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699566002; cv=none; d=google.com; s=arc-20160816; b=ekS+sN8Y0ep4JFlowj/oEo6TUpmMQSTD74/lwEjnGPmFBjTFulDaey0n4HZ8/c0ZlH g8WbmblqvkEKTn3+XecDHxsdBbcW+ifbz0ffQUslvoh+WpZvtXV9wXvjWZiAser9H/5b ouXdXBvCkWZrZh6GlDdvIEIgVrAWTvEWU73F4Q+Sv80Xkf4ZI6GyAhWAqaKRHk+ixdON chriGI5fjNmAHJ8RZo6qiRj/KzQtKLUwkaK8ebkgtiEQ96c7k/fvSCcFbtezbRUKdDqw gu/UTKQEMWCc9/mOa+XMGdcyTwT5k128W3KN1AZ8V8vATE+a/yMZR/j90g1hdIdu7+1V /DsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=jTULZb7nPWSXQoAz/suqF1eRILvjbvT5JeWBGWqkoIs=; fh=EEK2KLQhGDjxjn2ZkU2a/Dih8BpHmz9E2z62okVbmls=; b=0tM4ZFvxghEISMoTFfVFjTy5euG3FZ8FnqHQNLHWJkLNxUjV23Df1IizyET0Big8+n QaHDR6uQtQ1vh4UZ9V4ST2Vcw2EsksUMstJPkD9WtBi+Pk5Z8RjDroWa3+L0VkVJETbG ALgrVdexffsdSvhJaIXy1/HYf8RU9OXMQUzBH+YM5QBZm9TYl5jNttddJRFQYbDgMFFM JG/M4bOuoiOyjwo3JkZsZ6gzar+w3nzUH+Ze1I+8M/m2sHI0TveR/OJzzSM8rm3FJea2 u/uNwZreUg6cs4pdJn4fHkn+NP9bS9MKzACY1yXa0deN135oXl+pLhJN37PKf/V0O2iD R6lg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sipsolutions.net header.s=mail header.b=yWmkr2Ds; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=sipsolutions.net Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id bx10-20020a056a00428a00b006901387b09bsi17557315pfb.344.2023.11.09.13.40.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Nov 2023 13:40:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@sipsolutions.net header.s=mail header.b=yWmkr2Ds; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=sipsolutions.net Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 26D19815B72C; Thu, 9 Nov 2023 13:38:55 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344927AbjKIViW (ORCPT + 30 others); Thu, 9 Nov 2023 16:38:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42242 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229630AbjKIViV (ORCPT ); Thu, 9 Nov 2023 16:38:21 -0500 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:242:246e::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FC942139; Thu, 9 Nov 2023 13:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=Content-Transfer-Encoding:MIME-Version: Message-ID:Date:Subject:Cc:To:From:Content-Type:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-To:Resent-Cc: Resent-Message-ID:In-Reply-To:References; bh=jTULZb7nPWSXQoAz/suqF1eRILvjbvT5JeWBGWqkoIs=; t=1699565899; x=1700775499; b=yWmkr2DsB9ml6dHBZGwupNJRRGnOI4LA7w/RsvrdVvbpU0hOGjX5qSby3a6fHhpyASv7IafZ15J 5mkvjIPmuhPY42jaSAInV4G4T0B0Y6YPyvvig7mVIQu8JwltvZeVAqfluE5nzLLJp2MHZ+GKQrVFv 0qNGrz2JflJBlIg8rG59zhhbtcQWzjxHB81zytmFBkAt9rDwD6KiPiBT2YDE1iYFf8eKofw5wLryH rZ/sGHqxXGKAS7BpPXjtQrosw2VB0CJUs3lK/qm6FM3w6QB0/7sajAngVCnIODvmKsj/6jrl/L/J2 ve/qrKph1rOPwKiYth19qoKbhX7mDoDpW6GA==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.97) (envelope-from ) id 1r1CjA-00000001znF-2PA8; Thu, 09 Nov 2023 22:38:16 +0100 From: Johannes Berg To: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , Nicolai Stange , Ben Greear Subject: [RFC PATCH 0/6] debugfs/wifi: locking fixes Date: Thu, 9 Nov 2023 22:22:52 +0100 Message-ID: <20231109212251.213873-7-johannes@sipsolutions.net> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Thu, 09 Nov 2023 13:38:55 -0800 (PST) X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782124120938856180 X-GMAIL-MSGID: 1782124120938856180 Hi, So ... this is a bit complex. Ben found [1] that since the wireless locking rework [2] we have a deadlock in the debugfs use in the wireless stack, since some objects (netdevs, links, stations) can be removed while holding the wiphy->mtx, where as the files (all netdev/link and agg_status for stations) also acquire the wiphy->mtx. This of course leads to deadlocks, since Nicolai's proxy_fops work [3] we wait for the users of the file to finish before removing them, which they cannot in this case: thread 1 thread 2 lock(wiphy->mutex) read()/write() -> lock(wiphy->mutex) // waits for mutex debugfs_remove() -> wait_for_users() // cannot finish Unfortunately, there's no good way to remove the debugfs files *before* locking in wireless, since we may not even know which object needs to get removed, etc. Also, some files may need to be removed based on other actions, and we want/need to free the objects. I went back and forth on how to fix it, and Ben had some hacks in the threads, but in the end I decided on the approach taken in this patchset. So I have * debugfs: fix automount d_fsdata usage This patch fixes a bug in the existing automount case in debugfs, if that dentry were ever removed, we'd try to kfree() the function pointer. I previously tried to fix this differently [4] but that doesn't work, so here I just allocate a debugfs fsdata for automount, there's a single instance of this in the tree ... * debugfs: annotate debugfs handlers vs. removal with lockdep This just makes the problem obvious, whether in wireless or elsewhere, by annotating it with lockdep so that we get complaints about the deadlock described above. I've checked that the deadlock in wireless actually gets reported. * debugfs: add API to allow debugfs operations cancellation This adds a bit of infrastructure in debugfs to allow for cancellation of read/write/... handlers when remove() is called for a file. The API is written more generically, so that it could also be used to e.g. cancel operations in hardware/firmware, for example, if debugfs does accesses to that. * wifi: cfg80211: add locked debugfs wrappers I went back and forth on this, but in the end this seemed the easiest approach. Using these new helpers from debugfs files that are removed under the wiphy lock is safe, at the expense of pushing the read/write functions into a new wiphy work, which is called with wiphy->mutex held. This then uses the debugfs API introduced in the previous patch to cancel operations that are pending while the file is removed. * wifi: mac80211: use wiphy locked debugfs helpers for agg_status * wifi: mac80211: use wiphy locked debugfs for sdata/link These convert the files that actually have the problem in mac80211 to use the new helpers. Any comments would be appreciated :-) [1] https://lore.kernel.org/r/56d0b043-0585-5380-5703-f25d9a42f39d@candelatech.com [2] in particular commit 0ab6cba0696d ("wifi: mac80211: hold wiphy lock in netdev/link debugfs") but there's a lot more work that went into it [3] commit e9117a5a4bf6 ("debugfs: implement per-file removal protection") [4] https://lore.kernel.org/lkml/20231109160639.514a2568f1e7.I64fe5615568e87f9ae2d7fb2ac4e5fa96924cb50@changeid/ johannes