On Fri, May 19 2023 at 19:49, Baoquan He wrote:
> On 05/19/23 at 01:22pm, Thomas Gleixner wrote:
>> >
>> > When vb_free() is invoked, it could cause three kinds of vmap_block as
>> > below. Your code works well for the 2nd case, for the 1st one, it may be
>> > not. And the 2nd one is the stuff that we reclaim and put into purge
>> > list in purge_fragmented_blocks_allcpus().
>> >
>> > 1)
>> > |-----|------------|-----------|-------|
>> > |dirty|still mapped| dirty | free |
>> >
>> > 2)
>> > |------------------------------|-------|
>> > | dirty | free |
>>
>>
>> You sure? The first one is put into the purge list too.
>
> No way. You don't copy the essential code here. The key line is
> calculation of vb->dirty. ->dirty_min and ->dirty_max only provides a
> loose vlaue for calculating the flush range. Counting more or less page
> of ->dirty_min or ->dirty_max won't impact much, just make flush do
> some menningless operation. While counting ->dirty wrong will cause
> serious problem. If you put case 1 into purge list, freeing it later
> will fail because you can't find it in vmap_area_root tree. Please check
> vfree() and remove_vm_area().
I misread your mail. My point was soleley about the ranges which get
flushed via unmap_aliases() before the block is completely freed,
i.e. ->free = 0 and ->dirty = VMAP_BBMAP_BITS.
Thanks,
tglx
