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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
