[PATCH] Re: Oops on 2.4.13

From: Stephen C. Tweedie (sct@redhat.com)
Date: Fri Nov 02 2001 - 13:48:43 EST


Hi,

On Thu, Nov 01, 2001 at 04:45:04PM -0500, FORT David wrote:

> >>EIP; c013c7e4 <cdput+4/40> <=====
> Trace; c0149840 <clear_inode+c0/e0>
> Trace; c0148bcc <destroy_inode+2c/40>

In your case you appear to have a bit-flip in inode->i_cdev (which
contains 0x00008000). It could be pretty much any thing causing
that... but the locking in cdput is still suspect:

        void cdput(struct char_device *cdev)
        {
                if (atomic_dec_and_test(&cdev->count)) {
                        spin_lock(&cdev_lock);

lets somebody else elevate the cdev->count before we get the lock, and
we'll proceed to destroy the cdev which is now in use again.

Al already fixed this for bdput, but it looks like we need

--- linux-2.4.14-pre6/fs/char_dev.c.~1~ Tue May 22 17:35:42 2001
+++ linux-2.4.14-pre6/fs/char_dev.c Fri Nov 2 00:49:55 2001
@@ -104,8 +104,7 @@
 
 void cdput(struct char_device *cdev)
 {
- if (atomic_dec_and_test(&cdev->count)) {
- spin_lock(&cdev_lock);
+ if (atomic_dec_and_lock(&cdev->count, &cdev_lock)) {
                 list_del(&cdev->hash);
                 spin_unlock(&cdev_lock);
                 destroy_cdev(cdev);

for cdput too (compiled but not tested). I'm not 100% convinced this
is the problem you're seeing, though.

Cheers,
 Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:19 EST