Problem with recent changes to fs/dcache.c

[Art Haas]

Hi.

I run linux on a SparcStation SS20 in addition to a PC, and found that
none of the 2.6.6-rc kernels would boot. After trying the latest -rc3
kernel and seeing it fail also, my debugging quest began. Adding a few
printk() statements pointed the problem to be in fs/dcache.c in the
vfs_caches_init() function. The 1.69->1.70 changes to this file added in
a call to nr_free_pages() and used that result to adjust the global
mempages variable. This change caused the boot failures.

The printk() statements I'd added showed that vfs_caches_init() was
being called with 'mempages' set to 46073. The nr_free_pages() call
returned 127661, and this value being subtracted from mempages went
negative, but the value is unsigned, so mempages became enormous. Things
ended up getting stuck in the inode_init() call down a bit, having
seeming survived the dcache_init() call only because of values
wrapping around.

I commented out the 'mempages -= reserve;' line in the file, and the
boot continued along. Unfortunately I encounter a kernel trap when
mounting the hard drives, so there are other problems still needing to
be looked at.

The possiblity of nr_free_pages() being larger than mempages looks like
a silent bug that was tripped. If not, then another bug in the Sparc
port may be responsible for values being used in these functions. The
memory-management gurus can take a peek and see what they find.

Art Haas
-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/