Thanks Martin-Éric,
checking against the code this confirms that the bug occurs in
__destroy_inode at the following position:
232 void __destroy_inode(struct inode *inode)
233 {
234 BUG_ON(inode_has_buffers(inode));
235 ima_inode_free(inode);
236 security_inode_free(inode);
237 fsnotify_inode_delete(inode);
238 #ifdef CONFIG_FS_POSIX_ACL
239 if (inode->i_acl && inode->i_acl != ACL_NOT_CACHED)
240 posix_acl_release(inode->i_acl); /* here */
241 if (inode->i_default_acl && inode->i_default_acl !=
ACL_NOT_CACHED)
242 posix_acl_release(inode->i_default_acl);
243 #endif
244 }
In EAX is the address of i_acl, so it looks like it is (repeatably) 0xffffb4ff.
In theory i_acl is either a pointer to an acl structure or 0xffffffff
(ACL_NOT_CACHED) or 0x0 (uninitialized). The address causing the bug seems a
bit high for being a valid pointer. But just to be completely sure I put a
kernel to http://people.canonical.com/~smb/bug396286/ which tries to catch a
double free case.
On the other side 0xffffb4ff might be caused by something either writing 0xb4ff
into the first word (little endian) or 0xb4 at offset 1 into the area that
holds the pointer. Before the change that added i_acl and i_default_acl, the
last field was a private pointer. Could something (this would need to be an
externally build module) still use the wrong header file?...
One thing to try next would be to check whether the other pointer is corrupted
too. I try to get something sensible up and the post here.
--
2.6.31-generic: kernel panic near the end of initramfs
https://bugs.launchpad.net/bugs/396286
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
