A possible unbounded loop in moea_sync_icache: why sys/vm/mlock_test:mlock__copy_on_write_vnode fails?

[Mark Millard]

On 2020-Jan-9, at 03:12, Leandro Lupori <leandro.lupori at gmail.com> wrote:

> Interesting, this looks like the same issue that was fixed on 64-bit some time ago: https://reviews.freebsd.org/D19149.

I changed my local code to use va+1 as in that update
and can confirm that I now get:

# kyua test -k /usr/tests/Kyuafile sys/vm/mlock_test
sys/vm/mlock_test:mlock__copy_on_write_anon  ->  passed  [0.018s]
sys/vm/mlock_test:mlock__copy_on_write_vnode  ->  passed  [0.008s]
sys/vm/mlock_test:mlock__truncate_and_resize  ->  passed  [0.019s]
sys/vm/mlock_test:mlock__truncate_and_unlock  ->  passed  [0.019s]


> On Thu, Jan 9, 2020 at 3:03 AM Mark Millard via freebsd-ppc <freebsd-ppc at freebsd.org> wrote:
>> . . .
>> The code in question:
>> 
>> static void
>> moea_sync_icache(mmu_t mmu, pmap_t pm, vm_offset_t va, vm_size_t sz)
>> {       
>>         struct pvo_entry *pvo;
>>         vm_offset_t lim;
>>         vm_paddr_t pa;
>>         vm_size_t len;
>> 
>>         PMAP_LOCK(pm);
>>         while (sz > 0) {
>>                 lim = round_page(va);

The above line is where I changed the va to be
va+1 .

>>                 len = MIN(lim - va, sz);
>>                 pvo = moea_pvo_find_va(pm, va & ~ADDR_POFF, NULL);
>>                 if (pvo != NULL) {
>>                         pa = (pvo->pvo_pte.pte.pte_lo & PTE_RPGN) |
>>                             (va & ADDR_POFF);
>>                         moea_syncicache(pa, len);
>>                 }
>>                 va += len;
>>                 sz -= len;
>>         }
>>         PMAP_UNLOCK(pm);
>> }
> 


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)