Re: Bugfix in dquot_transfer()

From: Jan Kara (jack@suse.cz)
Date: Thu Sep 14 2000 - 08:53:30 EST


> On Mon, 4 Sep 2000, Jan Kara wrote:
>
> > Hello.
> >
> > Following patch fixes bug in dquot_transfer() - while we were sleeping
> > i_blocks might change and so number quota was miscounted. Patches are
> > against 2.2.16 and 2.4.0-test6 (but should apply well on newer versions).
>
> Umm... It still has a hole: pageout during notify_change() can
> allocate new blocks. Window is narrow, but it's there. Fsck knows what
> to do with that. Could we just keep the pointer to current quota elements
> (i.e. places where we should charge) in the inode? Then dquot_transfer()
> would transfer the charge after notify_change() and switch these pointers
> at the same time. Under BKL - nothing can block in that place. How about
> such strategy? Then DQUOT_INIT would have set these pointers, but it's not
> too horrible, IMO.
  I'm sorry I didn't replied to your mail but I had a bug in my .procmailrc
and mails got sorted to bad folders...
  Yes I agree that if notify_change() blocks we still can account imprecisely.
I think I didn't understand your proposal. The pointers to structures where
quota should be charged are already in inode. And if we count current number
of blocks after notify_change() once more all the quota will be counted
properly. The only problem is that quota can be exceeded this way. We have to check
exceeding before notify_change() because later there is no way to undo what
notify_change() did.
  Currently I'm thinking about change which would make sence to me (at least at
the first sight): notify_change() will call dquot_transfer() (currently
dquot_transfer() calls notify_change()).

                                                        Honza

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



This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:23 EST