lkml.org 
[lkml]   [2015]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] zram: fix umount-reset_store-mount race condition
On (02/03/15 23:52), Sergey Senozhatsky wrote:
> On (02/03/15 23:15), Sergey Senozhatsky wrote:
> > > How about keep this here? Protected by zram->init_lock.
> > > set_capacity(zram->disk, 0);
> >
> > why?
> >
> yeah, I see why. good catch.
>
> hm, why do we perform destroy_device() before zram_reset_device() in
> zram_exit()?
>
> how about doing something like this (I don't want to return
> that bool param back):

disregard the last one.


this is done to remove sysfs before we do reset, so we don't race module
unload with `echo 2G > /.../disksize', f.e.

well, several options:

1) move ->init_lock from zram_reset_device() to its callers.
iow, do

down_write(&zram->init_lock);
zram_reset_device(zram);
up_write(&zram->init_lock);

2) remove sysfs group separate, before zram_reset_device() in
zram_exit()

sysfs_remove_group()
zram_reset_device();
destroy_device();

3) return back bool reset_capacity to zram_reset_device(). but this one
is somewhat ungly. destroy() before reset() loks misleading, besides,
after destroy() in zram_reset_device() we
/*
* Shouldn't access zram->disk after destroy_device
* because destroy_device already released zram->disk.
*/

so we have garbaged ->disk pointer there, which is quite unsafe.

-ss


\
 
 \ /
  Last update: 2015-02-03 16:41    [W:2.193 / U:2.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site