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.
#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:
signature.asc
Description: This is a digitally signed message part