mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Chuck Ebbert <76306.1226@compuserve.com>
Cc: Steven Rostedt <rostedt@goodmis.org>, Andi Kleen <ak@suse.de>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [patch 2.6.13-rc6] Fix kmem read on 32-bit archs
Date: Sun, 14 Aug 2005 18:16:11 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.58.0508141803590.3553@g5.osdl.org> (raw)
In-Reply-To: <200508141639_MC3-1-A731-592C@compuserve.com>



On Sun, 14 Aug 2005, Chuck Ebbert wrote:
> 
>   GCC warns about using llseek and suggests lseek64 instead. That works
> for me, but up till 2.6.11 plain lseek worked too.  I guess it really
> shouldn't have?

Well, we have had various special-cases for /dev/[k]mem to try to make it 
work even with 32-bit lseek in the past (or with 64-bit lseek on archs 
that need the high bit set). So I wouldn't say "shouldn't have" - I'd love 
it if it worked, but my ove for it working is somewhat tempered by the 
need for it not screwing up everything else in the kernel ;)

Now, it's entirely possible that we shoul djust make "sys_lseek()" work
differently: right now it _always_ sign-extends its offset from "off_t" to
"loff_t", but the thing is, for a SEEK_SET, it probably makes more sense
to zero-extend it (since a negative SEEK_SET just doesn't make any sense).

So a hacky alternative might be something like the appended, but I have to 
admit that it's pretty damn hacky even if it makes sense at some level..

Oh, btw, this will cause it to still return EOVERFLOW, you'd need to also 
change that error return logic.

		Linus

-----
diff --git a/fs/read_write.c b/fs/read_write.c
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -137,7 +137,11 @@ asmlinkage off_t sys_lseek(unsigned int 
 
 	retval = -EINVAL;
 	if (origin <= 2) {
-		loff_t res = vfs_llseek(file, offset, origin);
+		/* SEEK_SET zero-extends, others sign-extend */
+		loff_t res = offset;
+		if (!origin)
+			res = (unsigned long)offset;
+		res = vfs_llseek(file, res, origin);
 		retval = res;
 		if (res != (loff_t)retval)
 			retval = -EOVERFLOW;	/* LFS: should only happen on 32 bit platforms */

  reply	other threads:[~2005-08-15  1:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-14 20:36 Chuck Ebbert
2005-08-15  1:16 ` Linus Torvalds [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-08-14 16:12 Chuck Ebbert
2005-08-14 16:22 ` Andi Kleen
2005-08-14 16:24 ` Linus Torvalds
2005-08-14 16:50 ` Linus Torvalds

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=Pine.LNX.4.58.0508141803590.3553@g5.osdl.org \
    --to=torvalds@osdl.org \
    --cc=76306.1226@compuserve.com \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®