From patchwork Thu Aug 16 15:25:13 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Theodore Ts'o X-Patchwork-Id: 178041 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 879AA2C063F for ; Fri, 17 Aug 2012 01:25:43 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964831Ab2HPPZT (ORCPT ); Thu, 16 Aug 2012 11:25:19 -0400 Received: from li9-11.members.linode.com ([67.18.176.11]:45025 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756288Ab2HPPZR (ORCPT ); Thu, 16 Aug 2012 11:25:17 -0400 Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.72) (envelope-from ) id 1T21wd-0005SF-KJ; Thu, 16 Aug 2012 15:25:11 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 6B28424466F; Thu, 16 Aug 2012 11:25:13 -0400 (EDT) Date: Thu, 16 Aug 2012 11:25:13 -0400 From: Theodore Ts'o To: Fengguang Wu Cc: Marti Raudsepp , Kernel hackers , ext4 hackers , maze@google.com Subject: Re: NULL pointer dereference in ext4_ext_remove_space on 3.5.1 Message-ID: <20120816152513.GA31346@thunk.org> Mail-Followup-To: Theodore Ts'o , Fengguang Wu , Marti Raudsepp , Kernel hackers , ext4 hackers , maze@google.com References: <20120816024654.GB3781@thunk.org> <20120816111051.GA16036@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120816111051.GA16036@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Aug 16, 2012 at 07:10:51PM +0800, Fengguang Wu wrote: > > Here is the dmesg. BTW, it seems 3.5.0 don't have this issue. Fengguang, It sounds like you have a (at least fairly) reliable reproduction for this problem? Is it something you can share? It would be good to get this into our test suites, since it was _not_ something that was caught by xfstests, apparently. Can you see if this patch addresses it? (The first two patch hunks are the same debugging additions I had posted before.) It looks like the responsible commit is 968dee7722: "ext4: fix hole punch failure when depth is greater than 0". I had thought this patch was low risk if you weren't using the new punch ioctl, but it turns out it did make a critical change in the non-punch (i.e., truncate) code path, which is what the addition of "i = 0;" in the patch below addresses. Regards, - Ted --- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 769151d..fa829dc 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -2432,6 +2432,10 @@ ext4_ext_rm_leaf(handle_t *handle, struct inode *inode, /* the header must be checked already in ext4_ext_remove_space() */ ext_debug("truncate since %u in leaf to %u\n", start, end); + if (!path[depth].p_hdr && !path[depth].p_bh) { + EXT4_ERROR_INODE(inode, "depth %d", depth); + BUG_ON(1); + } if (!path[depth].p_hdr) path[depth].p_hdr = ext_block_hdr(path[depth].p_bh); eh = path[depth].p_hdr; @@ -2730,6 +2734,10 @@ cont: /* this is index block */ if (!path[i].p_hdr) { ext_debug("initialize header\n"); + if (!path[i].p_hdr && !path[i].p_bh) { + EXT4_ERROR_INODE(inode, "i=%d", i); + BUG_ON(1); + } path[i].p_hdr = ext_block_hdr(path[i].p_bh); } @@ -2828,6 +2836,7 @@ out: kfree(path); if (err == -EAGAIN) { path = NULL; + i = 0; goto again; } ext4_journal_stop(handle);