From: Nadav Har'El <[email protected]>
Date: Tuesday, January 16, 2018 at 4:49 AM
To: Timmons Player <[email protected]>
Cc: Waldek Kozaczuk <[email protected]>, OSv Gopher 
<[email protected]>
Subject: Re: [PATCH] memory: respect _bitset length bounds in 
page_range_allocator


On Tue, Jan 16, 2018 at 12:31 AM, Player, Timmons 
<[email protected]<mailto:[email protected]>> wrote:
So, it is possible to reproduce the issue with a unit test, however it requires 
specifying an explicit memory size to the run script.

The issue only occurs when the bitset size is an exact multiple of 
mmu::huge_page_size.  In that case, the first mmap that is greater than or 
equal to mmu::huge_page_size will be allocated from the top most range.
When that allocation is munmapped, the system will hang.

Please see the patch below which adds a tst-page-range-allocator.cc unit test.

After applying and rebuilding the test image you should be able to trigger the 
hang by calling:

timmons@rtp-skink osv[0]> scripts/run.py -m512.15M -c2 -e 
tests/tst-page-range-allocator.so
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
OSv v0.24-474-g9cceaca
eth0: 192.168.122.15
_bitmap.size() = 131072, end = 131072
[ hangs here… ]

P.S.  Since the unit test requires an explicit configuration, I’m not sure if 
it’s useful to add it to the patch… Let me know if you think otherwise.

Thanks.
I think it's useful, but the unit test's source code should explain how it 
should be used.

But I wonder how stable this "512.15M" number is... Could we find a way for the 
test to check if the bitmap size is the problematic one, somehow?

I think the only way to get the bitset size is to add some code to explicitly 
retrieve the value.  The bitset size doesn’t correspond to the memory size 
reported by memory::stats::total() and the page_range_allocator object is only 
defined in mempool.cc (and _bitset is private).

Another problem from the test perspective is how to know for sure that you’ve 
actually allocated the highest range of memory you can from the system or not.  
The mmu::virt_to_phys doesn’t handle mapped memory and I could only ever 
generate this problem with mmap.

And yeah, I doubt the memory number is stable.  It certainly depends on your 
hypervisor.


diff --git a/core/mempool.cc b/core/mempool.cc
index 569a0ac..437b54c 100644
--- a/core/mempool.cc
+++ b/core/mempool.cc
@@ -767,6 +767,10 @@ void page_range_allocator::free(page_range* pr)
         pr2->size += pr->size;
         pr = pr2;
     }
+    auto end = get_bitmap_idx(*pr) + pr->size / page_size;
+    if (end >= _bitmap.size()) {
+        printf("_bitmap.size() = %zu, end = %zu\n", _bitmap.size(), end);

Is this case an indication of an error? If so, should we abort() here? Or is 
this an ok case - in which case it's probably not ok to print a message every 
ime it happens... (since you added this printout to the free() code, not to the 
test...).

Yeah, that could have been an abort…  That was just to show the issue 
explicitly when triggered by the test.  With the “memory: respect _bitset 
length bounds in page_range_allocator” patch applied you can’t exceed the array 
bounds so it’s a non-issue.

I’ll generate a better patch and we can then decide what to do with it…

Timmons




Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to 
Spirent Communications plc, its affiliates and / or subsidiaries. If you are 
not the intended recipient, you are hereby notified that any disclosure, 
copying, distribution and / or the taking of any action based upon reliance on 
the contents of this transmission is strictly forbidden. If you have received 
this message in error please notify the sender by return e-mail and delete it 
from your system.

Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, 
United Kingdom.

Or if within the US,

Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to