Whacky ia64: linux_proc_xfer_partial and lseek vs pread64

Whacky ia64: linux_proc_xfer_partial and lseek vs pread64

[David Lecomber]

Dear Dan and all,

It's great that these days we use file access to get at the memory via
the /proc filesystem - but there's an interesting sighting on the ia64
(suse 9) in linux_proc_xfer_partial.

#ifdef HAVE_PREAD64
  if (pread64 (fd, readbuf, len, offset) != len)
#else
  if (lseek (fd, offset, SEEK_SET) == -1 || read (fd, readbuf, len) !=
len)
#endif
    ret = 0;
  else
    ret = len;


So, Mr Itanium has pread64, it calls pread64..  it seems to fail
regularly..  As the strace log shows.

rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
open("/proc/21785/mem", O_RDONLY)       = 4
pread(4, 0x60000fffffffa040, 64, 11529215046068469760) = -1 EINVAL
(Invalid argument)
close(4)                                = 0
ptrace(PTRACE_PEEKTEXT, 21785, 0xa000000000000000, NULL) =
282584257676671
open("/proc/21785/mem", O_RDONLY)       = 4
pread(4, 0x60000fffffffa048, 56, 11529215046068469768) = -1 EINVAL
(Invalid argument)
close(4)                                = 0
ptrace(PTRACE_PEEKTEXT, 21785, 0xa000000000000008, NULL) = 0
open("/proc/21785/mem", O_RDONLY)       = 4


But, if you change this to actually call lseek, instead of pread, it's a
bit more successful.  

rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
open("/proc/22498/mem", O_RDONLY)       = 4
lseek(4, 11529215046068469760, SEEK_SET) = 11529215046068469760
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0`\6\1\0"...,
64) = 64
close(4)                                = 0
open("/proc/22498/mem", O_RDONLY)       = 4
lseek(4, 11529215046068469824, SEEK_SET) = 11529215046068469824
read(4, "\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\240\0\0"...,
224) = 224
close(4)                                = 0
open("/proc/22498/mem", O_RDONLY)       = 4
lseek(4, 11529215046068469760, SEEK_SET) = 11529215046068469760
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0`\6\1\0"...,
3408) = 3408

Literally saving over 500 calls to ptrace() in just one stroke.

Anyone any idea what's going on?  I'd be happy to let someone else
formulate the rather obvious patch, as I don't know the behaviour on
other platforms.

d.
-- 
David Lecomber <david@lecomber.net>

Re: Whacky ia64: linux_proc_xfer_partial and lseek vs pread64

[Daniel Jacobowitz]

On Fri, Feb 10, 2006 at 05:15:36PM +0000, David Lecomber wrote:
> Dear Dan and all,
> 
> It's great that these days we use file access to get at the memory via
> the /proc filesystem - but there's an interesting sighting on the ia64
> (suse 9) in linux_proc_xfer_partial.
> 
> #ifdef HAVE_PREAD64
>   if (pread64 (fd, readbuf, len, offset) != len)
> #else
>   if (lseek (fd, offset, SEEK_SET) == -1 || read (fd, readbuf, len) !=
> len)
> #endif
>     ret = 0;
>   else
>     ret = len;
> 
> 
> So, Mr Itanium has pread64, it calls pread64..  it seems to fail
> regularly..  As the strace log shows.

> open("/proc/21785/mem", O_RDONLY)       = 4
> pread(4, 0x60000fffffffa040, 64, 11529215046068469760) = -1 EINVAL
> (Invalid argument)
> close(4)                                = 0

Are there any warnings when compiling this file?  Is the prototype
for pread64 not in scope, maybe?  Failing that, put a breakpoint at
*pread64 and make sure the arguments in registers are really sane.

But I doubt it's either of those; the values look reasonable.

That offset is $1 = 0xa000000000000000.  Maybe the kernel is rejecting
that for pread because it thinks it's unacceptable for some reason.

> Anyone any idea what's going on?  I'd be happy to let someone else
> formulate the rather obvious patch, as I don't know the behaviour on
> other platforms.

The code appears to be fine and your pread appears to be busted,
unfortunately.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Whacky ia64: linux_proc_xfer_partial and lseek vs pread64

[Andreas Schwab]

David Lecomber <david@lecomber.net> writes:

> Dear Dan and all,
>
> It's great that these days we use file access to get at the memory via
> the /proc filesystem - but there's an interesting sighting on the ia64
> (suse 9) in linux_proc_xfer_partial.
>
> #ifdef HAVE_PREAD64
>   if (pread64 (fd, readbuf, len, offset) != len)
> #else
>   if (lseek (fd, offset, SEEK_SET) == -1 || read (fd, readbuf, len) !=
> len)
> #endif
>     ret = 0;
>   else
>     ret = len;
>
>
> So, Mr Itanium has pread64, it calls pread64..  it seems to fail
> regularly..  As the strace log shows.

pread and lseek with SEEK_SET do not allow negative offsets.  lseek on
/proc/$$/mem is a special exception.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Whacky ia64: linux_proc_xfer_partial and lseek vs pread64

[Daniel Jacobowitz]

On Fri, Feb 10, 2006 at 07:04:51PM +0100, Andreas Schwab wrote:
> pread and lseek with SEEK_SET do not allow negative offsets.  lseek on
> /proc/$$/mem is a special exception.

Uh-oh.  Should pread have the same exception, or must we fall back to
lseek?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Whacky ia64: linux_proc_xfer_partial and lseek vs pread64

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> On Fri, Feb 10, 2006 at 07:04:51PM +0100, Andreas Schwab wrote:
>> pread and lseek with SEEK_SET do not allow negative offsets.  lseek on
>> /proc/$$/mem is a special exception.
>
> Uh-oh.  Should pread have the same exception, or must we fall back to
> lseek?

pread fails upfront with offset < 0, whereas lseek lets the filesystem
llseek function decide.  But a fallback wouldn't help here anyway, because
you can't read the vdso memory with read, only with ptrace.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Whacky ia64: linux_proc_xfer_partial and lseek vs pread64

[Daniel Jacobowitz]

On Fri, Feb 10, 2006 at 08:00:23PM +0100, Andreas Schwab wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > On Fri, Feb 10, 2006 at 07:04:51PM +0100, Andreas Schwab wrote:
> >> pread and lseek with SEEK_SET do not allow negative offsets.  lseek on
> >> /proc/$$/mem is a special exception.
> >
> > Uh-oh.  Should pread have the same exception, or must we fall back to
> > lseek?
> 
> pread fails upfront with offset < 0, whereas lseek lets the filesystem
> llseek function decide.  But a fallback wouldn't help here anyway, because
> you can't read the vdso memory with read, only with ptrace.

Fascinating.  That definitely seems like a kernel bug to me; why not?

I see some magic bits in the kernel ptrace support to read backing
stores, which are obviously going to get fouled up by pread support.
But I don't see anything that would affect the vDSO.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Whacky ia64: linux_proc_xfer_partial and lseek vs pread64

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> Fascinating.  That definitely seems like a kernel bug to me; why not?

The vDSO page is quite special, since it is only executable, but not
readable.

> I see some magic bits in the kernel ptrace support to read backing
> stores, which are obviously going to get fouled up by pread support.
> But I don't see anything that would affect the vDSO.

That's problably the effect of ptrace overriding page protections.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Whacky ia64: linux_proc_xfer_partial and lseek vs pread64

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> Fascinating.  That definitely seems like a kernel bug to me; why not?

Looking closer, it indeed looks like a bug.  With 2.6.5 this still did
work.  The problem is that fs/read_write.c:rw_verify_area rejects negative
offsets as well, even though fs/proc/base.c:mem_read handles them fine.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Whacky ia64: linux_proc_xfer_partial and lseek vs pread64

[Daniel Jacobowitz]

On Sat, Feb 11, 2006 at 05:49:48PM +0100, Andreas Schwab wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > Fascinating.  That definitely seems like a kernel bug to me; why not?
> 
> Looking closer, it indeed looks like a bug.  With 2.6.5 this still did
> work.  The problem is that fs/read_write.c:rw_verify_area rejects negative
> offsets as well, even though fs/proc/base.c:mem_read handles them fine.

Who should this be reported to?  Normally I fix ptrace bugs myself, but
I can't do anything about ia64... hmm... I suppose it might manifest on
ia32 too since the kernel/user split is up at 4G.  I wonder if I can
coax GDB to try to read the stack using pread.

Anyway, I don't really have time to fix it.

-- 
Daniel Jacobowitz
CodeSourcery