[haiku-gsoc] Re: [HCD]: Bfs bug #1

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-gsoc@xxxxxxxxxxxxx
  • Date: Thu, 19 Jun 2008 23:58:47 +0200

On 2008-06-19 at 22:50:16 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx> 
wrote:
> 
> I had a look at the page writer thread and it seems that the thread can 
> acquire
> the same reference twice and not realising it at all if the state of
> the page is not modified.
> See the code belove.
> 
> src/system/kernel/vm/vm_page.cpp
> - page writer thread -
>             if (cache->store->ops->acquire_unreferenced_ref != NULL) {
>                 // we need our own reference to the store, as it might
>                 // currently be destructed
>                 if 
>                 (cache->store->ops->acquire_unreferenced_ref(cache->store)
>                         != B_OK) {
>                     cacheLocker.Unlock();
>                     thread_yield(true);
>                     continue;
>                 }
>             }
> 
> - At this point we have a reference to the vnode -
>             InterruptsSpinLocker locker(sPageLock);
> 
>             // state might have change while we were locking the cache
>             if (page->state != PAGE_STATE_MODIFIED)
>                 continue;
> 
> continue; brings us back to the while without realising the reference and
> possibly acquiring it once again, thus the error. Unless I am missing 
> something
> of course. I'll re-run the test with a patch that releases the reference.

That looks indeed like a reference is leaked, but that has nothing to do 
with the problem at hand. A vnode is not marked busy after one has a 
reference. And apparently no one has a reference according to your 
screenshots.

> I'm taking a look at the low memory thread handler now.
> 
> Any comments?
> 
> BTW: I changed the summary of the ticket as this is not a bfs problem,
> but rather a vfs one,

I think, if at all, it's more likely a problem of the ide module or related 
modules. It normally shouldn't take more than 10 seconds to write back 
changes to a file. Well unless the file is quite big and there are a lot of 
cache changes... or the system doesn't have an I/O scheduler and starts 
thrashing the disk in low-memory situations. So maybe nothing really goes 
wrong after all; at least nothing that wouldn't be fixed by using a 
condition variable and wait indefinitely. You could try increasing the 
timeout in get_vnode() (maybe to a minute?) and see if the problem still 
occurs.

> so if mentors think I should go "back" to my HCD just let me know please.

I suppose no one will mind, if you investigate this one or two more days. 
Particularly, since you seem to be able to reproduce it that well. The only 
thing left to find out is whether this is an IDE problem (in which case I 
would recommend handing it over to Marcus) or whether things are just a bit 
too slow for the timeout we allow.

CU, Ingo

Other related posts: