All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@redhat.com>
To: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Cc: Josef Bacik <josef@redhat.com>, linux-btrfs@vger.kernel.org
Subject: Re: BUG: unable to handle kernel NULL pointer dereference at (null)
Date: Tue, 5 Apr 2011 15:31:43 -0400	[thread overview]
Message-ID: <20110405193142.GC484@dhcp231-156.rdu.redhat.com> (raw)
In-Reply-To: <201104052121.56288.johannes.hirte@fem.tu-ilmenau.de>

On Tue, Apr 05, 2011 at 09:21:55PM +0200, Johannes Hirte wrote:
> On Tuesday 05 April 2011 20:53:24 Josef Bacik wrote:
> > On Tue, Apr 05, 2011 at 08:52:21PM +0200, Johannes Hirte wrote:
> > > On Tuesday 05 April 2011 19:42:03 Josef Bacik wrote:
> > > > On Tue, Apr 05, 2011 at 07:38:13PM +0200, Johannes Hirte wrote:
> > > > > With the latest btrfs changes, I got this Oops when doing rm on a
> > > > > large directory:
> > > > > 
> > > > > BUG: unable to handle kernel NULL pointer dereference at   (null)
> > > > > IP: [<c101c838>] kunmap+0x46/0x46
> > > > > *pdpt = 0000000034a85001 *pde = 0000000000000000
> > > > > Oops: 0000 [#1] PREEMPT SMP
> > > > > last sysfs file: /sys/devices/virtual/vtconsole/vtcon1/uevent
> > > > > Modules linked in: snd_seq_oss snd_seq_midi_event snd_seq
> > > > > snd_seq_device snd_pcm_oss snd_mixer_oss fuse dm_crypt dm_mod usbhid
> > > > > snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer sr_mod cdrom
> > > > > sg snd fschmd e1000 uhci_hcd snd_page_alloc i2c_i801 [last unloaded:
> > > > > microcode]
> > > > > 
> > > > > Pid: 1156, comm: btrfs-transacti Tainted: G        W  
> > > > > 2.6.39-rc1-00262- gc53813f #20 FUJITSU SIEMENS SCENIC P / SCENICO
> > > > > P/D1561
> > > > > EIP: 0060:[<c101c838>] EFLAGS: 00010296 CPU: 1
> > > > > EIP is at kmap+0x0/0x38
> > > > > EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000010
> > > > > ESI: f5bc6400 EDI: f3c75520 EBP: f3c755f0 ESP: f58f9e10
> > > > > 
> > > > >  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> > > > > 
> > > > > Process btrfs-transacti (pid: 1156, ti=f58f8000 task=f6516f40
> > > > > task.ti=f58f8000)
> > > > > 
> > > > > Stack:
> > > > >  c1186d15 ffc22000 f58f9ec0 00000010 f3c75610 00000000 f5885780
> > > > >  f52339e8 00000009 f5bc6400 00010000 00000000 f6415800 f3c75638
> > > > >  000008bb f5bc63c0 f58857b4 f60b68a0 00000040 f52338e8 ffc22000
> > > > >  00000000 00000008 00000010
> > > > > 
> > > > > Call Trace:
> > > > >  [<c1186d15>] ? btrfs_write_out_cache+0x60c/0xa3c
> > > > >  [<c114a815>] ? btrfs_write_dirty_block_groups+0x400/0x494
> > > > >  [<c11566a7>] ? commit_cowonly_roots+0xa9/0x180
> > > > >  [<c1157799>] ? btrfs_commit_transaction+0x2ee/0x59c
> > > > >  [<c1037c85>] ? wake_up_bit+0x16/0x16
> > > > >  [<c1152a83>] ? transaction_kthread+0x149/0x1d6
> > > > >  [<c101d1b9>] ? complete+0x28/0x36
> > > > >  [<c115293a>] ? btrfs_congested_fn+0x5d/0x5d
> > > > >  [<c10379c4>] ? kthread+0x63/0x68
> > > > >  [<c1037961>] ? kthread_worker_fn+0xeb/0xeb
> > > > >  [<c13cba36>] ? kernel_thread_helper+0x6/0xd
> > > > > 
> > > > > Code: 8d 8a 00 e4 54 c1 2b 8a 8c e7 54 c1 81 f9 00 08 00 00 74 11 81
> > > > > f9 00 0c 00 00 75 0e 83 3d 10 2f 60 c1 02 75 05 e9 5e a3 04 00 c3
> > > > > <8b> 10 c1 ea 1e c1 e2 0a 8d 8a 00 e4 54 c1 2b 8a 8c e7 54 c1 81
> > > > > EIP: [<c101c838>] kmap+0x0/0x38 SS:ESP 0068:f58f9e10
> > > > > CR2: 0000000000000000
> > > > > ---[ end trace c8511126ee91dfdf ]---
> > > > > 
> > > > > This is the second Oops. On the first one I wasn't able to catch the
> > > > > backtrace, but IIRC the bug happend on kmap not kunmap the first
> > > > > time.
> > > > 
> > > > Yeah I think I know what this is but I need somebody to verify it for
> > > > me. Can you run with this patch and let me know what happens?  Thanks,
> > > > 
> > > > Josef
> > > > 
> > > > diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
> > > > index 74bc432..5e6f4b3 100644
> > > > --- a/fs/btrfs/free-space-cache.c
> > > > +++ b/fs/btrfs/free-space-cache.c
> > > > @@ -624,6 +624,7 @@ int btrfs_write_out_cache(struct btrfs_root *root,
> > > > 
> > > >  		next_page = false;
> > > > 
> > > > +		BUG_ON(index > last_index);
> > > > 
> > > >  		if (index == 0) {
> > > >  		
> > > >  			start_offset = first_page_offset;
> > > >  			offset = start_offset;
> > > > 
> > > > @@ -732,6 +733,7 @@ int btrfs_write_out_cache(struct btrfs_root *root,
> > > > 
> > > >  		struct btrfs_free_space *entry =
> > > >  		
> > > >  			list_entry(pos, struct btrfs_free_space, list);
> > > > 
> > > > +		BUG_ON(index > last_index);
> > > > 
> > > >  		page = find_get_page(inode->i_mapping, index);
> > > >  		
> > > >  		addr = kmap(page);
> > > 
> > > Hm, I tried but now I hit the
> > > BUG_ON(block_group->total_bitmaps >= max_bitmaps); in add_new_bitmap in
> > > fs/btrfs/free-space-cache.c:1255 when booting the system.
> > 
> > Can you mount -o clear_cache to make sure it's not the cache thats causing
> > that? Thanks,
> > 
> > Josef
> 
> Mounting  with clear_cache under 2.6.38 helped. I was able to boot and test 
> with your patch an hit the second BUG_ON on free-space-cache.c:738.
> 

Perfect can you try this and verify you don't panic anymore please?  Thanks,

Josef

---
 fs/btrfs/free-space-cache.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 74bc432..33287e8 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -522,6 +522,7 @@ int btrfs_write_out_cache(struct btrfs_root *root,
 	int bitmaps = 0;
 	int ret = 0;
 	bool next_page = false;
+	bool out_of_space = false;
 
 	root = root->fs_info->tree_root;
 
@@ -629,6 +630,11 @@ int btrfs_write_out_cache(struct btrfs_root *root,
 			offset = start_offset;
 		}
 
+		if (index > last_index) {
+			out_of_space = true;
+			break;
+		}
+
 		page = find_get_page(inode->i_mapping, index);
 
 		addr = kmap(page);
@@ -732,6 +738,10 @@ int btrfs_write_out_cache(struct btrfs_root *root,
 		struct btrfs_free_space *entry =
 			list_entry(pos, struct btrfs_free_space, list);
 
+		if (index > last_index) {
+			out_of_space = true;
+			break;
+		}
 		page = find_get_page(inode->i_mapping, index);
 
 		addr = kmap(page);
@@ -754,6 +764,14 @@ int btrfs_write_out_cache(struct btrfs_root *root,
 		index++;
 	}
 
+	if (out_of_space) {
+		ret = 0;
+		unlock_extent_cached(&BTRFS_I(inode)->io_tree, 0,
+				     i_size_read(inode) - 1, &cached_state,
+				     GFP_NOFS);
+		goto out_free;
+	}
+
 	/* Zero out the rest of the pages just to make sure */
 	while (index <= last_index) {
 		void *addr;
-- 
1.7.2.3


  reply	other threads:[~2011-04-05 19:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05 17:38 BUG: unable to handle kernel NULL pointer dereference at (null) Johannes Hirte
2011-04-05 17:42 ` Josef Bacik
2011-04-05 18:52   ` Johannes Hirte
2011-04-05 18:53     ` Josef Bacik
2011-04-05 19:21       ` Johannes Hirte
2011-04-05 19:31         ` Josef Bacik [this message]
     [not found]           ` <201104052308.53816.johannes.hirte@fem.tu-ilmenau.de>
2011-04-05 21:12             ` Josef Bacik
2011-04-05 22:00               ` Johannes Hirte
2011-04-05 21:57                 ` Josef Bacik
2011-04-06 11:10                   ` Johannes Hirte
2011-04-06 17:15                     ` Josef Bacik
2011-04-06 20:47                       ` Jordan Patterson
2011-04-06 23:42                         ` Johannes Hirte
2011-04-07 13:17                         ` Josef Bacik
     [not found]                           ` <BANLkTin1MN-QZWGvVE4o0T1_U9B1qtunig@mail.gmail.com>
2011-04-07 15:44                             ` Jordan Patterson
2011-04-07  8:28                       ` Johannes Hirte
2011-07-20 15:12 TB
2011-07-21  4:13 ` Randy Dunlap
2011-11-13 15:18 Andreas Hartmann
2013-08-11  5:53 [cpufreq] " Fengguang Wu
2013-08-12  4:59 ` Viresh Kumar
2014-10-23  6:58 Kevin Wilson
2014-10-23  9:05 ` Paul Bolle

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=20110405193142.GC484@dhcp231-156.rdu.redhat.com \
    --to=josef@redhat.com \
    --cc=johannes.hirte@fem.tu-ilmenau.de \
    --cc=linux-btrfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.