linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Muhammad Usama Anjum <usama.anjum@collabora.com>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Eric Biederman <ebiederm@xmission.com>,
	Kees Cook <keescook@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	kernel@collabora.com, peterx@redhat.com, david@redhat.com,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] mm: implement granular soft-dirty vma support
Date: Tue, 10 Jan 2023 10:49:20 +0500	[thread overview]
Message-ID: <8a0ebe48-c9fd-b030-71bd-4a806c6d5f29@collabora.com> (raw)
In-Reply-To: <Y7ySt0XGnbzTyY6T@grain>

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(&reg->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@collabora.com

-- 
BR,
Muhammad Usama Anjum


      reply	other threads:[~2023-01-10  5:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-20 16:26 Muhammad Usama Anjum
2022-12-21  9:01 ` David Hildenbrand
2023-01-09 22:18 ` Cyrill Gorcunov
2023-01-10  5:49   ` Muhammad Usama Anjum [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8a0ebe48-c9fd-b030-71bd-4a806c6d5f29@collabora.com \
    --to=usama.anjum@collabora.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=gorcunov@gmail.com \
    --cc=keescook@chromium.org \
    --cc=kernel@collabora.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhiramat@kernel.org \
    --cc=peterx@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox