All of lore.kernel.org
 help / color / mirror / Atom feed
From: Muhammad Usama Anjum <usama.anjum@collabora.com>
To: "Nadav Amit" <namit@vmware.com>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Michał Mirosław" <emmir@google.com>
Cc: "Muhammad Usama Anjum" <usama.anjum@collabora.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Michał Mirosław" <emmir@google.com>,
	"Cyrill Gorcunov" <gorcunov@gmail.com>,
	"Paul Gofman" <pgofman@codeweavers.com>,
	"Danylo Mocherniuk" <mdanylo@google.com>,
	"Shuah Khan" <shuah@kernel.org>,
	"Christian Brauner" <brauner@kernel.org>,
	"Peter Xu" <peterx@redhat.com>, "Yang Shi" <shy828301@gmail.com>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Liam R . Howlett" <Liam.Howlett@Oracle.com>,
	"Yun Zhou" <yun.zhou@windriver.com>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Alex Sierra" <alex.sierra@amd.com>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Pasha Tatashin" <pasha.tatashin@soleen.com>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Axel Rasmussen" <axelrasmussen@google.com>,
	"Gustavo A . R . Silva" <gustavoars@kernel.org>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"kernel list" <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	linux-kselftest <linux-kselftest@vger.kernel.org>,
	"Greg KH" <gregkh@linuxfoundation.org>,
	"kernel@collabora.com" <kernel@collabora.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Andrei Vagin" <avagin@gmail.com>
Subject: Re: [PATCH v10 3/6] fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs
Date: Thu, 23 Feb 2023 12:10:40 +0500	[thread overview]
Message-ID: <c15446c5-eedd-690f-9dae-2bc12ee9eb78@collabora.com> (raw)
In-Reply-To: <751CCD6C-BFD1-42BD-A651-AE8E9568568C@vmware.com>

Hi Nadav, Mike, Michał,

Can you please share your thoughts at [A] below?

On 2/23/23 12:10 AM, Nadav Amit wrote:
> 
> 
>> On Feb 20, 2023, at 5:24 AM, Muhammad Usama Anjum <usama.anjum@collabora.com> wrote:
>>
>>>> +static inline int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
>>>> +                     unsigned long end, struct mm_walk *walk)
>>>> +{
>>>> +    struct pagemap_scan_private *p = walk->private;
>>>> +    struct vm_area_struct *vma = walk->vma;
>>>> +    unsigned long addr = end;
>>>> +    spinlock_t *ptl;
>>>> +    int ret = 0;
>>>> +    pte_t *pte;
>>>> +
>>>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>>> +    ptl = pmd_trans_huge_lock(pmd, vma);
>>>> +    if (ptl) {
>>>> +        bool pmd_wt;
>>>> +
>>>> +        pmd_wt = !is_pmd_uffd_wp(*pmd);
>>>> +        /*
>>>> +         * Break huge page into small pages if operation needs to be
>>>> performed is
>>>> +         * on a portion of the huge page.
>>>> +         */
>>>> +        if (pmd_wt && IS_WP_ENGAGE_OP(p) && (end - start < HPAGE_SIZE)) {
>>>> +            spin_unlock(ptl);
>>>> +            split_huge_pmd(vma, pmd, start);
>>>> +            goto process_smaller_pages;
>>> I think that such goto's are really confusing and should be avoided. And
>>> using 'else' (could have easily prevented the need for goto). It is not the
>>> best solution though, since I think it would have been better to invert the
>>> conditions.
>> Yeah, else can be used here. But then we'll have to add a tab to all the
>> code after adding else. We have already so many tabs and very less space to
>> right code. Not sure which is better.
> 
> goto’s are usually not the right solution. You can extract things into a different
> function if you have to.
> 
> I’m not sure why IS_GET_OP(p) might be false and what’s the meaning of taking the
> lock and dropping it in such a case. I think that the code can be simplified and
> additional condition nesting can be avoided.
Lock is taken and we check if pmd has UFFD_WP set or not. In the next
version, the GET check has been removed as we have dropped WP_ENGAGE + !GET
operation. So get is always specified and condition isn't needed.

Please comment on next version if you want anything more optimized.

> 
>>>> --- a/include/uapi/linux/fs.h
>>>> +++ b/include/uapi/linux/fs.h
>>>> @@ -305,4 +305,54 @@ typedef int __bitwise __kernel_rwf_t;
>>>>  #define RWF_SUPPORTED    (RWF_HIPRI | RWF_DSYNC | RWF_SYNC | RWF_NOWAIT |\
>>>>               RWF_APPEND)
>>>>  +/* Pagemap ioctl */
>>>> +#define PAGEMAP_SCAN    _IOWR('f', 16, struct pagemap_scan_arg)
>>>> +
>>>> +/* Bits are set in the bitmap of the page_region and masks in
>>>> pagemap_scan_args */
>>>> +#define PAGE_IS_WRITTEN        (1 << 0)
>>>> +#define PAGE_IS_FILE        (1 << 1)
>>>> +#define PAGE_IS_PRESENT        (1 << 2)
>>>> +#define PAGE_IS_SWAPPED        (1 << 3)
>>>
>>> These names are way too generic and are likely to be misused for the wrong
>>> purpose. The "_IS_" part seems confusing as well. So I think the naming
>>> needs to be fixed and some new type (using typedef) or enum should be
>>> introduced to hold these flags. I understand it is part of uapi and it is
>>> less common there, but it is not unheard of and does make things clearer.
>> Do you think PM_SCAN_PAGE_IS_* work here?
> 
> Can we lose the IS somehow?
[A] Do you think these names would work better: PM_SCAN_WRITTEN_PAGE,
PM_SCAN_FILE_PAGE, PM_SCAN_SWAP_PAGE, PM_SCAN_PRESENT_PAGE?

> 
>>
>>>
>>>
>>>> +
>>>> +/*
>>>> + * struct page_region - Page region with bitmap flags
>>>> + * @start:    Start of the region
>>>> + * @len:    Length of the region
>>>> + * bitmap:    Bits sets for the region
>>>> + */
>>>> +struct page_region {
>>>> +    __u64 start;
>>>> +    __u64 len;
>>>
>>> I presume in bytes. Would be useful to mention.
>> Length of region in pages.
> 
> Very unintuitive to me I must say. If the start is an address, I would expect
> the len to be in bytes.
The PAGEMAP_SCAN ioctl is working on page granularity level. We tell the
user if a page has certain flags are not. Keeping length in bytes doesn't
makes sense.

> 

-- 
BR,
Muhammad Usama Anjum

  reply	other threads:[~2023-02-23  7:10 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-02 11:29 [PATCH v10 0/6] Implement IOCTL to get and/or the clear info about PTEs Muhammad Usama Anjum
2023-02-02 11:29 ` [PATCH v10 1/6] userfaultfd: Add UFFD WP Async support Muhammad Usama Anjum
2023-02-08 21:12   ` Peter Xu
2023-02-09 15:27     ` Muhammad Usama Anjum
2023-02-17  9:37   ` Mike Rapoport
2023-02-20  8:36     ` Muhammad Usama Anjum
2023-02-02 11:29 ` [PATCH v10 2/6] userfaultfd: update documentation to describe UFFD_FEATURE_WP_ASYNC Muhammad Usama Anjum
2023-02-08 21:31   ` Peter Xu
2023-02-09 15:47     ` Muhammad Usama Anjum
2023-02-02 11:29 ` [PATCH v10 3/6] fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs Muhammad Usama Anjum
2023-02-08 22:15   ` Peter Xu
2023-02-13 12:55     ` Muhammad Usama Anjum
2023-02-13 21:42       ` Peter Xu
2023-02-14  7:57         ` Muhammad Usama Anjum
2023-02-14 20:59           ` Peter Xu
2023-02-15 10:03             ` Muhammad Usama Anjum
2023-02-15 21:12               ` Peter Xu
2023-02-17 10:39                 ` Muhammad Usama Anjum
2023-02-08 22:22   ` Cyrill Gorcunov
2023-02-13  8:19     ` Muhammad Usama Anjum
2023-02-17 10:10   ` Mike Rapoport
2023-02-20 10:38     ` Muhammad Usama Anjum
2023-02-20 11:38       ` Muhammad Usama Anjum
2023-02-20 13:17         ` Mike Rapoport
2023-02-17 15:18   ` Michał Mirosław
2023-02-21 10:28     ` Muhammad Usama Anjum
2023-02-21 12:42       ` Michał Mirosław
2023-02-22 10:11         ` Muhammad Usama Anjum
2023-02-22 10:44           ` Michał Mirosław
2023-02-22 11:06             ` Muhammad Usama Anjum
2023-02-22 11:48               ` Michał Mirosław
2023-02-23  6:44                 ` Muhammad Usama Anjum
2023-02-23  8:41                   ` Michał Mirosław
2023-02-23  9:23                     ` Muhammad Usama Anjum
2023-02-23  9:42                       ` Michał Mirosław
2023-02-24  2:20         ` Andrei Vagin
2023-02-25  9:38           ` Michał Mirosław
2023-02-19 13:52   ` Nadav Amit
2023-02-20 13:24     ` Muhammad Usama Anjum
2023-02-22 19:10       ` Nadav Amit
2023-02-23  7:10         ` Muhammad Usama Anjum [this message]
2023-02-23 17:11           ` Nadav Amit
2023-02-27 21:18             ` Peter Xu
2023-02-27 23:09               ` Nadav Amit
2023-02-28 15:55                 ` Peter Xu
2023-02-28 17:21                   ` Nadav Amit
2023-02-28 19:31                     ` Peter Xu
2023-03-01  1:59                       ` Nadav Amit
2023-02-20 13:26   ` Mike Rapoport
2023-02-21  7:02     ` Muhammad Usama Anjum
2023-02-02 11:29 ` [PATCH v10 4/6] tools headers UAPI: Update linux/fs.h with the kernel sources Muhammad Usama Anjum
2023-02-02 11:29 ` [PATCH v10 5/6] mm/pagemap: add documentation of PAGEMAP_SCAN IOCTL Muhammad Usama Anjum
2023-02-09 19:26   ` Peter Xu
2023-02-13 10:44     ` Muhammad Usama Anjum
2023-02-02 11:29 ` [PATCH v10 6/6] selftests: vm: add pagemap ioctl tests Muhammad Usama Anjum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c15446c5-eedd-690f-9dae-2bc12ee9eb78@collabora.com \
    --to=usama.anjum@collabora.com \
    --cc=Liam.Howlett@Oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.sierra@amd.com \
    --cc=avagin@gmail.com \
    --cc=axelrasmussen@google.com \
    --cc=brauner@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=emmir@google.com \
    --cc=gorcunov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavoars@kernel.org \
    --cc=kernel@collabora.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mdanylo@google.com \
    --cc=namit@vmware.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=peterx@redhat.com \
    --cc=pgofman@codeweavers.com \
    --cc=rppt@kernel.org \
    --cc=shuah@kernel.org \
    --cc=shy828301@gmail.com \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=yun.zhou@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.