From: Martin Steigerwald <Martin@lichtvoll.de>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: linux-kernel@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: bugs/regressions: report in LKML or in bugzilla?
Date: Tue, 7 Dec 2010 22:11:39 +0100 [thread overview]
Message-ID: <201012072211.40206.Martin@lichtvoll.de> (raw)
In-Reply-To: <1291738321.2695.338.camel@edumazet-laptop>
[-- Attachment #1: Type: Text/Plain, Size: 2059 bytes --]
Am Dienstag 07 Dezember 2010 schrieb Eric Dumazet:
> Le mardi 07 décembre 2010 à 16:39 +0100, Martin Steigerwald a écrit :
> > A participant of a linux performance training I hold found a bug with
> > window scaling which did not receive any reply as well:
> >
> > Bug 20312 - System freeze with multiples of 32 in
> > /proc/sys/net/ipv4/tcp_adv_win_scale
> > https://bugzilla.kernel.org/show_bug.cgi?id=20312
>
> User bug ?
Sure, but whats the point?
> Documentation/networking/ip-sysctl.txt
>
> tcp_adv_win_scale - INTEGER
> Count buffering overhead as bytes/2^tcp_adv_win_scale
> (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
> if it is <= 0.
> Default: 2
>
> Given we use 32bit numbers, using values outside of [-31 ... 31] makes
> litle sense.
Granted, it does not make sense. The user tried that on an exercise to
make TCP/IP networking in Linux as slow as possible (to understand why its
fast at all).
Still: Here isn't documented that the kernel freezes when writing a wrong
value in there.
> We could add sysctl range limit, but user should not mess with
> /proc/sys/net/ipv4/parameters unless he knows what he is doing ?
>
> Almost all /proc/sys/net/ipv4/parameters dont have range limits and
> unexpected results with insane values feeded.
Well I disagree. Its a user interface, even tough a root user interface,
that is even writable without writing a program. And as far as I
understand even at least some system calls do some basic sanity checking
on arguments.
If it doesn't cost too much overhead, arguments in there should receive at
least some basic sanity checking.
> An other way to freeze a machine being root is :
>
> halt
It won't freeze the machine. It does a clean halt which reduces the chance
to reduce valuable data in yet unwritten pages.
And here it is documented that this will halt the machine.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2010-12-07 21:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-07 15:39 bugs/regressions: report in LKML or in bugzilla? Martin Steigerwald
2010-12-07 16:12 ` Eric Dumazet
2010-12-07 21:02 ` Ben Hutchings
2010-12-07 21:28 ` Martin Steigerwald
2010-12-07 21:11 ` Martin Steigerwald [this message]
2010-12-07 17:41 ` Randy Dunlap
2010-12-07 21:04 ` Martin Steigerwald
2010-12-08 10:00 ` Florian Mickler
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=201012072211.40206.Martin@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.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