Hi!
I reported some regressions to bugzilla that did not receive any
attentation so far:
[Bug 23792] New: openvpn: failure to unregister tap1 device, possibly
related to some netconsole issue
https://bugzilla.kernel.org/show_bug.cgi?id=23792
[Bug 23642] New: easycap driver fails to compile in 2.6.37-rc3
https://bugzilla.kernel.org/show_bug.cgi?id=23642
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
Is it better to report on LKML? I have the impression that bug reports
onto the mailinglist are more easily recognized.
I also find it difficult to find the right component when reporting a problem
in bugzilla. Thus reports might not go to the right persons.
Please advice.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
On Tue, 7 Dec 2010 16:39:46 +0100 Martin Steigerwald wrote:
> Hi!
>
> I reported some regressions to bugzilla that did not receive any
> attentation so far:
>
> [Bug 23792] New: openvpn: failure to unregister tap1 device, possibly
> related to some netconsole issue
> https://bugzilla.kernel.org/show_bug.cgi?id=23792
>
> [Bug 23642] New: easycap driver fails to compile in 2.6.37-rc3
> https://bugzilla.kernel.org/show_bug.cgi?id=23642
>
That one has received attention. I commented on it and I have posted
a patch that fixes that particular build problem.
>
> 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
>
>
> Is it better to report on LKML? I have the impression that bug reports
> onto the mailinglist are more easily recognized.
They are generally more visible and get more attention if they are posted
on an appropriate mailing list. #20312, e.g., should be posted on the
netdev mailing list ([email protected])
Probably same for #27392.
> I also find it difficult to find the right component when reporting a problem
> in bugzilla. Thus reports might not go to the right persons.
>
> Please advice.
Bugs that are posted to LKML usually are added to the kernel bugzilla
by one of the bugzilla maintainers. They would also select the component,
so you could just try that route to see if it works better.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
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 ?
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.
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.
An other way to freeze a machine being root is :
halt
On Tue, 2010-12-07 at 17:12 +0100, Eric Dumazet wrote:
> 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 ?
>
> 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.
>
> We could add sysctl range limit, but user should not mess with
> /proc/sys/net/ipv4/parameters unless he knows what he is doing ?
[...]
For mere humans, the range is not quite os obvious. Which is why this
has been fixed in net-2.6 (as noted on that bug report now).
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
Am Dienstag 07 Dezember 2010 schrieb Randy Dunlap:
> On Tue, 7 Dec 2010 16:39:46 +0100 Martin Steigerwald wrote:
[...]
> > I reported some regressions to bugzilla that did not receive any
> > attentation so far:
> >
> > [Bug 23792] New: openvpn: failure to unregister tap1 device, possibly
> > related to some netconsole issue
> > https://bugzilla.kernel.org/show_bug.cgi?id=23792
> >
> > [Bug 23642] New: easycap driver fails to compile in 2.6.37-rc3
> > https://bugzilla.kernel.org/show_bug.cgi?id=23642
>
> That one has received attention. I commented on it and I have posted
> a patch that fixes that particular build problem.
Sorry, I somehow missed that reply. Thanks.
> > 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
> >
> >
> > Is it better to report on LKML? I have the impression that bug
> > reports onto the mailinglist are more easily recognized.
>
> They are generally more visible and get more attention if they are
> posted on an appropriate mailing list. #20312, e.g., should be posted
> on the netdev mailing list ([email protected])
> Probably same for #27392.
Thanks for your hints.
> > I also find it difficult to find the right component when reporting a
> > problem in bugzilla. Thus reports might not go to the right persons.
> >
> > Please advice.
>
> Bugs that are posted to LKML usually are added to the kernel bugzilla
> by one of the bugzilla maintainers. They would also select the
> component, so you could just try that route to see if it works better.
Or I create a Bugzilla to save bugzilla maintainers some work and post a
hint on the mailinglist, too?
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
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
Am Dienstag 07 Dezember 2010 schrieb Ben Hutchings:
> On Tue, 2010-12-07 at 17:12 +0100, Eric Dumazet wrote:
> > 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 ?
> >
> > 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.
> >
> > We could add sysctl range limit, but user should not mess with
> > /proc/sys/net/ipv4/parameters unless he knows what he is doing ?
>
> [...]
>
> For mere humans, the range is not quite os obvious. Which is why this
> has been fixed in net-2.6 (as noted on that bug report now).
>
> Ben.
I verified the fix on 2.6.37-rc5.
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
On Tue, 7 Dec 2010 22:04:30 +0100
Martin Steigerwald <[email protected]> wrote:
> Am Dienstag 07 Dezember 2010 schrieb Randy Dunlap:
> > On Tue, 7 Dec 2010 16:39:46 +0100 Martin Steigerwald wrote:
> > > [Bug 23642] New: easycap driver fails to compile in 2.6.37-rc3
> > > https://bugzilla.kernel.org/show_bug.cgi?id=23642
> >
> > That one has received attention. I commented on it and I have posted
> > a patch that fixes that particular build problem.
>
> Sorry, I somehow missed that reply. Thanks.
The Bugzilla system did have some hickups in the last months, but seems
stable now. (knock wood)
> > Bugs that are posted to LKML usually are added to the kernel bugzilla
> > by one of the bugzilla maintainers. They would also select the
> > component, so you could just try that route to see if it works better.
>
> Or I create a Bugzilla to save bugzilla maintainers some work and post a
> hint on the mailinglist, too?
>
> Ciao,
Yes, this would be ok. If you do that, it might be useful to also post a
note in the bugzilla report with a reference to the mailinglist-thread
in case a solutions crops up via mail and somehow doesn't make it into
the bugzilla. That makes it easier to decide what to do with a left-over
bugreport 6 months from now.
Regards,
Flo