group.of.nepali.translators team mailing list archive

[Christian Ehrhardt  <1807743@xxxxxxxxxxxxxxxxxx>]

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