Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #66701 > unrolled thread
| Started by | Thorsten Glaser <t.glaser@tarent.de> |
|---|---|
| First post | 2020-04-07 14:50 +0200 |
| Last post | 2020-04-08 16:10 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.debian.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Bug#954294: linux: __X32_SYSCALL_BIT being defined as UL constant breaks userspace (was Re: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)) Thorsten Glaser <t.glaser@tarent.de> - 2020-04-07 14:50 +0200
Bug#954294: linux: __X32_SYSCALL_BIT being defined as UL constant breaks userspace (was Re: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)) Ben Hutchings <ben@decadent.org.uk> - 2020-04-08 16:00 +0200
Bug#954294: linux: __X32_SYSCALL_BIT being defined as UL constant breaks userspace (was Re: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)) Thorsten Glaser <t.glaser@tarent.de> - 2020-04-08 16:10 +0200
| From | Thorsten Glaser <t.glaser@tarent.de> |
|---|---|
| Date | 2020-04-07 14:50 +0200 |
| Subject | Bug#954294: linux: __X32_SYSCALL_BIT being defined as UL constant breaks userspace (was Re: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)) |
| Message-ID | <zSVPY-86M-13@gated-at.bofh.it> |
Dear kernel team, libseccomp uses the __NR_* constants from <asm/unistd.h> in its macro SCMP_SYS() which is designed to return int. However, on x32 some codes return unsigned long instead, breaking this. The cause is that this… > /usr/include/x86_64-linux-gnux32/asm/unistd.h:#define __X32_SYSCALL_BIT 0x40000000UL … is OR’d into the numbers. I’d like to propose the change… -#define __X32_SYSCALL_BIT 0x40000000UL +#define __X32_SYSCALL_BIT 0x40000000 … which should be safe to do as the number fits into signed int, but must be checked against other users (especially in the kernel itself I’d guess). This should also technically be correct, since on all(?) other architectures syscall numbers are int constants. Please forward this to upstream. Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ********** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **********
[toc] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2020-04-08 16:00 +0200 |
| Message-ID | <zTjpg-5JD-7@gated-at.bofh.it> |
| In reply to | #66701 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, 2020-04-07 at 14:40 +0200, Thorsten Glaser wrote: > Dear kernel team, > > libseccomp uses the __NR_* constants from <asm/unistd.h> in its > macro SCMP_SYS() which is designed to return int. > > However, on x32 some codes return unsigned long instead, breaking this. > The cause is that this… > > > /usr/include/x86_64-linux-gnux32/asm/unistd.h:#define __X32_SYSCALL_BIT 0x40000000UL > > … is OR’d into the numbers. > > I’d like to propose the change… > -#define __X32_SYSCALL_BIT 0x40000000UL > +#define __X32_SYSCALL_BIT 0x40000000 > … which should be safe to do as the number fits into signed int, > but must be checked against other users (especially in the kernel > itself I’d guess). > > This should also technically be correct, since on all(?) other > architectures syscall numbers are int constants. > > Please forward this to upstream. You should not expect me to spend time talking to upstream about non- release architectures. That is way down the priority list. Ben. -- Ben Hutchings It's easier to fight for one's principles than to live up to them.
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Glaser <t.glaser@tarent.de> |
|---|---|
| Date | 2020-04-08 16:10 +0200 |
| Message-ID | <zTjyW-62i-7@gated-at.bofh.it> |
| In reply to | #66712 |
On Wed, 8 Apr 2020, Ben Hutchings wrote: > You should not expect me to spend time talking to upstream about non- > release architectures. That is way down the priority list. DevRef §5.8.3.(6) is a “must”, but you’re lucky: it turns out that this is a recent isolated change, so I can write to the persons in that commit. (Will do so in a follow-up mail, so they’re not confu‐ sed by Debian specifics.) The rationale for DevRef §5.8.3.(6) is that I, as user, would not know whom to contact on the upstream side: especially with the Linux kernel, there’s tons of maintainers, subsystems, mailing lists, etc. and I’d not have an idea where to contact. (Luckily, I *was* able to isolate it… this time. But I expect you to do at least the talking, generally.) bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ********** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **********
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web