linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Maciej Żenczykowski" <maze@google.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>,
	Marti Raudsepp <marti@juffo.org>,
	Kernel hackers <linux-kernel@vger.kernel.org>,
	ext4 hackers <linux-ext4@vger.kernel.org>
Subject: Re: NULL pointer dereference in ext4_ext_remove_space on 3.5.1
Date: Thu, 16 Aug 2012 18:26:29 -0400	[thread overview]
Message-ID: <20120816222629.GG31346@thunk.org> (raw)
In-Reply-To: <CANP3RGd62=voh5T6NACyFE-NqX=Huk1hkewSakPs67vC+uuTuw@mail.gmail.com>

On Thu, Aug 16, 2012 at 02:40:53PM -0700, Maciej Żenczykowski wrote:
> 
> This happened twice to me while moving data off of a ~1TB ext4 partition.
> The data portion was on a stripe raid across 2 ~500GB drives, the
> journal was on a relatively large partition (500MB?) on an SSD.
> (crypto and lvm were also involved).
> ...
> Perhaps just untarring a bunch of kernels onto an empty partition,
> filling it up, then deleting those kernels should be sufficient to
> repro this (untried).

Thanks, that's really helpful.   I can say that using a 4MB journal and
running fsstress is _not_ enough to trigger the problem.

Looking more closely at what might be needed to trigger the bug, 'i'
gets left uninitialized when err is set to -EAGAIN, and that happens
when ext4_ext_truncate_extend_restart() is unable to extend the
journal transaction.  But that also means we need to be deleting a
sufficiently large enough file that the blocks span multiple block
groups (which is why we need to extend the transaction, so we can
modify more bitmap blocks) at the point when there is no more room in
the journal, so we have to close the current transaction, and then
retry it again with a new journal handle in a new transaction.

So that implies that untaring a bunch of kernels probably won't be
sufficient, since the files will be too small.  What we probably will
need to do is to fill a large file system with lots of large files,
use a small journal, and then try to do an rm -rf.

          	    	     	      	     - Ted

  reply	other threads:[~2012-08-16 22:26 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-15 18:33 NULL pointer dereference in ext4_ext_remove_space on 3.5.1 Marti Raudsepp
2012-08-16  2:46 ` Theodore Ts'o
2012-08-16 11:10   ` Fengguang Wu
2012-08-16 15:25     ` Theodore Ts'o
2012-08-16 20:21       ` Maciej Żenczykowski
2012-08-16 21:19         ` Theodore Ts'o
2012-08-16 21:40           ` Maciej Żenczykowski
2012-08-16 22:26             ` Theodore Ts'o [this message]
2012-08-16 22:44               ` Maciej Żenczykowski
2012-08-17  6:01       ` Fengguang Wu
2012-08-17 13:15         ` Theodore Ts'o
2012-08-17 13:22           ` Fengguang Wu
2012-08-17 17:48           ` Christoph Hellwig
2012-08-17  6:09       ` ext4 write performance regression in 3.6-rc1 Fengguang Wu
2012-08-17 13:40         ` Theodore Ts'o
2012-08-17 14:13           ` Fengguang Wu
2012-08-17 14:25           ` ext4 write performance regression in 3.6-rc1 on RAID0/5 Fengguang Wu
     [not found]             ` <20120817151318.GA2341@localhost>
2012-08-17 15:37               ` Theodore Ts'o
2012-08-17 20:44             ` NeilBrown
2012-08-21  9:42               ` Fengguang Wu
2012-08-21 12:07                 ` Fengguang Wu
     [not found]             ` <20120822035702.GF2570@yliu-dev.sh.intel.com>
2012-08-22  4:07               ` Shaohua Li
2012-08-22  6:00               ` NeilBrown
2012-08-22  6:31                 ` Yuanhan Liu
2012-08-22  7:14                 ` Andreas Dilger
2012-08-22 20:47                 ` Dan Williams
2012-08-22 21:59                   ` NeilBrown
2012-09-17 12:21   ` NULL pointer dereference in ext4_ext_remove_space on 3.5.1 Dmitry Monakhov
2012-09-17 13:52     ` Theodore Ts'o
2012-09-17 14:48       ` Dmitry Monakhov
2012-08-16  9:00 ` Fengguang Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120816222629.GG31346@thunk.org \
    --to=tytso@mit.edu \
    --cc=fengguang.wu@intel.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marti@juffo.org \
    --cc=maze@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).