I agree to the case, but not fully to the fix. The old syscall definitions came in in 2007 via [1] "Update Linux kernel syscall list" (v0.10.0) The feature adding the timerfd was added in 2014 with [2] "linux-user: support timerfd_{create, gettime, settime} syscalls" (v2.2.0) using the wrong definitions.
Later this was fixed 2015 for arm [3] "linux-user/arm: Correct TARGET_NR_timerfd to TARGET_NR_timerfd_create" (v2.4.0) and for the rest 2016 in [4] "linux-user: correct timerfd_create syscall numbers" (2.6.0). No follow on fixes after that seen in upstream/master That said things are fixed in Yakkety and later. And the feature didn't exist in Trusty. So only Xenial is affected. The changes seem doable, and even if one used the old header on a backport it became the number which still is the same number. Also those headers are not meant for external use (no one links on that, and even if one would - again - it is the same number now). Old value only used in the defines: $ grep -Hrn 'TARGET_NR_timerfd\s' linux-user/sparc/syscall_nr.h:281:#define TARGET_NR_timerfd 312 linux-user/unicore32/syscall_nr.h:361:#define TARGET_NR_timerfd 350 linux-user/ppc/syscall_nr.h:322:#define TARGET_NR_timerfd 306 linux-user/sparc64/syscall_nr.h:313:#define TARGET_NR_timerfd 312 linux-user/mips/syscall_nr.h:323:#define TARGET_NR_timerfd (TARGET_NR_Linux + 318) linux-user/sh4/syscall_nr.h:326:#define TARGET_NR_timerfd 322 linux-user/m68k/syscall_nr.h:320:#define TARGET_NR_timerfd 318 linux-user/x86_64/syscall_nr.h:284:#define TARGET_NR_timerfd 283 linux-user/s390x/syscall_nr.h:246:#define TARGET_NR_timerfd 317 linux-user/i386/syscall_nr.h:327:#define TARGET_NR_timerfd 322 linux-user/mips64/syscall_nr.h:287:#define TARGET_NR_timerfd (TARGET_NR_Linux + 281) linux-user/mips64/syscall_nr.h:601:#define TARGET_NR_timerfd (TARGET_NR_Linux + 277) linux-user/alpha/syscall_nr.h:416:#define TARGET_NR_timerfd 477 That said, that LGTM - except I'd backport the official upstream fixes [3] and [4]. @Wes - would you mind outlining steps to reproduce as that is an integral part of any SRU [5] [1]: https://git.qemu.org/?p=qemu.git;a=commit;h=8dd77cca03ac6325bda61dbdb8b8a2021fe524c3 [2]: https://git.qemu.org/?p=qemu.git;a=commit;h=518343413fd311a3d95798b2c1d51853fd8d3c85 [3]: https://git.qemu.org/?p=qemu.git;a=commit;h=d82322e175d58c0c8951cbc905da1ca9ee2e008c [4]: https://git.qemu.org/?p=qemu.git;a=commit;h=93a92d3bd649cd315db47b9fb5dcb6af657cc22c [5]: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template ** Also affects: qemu (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: qemu (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: qemu (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: qemu (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: qemu (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: qemu (Ubuntu Precise) Status: New => Invalid ** Changed in: qemu (Ubuntu Trusty) Status: New => Invalid ** Changed in: qemu (Ubuntu Xenial) Status: New => Confirmed ** Changed in: qemu (Ubuntu Bionic) Status: New => Fix Released ** Changed in: qemu (Ubuntu Cosmic) Status: New => Fix Released ** Changed in: qemu (Ubuntu) Status: New => Fix Released ** Description changed: + [Impact] + + * A bad named define made timerfd_create be in the code but not + available + + * two smaller fixes to be backported from upstream that change the define + names; This will enable the timerfd_create in qemu-user + + [Test Case] + + * TODO @WES + + [Regression Potential] + + * The headers are only used internally so no outside regression should + happen. + * Even then only the names changed but the number stayed, that means even + if it would be an external ABI (it isn't) the number would be the same + * Internally the old define was only used when defining it, but not used + (see grep in comment #1) + * The one regression I could think of is software running in qemu-user + today and working by having a path like "does this have timerfd create + -> no, ok then do A", with the change this might become "-> yes, so do + B" and if that B is broken there would be a regression, but I'd + consider it unlikely since all versions after Xenials 2.5 had the new + variant and I have seen no complaints about it. + + [Other Info] + + * n/a + + + --- + QEMU erroneously fails to detect support for the timerfd_create syscall when running user-mode emulation of PowerPC targets. QEMU supports the timerfd_create syscall, but because the PowerPC target syscall header has it named "timerfd" instead of "timerfd_create", support is erroneously not enabled. This notably affects anything that uses Boost.Asio with deadline timers because it uses timerfds under the hood. I have attached a patch to fix the problem. For now I have a custom- built qemu-user-static.deb file with this fix implemented, but I would appreciate it if you could officially backport this patch to 16.04 LTS (Xenial) so our developers can use the official package repositories. -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1807743 Title: QEMU timerfd_create support on PowerPC Status in qemu package in Ubuntu: Fix Released Status in qemu source package in Precise: Invalid Status in qemu source package in Trusty: Invalid Status in qemu source package in Xenial: Confirmed Status in qemu source package in Bionic: Fix Released Status in qemu source package in Cosmic: Fix Released Bug description: [Impact] * A bad named define made timerfd_create be in the code but not available * two smaller fixes to be backported from upstream that change the define names; This will enable the timerfd_create in qemu-user [Test Case] * TODO @WES [Regression Potential] * The headers are only used internally so no outside regression should happen. * Even then only the names changed but the number stayed, that means even if it would be an external ABI (it isn't) the number would be the same * Internally the old define was only used when defining it, but not used (see grep in comment #1) * The one regression I could think of is software running in qemu-user today and working by having a path like "does this have timerfd create -> no, ok then do A", with the change this might become "-> yes, so do B" and if that B is broken there would be a regression, but I'd consider it unlikely since all versions after Xenials 2.5 had the new variant and I have seen no complaints about it. [Other Info] * n/a --- QEMU erroneously fails to detect support for the timerfd_create syscall when running user-mode emulation of PowerPC targets. QEMU supports the timerfd_create syscall, but because the PowerPC target syscall header has it named "timerfd" instead of "timerfd_create", support is erroneously not enabled. This notably affects anything that uses Boost.Asio with deadline timers because it uses timerfds under the hood. I have attached a patch to fix the problem. For now I have a custom-built qemu-user-static.deb file with this fix implemented, but I would appreciate it if you could officially backport this patch to 16.04 LTS (Xenial) so our developers can use the official package repositories. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1807743/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp