JFFS2/xattr problems.

[KaiGai Kohei]

> But I noticed this patch has another problem last night.
> In delete_xattr_ref(), we don't hold c->erase_completion_lock before
> atomic_dec_and_test(), so there is a possibility to release
> a xattr_datum twice.
> I think atomic_dec_and_lock() should be used in delete_xattr_datum().
> If so, we can release it safely with minimum locking pain.
> This behavior may be correct. Please wait a fix.

* jffs2-xattr-v6.2-01-fix-xd_refcnt-race-condition.patch

   Signed-off-by: KaiGai Kohei <kaigai at ak.jp.nec.com>

The attached patch resolves this problem.
When xd->refcnt is checked whether this xdatum should be released
or not, atomic_dec_and_lock() is used to ensure holding the
c->erase_completion_lock.

This fix change a specification of delete_xattr_datum().
Previously, it's only called when xd->refcnt equals zero.
(calling it with positive xd->refcnt cause a BUG())
If you applied this patch, the function checks whether
xd->refcnt is zero or not under the spinlock if necessary.
Then, it marks xd DEAD flahs and links with xattr_dead_list
or releases it immediately when xd->refcnt become zero.

I think it's not appropriate to call this behavior 'delete'.
Thus, I changed the function name 'unrefer_xattr_datum'.
Isn't it superfluous modify?

Thanks,
-- 
Open Source Software Promotion Center, NEC
KaiGai Kohei <kaigai at ak.jp.nec.com>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jffs2-xattr-v6.2-01-fix-xd_refcnt-race-condition.patch
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20060629/508282de/attachment.pl