linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: Alexey Perevalov <a.perevalov@samsung.com>
Cc: "Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	linux-mm@kvack.org, i.maximets@samsung.com,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH v2] userfaultfd: provide pid in userfault msg
Date: Wed, 29 Mar 2017 19:19:03 +0200	[thread overview]
Message-ID: <20170329171903.GG25920@redhat.com> (raw)
In-Reply-To: <1490207346-9703-2-git-send-email-a.perevalov@samsung.com>

Hello,

On Wed, Mar 22, 2017 at 09:29:06PM +0300, Alexey Perevalov wrote:
>  static inline struct uffd_msg userfault_msg(unsigned long address,
>  					    unsigned int flags,
> -					    unsigned long reason)
> +					    unsigned long reason,
> +					    unsigned int features)

userfaultfd_ctx.features is an int so this looks fine to me too. It's
in kernel representation and we do the validation with a __u64 on the
stack in userfaultfd_api() so that we -EINVAL any unknown bit >=32 to
retain backwards compatibility and so we can start using bits over 32
sometime later (by turning the above in a long long).

If the validation passes we then store the "known" (i.e. <32bit)
features in userfaultfd_ctx.features and we keep passing it around as
an int so we can pass it as an int above too.

> @@ -83,6 +84,7 @@ struct uffd_msg {
>  		struct {
>  			__u64	flags;
>  			__u64	address;
> +			pid_t   ptid;
>  		} pagefault;

Now that you made it conditional to a feature flag this could now be
put in an union and I think it'd better be a __u32 (or __u64 if the
pid space is expected to grow beyond 32bit any time in the future,
probably unlikely so __u32 could be enough).

Last thing I wonder is what happens if you pass the uffd from a
container under a PID namespace to some process outside the PID
namespace through unix domains sockets. Then the tpid seen by the
other container will be remapped and it may not be meaningful but
considering this is used for statistical purposes it will still
work. The security is handled through the unix domain sockets in such
case, if the app gives up voluntarily its uffd then it's ok the app
outside the namespace sees the tpid inside (and the same in the other
way around).

The important issue that got fixed in v2 and that I worried about in
v1, is the tpid seen by an uffd inside the namespace is the namespace
tpid and not the one seen outside the namespace that must never be
shown to userland.

Any other comment about merging this new uffd feature?

Thanks,
Andrea

--
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>

      parent reply	other threads:[~2017-03-29 17:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20170322182915eucas1p1e82e604ec8a37d6cd82fdccabe173b87@eucas1p1.samsung.com>
2017-03-22 18:29 ` [PATCH v2] Illuminate thread id to user space Alexey Perevalov
     [not found]   ` <CGME20170322182918eucas1p204ef2f7aadb0ac41d11f15ef434c74c4@eucas1p2.samsung.com>
2017-03-22 18:29     ` [PATCH v2] userfaultfd: provide pid in userfault msg Alexey Perevalov
2017-03-23  9:42       ` Hillf Danton
2017-03-23 10:07         ` Alexey Perevalov
2017-03-25 11:47         ` Alexey Perevalov
2017-03-27  3:57           ` Hillf Danton
2017-03-29 17:19       ` Andrea Arcangeli [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=20170329171903.GG25920@redhat.com \
    --to=aarcange@redhat.com \
    --cc=a.perevalov@samsung.com \
    --cc=dgilbert@redhat.com \
    --cc=i.maximets@samsung.com \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=rppt@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox