On 1/10/23 3:18 AM, Cyrill Gorcunov wrote:
> On Tue, Dec 20, 2022 at 09:26:05PM +0500, Muhammad Usama Anjum wrote:
> ...
>>
>> +static inline int nsdr_adjust_new_first(struct vm_area_struct *new, struct vm_area_struct *vma)
>> +{
>> + struct non_sd_reg *r, *r_tmp, *reg;
>> + unsigned long mid = vma->vm_start;
>> +
>> + list_for_each_entry_safe(r, r_tmp, &vma->non_sd_reg, nsdr_head) {
>> + if (r->start < mid && r->end > mid) {
>> + reg = kmalloc(sizeof(struct non_sd_reg), GFP_KERNEL);
>> + if (!reg)
>> + return -ENOMEM;
>> + reg->start = r->start;
>> + reg->end = mid;
>> + list_add_tail(®->nsdr_head, &new->non_sd_reg);
>> +
>> + r->start = mid;
>> + } else if (r->end <= mid) {
>> + list_move_tail(&r->nsdr_head, &new->non_sd_reg);
>> + }
>> + }
>> + return 0;
>> +}
>
> Hi Muhhamad, really sorry for delay. Please enlighten me here if I get your
No problem.
> idea right -- every new VMA merge might create a new non_sd_seg entry, right?
Every new VMA only has the non_sd_reg list initialized with no entries as
the whole VMA is soft-dirty at creation time. We add entries in this list
when the soft-dirty is cleared over the entire or the part of the VMA.
Once soft_dirty has been cleared, there might be entries in the non_sd_reg
lists of both VMAs which will be maintained properly if VMAs are
split/merged or freed if removed. At this time, the soft-dirty can only be
cleared over the entire process and hence over entire VMAs. So this list
will have only one entry even if VMAs are merged until VMAs are split.
> And this operation will be applied again and again until vma get freed. IOW
> we gonna have a chain of non_sd_reg which will be hanging around until VMA
> get freed, right?
Correct.
I've posted the next version of PAGEMAP_SCAN ioctl [1] where soft-dirty
support has been replaced with UFFD WP async. If that goes in, soft-dirty
support can be left alone as people don't seem receptive of the idea that
the soft-dirty support should be corrected. UFFD WP async is better as it
is PTE based. Please review it.
[1]
https://lore.kernel.org/all/20230109064519.3555250-1-usama.anjum@xxxxxxxxxxxxx
--
BR,
Muhammad Usama Anjum
