[bug] set_pgdir can skip mm's

2000-11-24 Thread V Ganesh
set_pgdir() needs to modify all active mm's to include the new entry. what it really does is for_each_task(p) { if (!p->mm) continue; *pgd_offset(p->mm,address) = entry; } however, there could be a lazy-tlb thread on another

Re: [bug] set_pgdir can skip mm's

2000-11-24 Thread V Ganesh
> From ganesh Fri Nov 24 18:08:15 2000 [ set_pgdir() blah blah blah ] damn. I was looking at test9 and as usual after shooting my mouth off on l-k I go look at test11 and find it's fixed there, at least in i386, thanks to the vmalloc_fault: stuff in do_page_fault. but a lot of other architecture

[bug] infinite loop in generic_make_request()

2000-11-29 Thread V Ganesh
[cc'ed to maintainers of md and lvm] hi, in generic_make_request(), the following code handles stacking: do { q = blk_get_queue(bh->b_rdev); if (!q) { printk(...) buffer_IO_error(bh); break; } } while (q

beware of add_waitqueue/waitqueue_active

2000-11-30 Thread V Ganesh
there's a very subtle race with using add_waitqueue() as a barrier, in the __find_lock_page() which used to exist in test9. it seems to be fixed in test11, but I thought I should mention this just in case it's ever used in a similar manner elsewhere. the race manifests itself as a lost wakeup. th

inode->i_dirty_buffers redundant ?

2001-01-24 Thread V Ganesh
now that we have inode->i_mapping->dirty_pages, what do we need inode->i_dirty_buffers for ? I understand the latter was added for the O_SYNC changes before dirty_pages came into the picture. but now both seem to be doing more or less the same thing. ganesh - To unsubscribe from this list: send t

Re: inode->i_dirty_buffers redundant ?

2001-01-25 Thread V Ganesh
Stephen C. Tweedie <[EMAIL PROTECTED]> wrote: : Hi, : On Wed, Jan 24, 2001 at 03:25:16PM +0530, V Ganesh wrote: :> now that we have inode->i_mapping->dirty_pages, what do we need :> inode->i_dirty_buffers for ? : Metadata. Specifically, directory contents and indirection

Re: inode->i_dirty_buffers redundant ?

2001-01-26 Thread V Ganesh
Stephen C. Tweedie <[EMAIL PROTECTED]> wrote: : That would only complicate things: it would mean we'd have to scan : both lists on fsync instead of just the one, for example. There are a we already do; filemap_fdatasync() is called first in sys_fsync(), though it usually doesn't have much work