| Summary: | hppa can't handle SIGRTMIN+29 | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Pacho Ramos <pachoramos1> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | systemd |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=482214 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Pacho Ramos
2014-10-12 09:56:31 UTC
Hmm, did I get this right? SIGRTMAX-SIGRTMIN is different for Linux on hppa than for Linux on all other archs? Yuck, what a fuck-up. The only sane solution I see is adding a patch that #ifdefs out the code that binds to the high SIGRTMIN+n signals. What's the last SIGRTMIN+n that works on hppa? Or in other words, what is SIGRTMAX-SIGRTMIN? If you let me know we'll just skip all signal assignments beyond this value on #ifdef __hppa__ Note that the signals we expose are kinda API, hence we cannot dynamically assign them. Hence checking things against SIGRTMAX and shifting things around is really not a good idea. And normally this wouldn't be a problem as on Linux/glibc the number of rt sigs should be stable and fixed. Apparently though with the exception of Linux/hppa... (In reply to Lennart Poettering from comment #1) > Hmm, did I get this right? SIGRTMAX-SIGRTMIN is different for Linux on hppa > than for Linux on all other archs? Yes. > What's the last SIGRTMIN+n that works on hppa? Or in other words, what is > SIGRTMAX-SIGRTMIN? If you let me know we'll just skip all signal assignments > beyond this value on #ifdef __hppa__ From the Gentoo bug that Pacho linked, it seems that SIGRTMIN is 39 on hppa. I assume SIGRTMAX is still 64, so that would make the difference 25. > Note that the signals we expose are kinda API, hence we cannot dynamically > assign them. Hence checking things against SIGRTMAX and shifting things > around is really not a good idea. And normally this wouldn't be a problem as > on Linux/glibc the number of rt sigs should be stable and fixed. Apparently > though with the exception of Linux/hppa... You are probably familiar, but signal(7) says: "... programs should never refer to real-time signals using hard-coded numbers, but instead should always refer to real-time signals using the notation SIGRTMIN+n, and include suitable (run-time) checks that SIGRTMIN+n does not exceed SIGRTMAX." Ideally, systemd would just use a smaller range of signals, without gaps. I also understand that shifting the signals around at this stage in development is not a very nice idea. However, you could shift them fairly safely whenever SIGRTMAX - SIGRTMIN < 29, since any such system is currently unusable anyway. I suppose that might be a bit difficult since SIGRTMIN is not a constant. (In reply to Mike Gilbert from comment #2) > (In reply to Lennart Poettering from comment #1) > > Hmm, did I get this right? SIGRTMAX-SIGRTMIN is different for Linux on hppa > > than for Linux on all other archs? > > Yes. > > > What's the last SIGRTMIN+n that works on hppa? Or in other words, what is > > SIGRTMAX-SIGRTMIN? If you let me know we'll just skip all signal assignments > > beyond this value on #ifdef __hppa__ > > From the Gentoo bug that Pacho linked, it seems that SIGRTMIN is 39 on hppa. > I assume SIGRTMAX is still 64, so that would make the difference 25. ok, will ifdef out all the signals beyond SIGRTMIN+25 then. > > Note that the signals we expose are kinda API, hence we cannot dynamically > > assign them. Hence checking things against SIGRTMAX and shifting things > > around is really not a good idea. And normally this wouldn't be a problem as > > on Linux/glibc the number of rt sigs should be stable and fixed. Apparently > > though with the exception of Linux/hppa... > > You are probably familiar, but signal(7) says: > > "... programs should never refer to real-time signals using hard-coded > numbers, but instead should always refer to real-time signals using the > notation SIGRTMIN+n, and include suitable (run-time) checks that SIGRTMIN+n > does not exceed SIGRTMAX." > > Ideally, systemd would just use a smaller range of signals, without gaps. Well, this is supposed to be a fallback interface, in case only "kill" is available. It's a safety net for the admin, not more than that. As such, it matters that the assigned signals are not dynamic, but fixed and documented. Now, I assumed that Linux would always have the same SIGRTMAX-SIGRTMIN, apparently I was wrong. This isn't too bad though, we can just ifdeff out the upper ones, the safety net is then gone on hppa, but given how exotic that platform is it shouldn't really matter. (In reply to Mike Gilbert from comment #3) > I also understand that shifting the signals around at this stage in > development is not a very nice idea. It's a documented user interface. I really have no intention to break this for an exotic platform like hppa. Especially as the interface is not really that important (see earlier comment). OK, commited this fix now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=4dffec1459f50ac9f8f67ccfcb79836b4ed5a50e This should fix builds on hppa. Of course the signals won't be available on hppa then, but I think that's OK. Please verify that things run on hppa now, as I can't test this. Thanks! Thanks a lot for your help on this :) Sorry to reopen this again; our hppa guy just pointed us at some recent kernel list traffic which proposes lowering SIGRTMIN on parisc (hppa), which would bring it in line with the other architectures. http://permalink.gmane.org/gmane.linux.ports.parisc/6172 http://permalink.gmane.org/gmane.linux.ports.parisc/6174 Definitely something to keep an eye on, and raises a good question: do you want to revert 4dffec1459f50ac9f8f67ccfcb79836b4ed5a50e, or try to do runtime detection? In any case, it should probably wait until the patch lands in Linus' tree. Hmm, are you sure they can make that change in the kernel without breaking userspace ABI? I have my doubts there... The number is exported to userspace after all, and many people specify the numeric value on "kill" command lines and such. Anyway, let's revert the systemd patch as soon as we know the kernel got changed accordingly. But until then, let's leave the change I made in. Sorry... set as NEW by mistake... please set it back to REOPENED. Sorry again! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.