cregit-Linux how code gets into the kernel

Release 4.12 include/uapi/linux/userfaultfd.h

 *  include/linux/userfaultfd.h
 *  Copyright (C) 2007  Davide Libenzi <>
 *  Copyright (C) 2015  Red Hat, Inc.



#include <linux/types.h>

 * If the UFFDIO_API is upgraded someday, the UFFDIO_UNREGISTER and
 * UFFDIO_WAKE ioctls should be defined as _IOW and not as _IOR.  In
 * userfaultfd.h we assumed the kernel was reading (instead _IOC_READ
 * means the userland is reading).

#define UFFD_API ((__u64)0xAA)

                           UFFD_FEATURE_EVENT_REMAP |           \
                           UFFD_FEATURE_EVENT_REMOVE |  \
                           UFFD_FEATURE_EVENT_UNMAP |           \
                           UFFD_FEATURE_MISSING_HUGETLBFS |     \

#define UFFD_API_IOCTLS				\
	((__u64)1 << _UFFDIO_REGISTER |         \
         (__u64)1 << _UFFDIO_UNREGISTER |       \
         (__u64)1 << _UFFDIO_API)

	((__u64)1 << _UFFDIO_WAKE |             \
         (__u64)1 << _UFFDIO_COPY |             \
         (__u64)1 << _UFFDIO_ZEROPAGE)

	((__u64)1 << _UFFDIO_WAKE |             \
         (__u64)1 << _UFFDIO_COPY)

 * Valid ioctl command number range with this API is from 0x00 to
 * 0x3F.  UFFDIO_API is the fixed number, everything else can be
 * changed by implementing a different UFFD_API. If sticking to the
 * same UFFD_API more ioctl can be added and userland will be aware of
 * which ioctl the running kernel implements through the ioctl command
 * bitmask written by the UFFDIO_API.

#define _UFFDIO_REGISTER		(0x00)

#define _UFFDIO_UNREGISTER		(0x01)

#define _UFFDIO_WAKE			(0x02)

#define _UFFDIO_COPY			(0x03)

#define _UFFDIO_ZEROPAGE		(0x04)

#define _UFFDIO_API			(0x3F)

/* userfaultfd ioctl ids */

#define UFFDIO 0xAA

                                      struct uffdio_api)

                                      struct uffdio_register)

                                     struct uffdio_range)

                                     struct uffdio_range)

                                      struct uffdio_copy)

                                      struct uffdio_zeropage)

/* read() structure */

struct uffd_msg {
__u8	event;

__u8	reserved1;
__u16	reserved2;
__u32	reserved3;

	union {
		struct {
__u64	flags;
__u64	address;
} pagefault;

		struct {
__u32	ufd;
} fork;

		struct {
__u64	from;
__u64	to;
__u64	len;
} remap;

		struct {
__u64	start;
__u64	end;
} remove;

		struct {
			/* unused reserved fields */
__u64	reserved1;
__u64	reserved2;
__u64	reserved3;
} reserved;
} arg;

} __packed;

 * Start at 0x12 and not at 0 to be more strict against bugs.


#define UFFD_EVENT_FORK		0x13

#define UFFD_EVENT_REMAP	0x14

#define UFFD_EVENT_REMOVE	0x15

#define UFFD_EVENT_UNMAP	0x16

/* flags for UFFD_EVENT_PAGEFAULT */

/* If this was a write fault */

#define UFFD_PAGEFAULT_FLAG_WP		(1<<1)	
/* If reason is VM_UFFD_WP */

struct uffdio_api {
	/* userland asks for an API number and the features to enable */
__u64 api;
         * Kernel answers below with the all available features for
         * the API, this notifies userland of which events and/or
         * which flags for each event are enabled in the current
         * kernel.
         * are to be considered implicitly always enabled in all kernels as
         * long as the uffdio_api.api requested matches UFFD_API.
         * with UFFDIO_REGISTER_MODE_MISSING mode will succeed on
         * hugetlbfs virtual memory ranges. Adding or not adding
         * UFFD_FEATURE_MISSING_HUGETLBFS to uffdio_api.features has
         * no real functional effect after UFFDIO_API returns, but
         * it's only useful for an initial feature set probe at
         * UFFDIO_API time. There are two ways to use it:
         * 1) by adding UFFD_FEATURE_MISSING_HUGETLBFS to the
         *    uffdio_api.features before calling UFFDIO_API, an error
         *    will be returned by UFFDIO_API on a kernel without
         *    hugetlbfs missing support
         * 2) the UFFD_FEATURE_MISSING_HUGETLBFS can not be added in
         *    uffdio_api.features and instead it will be set by the
         *    kernel in the uffdio_api.features if the kernel supports
         *    it, so userland can later check if the feature flag is
         *    present in uffdio_api.features after UFFDIO_API
         *    succeeded.
         * 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).


#define UFFD_FEATURE_EVENT_FORK			(1<<1)





__u64 features;

__u64 ioctls;

struct uffdio_range {
__u64 start;
__u64 len;

struct uffdio_register {
struct uffdio_range range;

#define UFFDIO_REGISTER_MODE_MISSING	((__u64)1<<0)

#define UFFDIO_REGISTER_MODE_WP		((__u64)1<<1)
__u64 mode;

         * kernel answers which ioctl commands are available for the
         * range, keep at the end as the last 8 bytes aren't read.
__u64 ioctls;

struct uffdio_copy {
__u64 dst;
__u64 src;
__u64 len;
         * There will be a wrprotection flag later that allows to map
         * pages wrprotected on the fly. And such a flag will be
         * available if the wrprotection ioctl are implemented for the
         * range according to the uffdio_register.ioctls.

#define UFFDIO_COPY_MODE_DONTWAKE		((__u64)1<<0)
__u64 mode;

         * "copy" is written by the ioctl and must be at the end: the
         * copy_from_user will not read the last 8 bytes.
__s64 copy;

struct uffdio_zeropage {
struct uffdio_range range;

#define UFFDIO_ZEROPAGE_MODE_DONTWAKE		((__u64)1<<0)
__u64 mode;

         * "zeropage" is written by the ioctl and must be at the end:
         * the copy_from_user will not read the last 8 bytes.
__s64 zeropage;


Overall Contributors

Andrea Arcangeli26178.85%746.67%
Pavel Emelyanov5416.31%426.67%
Mike Rapoport123.63%320.00%
Mike Kravetz41.21%16.67%
Information contained on this website is for historical information purposes only and does not indicate or represent copyright ownership.
Created with cregit.