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;
MIME-Version: 1.0
References: <20211001181627.394921-1-bgeffon@google.com> <YVtH60zyzq9AhUv2@google.com>
 <CADyq12xk-2Fhnf_rJQ70oC1_98OEBJqwxOt6z=PpJa5V=X3dFQ@mail.gmail.com>
 <YVtqHv+p3uYkbu5E@google.com> <CADyq12w2sHdeBhAKVP+5GghHMqNZN+h36ydV7gi8QxOcHZ7f7A@mail.gmail.com>
In-Reply-To: <CADyq12w2sHdeBhAKVP+5GghHMqNZN+h36ydV7gi8QxOcHZ7f7A@mail.gmail.com>
From:   Brian Geffon <bgeffon@google.com>
Date:   Tue, 5 Oct 2021 11:18:38 -0400
Message-ID: <CADyq12zNcXAS8+7GwMPsbFNgn-M-7e+mtR=_9PXBTOfX65yoew@mail.gmail.com>
Subject: Re: [PATCH] zram: Allow backing device to be assigned after init
To:     Minchan Kim <minchan@kernel.org>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Nitin Gupta <ngupta@vflare.org>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        Jonathan Corbet <corbet@lwn.net>,
        LKML <linux-kernel@vger.kernel.org>, linux-doc@vger.kernel.org,
        linux-block@vger.kernel.org,
        Suleiman Souhlal <suleiman@google.com>,
        Jesse Barnes <jsbarnes@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

> On Mon, Oct 4, 2021 at 4:55 PM Minchan Kim <minchan@kernel.org> wrote:
> >
> > On Mon, Oct 04, 2021 at 02:40:52PM -0400, Brian Geffon wrote:
> > > On Mon, Oct 4, 2021 at 2:29 PM Minchan Kim <minchan@kernel.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@google.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).
> >
> > I should have explained a bit more. Sorry about that.
> > I am thinking about a feature to deal with incompressible page.
> > Let's have an example to handle incompressible page for that.
> >
> > zram_bvec_rw
> >   zram_bvec_write
> >     if (comp_len >= huge_class)
> >         zs_page_writeback
> >             down_read(&zram->init_lock) or some other way
> >
> > It's just idea for incompressible page but we might intorduce
> > the way for other compresible pages, too at some condition.

(sorry for the top post before)

Hi Minchan,
I guess the point I was trying to make was that so long as we allow a
reset operation we'll need to be taking the init lock in read mode
before doing any writeback. Does that seem right?

Brian