Messages in this thread Patch in this message |  | | Date | Fri, 2 Nov 2001 18:48:43 +0000 | From | "Stephen C. Tweedie" <> | Subject | [PATCH] Re: Oops on 2.4.13 |
| |
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/
|  |