From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754050AbcKVALK (ORCPT ); Mon, 21 Nov 2016 19:11:10 -0500 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:51563 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753260AbcKVALJ (ORCPT ); Mon, 21 Nov 2016 19:11:09 -0500 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Tue, 22 Nov 2016 09:11:04 +0900 From: Minchan Kim To: Takashi Iwai Cc: Nitin Gupta , Sergey Senozhatsky , David Disseldorp , linux-kernel@vger.kernel.org Subject: Re: [PATCH] zram: Fix unbalanced idr management at hot removal Message-ID: <20161122001104.GA31611@bbox> References: <20161121132140.12683-1-tiwai@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161121132140.12683-1-tiwai@suse.de> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 21, 2016 at 02:21:40PM +0100, Takashi Iwai wrote: > The zram hot removal code calls idr_remove() even when zram_remove() > returns an error (typically -EBUSY). This results in a leftover at > the device release, eventually leading to a crash when the module is > reloaded. > > As described in the bug report below, the following procedure would > cause an Oops with zram: > > - provision three zram devices via modprobe zram num_devices=3 > - configure a size for each device > + echo "1G" > /sys/block/$zram_name/disksize > - mkfs and mount zram0 only > - attempt to hot remove all three devices > + echo 2 > /sys/class/zram-control/hot_remove > + echo 1 > /sys/class/zram-control/hot_remove > + echo 0 > /sys/class/zram-control/hot_remove > - zram0 removal fails with EBUSY, as expected > - unmount zram0 > - try zram0 hot remove again > + echo 0 > /sys/class/zram-control/hot_remove > - fails with ENODEV (unexpected) > - unload zram kernel module > + completes successfully > - zram0 device node still exists > - attempt to mount /dev/zram0 > + mount command is killed > + following BUG is encountered > > BUG: unable to handle kernel paging request at ffffffffa0002ba0 > IP: [] get_disk+0x16/0x50 > Oops: 0000 [#1] SMP > CPU: 0 PID: 252 Comm: mount Not tainted 4.9.0-rc6 #176 > task: ffff88001a9f2800 task.stack: ffffc90000300000 > RIP: 0010:[] [] get_disk+0x16/0x50 > Call Trace: > [] exact_lock+0xc/0x20 > [] kobj_lookup+0xdc/0x160 > [] ? disk_map_sector_rcu+0x70/0x70 > [] ? blkdev_get_by_dev+0x50/0x50 > [] get_gendisk+0x2f/0x110 > [] ? blkdev_get_by_dev+0x50/0x50 > [] __blkdev_get+0x10c/0x3c0 > [] ? blkdev_get_by_dev+0x50/0x50 > [] blkdev_get+0x19d/0x2e0 > [] ? blkdev_get_by_dev+0x50/0x50 > [] blkdev_open+0x56/0x70 > [] do_dentry_open.isra.19+0x1ff/0x310 > [] vfs_open+0x43/0x60 > [] path_openat+0x2c9/0xf30 > [] ? __save_stack_trace+0x40/0xd0 > [] do_filp_open+0x79/0xd0 > [] ? kmemleak_alloc+0x49/0xa0 > [] do_sys_open+0x114/0x1e0 > [] SyS_open+0x19/0x20 > [] entry_SYSCALL_64_fastpath+0x13/0x94 > > This patch adds the proper error check in hot_remove_store() not to > call idr_remove() unconditionally. > > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1010970 > Reported-and-tested-by: David Disseldorp > Reviewed-by: David Disseldorp > Cc: > Signed-off-by: Takashi Iwai Acked-by: Minchan Kim Thanks!