Bug 428896

Summary: GFS2: warning: assertion "al->al_alloced" failed
Product: Red Hat Enterprise Linux 5 Reporter: Nate Straz <nstraz>
Component: kernelAssignee: Steve Whitehouse <swhiteho>
Status: CLOSED NOTABUG QA Contact: GFS Bugs <gfs-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 5.1CC: cluster-maint, rpeterso
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-16 15:37:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Potential fix none

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.