* [PATCH] xfs_io: Make HAVE_MAP_SYNC more robust
@ 2022-07-20 20:53 Florian Fainelli
2022-07-20 21:32 ` Darrick J. Wong
0 siblings, 1 reply; 4+ messages in thread
From: Florian Fainelli @ 2022-07-20 20:53 UTC (permalink / raw)
To: linux-xfs; +Cc: ross.zwisler, david, darrick.wong, sandeen, Florian Fainelli
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
The reason for that is that the linux.h header file which intends to provide a fallback definition for MAP_SYNC and MAP_SHARED_VALIDATE is included too early through:
input.h -> libfrog/projects.h -> xfs.h -> linux.h and this happens
*before* sys/mman.h is included.
sys/mman.h -> bits/mman.h which has a:
#undef MAP_SYNC
see: https://git.musl-libc.org/cgit/musl/tree/arch/mips/bits/mman.h#n21
The end result is that sys/mman.h being included for the first time
ends-up overriding the HAVE_MAP_SYNC fallbacks.
To remedy that, make sure that linux.h is updated to include sys/mman.h
such that its fallbacks are independent of the inclusion order. As a
consequence this forces us to ensure that we do not re-define
accidentally MAP_SYNC or MAP_SHARED_VALIDATE so we protect against that.
Fixes: dad796834cb9 ("xfs_io: add MAP_SYNC support to mmap()")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
include/linux.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux.h b/include/linux.h
index 3d9f4e3dca80..c3cc8e30c677 100644
--- a/include/linux.h
+++ b/include/linux.h
@@ -252,8 +252,13 @@ struct fsxattr {
#endif
#ifndef HAVE_MAP_SYNC
+#include <sys/mman.h>
+#ifndef MAP_SYNC
#define MAP_SYNC 0
+#endif
+#ifndef MAP_SHARED_VALIDATE
#define MAP_SHARED_VALIDATE 0
+#endif
#else
#include <asm-generic/mman.h>
#include <asm-generic/mman-common.h>
--
2.25.1
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] xfs_io: Make HAVE_MAP_SYNC more robust 2022-07-20 20:53 [PATCH] xfs_io: Make HAVE_MAP_SYNC more robust Florian Fainelli @ 2022-07-20 21:32 ` Darrick J. Wong 2022-07-20 21:40 ` Florian Fainelli 0 siblings, 1 reply; 4+ messages in thread From: Darrick J. Wong @ 2022-07-20 21:32 UTC (permalink / raw) To: Florian Fainelli; +Cc: linux-xfs, ross.zwisler, david, darrick.wong, sandeen On Wed, Jul 20, 2022 at 01:53:07PM -0700, Florian Fainelli wrote: > 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 Didn't we already fix this? https://lore.kernel.org/linux-xfs/20220508193029.1277260-1-fontaine.fabrice@gmail.com/ Didn't we already fix this? https://lore.kernel.org/linux-xfs/20181116162346.456255382F@mx7.valuehost.ru/ Oh, I guess the maintainer didn't apply either of these patches, so this has been broken for years. Well... MAP_SYNC has been with us for a while now, perhaps it makes more sense to remove all the override cruft and make xfs_io not export -S if if neither kernel headers nor libc define it? --D > > The reason for that is that the linux.h header file which intends to provide a fallback definition for MAP_SYNC and MAP_SHARED_VALIDATE is included too early through: > > input.h -> libfrog/projects.h -> xfs.h -> linux.h and this happens > *before* sys/mman.h is included. > > sys/mman.h -> bits/mman.h which has a: > #undef MAP_SYNC > > see: https://git.musl-libc.org/cgit/musl/tree/arch/mips/bits/mman.h#n21 > > The end result is that sys/mman.h being included for the first time > ends-up overriding the HAVE_MAP_SYNC fallbacks. > > To remedy that, make sure that linux.h is updated to include sys/mman.h > such that its fallbacks are independent of the inclusion order. As a > consequence this forces us to ensure that we do not re-define > accidentally MAP_SYNC or MAP_SHARED_VALIDATE so we protect against that. > > Fixes: dad796834cb9 ("xfs_io: add MAP_SYNC support to mmap()") > Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> > --- > include/linux.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/include/linux.h b/include/linux.h > index 3d9f4e3dca80..c3cc8e30c677 100644 > --- a/include/linux.h > +++ b/include/linux.h > @@ -252,8 +252,13 @@ struct fsxattr { > #endif > > #ifndef HAVE_MAP_SYNC > +#include <sys/mman.h> > +#ifndef MAP_SYNC > #define MAP_SYNC 0 > +#endif > +#ifndef MAP_SHARED_VALIDATE > #define MAP_SHARED_VALIDATE 0 > +#endif > #else > #include <asm-generic/mman.h> > #include <asm-generic/mman-common.h> > -- > 2.25.1 > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] xfs_io: Make HAVE_MAP_SYNC more robust 2022-07-20 21:32 ` Darrick J. Wong @ 2022-07-20 21:40 ` Florian Fainelli 2022-07-20 22:16 ` Darrick J. Wong 0 siblings, 1 reply; 4+ messages in thread From: Florian Fainelli @ 2022-07-20 21:40 UTC (permalink / raw) To: Darrick J. Wong, Fabrice Fontaine, info Cc: linux-xfs, ross.zwisler, david, darrick.wong, sandeen On 7/20/22 14:32, Darrick J. Wong wrote: > On Wed, Jul 20, 2022 at 01:53:07PM -0700, Florian Fainelli wrote: >> 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 > > Didn't we already fix this? > https://lore.kernel.org/linux-xfs/20220508193029.1277260-1-fontaine.fabrice@gmail.com/ > > Didn't we already fix this? > https://lore.kernel.org/linux-xfs/20181116162346.456255382F@mx7.valuehost.ru/ First off, I was not aware of these two proposed solutions so apologies for submitting a third (are there more) one. The common problem I see with both proposed patches is that they specifically tackle io/mmap.c when really any inclusion order of linux.h and sys/mman.h could and would lead to the the same problem to re-surface somewhere else in a different file. So sure enough there is only mmap.c now, but it has been identified that this specific include order is problematic so we ought to address it in a general way. > > Oh, I guess the maintainer didn't apply either of these patches, so this > has been broken for years. Fabrice's patch is only a few months old, and but "info@mobile-stream.com"'s is nearly 4 years old... > > Well... MAP_SYNC has been with us for a while now, perhaps it makes more > sense to remove all the override cruft and make xfs_io not export -S if > if neither kernel headers nor libc define it? Sure that would work too, but we will still end up with some MAP_SYNC conditional code, so the original intent of always defining it seemed laudable. > > --D > >> >> The reason for that is that the linux.h header file which intends to provide a fallback definition for MAP_SYNC and MAP_SHARED_VALIDATE is included too early through: >> >> input.h -> libfrog/projects.h -> xfs.h -> linux.h and this happens >> *before* sys/mman.h is included. >> >> sys/mman.h -> bits/mman.h which has a: >> #undef MAP_SYNC >> >> see: https://git.musl-libc.org/cgit/musl/tree/arch/mips/bits/mman.h#n21 >> >> The end result is that sys/mman.h being included for the first time >> ends-up overriding the HAVE_MAP_SYNC fallbacks. >> >> To remedy that, make sure that linux.h is updated to include sys/mman.h >> such that its fallbacks are independent of the inclusion order. As a >> consequence this forces us to ensure that we do not re-define >> accidentally MAP_SYNC or MAP_SHARED_VALIDATE so we protect against that. >> >> Fixes: dad796834cb9 ("xfs_io: add MAP_SYNC support to mmap()") >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> >> --- >> include/linux.h | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/include/linux.h b/include/linux.h >> index 3d9f4e3dca80..c3cc8e30c677 100644 >> --- a/include/linux.h >> +++ b/include/linux.h >> @@ -252,8 +252,13 @@ struct fsxattr { >> #endif >> >> #ifndef HAVE_MAP_SYNC >> +#include <sys/mman.h> >> +#ifndef MAP_SYNC >> #define MAP_SYNC 0 >> +#endif >> +#ifndef MAP_SHARED_VALIDATE >> #define MAP_SHARED_VALIDATE 0 >> +#endif >> #else >> #include <asm-generic/mman.h> >> #include <asm-generic/mman-common.h> >> -- >> 2.25.1 >> -- Florian ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] xfs_io: Make HAVE_MAP_SYNC more robust 2022-07-20 21:40 ` Florian Fainelli @ 2022-07-20 22:16 ` Darrick J. Wong 0 siblings, 0 replies; 4+ messages in thread From: Darrick J. Wong @ 2022-07-20 22:16 UTC (permalink / raw) To: Florian Fainelli Cc: Fabrice Fontaine, info, linux-xfs, ross.zwisler, david, darrick.wong, sandeen On Wed, Jul 20, 2022 at 02:40:33PM -0700, Florian Fainelli wrote: > On 7/20/22 14:32, Darrick J. Wong wrote: > > On Wed, Jul 20, 2022 at 01:53:07PM -0700, Florian Fainelli wrote: > >> 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 > > > > Didn't we already fix this? > > https://lore.kernel.org/linux-xfs/20220508193029.1277260-1-fontaine.fabrice@gmail.com/ > > > > Didn't we already fix this? > > https://lore.kernel.org/linux-xfs/20181116162346.456255382F@mx7.valuehost.ru/ > > First off, I was not aware of these two proposed solutions so > apologies for submitting a third (are there more) one. No worries :) > The common problem I see with both proposed patches is that they > specifically tackle io/mmap.c when really any inclusion order of > linux.h OH, yikes, this is what goes into include/linux.h (which is also exported as /usr/include/xfs/linux.h): #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 */ xfsprogs has no business exporting redefinitions of kernel symbols to userspace. This innocent looking program on an x64 system: #include <stdio.h> #include <sys/mman.h> #include <xfs/xfs.h> int main(int argc, char *argv[]) { printf("MAP_SYNC 0x%x\n", MAP_SYNC); } prints "MAP_SYNC 0x0", not the "MAP_SYNC 0x80000" that you'd expect. Ok, all this override stuff needs to die. > and sys/mman.h could and would lead to the the same problem to > re-surface somewhere else in a different file. So sure enough there is > only mmap.c now, but it has been identified that this specific include > order is problematic so we ought to address it in a general way. Exactly. > > > > Oh, I guess the maintainer didn't apply either of these patches, so this > > has been broken for years. > > Fabrice's patch is only a few months old, and but > "info@mobile-stream.com"'s is nearly 4 years old... Yep. > > > > Well... MAP_SYNC has been with us for a while now, perhaps it makes more > > sense to remove all the override cruft and make xfs_io not export -S if > > if neither kernel headers nor libc define it? > > Sure that would work too, but we will still end up with some MAP_SYNC > conditional code, so the original intent of always defining it seemed > laudable. Oh no, if I cleaned up xfs_io mmap command, I'd also get rid of the override stuff too. Working on it... --D > > > > > --D > > > >> > >> The reason for that is that the linux.h header file which intends to provide a fallback definition for MAP_SYNC and MAP_SHARED_VALIDATE is included too early through: > >> > >> input.h -> libfrog/projects.h -> xfs.h -> linux.h and this happens > >> *before* sys/mman.h is included. > >> > >> sys/mman.h -> bits/mman.h which has a: > >> #undef MAP_SYNC > >> > >> see: https://git.musl-libc.org/cgit/musl/tree/arch/mips/bits/mman.h#n21 > >> > >> The end result is that sys/mman.h being included for the first time > >> ends-up overriding the HAVE_MAP_SYNC fallbacks. > >> > >> To remedy that, make sure that linux.h is updated to include sys/mman.h > >> such that its fallbacks are independent of the inclusion order. As a > >> consequence this forces us to ensure that we do not re-define > >> accidentally MAP_SYNC or MAP_SHARED_VALIDATE so we protect against that. > >> > >> Fixes: dad796834cb9 ("xfs_io: add MAP_SYNC support to mmap()") > >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> > >> --- > >> include/linux.h | 5 +++++ > >> 1 file changed, 5 insertions(+) > >> > >> diff --git a/include/linux.h b/include/linux.h > >> index 3d9f4e3dca80..c3cc8e30c677 100644 > >> --- a/include/linux.h > >> +++ b/include/linux.h > >> @@ -252,8 +252,13 @@ struct fsxattr { > >> #endif > >> > >> #ifndef HAVE_MAP_SYNC > >> +#include <sys/mman.h> > >> +#ifndef MAP_SYNC > >> #define MAP_SYNC 0 > >> +#endif > >> +#ifndef MAP_SHARED_VALIDATE > >> #define MAP_SHARED_VALIDATE 0 > >> +#endif > >> #else > >> #include <asm-generic/mman.h> > >> #include <asm-generic/mman-common.h> > >> -- > >> 2.25.1 > >> > > > -- > Florian ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-07-20 22:16 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-07-20 20:53 [PATCH] xfs_io: Make HAVE_MAP_SYNC more robust Florian Fainelli 2022-07-20 21:32 ` Darrick J. Wong 2022-07-20 21:40 ` Florian Fainelli 2022-07-20 22:16 ` Darrick J. Wong
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox