Re: Kernel bug: Bad page state: related to generic symlink code andmmap

From: Linus Torvalds
Date: Fri Aug 19 2005 - 11:08:20 EST




On Fri, 19 Aug 2005, Anton Altaparmakov wrote:
>
> struct page *page;
> page = find_get_page(dentry->d_inode->i_mapping, 0);
> if (!page)
> ----> BUG();

Something has truncated the mapping.

My guess is that you had a cache invalidate event that removed the page
from the mapping while it was being used. That might also explain why this
only happens for ncpfs. I bet that in the other cases, the mapping was
also invalidated, but re-filled immediately, and your strace slowed the
other process down enough that it didn't get to re-fill the cache it
invalidated or something like that.

The fact that it happens only for cross-volume things might also be
explained that way - is there something ncpfs does when switching volumes
that might trigger a cache invalidate for another volume (either on the
client side or the server side - maybe the server tends to try to break
the connection for the old volume when you start traversing a new one?)

The generic "page cache for symlinks" code does _not_ support invalidating
the cache while it's being used. A local filesystem will obviously never
invalidate the cache at all.

Hmm.. NFS _does_ use the page cache for symlinks, but uses it slightly
differently: instead of relying on the page cache entry being the same
when freeing the page, it just caches the page it looked up in the page
cache (ie "nfs_follow_link()" does look up the page cache, but then hides
the page pointer inside the page data itself (uglee), and thus does not
depend on the mapping staying the same (nfs_put_link() just takes the page
from the symlink data).

Linus
-
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/