From: Eric Sandeen Subject: Re: [PATCH] ext4: Don't call sb_issue_discard() in ext4_free_blocks() Date: Tue, 09 Nov 2010 10:36:05 -0600 Message-ID: <4CD97875.6050703@redhat.com> References: <1289196382-31239-1-git-send-email-tytso@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Ext4 Developers List , jiayingz@google.com To: "Theodore Ts'o" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:24412 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751222Ab0KIQgK (ORCPT ); Tue, 9 Nov 2010 11:36:10 -0500 In-Reply-To: <1289196382-31239-1-git-send-email-tytso@mit.edu> Sender: linux-ext4-owner@vger.kernel.org List-ID: On 11/8/10 12:06 AM, Theodore Ts'o wrote: > Commit 5c521830cf (ext4: Support discard requests when running in > no-journal mode) attempts to add sb_issue_discard() for data blocks > (in data=3Dwriteback mode) and in no-journal mode. Unfortunately, th= is > no longer works, because in commit dd3932eddf (block: remove > BLKDEV_IFL_WAIT), sb_issue_discard() only presents a synchronous > interface, and there are times when we call ext4_free_blocks() when w= e > are are holding a spinlock, or are otherwise in an atomic context. >=20 > For now, I've removed the call to sb_issue_discard() to prevent a > deadlock or (if spinlock debugging is enabled) failures like this: perhaps mount should fail with the combination of -o discard and no journal present? -Eric > BUG: scheduling while atomic: rc.sysinit/1376/0x00000002 > Pid: 1376, comm: rc.sysinit Not tainted 2.6.36-ARCH #1 > Call Trace: > [] __schedule_bug+0x5e/0x70 > [] schedule+0x950/0xa70 > [] ? insert_work+0x7d/0x90 > [] ? queue_work_on+0x1d/0x30 > [] ? queue_work+0x37/0x60 > [] schedule_timeout+0x21d/0x360 > [] ? generic_make_request+0x2c3/0x540 > [] wait_for_common+0xc0/0x150 > [] ? default_wake_function+0x0/0x10 > [] ? submit_bio+0x7c/0x100 > [] ? wake_bit_function+0x0/0x40 > [] wait_for_completion+0x18/0x20 > [] blkdev_issue_discard+0x1b9/0x210 > [] ext4_free_blocks+0x68e/0xb60 > [] ? __ext4_handle_dirty_metadata+0x110/0x120 > [] ext4_ext_truncate+0x8cc/0xa70 > [] ? pagevec_lookup+0x1e/0x30 > [] ext4_truncate+0x178/0x5d0 > [] ? unmap_mapping_range+0xab/0x280 > [] vmtruncate+0x56/0x70 > [] ext4_setattr+0x14b/0x460 > [] notify_change+0x194/0x380 > [] do_truncate+0x60/0x90 > [] ? security_inode_permission+0x1a/0x20 > [] ? tomoyo_path_truncate+0x11/0x20 > [] do_last+0x5d9/0x770 > [] do_filp_open+0x1ed/0x680 > [] ? page_fault+0x1f/0x30 > [] ? alloc_fd+0xec/0x140 > [] do_sys_open+0x61/0x120 > [] sys_open+0x1b/0x20 > [] system_call_fastpath+0x16/0x1b >=20 > https://bugzilla.kernel.org/show_bug.cgi?id=3D22302 >=20 > Reported-by: Mathias Bur=C3=A9n > Signed-off-by: "Theodore Ts'o" > Cc: jiayingz@google.com > --- > fs/ext4/mballoc.c | 2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) >=20 > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c > index c58eba3..5b4d4e3 100644 > --- a/fs/ext4/mballoc.c > +++ b/fs/ext4/mballoc.c > @@ -4640,8 +4640,6 @@ do_more: > * with group lock held. generate_buddy look at > * them with group lock_held > */ > - if (test_opt(sb, DISCARD)) > - ext4_issue_discard(sb, block_group, bit, count); > ext4_lock_group(sb, block_group); > mb_clear_bits(bitmap_bh->b_data, bit, count); > mb_free_blocks(inode, &e4b, bit, count); -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html