[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YW8AQ4fMNV8MT1vX@kroah.com>
Date: Tue, 19 Oct 2021 19:28:35 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: Ming Lei <ming.lei@...hat.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>, tj@...nel.org,
akpm@...ux-foundation.org, minchan@...nel.org, jeyu@...nel.org,
shuah@...nel.org, bvanassche@....org, dan.j.williams@...el.com,
joe@...ches.com, tglx@...utronix.de, keescook@...omium.org,
rostedt@...dmis.org, linux-spdx@...r.kernel.org,
linux-doc@...r.kernel.org, linux-block@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 11/12] zram: fix crashes with cpu hotplug multistate
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.
thanks,
greg k-h
Powered by blists - more mailing lists