Bug 104684 - lseek on /proc/*/maps fails
Summary: lseek on /proc/*/maps fails
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Rik van Riel
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-09-18 22:37 UTC by Ulrich Drepper
Modified: 2007-11-30 22:06 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-02 02:47:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ulrich Drepper 2003-09-18 22:37:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030912
Firebird/0.6.1+ StumbleUpon/1.83

Description of problem:
Pick a process you have read access to /proc/PID/maps too which has at least one
occurrence of two anonymous memory lines following each other.  I.e., the no
file name in two or more consecutive lines.  Now compare

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
0.Use bash as the shell
1.cat /proc/PID/maps
2.while read l; do echo $l; done < /proc/PID/maps
3.compare output

Actual Results:  These are two excerpts from the output of these program runs. 
First the cat output:

00d3d000-00d3e000 rw-p 0000c000 08:02 1634087   
00d3e000-00d40000 rw-p 00000000 00:00 0
00d40000-00d41000 ---p 00000000 00:00 0
00d41000-01741000 rwxp 00001000 00:00 0
01741000-01742000 ---p 00a01000 00:00 0
01742000-02142000 rwxp 00a02000 00:00 0
02a9a000-02a9b000 ---p 00000000 00:00 0

Now the shell while loop:

00d3d000-00d3e000 rw-p 0000c000 08:02 1634087
00d3e000-00d40000 rw-p 00000000 00:00 0
01741000-01742000 ---p 00a01000 00:00 0
02a9b000-0349b000 rwxp 00001000 00:00 0

Expected Results:  Outputs should match.

Additional info:

This problem is also in the RHL9 kernel.  It seems fixed in the current 2.6 kernel.

When starting bash with

  strace -o OUT -s 20000 bash

and then running the while loop one can see that bash does something like this:

_llseek(0, 0, [57344], SEEK_CUR)        = 0
read(0, "00d3e000-00d40000 rw-p 00000000 00:00 0\n00d40000-00d41000 ---p
00000000 00:00 0\n00d41000-01741000 rwxp 00001000 00:00 0\n01741000", 128) = 128
_llseek(0, -88, [69552], SEEK_CUR)      = 0
write(1, "00d3e000-00d40000 rw-p 00000000 00:00 0\n", 40) = 40
ioctl(0, SNDCTL_TMR_TIMEBASE, 0xfeef0c90) = -1 ENOTTY (Inappropriate ioctl for
_llseek(0, 0, [69552], SEEK_CUR)        = 0
read(0, "01741000-01742000 ---p 00a01000 00:00 0\n01742000-02142000 rwxp
00a02000 00:00 0\n02a9a000-02a9b000 ---p 00000000 00:00 0\n02a9b000", 128) = 128

The _llseek syscalls seem to work for file-backed mappings, but not for
anonymous memory.  This is probably a coincident, since in case the filename is
missing more lines fit into the 128 bytes one read() call gets from the kernel.

Comment 1 Ulrich Drepper 2003-09-18 22:39:10 UTC
Ugh.  It's a kernel problem but I first thought it's a bash problem and I
already filled in that field.  Reassign to kernel group.

Comment 2 Rik van Riel 2003-10-02 02:47:12 UTC
While the bug is certainly there, I see no reason to deviate from upstream 2.4
in this behaviour.  The 2.6 kernel does things as expected.

Note You need to log in before you can comment on or make changes to this bug.