Bug 428896 - GFS2: warning: assertion "al->al_alloced" failed
Summary: GFS2: warning: assertion "al->al_alloced" failed
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.1
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Steve Whitehouse
QA Contact: GFS Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-15 21:57 UTC by Nate Straz
Modified: 2009-05-28 03:39 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-01-16 15:37:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Potential fix (640 bytes, patch)
2008-01-16 12:06 UTC, Steve Whitehouse
no flags Details | Diff

Description Nate Straz 2008-01-15 21:57:00 UTC
Description of problem:

While running a gfs2.ko w/ Bob's 5th performance patch for bz253990 I started
seeing the following message on the console of some nodes.

GFS2: fsid=morph-cluster:brawl0.0: warning: assertion "al->al_alloced" failed
GFS2: fsid=morph-cluster:brawl0.0:   function = alloc_page_backing, file =
/builddir/build/BUILD/gfs2-kmod-1.68/_kmod_build_PAE/ops_vm.c, line = 94
 [<f8da2bd1>] gfs2_assert_warn_i+0x7e/0x114 [gfs2]
 [<f8d9b64b>] gfs2_sharewrite_nopage+0x24b/0x299 [gfs2]
 [<f8d9b443>] gfs2_sharewrite_nopage+0x43/0x299 [gfs2]
 [<c045ef98>] __handle_mm_fault+0x1d0/0xb23
 [<c042e0dc>] lock_timer_base+0x15/0x2f
 [<c04e23c6>] prio_tree_insert+0x1b/0x1f2
 [<c04617be>] vma_link+0x9c/0xb8
 [<c0608bb6>] do_page_fault+0x2a5/0x5d3
 [<c0608911>] do_page_fault+0x0/0x5d3
 [<c0405a71>] error_code+0x39/0x40
 =======================

It appears this message started appearing on nodes after they started a test
which does mmap operations.

Version-Release number of selected component (if applicable):
kernel-2.6.18-68.el5
kmod-gfs2-1.68-1.3

How reproducible:
My guess, easily.

Comment 1 Steve Whitehouse 2008-01-16 11:15:59 UTC
This basically means that gfs2_write_alloc_required thought that we needed to
allocate some blocks for this page fault, but when we came to do the allocation,
we discovered that we didn't need to allocate any blocks. I can't see why that
should be the case at the moment.

Comment 2 Steve Whitehouse 2008-01-16 11:32:17 UTC
No, I tell a lie. I can see exactly why it fails. Bob's latest patch to
gfs2_write_alloc_required is wrong. It tests di_blocks (which is wrong because
its  the number of blocks allocated to the file, not the size of the file). It
ought to be testing (di_size + (block size) - 1) >> (block size shift). Also
di_blocks covers all the blocks added to the file and not just the data blocks,
so its wrong in the normal case too as its not providing any short cut which was
the original idea.

You can get the result that you bumped into in the case of a file with a hole in
it as then di_blocks will be much smaller than the file size.


Comment 3 Steve Whitehouse 2008-01-16 12:06:34 UTC
Created attachment 291844 [details]
Potential fix

This should fix it. Its not tested yet, but I'm doing that at the moment.

Comment 4 Robert Peterson 2008-01-16 15:37:55 UTC
This was a problem with the fifth performance patch for bug #253990.
The patch from comment #3 above has been included in the reworked patch6
for bug @253990, so I'm closing this one as NOTABUG.



Note You need to log in before you can comment on or make changes to this bug.