From: Ingo Molnar <mingo@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Fenghua Yu <fenghua.yu@intel.com>
Subject: Re: [PATCH RFC] x86: uaccess s/might_sleep/might_fault/
Date: Thu, 2 May 2013 10:52:41 +0200 [thread overview]
Message-ID: <20130502085241.GA27969@gmail.com> (raw)
In-Reply-To: <20130502022134.GA7700@redhat.com>
* Michael S. Tsirkin <mst@redhat.com> wrote:
> The only reason uaccess routines might sleep
> is if they fault. Make this explicit for
> __copy_from_user_nocache, and consistent with
> copy_from_user and friends.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> I've updated all other arches as well - still
> build-testing. Any objections to the x86 patch?
>
> arch/x86/include/asm/uaccess_64.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/uaccess_64.h b/arch/x86/include/asm/uaccess_64.h
> index 142810c..4f7923d 100644
> --- a/arch/x86/include/asm/uaccess_64.h
> +++ b/arch/x86/include/asm/uaccess_64.h
> @@ -235,7 +235,7 @@ extern long __copy_user_nocache(void *dst, const void __user *src,
> static inline int
> __copy_from_user_nocache(void *dst, const void __user *src, unsigned size)
> {
> - might_sleep();
> + might_fault();
> return __copy_user_nocache(dst, src, size, 1);
Looks good to me:
Acked-by: Ingo Molnar <mingo@kernel.org>
... but while reviewing the effects I noticed a bug in might_fault():
#ifdef CONFIG_PROVE_LOCKING
void might_fault(void)
{
/*
* Some code (nfs/sunrpc) uses socket ops on kernel memory while
* holding the mmap_sem, this is safe because kernel memory doesn't
* get paged out, therefore we'll never actually fault, and the
* below annotations will generate false positives.
*/
if (segment_eq(get_fs(), KERNEL_DS))
return;
might_sleep();
the might_sleep() call should come first. With the current code
might_fault() schedules differently depending on CONFIG_PROVE_LOCKING,
which is an undesired semantical side effect ...
So please fix that too while at it.
Thanks,
Ingo
next prev parent reply other threads:[~2013-05-02 8:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-02 2:21 [PATCH RFC] x86: uaccess s/might_sleep/might_fault/ Michael S. Tsirkin
2013-05-02 8:52 ` Ingo Molnar [this message]
2013-05-02 13:28 ` Michael S. Tsirkin
2013-05-07 10:11 ` Michael S. Tsirkin
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=20130502085241.GA27969@gmail.com \
--to=mingo@kernel.org \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mst@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@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 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.