linux-kernel - Re: [PATCH v2 0/4] zram: fix few sysfs races

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 19 May 2021 13:09:09 -0700
From:   Minchan Kim <minchan@...nel.org>
To:     Luis Chamberlain <mcgrof@...nel.org>
Cc:     ngupta@...are.org, sergey.senozhatsky.work@...il.com,
        axboe@...nel.dk, mbenes@...e.com, jpoimboe@...hat.com,
        tglx@...utronix.de, keescook@...omium.org, jikos@...nel.org,
        rostedt@...dmis.org, peterz@...radead.org,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/4] zram: fix few sysfs races

On Fri, Apr 23, 2021 at 01:11:04AM +0000, Luis Chamberlain wrote:
> This 2nd series documents the fixes better and includes a bdgrab() fix
> for the issue noted by Minchan. A general fix has been proposed for two
> of these issues however they are not yet deemed required upstream and so
> we just open code individual solutions on the driver.
> 
> Luis Chamberlain (4):
>   zram: fix crashes due to use of cpu hotplug multistate
>   zram: avoid disksize setting when device is being claimed
>   zram: fix deadlock with sysfs attribute usage and driver removal
>   zram: fix possible races between sysfs use and bdev access
> 
>  drivers/block/zram/zram_drv.c | 473 +++++++++++++++++++++++++++++-----
>  1 file changed, 414 insertions(+), 59 deletions(-)

Hi Luis,

First of all, I am sorry too late review. Now I see [3/4] and [4/4] would
be not only zram issue since you shed a light in the descriptions.
Yeah, that would be helpful if it could be deal with under general
layer but looks like arguable or would take some times at least, IIUC.

On the case, yeah, we could fix it for zram first until the issue will
bring up further. Anyway, I'd like to see some wrapper rather than annotating
for every sysfs files for maintainance point of view.
At least, could you introduce one more patch "introduce zram sysfs wrapper"
on top of this series to centralize the work?

Thanks for your works!