> I'm currently writing a file system driver for linux, and have run into
> a strange bug which is driving me nuts. I have to allocate additional
> data for an inode using k/vmalloc, since it will no longer fit in the
> page with the inode,
Errr. "it will no longer fit in the page with the inode"? With 4k pages, you'll
get ~15 inodes per page. Anyway..
> and i store the pointer to the data in the
> inode->u.generic_ip pointer.
In 2.2.x, you can't write filesystems as standalone code (i.e. using
inode->u.generic_ip), if your filesystem allows pipes: pipe_i shares the
union with generic_ip. I don't know if this is your problem or not.
> I wrote a some memory allocation debugging
> routines that add 256 gaurd bytes to either end of the buffer allocated,
> and zeroed the entire memory space, just to make sure that i wasn't
> overruning the buffer. I then switched from using vmalloc to kmalloc.
kmalloc() has a pretty good set of debugging facilities already: have a look
at mm/slab.c.
W.r.t to your compiler: make sure if you used egcs to build the module, that
the kernel was built with it as well. The size of struct inode is different
between gcc & egcs, as spinlock_t on UP is declared differently on gcc 2.7.2
to work around a bug (I got bitten by this a few days ago).
I don't know that either of these issues would necessarily explain your
problem, though.
--
"I don't have any solution but I certainly admire the problem."
- Ashleigh Brilliant
-
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/