Re: [PATCH v18 2/5] fs/proc/task_mmu: Implement IOCTL to get and optionally clear info about PTEs

From: Michał Mirosław
Date: Tue Jun 13 2023 - 18:36:44 EST


On Tue, 13 Jun 2023 at 12:29, Muhammad Usama Anjum
<usama.anjum@xxxxxxxxxxxxx> wrote:
>
> This IOCTL, PAGEMAP_SCAN on pagemap file can be used to get and/or clear
> the info about page table entries. The following operations are supported
> in this ioctl:
> - Get the information if the pages have been written-to (PAGE_IS_WRITTEN),
> file mapped (PAGE_IS_FILE), present (PAGE_IS_PRESENT) or swapped
> (PAGE_IS_SWAPPED).
> - Find pages which have been written-to and/or write protect the pages
> (atomic PM_SCAN_OP_GET + PM_SCAN_OP_WP)
>
> This IOCTL can be extended to get information about more PTE bits.
[...]
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
[...]
> +static int pagemap_scan_output(bool wt, bool file, bool pres, bool swap,
> + struct pagemap_scan_private *p,
> + unsigned long addr, unsigned int n_pages)
> +{
> + unsigned long bitmap = PM_SCAN_BITMAP(wt, file, pres, swap);
> + struct page_region *cur_buf = &p->cur_buf;

Maybe we can go a step further and say here `cur_buf =
&p->vec_buf[p->vec_buf_index];` and remove `p->cur_buf` entirely?

> +
> + if (!n_pages)
> + return -EINVAL;
> +
> + if ((p->required_mask & bitmap) != p->required_mask)
> + return 0;
> + if (p->anyof_mask && !(p->anyof_mask & bitmap))
> + return 0;
> + if (p->excluded_mask & bitmap)
> + return 0;
> +
> + bitmap &= p->return_mask;
> + if (!bitmap)
> + return 0;
> +
> + if (cur_buf->bitmap == bitmap &&
> + cur_buf->start + cur_buf->len * PAGE_SIZE == addr) {
> + cur_buf->len += n_pages;
> + p->found_pages += n_pages;
> + } else {
> + if (cur_buf->len && p->vec_buf_index >= p->vec_buf_len)
> + return -ENOMEM;

Shouldn't this be -ENOSPC? -ENOMEM usually signifies that the kernel
ran out of memory when allocating, not that there is no space in a
user-provided buffer.

BTW, the check could be inside the if() below for easier reading and
less redundancy.

> + if (cur_buf->len) {
> + memcpy(&p->vec_buf[p->vec_buf_index], cur_buf,
> + sizeof(*p->vec_buf));
> + p->vec_buf_index++;
> + }
> +
> + cur_buf->start = addr;
> + cur_buf->len = n_pages;
> + cur_buf->bitmap = bitmap;
> + p->found_pages += n_pages;
> + }
> +
> + if (p->max_pages && (p->found_pages == p->max_pages))

Since `p->found_pages > 0` holds here, the first check is redundant.
Nit: the parentheses around == are not needed.

> + return PM_SCAN_FOUND_MAX_PAGES;
> +
> + return 0;
> +}
[...]
> +static inline unsigned long pagemap_scan_check_page_written(struct pagemap_scan_private *p)
> +{
> + return ((p->required_mask | p->anyof_mask | p->excluded_mask) &
> + PAGE_IS_WRITTEN) ? PM_SCAN_OP_WRITE : 0;
> +}

Please inline at the single callsite.

For flags name: PM_REQUIRE_WRITE_ACCESS?
Or Is it intended to be checked only if doing WP (as the current name
suggests) and so it would be redundant as WP currently requires
`p->required_mask = PAGE_IS_WRITTEN`?

> +static int pagemap_scan_args_valid(struct pm_scan_arg *arg, unsigned long start,
> + struct page_region __user *vec)
> +{
> + /* Detect illegal size, flags, len and masks */
> + if (arg->size != sizeof(struct pm_scan_arg))
> + return -EINVAL;
> + if (arg->flags & ~PM_SCAN_OPS)
> + return -EINVAL;
> + if (!arg->len)
> + return -EINVAL;
> + if ((arg->required_mask | arg->anyof_mask | arg->excluded_mask |
> + arg->return_mask) & ~PM_SCAN_BITS_ALL)
> + return -EINVAL;
> + if (!arg->required_mask && !arg->anyof_mask &&
> + !arg->excluded_mask)
> + return -EINVAL;
> + if (!arg->return_mask)
> + return -EINVAL;

I just noticed that `!arg->return_mask == !IS_PM_SCAN_GET()`. So the
OP_GET is redundant and can be removed from the `flags` if checking
`return_mask` instead. That way there won't be a "flags-encoded ops"
thing as it would be a 'scan' with optional 'write-protect'.

> +
> + /* Validate memory range */
> + if (!IS_ALIGNED(start, PAGE_SIZE))
> + return -EINVAL;
> + if (!access_ok((void __user *)start, arg->len))
> + return -EFAULT;
> +
> + if (IS_PM_SCAN_GET(arg->flags)) {
> + if (!arg->vec)
> + return -EINVAL;

access_ok() -> -EFAULT (an early fail-check) (the vec_len should be
checked first then, failing with -EINVAL if 0)

> + if (arg->vec_len == 0)
> + return -EINVAL;
> + }
> +
> + if (IS_PM_SCAN_WP(arg->flags)) {
> + if (!IS_PM_SCAN_GET(arg->flags) && arg->max_pages)
> + return -EINVAL;
> +
> + if ((arg->required_mask | arg->anyof_mask | arg->excluded_mask) &
> + ~PAGE_IS_WRITTEN)

Is `excluded_mask = PAGE_IS_WRITTEN` intended to be allowed? It would
make WP do nothing, unless the required/anyof/excluded masks are not
supposed to limit WP?


> + return -EINVAL;
> + }

If `flags == 0` (and `return_mask == 0` in case my earlier comment is
applied) it should fail with -EINVAL.

[...]
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> +/*
> + * struct page_region - Page region with bitmap flags
> + * @start: Start of the region
> + * @len: Length of the region in pages
> + * bitmap: Bits sets for the region

'@' is missing for the third field. BTW, maybe we can call it
something like `flags` or `category` (something that hints at the
meaning of the value instead of its data representation).

> +/*
> + * struct pm_scan_arg - Pagemap ioctl argument
> + * @size: Size of the structure
> + * @flags: Flags for the IOCTL
> + * @start: Starting address of the region
> + * @len: Length of the region (All the pages in this length are included)

Maybe `scan_start`, `scan_len` - so that there is a better distinction
from the structure's `size` field?

> + * @vec: Address of page_region struct array for output
> + * @vec_len: Length of the page_region struct array
> + * @max_pages: Optional max return pages
> + * @required_mask: Required mask - All of these bits have to be set in the PTE
> + * @anyof_mask: Any mask - Any of these bits are set in the PTE
> + * @excluded_mask: Exclude mask - None of these bits are set in the PTE
> + * @return_mask: Bits that are to be reported in page_region
> + */

I skipped most of the page walk implementation as maybe the comments
above could make it simpler. Reading this patch and the documentation
I still feel confused about how the filtering/limiting parameters
should affect GET, WP and WP+GET. Should they limit the pages walked
(and WP-ed)? Or only the GET's output? How about GET+WP case?

Best Regards

Michał Mirosław