As proposed in my last mail, here comes another problem with ramfs:
Randomly the BUG() statement of page_address in ramfs/inode.c:68 is hit by
using a HIGHMEM enabled kernel, with NO_HIGHMEM alls fine.
Here I would assume, there is no reason to restict the used memory to
low mem. So this time the kmap patch? (I'm not sure but in this
non-RT linux a user space program does not get a irq context, so kmap's
beeing not irq-save couldn't make problems?)
At least i was able to compile a kernel on the ramfs after applying the
patch :)
Kernel version was 2.4.0test1.
The patch is against 2.4.0test-ac18 anyway.
--- inode.c.ac18 Tue Jun 13 22:31:21 2000
+++ inode.c Wed Jun 14 22:21:24 2000
@@ -22,13 +22,18 @@
* caches is sufficient.
*/
+/*
+ * kmap instead of page_address fix proposed
+ * Gert Wollny <wollny@cns.mpg.de>
+ */
+
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/pagemap.h>
#include <linux/init.h>
#include <linux/string.h>
#include <linux/locks.h>
-
+#include <linux/highmem.h>
#include <asm/uaccess.h>
/* some random number */
@@ -65,7 +70,7 @@
static int ramfs_readpage(struct file *file, struct page * page)
{
if (!Page_Uptodate(page)) {
- memset((void *) page_address(page), 0, PAGE_CACHE_SIZE);
+ memset((void *) kmap(page), 0, PAGE_CACHE_SIZE);
SetPageUptodate(page);
}
UnlockPage(page);
Best wishes
Gert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:33 EST