All of lore.kernel.org
 help / color / mirror / Atom feed
From: Erich Focht <focht@ess.nec.de>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] /proc/pid/mem and stack variables
Date: Mon, 15 Jan 2001 17:57:56 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590693005042@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590693005037@msgid-missing>

A small patch for the file fs/proc/base.c implementing llseek for
/proc/PID/mem is appended. It's the same as for /dev/kmem therefore it
does only SEEK_SET and SEEK_CUR, not SEEK_END. 

It works for reading from stack pages, positioning is ok but the return
value is -1 (which is wrong). Probably because the offsets seem to be
negative... Can anybody please tell me why I'm getting the -1 error return
though I should get back the huge negative offset?

Thanks in advance,
Erich


On Mon, 15 Jan 2001, Maciej Golebiewski wrote:

> On Fri, Jan 12, 2001 at 06:29:33PM -0800, David Mosberger wrote:
> > >>>>> On Fri, 12 Jan 2001 13:45:10 -0500, Pete Wyckoff <pw@osc.edu> said:
> > 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 a lot for help. It seems that the solution is simpler than I
> was expecting. Anyway, I don't have a root access to the IA64 machine
> in question, so I can't test it myself, but one of the guys with root
> access told me he'll try to find some time and try it out.



*** linux-2.4.0test12/fs/proc/base.c.orig1      Mon Jan 15 13:12:36 2001
--- linux-2.4.0test12/fs/proc/base.c    Mon Jan 15 13:14:49 2001
***************
*** 396,402 ****
--- 396,417 ----
  }
  #endif
  
+ static loff_t mem_lseek(struct file * file, loff_t offset, int orig)
+ {
+         switch (orig) {
+                 case 0:
+                         file->f_pos = offset;
+                         return file->f_pos;
+                 case 1:
+                         file->f_pos += offset;
+                         return file->f_pos;
+                 default:
+                         return -EINVAL;
+         }
+ }
+ 
  static struct file_operations proc_mem_operations = {
+       llseek:         mem_lseek,
        read:           mem_read,
        write:          mem_write,
  };




  parent reply	other threads:[~2001-01-15 17:57 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
2001-01-15 10:17 ` Maciej Golebiewski
2001-01-15 17:57 ` Erich Focht [this message]
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-105590693005042@msgid-missing \
    --to=focht@ess.nec.de \
    --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.