[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.21.2110190820590.15009@pobox.suse.cz>
Date: Tue, 19 Oct 2021 08:23:51 +0200 (CEST)
From: Miroslav Benes <mbenes@...e.cz>
To: Ming Lei <ming.lei@...hat.com>
cc: Luis Chamberlain <mcgrof@...nel.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>, tj@...nel.org,
gregkh@...uxfoundation.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
> > By you only addressing the deadlock as a requirement on approach a) you are
> > forgetting that there *may* already be present drivers which *do* implement
> > such patterns in the kernel. I worked on addressing the deadlock because
> > I was informed livepatching *did* have that issue as well and so very
> > likely a generic solution to the deadlock could be beneficial to other
> > random drivers.
>
> In-tree zram doesn't have such deadlock, if livepatching has such AA deadlock,
> just fixed it, and seems it has been fixed by 3ec24776bfd0.
I would not call it a fix. It is a kind of ugly workaround because the
generic infrastructure lacked (lacks) the proper support in my opinion.
Luis is trying to fix that.
Just my two cents.
Miroslav
Powered by blists - more mailing lists