All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <monstr@monstr.eu>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
	John Williams <john.williams@petalogix.com>
Subject: Re: generic uaccess.h
Date: Mon, 27 Jul 2009 11:43:55 +0200	[thread overview]
Message-ID: <4A6D76DB.1050902@monstr.eu> (raw)
In-Reply-To: <200907241120.22483.arnd@arndb.de>

Arnd Bergmann wrote:
> On Friday 24 July 2009, Michal Simek wrote:
>> I have just look at asm-generic uaccess.h and there is one thing which
>> seems to me wrong.
>>
>> For put_user macro - you use __copy_to_user but you have for 64bit case
>> ifdef CONFIG_64BIT
>> but  look at fs/eventfd: eventfd_read function. At least for this
>> function(syscall) is necessary "return" 64bit
>> value on 32bit machines too.
>> IMHO that ifdef CONFIG_64BIT shouldn't be there.
>>
>> What do you think?
>> If you agree with me, I'll generate proper patch with description.
> 
> The code was intentional, because 32 bit architectures normally
> don't acces u64 values efficiently. I would expect the memcpy
> to produce better object code in that case.
> Did you see an actual bug in my version or are you only
> guessing that the assignment should work better than the
> memcpy?
> 
> What object code do you get with
> 
> int test(unsigned long long __user *out, unsigned long long in)
> {
> 	return put_user(in, ptr);
> }
> 
> in both cases?

I found that I have problem on noMMU with replacing
put_user macro

with

#define put_user(x, ptr)					\
({								\
	might_sleep();						\
	access_ok(VERIFY_WRITE, ptr, sizeof(*ptr)) ?		\
		__put_user(x, ptr) :				\
		-EFAULT;					\
})

(The similar issue is for get_user) (__put_user function is origin - not asm-generic)

I am getting any short write error. It is caused with adding access_ok macro.
It is weird.

RPC: Registered tcp transport module.
VFS: Mounted root (romfs filesystem) readonly on device 31:0.
Freeing unused kernel memory: 100k freed
0: short write
Kernel panic - not syncing: Attempted to kill init!


I have more important work in front of me - I take a look at it later.

Michal


> 
> 	Arnd <><


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854

  parent reply	other threads:[~2009-07-27  9:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-24  7:39 generic uaccess.h Michal Simek
2009-07-24  9:20 ` Arnd Bergmann
2009-07-24  9:44   ` Michal Simek
2009-07-27  9:43   ` Michal Simek [this message]
2009-07-27 18:18     ` Arnd Bergmann

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=4A6D76DB.1050902@monstr.eu \
    --to=monstr@monstr.eu \
    --cc=arnd@arndb.de \
    --cc=john.williams@petalogix.com \
    --cc=linux-kernel@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 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.