From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0276AC4167B for ; Wed, 13 Dec 2023 03:58:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 577D26B0451; Tue, 12 Dec 2023 22:58:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 528736B0452; Tue, 12 Dec 2023 22:58:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C9516B0453; Tue, 12 Dec 2023 22:58:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2CDF46B0451 for ; Tue, 12 Dec 2023 22:58:22 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E266C40B0C for ; Wed, 13 Dec 2023 03:58:21 +0000 (UTC) X-FDA: 81560437602.07.C66001A Received: from madrid.collaboradmins.com (madrid.collaboradmins.com [46.235.227.194]) by imf01.hostedemail.com (Postfix) with ESMTP id 0686F40006 for ; Wed, 13 Dec 2023 03:58:19 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=bYYRLl0j; dmarc=pass (policy=quarantine) header.from=collabora.com; spf=pass (imf01.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.194 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702439900; a=rsa-sha256; cv=none; b=k1XK7PkKNMj1c0sdoXgxvlEOuwWf18camGVSlc1W51JGEHYdgefnc7mOxjiDPD5K1HhaQq tUo1hvO+CJU9ZdCwVJ6d9uhKIrbXfAzU1WQuO6GQ1siJ/Kjf9f/jvpvSXNWAYpKXNs25Uc h/ZxGexTK85rlVkGpGZzX9nLGeYM7To= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=bYYRLl0j; dmarc=pass (policy=quarantine) header.from=collabora.com; spf=pass (imf01.hostedemail.com: domain of usama.anjum@collabora.com designates 46.235.227.194 as permitted sender) smtp.mailfrom=usama.anjum@collabora.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702439900; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PJJ6PZ4PdvAEnXO9rbql7ErzFCtEYWEM+Rc7rg302IA=; b=CiZNvub2zQpivmf/yrLfg8Cb4hu/J7xDtsLl7H6Mqy82T0gTstihAFx46wjYF+hOq3U8LY naPMmq7nVkwnb8TfcwwpUdqa+CfPG+QnLZAifqcHEWoTyqJsqUU4u6352PXlWrPUGQCLoA cYMGmPbv9GFr1BCV1o4pIp7J35Lv3AE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1702439898; bh=11blm8HJnQ9+FMdEFOr+A0pNMEFB7Ju+WMZoc5kI8rI=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=bYYRLl0jzzJ/ry5xSjKpPL3Ta4LRbgeYJx3Vgef71CF0GIHSmOPdE+YzqWjksBsGW d7D6bFX9jKH/NKYYgsHD+Hx61y+8aPtGJxa6ftQOA3QNawyzS7/2OT0cIKohk7KXNp Ta0Z7jytlPEm/dv4XB9uu3kZ01TwCcxFvk3s0Ze97Vs4v5Ymo687c6GBYiBUjusNxM 4AOPIQ8M5YIedSlhMujT/VRpw91eaObFkbTObneLptFPAsgiB+2uvpkrAcskIWlrGP BneWrr9+wgMp1N0R+bLRE/Nh9xaP4mOWhjbsACvzgCMSli8o+QnXqTMCRcAy/AVDaa 4oW120hXsVqSA== Received: from [100.96.234.34] (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: usama.anjum) by madrid.collaboradmins.com (Postfix) with ESMTPSA id 9787637813F2; Wed, 13 Dec 2023 03:58:09 +0000 (UTC) Message-ID: <2e4a719b-f2b3-48db-99db-d96040d78b12@collabora.com> Date: Wed, 13 Dec 2023 08:58:06 +0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: Muhammad Usama Anjum , David Hildenbrand , Suren Baghdasaryan , akpm@linux-foundation.org, viro@zeniv.linux.org.uk, brauner@kernel.org, shuah@kernel.org, aarcange@redhat.com, lokeshgidra@google.com, peterx@redhat.com, ryan.roberts@arm.com, hughd@google.com, mhocko@suse.com, axelrasmussen@google.com, rppt@kernel.org, willy@infradead.org, Liam.Howlett@oracle.com, jannh@google.com, zhangpeng362@huawei.com, bgeffon@google.com, kaleshsingh@google.com, ngeoffray@google.com, jdduke@google.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kernel-team@android.com, Peter Zijlstra Subject: Re: [PATCH v6 5/5] selftests/mm: add UFFDIO_MOVE ioctl test Content-Language: en-US To: John Hubbard , Mark Brown References: <50385948-5eb4-47ea-87f8-add4265933d6@redhat.com> <6a34b0c9-e084-4928-b239-7af01c8d4479@sirena.org.uk> <3240f4b5-081b-4075-851a-7d1cd86f4333@redhat.com> <3eadd79c-c02a-495f-92c0-0315046ef59f@nvidia.com> <3d22f342-280f-4a44-87f4-8cca291cfce7@sirena.org.uk> <0f97db9c-5b86-4f56-8463-2520fe79f709@sirena.org.uk> From: Muhammad Usama Anjum In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0686F40006 X-Stat-Signature: htgecp1p981wssiu1rx3fpnhfoihb9th X-HE-Tag: 1702439899-198162 X-HE-Meta: U2FsdGVkX18/XnpnAEu6bpLtA4nghGVl/oYj9C7MJboRHNZmaY2y3V8K6mjiS4lUK3LlqoSCWnyNSghNOicxojqc5d4jQtY7Op7itUu1VFA0UsZDh011z8AIEPu4uDsZuDBfvcuFAcH5A9sPd5gRrZ1IV3vAvUFWK7JENNcFYxXl7qMFTemXfe/ggwEbmV1IUcszz7UrCNz/gzvx5vDYpiaKcDIn4Yp3I4DmpMjrekmt5nt134GF5d/SbW6aNNNp/ZKwxk1KnELvmpZoV02XbtGC7aayG2as9rDGGPgI4a2yNSEo5UIzGnD8HdlNg3ek89wqAuZVvA6JGfNm9RcnJ2H4FEfQIvP0pv4BHfPcGSh97tRqb87UaBcF9NAtLUFjhnbyDC1pQkxT80775D3q0svKppfb41k+FvAb5bQ9TIZFTJ3wBvfOD2/oeyPtMGHOdcxl5ip/2XIk3/2LbMieacoq5V7G8M9eUoh/kDeMDC7LBMhcNaiy5sBZ9tjZdShB+XXxlHIr0xEXAStraMWWk7uc+aK1VGWm7bY7uzfekSDvc2nKA0DOn9BKTuC3p5Zs9mXEtsQqr9d2kTsRKEAqmhIeGMSQ9/N3JPtWvXrFFFVwGNYl5Z19h2LYssNnEoQhzF/1I2vSE36jRO1/Joeg15KqhyIQajvOBeXDlL3bdn92Puaj2lSX/c6hF+SBFedZgNc5N6DWzCRQo8t8WBR6Z8VP6sn9MshzMjirqUQp9+9arYQ0qUuzvmYQT6R22iufN3Z+HdrohZpOygTFIz0MiT96isB0u7vvMyRod7aUQo+/aTQ4GlGziaGlJTBynvosPzMpN47v0HSISxnD4uqEJNYynDe7GfIqqpVZkiYqNMjrroV0pAcfrYW0E86akQNLIG7uC0/hmuuNEKJ9wqJ7efWDFhY1OesiO2fMWTSXtk8DQjuBepW8oMMV4MyxJtXqnrmM1V0vOcGjylm8xjr xTsCZQp3 keymufpyWYvpXvOiY7RGioa25ggnpBXYWDf0R+JmCVmFLk0m9aWrI7bcjK1k1dBUU1R58zljH5e+bxqSg7NG5NENRwe0bccq28JrMolSSJyBYNv/PpJzclXFXjNyXAo+QLrp4VR4wupl/xlxgllLiUyNnPOxTsVcP0l2dd4hhr3s+z8EYMfrx9ChQLyPxxuHpnYuJde2nlfawCcc5Bb2APEFxyuH+iiFXaiagnV+CTpWWl8X0kZ+Gv6cGWLNZErI7DpqswUmz0tgJOyhDzTSwqiZ47Wk20xDHtGCb4U02uvb5AMgqhNfppYOjjAZWbkijXwXPxmycSELFN3+rajTc3NKiT6kumQYFEvEA0p3XSEh7yGiEKJ3r2fFAT0StADuAuEjO X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 12/13/23 7:14 AM, John Hubbard wrote: > On 12/12/23 07:12, Mark Brown wrote: >> On Mon, Dec 11, 2023 at 12:29:58PM -0800, John Hubbard wrote: >>> On 12/11/23 12:21, Mark Brown wrote: > ... >>> Or maybe there is an innovative way to do all of this, that we have >>> yet to think of. >> >> We do copy files into tools/include at random times which makes sense >> for things that aren't uapi, and we are putting bits of uapi there >> already so we could just expand the set of files copied there.  AFAICT >> the only reason we're copying the uapi files at all is that they're >> directly in the same include/ directories as everything else and are >> always referenced with their uapi/ prefix. > > Oh, this sounds like it would work nicely. No more "make headers" > required (hooray!). Instead, the new approach would be "selftests are > allowed to include from tools/include", and then we can just start > copying the files that we need to that location, and gradually fix up > all the selftests. No, this wouldn't work. * The selftests are applications which include default header files. The application don't care from where the header files are picked up at compile time. We should be able to build the application on normal system with latest headers installed without any changes. * The header files cannot be included directly as they need to be processed first which is done by `make headers`. Here is a diff between kernel fs.h and processed header file to be used by applications: --- include/uapi/linux/fs.h 2023-12-12 14:45:22.857409660 +0500 +++ usr/include/linux/fs.h 2023-12-12 14:49:23.469733573 +0500 @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -#ifndef _UAPI_LINUX_FS_H -#define _UAPI_LINUX_FS_H +#ifndef _LINUX_FS_H +#define _LINUX_FS_H /* * This file has definitions for some important file table structures @@ -13,14 +13,10 @@ #include #include #include -#ifndef __KERNEL__ #include -#endif /* Use of MS_* flags within the kernel is restricted to core mount(2) code. */ -#if !defined(__KERNEL__) #include -#endif /* * It's silly to have NR_OPEN bigger than NR_FILE, but you can change @@ -287,19 +283,19 @@ typedef int __bitwise __kernel_rwf_t; /* high priority request, poll if possible */ -#define RWF_HIPRI ((__force __kernel_rwf_t)0x00000001) +#define RWF_HIPRI ((__kernel_rwf_t)0x00000001) /* per-IO O_DSYNC */ -#define RWF_DSYNC ((__force __kernel_rwf_t)0x00000002) +#define RWF_DSYNC ((__kernel_rwf_t)0x00000002) /* per-IO O_SYNC */ -#define RWF_SYNC ((__force __kernel_rwf_t)0x00000004) +#define RWF_SYNC ((__kernel_rwf_t)0x00000004) /* per-IO, return -EAGAIN if operation would block */ -#define RWF_NOWAIT ((__force __kernel_rwf_t)0x00000008) +#define RWF_NOWAIT ((__kernel_rwf_t)0x00000008) /* per-IO O_APPEND */ -#define RWF_APPEND ((__force __kernel_rwf_t)0x00000010) +#define RWF_APPEND ((__kernel_rwf_t)0x00000010) /* mask of flags supported by the kernel */ #define RWF_SUPPORTED (RWF_HIPRI | RWF_DSYNC | RWF_SYNC | RWF_NOWAIT |\ @@ -364,4 +360,4 @@ __u64 return_mask; }; -#endif /* _UAPI_LINUX_FS_H */ +#endif /* _LINUX_FS_H */ > > I really like this, at first reading anyway. > > Muhammad, Shuah, others, what do you think? > > +Cc: Muhammad Usama Anjum > > > thanks, -- BR, Muhammad Usama Anjum