From: Paolo Bonzini <pbonzini@redhat.com>
To: Dominik Dingel <dingel@linux.vnet.ibm.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
herbert@gondor.apana.org.au, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-crypto@vger.kernel.org,
Tim Chen <tim.c.chen@linux.intel.com>
Subject: single_task_running() vs. preemption warnings (was Re: [PATCH] kvm: fix preemption warnings in kvm_vcpu_block)
Date: Thu, 17 Sep 2015 18:45:00 +0200 [thread overview]
Message-ID: <55FAEE0C.60904@redhat.com> (raw)
In-Reply-To: <1442507270-67227-1-git-send-email-dingel@linux.vnet.ibm.com>
On 17/09/2015 18:27, Dominik Dingel wrote:
> + preempt_disable();
> + solo = single_task_running();
> + preempt_enable();
> +
> cur = ktime_get();
> - } while (single_task_running() && ktime_before(cur, stop));
That's the obvious way to fix it, but the TOCTTOU problem (which was in
the buggy code too) is obvious too. :) And the only other user of
single_task_running() in drivers/crypto/mcryptd.c has the same issue.
In fact, because of the way the function is used ("maybe I can do a
little bit of work before going to sleep") it will likely be called many
times in a loop. This in turn means that:
- any wrong result due to a concurrent process migration would be
rectified very soon
- preempt_disable()/preempt_enable() can actually be just as expensive
or more expensive than single_task_running() itself.
Therefore, I wonder if single_task_running() should just use
raw_smp_processor_id(). At least the TOCTTOU issue can be clearly
documented in the function comment, instead of being hidden behind each
of the callers.
Thanks,
Paolo
next prev parent reply other threads:[~2015-09-17 16:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 16:27 [PATCH] kvm: fix preemption warnings in kvm_vcpu_block Dominik Dingel
2015-09-17 16:45 ` Paolo Bonzini [this message]
2015-09-17 17:07 ` single_task_running() vs. preemption warnings (was Re: [PATCH] kvm: fix preemption warnings in kvm_vcpu_block) Dominik Dingel
2015-09-17 20:32 ` Tim Chen
2015-09-18 7:52 ` Peter Zijlstra
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=55FAEE0C.60904@redhat.com \
--to=pbonzini@redhat.com \
--cc=davem@davemloft.net \
--cc=dingel@linux.vnet.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=kvm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tim.c.chen@linux.intel.com \
/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.