All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Lange Norbert <norbert.lange@andritz.com>,
	"Xenomai (xenomai@xenomai.org)" <xenomai@xenomai.org>
Subject: Re: Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks
Date: Wed, 19 Dec 2018 13:09:41 +0100	[thread overview]
Message-ID: <159d2a96-fb82-b974-7958-79367a00a546@xenomai.org> (raw)
In-Reply-To: <f4c18591165c4b919c85ac90a756af9f@andritz.com>

On 12/19/18 11:20 AM, Lange Norbert via Xenomai wrote:
> There is a deadlock issue that haunted me for several weeks,
> it is caused by the kernels update of the user-visible
> timekeeping structures used by the VDSO clock_gettime functions.
> 
> The kernel regularly updates a Timestamp structure, which is accessible in user-mode,
> it does so by something akin to a rw-lock in update_fast_timekeeper.
> 
> If cobalt preempts the core during holding the lock, any thread trying to read the time
> will continue to spin. (This alone is an issue IMHO).
> If the cobalt thread itself now call the vDSO function as reader,
> it will spin on the lock and block the lock from getting released.
> 
> 
> Either the update_fast_timekeeper funtion should not be preemptible by cobalt,
> or the spin-lock on reading could fallback to the syscall after a certain amount of retries.
> 
> The later is probably easier to implement, but then could randomly demote cobalt threads.
> (on the other hand, this would be always a demotion on platforms without the vdso function)
> 

update_vsyscall() is locking the write-side. If the analysis is correct, this patch may help at the expense of a some cycles more spent uninterruptible:

diff --git a/arch/x86/entry/vsyscall/vsyscall_gtod.c b/arch/x86/entry/vsyscall/vsyscall_gtod.c
index 9fb89b6e88c3..e9baa57e8385 100644
--- a/arch/x86/entry/vsyscall/vsyscall_gtod.c
+++ b/arch/x86/entry/vsyscall/vsyscall_gtod.c
@@ -32,11 +32,14 @@ void update_vsyscall(struct timekeeper *tk)
 {
 	int vclock_mode = tk->tkr_mono.clock->archdata.vclock_mode;
 	struct vsyscall_gtod_data *vdata = &vsyscall_gtod_data;
+	unsigned long flags;
 
 	/* Mark the new vclock used. */
 	BUILD_BUG_ON(VCLOCK_MAX >= 32);
 	WRITE_ONCE(vclocks_used, READ_ONCE(vclocks_used) | (1 << vclock_mode));
 
+	flags = hard_cond_local_irq_save();
+
 	gtod_write_begin(vdata);
 
 	/* copy vsyscall data */
@@ -77,6 +80,8 @@ void update_vsyscall(struct timekeeper *tk)
 
 	gtod_write_end(vdata);
 
+	hard_cond_local_irq_restore(flags);
+
 	if (tk->tkr_mono.clock == &clocksource_tsc)
 		ipipe_update_hostrt(tk);
 }

-- 
Philippe.


  reply	other threads:[~2018-12-19 12:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-19 10:20 Cobalt Preemption of kernel update_fast_timekeeper can cause deadlocks Lange Norbert
2018-12-19 12:09 ` Philippe Gerum [this message]
2018-12-19 12:44   ` Jan Kiszka
2018-12-19 13:08     ` Lange Norbert
2018-12-19 13:47     ` Philippe Gerum
2018-12-19 18:26     ` Auel, Kendall
2018-12-20 10:45       ` Jan Kiszka
2018-12-20 12:29         ` Lange Norbert
2018-12-20 13:32           ` Jan Kiszka
2018-12-20 15:02             ` Lange Norbert
2018-12-20 15:21               ` Jan Kiszka
2018-12-21 13:31                 ` Lange Norbert

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=159d2a96-fb82-b974-7958-79367a00a546@xenomai.org \
    --to=rpm@xenomai.org \
    --cc=norbert.lange@andritz.com \
    --cc=xenomai@xenomai.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.