Discussion:
[GIT]: Networking
(too old to reply)
David Miller
2008-08-19 11:17:06 UTC
Permalink
We're still chipping away at the packet scheduler layer locking
issues, but I feel that this is mostly sorted at this point.

Other highlights:

1) Fix for NAT via loopback per regression with GSO by Herbert
Xu.

2) Merge in wired driver fixes via Jeff Garzik.

3) Bluetooth updates via Marcel Holtmann.

4) Wireless driver updates via John Linville.

5) Fix to namespace handling in ipv6 from Brian Haley.

6) DCCP panic fix from Gerrit Renker.

7) Packet scheduler qdisc return value handling fix which can
cause TCP crashes.

8) Netfilter bug fixes from Patrick McHardy and co.

Please pull, thanks a lot!

The following changes since commit a7f5aaf36ded825477c4d7167cc6eb1bcdc6=
3191:
Linus Torvalds (1):
Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/.../=
tip/linux-2.6-tip

are available in the git repository at:

master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master

Adrian Bunk (2):
[netdrvr] uninline atl1e_setup_mac_ctrl()
ath9k: work around gcc ICEs (again)

Anders Grafstr=F6m (1):
netfilter: ipt_addrtype: Fix matching of inverted destination add=
ress type

Atsushi Nemoto (1):
[netdrvr] ne: Use CONFIG_MACH_TX49XX

Ben Dooks (1):
AX88796: Fix locking in ethtool support

Brian Haley (1):
netns: Add network namespace argument to rt6_fill_node() and ipv6=
_dev_get_saddr()

Brice Goglin (1):
myri10ge: myri10ge_fw_name also overrides the rss firmware

Bruce Allan (7):
e1000e: Return 1 instead of a non-zero value for link up indicati=
on
e1000e: Set InterruptThrottleRate to default when invalid value u=
sed
e1000e: Use skb_copy_to_linear_data_offset introduced in 2.6.22
e1000e: Increase Tx timeout factor for 10Mbps
e1000e: increase minimum frame size allowed
e1000e: test for unusable MSI support
e1000e: remove unnecessary snippet missed in prior check_options =
update

Christian Lamparter (3):
p54: Fix regression due to "net: Delete NETDEVICES_MULTIQUEUE kco=
nfig option"
p54: move p54_vdcf_init to the right place.
p54u: reset skb's data/tail pointer on requeue

David Brownell (1):
Kconfig: HSO driver bugfixes and updates

David S. Miller (18):
Merge branch 'upstream-davem' of master.kernel.org:/.../jgarzik/n=
etdev-2.6
loopback: Remove rest of LOOPBACK_TSO code.
bnx2: Fix build with VLAN_8021Q disabled.
pkt_sched: Add 'deactivated' state.
pkt_sched: Simplify dev_deactivate() polling loop.
pkt_sched: No longer destroy qdiscs from RCU.
sch_prio: Use NET_XMIT_SUCCESS instead of "0" constant.
pkt_sched: Fix missed RCU unlock in dev_queue_xmit()
pkt_sched: Fix return value corruption in HTB and TBF.
pkt_sched: Never schedule non-root qdiscs.
pkt_sched: Don't hold qdisc lock over qdisc_destroy().
Merge branch 'master' of git://git.kernel.org/.../linville/wirele=
ss-2.6
Revert "pkt_sched: Protect gen estimators under est_lock."
Revert "pkt_sched: Add BH protection for qdisc_stab_lock."
Merge branch 'master' of git://git.kernel.org/.../holtmann/blueto=
oth-2.6
pkt_sched: Prevent livelock in TX queue running.

Dhananjay Phadke (6):
netxen: fix mac addr setup
netxen: fix rxbuf leak across driver reload
netxen: force link update across ifdown/ifup
netxen: fix dma watchdog
netxen: cleanup interrupt code
netxen: update driver version

Gerrit Renker (1):
dccp: Fix panic caused by too early termination of retransmission=
mechanism

Greg Kroah-Hartman (2):
USB: HSO: make tty_operations const
USB: HSO: minor fixes due to code review

Henrique de Moraes Holschuh (1):
rfkill: protect suspended rfkill controllers

Herbert Xu (4):
ipv4: Disable route secret interval on zero interval
loopback: Enable TSO
net: Preserve netfilter attributes in skb_gso_segment using __cop=
y_skb_header
loopback: Drop obsolete ip_summed setting

Holger Schurig (1):
ssb: allow compilation on systems without PCI

Huang Weiyi (2):
[netdrvr] remove unnecessary #include
removed unused #include <version.h>

Ilpo J=E4rvinen (1):
pkt_sched: remove bogus block (cleanup)

Jarek Poplawski (4):
pkt_sched: Fix unlocking in tc_ctl_tfilter()
net: Change handling of the __QDISC_STATE_SCHED flag in net_tx_ac=
tion().
pkt_sched: Grab correct lock in notify_and_destroy().
pkt_sched: Add lockdep annotation for qdisc locks

Jesse Brandeburg (1):
ixgbe: add cx4 device ID

Jiri Slaby (1):
iwlwifi: fix printk newlines

Jochen Friedrich (1):
rt2x00: Fix txdone_entry_desc_flags

Jussi Kivilinna (1):
sch_prio: Use return value from inner qdisc requeue

Larry Finger (2):
b43: Fix for SPROM coding error in Linksys WMP54G (BCM4306/3)
b43: Fix for another Bluetooth Coexistence SPROM Programming erro=
r for BCM4306

Luis R. Rodriguez (1):
mac80211: remove kdoc references to IEEE80211_HW_HOST_GEN_BEACON_=
TEMPLATE

Marcel Holtmann (3):
[Bluetooth] Add SCO support to btusb driver
[Bluetooth] Fix userspace breakage due missing class links
[Bluetooth] Consolidate maintainers information

Mark McLoughlin (1):
tun: TUNGETIFF interface to query name and flags

Matt Carlson (6):
tg3: Add APE register access locking
tg3: Refine APE status check
tg3: Preserve register settings for DASH
tg3: Turn off ASF "driver alive" heartbeats for APE
tg3: Fix firmware event timeouts
tg3: Update version to 3.94

Michael Chan (4):
bnx2: Fix logic to setup VLAN rx tagging.
bnx2: Use proper CONFIG_VLAN_8021Q to compile the VLAN code.
bnx2: Reinsert VLAN tag when necessary.
bnx2: Update version to 1.8.0.

Michael Karcher (1):
ath5k: Don't fiddle with MSI on suspend/resume.

Mikael Pettersson (1):
ixp4xx_eth: fix dma_mapping_error() compile errors

Olivier Blin (2):
hso: fix oops in read/write callbacks
hso: fix refcounting on the ttyHSx devices

Pablo Neira Ayuso (3):
netfilter: ctnetlink: fix double helper assignation for NAT'ed co=
nntracks
netfilter: ctnetlink: fix sleep in read-side lock section
netfilter: ctnetlink: sleepable allocation with spin lock bh

Rafael J. Wysocki (1):
sky2: Fix suspend/hibernation/shutdown regression with WOL enable=
d (rev. 2)

Robert Fitzsimons (1):
tlan: Fix two regressions introduced by 64bit conversion.

Ron Rindjunsky (1):
mac80211: update new sta's rx timestamp

Rusty Russell (2):
net: skb_copy_datagram_from_iovec()
tun: fallback if skb_alloc() fails on big packets

Scott Wood (1):
gianfar: Call gfar_halt_nodisable() from gfar_halt().

Stefan Buehler (1):
tg3: fix 64 bit counter for ethtool stats

Stephen Hemminger (2):
bridge: show offload settings
nf_nat: use secure_ipv4_port_ephemeral() for NAT port randomizati=
on

Vegard Nossum (1):
au1000_eth: use 'unsigned long' for irqflags

Yang Hongyang (1):
ipv6: Fix the return interface index when get it while no message=
is received.

matthieu Barth=E9lemy (1):
rtl8187: Add USB ID for Netgear WG111V3

roel kluin (1):
atl1e: WAKE_MCAST 2x. 1st WAKE_UCAST?

Documentation/rfkill.txt | 5 +
MAINTAINERS | 87 +------
drivers/bluetooth/Kconfig | 10 +-
drivers/bluetooth/bt3c_cs.c | 2 +-
drivers/bluetooth/btusb.c | 282 +++++++++++++++++++=
-
drivers/bluetooth/hci_ldisc.c | 2 +-
drivers/bluetooth/hci_usb.c | 2 +-
drivers/bluetooth/hci_vhci.c | 2 +-
drivers/char/random.c | 1 +
drivers/net/Kconfig | 2 +-
drivers/net/acenic.c | 1 -
drivers/net/arm/ixp4xx_eth.c | 6 +-
drivers/net/atl1e/atl1e_ethtool.c | 2 +-
drivers/net/au1000_eth.c | 2 +-
drivers/net/ax88796.c | 4 +-
drivers/net/bnx2.c | 47 +++-
drivers/net/bnx2x_link.c | 1 -
drivers/net/bnx2x_main.c | 1 -
drivers/net/cpmac.c | 1 -
drivers/net/e1000e/defines.h | 2 +-
drivers/net/e1000e/e1000.h | 1 +
drivers/net/e1000e/ethtool.c | 2 +-
drivers/net/e1000e/netdev.c | 185 ++++++++++++-
drivers/net/e1000e/param.c | 25 ++-
drivers/net/gianfar.c | 6 +-
drivers/net/gianfar_sysfs.c | 1 -
drivers/net/ipg.h | 2 -
drivers/net/ixgbe/ixgbe_82598.c | 1 +
drivers/net/ixgbe/ixgbe_main.c | 4 +-
drivers/net/ixgbe/ixgbe_type.h | 1 +
drivers/net/loopback.c | 67 -----
drivers/net/myri10ge/myri10ge.c | 6 +-
drivers/net/ne.c | 4 +-
drivers/net/netxen/netxen_nic.h | 7 +-
drivers/net/netxen/netxen_nic_hw.c | 59 +++--
drivers/net/netxen/netxen_nic_init.c | 28 +-
drivers/net/netxen/netxen_nic_main.c | 210 +++++++--------
drivers/net/netxen/netxen_nic_phan_reg.h | 2 +
drivers/net/ppp_mppe.c | 1 -
drivers/net/pppol2tp.c | 1 -
drivers/net/r6040.c | 1 -
drivers/net/sh_eth.c | 1 -
drivers/net/sky2.c | 8 +-
drivers/net/tehuti.h | 1 -
drivers/net/tg3.c | 101 ++++++--
drivers/net/tg3.h | 6 +
drivers/net/tlan.c | 8 +-
drivers/net/tun.c | 105 +++++++-
drivers/net/typhoon.c | 1 -
drivers/net/usb/Kconfig | 21 +-
drivers/net/usb/hso.c | 53 +++--
drivers/net/wireless/ath5k/base.c | 9 +-
drivers/net/wireless/ath9k/hw.c | 6 +-
drivers/net/wireless/b43/main.c | 3 +-
drivers/net/wireless/ipw2100.c | 1 -
drivers/net/wireless/ipw2200.c | 1 -
drivers/net/wireless/iwlwifi/iwl-3945.c | 1 -
drivers/net/wireless/iwlwifi/iwl-4965.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 1 -
drivers/net/wireless/iwlwifi/iwl-agn.c | 1 -
drivers/net/wireless/iwlwifi/iwl-core.c | 1 -
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 7 +-
drivers/net/wireless/iwlwifi/iwl-hcmd.c | 1 -
drivers/net/wireless/iwlwifi/iwl-power.c | 1 -
drivers/net/wireless/iwlwifi/iwl-sta.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 4 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 7 +-
drivers/net/wireless/p54/p54common.c | 51 ++--
drivers/net/wireless/p54/p54common.h | 18 +-
drivers/net/wireless/p54/p54usb.c | 10 +
drivers/net/wireless/rt2x00/rt2x00queue.h | 8 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 1 +
drivers/net/wireless/rtl8187_dev.c | 1 +
drivers/ssb/main.c | 8 +
include/linux/if_tun.h | 1 +
include/linux/skbuff.h | 4 +
include/net/addrconf.h | 3 +-
include/net/ip6_route.h | 1 +
include/net/mac80211.h | 11 +-
include/net/sch_generic.h | 2 +-
net/bluetooth/af_bluetooth.c | 2 +-
net/bluetooth/bnep/core.c | 2 +-
net/bluetooth/hci_sysfs.c | 376 ++++++++++++++-----=
--------
net/bluetooth/l2cap.c | 2 +-
net/bluetooth/rfcomm/core.c | 2 +-
net/bluetooth/sco.c | 2 +-
net/bridge/br_device.c | 15 +-
net/core/datagram.c | 87 ++++++
net/core/dev.c | 49 +++--
net/core/gen_estimator.c | 9 +-
net/core/skbuff.c | 12 +-
net/dccp/input.c | 12 +-
net/ipv4/netfilter/ipt_addrtype.c | 2 +-
net/ipv4/netfilter/nf_nat_proto_common.c | 8 +-
net/ipv4/route.c | 76 +++++-
net/ipv6/addrconf.c | 3 +-
net/ipv6/fib6_rules.c | 3 +-
net/ipv6/ip6_fib.c | 1 +
net/ipv6/ip6_output.c | 2 +-
net/ipv6/ipv6_sockglue.c | 4 +-
net/ipv6/ndisc.c | 2 +-
net/ipv6/route.c | 12 +-
net/ipv6/xfrm6_policy.c | 4 +-
net/mac80211/mlme.c | 2 +
net/netfilter/nf_conntrack_netlink.c | 36 ++--
net/rfkill/rfkill.c | 14 +-
net/sched/cls_api.c | 2 +-
net/sched/sch_api.c | 47 ++--
net/sched/sch_cbq.c | 2 +-
net/sched/sch_generic.c | 68 ++----
net/sched/sch_htb.c | 4 +-
net/sched/sch_prio.c | 4 +-
net/sched/sch_tbf.c | 11 +-
net/sctp/ipv6.c | 3 +-
114 files changed, 1533 insertions(+), 898 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-08-19 17:03:07 UTC
Permalink
Post by David Miller
114 files changed, 1533 insertions(+), 898 deletions(-)
David, this absolutely _has_ to stop.

We're after -rc3. Your network merges continue to be too f*cking large,
and this has been going on for many months now. If you cannot throttle
people, I will have to throttle you and stop pulling things.

I'm going to take this, but really - this isn't just new drivers or
something like that that you've used as an excuse for big pulls before,
this is a _lot_ of changes to existing code.

Tell your people to look at the regression list, and if it's not there,
they should stop.

I realize that this problem is partly because when I see the pull requests
from you, I effectively see a combined pull from multiple different
sources, and in that sense it's not quite as big. But the networking pulls
have _consistently_ had the problem that they keep on being big not just
after -rc3, but after -rc4 and on, and I get the distinct feeling that
you're not moving the pain downwards, and aren't telling the people under
you to keep it clean and minimal and regressions only.

For example, those BT updates looked in no way like regression fixes. So
what the f*ck were they doing there? And why do you think all those driver
updates cannot cause new regressions?

If it's not a regression fix, it shouldn't be there. It should be in the
queue for the next version. Why is that apparently so hard for the network
people?

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-08-19 18:27:31 UTC
Permalink
Hi Linus,
Post by Linus Torvalds
For example, those BT updates looked in no way like regression fixes.
the Bluetooth fixes do fix one regression that broke user space
assumptions.

I included additional support for one new driver since I was under the
assumption that new driver support is fine since it can't introduce a
regression. If that has changed then please spell this out and we have
to apply this rule to all subsystems.

Also I cleaned up the MAINTAINERS file entries for Bluetooth. Are these
considered harmful now and should be postponed to the next merge window?
They can obviously not introduce any regressions?

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-08-19 20:54:03 UTC
Permalink
Post by Marcel Holtmann
Also I cleaned up the MAINTAINERS file entries for Bluetooth. Are these
considered harmful now and should be postponed to the next merge window?
They can obviously not introduce any regressions?
What I consider harmful is not any individual commit per se, but the
mindset that clearly says "hey, this particular commit is good, let's
push it up".

And all of the commits are _individually_ fine and the likelihood for
breakage is probably damn low, but when you have lots of them, that
doesn't work any more.

The whole point of the merge window is that you should be sending good,
tested commits _then_. And if you miss the merge window, then you queue
them up for the next one.

As it is, it seems like some people think that the merge window is when
you send any random crap that hasn't even been tested, and then after the
merge window you send the stuff that looks "obviously good".

How about raising your quality control a bit, so that I don't have to
berate you? Send the _obviously good_ stuff during the merge window, and
don't send the "random crap" AT ALL. And then, during the -rc series, you
don't do any "obviously good" stuff at all, but you do the "absolutely
required" stuff.

The rule should be that if you have any doubt _what-so-ever_ that
something is absolutely required, you simply don't send it during the -rc
phase. And if you have any doubt at all about something not working, you
don't send it during the merge window either!

The merge window is not for "let's get this tested, so that we can fix it
during the -rc". And the stabilization phase is not for "this one looks
obviously correct and safe".

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-08-19 21:21:50 UTC
Permalink
From: Linus Torvalds <***@linux-foundation.org>
Date: Tue, 19 Aug 2008 13:54:03 -0700 (PDT)
Post by Linus Torvalds
As it is, it seems like some people think that the merge window is when
you send any random crap that hasn't even been tested, and then after the
merge window you send the stuff that looks "obviously good".
We are perpetuating this mind set, aren't we? I could be wrong
but this is how I see things currently.

I agree, we should be working on regressions fixes now. And we should
essentially be doing so up until the merge window opens up again,
right?

When do people following those rules have time to work on new stuff?
Especially people like me who have to review and merge everyone else's
work as well as help fix bugs.

And not just subsystem maintainers like me, it's also the same for
people who are experienced, dilligent, and work on fixing bugs.
That kind of work is very time consuming.

So given that, who spends a decent amount of time working on features?
People who aren't dilligent working on bugs before the merge window,
and new developers, that's who.

linux-next is great, I love it, it solves all the merge hassles that
used to knock us out during the merge window and make life hell.

But it doesn't fix the time delegation problem.

There is always this "oh crap, I just spent 3 months doing nothing
but fixing bugs" feeling a lot of us core folks get right before
the merge window opens up.

So instead of getting the best work from the best people we have,
we get this last minute flurry of development in the days leading
up to the merge window openning up.

Maybe it's just a longing for the golden era of 2.${ODD}.x style
development, who knows :-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-08-19 21:31:46 UTC
Permalink
Post by David Miller
I agree, we should be working on regressions fixes now.
Not just now. For the last two weeks, yes.
Post by David Miller
And we should essentially be doing so up until the merge window opens up
again, right?
Yes. But any new code should go into another branch (or delayed entirely,
but that probably doesn't work wekk for you guys) so that by the time the
merge window opens up, it's already ready and rearing to go, and
preferably pretty well tested too.

The problem is, you guys end up accepting a lot of stuff even after the
merge window. I know why - it's easy to do. It looks obviously fine. And
yeah, I let things slide.

The problem is, I've let things slide for a long time, and you guys don't
feel the pain.
Post by David Miller
When do people following those rules have time to work on new stuff?
You can work on the new stuff too, but DON'T F*CKING SEND IT TO ME!

What's so hard to understand about that?

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Josh Boyer
2008-08-20 02:25:15 UTC
Permalink
Post by David Miller
But it doesn't fix the time delegation problem.
There is always this "oh crap, I just spent 3 months doing nothing
but fixing bugs" feeling a lot of us core folks get right before
the merge window opens up.
So instead of getting the best work from the best people we have,
we get this last minute flurry of development in the days leading
up to the merge window openning up.
So, not to add fuel to a fire that seems to be calming down, but what is
so wrong with having that feeling? If the core people are spending 3
months doing nothing but fixing bugs, the I consider that to _be_ the
best work from the best people.

Bugs happen and it's not really worth debating over how they got into
the tree to begin with because it happens in a number of different ways.
However, if it takes 3 months of bug fixing to get a tree in shape then
I don't see how that's a problem at all. Personally, I'd rather take a
relatively bug free tree over new shiny features on top of a buggy as
hell tree.

Call me old fashioned.

josh

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-08-20 02:51:15 UTC
Permalink
From: Josh Boyer <***@gmail.com>
Date: Tue, 19 Aug 2008 22:25:15 -0400
Post by Josh Boyer
So, not to add fuel to a fire that seems to be calming down, but what is
so wrong with having that feeling? If the core people are spending 3
months doing nothing but fixing bugs, the I consider that to _be_ the
best work from the best people.
All work and no play makes Dave a dull boy, that's the
problem. :-)

I don't care how much someone claims they enjoy bug fixing
and gathering up other people's patches, you will go out
of your mind or become bored to death if you don't get to
spend real time implementing something significant from
time to time.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Willy Tarreau
2008-08-20 04:20:29 UTC
Permalink
Post by David Miller
Date: Tue, 19 Aug 2008 22:25:15 -0400
Post by Josh Boyer
So, not to add fuel to a fire that seems to be calming down, but what is
so wrong with having that feeling? If the core people are spending 3
months doing nothing but fixing bugs, the I consider that to _be_ the
best work from the best people.
All work and no play makes Dave a dull boy, that's the
problem. :-)
I don't care how much someone claims they enjoy bug fixing
and gathering up other people's patches, you will go out
of your mind or become bored to death if you don't get to
spend real time implementing something significant from
time to time.
That's true and I would also add that it's very common for bugs to
be discovered and fixed while implementing new features. However,
it's so convenient to manage several branches with git that it should
not be a problem to "play" in one branch and push all the stuff during
the merge window only. One of the problems with networking is that you
need a lot of testers. I don't think it's too hard for them to pull
from your development tree. And if it is, maybe you can incite them
from time to time by releasing snapshots as plain patches.

BTW, it also helps testers a lot to be able to play with topic trees
provided as patches against last release, because they generally can
apply them to stable kernels without the fear of losing their data.
I'm sure that many people already run stable kernels with not-yet-merged
patches on top of them and are happy that way.

Regards,
Willy

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Grant Coady
2008-08-20 06:35:42 UTC
Permalink
On Wed, 20 Aug 2008 06:20:29 +0200, Willy Tarreau <***@1wt.eu> wrote:

...
Post by Willy Tarreau
I'm sure that many people already run stable kernels with not-yet-merged
patches on top of them and are happy that way.
Count me as a patch tester -- trying to learn git but I break the thing
too often at the moment :(

Grant.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
John W. Linville
2008-08-20 14:35:19 UTC
Permalink
Post by David Miller
I don't care how much someone claims they enjoy bug fixing
and gathering up other people's patches, you will go out
of your mind or become bored to death if you don't get to
spend real time implementing something significant from
time to time.
Are you talking to me??? :-)

John
--
John W. Linville
***@tuxdriver.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-08-20 03:42:33 UTC
Permalink
Hi Linus,
Post by Linus Torvalds
Post by Marcel Holtmann
Also I cleaned up the MAINTAINERS file entries for Bluetooth. Are these
considered harmful now and should be postponed to the next merge window?
They can obviously not introduce any regressions?
What I consider harmful is not any individual commit per se, but the
mindset that clearly says "hey, this particular commit is good, let's
push it up".
again, my current understanding was that updates to the documentation
that would help people to navigate and understand the kernel better and
make it easier for them to do bug reports etc. are always welcome and
should be pushed immediately. Same goes for new drivers that would
enable people to use their hardware.

If you don't want these patches during the -rc phase, then this is fine
by me. It is no extra work for me to queue these up until the next merge
window. Actually GIT makes merges for me so simple that I couldn't care
less. I was mislead that you want these kind of fixes to go in quickly
and I apologize for the trouble. I will stop bothering Dave with these
from now on and wait until the next merge window.
Post by Linus Torvalds
And all of the commits are _individually_ fine and the likelihood for
breakage is probably damn low, but when you have lots of them, that
doesn't work any more.
The whole point of the merge window is that you should be sending good,
tested commits _then_. And if you miss the merge window, then you queue
them up for the next one.
As it is, it seems like some people think that the merge window is when
you send any random crap that hasn't even been tested, and then after the
merge window you send the stuff that looks "obviously good".
How about raising your quality control a bit, so that I don't have to
berate you? Send the _obviously good_ stuff during the merge window, and
don't send the "random crap" AT ALL. And then, during the -rc series, you
don't do any "obviously good" stuff at all, but you do the "absolutely
required" stuff.
The rule should be that if you have any doubt _what-so-ever_ that
something is absolutely required, you simply don't send it during the -rc
phase. And if you have any doubt at all about something not working, you
don't send it during the merge window either!
The merge window is not for "let's get this tested, so that we can fix it
during the -rc". And the stabilization phase is not for "this one looks
obviously correct and safe".
I get your point! And I was never using the merge window for "random
crap". All my stuff is heavily tested and even on non-x86 systems.

So why does it happen that I touched the MAINTAINERS file outside the
merge window? Simply because I ran into it looking what it says and then
fixed it. And when I had the regression fix for Dave to pull, I picked
the other two patches that couldn't introduce any regression and send it
with it. You don't want these. I get it and from now on they will stay
in my queue until the next merge window.

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
John W. Linville
2008-08-20 14:37:34 UTC
Permalink
Post by Marcel Holtmann
again, my current understanding was that updates to the documentation
that would help people to navigate and understand the kernel better and
make it easier for them to do bug reports etc. are always welcome and
should be pushed immediately. Same goes for new drivers that would
enable people to use their hardware.
This is my (current) understanding as well. If that is not the case,
then someone should clarify.

John
--
John W. Linville
***@tuxdriver.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-08-20 15:30:50 UTC
Permalink
Post by John W. Linville
Post by Marcel Holtmann
again, my current understanding was that updates to the documentation
that would help people to navigate and understand the kernel better and
make it easier for them to do bug reports etc. are always welcome and
should be pushed immediately. Same goes for new drivers that would
enable people to use their hardware.
This is my (current) understanding as well. If that is not the case,
then someone should clarify.
Guys, which part of "it wasn't any individual commit" didn' you
understand?

Why are you concentrating on one documentation commit that I didn't even
point to?

But that said - no, I don't think there is any reason to even push
documentation commits, unless there is a real and pressing reason (ie the
documentation is really important or will really matter from a future
merge standpoint). I generally won't complain about them, but I also don't
see the point.

I'd _much_ rather see you guys queue it up for future merges.

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-08-20 15:40:13 UTC
Permalink
Hi Linus,
Post by Linus Torvalds
Post by John W. Linville
Post by Marcel Holtmann
again, my current understanding was that updates to the documentation
that would help people to navigate and understand the kernel better and
make it easier for them to do bug reports etc. are always welcome and
should be pushed immediately. Same goes for new drivers that would
enable people to use their hardware.
This is my (current) understanding as well. If that is not the case,
then someone should clarify.
Guys, which part of "it wasn't any individual commit" didn' you
understand?
Why are you concentrating on one documentation commit that I didn't even
point to?
But that said - no, I don't think there is any reason to even push
documentation commits, unless there is a real and pressing reason (ie the
documentation is really important or will really matter from a future
merge standpoint). I generally won't complain about them, but I also don't
see the point.
I'd _much_ rather see you guys queue it up for future merges.
John was just pointing out (like myself before) that a lot of people are
under the impression that documentation updates and new drivers should
not be queued up and merged as soon as possible.

I am really fine either way. Queuing them up is not a problem and you
made your point that you don't wanna see them after -rc1. That is fair
enough, but it really needs to be spelled our here since the overall
consensus is different. I will not send any of these do Dave anymore
after the merge window.

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-08-20 16:09:11 UTC
Permalink
Post by Marcel Holtmann
John was just pointing out (like myself before) that a lot of people are
under the impression that documentation updates and new drivers should
not be queued up and merged as soon as possible.
I think (and hey, I'm flexible, and we can discuss this) that the rules
should be:

- by default, the answer should always be "don't push anything after the
merge window unless it fixes a regression or a nasty bug".

Here "nasty bug" is something that is a problem in practice, and not
something theoretical that people haven't really reported.

- but as a special case, we relax that for totally new drivers (and that
includes things like just adding a new PCI or USB ID's to old drivers),
because (a) it can't really regress and (b) support for a specific
piece of hardware can often be critical.

With regard to that second case, I'd like to note that obviously even a
totally new driver _can_ regress, in the sense that it can cause build
errors, or problems that simply wouldn't have happened without that
driver. So the "cannot regress" obviously isn't strictly true, but I
think everybody understands what I really mean.

It should also be noted that the "new driver" exception should only be an
issue for things that _matter_.

For example, a machine without networking support (or without suppoort for
a some other really core driver that provides basic functionality) is
practically useless. But a machine without support for some particular
webcam or support for some special keys on a particular keyboard? That
really doesn't matter, and might as well wait for the next release.

So the "merge drivers early" is for drivers that reasonably _matter_ in
the sense that it allows people to test Linux AT ALL on the platform. It
shouldn't be "any possible random driver".

IOW, think about the drivers a bit like a distro would think about
backporting drivers to a stable kernel. Which ones are really needed?

Also, note that "new driver" really should be that. If it's an older
driver, and you need to touch _any_ old code to add a new PCI ID or
something, the whole argument about it not breaking falls away. Don't do
it. I think, for example, that the SCSI people seem to be a bit too eager
sometimes to update their drivers for new revisions of cards, and they do
it to old drivers.

And finally - the rules should be guidelines. It really isn't always
black-and-white, but most of the time the simple question of "could this
_possibly_ be just queued for the next release without hurting anything"
should be the basic one. If the answer is "yes", then wait.

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jiri Kosina
2008-08-20 16:46:05 UTC
Permalink
Post by Linus Torvalds
- but as a special case, we relax that for totally new drivers (and that
includes things like just adding a new PCI or USB ID's to old drivers),
because (a) it can't really regress
It in fact depends on your definition of regression really :)

If we merge a buggy driver that hangs the user's machine when loaded, well
... before the driver has been merged, the machine had been booting well,
just some hardware was not functioning at all. After this late driver
merge, the driver gets autoloaded upon boot and crashes the machine. Users
will probably see this as a regression.

This doesn't mean that I am against merging new drivers as aggressively as
possible, I just wanted to point out that it might bring actual
regressions to users.
--
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-08-20 17:33:20 UTC
Permalink
Hi Linus,
Post by Linus Torvalds
Post by Marcel Holtmann
John was just pointing out (like myself before) that a lot of people are
under the impression that documentation updates and new drivers should
not be queued up and merged as soon as possible.
I think (and hey, I'm flexible, and we can discuss this) that the rules
- by default, the answer should always be "don't push anything after the
merge window unless it fixes a regression or a nasty bug".
Here "nasty bug" is something that is a problem in practice, and not
something theoretical that people haven't really reported.
- but as a special case, we relax that for totally new drivers (and that
includes things like just adding a new PCI or USB ID's to old drivers),
because (a) it can't really regress and (b) support for a specific
piece of hardware can often be critical.
With regard to that second case, I'd like to note that obviously even a
totally new driver _can_ regress, in the sense that it can cause build
errors, or problems that simply wouldn't have happened without that
driver. So the "cannot regress" obviously isn't strictly true, but I
think everybody understands what I really mean.
It should also be noted that the "new driver" exception should only be an
issue for things that _matter_.
For example, a machine without networking support (or without suppoort for
a some other really core driver that provides basic functionality) is
practically useless. But a machine without support for some particular
webcam or support for some special keys on a particular keyboard? That
really doesn't matter, and might as well wait for the next release.
So the "merge drivers early" is for drivers that reasonably _matter_ in
the sense that it allows people to test Linux AT ALL on the platform. It
shouldn't be "any possible random driver".
IOW, think about the drivers a bit like a distro would think about
backporting drivers to a stable kernel. Which ones are really needed?
Also, note that "new driver" really should be that. If it's an older
driver, and you need to touch _any_ old code to add a new PCI ID or
something, the whole argument about it not breaking falls away. Don't do
it. I think, for example, that the SCSI people seem to be a bit too eager
sometimes to update their drivers for new revisions of cards, and they do
it to old drivers.
And finally - the rules should be guidelines. It really isn't always
black-and-white, but most of the time the simple question of "could this
_possibly_ be just queued for the next release without hurting anything"
should be the basic one. If the answer is "yes", then wait.
I am perfectly fine with these rules. You only had to spell them out :)

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Paolo Ciarrocchi
2008-08-20 18:50:42 UTC
Permalink
Post by Marcel Holtmann
Hi Linus,
Post by Linus Torvalds
Post by Marcel Holtmann
John was just pointing out (like myself before) that a lot of people are
under the impression that documentation updates and new drivers should
not be queued up and merged as soon as possible.
I think (and hey, I'm flexible, and we can discuss this) that the rules
- by default, the answer should always be "don't push anything after the
merge window unless it fixes a regression or a nasty bug".
Here "nasty bug" is something that is a problem in practice, and not
something theoretical that people haven't really reported.
- but as a special case, we relax that for totally new drivers (and that
includes things like just adding a new PCI or USB ID's to old drivers),
because (a) it can't really regress and (b) support for a specific
piece of hardware can often be critical.
With regard to that second case, I'd like to note that obviously even a
totally new driver _can_ regress, in the sense that it can cause build
errors, or problems that simply wouldn't have happened without that
driver. So the "cannot regress" obviously isn't strictly true, but I
think everybody understands what I really mean.
It should also be noted that the "new driver" exception should only be an
issue for things that _matter_.
For example, a machine without networking support (or without suppoort for
a some other really core driver that provides basic functionality) is
practically useless. But a machine without support for some particular
webcam or support for some special keys on a particular keyboard? That
really doesn't matter, and might as well wait for the next release.
So the "merge drivers early" is for drivers that reasonably _matter_ in
the sense that it allows people to test Linux AT ALL on the platform. It
shouldn't be "any possible random driver".
IOW, think about the drivers a bit like a distro would think about
backporting drivers to a stable kernel. Which ones are really needed?
Also, note that "new driver" really should be that. If it's an older
driver, and you need to touch _any_ old code to add a new PCI ID or
something, the whole argument about it not breaking falls away. Don't do
it. I think, for example, that the SCSI people seem to be a bit too eager
sometimes to update their drivers for new revisions of cards, and they do
it to old drivers.
And finally - the rules should be guidelines. It really isn't always
black-and-white, but most of the time the simple question of "could this
_possibly_ be just queued for the next release without hurting anything"
should be the basic one. If the answer is "yes", then wait.
I am perfectly fine with these rules. You only had to spell them out :)
I wonder whether if it would be a good idea to periodically send out an email
with the basic rules to be followed in each phase of the project.


regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-08-19 20:14:54 UTC
Permalink
From: Linus Torvalds <***@linux-foundation.org>
Date: Tue, 19 Aug 2008 10:03:07 -0700 (PDT)
Post by Linus Torvalds
For example, those BT updates looked in no way like regression fixes. So
what the f*ck were they doing there? And why do you think all those driver
updates cannot cause new regressions?
The BT bits were the only part I really considered borderline,
and I was going to push back on Marcel.

But to be honest, I haven't seen bluetooth updates from him
for such a long time I felt that being strict here would just
exacerbate the problem.

Guess I was wrong.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-08-19 20:47:59 UTC
Permalink
Post by David Miller
The BT bits were the only part I really considered borderline,
and I was going to push back on Marcel.
I really don't see the e1000 and netxen updates as being critical either.
Sure, they look like driver improvement, but "improvement" is not what the
-rc3+ series is about.

Same goes for all the loopback changes. They look like cleanups or feature
enables.

IOW, it all looks like good commits, but quite a _lot_ of that queue looks
like good commits that should happen during the merge window, not during
the stabilization phase.

And this is by no means unique to _this_ pull request. It's been a very
clear pattern for a long time now. The networking area tends to be one of
the absolutely *most* active ones during the post-rc1 phase.

[ Yeah, in all fairness some architectures also do that, but at least I
feel like I _really_ don't need to care when I get a diffstat that only
touches arch/sh/* or something like that. ]
Post by David Miller
But to be honest, I haven't seen bluetooth updates from him
for such a long time I felt that being strict here would just
exacerbate the problem.
I pointed out the BT ones as standing out (they were larger than some of
the other patches too), but I really don't think this was in any way
limited to BT in any shape, form or color. Quite frankly, looking through
the thing, my gut feel is that about _half_ the commits over-all should
probably have been in the queue for the next release.

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-08-19 21:04:58 UTC
Permalink
From: Linus Torvalds <***@linux-foundation.org>
Date: Tue, 19 Aug 2008 13:47:59 -0700 (PDT)
Post by Linus Torvalds
Same goes for all the loopback changes. They look like cleanups or feature
enables.
Those fix a performance regression reported by a real user.

Sure I did a cleanup of dead code in one of those commits,
but if you look at the commit beforehand from Herbert, the
context, you can see that it made no sense to leave that
in there any longer as half of what it was standing there
as "documenting" was removed by Herbert's commit.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki
2008-08-19 21:15:47 UTC
Permalink
Post by David Miller
Date: Tue, 19 Aug 2008 13:47:59 -0700 (PDT)
Post by Linus Torvalds
Same goes for all the loopback changes. They look like cleanups or feature
enables.
Those fix a performance regression reported by a real user.
FWIW, they fix the recent regression tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=11316 .

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-08-19 21:28:49 UTC
Permalink
Post by Rafael J. Wysocki
FWIW, they fix the recent regression tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=11316 .
Yeah, and the real cause was apparently another commit that *ALSO*
happened after the merge window!

Guys, you're making excuses for the problem.

The problem that triggered this bugus loopback change was commit
e5a4a72d4f88f4389e9340d383ca67031d1b8536. Look at when that one was done.

This is my whole _point_. The networking layer is doing development during
the -rc window. And you guys are making excuses for it. Wake up, guys!

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-08-19 21:35:56 UTC
Permalink
From: Linus Torvalds <***@linux-foundation.org>
Date: Tue, 19 Aug 2008 14:28:49 -0700 (PDT)
Post by Linus Torvalds
Yeah, and the real cause was apparently another commit that *ALSO*
happened after the merge window!
Guys, you're making excuses for the problem.
The problem that triggered this bugus loopback change was commit
e5a4a72d4f88f4389e9340d383ca67031d1b8536. Look at when that one was done.
This is my whole _point_. The networking layer is doing development during
the -rc window. And you guys are making excuses for it. Wake up, guys!
That change was made under the pretext that it was tested heavily and
that if we hit any problem whatsoever with it that we couldn't fix
quickly it would be reverted.

If you look at the pull request I sent you that contained that change,
I pointed this change out as "highlight" and explained the situation,
in detail. Here it is:

4) Lennert Buytenhek did some really nice analysis on a network
device that cannot do TSO offloading in hardware. He checked
out what happens if you enable the software TSO mechanism fallback
we have in the kernel, and it improves CPU utilization tremendously.

It is safe to do this as long as the device in question can
support scatter-gather.

Herbert and I are discussing a way to do this even more efficiently
with some help from the device (currently the code has to allocate
extra sk_buff objects as we split up the TSO frame, and then do
a bunch of extra page ref counting, when all we need is some headers
and some way to say where the data portion split points are).

If this causes any problems whatsoever, it's trivial to revert this.

Did you read it? I write those for you specifically, so that you know
what changes in there are "of note" and you may want to be aware of.

But anyways, let's chalk this one up as inappropriate.

Looking through the rest of the networking changes in this
pull I see real bug fixes in all of the netxen and e1000
changes that seemed to stand out. All of the wireless stuff
looks like real bug fixes for things reported by real users.

And then there are 2 or 3 cleanups that probably could have
waited.

And then there is the Bluetooth SCO change which I agree was
borderline and I should have pushed back on.

There are simply a lot of people fixing a lot of bugs. And I have to
stay on top of it all. And I also have to be able to trust John
Linville, Jeff Garzik, Marcel, and others so that I don't have to be
checking up on them every single time. I look at what they send me,
and I do push back when I see obviously bogus stuff, but there is a
trust breakpoint.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-08-19 21:46:46 UTC
Permalink
Post by David Miller
That change was made under the pretext that it was tested heavily and
that if we hit any problem whatsoever with it that we couldn't fix
quickly it would be reverted.
David, I will say this one more time:

- as long as you concentrate on individual commits, you're missing the
big picture.

you can _always_ make excuses for individual commits. That's not my point.
Or rather, it actually verry much _is_ my point. If you have the mindset
that you're looking for excuses why any individual commit is ok to merge,
then you don't end up with a coupld of individual commits any more: you
end up with a LOT OF CHURN.

It's not the individual commits. You're looking at the individual trees,
and you're missing the forest. The problem isn't the individual trees. The
problem is that there's a metric sh*tload of individual trees, what we in
the tree industry call a 'forest'. You're not seeing it.

And btw, don't get me wrong - you're not the only problem spot. During the
-rc's leading up to 2.6.26, drivers/merdia was actually a _bigger_
problem. I happen to care less about that (the same way I care less about
some odd-ball architectures), but I have to admit that drivers/media was a
total disaster last time around.

So if it makes you feel any better, others have been even worse. But this
networking problem ha been going on for quite a while.

So the problem here really is that you seem overly eager to make excuses
for individual patches. And if they _stayed_ "individual" it would all be
good. But they don't seem to.

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-08-20 05:22:56 UTC
Permalink
Hi Linus,
Post by Linus Torvalds
And btw, don't get me wrong - you're not the only problem spot. During the
-rc's leading up to 2.6.26, drivers/merdia was actually a _bigger_
problem. I happen to care less about that (the same way I care less about
some odd-ball architectures), but I have to admit that drivers/media was a
total disaster last time around.
to be quite honest, don't you think this is a little bit unfair. So if
it is drivers/media/ or arch/sh/ or whatever you don't care. Do you
actually care what I do in drivers/bluetooth/?

I think that networking and USB are the two most biggest trees of the
kernel and the number of changes they produce are big. And most things
are drivers. I do think that we are doing pretty well in holding back
architectural changes of a subsystem and testing them properly in -mm or
-next before merging them.

The actual drivers make a big portion of Linux and we need them and we
want them. However drivers are the biggest problem for most subsystem
maintainers since they don't own all hardware. And just face it. Most
people that have certain hardware bits are not going to run -next or -mm
kernels. If we get them to test -rc kernels we are lucky.

So drivers/net/ alone is 41M in size. That is a quarter of all drivers/
directory and to be fair the others also contain the actual subsystem in
there while networking maintains it outside that directory.

Just look at your EeePC. Booting a 2.6.26 kernel on it and you have no
Ethernet and no WiFi drivers for the built-in hardware.

I personally think that we need to be conservative for the actual
subsystem changes and a little bit more open for driver changes.
Especially when it comes to new drivers (not a tg3 or e100 driver) since
we wanna ease the entry level to get Linux running. When it comes to
networking, there are just a lot of drivers. Plain simple as that.

And when it comes to architectural or subsystem changes, I think that
the merge window rule is followed quite literal. With minor things
during -rc1 because of merge conflicts, but eventually the -next tree
will solve all of these.

So what about the drivers? Should drivers for new hardware go in? Even
if the maintainers don't think they are stable enough? The current
approach is that even an almost stable driver is better than no driver.
If this no longer applies, then please spell it out and I am more than
happy to oblige.

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-08-20 04:20:13 UTC
Permalink
Hi guys,
Post by David Miller
And then there is the Bluetooth SCO change which I agree was
borderline and I should have pushed back on.
so this is the statement, I sent Dave to explain why that change was in
there:

---
For the btusb driver this adds the promised SCO support. The btusb
driver is a new driver and will eventually replace hci_usb. Adding SCO
support was the last missing piece. All distributions are using the
hci_usb driver at the moment and you can only select one of them. So
this can't introduce any regression. With this change the distributions
are now able to select the new driver if they really want to.
---

Was this absolutely needed after -rc3. Of course not. No questions asked
about it. So why did it ended up in there?

Almost everybody is using the hci_usb driver and that one has issues
that are beyond fixable. So the btusb is its replacement and with this
change it became a real alternate solution. For me this is a new driver
that would allow people to use it in case hci_usb gives them a hard time
and falls over again. And fixing hci_usb is not an option. A lot of
people tried it and they failed. I think the last one was Pavel a month
ago. This is why I re-wrote the whole beast from scratch.

So that is my excuse why I thought this would be good choice to push it
to Dave. No more excuses and no new drivers after the merge window. At
least not from me.

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
d***@lang.hm
2008-08-20 04:47:25 UTC
Permalink
Post by Marcel Holtmann
Post by David Miller
And then there is the Bluetooth SCO change which I agree was
borderline and I should have pushed back on.
so this is the statement, I sent Dave to explain why that change was in
---
For the btusb driver this adds the promised SCO support. The btusb
driver is a new driver and will eventually replace hci_usb. Adding SCO
support was the last missing piece. All distributions are using the
hci_usb driver at the moment and you can only select one of them. So
this can't introduce any regression. With this change the distributions
are now able to select the new driver if they really want to.
---
Was this absolutely needed after -rc3. Of course not. No questions asked
about it. So why did it ended up in there?
Almost everybody is using the hci_usb driver and that one has issues
that are beyond fixable. So the btusb is its replacement and with this
change it became a real alternate solution. For me this is a new driver
that would allow people to use it in case hci_usb gives them a hard time
and falls over again. And fixing hci_usb is not an option. A lot of
people tried it and they failed. I think the last one was Pavel a month
ago. This is why I re-wrote the whole beast from scratch.
So that is my excuse why I thought this would be good choice to push it
to Dave. No more excuses and no new drivers after the merge window. At
least not from me.
one of thr goals of the new release approach was to make releases
frequently enough that it's not a big deal to miss a merge window, you
only have to wait a couple of months (rather then a couple of years under
the old model).

while I don't see a bit problem with drivers going in for previously
unsupported hardware (at least since I custom compile my kernels with all
unnessasary drivers disabled, so I wouldn't even try to compile them ;-)
it doesn't hurt much, either as a user, or for you as a developer (as you
note above) to go ahead and delay till the next merge window.

the benifits of delaying are that the changes in the -rc cycle are clearer
and smaller. this should make the progress towards the release more
obvious, and avoid distractions like the one that started this thread.
yes, this will make the -rc1/-rc2 even bigger as there is more stuff going
in, but it looks like that is being handled well (in part thanks to the
preview that -next is providing)

so as a user/tester I want to thank you for being so willing to delay new
stuff for the next merge window, may others learn to follow your example.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-08-20 05:38:22 UTC
Permalink
Hi David,
Post by d***@lang.hm
Post by Marcel Holtmann
Post by David Miller
And then there is the Bluetooth SCO change which I agree was
borderline and I should have pushed back on.
so this is the statement, I sent Dave to explain why that change was in
---
For the btusb driver this adds the promised SCO support. The btusb
driver is a new driver and will eventually replace hci_usb. Adding SCO
support was the last missing piece. All distributions are using the
hci_usb driver at the moment and you can only select one of them. So
this can't introduce any regression. With this change the distributions
are now able to select the new driver if they really want to.
---
Was this absolutely needed after -rc3. Of course not. No questions asked
about it. So why did it ended up in there?
Almost everybody is using the hci_usb driver and that one has issues
that are beyond fixable. So the btusb is its replacement and with this
change it became a real alternate solution. For me this is a new driver
that would allow people to use it in case hci_usb gives them a hard time
and falls over again. And fixing hci_usb is not an option. A lot of
people tried it and they failed. I think the last one was Pavel a month
ago. This is why I re-wrote the whole beast from scratch.
So that is my excuse why I thought this would be good choice to push it
to Dave. No more excuses and no new drivers after the merge window. At
least not from me.
one of thr goals of the new release approach was to make releases
frequently enough that it's not a big deal to miss a merge window, you
only have to wait a couple of months (rather then a couple of years under
the old model).
while I don't see a bit problem with drivers going in for previously
unsupported hardware (at least since I custom compile my kernels with all
unnessasary drivers disabled, so I wouldn't even try to compile them ;-)
it doesn't hurt much, either as a user, or for you as a developer (as you
note above) to go ahead and delay till the next merge window.
the downside is that users wanna use this hardware have to wait for the
next kernel release. The -next and -mm trees are simply not for
everybody. Even some of the -rc kernels are a pain if you happen to use
a non-x86 system. The kernel developers can fix them easily or know who
to ask for a fix. So decision to include certain driver updates or new
drivers are made from the perspective of the end users.
Post by d***@lang.hm
From a developer perspective if you work on a well separated subsystem
or an individual driver, I can go for many kernel releases without
running into major merge conflicts.

We do have the fast moving targets like wireless. And it is not always
the developers fault. The hardware manufactures are putting out new
chips so fast nowadays that keeping up with the drivers is a hard job.
Also laptop/desktop manufactures are a lot quicker in integrating these
chips and bringing them to market.

I made the EeePC 901 example. A 2.6.26 kernel has no support for the
Ethernet card in it. This happened that last time with a 2.2 kernel
where I bought an Ethernet card that was not supported.

So when it comes to new driver support, it is a judgment call. Some
times we make the wrong one.

Regards

Marcel
Linus Torvalds
2008-08-19 21:21:57 UTC
Permalink
Post by David Miller
Those fix a performance regression reported by a real user.
Since when?

The thing is, I can do a

gitk v2.6.24.. drivers/net/loopback.c

as well as anybody else, and TSO has not been enabled for loopback at
least since 2.6.24. Going back to 2.6.23 (which has more changes that I
won't comment on), it looks like that LOOPBACK_TSO thing you removed was
there back then too.

So the performance regression if it happened must have been due to
something else, no?

Oh, I'm sure that enabling TSO speeds things up, but apparently it also
basically enables a code-path that hasn't been enabled since at least
2.6.23, no?

Really, David. Was the performance regression due to something else, and
then by enabling LOOPBACK_TSO it hid the problem? Or what? The thing is,
-rc3 is _not_ the point to apparently change something that hasn't been
changed in about a year (I didn't go any further back in history).

So what's going on? Do you seriously think it's a good point in time to
enable TSO for loopback after a long time of apparently _not_ being
enabled?

It smells like excuses to me. Was this really a "must be in 2.6.27" thing?

And no, it wouldn't bother me if this was a rare thing. Again, let me
repeat: the problem is not any of the individual commits _per_se_. The
problem is that the network layer stands out. And not in a good way. It
stands out as being a layer that gets a _lot_ of churn late in the -rc
game.

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-08-19 21:27:35 UTC
Permalink
From: Linus Torvalds <***@linux-foundation.org>
Date: Tue, 19 Aug 2008 14:21:57 -0700 (PDT)
Post by Linus Torvalds
Post by David Miller
Those fix a performance regression reported by a real user.
Since when?
Check the regression list entry you were pointed to in another
reply.

But I'll save you some time and I'll explain the problem for you.

We enabled GSO segmentation offload, which is a software variant of
TSO we've had in the tree for ages, when a card can do scatter-gather
and checksumming offloading in HW. We do this because Lennert
Buytenhek validated with many tests that this consistently decreases
cpu utilization.

However, a user reported that if they NAT'd a remote destination port
using netfilter to a loopback addr:port, then there was a performance
degradation.

Herbert discovered the cause, which was multi-fold. And smashing the
SKB checksum and not indicating TSO capability in loopback was the end
cause.

Loopback should enable TSO for other reasons, not just to fix this
bug. If loopback says it can do TSO then the TSO packet gets passed
straight through to the receive side, and our entire stack has been
able to handle that for years.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-08-19 21:33:03 UTC
Permalink
Post by David Miller
Check the regression list entry you were pointed to in another
reply.
I did. You apparently didn't do that yourself.
Post by David Miller
We enabled GSO segmentation offload [ .. ]
yeah. And look at when that happened.

Dammit, all I ask is that you

- admit that you have a problem
- work on fixing it.

Stop the incessant excuses already.

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-08-19 21:40:15 UTC
Permalink
From: Linus Torvalds <***@linux-foundation.org>
Date: Tue, 19 Aug 2008 14:33:03 -0700 (PDT)
Post by Linus Torvalds
Dammit, all I ask is that you
- admit that you have a problem
- work on fixing it.
Stop the incessant excuses already.
I happily consider this example as inappropriate, sure.

But I think you're throwing the baby out with the bath water, the
majority of that pull contained legitimate real bug regression fixes.
That's why some other developers are coming out of the woods and
defending me, they don't have to do that, but they do it because they
feel I'm being slighted at least a little bit.

I don't know what to say, because I spent most of my sunny weekend
working on bug fixes as well as integrating other people's work.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-08-19 21:50:36 UTC
Permalink
Post by David Miller
But I think you're throwing the baby out with the bath water, the
majority of that pull contained legitimate real bug regression fixes.
.. and notice how I

(a) took it

and

(b) am asking for you to be more careful?

In other words, I would be a lot happier if you didn't say "majority". I
would be a ton happioer if you could HONESTLY say that every single one
was a regression.

And the thing is, you cannot. Some of the ones I pointed you to were
actually regressions due to _other_ patches you had much too happily sent
me after the merge window had already closed).
Post by David Miller
That's why some other developers are coming out of the woods and
defending me, they don't have to do that, but they do it because they
feel I'm being slighted at least a little bit.
Umm. The only defending I have seen was a F*CKING DISGRACE, since nobody
apparently had the balls to stand up and admit that the whole problem
happened after -rc1 in the first place!

In other words, the "defense" was just making excuses for EXACTLY the
behaviour I'm trying to tell you shouldn't have happened in the first
place.

Please. You're still making excuses for this, even after I pointed out
that ALL of the problems with the whole loopback driver thing happened
after the merge window.

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-08-19 21:56:47 UTC
Permalink
From: Linus Torvalds <***@linux-foundation.org>
Date: Tue, 19 Aug 2008 14:50:36 -0700 (PDT)
Post by Linus Torvalds
In other words, I would be a lot happier if you didn't say "majority". I
would be a ton happioer if you could HONESTLY say that every single one
was a regression.
And the thing is, you cannot. Some of the ones I pointed you to were
actually regressions due to _other_ patches you had much too happily sent
me after the merge window had already closed).
Fair enough.
Evgeniy Polyakov
2008-08-19 22:26:12 UTC
Permalink
Post by Linus Torvalds
And the thing is, you cannot. Some of the ones I pointed you to were
actually regressions due to _other_ patches you had much too happily sent
me after the merge window had already closed).
... phisiological thoughts skipped ...
Post by Linus Torvalds
Please. You're still making excuses for this, even after I pointed out
that ALL of the problems with the whole loopback driver thing happened
after the merge window.
I belive it was you who told that there is no black and white (another
guy told that there is no spoon, I frequntly confuse).

Any changes made no matter when can not be 100% tested in laboratory
environment, even fixes, which look obviously. Even changes which do fix
some problems can introduce another. And some fixes can introduce
problems, which are not immediately shown in majority of the tests, so
changes on top of them can look like introducing new bugs. If you have
multiple changes and result which produce an error, it does not mean
that the last one was wrong. Of course it can, but 'there is no black
and white', and in really complex system only trivial changes can be
thought of not touching others. The same applies to loopback. So this
particular note is just about the fact, that fixing regression means
either reverting a change or introducing a new change. The latter is
preferred (or at least should be), since it is a move forward.

According to other changes, which you believe are not suitable for the
post merge window releases... People do know that major changes are not
allowed to be made, but there are always last strikes in the head which
are supposed to fix problems, not to introduce new ones. Where did you
see experimental code in -rc cycle? Where did you see patches which
break things without bringing improvement at that time? Yes, there
changes which are not supposed to be in the tree at that time, but
that's just a development process, which even in a short run makes good
result. Regressions and bugs are fixed, and things are not getting worse
with time.
--
Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-08-19 22:40:35 UTC
Permalink
Post by Evgeniy Polyakov
I belive it was you who told that there is no black and white (another
guy told that there is no spoon, I frequntly confuse).
Yes.
Post by Evgeniy Polyakov
Any changes made no matter when can not be 100% tested in laboratory
environment, even fixes, which look obviously.
100% agreed.

Please note that I'm not against these things slipping in occasionally.
The reason I brought this up in the first place really wasn't the loopback
driver issue at all. The reason I brought it up was simply the fact that
when I compare the size and frequency of changes, the networking pulls
tend to be the worst of the lot of the "core" kernel changes.

I say "core" kernel changes, because things are usually worse for the
outliers. As mentioned, networking is actually one of the _better_ guys if
you start comparing to the DVB people, or to some of the architectures
that often slip the merge window _entirely_, and *all* their changes come
in during -rc2 or something.

So it's not that networking is especially bad on an absolute scale in this
regard. And it's not like it doesn't happen all the time for everybody
else too. But I think networking has ben a bit more cavalier about things
than many other core areas.

So no, I'm not asking for black-and-white absolutes here. But I'm asking
for a "tightening of the belts". Please don't let it all hang out, ok?

Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-08-19 22:52:16 UTC
Permalink
From: Linus Torvalds <***@linux-foundation.org>
Date: Tue, 19 Aug 2008 15:40:35 -0700 (PDT)
Post by Linus Torvalds
So no, I'm not asking for black-and-white absolutes here. But I'm asking
for a "tightening of the belts". Please don't let it all hang out, ok?
I'm in agreement :)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-08-20 06:15:46 UTC
Permalink
Hi Linus,
Post by Linus Torvalds
Post by Evgeniy Polyakov
I belive it was you who told that there is no black and white (another
guy told that there is no spoon, I frequntly confuse).
Yes.
Post by Evgeniy Polyakov
Any changes made no matter when can not be 100% tested in laboratory
environment, even fixes, which look obviously.
100% agreed.
Please note that I'm not against these things slipping in occasionally.
The reason I brought this up in the first place really wasn't the loopback
driver issue at all. The reason I brought it up was simply the fact that
when I compare the size and frequency of changes, the networking pulls
tend to be the worst of the lot of the "core" kernel changes.
I say "core" kernel changes, because things are usually worse for the
outliers. As mentioned, networking is actually one of the _better_ guys if
you start comparing to the DVB people, or to some of the architectures
that often slip the merge window _entirely_, and *all* their changes come
in during -rc2 or something.
So it's not that networking is especially bad on an absolute scale in this
regard. And it's not like it doesn't happen all the time for everybody
else too. But I think networking has ben a bit more cavalier about things
than many other core areas.
I was always under the impression that Dave was quite strict when it
comes to merging things after the merge window. Yes, some things should
have better waiting for the next release, but we always had exceptions
for various things that fall out of the merge window anyway.

All the small "soldiers" like me make a call on what to pick to send to
Dave and it is not that we try to sneak anything in. It just made sense
to us and either he agrees or not. Some choices are better than others,
no questions asked, but I think what you are seeing is that networking
is getting huge. And this is mostly networking drivers. And I don't
expect this to slow down or anything. The Linux WiFi support is just at
the edge to really become competitive and show real leading across all
other operating systems.

When looking at the actual split between net/ and drivers/, then the
drivers part is the big one. And I don't expect this to go down any time
soon. We are about to get Ultra-Wideband support merged. After that we
will have plain networking over UWB, Wireless USB using UWB and soon
Bluetooth over UWB. Also we will see Bluetooth over 802.11 and then
another Ultra-Low-Power thing for sensor devices. And I forget WiMAX.
That is just the short term wireless future. Every of these come with
new networking drivers and then you have new Ethernet drivers and so on.
It is just a lot of stuff.

While looking at the actual diffstat, I realized that I really was the
biggest offender:

net/bluetooth/hci_sysfs.c | 376 ++++++++++++++-------------

This is actually the regression fix. It is big, because thanks to sysfs,
I had to move some code around in that file and rename things. I should
have seen that earlier and gave Dave an extra comment why it is so big.
That was my bad. Sorry for that.

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Denys Fedoryshchenko
2008-08-19 21:39:08 UTC
Permalink
Post by Linus Torvalds
Oh, I'm sure that enabling TSO speeds things up, but apparently it also
basically enables a code-path that hasn't been enabled since at least
2.6.23, no?
Well i report about performance regression before too, seems related case,
but my report was unclear.

And the bug was terrible for me, it was causing very bad performance on
REDIRECT and loopback transfers. I am testing also recent net-2.6 with this
loopback changes, it seems improve things for me much. So it is really
important bugfix for me too.

There is always chances that some fix will cause regression, i will try to
test this changes on intensive real-life workloads to make sure all fine.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Evgeniy Polyakov
2008-08-19 21:15:14 UTC
Permalink
Post by Linus Torvalds
I really don't see the e1000 and netxen updates as being critical either.
Sure, they look like driver improvement, but "improvement" is not what the
-rc3+ series is about.
Netxen driver update contains bug fixes (leak and races) and hardware
workaround. Well, it has driver version bump either, I agress, that
one was an error. E1000 contains number of regression fixes and
performance improvement via module parameter change.
Post by Linus Torvalds
Same goes for all the loopback changes. They look like cleanups or feature
enables.
It fixes performance regression.
--
Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-08-20 03:43:52 UTC
Permalink
Hi Dave,
Post by David Miller
Post by Linus Torvalds
For example, those BT updates looked in no way like regression fixes. So
what the f*ck were they doing there? And why do you think all those driver
updates cannot cause new regressions?
The BT bits were the only part I really considered borderline,
and I was going to push back on Marcel.
But to be honest, I haven't seen bluetooth updates from him
for such a long time I felt that being strict here would just
exacerbate the problem.
Guess I was wrong.
as I explained to Linus, my current assumption was that documentation
updates and new driver stuff should go in quickly. You will not get any
of these from me anymore. Next time you only get the one regression fix
and all my queued up stuff in the next merge window.

Don't hold back if you think that a patch is not acceptable. Really, I
am using GIT for everything. Merging is no problem for me. I also do
backports in my -mh patch for the latest stable kernel. So there is no
extra work for me. It is just sending you a new email with another tree
to pull from :)

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-08-23 12:24:03 UTC
Permalink
Here are some bug fixes:

1) Zebra routing daemon is confused because ipv6 netlink
event messages don't set the protocol field properly
like ipv4 ones do. Fix from Stephen Hemminger.

2) Insufficient qdisc list locking leads to Qdisc corruption
and oops. Fix from Jarek Poplawski.

3) Qdisc watchdog timer can race with dev_deactivate(), put
state tests in the slow path to prevent this. Also from
Jarek Poplawski.

4) Several SCTP-AUTH sock options are user OOPS'able. Fix from Vlad
Yasevich.

5) Fix smp_processor_id() usage by icmp_sk(), needs to disable
preemption. Fix from Denis V. Lunev

Please pull, thanks a lot.

The following changes since commit 6a55617ed5d1aa62b850de2cf66f5ede2eef4825:
Linus Torvalds (1):
Linux v2.6.27-rc4

are available in the git repository at:

master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master

Denis V. Lunev (1):
icmp: icmp_sk() should not use smp_processor_id() in preemptible code

Jarek Poplawski (2):
pkt_sched: Fix qdisc_watchdog() vs. dev_deactivate() race
pkt_sched: Fix qdisc list locking

Stephen Hemminger (1):
ipv6: protocol for address routes

Vlad Yasevich (1):
sctp: fix potential panics in the SCTP-AUTH API.

include/net/pkt_sched.h | 1 +
include/net/sch_generic.h | 5 +++
net/ipv4/icmp.c | 22 +++++++----
net/ipv6/addrconf.c | 1 +
net/ipv6/icmp.c | 23 ++++++------
net/sched/sch_api.c | 48 +++++++++++++++++++++++---
net/sched/sch_cbq.c | 4 ++
net/sched/sch_generic.c | 5 +--
net/sctp/endpointola.c | 4 +-
net/sctp/socket.c | 85 ++++++++++++++++++++++++++++++++++----------
10 files changed, 149 insertions(+), 49 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-08-27 23:46:49 UTC
Permalink
1) Build fix of 8390 layer from Alan Cox.

2) IGB driver bug fixes from Alexander Duyck:
a) Incorrect VLAN register programming
b) Fix RX hang condition by forcing all queues to interrupt every=
2 secs
c) ethtool -d accidently masks off interrupts, whoops...
d) Fix setting of number of TX queues when in MSI-X only mode
e) Remove 82576 quad adapter PCI IDs, these don't work properly y=
et

3) Add new device ID for MCS7830 USB adapter, from Arnd Bergmann

4) In forcedeth driver, make the checksum feature setting match what th=
e
hardware can actually do, from Ayaz Abdulla.

5) ibm_newemac calls dev_mc_add() before the device is even registered,
fix from Benjamin Herrenschmidt.

6) Two atmel wireless driver fixes from Dan Williams:
a) Try open system authentication when shared key fails.
b) Return correct error code on request_firmware() failure

7) Two HSO driver fixes from Denis Joseph Barrow
a) dev_kfree_skb() called twice on same packet during resume
b) Icon-322 entry in hsi_ids[] table was incorrect

8) Eugene Teo noticed some bogus capability checks in SBNI wan
driver, it was doing direct checks of current->euid :-)

9) rfkill_claim_show() was missing a line break in output,
from Felipe Balbi.

10) r8169 DMA mapping leak fix from Francois Romieu, size argument
to pci_unmap_single() was incorrect.

11) qeth driver should use -EOPNOTSUPP instead of -ENOTSUPP, from
Ursula Braun. Also, qeth forgets to post unicast address list
to the hardware in some circumstances, from Frank Blaschka.

12) fs_enet_rx_napi() crash fix in fs_enet driver from Heiko Schocher.

13) Hugh Dickins fixed a brown paper bag issue in the recent ipv4
sysctl bits from Al Viro.

14) Missing braces in atl1e driver, fix from Ilpo Jarvinen.

15) MAC80211 layer fix from Jan-Espen Pettersen so that we do not
emit empty extended rates IE frames.

16) Four packet scheduler layer locking fixes from Jarek Poplawski:
a) dev_graft_qdisc() locks the wrong qdisc
b) Same problem in sch_tree_lock()
c) Some dev_queue->qdisc assignments were missing rcu_assign_pointe=
r()
d) Wrong qdisc root passed to gen_replace_estimator(), thus wrong
qdisc being locked by that code.

17) atl1 is showing problems now that TSO was enabled by default, turn
it back off by default until we know what the problem is, from
Jay Cliburn.

18) Fix smc91x null pointer deref in resource removal, from Jeff Garzik=
=2E

19) e100 uses plain readX() on iomap memory, from Jiri Slaby

20) Two ath5k bug fixes from Jiri Slaby:
a) Beacon set and config can race with beacon sendng
b) bintval needs to be setup earlier to be accurate

21) Lower verbosity of IBSS merge messages, they sometimes happen
a lot, from John Linville.

22) Two mac80211 bug fixes from Jouni Malinen:
a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
IWEVASSOCREQIE has
b) Fix debugfs entry corruption due to entries being left
behind accidently with references to freed memory

23) __mesh_table_free() called with wrong table pointer when
mesh_table_grow() fails, from Julia Lawall.

24) S390 LCS driver forgets to check CPA state in interrupt handler,
resulting in incorrect behavior when recovery is driven after cable
reconnect, fix from Klaus-D. Wacker.

25) mv643xx_eth fixes from Lennert Buytenhek:
a) Interrupt handler needs to ACK RX irq before processing the ring
to avoid a race that can get packets wedged and never processed.
b) accidental double add_timer() in receive OOM handling
c) Need to use IRQ safe locks in mv643xx_eth_poll or else we deadlo=
ck
d) fix NULL pointer deref in rxq_process()
e) chip has 8 byte multiple size restriction for buffers on receive=
,
but this isn't being enforced everywhere it needs to be

26) Memory leak fix in claw_probe() from Martin Schwidefsky.

27) claw and ctcm drivers were non-functional because they were using
netdev->priv as a mid-layer private pointer, but that doesn't work
because netdev->priv is where the generic networking stores the
private memory allocated at alloc_netdev() time.

We have a netdev->ml_priv pointer that fits the need here, so we
convert things to use that to fix this bug, from Peter Tiedemann.

28) TCP header size miscalculation when eliding window scaling, fix
from Philip Love.

29) ibmveth transmits incorrect UDP checksums, fix from Santiago Leon.

30) gianfar grabs a mutex in softirq context, oops, fix from Sebastian =
Siewior.

31) Two more SCTP overflow fixes from Vlad Yasevich based upon feedback
from Eugene Teo. I have to ship these two off to -stable as well.

Please pull, thanks a lot!

The following changes since commit c2d42545774c4bba7232521d836d0793330e=
3a4e:
Eilon Greenstein (1):
bnx2x: Version update

are available in the git repository at:

master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master

Alan Cox (1):
[netdrvr] fix build issue: undefined reference to `NS8390p_init'

Alexander Duyck (5):
ixgbe: fix vlan filtering
igb: force all queues to interrupt once every 2 seconds
igb: ethtool -d reads EICR which is incorrect as it is read on cl=
ear
igb: fix setting the number of tx queues
igb: remove 82576 quad adapter

Arnd Bergmann (1):
net/usb/mcs7830: new device IDs

Ayaz Abdulla (1):
forcedeth: fix checksum flag

Benjamin Herrenschmidt (1):
ibm_newemac: Don't call dev_mc_add() before device is registered

Brice Goglin (1):
myri10ge: update version string to 1.4.3-1.358

Dan Williams (2):
atmel: return ENOENT on request_firmware failure
atmel: try open system authentication too

David S. Miller (2):
Merge branch 'davem-fixes' of master.kernel.org:/.../jgarzik/netd=
ev-2.6
Merge branch 'no-iwlwifi' of git://git.kernel.org/.../linville/wi=
reless-2.6

Denis Joseph Barrow (2):
[netdrvr] hso: icon 322 detection fix
[netdrvr] hso: dev_kfree_skb crash fix

Eugene Teo (1):
wan: Missing capability checks in sbni_ioctl()

=46elipe Balbi (1):
net: rfkill: add missing line break

=46rancois Romieu (1):
r8169: balance pci_map / pci_unmap pair

=46rank Blaschka (2):
qeth: l2 write unicast list to hardware
qeth: preallocated header account offset

Heiko Schocher (1):
fs_enet: Fix SCC Ethernet on CPM2, and crash in fs_enet_rx_napi()

Hugh Dickins (1):
ipv4: mode 0555 in ipv4_skeleton

Ilpo J=C3=A4rvinen (1):
atl1e: multistatement if missing braces

Jan-Espen Pettersen (1):
mac80211: don't send empty extended rates IE

Jarek Poplawski (4):
pkt_sched: Fix dev_graft_qdisc() locking
pkt_sched: Use rcu_assign_pointer() to change dev_queue->qdisc
pkt_sched: Fix gen_estimator locks
pkt_sched: Fix sch_tree_lock()

Jay Cliburn (1):
atl1: disable TSO by default

Jeff Garzik (2):
Merge branch 'for-2.6.27' of git://git.marvell.com/mv643xx_eth in=
to upstream-fixes
[netdrvr] smc91x: fix resource removal (null ptr deref)

Jiri Slaby (3):
Ath5k: lock beacons
Ath5k: fix bintval setup
e100, fix iomap read

John W. Linville (1):
mac80211: quiet chatty IBSS merge message

Jouni Malinen (2):
mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
mac80211: Fix debugfs file add/del for netdev

Julia Lawall (1):
net/mac80211/mesh.c: correct the argument to __mesh_table_free

Klaus-D. Wacker (1):
LCS recovery dumps when cable reconnect

Lennert Buytenhek (6):
mv643xx_eth: fix NAPI 'rotting packet' issue
mv643xx_eth: fix double add_timer() on the receive oom timer
mv643xx_eth: fix inconsistent lock semantics
mv643xx_eth: fix NULL pointer dereference in rxq_process()
mv643xx_eth: enforce multiple-of-8-bytes receive buffer size rest=
riction
mv643xx_eth: bump version to 1.3

Martin Schwidefsky (1):
claw: fix memory leak in claw_probe.

Mike Frysinger (1):
Blackfin EMAC Driver: the BF526 also supports the MAC,

Oliver Martin (1):
net/usb/mcs7830: add set_mac_address

Peter Tiedemann (2):
claw: netdev->priv vs. netdev->ml_priv
ctcm: netdev->priv vs. netdev->ml_priv

Philip Love (1):
tcp: fix tcp header size miscalculation when window scale is unus=
ed

Santiago Leon (1):
ibmveth: fix bad UDP checksums

Sebastian Siewior (1):
net: don't grab a mutex within a timer context in gianfar

Takashi Iwai (1):
drivers/net/skfp/ess.c: fix compile warnings

Ursula Braun (1):
qeth: use -EOPNOTSUPP instead of -ENOTSUPP.

Vlad Yasevich (2):
sctp: correct bounds check in sctp_setsockopt_auth_key
sctp: fix random memory dereference with SCTP_HMAC_IDENT option.

arch/powerpc/include/asm/cpm2.h | 5 ++
drivers/net/Kconfig | 6 +-
drivers/net/atl1e/atl1e_main.c | 3 +-
drivers/net/atlx/atl1.c | 1 -
drivers/net/e100.c | 4 +-
drivers/net/forcedeth.c | 4 +-
drivers/net/fs_enet/fs_enet-main.c | 8 ++++
drivers/net/fs_enet/mac-scc.c | 8 +++-
drivers/net/gianfar.c | 22 ++++++++--
drivers/net/gianfar.h | 1 +
drivers/net/ibm_newemac/core.c | 6 +-
drivers/net/ibmveth.c | 5 +-
drivers/net/igb/e1000_82575.c | 1 -
drivers/net/igb/e1000_hw.h | 1 -
drivers/net/igb/igb_ethtool.c | 17 +++-----
drivers/net/igb/igb_main.c | 25 +++++------
drivers/net/ixgbe/ixgbe_main.c | 8 ++-
drivers/net/mv643xx_eth.c | 35 +++++++++-------
drivers/net/myri10ge/myri10ge.c | 2 +-
drivers/net/r8169.c | 2 +-
drivers/net/skfp/ess.c | 6 +-
drivers/net/smc91x.c | 2 +-
drivers/net/usb/hso.c | 3 +-
drivers/net/usb/mcs7830.c | 47 +++++++++++++++++++++-
drivers/net/wan/sbni.c | 8 ++--
drivers/net/wd.c | 2 +-
drivers/net/wireless/ath5k/base.c | 23 ++++++++---
drivers/net/wireless/ath5k/base.h | 1 +
drivers/net/wireless/atmel.c | 51 ++++++++++++++---------
drivers/s390/net/claw.c | 79 +++++++++++++++++-----------=
-------
drivers/s390/net/ctcm_fsms.c | 56 +++++++++++++-------------
drivers/s390/net/ctcm_main.c | 24 +++++-----
drivers/s390/net/ctcm_main.h | 9 ++--
drivers/s390/net/ctcm_mpc.c | 46 ++++++++++----------
drivers/s390/net/lcs.c | 3 +-
drivers/s390/net/qeth_core.h | 1 +
drivers/s390/net/qeth_core_main.c | 2 +-
drivers/s390/net/qeth_l2_main.c | 27 ++++++++++--
drivers/s390/net/qeth_l3_sys.c | 2 +-
include/net/sch_generic.h | 12 +++++-
net/ipv4/route.c | 4 +-
net/ipv4/tcp_output.c | 6 ++-
net/mac80211/debugfs_netdev.c | 24 +++++-----
net/mac80211/ieee80211_i.h | 6 +++
net/mac80211/mesh.c | 2 +-
net/mac80211/mlme.c | 52 +++++------------------
net/rfkill/rfkill.c | 2 +-
net/sched/sch_api.c | 18 ++++++--
net/sched/sch_cbq.c | 4 +-
net/sched/sch_generic.c | 4 +-
net/sched/sch_hfsc.c | 4 +-
net/sched/sch_htb.c | 4 +-
net/sctp/auth.c | 3 +
net/sctp/socket.c | 8 ++-
54 files changed, 413 insertions(+), 296 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alex Williamson
2008-09-05 15:08:12 UTC
Permalink
Post by David Miller
a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
IWEVASSOCREQIE has
This one breaks wireless with 32bit userspace/64bit kernel. Bisected
back to changeset 087d833e5a9f67ba933cb32eaf5a2279c1a5b47c:

mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
--
Alex Williamson HP Open Source & Linux Org.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds
2008-09-05 17:45:11 UTC
Permalink
Post by Alex Williamson
Post by David Miller
a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
IWEVASSOCREQIE has
This one breaks wireless with 32bit userspace/64bit kernel. Bisected
mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
Grr. I'd love to say "I told you so", and write another rant about -rc
series patches. But I'm too lazy, so people - please mentally insert my
standard rant here.

David/Jouni - just revert it?

Linus
John W. Linville
2008-09-05 18:17:04 UTC
Permalink
Post by Linus Torvalds
Post by Alex Williamson
Post by David Miller
a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
IWEVASSOCREQIE has
This one breaks wireless with 32bit userspace/64bit kernel. Bisected
mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
Grr. I'd love to say "I told you so", and write another rant about -rc
series patches. But I'm too lazy, so people - please mentally insert my
standard rant here.
David/Jouni - just revert it?
Yes, just revert it.

Jouni, feel free to send me a new version for 2.6.28.

Thanks,

John
--
John W. Linville
***@tuxdriver.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jouni Malinen
2008-09-09 02:44:12 UTC
Permalink
Post by Alex Williamson
Post by David Miller
a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
IWEVASSOCREQIE has
By the way, that description is incorrect; the change was in the other
direction (i.e., to use IWSSOCREQIE).
Post by Alex Williamson
This one breaks wireless with 32bit userspace/64bit kernel. Bisected
mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
Great.. I was hoping that the WEXT compat ioctl fixes from Dave resolved
all WEXT cases. This code is (and was) using wireless_send_event() and I
did not find clear changes to its use in Dave's patch set. Was that
supposed to be fixed with the compat ioctl patches? I'm not very
familiar with this area and don't have an easy way to test this now (I'm
traveling and don't have access to a 64/32-bit setup).

As far as I can tell, the commit mentioned here is correct in itself,
but it looks like the WEXT code would not handle something properly for
wireless_send_event(). I'm not sure why IWEVCUSTOM would work any
better, but well, maybe it does not have some fields that get wrong in
64/32 case or the previous working case ended up getting the
too-long-buffer error which prevented the message from being processed
in userspace).

What exactly does "breaks wireless" mean here?

As far as resolving this quickly is concerned, reverting the change is
fine; this is not a critical issue with most use cases. Anyway, this
should really be fixed eventually, but it looks like someone would need
to fix WEXT for wireless_send_event() first..

- Jouni
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-09-09 02:46:27 UTC
Permalink
I'm so entirely tired of reading these 300+ column emails today that
I'm just flat out refusing to read this one.

People, fix your setup please! And if you have to get your email
client to auto format your outgoing email text for you, that's fine.
Although I can't understand why folks are too lazy to type enter every
80 columns or so.

It's funny how something so fundamental that everyone could get
right 15 years ago, is now such an epidemic problem. :-/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jouni Malinen
2008-09-09 02:55:25 UTC
Permalink
Post by David Miller
I'm so entirely tired of reading these 300+ column emails today that
I'm just flat out refusing to read this one.
People, fix your setup please! And if you have to get your email
client to auto format your outgoing email text for you, that's fine.
Although I can't understand why folks are too lazy to type enter every
80 columns or so.
Hmm.. I was using my temporary thunderbird setup and it is configured to
wordwrap at 72 character lines.. The mail server may have done something
odd, though. The version of the message I received directly at w1.fi was
word wrapped, so I have no idea what happened here. Anyway, since the
message was discussing your patchset, here's another version from mutt
(and another mail server) and which will hopefully show up in more
reasonable format.
Post by David Miller
Post by David Miller
a) Use IWEVCUSTOM so that we don't hit the 256 byte limit that
IWEVASSOCREQIE has
By the way, that description is incorrect; the change was in the other
direction (i.e., to use IWSSOCREQIE).
Post by David Miller
This one breaks wireless with 32bit userspace/64bit kernel. Bisected
mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
Great.. I was hoping that the WEXT compat ioctl fixes from Dave resolved
all WEXT cases. This code is (and was) using wireless_send_event() and I
did not find clear changes to its use in Dave's patch set. Was that
supposed to be fixed with the compat ioctl patches? I'm not very
familiar with this area and don't have an easy way to test this now (I'm
traveling and don't have access to a 64/32-bit setup).

As far as I can tell, the commit mentioned here is correct in itself,
but it looks like the WEXT code would not handle something properly for
wireless_send_event(). I'm not sure why IWEVCUSTOM would work any
better, but well, maybe it does not have some fields that get wrong in
64/32 case or the previous working case ended up getting the
too-long-buffer error which prevented the message from being processed
in userspace).

What exactly does "breaks wireless" mean here?

As far as resolving this quickly is concerned, reverting the change is
fine; this is not a critical issue with most use cases. Anyway, this
should really be fixed eventually, but it looks like someone would need
to fix WEXT for wireless_send_event() first..

- Jouni
--
Jouni Malinen PGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-09-09 03:43:23 UTC
Permalink
From: Jouni Malinen <***@w1.fi>
Date: Mon, 8 Sep 2008 19:55:25 -0700
Post by Jouni Malinen
Post by Alex Williamson
This one breaks wireless with 32bit userspace/64bit kernel. Bisected
mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
Great.. I was hoping that the WEXT compat ioctl fixes from Dave resolved
all WEXT cases. This code is (and was) using wireless_send_event() and I
did not find clear changes to its use in Dave's patch set. Was that
supposed to be fixed with the compat ioctl patches? I'm not very
familiar with this area and don't have an easy way to test this now (I'm
traveling and don't have access to a 64/32-bit setup).
If we're talking about the netlink emission of WEXT blobs, then such
bits cannot be fixed unfortunately, because via netlink we don't know
in the message generating context what kind of process will receive
the message.

In fact, when broadcasting a netlink message, applications of different
dispositions can want to receive the message.

So in essence netlink cases cannot be fixed for COMPAT handling,
rather, netlink protocols must be designed to be COMPAT agnostic from
the beginning, and use fixed sized types only. WEXT was not.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jouni Malinen
2008-09-09 04:05:25 UTC
Permalink
Post by David Miller
If we're talking about the netlink emission of WEXT blobs, then such
bits cannot be fixed unfortunately, because via netlink we don't know
in the message generating context what kind of process will receive
the message.
OK. Interesting point here is that the old code was using IWEVCUSTOM
which is defined as having header_type IW_HEADER_TYPE_POINT and so are
the new IWEVASSOCREQIE and IWEVASSOCRESPIE. The only difference is in
max_tokens specifying different maximum length for the data. Maybe the
old code was also broken, but wpa_supplicant handled the bogus data
without causing problems (text parsing failing instead of some
parameters being set based on bogus binary data).
Post by David Miller
In fact, when broadcasting a netlink message, applications of different
dispositions can want to receive the message.
So in essence netlink cases cannot be fixed for COMPAT handling,
rather, netlink protocols must be designed to be COMPAT agnostic from
the beginning, and use fixed sized types only. WEXT was not.
I haven't looked how IW_HEADER_TYPE_POINT headers get encoded with
wireless_send_event(), but it sounds likely something there gets
different field size. It sounds like there is not really a good
solution for this with the current iw event types and should we want to
get the original issue fixed, something new would need to be
specified.. Would people be fine with extending wireless_send_event()
with new event types that use fixed sized fields or is someone going to
be interesting in providing a better replacement for this functionality?
--
Jouni Malinen PGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-09-09 04:15:48 UTC
Permalink
From: Jouni Malinen <***@w1.fi>
Date: Mon, 8 Sep 2008 21:05:25 -0700
Would people be fine with extending wireless_send_event() with new
event types that use fixed sized fields or is someone going to be
interesting in providing a better replacement for this
functionality?
I thought this was the idea behind nl80211? To be a new netlink
interface for wireless, one that actually is designed correctly
from the start and thus can avoid all of these problems.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jouni Malinen
2008-09-09 05:34:39 UTC
Permalink
Post by David Miller
Would people be fine with extending wireless_send_event() with new
event types that use fixed sized fields or is someone going to be
interesting in providing a better replacement for this
functionality?
I thought this was the idea behind nl80211? To be a new netlink
interface for wireless, one that actually is designed correctly
from the start and thus can avoid all of these problems.
Well, this wireless_send_event() is the part of WEXT that no one has
worked with replacing yet as far as I'm aware.. The currently available
infrastructure in nl80211 can be relatively easily extended to handle
all other functionality, but unless I've missed something, this sending
of event messages to user space would require new type of functionality
for nl8211. In other words, sure, it can be done, but we are not there
yet.
--
Jouni Malinen PGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jouni Malinen
2008-09-17 19:11:28 UTC
Permalink
Post by Jouni Malinen
OK. Interesting point here is that the old code was using IWEVCUSTOM
which is defined as having header_type IW_HEADER_TYPE_POINT and so are
the new IWEVASSOCREQIE and IWEVASSOCRESPIE. The only difference is in
max_tokens specifying different maximum length for the data. Maybe the
old code was also broken, but wpa_supplicant handled the bogus data
without causing problems (text parsing failing instead of some
parameters being set based on bogus binary data).
I was able to test this with a 64/32-bit setup and confirmed that both
IWEVCUSTOM and the new IWEVASSOCREQIE/IWEVASSOCRESPIE are indeed failing
when using 32-bit binary in userspace (and work with 64-bit). The length
field is parsed incorrectly for all these events.

wpa_supplicant has code for rejecting IWEVCUSTOM events that have too
large a value in the length field. However, same validation is not done
for IWEVASSOCREQIE/IWEVASSOCRESPIE (i.e., wpa_supplicant relies on
kernel providing the correct value for the length field). As the end
result, the new IWEVASSOCREQIE/IWEVASSOCRESPIE events will trigger a
segmentation fault in wpa_supplicant when the buffer is being read way
beyond its end.

I'll make wpa_supplicant validate the length field for all WEXT events
to avoid the crash. This was enough to make association work with the
reverted mac80211 patch since the values from these association info
events are not critical for many use cases.

Since we cannot fix the kernel code to handle the WEXT events for all
cases (e.g., 64-bit kernel and mix of 32-bit and 64-bit userspace
apps), I could consider adding a workaround in wpa_supplicant to handle
the 64-bit data being received in 32-bit app.. However, that would not
fix problems for anyone using older versions of wpa_supplicant.

Would it be acceptable to ever enable use of IWEVASSOCREQIE /
IWEVSSOCRESPIE in kernel if the workaround were available in new
wpa_supplicant versions? Or should we try to add a new WEXT event
type that uses fixed size for the length field and then replace the old
IWEVCUSTOM with the new type since IWEVCUSTOM does not work with
64/32-bit case (wpa_supplicant just knows how to avoid processing that
bogus event data)?
--
Jouni Malinen PGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-09-17 20:11:33 UTC
Permalink
From: Jouni Malinen <***@w1.fi>
Date: Wed, 17 Sep 2008 12:11:28 -0700
Post by Jouni Malinen
Would it be acceptable to ever enable use of IWEVASSOCREQIE /
IWEVSSOCRESPIE in kernel if the workaround were available in new
wpa_supplicant versions? Or should we try to add a new WEXT event
type that uses fixed size for the length field and then replace the old
IWEVCUSTOM with the new type since IWEVCUSTOM does not work with
64/32-bit case (wpa_supplicant just knows how to avoid processing that
bogus event data)?
Moving to a new event with a strictly sized datastructure, instead of
one that has variable sized members like pointers and crap which are
impossible to compat layer'ify, is indeed my preference.

But in that case, we might as well make nl80211 usable instead.

We'll always have those existing wpa_supplicant binaries out there, we
can't break them. And the size checks wpa_supplicant makes is a BOGUS
and REDICULIOUS way to get these malformed objects "supported" and
"usable".
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alex Williamson
2008-09-09 03:08:08 UTC
Permalink
Post by Jouni Malinen
What exactly does "breaks wireless" mean here?
NetworkManager can see access points, but doesn't get much further than
that. From an end user perspective, similar to how it behaved in
2.6.26, before Dave's wext compat fixes.

Alex


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jouni Malinen
2008-09-09 03:06:33 UTC
Permalink
Post by Alex Williamson
NetworkManager can see access points, but doesn't get much further than
that. From an end user perspective, similar to how it behaved in
2.6.26, before Dave's wext compat fixes.
Are you using 802.11n? Dave's patches fixed scan result processing, but
it looks like they may not have fixed wireless_send_event() processing.
It would be interesting to see what wpa_supplicant debug log shows
here. I would assume the device was able to associate with the AP, but
something went wrong when the association information (the data that
was changed to use binary format instead of text-based custom iw event).
--
Jouni Malinen PGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-09-08 21:32:49 UTC
Permalink
1) nf_conntrack_sip has a local variable marked static
unintentionally, for a function callable in parallel by
multiple threads this is very bad. Fix from Alexey Dobriyan.

2) GRE conntrack module's keymap list has bad locking leading to OOPS.
Fix by Alexey Dobriyan.

3) GRE conntrack module kfree()'s list head member of structure instead
of structure itself, yikes... Fixed by Alexey Dobriyan.

4) Potential remote exploit issue, IRC conntrack module blindly parses
strings in protocol packets assuming there is zero termination
there somewhere. We likely hit a zero byte anyways in the post
skb->data area since thats where skb_shared_info() sits, but that
is not something to rely upon at all. Fix from Patrick McHardy.

5) Denys Fedoryshchenko reports that his interfaces generally wedge
after some time, and this has happened since early 2.6.27-rcX
releases. Jarek Poplawski figured out that when net_tx_action()
races with dev_deactivate() the __QDISC_STATE_SCHED bit is left
set, and this causes dev_deactivate() to loop forever in a sleeping
state bit test.

6) Timewait socket handling under namespaces can lead to an OOPS
simply because we don't purge the timewait sockets attached to that
namespace from the hash tables when the namespace goes down.
Reproducer for the OOPS included in the commit message. Fix from
Daniel Lezcano.

7) Reported excessive ksoftirqd cpu utilization was tracked down to
allowing bridge hello timers smaller than 1 second, fixed by
Stephen Hemminger.

Please pull, thanks a lot!

The following changes since commit fca1287a3a9246d4facc27a0a455fada18fd1164:
David S. Miller (1):
Merge branch 'davem-fixes' of master.kernel.org:/.../jgarzik/netdev-2.6

are available in the git repository at:

master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master

Alexey Dobriyan (3):
netfilter: nf_conntrack_sip: de-static helper pointers
netfilter: nf_conntrack_gre: more locking around keymap list
netfilter: nf_conntrack_gre: nf_ct_gre_keymap_flush() fixlet

Daniel Lezcano (1):
netns : fix kernel panic in timewait socket destruction

Jarek Poplawski (1):
pkt_sched: Fix qdisc state in net_tx_action()

Patrick McHardy (1):
netfilter: nf_conntrack_irc: make sure string is terminated before calling simple_strtoul

Stephen Hemminger (1):
bridge: don't allow setting hello time to zero

include/net/inet_timewait_sock.h | 3 ++
net/bridge/br_ioctl.c | 8 ++++++-
net/bridge/br_sysfs_br.c | 26 ++++++++++++++++-------
net/core/dev.c | 7 +++++-
net/ipv4/inet_timewait_sock.c | 35 ++++++++++++++++++++++++++++++++
net/ipv4/tcp_ipv4.c | 1 +
net/ipv6/tcp_ipv6.c | 1 +
net/netfilter/nf_conntrack_irc.c | 10 +++++++++
net/netfilter/nf_conntrack_proto_gre.c | 14 ++++++++----
net/netfilter/nf_conntrack_sip.c | 6 +++-
10 files changed, 94 insertions(+), 17 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2008-09-12 23:26:53 UTC
Permalink
1) When NIU driver resets the chip after an error, it doesn't
reset the buffer pointers in the TX and RX rings, which
hangs the machine. Fix from Santwona Behera

2) nla_ok() has a signedness bug that causes us to reference
memory past the end of the attribute array in certain
circumstances. Fix from Vegard Nossum.

3) Bluetooth link policy regression fix from Marcel Holtmann.

4) ATH9K wireless sequence number handling bug fix from Jouni Malinen.

Please pull, thanks a lot!

The following changes since commit e550dfb0c2c31b6363aa463a035fc9f8dcaa3c9b:
Neil Horman (1):
ipv6: Fix OOPS in ip6_dst_lookup_tail().

are available in the git repository at:

master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master

David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../holtmann/bluetooth-2.6

Jouni Malinen (1):
ath9k: Assign seq# when mac80211 requests this

Marcel Holtmann (1):
[Bluetooth] Fix regression from using default link policy

Santwona Behera (1):
niu: panic on reset

Vegard Nossum (1):
netlink: fix overrun in attribute iteration

drivers/net/niu.c | 56 +++++++++++++++++++++++++++++++++++
drivers/net/wireless/ath9k/beacon.c | 13 ++++++++
drivers/net/wireless/ath9k/core.h | 1 +
drivers/net/wireless/ath9k/main.c | 14 +++++++++
include/net/netlink.h | 2 +-
net/bluetooth/hci_core.c | 3 ++
6 files changed, 88 insertions(+), 1 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Continue reading on narkive:
Loading...