Home » Mailing list archives » linux-kernel » 2008 » April » 29

Re: PTRACE_{READ,WRITE}{TEXT,DATA}

Previous thread: [LTP/VFS] fcntl SETLEASE fails on ramfs/tmpfs by Bryan Wu on Monday, April 28, 2008 - 8:42 pm. (14 messages)

Next thread: Re: [PATCH 007 of 9] md: prevent duplicates in bind_rdev_to_array by Neil Brown on Monday, April 28, 2008 - 9:09 pm. (1 message)
[view original message]
From: Benjamin Herrenschmidt
Subject: PTRACE_{READ,WRITE}{TEXT,DATA}
Date: Monday, April 28, 2008 - 8:54 pm

Hi Roland, David !

I noticed kernel/ptrace.c has ptrace_readdata/writedata functions that
are only used by sparc and sparc64 which implements the ptrace requests
PTRACE_READ_DATA, PTRACE_WRITE_DATA (and _TEXT variants).

Any reason not to make everybody benefit from these and moving the sparc
implementation to the generic ptrace_request (&compat) ?

It's more efficient than read/writing one word at a time... I thought
about it in the light of some work Rik is doing to make
access_process_vm useable on video ram mappings done by the X server...

If you are ok, I'll do a patch.

Cheers,
Ben

--


[ message continues ]
[view original message]
From: David Miller
Subject: Re: PTRACE_{READ,WRITE}{TEXT,DATA}
Date: Monday, April 28, 2008 - 9:34 pm

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

It's kind of pointless because what gdb does these days on Linux is
use the procfs 'mem' file to directly read in parts of the inferior's
address space.

See linux_proc_xfer_partial() in gdb/linux-nat.c
--


[ message continues ]
[view original message]
From: Rik van Riel
Subject: Re: PTRACE_{READ,WRITE}{TEXT,DATA}
Date: Monday, April 28, 2008 - 9:44 pm

On Mon, 28 Apr 2008 21:34:16 -0700 (PDT)

Strange, changing access_process_vm on Fedora 9 made gdb able to
see video memory that the X server had mmapped.

Are you sure gdb behaves as you suggest?  

On x86 my patch seems to work as I expected...

-- 
All rights reversed.
--


[ message continues ]
[view original message]
From: Benjamin Herrenschmidt
Subject: Re: PTRACE_{READ,WRITE}{TEXT,DATA}
Date: Monday, April 28, 2008 - 10:06 pm

Because /proc/<pid>/mem also uses access_process_vm(). See
fs/proc/base.c

Cheers,
Ben.


--


[ message continues ]
[view original message]
From: Benjamin Herrenschmidt
Subject: Re: PTRACE_{READ,WRITE}{TEXT,DATA}
Date: Monday, April 28, 2008 - 10:06 pm

Good point. That still uses access_process_vm() so Rik and I work
is still valid tho.

Thanks,
Ben.


--


[ message continues ]
[view original message]
From: Roland McGrath
Subject: Re: PTRACE_{READ,WRITE}{TEXT,DATA}
Date: Tuesday, April 29, 2008 - 3:07 pm

I don't see any sense in adding that.  Using /proc/pid/mem is already the
"efficient" API for this known to userland.  I don't think keeping the fd
around for that is any great burden, and if you do then the one pread64
call is just as efficient as one ptrace call to do the same thing.


Thanks,
Roland
--


[ message continues ]
[view original message]
From: Benjamin Herrenschmidt
Subject: Re: PTRACE_{READ,WRITE}{TEXT,DATA}
Date: Tuesday, April 29, 2008 - 5:06 pm

Yup, I didn't know gdb used /proc/pid/mem to be honest ... as long as it
goes through access_process_vm(), I'm fine anyway.

Cheers,
Ben.

--


[ message continues ]
[view original message]
From: Roland McGrath
Subject: Re: PTRACE_{READ,WRITE}{TEXT,DATA}
Date: Tuesday, April 29, 2008 - 6:32 pm

All user ABIs for this have always boiled down to access_process_vm.
--


[ message continues ]
Previous thread: [LTP/VFS] fcntl SETLEASE fails on ramfs/tmpfs by Bryan Wu on Monday, April 28, 2008 - 8:42 pm. (14 messages)

Next thread: Re: [PATCH 007 of 9] md: prevent duplicates in bind_rdev_to_array by Neil Brown on Monday, April 28, 2008 - 9:09 pm. (1 message)