>Xin Xiaohui wrote:
> I looked into the code dev_gro_receive(), found the code here:
> if the frags[0] is pulled to 0, then the page will be released,
> and memmove() frags left.
> Is that right? I'm not sure if memmove do right or not, but
> frags[0].size is never set after memove at least. what I think
> a simple way is not to do anything if we found frags[0].size == 0.
> The patch is as followed.
...

This version of the patch fixes the bug directly in memmove.
Reported-by: "Xin, Xiaohui" <xiaohui.xin@intel.com>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

We leak at least 32bits of kernel memory to user land in tc dump,
because we dont init all fields (capab ?) of the dumped structure.

Use C99 initializers so that holes and non explicit fields are zeroed.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

After commit 24b36f01 (netfilter: {ip,ip6,arp}_tables: dont block
bottom half more than necessary), lockdep can raise a warning
because we attempt to lock a spinlock with BH enabled, while
the same lock is usually locked by another cpu in a softirq context.

Disable again BH to avoid these lockdep warnings.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Diagnosed-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

This reverts commit 1235f504.

It causes regressions worse than the problem it was trying
to fix.  Eric will try to solve the problem another way.
Signed-off-by: David S. Miller <davem@davemloft.net>

sysctl output ipv6 gc_elasticity and min_adv_mss as values divided by
HZ. However, they are not in unit of jiffies, since ip6_rt_min_advmss
refers to packet size and ip6_rt_fc_elasticity is used as scaler as in
expire>>ip6_rt_gc_elasticity, so replace the jiffies conversion
handler will regular handler for them.

This has impact on scripts that are currently working assuming the
divide by HZ, will yield different results with this patch in place.
Signed-off-by: Min Zhang <mzhang@mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

As xfrm_compile_policy runs within a read_lock, we cannot use
GFP_KERNEL for memory allocations.
Reported-by: Luca Tettamanti <kronos.it@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

Atheros PCIe wireless cards handled by ath5k do require L0s disabled.
For distributions shipping with CONFIG_PCIEASPM (this will be enabled
by default in the future in 2.6.36) this will also mean both L1 and L0s
will be disabled when a pre 1.1 PCIe device is detected. We do know L1
works correctly even for all ath5k pre 1.1 PCIe devices though but cannot
currently undue the effect of a blacklist, for details you can read
pcie_aspm_sanity_check() and see how it adjusts the device link
capability.

It may be possible in the future to implement some PCI API to allow
drivers to override blacklists for pre 1.1 PCIe but for now it is
best to accept that both L0s and L1 will be disabled completely for
distributions shipping with CONFIG_PCIEASPM rather than having this
issue present. Motivation for adding this new API will be to help
with power consumption for some of these devices.

Example of issues you'd see:

  - On the Acer Aspire One (AOA150, Atheros Communications Inc. AR5001
    Wireless Network Adapter [168c:001c] (rev 01)) doesn't work well
    with ASPM enabled, the card will eventually stall on heavy traffic
    with often 'unsupported jumbo' warnings appearing. Disabling
    ASPM L0s in ath5k fixes these problems.

  - On the same card you would see a storm of RXORN interrupts
    even though medium is idle.

Credit for root causing and fixing the bug goes to Jussi Kivilinna.

Cc: David Quan <David.Quan@atheros.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tim Gardner <tim.gardner@canonical.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch handles the firmware loading properly
for device ID 7015.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Use appropriate command (CMD_TRIGGER_SCAN_TO) instead of scan command
(CMD_SCAN) to configure trigger scan timeout.

This was broken in commit 3a98c30f.

This fix address the bug reported here:

https://bugzilla.kernel.org/show_bug.cgi?id=16554

Cc: stable@kernel.org
Signed-off-by: Yuri Ershov <ext-yuri.ershov@nokia.com>
Signed-off-by: Yuri Kululin <ext-yuri.kululin@nokia.com>
Acked-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Some APs advertise that they may be HT40 capable in the capabilites
but the current operating channel configuration may be only HT20.
This causes disconnection as ath9k_htc sets WLAN_RC_40_FLAG despite
the AP operating in HT20 mode.
Hence set this flag only if the current channel configuration
is HT40 enabled.

Cc: stable@kernel.org
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

READ/WRITE seems to be a bit too generic for defines in a device
driver. Just rename them to CTCM_READ/CTCM_WRITE to avoid warnings.
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

READ/WRITE seems to be a bit too generic for defines in a device driver.
Just rename them to READ_CHANNEL/WRITE_CHANNEL which should suffice.

Fixes this:

In file included from drivers/s390/net/claw.c:93:
drivers/s390/net/claw.h:78:1: warning: "WRITE" redefined
In file included from /home2/heicarst/linux-2.6/arch/s390/include/asm/debug.h:12,
                 from drivers/s390/net/claw.c:68:
include/linux/fs.h:156:1: warning: this is the location of the previous definition
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Several gigabit network drivers (SB1250_MAC, TIGON3, FSL, GIANFAR,
UCC_GETH, MV643XX_ETH, XILINX_LL_TEMAC, S6GMAC, STMMAC_ETH, PASEMI_MAC,
and OCTEON_ETHERNET) select PHYLIB.  These drivers are not under
NET_ETHERNET (10/100 mbit), so this warning is generated (long, irrelevant
parts are omitted):

warning: (NET_DSA && NET && EXPERIMENTAL && NET_ETHERNET && !S390 || ... || SB1250_MAC && NETDEVICES && NETDEV_1000 && SIBYTE_SB1xxx_SOC || TIGON3 && NETDEVICES && NETDEV_1000 && PCI || FSL_PQ_MDIO && NETDEVICES && NETDEV_1000 && FSL_SOC || GIANFAR && NETDEVICES && NETDEV_1000 && FSL_SOC || UCC_GETH && NETDEVICES && NETDEV_1000 && QUICC_ENGINE || MV643XX_ETH && NETDEVICES && NETDEV_1000 && (MV64X60 || PPC32 || PLAT_ORION) || XILINX_LL_TEMAC && NETDEVICES && NETDEV_1000 && (PPC || MICROBLAZE) || S6GMAC && NETDEVICES && NETDEV_1000 && XTENSA_VARIANT_S6000 || STMMAC_ETH && NETDEV_1000 && NETDEVICES && CPU_SUBTYPE_ST40 || PASEMI_MAC && NETDEVICES && NETDEV_10000 && PPC_PASEMI && PCI || OCTEON_ETHERNET && STAGING && !STAGING_EXCLUDE_BUILD && CPU_CAVIUM_OCTEON) selects PHYLIB which has unmet direct dependencies (!S390 && NET_ETHERNET)

PHYLIB is used by non-10/100 mbit ethernet drivers, so change the dependencies
to be NETDEVICES instead of NET_ETHERNET.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

This patch adds a limit for nframes as the number of frames in TX_SETUP and
RX_SETUP are derived from a single byte multiplex value by default.
Use-cases that would require to send/filter more than 256 CAN frames should
be implemented in userspace for complexity reasons anyway.

Additionally the assignments of unsigned values from userspace to signed
values in kernelspace and vice versa are fixed by using unsigned values in
kernelspace consistently.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Reported-by: Ben Hawkes <hawkes@google.com>
Acked-by: Urs Thuermann <urs.thuermann@volkswagen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

This should fix the oops which occurs during the packet injection
on monitor interface.

EIP is at ath9k_htc_tx_start+0x69/0x220 [ath9k_htc]
 [<f84dc8ea>] ? invoke_tx_handlers+0xa5a/0xee0 [mac80211]
 [<f82c84f4>] ? ath9k_htc_tx+0x44/0xe0 [ath9k_htc]
 [<f84db7b8>] ? __ieee80211_tx+0xf8/0x190 [mac80211]
 [<f84dce0d>] ? ieee80211_tx+0x9d/0x1a0 [mac80211]
 [<f84dcfac>] ? ieee80211_xmit+0x9c/0x1c0 [mac80211]
 [<f84dd1b5>] ? ieee80211_monitor_start_xmit+0x85/0xb0 [mac80211]
 [<c04c30cd>] ? dev_hard_start_xmit+0x1ad/0x210
 [<c04b97c2>] ? __alloc_skb+0x52/0x130
 [<c04d7cd5>] ? sch_direct_xmit+0x105/0x170
 [<c04c5e9f>] ? dev_queue_xmit+0x37f/0x4b0
 [<c0567e1e>] ? packet_snd+0x21e/0x250
 [<c05684a2>] ? packet_sendmsg+0x32/0x40
 [<c04b4c63>] ? sock_aio_write+0x113/0x130
 [<c0207934>] ? do_sync_write+0xc4/0x100
 [<c0167740>] ? autoremove_wake_function+0x0/0x50
 [<c02f4414>] ? security_file_permission+0x14/0x20
 [<c0207ad4>] ? rw_verify_area+0x64/0xe0
 [<c01e6458>] ? handle_mm_fault+0x338/0x390
 [<c0207cd5>] ? vfs_write+0x185/0x1a0
 [<c058db20>] ? do_page_fault+0x160/0x3a0
 [<c0208512>] ? sys_write+0x42/0x70
 [<c01033ec>] ? syscall_call+0x7/0xb
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

It is necessary to call pm_qos_add_request prior to calling
pm_qos_update_request.  It was revealed that ipw2100 has been
doing this wrong since "pm_qos: Get rid of the allocation in
pm_qos_add_request()" (commit 82f68251)
added a WARN that results in the following backtrace:

WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x5e/0x70()
pm_qos_update_request() called for unknown object
Call Trace:
[<c1024088>] ? warn_slowpath_common+0x78/0xb0
[<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
[<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
[<c1024153>] ? warn_slowpath_fmt+0x33/0x40
[<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
[<f89fe15f>] ? ipw2100_up+0x3f/0xf10 [ipw2100]
[<c11961c9>] ? vsnprintf+0xc9/0x530
[<f89ff36c>] ? ipw2100_net_init+0x2c/0x1c0 [ipw2100]
[<c12f542d>] ? register_netdevice+0x7d/0x3c0
[<f89f9b00>] ? ipw2100_irq_tasklet+0x910/0x9a0 [ipw2100]
[<c12f579f>] ? register_netdev+0x2f/0x40
[<f89fd471>] ? ipw2100_pci_init_one+0xd21/0x1060 [ipw2100]
[<c11a5ebb>] ? local_pci_probe+0xb/0x10
[<c11a6d49>] ? pci_device_probe+0x69/0x90
[<c1224704>] ? driver_probe_device+0x74/0x180
[<c10dd15a>] ? sysfs_create_dir+0x6a/0xb0
[<c1224889>] ? __driver_attach+0x79/0x80
[<c1224810>] ? __driver_attach+0x0/0x80
[<c1223fa2>] ? bus_for_each_dev+0x52/0x80
[<c1224586>] ? driver_attach+0x16/0x20
[<c1224810>] ? __driver_attach+0x0/0x80
[<c122395f>] ? bus_add_driver+0x17f/0x250
[<c11a5ec0>] ? pci_device_shutdown+0x0/0x20
[<c11a6c80>] ? pci_device_remove+0x0/0x40
[<c1224b13>] ? driver_register+0x63/0x120
[<c11a6f96>] ? __pci_register_driver+0x36/0xa0
[<f84f9048>] ? ipw2100_init+0x48/0x67 [ipw2100]
[<c1001122>] ? do_one_initcall+0x32/0x170
[<c1087078>] ? __vunmap+0xb8/0xf0
[<f84f9000>] ? ipw2100_init+0x0/0x67 [ipw2100]
[<c10510c1>] ? sys_init_module+0x161/0x1000
[<c108f847>] ? sys_close+0x67/0xe0
[<c13647c1>] ? syscall_call+0x7/0xb

This patch moves pm_qos_add_request prior to pci_register_driver in
ipw2100 in order to avoid this problem.
Reported-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Require qdisc class ops .walk and .leaf for classful qdisc in
register_qdisc(). The checks could be done later insted, but these
ops are really needed and used by most of classful qdiscs.
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

sch_sfq as a classful qdisc needs the .leaf handler. Otherwise, there
is an oops possible in tc_modify_qdisc()/check_loop().

Fixes commit 7d2681a6Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The setting of SPI_DATA_POS depending on CONFIG_CAIF_SPI_SYNC
where inverted.
Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Headroom size for control channel must be at least 48 bytes in some scenarios.
Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

"netpoll: Use 'bool' for netpoll_rx() return type." missed the case when
CONFIG_NETPOLL is disabled.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The previous value of 672 for L2CAP_DEFAULT_MAX_PDU_SIZE is based on
the default L2CAP MTU.  That default MTU is calculated from the size
of two DH5 packets, minus ACL and L2CAP b-frame header overhead.

ERTM is used with newer basebands that typically support larger 3-DH5
packets, and i-frames and s-frames have more header overhead.  With
clean RF conditions, basebands will typically attempt to use 1021-byte
3-DH5 packets for maximum throughput.  Adjusting for 2 bytes of ACL
headers plus 10 bytes of worst-case L2CAP headers yields 1009 bytes
of payload.

This PDU size imposes less overhead for header bytes and gives the
baseband the option to choose 3-DH5 packets, but is small enough for
ERTM traffic to interleave well with other L2CAP or SCO data.
672-byte payloads do not allow the most efficient over-the-air
packet choice, and cannot achieve maximum throughput over BR/EDR.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

remote_tx_win is intended to be set on receipt of an L2CAP
configuration request.  The value is used to determine the size of the
transmit window on the remote side of an ERTM connection, so L2CAP
can stop sending frames when that remote window is full.

An incorrect remote_tx_win value will cause the stack to not fully
utilize the tx window (performance impact), or to overfill the remote
tx window (causing dropped frames or a disconnect).

This patch removes an extra setting of remote_tx_win when a
configuration response is received.  The transmit window has a
different meaning in a response - it is an informational value
less than or equal to the local tx_win.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

The L2CAP specification requires that the ERTM retransmit timeout be at
least 2 seconds for BR/EDR connections.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Incoming configuration values must be converted to native CPU order
before use.  This fixes a bug where a little-endian MPS value is
compared to a native CPU value.  On big-endian processors, this
can cause ERTM and streaming mode segmentation to produce PDUs
that are larger than the remote stack is expecting, or that would
produce fragmented skbs that the current FCS code cannot handle.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This is based on work originally done by Patric McHardy.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Driver should call pci_disable_device() if it returns from pci_probe()
with error.
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Driver should call pci_disable_device() if it returns from pci_probe()
with error.
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Driver should call pci_disable_device() if it returns from pci_probe()
with error.
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

This patch makes rx_submit() return an error code, and makes some call sites
that care check the return value. This is important because it lets us properly
handle cases where the device isn't ready to handle URB submissions (e.g., when
it is autosuspended under some drivers); previously, we would attempt and fail
to submit URBs and reschedule ourselves to try and fail again. This patch is
against Linus's 2.6 repo commit 45d7f32c.
Signed-Off-By: Elizabeth Jones <ellyjones@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

pkt_sched: Add some basic qdisc class ops verification. Was: [PATCH] sfq: add dummy bind/unbind handles

Verify in register_qdisc() some basic qdisc class handlers are present.
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

pkt_sched: sch_sfq: Add dummy unbind_tcf and put handles. Was: [PATCH] sfq: add dummy bind/unbind handles

Add dummy .unbind_tcf and .put qdisc class ops for easier verification.
(All other schedulers have it like this.)
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlcnic_pci_info structs are 128 bytes so an array of 8 uses 1024 bytes.
That's a lot if you run with 4K stacks.  I allocated them with kcalloc()
instead.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

In the original code we allocated memory conditionally and freed it in
the error handling unconditionally.  It turns out that this function is
only called during initialization and "adapter->npars" and
"adapter->eswitch" are always NULL at the start of the function.  I
removed those checks.

Also since I was cleaning things, I changed the error handling for
qlcnic_get_pci_info() and pulled everything in an indent level.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Fix phy.c kernel-doc notation:

Warning(drivers/net/phy/phy.c:313): No description found for parameter 'ifr'
Warning(drivers/net/phy/phy.c:313): Excess function parameter 'mii_data' description in 'phy_mii_ioctl'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Add missing kernel-doc notation to struct sock:

Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_pid'
Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_cred'
Warning(include/net/sock.h:324): No description found for parameter 'sk_classid'
Warning(include/net/sock.h:324): Excess struct/union/enum/typedef member 'sk_peercred' description in 'sock'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Fix etherdevice.h parameter name typo in kernel-doc:

Warning(include/linux/etherdevice.h:138): No description found for parameter 'hwaddr'
Warning(include/linux/etherdevice.h:138): Excess function parameter 'addr' description in 'dev_hw_addr_random'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>