linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Wilck <Martin.Wilck@fujitsu-siemens.com>
To: Mike Galbraith <mikeg@wen-online.de>
Cc: Martin Wilck <Martin.Wilck@fujitsu-siemens.com>,
	Linux Kernel mailing list <linux-kernel@vger.kernel.org>,
	<Paul.Russell@rustcorp.com.au>
Subject: [PATCH] proc_file_read() (Was: Re: proc_file_read() question)
Date: Tue, 26 Jun 2001 19:14:05 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.30.0106261906240.13052-100000@biker.pdb.fsc.net> (raw)
In-Reply-To: <Pine.LNX.4.33.0106260834400.737-100000@mikeg.weiden.de>

Hi,

> Shhh ;-)  Last time that hack was mentioned, someone wanted to _remove_
> it.  It's a very nice little hack to have around, and IKD uses it.

I am not saying it should be removed. But IMO it is a legitimate (if
not the originally intended) use of "start" to serve as a pointer to
a memory area allocated in the proc_read () function. This use is broken
with this hack in its current form, because reading from such a file
will fail depending on the (random) order of the page and start pointers.

If I understand the "hack" right, legitimate offsets generated for it
are always between 0 and PAGE_SIZE. Therefore the patch below would
not break it, while overcoming the abovementioned problem, because
legitimate page pointers will never be < PAGE_SIZE.

Please correct me if I'm wrong.

Cheers,
Martin

-- 
Martin Wilck     <Martin.Wilck@fujitsu-siemens.com>
FSC EP PS DS1, Paderborn      Tel. +49 5251 8 15113


--- linux-2.4.5/fs/proc/generic.c	Mon Jun 25 13:46:26 2001
+++ 2.4.5mw/fs/proc/generic.c	Tue Jun 26 20:42:22 2001
@@ -104,14 +104,14 @@
  		 * return the bytes, and set `start' to the desired offset
  		 * as an unsigned int. - Paul.Russell@rustcorp.com.au
 		 */
- 		n -= copy_to_user(buf, start < page ? page : start, n);
+ 		n -= copy_to_user(buf, (unsigned long) start < PAGE_SIZE ? page : start, n);
 		if (n == 0) {
 			if (retval == 0)
 				retval = -EFAULT;
 			break;
 		}

-		*ppos += start < page ? (long)start : n; /* Move down the file */
+		*ppos += (unsigned long) start < PAGE_SIZE ? (unsigned long) start : n; /* Move down the file */
 		nbytes -= n;
 		buf += n;
 		retval += n;


  reply	other threads:[~2001-06-26 17:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-25 19:46 proc_file_read() question Martin Wilck
2001-06-26  6:48 ` Mike Galbraith
2001-06-26 17:14   ` Martin Wilck [this message]
2001-06-26 17:54     ` [PATCH] proc_file_read() (Was: Re: proc_file_read() question) Jonathan Lundell
2001-06-27  8:07       ` Martin Wilck
2001-06-27 15:54         ` Jonathan Lundell
2001-06-27 17:56           ` Martin Wilck
2001-06-27 21:32             ` Roman Zippel
2001-06-26 20:35     ` Mike Galbraith

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=Pine.LNX.4.30.0106261906240.13052-100000@biker.pdb.fsc.net \
    --to=martin.wilck@fujitsu-siemens.com \
    --cc=Paul.Russell@rustcorp.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikeg@wen-online.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).