[PATCH v2] Illuminate thread id to user space

[PATCH v2] Illuminate thread id to user space

[Alexey Perevalov]

Hi Andrea,

This is updated patch, difference since previous version is following:
 - process thread id is provided only when it was requested with
UFFD_FEATURE_THREAD_ID bit.
 - pid from namespace is provided, so locking thread's gettid in namespace
and msg.arg.pagefault.ptid will be equal. 
 - current patch is based on
git://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git userfault
branch too, but rebased.

Alexey Perevalov (1):
  userfaultfd: provide pid in userfault msg

 fs/userfaultfd.c                 | 8 ++++++--
 include/uapi/linux/userfaultfd.h | 8 +++++++-
 2 files changed, 13 insertions(+), 3 deletions(-)

-- 
2.7.4

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

[PATCH v2] userfaultfd: provide pid in userfault msg

[Alexey Perevalov]

It could be useful for calculating downtime during
postcopy live migration per vCPU. Side observer or application itself
will be informed about proper task's sleep during userfaultfd
processing.

Process's thread id is being provided when user requeste it
by setting UFFD_FEATURE_THREAD_ID bit into uffdio_api.features.

Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com>
---
 fs/userfaultfd.c                 | 8 ++++++--
 include/uapi/linux/userfaultfd.h | 8 +++++++-
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 24fd7e0..14c30d4 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -180,7 +180,8 @@ static inline void msg_init(struct uffd_msg *msg)
 
 static inline struct uffd_msg userfault_msg(unsigned long address,
 					    unsigned int flags,
-					    unsigned long reason)
+					    unsigned long reason,
+					    unsigned int features)
 {
 	struct uffd_msg msg;
 	msg_init(&msg);
@@ -204,6 +205,8 @@ static inline struct uffd_msg userfault_msg(unsigned long address,
 		 * write protect fault.
 		 */
 		msg.arg.pagefault.flags |= UFFD_PAGEFAULT_FLAG_WP;
+	if (features & UFFD_FEATURE_THREAD_ID)
+		msg.arg.pagefault.ptid = task_pid_vnr(current);
 	return msg;
 }
 
@@ -408,7 +411,8 @@ int handle_userfault(struct vm_fault *vmf, unsigned long reason)
 
 	init_waitqueue_func_entry(&uwq.wq, userfaultfd_wake_function);
 	uwq.wq.private = current;
-	uwq.msg = userfault_msg(vmf->address, vmf->flags, reason);
+	uwq.msg = userfault_msg(vmf->address, vmf->flags, reason,
+			ctx->features);
 	uwq.ctx = ctx;
 	uwq.waken = false;
 
diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h
index 819e235..84e4a1e 100644
--- a/include/uapi/linux/userfaultfd.h
+++ b/include/uapi/linux/userfaultfd.h
@@ -24,7 +24,8 @@
 			   UFFD_FEATURE_EVENT_REMOVE |	\
 			   UFFD_FEATURE_EVENT_UNMAP |		\
 			   UFFD_FEATURE_MISSING_HUGETLBFS |	\
-			   UFFD_FEATURE_MISSING_SHMEM)
+			   UFFD_FEATURE_MISSING_SHMEM |		\
+			   UFFD_FEATURE_THREAD_ID)
 #define UFFD_API_IOCTLS				\
 	((__u64)1 << _UFFDIO_REGISTER |		\
 	 (__u64)1 << _UFFDIO_UNREGISTER |	\
@@ -83,6 +84,7 @@ struct uffd_msg {
 		struct {
 			__u64	flags;
 			__u64	address;
+			pid_t   ptid;
 		} pagefault;
 
 		struct {
@@ -158,6 +160,9 @@ struct uffdio_api {
 	 * UFFD_FEATURE_MISSING_SHMEM works the same as
 	 * UFFD_FEATURE_MISSING_HUGETLBFS, but it applies to shmem
 	 * (i.e. tmpfs and other shmem based APIs).
+	 *
+	 * UFFD_FEATURE_THREAD_ID pid of the page faulted task_struct will
+	 * be returned, if feature is not requested 0 will be returned.
 	 */
 #define UFFD_FEATURE_PAGEFAULT_FLAG_WP		(1<<0)
 #define UFFD_FEATURE_EVENT_FORK			(1<<1)
@@ -166,6 +171,7 @@ struct uffdio_api {
 #define UFFD_FEATURE_MISSING_HUGETLBFS		(1<<4)
 #define UFFD_FEATURE_MISSING_SHMEM		(1<<5)
 #define UFFD_FEATURE_EVENT_UNMAP		(1<<6)
+#define UFFD_FEATURE_THREAD_ID			(1<<7)
 	__u64 features;
 
 	__u64 ioctls;
-- 
2.7.4

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

Re: [PATCH v2] userfaultfd: provide pid in userfault msg

[Hillf Danton]

On March 23, 2017 2:29 AM 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)
Nit: the type of feature is u64 by define.


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

Re: [PATCH v2] userfaultfd: provide pid in userfault msg

[Alexey Perevalov]

On 03/23/2017 12:42 PM, Hillf Danton wrote:
> On March 23, 2017 2:29 AM 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)
> Nit: the type of feature is u64 by define.
>
Yes, you right, it's different types, especially for 32bit architectures.

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

Re: [PATCH v2] userfaultfd: provide pid in userfault msg

[Alexey Perevalov]

Hi, Hillf

On 03/23/2017 12:42 PM, Hillf Danton wrote:
> On March 23, 2017 2:29 AM 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)
> Nit: the type of feature is u64 by define.
>
>
>
>
>

Yes, let me clarify once again,
type of features is u64, but in struct uffdio_api, which used for handling
UFFDIO_API.
Function userfault_msg is using in handle_userfault, when only
context (struct userfaultfd_ctx) is available, features inside context is
type of unsigned int and uffd_ctx_features is using for casting.
It's more likely question to maintainer, but due to userfaultfd_ctx is 
internal only
structure, it's not a big problem to extend it in the future.


-- 
Best regards,
Alexey Perevalov

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

Re: [PATCH v2] userfaultfd: provide pid in userfault msg

[Hillf Danton]

On March 25, 2017 7:48 PM Alexey Perevalov wrote:
> On 03/23/2017 12:42 PM, Hillf Danton wrote:
> > On March 23, 2017 2:29 AM 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)
> > Nit: the type of feature is u64 by define.
> 
> Yes, let me clarify once again,

Thanks:)

> type of features is u64, but in struct uffdio_api, which used for handling
> UFFDIO_API.
> Function userfault_msg is using in handle_userfault, when only
> context (struct userfaultfd_ctx) is available, features inside context is
> type of unsigned int and uffd_ctx_features is using for casting.
> It's more likely question to maintainer, but due to userfaultfd_ctx is
> internal only
> structure, it's not a big problem to extend it in the future.
> 
You are right.

Hillf

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

Re: [PATCH v2] userfaultfd: provide pid in userfault msg

[Andrea Arcangeli]

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>