[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADyq12xk-2Fhnf_rJQ70oC1_98OEBJqwxOt6z=PpJa5V=X3dFQ@mail.gmail.com>
Date: Mon, 4 Oct 2021 14:40:52 -0400
From: Brian Geffon <bgeffon@...gle.com>
To: Minchan Kim <minchan@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Nitin Gupta <ngupta@...are.org>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Jonathan Corbet <corbet@....net>,
LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
linux-block@...r.kernel.org,
Suleiman Souhlal <suleiman@...gle.com>,
Jesse Barnes <jsbarnes@...gle.com>
Subject: Re: [PATCH] zram: Allow backing device to be assigned after init
On Mon, Oct 4, 2021 at 2:29 PM Minchan Kim <minchan@...nel.org> wrote:
>
> On Fri, Oct 01, 2021 at 11:16:27AM -0700, Brian Geffon wrote:
> > There does not appear to be a technical reason to not
> > allow the zram backing device to be assigned after the
> > zram device is initialized.
> >
> > This change will allow for the backing device to be assigned
> > as long as no backing device is already assigned. In that
> > event backing_dev would return -EEXIST.
> >
> > Signed-off-by: Brian Geffon <bgeffon@...gle.com>
> > ---
> > drivers/block/zram/zram_drv.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index fcaf2750f68f..12b4555ee079 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -462,9 +462,9 @@ static ssize_t backing_dev_store(struct device *dev,
> > return -ENOMEM;
> >
> > down_write(&zram->init_lock);
> > - if (init_done(zram)) {
> > - pr_info("Can't setup backing device for initialized device\n");
> > - err = -EBUSY;
> > + if (zram->backing_dev) {
> > + pr_info("Backing device is already assigned\n");
> > + err = -EEXIST;
> > goto out;
>
> Hi Brian,
>
Hi Minchan,
> I am worry about the inconsistency with other interface of current zram
> set up. They were supposed to set it up before zram disksize setting
> because it makes code more simple/maintainalbe in that we don't need
> to check some feature on the fly.
>
> Let's think about when zram extends the writeback of incompressible
> page on demand. The write path will need the backing_dev under
> down_read(&zarm->init_lock) or other conditional variable to check
> whether the feature is enabled or not on the fly.
I don't follow what you mean by that, writeback_store already holds
down_read(&zarm->init_lock).
Brian
Powered by blists - more mailing lists