linux-kernel - Re: [PATCH v6 5/5] selftests/mm: add UFFDIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2e4a719b-f2b3-48db-99db-d96040d78b12@collabora.com>
Date:   Wed, 13 Dec 2023 08:58:06 +0500
From:   Muhammad Usama Anjum <usama.anjum@...labora.com>
To:     John Hubbard <jhubbard@...dia.com>, Mark Brown <broonie@...nel.org>
Cc:     Muhammad Usama Anjum <usama.anjum@...labora.com>,
        David Hildenbrand <david@...hat.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
        brauner@...nel.org, shuah@...nel.org, aarcange@...hat.com,
        lokeshgidra@...gle.com, peterx@...hat.com, ryan.roberts@....com,
        hughd@...gle.com, mhocko@...e.com, axelrasmussen@...gle.com,
        rppt@...nel.org, willy@...radead.org, Liam.Howlett@...cle.com,
        jannh@...gle.com, zhangpeng362@...wei.com, bgeffon@...gle.com,
        kaleshsingh@...gle.com, ngeoffray@...gle.com, jdduke@...gle.com,
        linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        kernel-team@...roid.com, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v6 5/5] selftests/mm: add UFFDIO_MOVE ioctl test

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 <linux/limits.h>
 #include <linux/ioctl.h>
 #include <linux/types.h>
-#ifndef __KERNEL__
 #include <linux/fscrypt.h>
-#endif

 /* Use of MS_* flags within the kernel is restricted to core mount(2) code. */
-#if !defined(__KERNEL__)
 #include <linux/mount.h>
-#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 <usama.anjum@...labora.com>
> 
> 
> thanks,

-- 
BR,
Muhammad Usama Anjum