All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brendan Higgins <brendanhiggins@google.com>
To: Vitor Massaru Iha <vitor@massaru.org>
Cc: KUnit Development <kunit-dev@googlegroups.com>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	David Gow <davidgow@google.com>,
	Shuah Khan <skhan@linuxfoundation.org>,
	linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [PATCH v3] lib: kunit: Provides a userspace memory context when tests are compiled as module
Date: Tue, 21 Jul 2020 16:52:51 -0700	[thread overview]
Message-ID: <CAFd5g45DrBCA2Oq0RCb5FDWybt9NnXj=tN7pZFqjMLhuWWQoew@mail.gmail.com> (raw)
In-Reply-To: <20200721174036.71072-1-vitor@massaru.org>

On Tue, Jul 21, 2020 at 10:40 AM Vitor Massaru Iha <vitor@massaru.org> wrote:
>
> KUnit test cases run on kthreads, and kthreads don't have an
> adddress space (current->mm is NULL), but processes have mm.
>
> The purpose of this patch is to allow to borrow mm to KUnit kthread
> after userspace is brought up, because we know that there are processes
> running, at least the process that loaded the module to borrow mm.
>
> This allows, for example, tests such as user_copy_kunit, which uses
> vm_mmap, which needs current->mm.
>
> Signed-off-by: Vitor Massaru Iha <vitor@massaru.org>

Isn't this a dependency for the test_user_copy? Also, don't we also
need the change that makes kunit_tool build modules? It seems like you
should put these together in a patchset like you did before. If not,
you should at least reference the dependencies in each patch.

WARNING: multiple messages have this Message-ID (diff)
From: Brendan Higgins via Linux-kernel-mentees <linux-kernel-mentees@lists.linuxfoundation.org>
To: Vitor Massaru Iha <vitor@massaru.org>
Cc: "open list:KERNEL SELFTEST FRAMEWORK"
	<linux-kselftest@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Gow <davidgow@google.com>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	KUnit Development <kunit-dev@googlegroups.com>
Subject: Re: [Linux-kernel-mentees] [PATCH v3] lib: kunit: Provides a userspace memory context when tests are compiled as module
Date: Tue, 21 Jul 2020 16:52:51 -0700	[thread overview]
Message-ID: <CAFd5g45DrBCA2Oq0RCb5FDWybt9NnXj=tN7pZFqjMLhuWWQoew@mail.gmail.com> (raw)
In-Reply-To: <20200721174036.71072-1-vitor@massaru.org>

On Tue, Jul 21, 2020 at 10:40 AM Vitor Massaru Iha <vitor@massaru.org> wrote:
>
> KUnit test cases run on kthreads, and kthreads don't have an
> adddress space (current->mm is NULL), but processes have mm.
>
> The purpose of this patch is to allow to borrow mm to KUnit kthread
> after userspace is brought up, because we know that there are processes
> running, at least the process that loaded the module to borrow mm.
>
> This allows, for example, tests such as user_copy_kunit, which uses
> vm_mmap, which needs current->mm.
>
> Signed-off-by: Vitor Massaru Iha <vitor@massaru.org>

Isn't this a dependency for the test_user_copy? Also, don't we also
need the change that makes kunit_tool build modules? It seems like you
should put these together in a patchset like you did before. If not,
you should at least reference the dependencies in each patch.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

  parent reply	other threads:[~2020-07-21 23:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-21 17:40 [PATCH v3] lib: kunit: Provides a userspace memory context when tests are compiled as module Vitor Massaru Iha
2020-07-21 17:40 ` [Linux-kernel-mentees] " Vitor Massaru Iha
2020-07-21 19:06 ` Kees Cook
2020-07-21 19:06   ` [Linux-kernel-mentees] " Kees Cook
2020-07-21 21:50   ` Vitor Massaru Iha
2020-07-21 21:50     ` [Linux-kernel-mentees] " Vitor Massaru Iha
2020-07-21 23:52 ` Brendan Higgins [this message]
2020-07-21 23:52   ` Brendan Higgins via Linux-kernel-mentees

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='CAFd5g45DrBCA2Oq0RCb5FDWybt9NnXj=tN7pZFqjMLhuWWQoew@mail.gmail.com' \
    --to=brendanhiggins@google.com \
    --cc=davidgow@google.com \
    --cc=keescook@chromium.org \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=vitor@massaru.org \
    /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.