Bug 218571
| Summary: | umtx compat6 regression affecting 'jar' command | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Nicholas Hardison <nicholas.hardison> |
| Component: | kern | Assignee: | freebsd-threads (Nobody) <threads> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | emaste, jilles, kib, mops |
| Priority: | --- | Keywords: | patch, regression |
| Version: | 11.0-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Nicholas Hardison
2017-04-11 21:26:34 UTC
Rather than adding backwards compatibility for a 10-year obsolete version of FreeBSD to 11, why not just rebuild jdk1.5.0? It isn't practical to recompile the jdk in this environment due to its location on a shared filesystem (with a bunch of other stuff) and need to be able to continue running the 8.2 systems as I do the upgrades (a multi-stage process that happens over a period of months, during which work must go on). I started working in this freebsd environment back when it was running 4.8, and the binary compatibility has been a major selling point of FreeBSD through upgrades since then (though my regression tests don't cover product versions from that long ago - iirc we don't need it _quite_ that far back). Being able to replace the environment with new systems that can still run the old toolchains keeps me from having to keep and support my current set of 8.2 servers for X more years (they're too old as it is - ironically one of the reasons I could finally justify upgrading is the need to run a _new_ jdk). You could rebuild jdk1.5.0 on your 8.2 machines, which have the new interface, and share it with the 11 machines. FreeBSD supports a lot of backwards compatibility but a decade old obsolete interface is expecting a lot. Most of the time, freebsd6 compatibility is left in. It seems inconsistent to remove the old umtx calls if the rest is left in. It does look unfortunate to have two copies of almost-but-not-completely duplicate code added to kern_umtx.c. However, it may be the least bad way so that development of the current code is hindered as little as possible. Adding the syscall stubs and exports back to libc seems unnecessary since these calls were not supposed to be used by applications directly, and mixing libc/libthr versions is not supported. Likewise, what was removed from <sys/umtx.h> need not be restored (except as needed for kernel implementation). UMUTEX_ERROR_CHECK was added after stable/6 and never used, so need not be restored either. If the old code is dynamically linked, it is worth a try to run it with the new libc and libthr. Thanks for the pointer - it looks like my binary is dynamically linked, so I'll try making another patch in the next day or so and see if that will work. I believe I have a new patch, with the syscalls marked as COMPAT6 instead of STD, and without the libc changes, and my test case binary seems to work! On the UMUTEX_ERROR_CHECK definition - on my 8.2-RELEASE systems, it looks like it is being used in error handling for the functions in kern/kern_umtx.c, so I don't think I should get rid of it. I could try and remove it, or does that mean it should be marked compat8 instead of compat6? I have the same problem running a FreeBSD 6 version of MySQL 4.0.27. This is an application that we just need to keep running in "read only mode" for a possible tax audit - our former years old ERP system. While the mysqld does run, it clogs 1 CPU core 100%. _umtx_op(0x812a10,UMTX_OP_RESERVED0,0x1962b,0x0,0x0) ERR#45 'Operation not supported' _umtx_op(0x812a10,UMTX_OP_RESERVED0,0x1962b,0x0,0x0) ERR#45 'Operation not supported' _umtx_op(0x812a10,UMTX_OP_RESERVED0,0x1962b,0x0,0x0) ERR#45 'Operation not supported' _umtx_op(0x812a10,UMTX_OP_RESERVED0,0x1962b,0x0,0x0) ERR#45 'Operation not supported' _umtx_op(0x812a10,UMTX_OP_RESERVED0,0x1962b,0x0,0x0) ERR#45 'Operation not supported' _umtx_op(0x812a10,UMTX_OP_RESERVED0,0x1962b,0x0,0x0) ERR#45 'Operation not supported' If we have something like COMPAT_FREEBSD6 as a supported feature, why are parts of syscalls removed? FreeBSD 12.2 for me - I threw the entire legacy database server in a jail. Which works apart from the CPU usage. Kind regards, Patrick Works as expected in FreeBSD 10.4 - so the removal of these two operations is definitely to blame. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9b6b793bd79521edc082a89b264a30881cb65e22 commit 9b6b793bd79521edc082a89b264a30881cb65e22 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2021-07-19 15:40:38 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2021-07-28 10:21:12 +0000 Revert most of ce42e793100b460f597e4c85ec0da12e274f9394 to restore ABI compatibility for pre-10.x binaries. It restores _umtx_lock() and _umtx_unlock() syscalls, and UMTX_OP_LOCK/ UMTX_OP_UNLOCK umtx_op(2) operations. UMUTEX_ERROR_CHECK flag is left out for now, I do not think it makes a difference. PR: 218571 Reviewed by: brooks (previous version) Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D31220 sys/compat/freebsd32/syscalls.master | 6 +- sys/kern/kern_umtx.c | 446 ++++++++++++++++++++++++++++++++++- sys/kern/syscalls.master | 14 +- sys/sys/_umtx.h | 4 + sys/sys/umtx.h | 7 +- 5 files changed, 467 insertions(+), 10 deletions(-) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2fb281fa02d34b31b25e949415cfda4549b5aa6b commit 2fb281fa02d34b31b25e949415cfda4549b5aa6b Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2021-07-19 15:40:38 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2021-08-03 09:52:36 +0000 Revert most of ce42e793100b460f597e4c85ec0da12e274f9394 to restore ABI compatibility for pre-10.x binaries. It restores _umtx_lock() and _umtx_unlock() syscalls, and UMTX_OP_LOCK/ UMTX_OP_UNLOCK umtx_op(2) operations. UMUTEX_ERROR_CHECK flag is left out for now, I do not think it makes a difference. PR: 218571 Reviewed by: brooks (previous version) Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D31220 (cherry picked from commit 9b6b793bd79521edc082a89b264a30881cb65e22) sys/compat/freebsd32/syscalls.master | 6 +- sys/kern/kern_umtx.c | 446 ++++++++++++++++++++++++++++++++++- sys/kern/syscalls.master | 14 +- sys/sys/_umtx.h | 4 + sys/sys/umtx.h | 7 +- 5 files changed, 467 insertions(+), 10 deletions(-) I guess someone with the necessary superpowers should close this. Correct? Kind regards, Patrick |
