[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Bugfix in dquot_transfer()
> > 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
> Nope. You've just shifted the race window (and inverted the
> effect) - think what happens if you've got new allocations after the UID
> change but before the return from notify_change().
Quota will be still acounted to old user - it's independent of i_uid contents -
so when we switch pointers to dquot structures and move allocated space without
blocking there shouldn't be problem...

> > 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()).
> Umm... I don't think that it will help anything.
> How about the following:
> * dquot_{alloc,free}_block() _never_ blocks.
> * we have 3 inlined helper functions - alloc_block(), free_block() and
> change_xid(). They get exclusion (BKL, spinlock, whatever) and update both
> quota and i_blocks.
> Consequences:
> * quota for filesystems without ->i_blocks is history. It doesn't
> work anyway - quota for minixfs is so easy to screw that it's not even
> funny.
> * we can't print any messages from the dquot_{alloc,free}_block().
> Let the helper thread do it - we would just add a request to queue and let
> it pick the thing. BTW, use of global buffer for creating the messages is
> extremely bad idea - TTY output can block and you've got no protection
> around print_warning().
> * we have to be careful in {read,write}_dquot(). Frankly, I would
> prefer to use the pagecache for quota file rather than messing with
> ->read() and ->write(). Then we can get an exclusion between updating
> dquot and copying it to/from page without blocking. Incidentially, we kill
> the set_fs() crap that way.
> BTW, changing ->dq_op looks nasty - AFAICS you can easily oops on
> access to the methods, since the thing may become NULL between the check
> and dereferencing.
> Comments?
I'll think about it... Now I have to go...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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