Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 18 Oct 2022 12:48:04 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc:     Danylo Mocherniuk <mdanylo@google.com>, avagin@gmail.com,
        linux-mm@kvack.org, akpm@linux-foundation.org, corbet@lwn.net,
        david@redhat.com, kernel@collabora.com, krisman@collabora.com,
        linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
        peter.enderborg@sony.com, shuah@kernel.org,
        viro@zeniv.linux.org.uk, willy@infradead.org, emmir@google.com,
        figiel@google.com, kyurtsever@google.com,
        Paul Gofman <pgofman@codeweavers.com>, surenb@google.com
Subject: Re: [PATCH v3 0/4] Implement IOCTL to get and clear soft dirty PTE
Message-ID: <Y06EZNAkLtigZi25@kroah.com>
References: <Y0T2l3HaH2MU8M9m@gmail.com>
 <20221014134802.1361436-1-mdanylo@google.com>
 <474513c0-4ff9-7978-9d77-839fe775d04c@collabora.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <474513c0-4ff9-7978-9d77-839fe775d04c@collabora.com>
Precedence: bulk

On Tue, Oct 18, 2022 at 03:36:24PM +0500, Muhammad Usama Anjum wrote:
> /**
>  * struct pagemap_sd_args - Soft-dirty IOCTL argument
>  * @start:		Starting address
>  * @len:		Length of the region
>  * @vec:		Output page_region struct array
>  * @vec_len:		Length of the page_region struct array
>  * @max_out_page:	Optional max output pages (It must be less than vec_len if
> specified)
>  * @flags:		Special flags for the IOCTL
>  * @rmask:		Special flags for the IOCTL
>  * @amask:		Special flags for the IOCTL
>  * @emask:		Special flags for the IOCTL

What do you mean exactly by "special flags"?

>  * @__reserved:		Reserved member to preserve data alignment. Must be 0.
>  */
> struct pagemap_sd_args {
> 	__u64 __user start;
> 	__u64 len;
> 	__u64 __user vec; // page_region

__user is a marking for a pointer, not a u64, right?  Now the fact that
you treat it like a pointer later in the kernel is different, but that
shouldn't be on the uapi header file.  You can put it in the kerneldoc,
which you did not do.

thanks,

greg k-h