All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
	linux-kernel@vger.kernel.org, gcosta@redhat.com, lenb@kernel.org,
	mingo@elte.hu, tglx@linutronix.de, ying.huang@intel.com,
	Linux Arch Mailing List <linux-arch@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: + drivers-acpi-apei-erst-dbgc-get_useru64-doesnt-work-on-i386.patch added to -mm tree
Date: Wed, 11 Aug 2010 21:22:51 -0700	[thread overview]
Message-ID: <4C63771B.6030005@zytor.com> (raw)
In-Reply-To: <20100811173327.3ae325ff.akpm@linux-foundation.org>

[Adding Linux and linux-arch.  The context is that get_user/put_user
don't work on 64 bit values on i386.]

On 08/11/2010 05:33 PM, Andrew Morton wrote:
> 
> Anyway, this should be fixed in x86 core, I suspect.

After looking at it -- and suffering a bad case of déjà vu -- I'm
reluctant to change it, as get/put_user are specified to work only on
locally atomic data:

 * This macro copies a single simple variable from user space to kernel
 * space.  It supports simple types like char and int, but not larger
 * data types like structures or arrays.

Given that u64 is not a simple type on 32 bits, it would appear that the
behavior is intentional.

A user might very well find that supporting u64 and/or structure types
would be beneficial, but it would a) be a semantic change, and b) would
introduce the possibility of a partially completed transfer.  That is a
semantic change to the interface.  However, it may very well be nicer to
have a generally available get_user()/put_user() for the cases which
would just kick an EFAULT up the stack when they fail anyway.

If there is consensus for making get_user/put_user a general interface,
I'm more than willing to do the x86 changes, but I don't want to do them
a) unilaterally and b) for 2.6.36.  This seems like .37 material at this
point.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

  parent reply	other threads:[~2010-08-12  4:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-11 23:06 + drivers-acpi-apei-erst-dbgc-get_useru64-doesnt-work-on-i386.patch added to -mm tree akpm
2010-08-11 23:43 ` Randy Dunlap
2010-08-12  0:33   ` Andrew Morton
2010-08-12  0:42     ` Huang Ying
2010-08-12  1:35     ` H. Peter Anvin
2010-08-12  4:22     ` H. Peter Anvin [this message]
2010-08-12  4:30       ` Andrew Morton
2010-08-12  4:42         ` H. Peter Anvin
2010-08-12  5:06         ` H. Peter Anvin
2010-08-12  6:03           ` Andrew Morton
2010-08-12  6:10             ` H. Peter Anvin

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=4C63771B.6030005@zytor.com \
    --to=hpa@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=gcosta@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=randy.dunlap@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=ying.huang@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.