o fix the ip/tcp hdr offset in tx descriptors for ipv6.
o cleanup xmit function, move the tso checks into separate function,
  this reduces unnecessary endian conversions back and forth.
o optimize macros to initialize tx descriptors.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

o Set restricted (little endian) data types in firmware command
  requests and responses.
o Remove unnecessary conversion to LE when writing registers.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The attached patch modifies the sis900 driver when the MAC address
read from the hardware is invalid. As suggested, the patch now
generates a random address so that the user can go on and use
the hardware. In any case a message is also shown to warn on the
unexpected condition.
This seems to happen with newer HW implementation of the sis900
chipset, since this never came up before.

Patch is against vanilla 2.6.28 (but the driver doesn't change so often,
so it will probably apply to older/newer versions too).

See bugzilla ID 10201 and 11649 and ignore the previous patch.
Signed-off-by: Daniele Venzano <venza@brownhat.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

If something goes wrong attaching to phy driver, we weren't freeing
the IRQ.
Signed-off-by: Mike Ditto <mditto@consentry.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

When we get a GSO packet from an untrusted source, we need to
ensure that it is sufficiently long so that we don't end up
crashing.

Based on discovery and patch by Ian Campbell.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

When an skb with page frags is merged into an existing one, we
cannibalise its reference count.  This is OK when the skb is
reused because we set nr_frags to zero in that case.  However,
for the case where the skb is freed through kfree_skb, we didn't
clear nr_frags which causes the page to be freed prematurely.

This is fixed by moving the skb resetting into skb_gro_receive.
Reported-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

Reported by Jiri Klimes.

Fix suggested by Patrick McHardy.
Signed-off-by: David S. Miller <davem@davemloft.net>

Minor cleanups, either made possible or obvious after commit d700555b (I4l:
convert to net_device_ops).
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>

When an i4l ppp interface is shut down (e.g. with /sbin/ifdown ippp0) a
scary warning is logged:
    
    isdn_free_channel: called with invalid drv(-1) or channel(-1)
    
This warning is caused by isdn_net_unbind_channel(), which always calls
isdn_free_channel() even if isdn_net_local->isdn_device and
isdn_net_local->isdn_channel are (still) in a perfectly acceptable
default state, so let's not do that.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>

Freescale on-chip TBI PHYs reports PHY ID as 0x0, but as of

commit 3ee82383
Author: Giulio Benetti <giulio.benetti@micronovasrl.com>
Date:   Thu Nov 13 21:53:13 2008 +0000

    phy: fix phy address bug

    PHYID returns 0xffff and not 0xffffffff when not found and in some
    case(at91sam9263) 0x0. Maybe this patch could be useful.

phy_device.c treats PHY ID == 0x0 as bogus IDs, and that results in
gianfar driver failure to see the TBI PHYs. This code snippet triggers:

	if (!priv->tbiphy) {
		printk(KERN_WARNING "SGMII mode requires that the device "
				"tree specify a tbi-handle\n");
		return;
	}

Although tbi-handle is specified in the device tree.

Btw, technically PHY ID == 0x0 is a valid ID (if we ever see a PHY
manufactured by Xerox :-).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

As GRO cannot be applied to packets with frag_list we need to
make sure that we reject such packets if they are fed to us,
e.g., through a tunnel device.

Also there is no point in applying GRO on GSO packets so they
too should be rejected.  This allows GRO to be used in virtio-net
which may produce GSO packets directly but may still benefit
from GRO if the other end of it doesn't support GSO.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

Reported by Russell King:

drivers/net/arm/etherh.c:649: error: unknown field 'ndo_set_mac_addr' specified in initializer
Signed-off-by: David S. Miller <davem@davemloft.net>

When a fib6 table dump is prematurely ended, we won't unlink
its walker from the list.  This causes all sorts of grief for
other users of the list later.
Reported-by: Chris Caputo <ccaputo@alt.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

As spotted by Willy Tarreau, current splice() from tcp socket to pipe is not
optimal. It processes at most one segment per call.
This results in low performance and very high overhead due to syscall rate
when splicing from interfaces which do not support LRO.

Willy provided a patch inside tcp_splice_read(), but a better fix
is to let tcp_read_sock() process as many segments as possible, so
that tcp_rcv_space_adjust() and tcp_cleanup_rbuf() are called less
often.

With this change, splice() behaves like tcp_recvmsg(), being able
to consume many skbs in one system call. With typical 1460 bytes
of payload per frame, that means splice(SPLICE_F_NONBLOCK) can return
16*1460 = 23360 bytes.
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

drivers/net/wireless/p54/p54common.c: In function ‘p54_config’:
drivers/net/wireless/p54/p54common.c:1853: warning: ‘ret’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>

drivers/net/wireless/iwlwifi/iwl-3945.c: In function ‘iwl3945_txpower_set_from_eeprom’:
drivers/net/wireless/iwlwifi/iwl-3945.c:2222: warning: ‘power_idx’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>

drivers/net/wireless/b43legacy/main.c: In function ‘b43legacy_op_dev_config’:
drivers/net/wireless/b43legacy/main.c:2468: warning: ‘up_dev’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>

drivers/net/wireless/b43/main.c: In function ‘b43_op_config’:
drivers/net/wireless/b43/main.c:3264: warning: ‘gmode’ may be used uninitialized
Signed-off-by: John W. Linville <linville@tuxdriver.com>

net/mac80211/ht.c: In function ‘ieee80211_start_tx_ba_session’:
net/mac80211/ht.c:472: warning: ‘ret’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The commits:

	7a95d267
	("net: ppp_generic - use idr technique instead of cardmaps")

	ab5024ab
	("net: ppp_generic - use DEFINE_IDR for static initialization")

introduced usage of IDR functionality but broke userspace side.

Before this commits it was possible to allocate new ppp interface with
specified number. Now it fails with EINVAL.  Fix it by trying to
allocate interface with specified unit number and return EEXIST if
fail which allow pppd to ask us to allocate new unit number.

And fix messages on memory allocation fails - add details that it's
PPP module who is complaining.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

This patch fixes following bug:

BUG: soft lockup - CPU#0 stuck for 61s! [S03mountvirtfs-:922]
Modules linked in:
NIP: c006505c LR: c00675f0 CTR: c0020438
REGS: c7a1db90 TRAP: 0901   Not tainted  (2.6.28-rc8-01311-g8c7396ae)
MSR: 00009032 <EE,ME,IR,DR>  CR: 28248442  XER: 20000000
TASK = c7a288a0[922] 'S03mountvirtfs-' THREAD: c7a1c000
GPR00: 00009032 c7a1dc40 c7a288a0 00000024 c79a1840 00000000 00000300 00000020
GPR08: c035f97c 00000000 00004008 c04d5210 00000000
NIP [c006505c] handle_IRQ_event+0x34/0xb0
LR [c00675f0] handle_level_irq+0xa8/0x144
Call Trace:
[c7a1dc40] [c00204d8] ipic_mask_irq+0xa0/0xb4 (unreliable)
[c7a1dc60] [c00675f0] handle_level_irq+0xa8/0x144
[c7a1dc80] [c00067f8] do_IRQ+0x78/0x108
[c7a1dc90] [c0014d7c] ret_from_except+0x0/0x14
--- Exception: 501 at gfar_schedule_cleanup+0x54/0x7c
    LR = gfar_transmit+0x14/0x28
[c7a1dd50] [c0352a3c] _spin_unlock_irqrestore+0x18/0x30 (unreliable)
[c7a1dd60] [c01f49a8] gfar_transmit+0x14/0x28
[c7a1dd70] [c0065084] handle_IRQ_event+0x5c/0xb0
[c7a1dd90] [c00675f0] handle_level_irq+0xa8/0x144
[c7a1ddb0] [c00067f8] do_IRQ+0x78/0x108
[c7a1ddc0] [c0014d7c] ret_from_except+0x0/0x14
--- Exception: 501 at up_read+0x10/0x48
    LR = do_page_fault+0x2b0/0x3e0
[c7a1de80] [c7a177e8] 0xc7a177e8 (unreliable)
[c7a1de90] [c0017964] do_page_fault+0x2b0/0x3e0
[c7a1df40] [c0014b14] handle_page_fault+0xc/0x80
--- Exception: 301 at 0xfe98b7c
    LR = 0xfe989c0
Instruction dump:
7c0802a6 bf810010 7c9f2378 7c7c1b78 90010024 80040004 70090020 40820010
7c0000a6 60008000 7c000124 3bc00000 <3ba00000> 48000010 83ff0014 2f9f0000


The bug introduced by commit 8c7396ae
("gianfar: Merge Tx and Rx interrupt for scheduling clean up ring").

The commit merged TX and RX interrupt code into a single routine that
schedules NAPI, but no locks were introduced. This causes irq races, so
when irqs are enabled and netif_rx_schedule_prep() returns 0, nobody
disable the interrupts again. This leads to interrupt storm and finally
to the lockup.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Filip Aben says this fix is neccessary for big endian machines.
Signed-off-by: Denis Joseph Barrow <D.Barow@option.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Currently htb_do_events() breaks events recounting for a level after 2
jiffies, but there is no reason to repeat this for next levels and
increase delays even more (with softirqs disabled). htb_dequeue_tree()
can add to this too, btw. In such a case q->now time is invalid anyway.

Thanks to Patrick McHardy for spotting an error around earlier version
of this patch.
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Next event time should consider jiffies used for recounting. Otherwise
qdisc_watchdog_schedule() triggers hrtimer immediately with the event
in the past, and may cause very high ksoftirqd cpu usage (if highres
is on).

There is also removed checking "event" for zero in htb_dequeue(): it's
always true in this place.
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

reorder struct xt_match to remove 8 bytes of padding and make its size
128 bytes.

This saves a small amount of data space in each of the xt netfilter
modules and fits xt_match in one 128 byte cache line.
Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

netfilter: xt_time: print timezone for user information

Let users have a way to figure out if their distro set the kernel
timezone at all.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

nf_conntrack_alloc cannot return NULL, so there is no need to check for
NULL before using the value.  I have also removed the initialization of ct
to NULL in nf_conntrack_alloc, since the value is never used, and since
perhaps it might lead one to think that return ct at the end might return
NULL.

The semantic patch that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@match exists@
expression x, E;
position p1,p2;
statement S1, S2;
@@

x@p1 = nf_conntrack_alloc(...)
... when != x = E
(
  if (x@p2 == NULL || ...) S1 else S2
|
  if (x@p2 == NULL && ...) S1 else S2
)

@other_match exists@
expression match.x, E1, E2;
position p1!=match.p1,match.p2;
@@

x@p1 = E1
... when != x = E2
x@p2

@ script:python depends on !other_match@
p1 << match.p1;
p2 << match.p2;
@@

print "%s: call to nf_conntrack_alloc %s bad test %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

An old bug crept back into the ICMP/ICMPv6 conntrack protocols: the timeout
values are defined as unsigned longs, the sysctl's maxsize is set to
sizeof(unsigned int). Use unsigned int for the timeout values as in the
other conntrack protocols.
Reported-by: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

Commit 8cc784ee (netfilter: change return types of match functions
for ebtables extensions) broke ebtables matches by inverting the
sense of match/nomatch.
Reported-by: Matt Cross <matthltc@us.ibm.com>
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

Commit 55b69e91 (netfilter: implement NFPROTO_UNSPEC as a wildcard
for extensions) broke revision probing for matches and targets that
are registered with NFPROTO_UNSPEC.

Fix by continuing the search on the NFPROTO_UNSPEC list if nothing
is found on the af-specific lists.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

The PPPOE/VLAN processing code in the bridge netfilter is broken
by design.  The VLAN tag and the PPPOE session ID are an integral
part of the packet flow information, yet they're completely
ignored by the bridge netfilter.  This is potentially a security
hole as it treats all VLANs and PPPOE sessions as the same.

What's more, it's actually broken for PPPOE as the bridge netfilter
tries to trim the packets to the IP length without adjusting the
PPPOE header (and adjusting the PPPOE header isn't much better
since the PPPOE peer may require the padding to be present).

Therefore we should disable this by default.

It does mean that people relying on this feature may lose networking
depending on how their bridge netfilter rules are configured.
However, IMHO the problems this code causes are serious enough to
warrant this.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

Currently the bridge FORWARD/POST_ROUTING chains treats all
non-IPv4 packets as IPv6.  This packet fixes that by returning
NF_ACCEPT on non-IP packets instead, just as is done in PRE_ROUTING.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

Don't spam logs for locally generated short packets. these can only
be generated by root.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

Fix a comment in include/linux/netdevice.h.
Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>

At 37000 feet somewhere near Greenland I woke up from a half-sleep with the
realisation that __lowest_in_progress() is buggy. After landing I checked
and there were indeed 2 problems with it; this patch fixes both:
* The order of the list checks was wrong
* The locking was not correct.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

There has been some light flamewar on lkml about decoding oopses
in modules (as part of the crashdump flamewar).

Now this isn't rocket science, just the markup_oops.pl script
cheaped out and didn't handle modules. But really; a flamewar
all about that?? What happened to C++ in the kernel or reading
files from inside the kernel?

This patch adds module support to markup_oops.pl; it's not the
most pretty perl but it works for my testcases...
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Add the Multi-Tech cellular modem firmware to the TI USB serial driver.
This firmware was extracted from:

ftp://ftp.multitech.com/wireless/wireless_linux.zip

Firmware licence: "all firmware components are redistributable in binary
	form" per support@multitech.com
	Copyright (C) 2005 Multi-Tech Systems, Inc.
Signed-off-by: Chris Adams <cmadams@hiwaay.net>
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Add Multi-Tech cellular modem support to the ti_usb_3410_5052 driver.
Signed-off-by: Chris Adams <cmadams@hiwaay.net>
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>