Bug 8276
| Summary: | ufs (ufstype=ufs2) oops on unmount | ||
|---|---|---|---|
| Product: | File System | Reporter: | Jim Paris (jim) |
| Component: | Other | Assignee: | Evgeniy A. Dushistov (dushistov) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | dushistov, protasnb |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.20.1 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
objdump -S ufs.ko
objdump -S ufs.ko ufs_unmount_zero_link fix |
||
|
Description
Jim Paris
2007-03-28 10:13:15 UTC
>$ file fs.img
Thanks for reporting this.
May be I'm missing something,
is it possible to get this image somewhere?
Unfortunately I can't share it, and I haven't reproduced it with other images. I can probably pull out pieces if there is some particular table or entry you'd like to see, or if you'd like any extra debugging added to ufs I can do that too. >Unfortunately I can't share it, and I haven't reproduced it with other images. >I can probably pull out pieces if there is some particular table or entry you'd >like to see, or if you'd like any extra debugging added to ufs I can do that >too. There is UFS's option avaible on kernel build stage: >UFS debugging (UFS_DEBUG) > >If you are experiencing any problems with the UFS filesystem, say >Y here. This will result in _many_ additional debugging messages to be >written to the system log. can you turn on it and post result here, messages should appear somewhere like /var/log/messages. And before any rebuild of kernel can you post here result of "objdump -S path/to/ufs/module"? This should help "parse" oops message. Created attachment 10984 [details]
objdump -S ufs.ko
Created attachment 10985 [details]
objdump -S ufs.ko
Disassembly added. I'll want to move to a different machine before I start triggering the oops on purpose, so it might take me a few days to get the debugging output. >Disassembly added.
Thanks.
After looking on trace:
827297.980942] [<ffffffff88395e7b>] :ufs:ufs_delete_inode+0x8d/0x93
[827297.980974] [<ffffffff8022c05e>] generic_delete_inode+0xc0/0x136
the problem happened, because of
a)filesystem mounted read-only
b)filesystem was damaged, and inode has zero link count
c)ufs_delete_inode was called
Can you try this patch?
Created attachment 11104 [details]
ufs_unmount_zero_link fix
This patch should fix oops on unmount, if cache contains inode with zero links,
and filesystem mounted readonly.
I tested it: ufs-proper-handling-of-zero-link-case.patch fixes the oops on unmount. Thank you! It looks like the patch is in the tree, the problem can be closed. Thanks. |