Hello,
On Wed, Feb 04, 2015 at 12:06:24AM +0900, Sergey Senozhatsky wrote:
> 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);
So, you mean this?
reset_store
down_write(&zram->init_lock);
zram_reset_device(zram);
set_capacity(zram->disk, 0);
up_write(&zram->init_lock);
If so, +1.
Hope you send a squash patch to Andrew.
>
> 2) remove sysfs group separate, before zram_reset_device() in
> zram_exit()
>
> sysfs_remove_group()
> zram_reset_device();
> destroy_device();
I want to keep sysfs creation/destory in zram create/destroy abstraction.
>
> 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.
Agree.
>
> -ss
--
Kind regards,
Minchan Kim
--
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/
