Re: Bug#659499: bash fails to properly read /proc files

2 messages, 1 author, 2012-04-07 · open the first message on its own page

Re: Bug#659499: bash fails to properly read /proc files

From: Ben Hutchings <hidden>
Date: 2012-02-26 00:12:07

On Sun, 2012-02-19 at 23:14 +0100, Cyril Brulebois wrote:
Hi kernel folks,

here's a tiny analysis I tried to perform on bash's having issues with
reading /proc files, which I think is related to seeking in those files.
I can't play much with other kernel versions right now though. My tests
were performed with squeeze's bpo kernel: 3.2.0-0.bpo.1-amd64 (Debian
3.2.4-1~bpo60+1).
The specific problem with seeking in /proc/net/dev appears to be caused
by this change:

commit f04565ddf52e401880f8ba51de0dff8ba51c99fd
Author: Mihai Maruseac [off-list ref]
Date:   Thu Oct 20 20:45:10 2011 +0000

    dev: use name hash for dev_seq_ops

Ben.

[...]
Attached is a reduced (as in “lighter than bash”) test case. The code is
ugly but I'm throwing it over the wall before the BSP's end: built with
bufsize=8000, everything is fine for my 600-ish bytes /proc/net/dev;
built with bufsize=128, read()+lseek() seem to trigger nasty stuff as I
suspected.

Here's the output for bufsize=8000:
| $ gcc mini-test.c && ./a.out 
| Warning: no file specified, defaulting to /proc/net/dev
| Info: /proc/net/dev opened successfully
| Read: 694
| Found newline: 76 char-long line: with 617 extra chars:
| Inter-|   Receive                                                |  Transmit
| Read: 617
| Found newline: 122 char-long line: with 494 extra chars:
|  face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
| Read: 494
| Found newline: 122 char-long line: with 371 extra chars:
|     lo:   63886     451    0    0    0     0          0         0    63886     451    0    0    0     0       0          0
| Read: 371
| Found newline: 122 char-long line: with 248 extra chars:
|   pan0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
| Read: 248
| Found newline: 124 char-long line: with 123 extra chars:
|  wlan0: 151354717  197302    0    0    0     0          0         0 22011993  189809    0    0    0     0       0          0
| Read: 123
| Found newline: 122 char-long line: with 0 extra chars:
|   eth0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
| Final position: 694
→ OK

Here's the output for bufsize=128:
| $ gcc mini-test.c && ./a.out 
| Warning: no file specified, defaulting to /proc/net/dev
| Info: /proc/net/dev opened successfully
| Read: 128
| Found newline: 76 char-long line: with 51 extra chars:
| Inter-|   Receive                                                |  Transmit
| Read: 128
| Found newline: 122 char-long line: with 5 extra chars:
|  face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
| Read: 128
| Found newline: 122 char-long line: with 5 extra chars:
|   pan0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
| Final position: 323

Has anything like that been reported/fixed recently?


(Probably my last one:) Thanks to IRILL for sponsoring this BSP in Paris.

Mraw,
KiBi.
-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.

Re: Bug#659499: bash fails to properly read /proc files

From: Ben Hutchings <hidden>
Date: 2012-04-07 01:01:57

On Sun, 2012-02-26 at 00:11 +0000, Ben Hutchings wrote:
On Sun, 2012-02-19 at 23:14 +0100, Cyril Brulebois wrote:
quoted
Hi kernel folks,

here's a tiny analysis I tried to perform on bash's having issues with
reading /proc files, which I think is related to seeking in those files.
I can't play much with other kernel versions right now though. My tests
were performed with squeeze's bpo kernel: 3.2.0-0.bpo.1-amd64 (Debian
3.2.4-1~bpo60+1).
The specific problem with seeking in /proc/net/dev appears to be caused
by this change:

commit f04565ddf52e401880f8ba51de0dff8ba51c99fd
Author: Mihai Maruseac [off-list ref]
Date:   Thu Oct 20 20:45:10 2011 +0000

    dev: use name hash for dev_seq_ops
[...]

This is supposed to be fixed by:

commit 2def16ae6b0c77571200f18ba4be049b03d75579
Author: Eric Dumazet [off-list ref]
Date:   Mon Apr 2 22:33:02 2012 +0000

    net: fix /proc/net/dev regression

which will be applied some time soon.  I'm attaching the patch in case
anyone would like to test it (see
<http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>).

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help