> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 3df4394..7fb72dc 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -1074,13 +1074,6 @@ static ssize_t reset_store(struct device *dev,
> if (!bdev)
> return
On (05/04/15 11:28), Minchan Kim wrote:
> [minchan]: use zram->claim to avoid lockdep splat
> Reported-by: Minchan Kim
> Signed-off-by: Sergey Senozhatsky
> ---
will take a look today, cleanup and re-submit. thanks!
> /*
>* Remove sysfs first, so no one will perform a disksize
>
On (05/04/15 11:20), Minchan Kim wrote:
> I had a time to think over it.
>
> I think your patch is rather tricky so someone cannot see sysfs
> although he already opened /dev/zram but after a while he can see sysfs.
> It's weired.
>
> I want to fix it more generic way. Othewise, we might have tro
On Mon, May 04, 2015 at 11:20:08AM +0900, Minchan Kim wrote:
> Hello Sergey,
>
> On Thu, Apr 30, 2015 at 03:51:12PM +0900, Sergey Senozhatsky wrote:
> > On (04/30/15 15:44), Minchan Kim wrote:
> > > > > I think the problem of deadlock is that you are trying to remove
> > > > > sysfs file
> > > >
Hello Sergey,
On Thu, Apr 30, 2015 at 03:51:12PM +0900, Sergey Senozhatsky wrote:
> On (04/30/15 15:44), Minchan Kim wrote:
> > > > I think the problem of deadlock is that you are trying to remove sysfs
> > > > file
> > > > in sysfs handler.
> > > >
> > > > #> echo 1 > /sys/xxx/zram_remove
> > >
On (04/30/15 15:44), Minchan Kim wrote:
> > > I think the problem of deadlock is that you are trying to remove sysfs
> > > file
> > > in sysfs handler.
> > >
> > > #> echo 1 > /sys/xxx/zram_remove
> > >
> > > kernfs_fop_write - hold s_active
> > > -> zram_remove_store
> > > -> zram_remove
On Thu, Apr 30, 2015 at 03:34:57PM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
>
> On (04/30/15 14:47), Minchan Kim wrote:
> [..]
> >
> > Isn't it related to bd_mutex?
>
> I think it is:
>
> [ 216.713922] Possible unsafe locking scenario:
> [ 216.713923]CPU0
On (04/30/15 15:34), Sergey Senozhatsky wrote:
> > Isn't it related to bd_mutex?
>
> I think it is:
>
I meant: I think it's related
> [ 216.713922] Possible unsafe locking scenario:
> [ 216.713923]CPU0CPU1
> [ 216.713924]
> [
Hello Minchan,
On (04/30/15 14:47), Minchan Kim wrote:
[..]
>
> Isn't it related to bd_mutex?
I think it is:
[ 216.713922] Possible unsafe locking scenario:
[ 216.713923]CPU0CPU1
[ 216.713924]
[ 216.713925] lock(&bdev->bd_mu
Hello Sergey,
On Wed, Apr 29, 2015 at 04:23:28PM +0900, Sergey Senozhatsky wrote:
> On (04/29/15 16:02), Sergey Senozhatsky wrote:
> > sure. I was talking about this one:
> >
> > CPU0CPU1
> > umount
> > zram_remove()
> > lock ->bd_mutex
> > zram_reset_devic
On (04/29/15 16:02), Sergey Senozhatsky wrote:
> sure. I was talking about this one:
>
> CPU0CPU1
> umount
> zram_remove()
> lock ->bd_mutex
> zram_reset_device()
> unlock ->bd_mutex
> disksize_store
>
Hello Minchan,
On (04/29/15 15:48), Minchan Kim wrote:
[..]
> >
> > CPU0CPU1
> > umount
> > zram_remove()
> > zram_reset_device() disksize_store()
> > mount
> > kfree zram
> >
> > or
> >
> > CPU0
Hello Sergey,
On Wed, Apr 29, 2015 at 09:16:24AM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> Minchan, a quick question. just to avoid resends and to make sure that I'm
> not missing any better solution.
>
>
> lockdep is unhappy here:
>
> > -static void zram_remove(struct zram *zram)
> > +sta
Hello,
Minchan, a quick question. just to avoid resends and to make sure that I'm
not missing any better solution.
lockdep is unhappy here:
> -static void zram_remove(struct zram *zram)
> +static int zram_remove(struct zram *zram)
> {
> - pr_info("Removed device: %s\n", zram->disk->disk_na
We currently don't support on-demand device creation. The one and only way
to have N zram devices is to specify num_devices module parameter (default
value: 1). IOW if, for some reason, at some point, user wants to have
N + 1 devies he/she must umount all the existing devices, unload the
module, lo
15 matches
Mail list logo
