linux-kernel - Re: [PATCH V2 0/4] zram: fix two races and one zram leak

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: <YXGnijd+Ca+bWJZs@bombadil.infradead.org>
Date:   Thu, 21 Oct 2021 10:46:50 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Minchan Kim <minchan@...nel.org>
Cc:     Ming Lei <ming.lei@...hat.com>, Jens Axboe <axboe@...nel.dk>,
        linux-block@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 0/4] zram: fix two races and one zram leak

On Thu, Oct 21, 2021 at 10:39:46AM -0700, Luis Chamberlain wrote:
> On Wed, Oct 20, 2021 at 02:40:05PM -0700, Minchan Kim wrote:
> > On Wed, Oct 20, 2021 at 09:55:44AM +0800, Ming Lei wrote:
> > > Hello,
> > > 
> > > Fixes three issues reported by Luis Chamberlain with one simpler approach:
> > > 
> > > - race between between zram_reset_device() and disksize_store() (1/4)
> > > 
> > > - zram leak during unloading module, which is one race between resetting
> > > and removing device (2/4)
> > > 
> > > - race between zram_remove and disksize_store (3/4)
> > > 
> > > Also replace replace fsync_bdev with sync_blockdev since no one opens
> > > it.(4/4)
> > > 
> > > V2:
> > > 	- take another approach to avoid failing of zram_remove()
> > > 	- add patch to address race between zram_reset_device() and
> > > 	  disksize_store()
> > > 
> > 
> > Thanks for breaking the problems down, Ming.
> > 
> > To me, the whole patchset looks good to me since each patch solves
> > the problem step by step and finally fix.
> > 
> > Luis, do you have any concern of this patchset to solve the cpuhp
> > problem? (Sorry in advance if I miss some concerns if you raised
> > in different thread. I'm totally lost).
> 
> Running tests against this now. Will report back!

So indeed with these patches I end up in the situation where we if
if spawn two ltp zram02.sh runs and cancel then randomly and start
them again:

zram: Can't change algorithm for initialized device

And after that only if you do:

swapoff /dev/zram0

Only then can you restart the tests again.

I had note seen that with my patch fix, but But Ming noted that he
did see that, and I trust him, although I can't reproduce that issue.

And from at lest a testing perspective then:

Tested-by: Luis Chamberlain <mcgrof@...nel.org>

I'll go and do the line-by-line code review now.

  Luis