Message ID | 20231124162522.16344-7-johannes@sipsolutions.net |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:ce62:0:b0:403:3b70:6f57 with SMTP id o2csp1353869vqx; Fri, 24 Nov 2023 08:37:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IHNsaOtdthRFDArYauPokOiq+pGhjDF7YJ/rvGn7wjA+zqJSsFKK2n3y9LCEhkKDu5ADhza X-Received: by 2002:a05:6820:228b:b0:56c:d297:164c with SMTP id ck11-20020a056820228b00b0056cd297164cmr3805263oob.4.1700843827881; Fri, 24 Nov 2023 08:37:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700843827; cv=none; d=google.com; s=arc-20160816; b=hrvtpuPoGlSKyEEldIPF8Y1/XLFu1xOuC23x8MS+8x4CYHq8Tde5hWYf7NpFFe0cqw m2iynQ937H3c3Ia1yrr/w1goz68O/DB53Ft59eUoQu0/Am1g69pP5XVq/0jNrw58M5gA nYe191IWovg3siZ4Z3LRJB12xbKmImFH97RC2DZKG9t/hP78rrndprZ6RvwxFvqmXvf6 1ICE/sjMw2V+cd7uTV2InCEohq1Q4QywB5lAH0AWB2SzwxXdpJ/H5VT2MlEsl5x12ARF DmjBG3xoGJx/0lCHUz2pLYU8Z0Z/TnAXpEVyc8utcFT6w7oUwjN3lyTBxK35bfGzGRT5 BlYg== 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=2wxrylrSD098+RrYmJNUHBHYAaD0hX9xrQiFrNIZx9A=; fh=o/oe/UXTGT2y0H+FdIVDaN7yZ4+ZBn/0W6OuN+pPI/E=; b=b0l1fMVUiX0iDhDMdW32YaZrsa9VehD/5r+paM7jY22vKzY5sEkLd1XwKSDPWujDRF ob4+hd//0pgQ/gc1LoIQ8rAKkXlfRw0ztzaZUi89YcEpoIjowXhR1TAfuCesQed0t1A0 i1t6E3xCK/Q9SP+R6eblYmDPYn93/wQsxGS2YtKmB8PcqBniD2Fj+1X8u7J2rfPDa3sl rF3h/7+JRAmCmbEvKKmYIbfBi066u4OqbKlIQ0d6DPeb6OJKp93jVYtni7Qybm8uOjVf B4lcCqGVGuuu9nXQyDUX5bhRJOSRz/NLugxpCPYkhZYNol0J89l8ETyFyD5d6uX19WQb MMrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sipsolutions.net header.s=mail header.b=hLHEoSCO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id b3-20020a056820134300b0058d3b4e45bdsi866861oow.1.2023.11.24.08.37.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Nov 2023 08:37:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@sipsolutions.net header.s=mail header.b=hLHEoSCO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 agentk.vger.email (Postfix) with ESMTP id 17D4781E62B1; Fri, 24 Nov 2023 08:35:57 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231249AbjKXQfN (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Fri, 24 Nov 2023 11:35:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37506 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229907AbjKXQfL (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 24 Nov 2023 11:35:11 -0500 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:242:246e::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E6E71733; Fri, 24 Nov 2023 08:35:16 -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=2wxrylrSD098+RrYmJNUHBHYAaD0hX9xrQiFrNIZx9A=; t=1700843716; x=1702053316; b=hLHEoSCOoqHqbVNYWJbpWQgyM9C6WSpdkLsif/4f3IbHjmyLNSo3HJIYe3nySZHnrV7abODJJ9S 7mbadmcw+Pod1wlfEB9emf8ACmzWj/dXAofD8Fslmzy74JQ+Lvm3Q/qg6dJkfoWcr4O7JS84dSPR5 yDRIPKGzx9lFMRGIcF9G6kzy70IG+EtC3AO7S91fgsjrz0uKwmpH2XKd0+2o7tjh6UA9q8orE+1Be igHeq6DqB9HN0rQmC7GAUB8WeD27nPEw2VGbjcbAtiRjF8SoE4G9r62TVwKTqtbZLaWzr32NZKCNv VImtt+mJ6vZzGandzS3sYkeHlIlGi/LtRWNg==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.97) (envelope-from <johannes@sipsolutions.net>) id 1r6Z98-00000002fA8-2pL6; Fri, 24 Nov 2023 17:35:14 +0100 From: Johannes Berg <johannes@sipsolutions.net> To: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org> Subject: [PATCH v2 0/6] fixes for debugfs/wireless locking issue Date: Fri, 24 Nov 2023 17:25:23 +0100 Message-ID: <20231124162522.16344-7-johannes@sipsolutions.net> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Fri, 24 Nov 2023 08:35:57 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783464017508913499 X-GMAIL-MSGID: 1783464017508913499 |
Series |
fixes for debugfs/wireless locking issue
|
|
Message
Johannes Berg
Nov. 24, 2023, 4:25 p.m. UTC
There's a locking issue in wireless where it takes a lock inside a debugfs file handler that's also taken around the removal of the debugfs file, and this causes a deadlock due to the proxy object use. Fixing the debugfs removal is tricky because some of the objects represented there fundamentally are deleted with the lock held. Not taking the lock in the debugfs file is also not really the right thing to do. Therefore, right now, the only way to fix this would be to not have the debugfs files entirely, but that isn't really helpful either. Thus, here's a way to fix it that doesn't just remove the files. The first patch is just a consistency thing in debugfs, right now directory dentries don't have d_fsdata, normal file use the proxy fops object, and automount uses the original autmount (function) pointer, no proxy object. This is an issue if an automount dentry were ever removed, which right now it isn't as far as I can tell, but it still makes little sense, so fix it here by also allocating an object for it, just not with real_fops making it a proxy, but with the automount pointer inside. The second patch annotates debugfs with lockdep to actually find deadlock scenarios such as the one in wireless, indeed with that and accessing one of the affected debugfs files, lockdep detects the situation. The third patch introduces a concept of 'cancellation', whereby a debugfs file handler that is "long-running" may enter (and later leave, of course) a cancellation section, where a function call is made when the file is removed while the handler is running, and the cancellation function can then abort the handling. This is pretty generic so far. The later patches (and I assume those would go through the wireless tree) then fix the locking issue by declaring that the work that's going to happen under lock is "long-running" per the above, and setting up a cancellation. The way it works is that it actually defers the real handling to a workqueue but then waits for it, but that waiting can be aborted (and the work stopped) if the file is removed before the work was able to run, thus fixing the deadlock. I hope this is an acceptable compromise in terms of functionality in debugfs vs. the user. It'd be possible to set up something of the same sort in debugfs, but I feel the cancellation API is more generic and thus more useful, and the actual details of what's in the actual file handlers don't matter then. johannes
Comments
On 11/24/23 08:25, Johannes Berg wrote: > There's a locking issue in wireless where it takes a lock inside > a debugfs file handler that's also taken around the removal of > the debugfs file, and this causes a deadlock due to the proxy > object use. Fixing the debugfs removal is tricky because some > of the objects represented there fundamentally are deleted with > the lock held. Not taking the lock in the debugfs file is also > not really the right thing to do. Therefore, right now, the only > way to fix this would be to not have the debugfs files entirely, > but that isn't really helpful either. I have been running the RFC series and haven't noticed problems, so you can add: Tested-by: Ben Greear <greearb@candelatech.com> Thanks, Ben