From: Christian Lamparter <chunkeey@gmail.com>
To: linux-kernel@vger.kernel.org, linux-um@lists.infradead.org
Cc: benjamin.berg@intel.com, sashal@kernel.org,
johannes@sipsolutions.net, richard@nod.at,
stable@vger.kernel.org
Subject: [PATCH 6.12] Revert "um: work around sched_yield not yielding in time-travel mode"
Date: Fri, 9 May 2025 11:50:39 +0200 [thread overview]
Message-ID: <20250509095040.33355-1-chunkeey@gmail.com> (raw)
This reverts commit 887c5c12e80c ("um: work around sched_yield not yielding in time-travel mode")
added with v6.12.25.
Reason being that the patch depends on at least
commit 0b8b2668f998 ("um: insert scheduler ticks when userspace does not yield")
in order to build. Otherwise it fails with:
| /usr/bin/ld: arch/um/kernel/skas/syscall.o: in function `handle_syscall':
| linux-6.12.27/arch/um/kernel/skas/syscall.c:43:(.text+0xa2): undefined
| reference to `tt_extra_sched_jiffies'
| collect2: error: ld returned 1 exit status
The author Benjamin Berg commented: "I think it is better to just not backport
commit 0b8b2668f998 ("um: insert scheduler ticks when userspace does not yield")
"
Link: https://lore.kernel.org/linux-um/8ce0b6056a9726e540f61bce77311278654219eb.camel@sipsolutions.net/
Cc: <stable@vger.kernel.org> # 6.12.y
Cc: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
Just in case, this throws someone else for a space-time loop:
What's interessting/very strange strange about this time-travel stuff:
|commit 0b8b2668f998 ("um: insert scheduler ticks when userspace does not yield")
$ git describe 0b8b2668f998
=> v6.12-rc2-43-g0b8b2668f998
(from what I know this is 43 patches on top of v6.12-rc2 as per the man page:
"The command finds the most recent tag that is reachable from a commit. [...]
it suffixes the tag name with the number of additional commits on top of the tagged
object and the abbreviated object name of the most recent commit."
But it was merged as part of: uml-for-linus-6.13-rc1 :
https://lore.kernel.org/lkml/1155823186.11802667.1732921581257.JavaMail.zimbra@nod.at/
---
arch/um/include/linux/time-internal.h | 2 --
arch/um/kernel/skas/syscall.c | 11 -----------
2 files changed, 13 deletions(-)
diff --git a/arch/um/include/linux/time-internal.h b/arch/um/include/linux/time-internal.h
index 138908b999d7..b22226634ff6 100644
--- a/arch/um/include/linux/time-internal.h
+++ b/arch/um/include/linux/time-internal.h
@@ -83,8 +83,6 @@ extern void time_travel_not_configured(void);
#define time_travel_del_event(...) time_travel_not_configured()
#endif /* CONFIG_UML_TIME_TRAVEL_SUPPORT */
-extern unsigned long tt_extra_sched_jiffies;
-
/*
* Without CONFIG_UML_TIME_TRAVEL_SUPPORT this is a linker error if used,
* which is intentional since we really shouldn't link it in that case.
diff --git a/arch/um/kernel/skas/syscall.c b/arch/um/kernel/skas/syscall.c
index a5beaea2967e..b09e85279d2b 100644
--- a/arch/um/kernel/skas/syscall.c
+++ b/arch/um/kernel/skas/syscall.c
@@ -31,17 +31,6 @@ void handle_syscall(struct uml_pt_regs *r)
goto out;
syscall = UPT_SYSCALL_NR(r);
-
- /*
- * If no time passes, then sched_yield may not actually yield, causing
- * broken spinlock implementations in userspace (ASAN) to hang for long
- * periods of time.
- */
- if ((time_travel_mode == TT_MODE_INFCPU ||
- time_travel_mode == TT_MODE_EXTERNAL) &&
- syscall == __NR_sched_yield)
- tt_extra_sched_jiffies += 1;
-
if (syscall >= 0 && syscall < __NR_syscalls) {
unsigned long ret = EXECUTE_SYSCALL(syscall, regs);
--
2.49.0
next reply other threads:[~2025-05-09 10:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-09 9:50 Christian Lamparter [this message]
2025-05-09 10:03 ` [PATCH 6.12] Revert "um: work around sched_yield not yielding in time-travel mode" Johannes Berg
2025-05-11 19:23 ` Johannes Berg
2025-05-11 20:04 ` Christian Lamparter
2025-05-12 13:30 ` Patch "[PATCH 6.12] Revert "um: work around sched_yield not yielding in time-travel mode"" has been added to the 6.12-stable tree gregkh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250509095040.33355-1-chunkeey@gmail.com \
--to=chunkeey@gmail.com \
--cc=benjamin.berg@intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=richard@nod.at \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).