From: Ben Hutchings <ben@decadent.org.uk>
To: Mihai Maruseac <mihai.maruseac@gmail.com>
Cc: "Michael Stone" <mstone@debian.org>,
659499@bugs.debian.org, debian-kernel@lists.debian.org,
"Cyril Brulebois" <kibi@debian.org>,
"Jean-Michel Vourgère" <jmv_deb@nirgal.com>,
netdev <netdev@vger.kernel.org>
Subject: Re: Bug#659499: bash fails to properly read /proc files
Date: Sun, 26 Feb 2012 00:11:59 +0000 [thread overview]
Message-ID: <1330215119.8460.18.camel@deadeye> (raw)
In-Reply-To: <20120219221413.GA14935@mraw.org>
[-- Attachment #1.1: Type: text/plain, Size: 3466 bytes --]
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.
[-- Attachment #1.2: mini-test.c --]
[-- Type: text/x-csrc, Size: 1397 bytes --]
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
const char default_input[] = "/proc/net/dev";
int main(int argc, const char **argv) {
const char *input = default_input;
/* "usage" */
if (argc < 2) {
printf("Warning: no file specified, defaulting to %s\n", default_input);
} else {
input = argv[1];
printf("Info: using %s as specified\n", argv[1]);
}
int file = open(input, 0);
if (file < 0) {
printf("Error: unable to open %s: %s\n", input, strerror(errno));
return 1;
} else {
ssize_t ret;
ssize_t current = 0;
ssize_t extra = 0;
printf("Info: %s opened successfully\n", input);
/* this is ugly but oh well */
#define bufsize (8000)
char buf[bufsize+1] = "";
while ((ret = read(file, buf, bufsize)) > 0) {
printf("Read: %u\n", ret);
char *newline = strchr(buf, '\n');
if (newline) {
current += (newline-buf);
*newline = '\0';
extra = ret-(newline-buf+1);
printf("Found newline: %u char-long line: with %u extra chars:\n%s\n", current, extra, buf);
lseek(file, -extra, SEEK_CUR);
current = 0;
}
}
printf("Final position: %u\n", lseek(file, 0, SEEK_CUR));
close(file);
}
return 0;
}
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next parent reply other threads:[~2012-02-26 0:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120211162451.3805.76693.reportbug@annuminas.home.mathom.us>
[not found] ` <20120218010548.GE18080@mraw.org>
[not found] ` <20120219221413.GA14935@mraw.org>
2012-02-26 0:11 ` Ben Hutchings [this message]
2012-04-07 1:01 ` Bug#659499: bash fails to properly read /proc files Ben Hutchings
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=1330215119.8460.18.camel@deadeye \
--to=ben@decadent.org.uk \
--cc=659499@bugs.debian.org \
--cc=debian-kernel@lists.debian.org \
--cc=jmv_deb@nirgal.com \
--cc=kibi@debian.org \
--cc=mihai.maruseac@gmail.com \
--cc=mstone@debian.org \
--cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox