All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Alexey Toptygin <alexeyt@freeshell.org>
Cc: linux-kernel@vger.kernel.org, tony.luck@intel.com
Subject: Re: [PATCH] sendfile compat functions on x86_64 and ia64
Date: Fri, 5 May 2006 22:38:26 +0200	[thread overview]
Message-ID: <200605052238.26834.ak@suse.de> (raw)
In-Reply-To: <Pine.NEB.4.62.0605050030200.18795@norge.freeshell.org>

On Friday 05 May 2006 02:45, Alexey Toptygin wrote:
> 
> Hi,
> 
> I'm a kernel noob, so I apologise in advance if I completely misunderstood 
> something. In arch/x86_64/ia32/sys_ia32.c there is this code:
> 
> sys32_sendfile(int out_fd, int in_fd, compat_off_t __user *offset, s32 count)
> [snip]
> 	ret = sys_sendfile(out_fd, in_fd, offset ? &of : NULL, count);
> 
> However on ia32, count (a size_t) is u32. I think this is taking the u32 
> value from the 32 bit userland, sign-extending it to 64 bits, then giving 
> it to sys_sendfile in a u64. So, a count >= 1<<31 passed from the 32 bit 
> app will become a count >= ((1<<33)-1)<<31 given to sys_sendfile.
> 
> Now, I don't think this actually hurts anything, because sys_sendfile 
> passes a max of ((1<<31)-1) to do_sendfile, plus rw_verify_area will 
> reject values that are negative when cast to ssize_t; but, this is 
> certainly confusing.

With your change there wouldn't be any sign extension and rw_verify_area
couldn't reject negative values them anymore.

I think it would be a wrong change because it would differ from a native 
32bit kernel.

-Andi


  reply	other threads:[~2006-05-05 20:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05  0:45 [PATCH] sendfile compat functions on x86_64 and ia64 Alexey Toptygin
2006-05-05 20:38 ` Andi Kleen [this message]
2006-05-05 20:44   ` Alexey Toptygin
2006-05-05 21:28     ` Andi Kleen
2006-05-05 22:19       ` Alexey Toptygin
2006-05-06  8:46         ` Andi Kleen
2006-05-06 22:43           ` Alexey Toptygin

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=200605052238.26834.ak@suse.de \
    --to=ak@suse.de \
    --cc=alexeyt@freeshell.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@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.