Date: Thu, 14 Feb 2019 17:21:09 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 235747] vmem_bt_alloc() may leak reserved boundary tags Message-ID: <bug-235747-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235747 Bug ID: 235747 Summary: vmem_bt_alloc() may leak reserved boundary tags Product: Base System Version: CURRENT Hardware: powerpc OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: markj@FreeBSD.org vmem_bt_alloc() is somewhat magical in that it must use the vmem allocator = to allocate boundary tags for the vmem allocator. It uses a reserve of bounda= ry tags and a global mutex to avoid infinite recursion. If the reserve somehow gets depleted, vmem_bt_alloc() effectively gets stuck and the system will g= rind to a halt; jhibbits has observed this happening on a powerpc64 platform. I think this can happen in the following scenario: vmem_bt_alloc() calls vmem_xalloc() on the per-domain kernel arena and puts some reserved boundary tags into the arena's pool. The attempt to allocate a KVA range subsequent= ly fails because the per-domain arena has no free ranges and we cannot import = from kernel_arena because it is too fragmented to satisfy a KVA_QUANTUM-sized allocation. So, vmem_xalloc() fails, leaving the reserved boundary tags up= for grabs. Later, even if the per-domain kernel arena can satisfy an allocation for vmem_bt_alloc(), we may not have any boundary tags left to actually per= form the allocation, and we're stuck. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235747-227>