> On 12 Mar 1999 11:08:10 +0100, Jes Sorensen <Jes.Sorensen@cern.ch>
> said:
>
> > Andrea, if you got your head down in the dquota code (and have an idea
> > about what is going on there) you might want to look at the fact that
> > it is not SMP safe. I have a report from a guy who had it blow up on
> > him like 1-2 times/day when running on SMP, whereas it seems to be
> > fine on UP.
>
> Umm, "blow up" is a bit of a vague term... :)
>
> Any oopsen for us to look at?
I believe Alan (?) tweaked it between 2.2.2ac7->2.2.3 with the following
patch, which went into 2.2.3:
--- v2.2.2/linux/fs/dquot.c Mon Sep 28 10:51:34 1998
+++ linux/fs/dquot.c Sun Mar 7 15:25:23 1999
@@ -483,7 +483,10 @@
if (dquot->dq_flags & (DQ_LOCKED | DQ_MOD)) {
wait_on_dquot(dquot);
if (dquot->dq_flags & DQ_MOD)
- write_dquot(dquot);
+ {
+ if(dquot->dq_mnt != (struct vfsmount *)NULL)
+ write_dquot(dquot);
+ }
/*
* The dquot may be back in use now, so we
* must recheck the free list.
This seems to have completely fixed it on the two SMP machines using quota
that we just got in when 2.2.2ac7 was out, which one previously oopsed on.
The oops was in write_dquot(), and it happened every time when I ran
"sync" (sync segfaulted). I was able to "quotaoff -a", and "sync" then
worked normally again and everything appeared completely stable. The
machine was almost completely unloaded when this happened, so it shouldn't
be hard to reproduce if the above patch isn't the correct fix.
Unfortunately, I don't have the oops anymore because syslog's symbol file
wasn't right and so syslog just swallowed the oops. I believe it was just
that dquot->dq_mnt was null, though.
Simon-
| Simon Kirby | Systems Administration |
| mailto:sim@netnation.com | NetNation Communications |
| http://www.netnation.com/ | Tech: (604) 684-6892 |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/