From: Jan Kara <jack@suse.cz>
To: John Stultz <john.stultz@linaro.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Android Kernel Team <kernel-team@android.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Robert Love <rlove@google.com>, Mel Gorman <mel@csn.ul.ie>,
Hugh Dickins <hughd@google.com>, Dave Hansen <dave@sr71.net>,
Rik van Riel <riel@redhat.com>,
Dmitry Adamushko <dmitry.adamushko@gmail.com>,
Neil Brown <neilb@suse.de>,
Andrea Arcangeli <aarcange@redhat.com>,
Mike Hommey <mh@glandium.org>, Taras Glek <tglek@mozilla.com>,
Dhaval Giani <dgiani@mozilla.com>, Jan Kara <jack@suse.cz>,
KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
Michel Lespinasse <walken@google.com>,
Minchan Kim <minchan@kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH 1/3] vrange: Add vrange syscall and handle splitting/merging and marking vmas
Date: Mon, 17 Mar 2014 10:43:39 +0100 [thread overview]
Message-ID: <20140317094339.GC2210@quack.suse.cz> (raw)
In-Reply-To: <20140317092118.GA2210@quack.suse.cz>
On Mon 17-03-14 10:21:18, Jan Kara wrote:
> On Fri 14-03-14 11:33:31, John Stultz wrote:
> > + for (;;) {
> > + unsigned long new_flags;
> > + pgoff_t pgoff;
> > + unsigned long tmp;
> > +
> > + if (!vma)
> > + goto out;
> > +
> > + if (vma->vm_flags & (VM_SPECIAL|VM_LOCKED|VM_MIXEDMAP|
> > + VM_HUGETLB))
> > + goto out;
> > +
> > + /* We don't support volatility on files for now */
> > + if (vma->vm_file) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> > +
> > + new_flags = vma->vm_flags;
> > +
> > + if (start < vma->vm_start) {
> > + start = vma->vm_start;
> > + if (start >= end)
> > + goto out;
> > + }
One more question: This seems to silently skip any holes between VMAs. Is
that really intended? I'd expect that marking unmapped range as volatile /
non-volatile should return error... In any case what happens should be
defined in the description.
Honza
> > + tmp = vma->vm_end;
> > + if (end < tmp)
> > + tmp = end;
> > +
> > + switch (mode) {
> > + case VRANGE_VOLATILE:
> > + new_flags |= VM_VOLATILE;
> > + break;
> > + case VRANGE_NONVOLATILE:
> > + new_flags &= ~VM_VOLATILE;
> > + }
> > +
> > + pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT);
> > + prev = vma_merge(mm, prev, start, tmp, new_flags,
> > + vma->anon_vma, vma->vm_file, pgoff,
> > + vma_policy(vma));
> > + if (prev)
> > + goto success;
> > +
> > + if (start != vma->vm_start) {
> > + ret = split_vma(mm, vma, start, 1);
> > + if (ret)
> > + goto out;
> > + }
> > +
> > + if (tmp != vma->vm_end) {
> > + ret = split_vma(mm, vma, tmp, 0);
> > + if (ret)
> > + goto out;
> > + }
> > +
> > + prev = vma;
> > +success:
> > + vma->vm_flags = new_flags;
> > + *purged = lpurged;
> > +
> > + /* update count to distance covered so far*/
> > + count = tmp - orig_start;
> > +
> > + if (prev && start < prev->vm_end)
> In which case 'prev' can be NULL? And when start >= prev->vm_end? In all
> the cases I can come up with this condition seems to be true...
>
> > + start = prev->vm_end;
> > + if (start >= end)
> > + goto out;
> > + if (prev)
> Ditto regarding 'prev'...
>
> > + vma = prev->vm_next;
> > + else /* madvise_remove dropped mmap_sem */
> > + vma = find_vma(mm, start);
> The comment regarding madvise_remove() looks bogus...
>
> > + }
> > +out:
> > + up_read(&mm->mmap_sem);
> > +
> > + /* report bytes successfully marked, even if we're exiting on error */
> > + if (count)
> > + return count;
> > +
> > + return ret;
> > +}
> > +
> > +SYSCALL_DEFINE4(vrange, unsigned long, start,
> > + size_t, len, int, mode, int __user *, purged)
> > +{
> > + unsigned long end;
> > + struct mm_struct *mm = current->mm;
> > + ssize_t ret = -EINVAL;
> > + int p = 0;
> > +
> > + if (start & ~PAGE_MASK)
> > + goto out;
> > +
> > + len &= PAGE_MASK;
> > + if (!len)
> > + goto out;
> > +
> > + end = start + len;
> > + if (end < start)
> > + goto out;
> > +
> > + if (start >= TASK_SIZE)
> > + goto out;
> > +
> > + if (purged) {
> > + /* Test pointer is valid before making any changes */
> > + if (put_user(p, purged))
> > + return -EFAULT;
> > + }
> > +
> > + ret = do_vrange(mm, start, end, mode, &p);
> > +
> > + if (purged) {
> > + if (put_user(p, purged)) {
> > + /*
> > + * This would be bad, since we've modified volatilty
> > + * and the change in purged state would be lost.
> > + */
> > + WARN_ONCE(1, "vrange: purge state possibly lost\n");
> > + }
> > + }
> > +
> > +out:
> > + return ret;
> > +}
> Honza
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: John Stultz <john.stultz@linaro.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Android Kernel Team <kernel-team@android.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Robert Love <rlove@google.com>, Mel Gorman <mel@csn.ul.ie>,
Hugh Dickins <hughd@google.com>, Dave Hansen <dave@sr71.net>,
Rik van Riel <riel@redhat.com>,
Dmitry Adamushko <dmitry.adamushko@gmail.com>,
Neil Brown <neilb@suse.de>,
Andrea Arcangeli <aarcange@redhat.com>,
Mike Hommey <mh@glandium.org>, Taras Glek <tglek@mozilla.com>,
Dhaval Giani <dgiani@mozilla.com>, Jan Kara <jack@suse.cz>,
KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
Michel Lespinasse <walken@google.com>,
Minchan Kim <minchan@kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH 1/3] vrange: Add vrange syscall and handle splitting/merging and marking vmas
Date: Mon, 17 Mar 2014 10:43:39 +0100 [thread overview]
Message-ID: <20140317094339.GC2210@quack.suse.cz> (raw)
In-Reply-To: <20140317092118.GA2210@quack.suse.cz>
On Mon 17-03-14 10:21:18, Jan Kara wrote:
> On Fri 14-03-14 11:33:31, John Stultz wrote:
> > + for (;;) {
> > + unsigned long new_flags;
> > + pgoff_t pgoff;
> > + unsigned long tmp;
> > +
> > + if (!vma)
> > + goto out;
> > +
> > + if (vma->vm_flags & (VM_SPECIAL|VM_LOCKED|VM_MIXEDMAP|
> > + VM_HUGETLB))
> > + goto out;
> > +
> > + /* We don't support volatility on files for now */
> > + if (vma->vm_file) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> > +
> > + new_flags = vma->vm_flags;
> > +
> > + if (start < vma->vm_start) {
> > + start = vma->vm_start;
> > + if (start >= end)
> > + goto out;
> > + }
One more question: This seems to silently skip any holes between VMAs. Is
that really intended? I'd expect that marking unmapped range as volatile /
non-volatile should return error... In any case what happens should be
defined in the description.
Honza
> > + tmp = vma->vm_end;
> > + if (end < tmp)
> > + tmp = end;
> > +
> > + switch (mode) {
> > + case VRANGE_VOLATILE:
> > + new_flags |= VM_VOLATILE;
> > + break;
> > + case VRANGE_NONVOLATILE:
> > + new_flags &= ~VM_VOLATILE;
> > + }
> > +
> > + pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT);
> > + prev = vma_merge(mm, prev, start, tmp, new_flags,
> > + vma->anon_vma, vma->vm_file, pgoff,
> > + vma_policy(vma));
> > + if (prev)
> > + goto success;
> > +
> > + if (start != vma->vm_start) {
> > + ret = split_vma(mm, vma, start, 1);
> > + if (ret)
> > + goto out;
> > + }
> > +
> > + if (tmp != vma->vm_end) {
> > + ret = split_vma(mm, vma, tmp, 0);
> > + if (ret)
> > + goto out;
> > + }
> > +
> > + prev = vma;
> > +success:
> > + vma->vm_flags = new_flags;
> > + *purged = lpurged;
> > +
> > + /* update count to distance covered so far*/
> > + count = tmp - orig_start;
> > +
> > + if (prev && start < prev->vm_end)
> In which case 'prev' can be NULL? And when start >= prev->vm_end? In all
> the cases I can come up with this condition seems to be true...
>
> > + start = prev->vm_end;
> > + if (start >= end)
> > + goto out;
> > + if (prev)
> Ditto regarding 'prev'...
>
> > + vma = prev->vm_next;
> > + else /* madvise_remove dropped mmap_sem */
> > + vma = find_vma(mm, start);
> The comment regarding madvise_remove() looks bogus...
>
> > + }
> > +out:
> > + up_read(&mm->mmap_sem);
> > +
> > + /* report bytes successfully marked, even if we're exiting on error */
> > + if (count)
> > + return count;
> > +
> > + return ret;
> > +}
> > +
> > +SYSCALL_DEFINE4(vrange, unsigned long, start,
> > + size_t, len, int, mode, int __user *, purged)
> > +{
> > + unsigned long end;
> > + struct mm_struct *mm = current->mm;
> > + ssize_t ret = -EINVAL;
> > + int p = 0;
> > +
> > + if (start & ~PAGE_MASK)
> > + goto out;
> > +
> > + len &= PAGE_MASK;
> > + if (!len)
> > + goto out;
> > +
> > + end = start + len;
> > + if (end < start)
> > + goto out;
> > +
> > + if (start >= TASK_SIZE)
> > + goto out;
> > +
> > + if (purged) {
> > + /* Test pointer is valid before making any changes */
> > + if (put_user(p, purged))
> > + return -EFAULT;
> > + }
> > +
> > + ret = do_vrange(mm, start, end, mode, &p);
> > +
> > + if (purged) {
> > + if (put_user(p, purged)) {
> > + /*
> > + * This would be bad, since we've modified volatilty
> > + * and the change in purged state would be lost.
> > + */
> > + WARN_ONCE(1, "vrange: purge state possibly lost\n");
> > + }
> > + }
> > +
> > +out:
> > + return ret;
> > +}
> Honza
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2014-03-17 9:43 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-14 18:33 [PATCH 0/3] Volatile Ranges (v11) John Stultz
2014-03-14 18:33 ` John Stultz
2014-03-14 18:33 ` [PATCH 1/3] vrange: Add vrange syscall and handle splitting/merging and marking vmas John Stultz
2014-03-14 18:33 ` John Stultz
2014-03-17 9:21 ` Jan Kara
2014-03-17 9:21 ` Jan Kara
2014-03-17 9:43 ` Jan Kara [this message]
2014-03-17 9:43 ` Jan Kara
2014-03-18 0:36 ` John Stultz
2014-03-18 0:36 ` John Stultz
2014-03-17 22:19 ` John Stultz
2014-03-17 22:19 ` John Stultz
2014-03-14 18:33 ` [PATCH 2/3] vrange: Add purged page detection on setting memory non-volatile John Stultz
2014-03-14 18:33 ` John Stultz
2014-03-17 9:39 ` Jan Kara
2014-03-17 9:39 ` Jan Kara
2014-03-17 22:22 ` John Stultz
2014-03-17 22:22 ` John Stultz
2014-03-14 18:33 ` [PATCH 3/3] vrange: Add page purging logic & SIGBUS trap John Stultz
2014-03-14 18:33 ` John Stultz
2014-03-18 12:24 ` [PATCH 0/3] Volatile Ranges (v11) Michal Hocko
2014-03-18 12:24 ` Michal Hocko
2014-03-18 17:53 ` John Stultz
2014-03-18 17:53 ` John Stultz
2014-03-20 0:38 ` Dave Hansen
2014-03-20 0:38 ` Dave Hansen
2014-03-20 0:57 ` John Stultz
2014-03-20 0:57 ` John Stultz
2014-03-20 7:45 ` Minchan Kim
2014-03-20 7:45 ` Minchan Kim
2014-03-18 15:11 ` Minchan Kim
2014-03-18 15:11 ` Minchan Kim
2014-03-18 18:07 ` John Stultz
2014-03-18 18:07 ` John Stultz
2014-03-19 0:49 ` Minchan Kim
2014-03-19 10:12 ` Jan Kara
2014-03-19 10:12 ` Jan Kara
2014-03-20 1:09 ` Minchan Kim
2014-03-20 1:09 ` Minchan Kim
2014-03-20 8:13 ` Jan Kara
2014-03-20 8:13 ` Jan Kara
2014-03-21 5:29 ` Minchan Kim
2014-03-21 5:29 ` Minchan Kim
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=20140317094339.GC2210@quack.suse.cz \
--to=jack@suse.cz \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dave@sr71.net \
--cc=dgiani@mozilla.com \
--cc=dmitry.adamushko@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=kosaki.motohiro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=mh@glandium.org \
--cc=minchan@kernel.org \
--cc=neilb@suse.de \
--cc=riel@redhat.com \
--cc=rlove@google.com \
--cc=tglek@mozilla.com \
--cc=walken@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.