linux-kernel - Re: [PATCH] zram: fix umount-reset

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150203150624.GB1046@swordfish>
Date:	Wed, 4 Feb 2015 00:06:24 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:	Ganesh Mahendran <opensource.ganesh@...il.com>,
	sergey.senozhatsky.work@...il.com,
	Minchan Kim <minchan@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jerome Marchand <jmarchan@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/