From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [PATCH] xen/blkfront: fix warning when deleting gendisk on unplug/shutdown. Date: Tue, 19 May 2009 08:28:34 +0200 Message-ID: <20090519062834.GQ4140@kernel.dk> References: <1242650931.20731.41.camel@zakaz.uk.xensource.com> <1242650974-13056-1-git-send-email-ian.campbell@citrix.com> <4A11B2C5.1020205@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4A11B2C5.1020205@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: xen-devel@lists.xensource.com, Ian Campbell List-Id: xen-devel@lists.xenproject.org On Mon, May 18 2009, Jeremy Fitzhardinge wrote: > Ian Campbell wrote: >> Currently blkfront gives a warning when hot unplugging due to calling >> del_gendisk() with interrupts disabled (due to blkif_io_lock). >> >> WARNING: at kernel/softirq.c:124 local_bh_enable+0x36/0x84() >> Modules linked in: xenfs xen_netfront ext3 jbd mbcache xen_blkfront >> Pid: 13, comm: xenwatch Not tainted 2.6.29-xs5.5.0.13 #3 >> Call Trace: >> [] warn_slowpath+0x80/0xb6 >> [] xen_sched_clock+0x16/0x63 >> [] xen_force_evtchn_callback+0xc/0x10 >> [] check_events+0x8/0xe >> [] xen_restore_fl_direct_end+0x0/0x1 >> [] xen_mc_flush+0x10a/0x13f >> [] __switch_to+0x114/0x14e >> [] dequeue_task+0x62/0x70 >> [] finish_task_switch+0x2b/0x84 >> [] schedule+0x66d/0x6e7 >> [] xen_force_evtchn_callback+0xc/0x10 >> [] xen_force_evtchn_callback+0xc/0x10 >> [] local_bh_enable+0x36/0x84 >> [] sk_filter+0x57/0x5c >> [] netlink_broadcast+0x1d5/0x315 >> [] kobject_uevent_env+0x28d/0x331 >> [] device_del+0x10f/0x120 >> [] device_unregister+0x8/0x10 >> [] bdi_unregister+0x2d/0x39 >> [] unlink_gendisk+0x23/0x3e >> [] del_gendisk+0x7b/0xe7 >> [] blkfront_closing+0x28/0x6e [xen_blkfront] >> [] backend_changed+0x3ad/0x41d [xen_blkfront] >> >> We can fix this by calling del_gendisk() later in blkfront_closing, after >> releasing blkif_io_lock. Since the queue is stopped during the interrupts >> disabled phase I don't think there is any danger of an event occuring between >> releasing the blkif_io_lock and deleting the disk. >> >> Signed-off-by: Ian Campbell >> Cc: Jeremy Fitzhardinge >> > > Looks OK to me. Alex Nixon came up with more or less the same patch to > replace his first failed attempt to fix this. It looks much better than > mucking around with interrupts states. > > Jens? How does it look to you? Yes, I have applied this one as well. -- Jens Axboe