linux-kernel - Re: [PATCH] zram: Allow backing device to be assigned after init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YVtqHv+p3uYkbu5E@google.com>
Date:   Mon, 4 Oct 2021 13:54:54 -0700
From:   Minchan Kim <minchan@...nel.org>
To:     Brian Geffon <bgeffon@...gle.com>
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 04, 2021 at 02:40:52PM -0400, Brian Geffon wrote:
> 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).

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.