lkml.org 
[lkml]   [2001]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:12    [W:0.093 / U:27.988 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site