Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp650333imu; Thu, 13 Dec 2018 01:59:49 -0800 (PST) X-Google-Smtp-Source: AFSGD/Xwow1eubfnom13zMIGk5M0ktCpIRoZz+pn9VYqu6bz/I0abYke6E/OD+XLD+L7btT6kwU+ X-Received: by 2002:a62:178f:: with SMTP id 137mr23181564pfx.226.1544695189861; Thu, 13 Dec 2018 01:59:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544695189; cv=none; d=google.com; s=arc-20160816; b=WTOpNTiqfQZKGAWQtpSentzU+wtZdnlu2high1ay3IuGchFYc9502gKQMYxf9tXAGe dgl2T2ScYoLOab7w4E35lmdw70mznUdjgeLSRMPc7GNQRI6RXNsFVHbwmb3GWdWS9Pn+ V1C8l0n0izDIjFUyYS112Gkckj0T92TkOs/eGK5aoHOSbxeWxTtDqAYDq08Ud1zNEolE 1q35gvwMek4n0XSRDZBx1lsgUsTVLuR9A0h0yGJwRicv9LFdIMQnzWgAwO+10cJNaLcJ qSVHDPpeEXRSXsEqiCVoEqK8467b6OATQ3CoTp3bB62cGsOxVh/STE4gQ8TYmaWU9mjR MNZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature; bh=DyFnPGwFai6jF7+vAFApibSkmEDc58F14dUuetMugDs=; b=AYgYRhnHpP3xegUNPAzbcwUKtx5+YumcBinMmzJBMplXQYsFHF7b5pNrd6ud5gKGnG +8GvkFFl+P3EjLzs73ptr0clNuM4bDwcm+Zf+o5cwW4oOZx7oZTCORampS7FgT3vlLQ7 //Fh/Lf0uefMSZyYLGDdXhtJrQiYdRk87F88p8KS4HDmJI8bFmS9DaVTkmPUxcffXAXp DN3GcEqVhJGnULiYUHRgTeX51h5sZ6AacFp4tDzS5w4eJi75wh6BRVYYMwpK0HqSSzV/ Ce2r6RqWPNIl84UyWCWWAHuYFOAeVga2tf4pbcVvCpP3D05BIbYi6erdM9/+z8I12lv/ WWMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=gghMC4j3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u184si1184009pgd.262.2018.12.13.01.59.35; Thu, 13 Dec 2018 01:59:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=gghMC4j3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728106AbeLMJ6T (ORCPT + 99 others); Thu, 13 Dec 2018 04:58:19 -0500 Received: from mail-ed1-f67.google.com ([209.85.208.67]:40303 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727210AbeLMJ6T (ORCPT ); Thu, 13 Dec 2018 04:58:19 -0500 Received: by mail-ed1-f67.google.com with SMTP id d3so1492899edx.7 for ; Thu, 13 Dec 2018 01:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=DyFnPGwFai6jF7+vAFApibSkmEDc58F14dUuetMugDs=; b=gghMC4j3C8I6NnpLypL3hnig0jjZnNyWWpdK5+P+gv42CrQ7qZztqebPbkF5N7fIAE 9Ba5Ow5ZZE0Er6lCxPhDOm0gMtkaUPI5IOCR1hsOUOKxZsQqHc19d2fe6beyfn6xHGw6 4sQohqr8d7ouhmmNA+V7Cqhh5uP3bbQPFY19k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=DyFnPGwFai6jF7+vAFApibSkmEDc58F14dUuetMugDs=; b=Y4+DiNvxVFL9fgxcXpKOoriA8ysf5fldVkrY8jYjAH6e2ev3KcJ5J4pjrOM86AtQWV JvHgLVJNT7PuRK+6z4bvxQaRcYpev2gbEGto7GThEkBsWCbmu4T48rjZIrw2UF8rOsQt p4Qc9aUptIAlawJeSGOum+b3P7C+RXBEkA6VI06icGRpayFv27nwOCHqRaAbKRaFodPn Rd05M/Rh0nVqCoWAC19pYJ3LapMiRFURb/GU+4K/pl23vp697gyDW0zF6P7rESQ++OUM M6BtkNufEATWTS14o5nbpPZMTwIqRx9livAL2mQYqjFxkGNmOl6ijfI5zp+AVGDEfGXJ qCYw== X-Gm-Message-State: AA+aEWaZ3UyWalx01pln2vTkHarM+HyPc3IYHI3Qq8QtDLrIot5tT5rL EGuUfKM4AYu0tvjyS4awx5qMqg== X-Received: by 2002:a17:906:38e:: with SMTP id b14-v6mr17236866eja.209.1544695097640; Thu, 13 Dec 2018 01:58:17 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id r1sm499200eds.1.2018.12.13.01.58.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Dec 2018 01:58:16 -0800 (PST) Date: Thu, 13 Dec 2018 10:58:14 +0100 From: Daniel Vetter To: "Rafael J. Wysocki" Cc: Daniel Vetter , Linux Kernel Mailing List , dri-devel , ramalingam.c@intel.com, Greg Kroah-Hartman , Daniel Vetter Subject: Re: [PATCH] drivers/base: use a worker for sysfs unbind Message-ID: <20181213095814.GC21184@phenom.ffwll.local> Mail-Followup-To: "Rafael J. Wysocki" , Linux Kernel Mailing List , dri-devel , ramalingam.c@intel.com, Greg Kroah-Hartman , Daniel Vetter References: <20181210084653.7268-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 4.18.0-2-amd64 User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 13, 2018 at 10:38:14AM +0100, Rafael J. Wysocki wrote: > On Mon, Dec 10, 2018 at 9:47 AM Daniel Vetter wrote: > > > > Drivers might want to remove some sysfs files, which needs the same > > locks and ends up angering lockdep. Relevant snippet of the stack > > trace: > > > > kernfs_remove_by_name_ns+0x3b/0x80 > > bus_remove_driver+0x92/0xa0 > > acpi_video_unregister+0x24/0x40 > > i915_driver_unload+0x42/0x130 [i915] > > i915_pci_remove+0x19/0x30 [i915] > > pci_device_remove+0x36/0xb0 > > device_release_driver_internal+0x185/0x250 > > unbind_store+0xaf/0x180 > > kernfs_fop_write+0x104/0x190 > > Is the acpi_bus_unregister_driver() in acpi_video_unregister() the > source of the lockdep unhappiness? Yeah I guess I cut out too much of the lockdep splat. It complains about kernfs_fop_write and kernfs_remove_by_name_ns acquiring the same lock class. It's ofc not the same lock, so no real deadlock. Getting the device_release_driver outside of the callchain under kernfs_fop_write, which this patch does, "fixes" it. For "fixes" = shut up lockdep. Other options: - Anotate the recursion with the usual lockdep annotations. Potentially results in lockdep not catching real deadlocks (you can still have other loops closing the deadlock, maybe through some subsystem/bus lock). - Rewrite kernfs_fop_write to drop the lock (optionally, for callbacks that know what they're doing), which should be fine if we refcount everything properly (bus, driver & device). - Also note that probably the same bug exists on the bind sysfs interface, but we don't use that, so I don't care :-) - Most of these issues are never visible in normal usage, since normally driver bind/unbind is done from a kthread or model_load/unload, neither of which is running in the context of that kernfs mutex kernfs_fop_write holds. That's why I think the task work is the best solution, since it changes the locking context of the unbind sysfs to match the locking context of module unload and hotunplug. Unfortunately that trick doesn't work for the bind sysfs file, since that way we can't thread the errno value back to userspace. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch