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: <CADyq12w2sHdeBhAKVP+5GghHMqNZN+h36ydV7gi8QxOcHZ7f7A@mail.gmail.com>
Date:   Tue, 5 Oct 2021 11:01:15 -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

Hi Minchan,
Thank you for expanding on that. The only situation where there will
be lock contention that is problematic is when we're storing the
backing device the first time, all other times the lock will be held
as a read. Once the backing device has been set it cannot be set again
(it would return -EEXIST). I think no matter what if we're doing
writeback, even with the optimization you're describing, you'd have to
hold the zram->init_lock as read to validate that you have a writeback
device. Does that make sense?

Brian

On Mon, Oct 4, 2021 at 4:55 PM Minchan Kim <minchan@...nel.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@...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.