From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755394AbbEFHHn (ORCPT ); Wed, 6 May 2015 03:07:43 -0400 Received: from mail-pa0-f51.google.com ([209.85.220.51]:34413 "EHLO mail-pa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751392AbbEFHHj (ORCPT ); Wed, 6 May 2015 03:07:39 -0400 Date: Wed, 6 May 2015 16:07:56 +0900 From: Sergey Senozhatsky To: Sergey Senozhatsky Cc: Minchan Kim , Sergey Senozhatsky , Andrew Morton , Nitin Gupta , linux-kernel@vger.kernel.org Subject: Re: [PATCHv4 00/10] add on-demand device creation Message-ID: <20150506070756.GC820@swordfish> References: <1430743142-15854-1-git-send-email-sergey.senozhatsky@gmail.com> <20150506050114.GA29132@blaptop> <20150506052557.GA820@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150506052557.GA820@swordfish> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (05/06/15 14:25), Sergey Senozhatsky wrote: > a-ha... found it: > http://lkml.iu.edu/hypermail/linux/kernel/1505.0/04389.html > well... that's weird. can you reproduce this easily? we do zram_add(): zram_remove(): ------------------------------------------- mutex_lock(idr); idr_alloc() ... ->major = 252; ->first_minor = idr index; add_disk(); mumutex_unlock(idr); mutex_lock(idr); ... idr_remove(idr index); del_gendisk(); put_disk(); mutex_unlock(idr); script attempted to create a new device with minor (idr index) 2, but there was a kernfs node from already removed zram2: '/devices/virtual/bdi/252:2' from your logs: ... [ 98.756017] zram: Removed device: zram2 [ 98.757087] ------------[ cut here ]------------ ... locked zram_index_mutex, removed zram2, unlocked zram_index_mutex, locked zram_index_mutex, attempted to create zram2: zram2 sysfs already exist. hm... need to think. zram hot/remove is serialized. a separate issue: /* * FIXME: error handling */ void add_disk(struct gendisk *disk) does not handle any errors at all nor it reports any errors back to caller: 612 /* Register BDI before referencing it from bdev */ 613 bdi = &disk->queue->backing_dev_info; 614 bdi_register_dev(bdi, disk_devt(disk)); 615 616 blk_register_region(disk_devt(disk), disk->minors, NULL, 617 exact_match, exact_lock, disk); 618 register_disk(disk); 619 blk_register_queue(disk); 620 621 /* 622 * Take an extra ref on queue which will be put on disk_release() 623 * so that it sticks around as long as @disk is there. 624 */ 625 WARN_ON_ONCE(!blk_get_queue(disk->queue)); 626 627 retval = sysfs_create_link(&disk_to_dev(disk)->kobj, &bdi->dev->kobj, 628 "bdi"); 629 WARN_ON(retval); if bdi_register_dev()->device_add() fails (for example), then sysfs_create_link() is just "expected" to cause: [ 98.819810] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 [ 98.820591] IP: [] sysfs_do_create_link_sd.isra.2+0x40/0xd0 [ 98.821290] PGD 61669067 PUD 61553067 PMD 0 [ 98.821709] Oops: 0000 [#1] SMP [..] [ 98.823663] Call Trace: [ 98.823663] [] ? disk_part_iter_next+0x2b/0x280 [ 98.823663] [] sysfs_create_link+0x25/0x50 [ 98.823663] [] add_disk+0x252/0x4e0 or: [ 98.823663] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:21 [ 98.823663] in_atomic(): 1, irqs_disabled(): 1, pid: 2952, name: cat [ 98.823663] INFO: lockdep is turned off. [ 98.823663] irq event stamp: 3392 [ 98.823663] hardirqs last enabled at (3391): [] __mutex_unlock_slowpath+0xb3/0x180 [ 98.823663] hardirqs last disabled at (3392): [] error_sti+0x5/0x6 [ 98.823663] softirqs last enabled at (0): [] copy_process.part.35+0x4d9/0x1ce0 [ 98.823663] softirqs last disabled at (0): [< (null)>] (null) [ 98.823663] CPU: 5 PID: 2952 Comm: cat Tainted: G D W 4.1.0-rc2-next-20150505+ #1260 [ 98.823663] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 98.823663] ffff88005d40f8c8 ffff88005d40f8c8 ffffffff8163d8d8 0000000000000000 [ 98.823663] 0000000000000000 ffff88005d40f8f8 ffffffff8108c18e ffffffff8108c005 [ 98.823663] ffffffff819ec8b3 0000000000000015 0000000000000000 ffff88005d40f928 [ 98.823663] Call Trace: [ 98.823663] [] dump_stack+0x4c/0x65 [ 98.823663] [] ___might_sleep+0x18e/0x250 [ 98.823663] [] ? ___might_sleep+0x5/0x250 [ 98.823663] [] __might_sleep+0x4d/0x90 [ 98.823663] [] ? __might_sleep+0x5/0x90 [ 98.823663] [] down_read+0x24/0x70 [ 98.823663] [] ? down_read+0x5/0x70 [ 98.823663] [] ? exit_signals+0x24/0x130 [ 98.823663] [] exit_signals+0x24/0x130 [ 98.823663] [] ? exit_signals+0x5/0x130 [ 98.823663] [] ? do_exit+0xb8/0xbc0 [ 98.823663] [] do_exit+0xb8/0xbc0 [ 98.823663] [] ? do_exit+0x5/0xbc0 [ 98.823663] [] ? kmsg_dump+0x119/0x1a0 [ 98.823663] [] ? kmsg_dump+0x25/0x1a0 [ 98.823663] [] oops_end+0x8e/0xd0 [ 98.823663] [] ? oops_end+0x5/0xd0 [ 98.823663] [] no_context+0x2d9/0x33e [ 98.823663] [] ? no_context+0x5/0x33e [ 98.823663] [] __bad_area_nosemaphore+0x78/0x1d1 [ 98.823663] [] ? bad_area_nosemaphore+0x5/0x15 [ 98.823663] [] bad_area_nosemaphore+0x13/0x15 [ 98.823663] [] __do_page_fault+0x9e/0x490 [ 98.823663] [] ? __do_page_fault+0x5/0x490 [ 98.823663] [] do_page_fault+0xc/0x10 [ 98.823663] [] page_fault+0x22/0x30 [ 98.823663] [] ? sysfs_do_create_link_sd.isra.2+0x40/0xd0 [ 98.823663] [] ? sysfs_do_create_link_sd.isra.2+0x40/0xd0 [ 98.823663] [] ? disk_part_iter_next+0x2b/0x280 [ 98.823663] [] sysfs_create_link+0x25/0x50 [ 98.823663] [] add_disk+0x252/0x4e0 there are lots of places in add_disk() that can potentially fail. it's probably time to "fix" it. including numerous add_disk() callers, that don't check for errors. -ss