#5328: Had reserved page but threre is none after latest slab/vm changes ---------------------------+------------------------------------------------ Reporter: mmlr | Owner: bonefish Type: bug | Status: new Priority: normal | Milestone: R1 Component: System/Kernel | Version: R1/Development Keywords: | Blockedby: Platform: All | Blocking: ---------------------------+------------------------------------------------ Comment(by bonefish): Replying to [comment:2 mmlr]: > Replying to [comment:1 bonefish]: > > free count + clear count >= unreserved free pages + system reserved pages > > As far as I've seen we only panic in case we actually failed to allocate a page, hiding cases where there is a violation of the rules but we just don't happen to be as short on pages. Couldn't we introduce a paranoid checking of the reserve on each allocation and then panic in case of violation? If you mean checking the invariant, then this is not really possible. The variables on the right hand side are accessed atomically without holding any lock. The queue counts are protected by a R/W lock + spinlock combo -- unless one holds the write lock, they can change individually. There's no way one can get a snapshot of all four variables at the same time. Introducing a mutex to make that possible would kill all concurrency and thus probably make the bug disappear, if it is some kind of race condition in vm_page.cpp. If r35295 introduced the bug, I don't think a problem outside of vm_page.cpp is likely. I just read through the patch again and it really doesn't change anything related other than adding passing of the priority argument in various functions and methods. No accidental replacement of vm_page_reserve_pages() by vm_page_unreserve_pages() or changing of the numbers passed to them. -- Ticket URL: <http://dev.haiku-os.org/ticket/5328#comment:4> Haiku <http://dev.haiku-os.org> Haiku - the operating system.