On Thursday 26 May 2005 02:05, Hans Reiser reiser@namesys.com wrote:
Finally, are there still known situations where a corrupt ReiserFS file
They were reported years ago on the ReiserFS list. Hans didn't seem inclined to fix them as fixing such bugs incurred a performance penalty.
If that policy has changed in the ReiserFS development team then I'll write some scripts to randomly corrupt ReiserFS file systems and try to reproduce kernel bugs.
I don't know which bugs you are referring to, and I don't remember saying what you ascribe to me. Perhaps you refer to my not fscking each node after it is read into memory before it is used by the filesystem. I don't think anybody does that, not just us. Some checks are made by us, but a complete and exhaustive check is not made by anyone that I know of. We could probably write a node plugin that would crc check after the node is read from disk. That would be reasonable, and I would accept a node plugin to do that.
I don't know the exact cause of the bug in terms of which part of the code was responsible.
I reported a bug where I had a file system which if mounted would have a "find /" operation cause a kernel Oops. As far as I am aware the bug in question was never fixed.
It is my belief and the belief of many other people that a corrupted file system should not be able to corrupt kernel memory, not even if the file system is maliciously generated (think about the case of an attacker inserting a CD or USB disk). I am not aware of any other Linux file system for which a corrupted partition can cause kernel memory corruption (please inform me if you know of one).
As for the "complete and exhaustive check", maybe this is an advantage for a file system based on Inode tables as the data structures are simpler and easier to check?
On Thursday 26 May 2005 14:09, Russell Coker russell@coker.com.au wrote:
I reported a bug where I had a file system which if mounted would have a "find /" operation cause a kernel Oops. As far as I am aware the bug in question was never fixed.
My previous message didn't go to the list because the attachment was too big.
I've devised a test case that causes the ReiserFS v3 driver to access random memory and cause big problems (Oops and a clean shutdown is impossible). The test case is a file system that was freshly fsck'd so it indicates a bug in reiserfsck and the kernel code.
The file system image is on http://www.coker.com.au/bug/reiser3.bz2
On Monday 30 May 2005 07:26, Russell Coker russell@coker.com.au wrote:
On Thursday 26 May 2005 14:09, Russell Coker russell@coker.com.au wrote:
I reported a bug where I had a file system which if mounted would have a "find /" operation cause a kernel Oops. As far as I am aware the bug in question was never fixed.
My previous message didn't go to the list because the attachment was too big.
I've devised a test case that causes the ReiserFS v3 driver to access random memory and cause big problems (Oops and a clean shutdown is impossible). The test case is a file system that was freshly fsck'd so it indicates a bug in reiserfsck and the kernel code.
The file system image is on http://www.coker.com.au/bug/reiser3.bz2
Hans, there is a bug reported against Reiser3 which has been closed as WONTFIX as it's a ReiserFS kernel issue and ReiserFS is unsupported. Are you interested in fixing this?