All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: Paul Taysom <Paul.Taysom@novell.com>,
	linux-fsdevel@vger.kernel.org, viro@www.linux.org.uk
Subject: Re: negative seek offsets in VFS
Date: 26 May 2005 21:23:32 +0200
Date: Thu, 26 May 2005 21:23:32 +0200	[thread overview]
Message-ID: <20050526192332.GW86087@muc.de> (raw)
In-Reply-To: <OF71D8EA4F.087D140F-ON8825700D.00613961-8825700D.0061F567@us.ibm.com>

On Thu, May 26, 2005 at 10:49:57AM -0700, Bryan Henderson wrote:
> >The addresses returned from /proc/kallsyms on the x86_64 are negative and 
> when
> >I print the address of a kernel variable with "%p" it comes out negative.
> 
> Wow.  So can someone explain this?  Does the x86_64 architecture actually 
> have a concept of negative addresses?

Yes, it has. It has a 48bit address space, and the 48th bit 
is sign extended to 64bits. So you have a big hole in the middle
and positive and negative address spaces. The kernel uses the negative
half, user space the positive half.

> 
> Ordinarily, I'd think this was a bug if I saw it, but I don't see how %p 
> could format a minus sign without it being deliberate.

It doesnt, but they are still negative. 
 
> In any case, I know POSIX doesn't have a concept of a negative absolute 
> file offset, so a kmem device cannot represent a negative address as a 
> negative file offset.  A negative loff_t means something else.

I dont think POSIX has anything to say about /dev/kmem.

-Andi
> 

  reply	other threads:[~2005-05-26 19:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <s29588e0.089@sinclair.provo.novell.com>
2005-05-26 17:49 ` negative seek offsets in VFS Bryan Henderson
2005-05-26 19:23   ` Andi Kleen [this message]
2005-05-26 21:17     ` Bryan Henderson
2005-05-27 10:43       ` Andi Kleen
2005-05-27 18:39         ` Bryan Henderson
2005-05-28 12:41           ` Jamie Lokier
2005-05-31 18:08             ` Bryan Henderson
2005-05-30  9:36           ` Andi Kleen
2005-05-31 18:33             ` Bryan Henderson
2005-05-28 12:37         ` Jamie Lokier
2005-05-30  9:32           ` Andi Kleen
2005-05-26 14:29 Paul Taysom
  -- strict thread matches above, loose matches on Subject: below --
2005-05-25 16:39 Andi Kleen
2005-05-25 16:56 ` Trond Myklebust
2005-05-25 18:48   ` Andi Kleen
2005-05-26  0:56 ` Bryan Henderson
2005-05-26 19:20   ` Andi Kleen
2005-05-26 15:15 ` Al Viro
2005-05-26 15:29   ` Linus Torvalds
2005-05-26 19:25     ` Andi Kleen
2005-05-26 19:39       ` 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=20050526192332.GW86087@muc.de \
    --to=ak@muc.de \
    --cc=Paul.Taysom@novell.com \
    --cc=hbryan@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@www.linux.org.uk \
    /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.