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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
