Messages in this thread |  | | Date | Sun, 17 Sep 2000 19:40:04 +0200 | From | Jan Kara <> | Subject | Re: Bugfix in dquot_transfer() |
| |
> 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(). Seems I'll have to read that part of kernel... I didn't expect writing to console can block (especially as this code was there for ages).
> * 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. I think it's reasonable (I wanted to move quota to pagecache anyway...).
> 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. True.. I'll think off how to fix it.
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/
|  |