> From a quick look at the dquot.c code, there appear to be some problems
> with dquot_sync, and possibly other operations. The dquot_sync code does
> two potentially blocking operations, a wait_on_quota and the
> write_quota, but it doesn't hold a use count on the list node, and
> assumes that the list successor will be the same after the operation.
Now you put the finger on that code... mmm, I really dislike that.
> Also, clear_dquot appears to assume that a use count > 1 means that the
> item is on the inuse list, so just protecting the above operations by
> bumping the use count may have side effects ...
What would be the consequence of putting a big spinlock around the whole
sync_dquots routine ? We would be unable to sync() the quota on two
partitions simultaneously, but we would then be the only agent performing
actions on the dquot list. Perhaps too coarse ; we already have
dquot->dq_mnt->mnt_dquot.semaphore for each quota entry. The assumption
in clear_dquot really scares me ; what would it cost to add a flag
"inuse/free" in dquot->dq_flags ?
> I'm not sure who looks after dquota these days, but if nobody comes
> forward to work on it, I'll take a try at fixing it. (But others will
> have to test, as I'm not using quota ...)
You can count on my machine for that : it's a router but for a students'
network we're in the process to connect to the 'net, and no one would dare
to complain too loud if I bring it down a hour or two <big evil grin />.
(If we get the connection next week, as hoped, and if the problem is still
here, I may give you telnet access, if you need it. Unfortunately, I
couldn't reproduce the problem on a currently connected machine).
TIA
-- Cyrille
------------------------------
Zog Zog
-
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/