kernel: cutting mapped file area cause zeroing of second part

[X512]

This is hrev55664.

Steps to reproduce:

1. Map file to team address space with mmap.
2. Allocate anonymous virtual memory at middle of mapped file memory from (1).
3. Second mapped file part after the end of anonymous memory will be zeroed.

This problem cause Wine to not work properly.

[X512]

0058:err:virtual:anon_mmap_fixed anon_mmap_fixed(0x14a0000, 0x100000)
0058:err:virtual:anon_mmap_fixed old area 181145(ntdll.so mmap area): 0x14a0000, 0x120000
0058:err:virtual:anon_mmap_fixed [!!!] newEndAdr < oldEndAdr: Haiku bug #17556 triggered
00b4:err:virtual:anon_mmap_fixed anon_mmap_fixed(0x1260000, 0x100000)
00b4:err:virtual:anon_mmap_fixed old area 179307(ntdll.so mmap area): 0x1260000, 0x120000
00b4:err:virtual:anon_mmap_fixed [!!!] newEndAdr < oldEndAdr: Haiku bug #17556 triggered

[waddlesplash]

<waddlesplash> did you see https://dev.haiku-os.org/ticket/17556 ? any chance you might be able to point me in the right direction for investigating it?
<waddlesplash> I already eliminated the pages being cleared as a possibility (or at least it isn't done via vm_memset_physical, which is the usual method for that)
<mmlr> I've seen it but I don't really have an idea
<mmlr> since it involves actual files it didn't come up in my prior area cutting work
<mmlr> I guess I should figure out if the pages are "lost" or cleared? possibly via adding more traces to map_file/cut_area?
<mmlr> there might be assumptions, i.e. that cutting is never backed by a file and therefore some wrong cache type is used for the new area
<mmlr> in the end, cutting means making a new area that should be the same as the earlier part and then resizing
<mmlr> if the new area doesn't propery reflect the type of the original area it'll go wrong
<mmlr> or at least that's what I remember from it
<waddlesplash> thnx, that's helpful
<mmlr> I would expect the pages being lost rather than explicitly being zeroed
<waddlesplash> yes, that seems most probable, as it'd have to be zeroed some other way than vm_memset_physical/clear_page which I already traced
<mmlr> definitely look at cut_area, that should be where the area creation should happen. maybe also just take a look at the cache tree of the two areas and see if they are set up differently.

[waddlesplash]

kdebug> area 0x2220
AREA: 0xffffffff86abe6c0
name:           '_APP_ mmap area'
owner:          0x1bf
id:             0x2220
base:           0xf12a356000
size:           0x1000
protection:     0x11
page_protection:0x0000000000000000
wiring:         0x0
memory_type:    0x0
cache:          0xffffffff869197e0
cache_type:     vnode
cache_offset:   0x0
cache_next:     0x0000000000000000
cache_prev:     0x0000000000000000
page mappings:  1
kdebug> area 0x2221
AREA: 0xffffffff86abe780
name:           '_APP_ mmap area'
owner:          0x1bf
id:             0x2221
base:           0xf12a357000
size:           0x1000
protection:     0x33
page_protection:0x0000000000000000
wiring:         0x0
memory_type:    0x0
cache:          0xffffffff86919990
cache_type:     RAM
cache_offset:   0x0
cache_next:     0x0000000000000000
cache_prev:     0x0000000000000000
page mappings:  0
kdebug> area 0x2222
AREA: 0xffffffff86abe9c0
name:           '_APP_ mmap area'
owner:          0x1bf
id:             0x2222
base:           0xf12a358000
size:           0xe000
protection:     0x11
page_protection:0x0000000000000000
wiring:         0x0
memory_type:    0x0
cache:          0xffffffff86671638
cache_type:     RAM
cache_offset:   0x0
cache_next:     0x0000000000000000
cache_prev:     0x0000000000000000
page mappings:  1

The area after the cut has the wrong cache_type and source cache.

[waddlesplash]

kdebug> cache 0xffffffff869197e0
CACHE 0xffffffff869197e0:
  ref_count:    1
  source:       0xffffffff8214a700
  type:         RAM
  virtual_base: 0x0
  virtual_end:  0x1000
  temporary:    1
  lock:         0xffffffff86919860
  lock.holder:  -1
  areas:
    area 0x2220, _APP_ mmap area
        base_addr:  0xf12a356000, size: 0x1000
        protection: 0x11
        owner:      0x1bf
  consumers:
  pages:
        0 in cache

So! The cache of the area has the wrong type! How did that happen?

[waddlesplash]

Ah, because its own source cache has the correct type. So then the question is, how should this case get handled?

[waddlesplash]

Fixed in hrev55942.

[waddlesplash]

Wound up redoing the fix in hrev58425.