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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26F6DC43219 for ; Tue, 19 Oct 2021 19:46:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1172360F02 for ; Tue, 19 Oct 2021 19:46:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234400AbhJSTsx (ORCPT ); Tue, 19 Oct 2021 15:48:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230147AbhJSTsw (ORCPT ); Tue, 19 Oct 2021 15:48:52 -0400 Received: from bombadil.infradead.org (unknown [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E596C06161C; Tue, 19 Oct 2021 12:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=jCo7U915eFRqWzpvn4v1HPXwjv12FjYjhZ4kBCli1BA=; b=XQzRM95CX9ofAeF03oyBgo9tdr tca/b6ddAmgUpGHrIOgKOl7J+MmMtICCtW9iI9X/pIp9MDdL8jhpdq1WUpyF+AqNyJJXM+xcXea+Y A+/eXwEiUOwerfpiB9WrGkP+ywwG+ealnZuYQt1ByR+KUnhNAXDvKMFwufKpwEgRWHNiYPNEhnjoi bTJNL3eWVoeD+EBPCVAiiRgFpwqUUIkHuRc7HNZ6R8Ax6kfd/8src6qtI8PSnjLsvdemXY2lQiN4s fVHcuQayWAEmJ2qh+RFvpTD5WkbnMFHUROEQZMwM1v8B3T9/7bol/7RXJacyarkYcDITzTWqga2Vd eQK52yWw==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mcv49-002XTn-Ah; Tue, 19 Oct 2021 19:46:29 +0000 Date: Tue, 19 Oct 2021 12:46:29 -0700 From: Luis Chamberlain To: Greg KH Cc: Ming Lei , Benjamin Herrenschmidt , Paul Mackerras , tj@kernel.org, akpm@linux-foundation.org, minchan@kernel.org, jeyu@kernel.org, shuah@kernel.org, bvanassche@acm.org, dan.j.williams@intel.com, joe@perches.com, tglx@linutronix.de, keescook@chromium.org, rostedt@goodmis.org, linux-spdx@vger.kernel.org, linux-doc@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v8 11/12] zram: fix crashes with cpu hotplug multistate Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Luis Chamberlain Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Tue, Oct 19, 2021 at 07:28:35PM +0200, Greg KH wrote: > On Tue, Oct 19, 2021 at 09:30:05AM -0700, Luis Chamberlain wrote: > > On Tue, Oct 19, 2021 at 06:25:18PM +0200, Greg KH wrote: > > > On Tue, Oct 19, 2021 at 08:50:24AM -0700, Luis Chamberlain wrote: > > > > So do you want to take the position: > > > > > > > > Hey driver authors: you cannot use any shared lock on module removal and > > > > on sysfs ops? > > > > > > Yes, I would not recommend using such a lock at all. sysfs operations > > > happen on a per-device basis, so you can lock the device structure. > > > > All devices are going to be removed on module removal and so cannot be locked. > > devices are not normally created by a driver, that is up to the bus > controller logic. A module will just disconnect itself from the device, > the device does not go away. > > But yes, there are exceptions, and if you are doing something odd like > that, then you need to be aware of crazy things like this, so be > careful. But for all normal drivers, they do not have to worry about > this. "Recommend" is a weak position to take given a possible deadlock with sysfs. Do we want to at the very least document this is not a supported scheme? If so I can also add a simple 1 level indirrection coccinelle patch to detect these schemes and complain about them as wel, if we are going to take this position. But to simply disregard this as "not an issue", or we won't do anything seems pretty counter productive given we *do* had drivers with this issue before *and* still have them upstream, and can end up with more drivers like this later. Luis