linux-kernel - Re: [RFC PATCH v1 4/8] zram: destroy all devices on error recovery path in zram

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]

Date:	Tue, 4 Jun 2013 11:49:16 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	Jiang Liu <liuj97@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Nitin Gupta <ngupta@...are.org>,
	Minchan Kim <minchan@...nel.org>,
	Jerome Marchand <jmarchan@...hat.com>,
	Yijing Wang <wangyijing@...wei.com>,
	devel@...verdev.osuosl.org, Jiang Liu <jiang.liu@...wei.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 4/8] zram: destroy all devices on error recovery
 path in zram_init()

Everyone stop putting RFC on their bugfixes!  :P  No one wants to
pre-review patches.

On Mon, Jun 03, 2013 at 11:42:16PM +0800, Jiang Liu wrote:
> On error recovery path of zram_init(), it leaks the zram device object
> causing the failure.
> 

This is a real bug but the fix isn't right.  The object causing the
failure has only been partially set up.  And in some cases it has
been partially cleaned up, for example we could end up releasing
->queue twice.

The better way is to make create_device() clean up after itself
completely instead of only partly and sometimes.

regards,
dan carpenter

--
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/