This is bit late, but we're still on v4.9-rc2, so anyhow. On Wed, 2016-09-14 at 12:34 -0700, tip-bot for Dmitry Safonov wrote: > Commit-ID: 2eefd8789698e89c4a5d610921dc3c1b66e3bd0d > Gitweb: http://git.kernel.org/tip/2eefd8789698e89c4a5d610921dc3c1b66e3bd0d > Author: Dmitry Safonov <dsafonov@xxxxxxxxxxxxx> > AuthorDate: Mon, 5 Sep 2016 16:33:05 +0300 > Committer: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > CommitDate: Wed, 14 Sep 2016 21:28:09 +0200 > > x86/arch_prctl/vdso: Add ARCH_MAP_VDSO_* > > Add API to change vdso blob type with arch_prctl. > As this is usefull only by needs of CRIU, expose > this interface under CONFIG_CHECKPOINT_RESTORE. > > Signed-off-by: Dmitry Safonov <dsafonov@xxxxxxxxxxxxx> > Acked-by: Andy Lutomirski <luto@xxxxxxxxxx> > Cc: 0x7f454c46@xxxxxxxxx > Cc: oleg@xxxxxxxxxx > Cc: linux-mm@xxxxxxxxx > Cc: gorcunov@xxxxxxxxxx > Cc: xemul@xxxxxxxxxxxxx > Link: http://lkml.kernel.org/r/20160905133308.28234-4-dsafonov@xxxxxxxxxxxxx > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > --- a/arch/x86/include/uapi/asm/prctl.h > +++ b/arch/x86/include/uapi/asm/prctl.h > #define ARCH_GET_FS 0x1003 > #define ARCH_GET_GS 0x1004 > > +#ifdef CONFIG_CHECKPOINT_RESTORE > +# define ARCH_MAP_VDSO_X32 0x2001 > +# define ARCH_MAP_VDSO_32 0x2002 > +# define ARCH_MAP_VDSO_64 0x2003 > +#endif > + > #endif /* _ASM_X86_PRCTL_H */ On my machine this header ends up in /usr/include/asm/prctl.h. But in userspace CONFIG_CHECKPOINT_RESTORE is meaningless. I think if you actually want to export these three macros to userspace the guard should read: #if defined(CONFIG_CHECKPOINT_RESTORE) || !defined(__KERNEL__) And if you don't want to export these macros the guard should read: #if defined(CONFIG_CHECKPOINT_RESTORE) && defined(__KERNEL__) (In that case you're probably better of defining these macros outside of uapi.) I've only lightly tested those two alternatives, so please double check. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|