lkml.org 
[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Bugfix in dquot_transfer()
> 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/

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