From: David Mosberger <davidm@hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] /proc/pid/mem and stack variables
Date: Sat, 13 Jan 2001 02:29:33 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590693005040@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590693005037@msgid-missing>
>>>>> On Fri, 12 Jan 2001 13:45:10 -0500, Pete Wyckoff <pw@osc.edu> said:
Pete> maciej@ccrl-nece.technopark.gmd.de said:
>> I have recompiled the library on IA64 under 2.4.0-test12 and
>> using version 2.9-ia64-000216-final. The library works OK except
>> when the address it tries to access via /proc/pid/mem refers to
>> variables allocated on stack (e.g. local arrays defined in
>> functions).
>>
>> This is a snippet of code used to access memory via
>> /proc/pid/mem:
>>
>> void mem_read (int fd, void *buf, void *addr, size_t len) {
>>
>> if (lseek (fd, (off_t)addr, SEEK_SET) = (off_t)-1) perror
>> ("lseek"); read (fd, buf, len);
>>
>> lseek in this code fails (EINVAL) always when addr is address of
>> a variable allocated on stack.
Pete> Try removing the "offset >= 0" check in default_llseek in
Pete> fs/read_write.c. Stack pages seem to have the high bit set
Pete> which is flummoxing that test.
Pete> If you keep this "solution" you may want to write an llseek
Pete> function for /proc/pid/mem so that the entire kernel doesn't
Pete> suffer any unforseen consequences.
Yes, implementing llseek for fs/proc/base.c:proc_mem_operations is the
right solution. /dev/kmem already has its own llseek (which treats
the offset as unsigned) but, for some reason, was left out of the
/proc/pid/mem support.
Don, can you add this to the TODO list so we won't forget about it?
Thanks,
--david
next prev parent reply other threads:[~2001-01-13 2:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-12 16:20 [Linux-ia64] /proc/pid/mem and stack variables Maciej Golebiewski
2001-01-12 18:45 ` Pete Wyckoff
2001-01-13 2:29 ` David Mosberger [this message]
2001-01-15 10:17 ` Maciej Golebiewski
2001-01-15 17:57 ` Erich Focht
2001-01-18 2:48 ` David Mosberger
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=marc-linux-ia64-105590693005040@msgid-missing \
--to=davidm@hpl.hp.com \
--cc=linux-ia64@vger.kernel.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 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.