Bug 428896 - GFS2: warning: assertion "al->al_alloced" failed
GFS2: warning: assertion "al->al_alloced" failed
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Steve Whitehouse
GFS Bugs
Depends On:
  Show dependency treegraph
Reported: 2008-01-15 16:57 EST by Nate Straz
Modified: 2009-05-27 23:39 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-16 10:37:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Nate Straz 2008-01-15 16:57:00 EST
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):

How reproducible:
My guess, easily.
Comment 1 Steve Whitehouse 2008-01-16 06:15:59 EST
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 06:32:17 EST
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 07:06:34 EST
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 10:37:55 EST
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.