[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210521201618.GX4332@42.do-not-panic.com>
Date: Fri, 21 May 2021 20:16:18 +0000
From: Luis Chamberlain <mcgrof@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Minchan Kim <minchan@...nel.org>, Hannes Reinecke <hare@...e.de>,
Douglas Gilbert <dgilbert@...erlog.com>, ngupta@...are.org,
sergey.senozhatsky.work@...il.com, axboe@...nel.dk,
mbenes@...e.com, jpoimboe@...hat.com, tglx@...utronix.de,
keescook@...omium.org, jikos@...nel.org, rostedt@...dmis.org,
peterz@...radead.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/4] zram: fix few sysfs races
On Fri, May 21, 2021 at 10:01:52PM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 19, 2021 at 08:20:23PM +0000, Luis Chamberlain wrote:
> > Greg,
> >
> > your feedback would be appreciated here.
>
> Appreciated where? This is a zram patchset, what do I need to mess with
> it for?
This patchset has 2 issues which I noted in the last series that are
generic, and could best be dealt with on sysfs, and suggested
how this could actually be dealt with on sysfs / kernfs.
> > Greg, can you comment on technical levels why a general core fix is not
> > desirable upstream for those two issues?
>
> What issues exactly?
When I suggested the generic way to fix this your main argument against
a generic solution was that we don't support module removal. Given that
argument did not seem to hold any water it begs the question if you
still would rather not see this fixed in sysfs / kernfs.
If you however are more open to it now, I can instead take that work, and
send a proper patch for review.
Luis
Powered by blists - more mailing lists