* [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.