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:   Wed, 10 Mar 2021 21:21:28 +0000
From:   Luis Chamberlain <mcgrof@kernel.org>
To:     Minchan Kim <minchan@kernel.org>
Cc:     ngupta@vflare.org, sergey.senozhatsky.work@gmail.com,
        axboe@kernel.dk, mbenes@suse.com, linux-block@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug
 multistate
Message-ID: <20210310212128.GR4332@42.do-not-panic.com>
References: <20210306022035.11266-1-mcgrof@kernel.org>
 <20210306022035.11266-2-mcgrof@kernel.org>
 <YEbjom8FIclEgRYv@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YEbjom8FIclEgRYv@google.com>
Precedence: bulk

On Mon, Mar 08, 2021 at 06:55:30PM -0800, Minchan Kim wrote:
> If I understand correctly, bugs you found were related to module
> unloading race while the zram are still working.

No, that is a simplifcation of the issue. The issue consists of
two separate issues:

 a) race against module unloading in light of incorrect racty use of
    cpu hotplug multistate support
 b) module unload race with sysfs attribute race on *any* driver which
    has sysfs attributes which also shares the same lock as used during
    module unload

It is important to realize that issue b) is actually a generic kernel
issue, it would be present on *any* driver which shares a lock used on
a sysfs attribute and module unload. I looked to implement a generic
solution on kernfs, however we don't yet have semantics to enable this
generically, and so for now each driver needs to deal with those races
on their own. That sysfs race is dealt with in the second patch.

The first patch only deals with the cpu hotplug races exposed at module
unloading.

  Luis