| Message ID | 20130813154958.7514d525@marga.jer-c2.orkz.net (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Headers | show |
On 08/13/2013 03:49 PM, Jeroen Roovers wrote: > Trying out systemd I found that libc 2.17 does not build > fanotify_mark() support[1]. When I got it to do that (see attached > patch, which is probably incorrect), calls to fanotify_mark() still > failed on a C8000 (64-bit kernel). I am sure I am missing something > obvious. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=480268 In the Linux kernel we use the compat layer for 32bit syscalls on 64bit kernel: arch/parisc/kernel/syscall_table.S: ENTRY_COMP(fanotify_mark) which means we call (with 32bit userspace on 64bit kernel): fs/notify/fanotify/fanotify_user.c:COMPAT_SYSCALL_DEFINE6(fanotify_mark, int, fanotify_fd, unsigned int, flags, __u32, mask0, __u32, mask1, int, dfd, const char __user *, pathname) which has 6 parameters. So, I assume you need one more "i" in this line here (change i:iiiis -> i:iiiiis {to 5 i's}): > +fanotify_mark EXTRA fanotify_mark i:iiiis __fanotify_mark fanotify_mark@@GLIBC_2.17 Just an assumption... Helge -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 13 Aug 2013 23:29:42 +0200 Helge Deller <deller@gmx.de> wrote: > > [1] https://bugs.gentoo.org/show_bug.cgi?id=480268 > > In the Linux kernel we use the compat layer for 32bit syscalls on > 64bit kernel: arch/parisc/kernel/syscall_table.S: > ENTRY_COMP(fanotify_mark) which means we call (with 32bit userspace > on 64bit kernel): > fs/notify/fanotify/fanotify_user.c:COMPAT_SYSCALL_DEFINE6(fanotify_mark, > int, fanotify_fd, unsigned int, flags, __u32, mask0, __u32, mask1, > int, dfd, const char __user *, pathname) which has 6 parameters. > > So, I assume you need one more "i" in this line here (change i:iiiis > -> i:iiiiis {to 5 i's}): I tried that too with a similarly bad result (I forgot to keep a binary tarball of the packages glibc for easy switching, and I didn't keep the strace output of the first attempt either). As noted on the bug report. The bug report lists the relevant strace output of the delightfully simple implementation of fanotify_mark in the fatrace[1] tool as well: # grep fanotif fatrace.strace 361 fanotify_init(0, 0) = 3 361 fanotify_mark(0x3, 0x11, 0x4800003b, 0, 0xffffff9c) = -1 EINVAL (Invalid argument) I have since tried with a 32-bit kernel on a C3600, and there I get a different one: # grep fanotif fatrace.strace 2810 fanotify_init(0, 0) = 3 2810 fanotify_mark(0x3, 0x11, 0x4800003b, 0, 0xffffff9c) = -1 EBADF (Bad file descriptor) jer [1] https://launchpad.net/fatrace -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 14 Aug 2013 00:54:00 +0200 Jeroen Roovers <jer@gentoo.org> wrote: > On Tue, 13 Aug 2013 23:29:42 +0200 > Helge Deller <deller@gmx.de> wrote: > > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=480268 > > > > In the Linux kernel we use the compat layer for 32bit syscalls on > > 64bit kernel: arch/parisc/kernel/syscall_table.S: > > ENTRY_COMP(fanotify_mark) which means we call (with 32bit userspace > > on 64bit kernel): > > fs/notify/fanotify/fanotify_user.c:COMPAT_SYSCALL_DEFINE6(fanotify_mark, > > int, fanotify_fd, unsigned int, flags, __u32, mask0, __u32, mask1, > > int, dfd, const char __user *, pathname) which has 6 parameters. > > > > So, I assume you need one more "i" in this line here (change i:iiiis > > -> i:iiiiis {to 5 i's}): > > I tried that too with a similarly bad result After the 5 i patch =and= recompiling fatrace, fanotify_mark() now works properly. Which brings me no closer to systemd support on HPPA, I'm afraid, but at least systemd now installs properly. I'm working on writing up another e-mail about the next hurdle[1] systemd presents us. jer [1] Sneak preview: https://bugs.gentoo.org/show_bug.cgi?id=482214 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/26/2013 01:46 AM, Jeroen Roovers wrote: > On Wed, 14 Aug 2013 00:54:00 +0200 > Jeroen Roovers <jer@gentoo.org> wrote: > >> On Tue, 13 Aug 2013 23:29:42 +0200 >> Helge Deller <deller@gmx.de> wrote: >> >>>> [1] https://bugs.gentoo.org/show_bug.cgi?id=480268 >>> >>> In the Linux kernel we use the compat layer for 32bit syscalls on >>> 64bit kernel: arch/parisc/kernel/syscall_table.S: >>> ENTRY_COMP(fanotify_mark) which means we call (with 32bit userspace >>> on 64bit kernel): >>> fs/notify/fanotify/fanotify_user.c:COMPAT_SYSCALL_DEFINE6(fanotify_mark, >>> int, fanotify_fd, unsigned int, flags, __u32, mask0, __u32, mask1, >>> int, dfd, const char __user *, pathname) which has 6 parameters. >>> >>> So, I assume you need one more "i" in this line here (change i:iiiis >>> -> i:iiiiis {to 5 i's}): >> >> I tried that too with a similarly bad result > > After the 5 i patch =and= recompiling fatrace, fanotify_mark() now works > properly. Great! I didn't checked, but will the "5 i" work on 32bit too? Don't think so... > Which brings me no closer to systemd support on HPPA, I'm > afraid, but at least systemd now installs properly. I'm working on > writing up another e-mail about the next hurdle[1] systemd presents us. > [1] Sneak preview: https://bugs.gentoo.org/show_bug.cgi?id=482214 Did you already filed this signal-problem upstream as suggested in comment #3 (https://bugs.gentoo.org/show_bug.cgi?id=482214#c3)? Helge -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 26-Aug-13, at 5:27 PM, Helge Deller wrote: >> Which brings me no closer to systemd support on HPPA, I'm >> afraid, but at least systemd now installs properly. I'm working on >> writing up another e-mail about the next hurdle[1] systemd presents >> us. >> [1] Sneak preview: https://bugs.gentoo.org/show_bug.cgi?id=482214 > > Did you already filed this signal-problem upstream as suggested in > comment #3 (https://bugs.gentoo.org/show_bug.cgi?id=482214#c3)? I believe two of the signal numbers come from HP-UX. Dave -- John David Anglin dave.anglin@bell.net -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 26 Aug 2013 23:27:39 +0200 Helge Deller <deller@gmx.de> wrote: > > After the 5 i patch =and= recompiling fatrace, fanotify_mark() now > > works properly. > > Great! > I didn't checked, but will the "5 i" work on 32bit too? Don't think > so... Yes, that works too. jer -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 26 Aug 2013 18:37:54 -0400 John David Anglin <dave.anglin@bell.net> wrote: > On 26-Aug-13, at 5:27 PM, Helge Deller wrote: > >> [1] Sneak preview: https://bugs.gentoo.org/show_bug.cgi?id=482214 > > > > Did you already filed this signal-problem upstream as suggested in > > comment #3 (https://bugs.gentoo.org/show_bug.cgi?id=482214#c3)? Well, there are two ways to resolve this problem, and seeing who is developing systemd and seeing the generous way the "available" signal range is used, I'm pretty doubtful about changes there. As I said in comment #2, that range could be compacted (a lot) and then fit easily on any future platform. Since it was a design choice even reflected in man pages[1] ("[...], SIGRTMIN+29 Sets the log level to [...]"), I'm very afraid they will not change it easily. > I believe two of the signal numbers come from HP-UX. #define SIGXCPU 33 #define SIGXFSZ 34 #define SIGSTKFLT 36 According to [2], SIGSTKFLT isn't used. Do we still support HP-UX? I have never seen a binary for it I could try with, but then maybe I never went looking for one, either. :) jer [1] http://www.freedesktop.org/software/systemd/man/systemd.html [2] http://h21007.www2.hp.com/portal/download/files/unprot/STK/Linux_STK/impacts/i60.html -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 8/27/2013 10:46 AM, Jeroen Roovers wrote: > On Mon, 26 Aug 2013 18:37:54 -0400 > John David Anglin <dave.anglin@bell.net> wrote: > >> On 26-Aug-13, at 5:27 PM, Helge Deller wrote: >>>> [1] Sneak preview: https://bugs.gentoo.org/show_bug.cgi?id=482214 >>> Did you already filed this signal-problem upstream as suggested in >>> comment #3 (https://bugs.gentoo.org/show_bug.cgi?id=482214#c3)? > Well, there are two ways to resolve this problem, and seeing who is > developing systemd and seeing the generous way the "available" signal > range is used, I'm pretty doubtful about changes there. > > As I said in comment #2, that range could be compacted (a lot) and then > fit easily on any future platform. Since it was a design choice even > reflected in man pages[1] ("[...], SIGRTMIN+29 Sets the log level to > [...]"), I'm very afraid they will not change it easily. > >> I believe two of the signal numbers come from HP-UX. > #define SIGXCPU 33 > #define SIGXFSZ 34 The signal numbers for these two signals come from HP-UX but the signals are used by Linux, so I can't see how they can change. > #define SIGSTKFLT 36 > > According to [2], SIGSTKFLT isn't used. This signal isn't used by HP-UX but it is used by Linux, so again this can't change. Can we change _NSIG to 69 so there are 32 RT signals as on other arches? > > Do we still support HP-UX? I have never seen a binary for it I could > try with, but then maybe I never went looking for one, either. :) Doesn't really matter... > > > jer > > > [1] http://www.freedesktop.org/software/systemd/man/systemd.html > [2] > http://h21007.www2.hp.com/portal/download/files/unprot/STK/Linux_STK/impacts/i60.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-parisc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >
On 8/27/2013 11:26 AM, John David Anglin wrote:
> Can we change _NSIG to 69 so there are 32 RT signals as on other arches?
It looks like it needs to be a power of 2. MIPS uses 128.
Dave
On 08/27/2013 05:26 PM, John David Anglin wrote: > On 8/27/2013 10:46 AM, Jeroen Roovers wrote: >> On Mon, 26 Aug 2013 18:37:54 -0400 John David Anglin >> <dave.anglin@bell.net> wrote: >> >>> On 26-Aug-13, at 5:27 PM, Helge Deller wrote: >>>>> [1] Sneak preview: >>>>> https://bugs.gentoo.org/show_bug.cgi?id=482214 >>>> Did you already filed this signal-problem upstream as suggested >>>> in comment #3 >>>> (https://bugs.gentoo.org/show_bug.cgi?id=482214#c3)? >> Well, there are two ways to resolve this problem, and seeing who >> is developing systemd and seeing the generous way the "available" >> signal range is used, I'm pretty doubtful about changes there. I can see why they wouldn't like to change this again. It might break systemd binaries on other existing arches which already support systemd. Anyway, has there been any further upstream discussion? >> As I said in comment #2, that range could be compacted (a lot) and >> then fit easily on any future platform. Since it was a design >> choice even reflected in man pages[1] ("[...], SIGRTMIN+29 Sets >> the log level to [...]"), I'm very afraid they will not change it >> easily. >> >>> I believe two of the signal numbers come from HP-UX. >> #define SIGXCPU 33 #define SIGXFSZ 34 > The signal numbers for these two signals come from HP-UX but the > signals are used by Linux, so I can't see how they can change. >> #define SIGSTKFLT 36 >> >> According to [2], SIGSTKFLT isn't used. > This signal isn't used by HP-UX but it is used by Linux, so again > this can't change. changing those would break our binary compatibility... > Can we change _NSIG to 69 so there are 32 RT signals as on other > arches? [Dave followup]: It looks like it needs to be a power of 2. > MIPS uses 128. 127 seems to be the better choice then... (signal #128 seems to conflict with the core dump bit) So, how should we proceed here? If I haven't overlooked something, it seems that changing the parisc kernel & glibc is possible. Downside is, that people of course need newer kernel/glibc and at least systemd recompiled. Another downside is that we add more overhead in the signal paths, but I'm not sure if this really hurts performance (is signal handling performance-relevant at all?). I can come up with a kernel/glibc patch (which seem to be trivial) if we agree to really go that way... Helge >> [1] http://www.freedesktop.org/software/systemd/man/systemd.html >> [2] >> http://h21007.www2.hp.com/portal/download/files/unprot/STK/Linux_STK/impacts/i60.html -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Regarding _NSIG, I realized after I wrote that the number has to be divisible by 64 because of the way various words are allocated (one bit per signal). There is no roundup in the allocation. We need to tweak the RT max value so we at least 32 RT signals. This should keep userspace happy. This will leave a whole bunch of numbers free. So, probably there wouldn't be a conflict with the core dump bit. I had the sense the glibc doesn't need to change because of the way POSIX specifies the number of available realtime signals. Dave On 9/18/2013 2:40 PM, Helge Deller wrote: > On 08/27/2013 05:26 PM, John David Anglin wrote: >> On 8/27/2013 10:46 AM, Jeroen Roovers wrote: >>> On Mon, 26 Aug 2013 18:37:54 -0400 John David Anglin >>> <dave.anglin@bell.net> wrote: >>> >>>> On 26-Aug-13, at 5:27 PM, Helge Deller wrote: >>>>>> [1] Sneak preview: >>>>>> https://bugs.gentoo.org/show_bug.cgi?id=482214 >>>>> Did you already filed this signal-problem upstream as suggested >>>>> in comment #3 >>>>> (https://bugs.gentoo.org/show_bug.cgi?id=482214#c3)? >>> Well, there are two ways to resolve this problem, and seeing who >>> is developing systemd and seeing the generous way the "available" >>> signal range is used, I'm pretty doubtful about changes there. > I can see why they wouldn't like to change this again. > It might break systemd binaries on other existing arches which already > support systemd. > > Anyway, has there been any further upstream discussion? > >>> As I said in comment #2, that range could be compacted (a lot) and >>> then fit easily on any future platform. Since it was a design >>> choice even reflected in man pages[1] ("[...], SIGRTMIN+29 Sets >>> the log level to [...]"), I'm very afraid they will not change it >>> easily. >>> >>>> I believe two of the signal numbers come from HP-UX. >>> #define SIGXCPU 33 #define SIGXFSZ 34 >> The signal numbers for these two signals come from HP-UX but the >> signals are used by Linux, so I can't see how they can change. >>> #define SIGSTKFLT 36 >>> >>> According to [2], SIGSTKFLT isn't used. >> This signal isn't used by HP-UX but it is used by Linux, so again >> this can't change. > changing those would break our binary compatibility... > >> Can we change _NSIG to 69 so there are 32 RT signals as on other >> arches? [Dave followup]: It looks like it needs to be a power of 2. >> MIPS uses 128. > 127 seems to be the better choice then... (signal #128 seems to conflict with > the core dump bit) > > So, how should we proceed here? > If I haven't overlooked something, it seems that changing the parisc kernel > & glibc is possible. > Downside is, that people of course need newer kernel/glibc and at least > systemd recompiled. > Another downside is that we add more overhead in the signal paths, but I'm not > sure if this really hurts performance (is signal handling performance-relevant > at all?). > > I can come up with a kernel/glibc patch (which seem to be trivial) if we agree > to really go that way... > > Helge > >>> [1] http://www.freedesktop.org/software/systemd/man/systemd.html >>> [2] >>> http://h21007.www2.hp.com/portal/download/files/unprot/STK/Linux_STK/impacts/i60.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-parisc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >
--- a/ports/sysdeps/unix/sysv/linux/hppa/syscalls.list +++ b/ports/sysdeps/unix/sysv/linux/hppa/syscalls.list @@ -36,3 +36,4 @@ setrlimit - setrlimit i:ip __setrlimit setrlimit getrlimit - getrlimit i:ip __getrlimit getrlimit prlimit64 EXTRA prlimit64 i:iipp __prlimit64 prlimit64@@GLIBC_2.17 +fanotify_mark EXTRA fanotify_mark i:iiiis __fanotify_mark fanotify_mark@@GLIBC_2.17
Trying out systemd I found that libc 2.17 does not build fanotify_mark() support[1]. When I got it to do that (see attached patch, which is probably incorrect), calls to fanotify_mark() still failed on a C8000 (64-bit kernel). I am sure I am missing something obvious. Kind regards, jer [1] https://bugs.gentoo.org/show_bug.cgi?id=480268