FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 02-19-2012, 09:14 PM
Cyril Brulebois
 
Default Bug#659499: bash fails to properly read /proc files

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).

I'm stripping parts of my explanations of why other shells seem
unaffected (different implementations for reading files).

Cyril Brulebois <kibi@debian.org> (18/02/2012):
> strace shows it's reading 128 bytes, then trying to adjust using
> lseek(), which might explain what you're seeing if the read() + lseek()
> calls trigger nasty things.

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.
 
Old 02-25-2012, 10:51 AM
"Jean-Michel Vourgre"
 
Default Bug#659499: bash fails to properly read /proc files

Thank you Cyril for the mini-test.

I can reproduce this bug with linux-image-3.2.0-1-686-pae

If I reboot on linux-image-3.1.0-1-686-pae lseeking in /proc works fine.
 
Old 02-25-2012, 11:11 PM
Ben Hutchings
 
Default Bug#659499: bash fails to properly read /proc files

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 <mihai.maruseac@gmail.com>
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.
 
Old 04-07-2012, 01:01 AM
Ben Hutchings
 
Default Bug#659499: bash fails to properly read /proc files

On Sun, 2012-02-26 at 00:11 +0000, Ben Hutchings wrote:
> 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 <mihai.maruseac@gmail.com>
> 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 <eric.dumazet@gmail.com>
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.
 

Thread Tools




All times are GMT. The time now is 05:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org