Klaus Knopper:
> I can't believe this. I have been reading that special part of inode.c
> several times during my 3 week debugging session, and did not notice the

I didn't believe that either. :-)


> "off by one", maybe because the last byte of "name" is overwritten with
> a zero later. Also, I was searching more for uninitialized pointers or
> race conditions.

Actually, in my case, only one byte was overwritten. that was zero as a
terminator. The address was used a part of hidden dentry pointer in
unionfs dentry. When the real pointer was 0xabcdabcd, it was overwritten
as 0xabcdab00. And later atomic_read(&dentry->d_count) or something
crashed.

The string constant ".wh." should be a macro, and probably
allocating/generating whiteout path is better to be an inline function.


> Some bugs are still pending, but at least now it looks like I can make a
> new release this week.

If you show me the bug list, I'd like to try addressing them. Especially
the bug is common to my nfs case.


> Can I send you something for showing my appreciation of your quick bugfix?

Surprise!!
My pleasure!!
I will receive it. Thanx in advance.


Junjiro Okajima
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs

Reply via email to