From: "Darrick J. Wong" <djwong@kernel.org>
To: xfs <linux-xfs@vger.kernel.org>
Cc: info@mobile-stream.com,
Fabrice Fontaine <fontaine.fabrice@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>
Subject: [RFC PATCH] libxfs: stop overriding MAP_SYNC in publicly exported header files
Date: Wed, 20 Jul 2022 16:28:00 -0700 [thread overview]
Message-ID: <YtiPgDT3imEyU2aF@magnolia> (raw)
Can one of you please apply this patch and see if it'll build in musl on
mips, please? Sorry it's taken so long to address this. :/
--D
---
From: Darrick J. Wong <djwong@kernel.org>
Florian Fainelli most recently reported that xfsprogs doesn't build with
musl on mips:
"MIPS platforms building with recent kernel headers and the musl-libc
toolchain will expose the following build failure:
mmap.c: In function 'mmap_f':
mmap.c:196:12: error: 'MAP_SYNC' undeclared (first use in this function); did you mean 'MS_SYNC'?
196 | flags = MAP_SYNC | MAP_SHARED_VALIDATE;
| ^~~~~~~~
| MS_SYNC
mmap.c:196:12: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [../include/buildrules:81: mmap.o] Error 1"
At first glance, the build failure here is caused by the fact that:
1. The configure script doesn't detect MAP_SYNC support
2. The build system doesn't set HAVE_MAP_SYNC
2. io/mmap.c includes input.h -> projects.h -> xfs.h and later sys/mman.h
3. include/linux.h #define's MAP_SYNC to 0 if HAVE_MAP_SYNC is not set
4. musl's sys/mman.h #undef MAP_SYNC on platforms that don't support it
5. io/mmap.c tries to use MAP_SYNC, not realizing that libc undefined it
Normally, xfs_io only exports functionality that is defined by the libc
and/or kernel headers on the build system. We often make exceptions for
new functionality so that we have a way to test them before the header
file packages catch up, hence this '#ifndef HAVE_FOO #define FOO'
paradigm.
MAP_SYNC is a gross and horribly broken example of this. These support
crutches are supposed to be *private* to xfsprogs for benefit of early
testing, but they were instead added to include/linux.h, which we
provide to user programs in the xfslibs-dev package. IOWs, we've been
#defining MAP_SYNC to zero for unsuspecting programs.
Worst yet, gcc 11.3 doesn't even warn about overriding a #define to 0:
#include <stdio.h>
#include <sys/mman.h>
#ifdef STUPID
# include <xfs/xfs.h>
#endif
int main(int argc, char *argv[]) {
printf("MAP_SYNC 0x%x\n", MAP_SYNC);
}
$ gcc -o a a.c -Wall
$ ./a
MAP_SYNC 0x80000
$ gcc -DSTUPID -o a a.c -Wall
$ ./a
MAP_SYNC 0x0
Four years have gone by since the introduction of MAP_SYNC, so let's get
rid of the override code entirely -- any platform that supports MAP_SYNC
has had plenty of chances to ensure their header files have the right
bits. While we're at it, fix AC_HAVE_MAP_SYNC to look for MAP_SYNC in
the same header file that the one user (io/mmap.c) uses -- sys/mman.h.
Annoyingly, I had to test this by hand because the sole fstest that
exercises MAP_SYNC (generic/470) requires dm-logwrites and dm-thinp,
neither of which support fsdax on current kernels.
Reported-by: info@mobile-stream.com
Reported-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
include/linux.h | 8 --------
io/io.h | 2 +-
io/mmap.c | 25 +++++++++++++------------
m4/package_libcdev.m4 | 3 +--
4 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/include/linux.h b/include/linux.h
index 3d9f4e3d..eddc4ad9 100644
--- a/include/linux.h
+++ b/include/linux.h
@@ -251,14 +251,6 @@ struct fsxattr {
#define FS_XFLAG_COWEXTSIZE 0x00010000 /* CoW extent size allocator hint */
#endif
-#ifndef HAVE_MAP_SYNC
-#define MAP_SYNC 0
-#define MAP_SHARED_VALIDATE 0
-#else
-#include <asm-generic/mman.h>
-#include <asm-generic/mman-common.h>
-#endif /* HAVE_MAP_SYNC */
-
/*
* Reminder: anything added to this file will be compiled into downstream
* userspace projects!
diff --git a/io/io.h b/io/io.h
index ada0a149..de4ef607 100644
--- a/io/io.h
+++ b/io/io.h
@@ -58,7 +58,7 @@ typedef struct mmap_region {
size_t length; /* length of mapping */
off64_t offset; /* start offset into backing file */
int prot; /* protection mode of the mapping */
- bool map_sync; /* is this a MAP_SYNC mapping? */
+ int flags; /* MAP_* flags passed to mmap() */
char *name; /* name of backing file */
} mmap_region_t;
diff --git a/io/mmap.c b/io/mmap.c
index 8c048a0a..425957d4 100644
--- a/io/mmap.c
+++ b/io/mmap.c
@@ -46,8 +46,11 @@ print_mapping(
for (i = 0, p = pflags; p->prot != PROT_NONE; i++, p++)
buffer[i] = (map->prot & p->prot) ? p->mode : '-';
- if (map->map_sync)
+#ifdef HAVE_MAP_SYNC
+ if ((map->flags & (MAP_SYNC | MAP_SHARED_VALIDATE)) ==
+ (MAP_SYNC | MAP_SHARED_VALIDATE))
sprintf(&buffer[i], " S");
+#endif
printf("%c%03d%c 0x%lx - 0x%lx %s %14s (%lld : %ld)\n",
braces? '[' : ' ', index, braces? ']' : ' ',
@@ -139,7 +142,9 @@ mmap_help(void)
" -r -- map with PROT_READ protection\n"
" -w -- map with PROT_WRITE protection\n"
" -x -- map with PROT_EXEC protection\n"
+#ifdef HAVE_MAP_SYNC
" -S -- map with MAP_SYNC and MAP_SHARED_VALIDATE flags\n"
+#endif
" -s <size> -- first do mmap(size)/munmap(size), try to reserve some free space\n"
" If no protection mode is specified, all are used by default.\n"
"\n"));
@@ -193,18 +198,14 @@ mmap_f(
prot |= PROT_EXEC;
break;
case 'S':
+#ifdef HAVE_MAP_SYNC
flags = MAP_SYNC | MAP_SHARED_VALIDATE;
-
- /*
- * If MAP_SYNC and MAP_SHARED_VALIDATE aren't defined
- * in the system headers we will have defined them
- * both as 0.
- */
- if (!flags) {
- printf("MAP_SYNC not supported\n");
- return 0;
- }
break;
+#else
+ printf("MAP_SYNC not supported\n");
+ exitcode = 1;
+ return command_usage(&mmap_cmd);
+#endif
case 's':
length2 = cvtnum(blocksize, sectsize, optarg);
break;
@@ -281,7 +282,7 @@ mmap_f(
mapping->offset = offset;
mapping->name = filename;
mapping->prot = prot;
- mapping->map_sync = (flags == (MAP_SYNC | MAP_SHARED_VALIDATE));
+ mapping->flags = flags;
return 0;
}
diff --git a/m4/package_libcdev.m4 b/m4/package_libcdev.m4
index df44174d..5293dd1a 100644
--- a/m4/package_libcdev.m4
+++ b/m4/package_libcdev.m4
@@ -387,8 +387,7 @@ AC_DEFUN([AC_HAVE_MAP_SYNC],
[ AC_MSG_CHECKING([for MAP_SYNC])
AC_COMPILE_IFELSE(
[ AC_LANG_PROGRAM([[
-#include <asm-generic/mman.h>
-#include <asm-generic/mman-common.h>
+#include <sys/mman.h>
]], [[
int flags = MAP_SYNC | MAP_SHARED_VALIDATE;
]])
next reply other threads:[~2022-07-20 23:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <WVSe_1J22WBxe1bXs0u1-LcME14brH0fGDu5RCt5eBvqFJCSvxxAEPHIObGT4iqkEoCCZv4vpOzGZSrLjg8gcQ==@protonmail.internalid>
2022-07-20 23:28 ` Darrick J. Wong [this message]
2022-07-21 3:29 ` [RFC PATCH] libxfs: stop overriding MAP_SYNC in publicly exported header files Florian Fainelli
2022-07-21 12:11 ` Carlos Maiolino
2022-07-28 22:29 ` Florian Fainelli
2022-07-29 15:48 ` Darrick J. Wong
2022-08-05 2:11 ` Eric Sandeen
2022-08-08 17:13 ` Florian Fainelli
2022-08-08 17:36 ` Darrick J. Wong
2022-08-08 17:37 ` Florian Fainelli
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=YtiPgDT3imEyU2aF@magnolia \
--to=djwong@kernel.org \
--cc=f.fainelli@gmail.com \
--cc=fontaine.fabrice@gmail.com \
--cc=info@mobile-stream.com \
--cc=linux-xfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox