Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 27 Jul 2021 10:35:10 -0700
From:   Luis Chamberlain <mcgrof@kernel.org>
To:     Greg KH <gregkh@linuxfoundation.org>,
        David Laight <David.Laight@aculab.com>
Cc:     akpm@linux-foundation.org, minchan@kernel.org, jeyu@kernel.org,
        ngupta@vflare.org, sergey.senozhatsky.work@gmail.com,
        rafael@kernel.org, axboe@kernel.dk, tj@kernel.org, mbenes@suse.com,
        jpoimboe@redhat.com, tglx@linutronix.de, keescook@chromium.org,
        jikos@kernel.org, rostedt@goodmis.org, peterz@infradead.org,
        linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 2/3] zram: fix deadlock with sysfs attribute usage and
 module removal
Message-ID: <YQBDzoSohQ0wbLN4@bombadil.infradead.org>
References: <20210703001958.620899-1-mcgrof@kernel.org>
 <20210703001958.620899-3-mcgrof@kernel.org>
 <YPgFGd+FZQZWODY7@kroah.com>
 <20210722221705.kyrdkpt6fwf5k56o@garbanzo>
 <YPqk5WCBgvNQzq4S@kroah.com>
 <20210723174919.ka3tzyre432uilf7@garbanzo>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210723174919.ka3tzyre432uilf7@garbanzo>
Sender: Luis Chamberlain <mcgrof@infradead.org>
Precedence: bulk

On Fri, Jul 23, 2021 at 10:49:19AM -0700, Luis Chamberlain wrote:
> We are talking about sysfs files and you're argument is that
> try_module_get() should lock the module, and so cannot be used
> in sysfs files. My point is that such module lock is inferred:
> 
> 1) Sysfs files are created by a module, that same module is responsible
>    for removing the same sysfs files.
> 2) The module can only be removed and gone, once *all* sysfs files are
>    removed first.
> 3) If any of the module's sysfs files are present the module must
>    still be present
> 4) kernfs ensures that if a file is opened the file will not be
>    removed until any pending operation completes
> 5) If a sysfs file is used to write something, that means the
>    sysfs file has not yet been removed, and we know it will
>    remain in existance throughout its entire operation
> 6) When a sysfs file operation is being run, the module must
>    always exist

Greg,

I'm inclined to believe my original generic solution would be better
again [0]. Specially since we can drop the dev_type_get() / dev_type_put()
stuff.

Thoughts?

[0] https://lore.kernel.org/linux-block/20210401235925.GR4332@42.do-not-panic.com/

  Luis