Use a different work_struct variables for add_conn() and del_conn() and
use single work queue instead of two for adding and deleting connections.

It eliminates the following error on a preemptible kernel:

[  204.358032] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[  204.370697] pgd = c0004000
[  204.373443] [0000000c] *pgd=00000000
[  204.378601] Internal error: Oops: 17 [#1] PREEMPT
[  204.383361] Modules linked in: vfat fat rfcomm sco l2cap sd_mod scsi_mod iphb pvr2d drm omaplfb ps
[  204.438537] CPU: 0    Not tainted  (2.6.28-maemo2 #1)
[  204.443664] PC is at klist_put+0x2c/0xb4
[  204.447601] LR is at klist_put+0x18/0xb4
[  204.451568] pc : [<c0270f08>]    lr : [<c0270ef4>]    psr: a0000113
[  204.451568] sp : cf1b3f10  ip : cf1b3f10  fp : cf1b3f2c
[  204.463104] r10: 00000000  r9 : 00000000  r8 : bf08029c
[  204.468353] r7 : c7869200  r6 : cfbe2690  r5 : c78692c8  r4 : 00000001
[  204.474945] r3 : 00000001  r2 : cf1b2000  r1 : 00000001  r0 : 00000000
[  204.481506] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment kernel
[  204.488861] Control: 10c5387d  Table: 887fc018  DAC: 00000017
[  204.494628] Process btdelconn (pid: 515, stack limit = 0xcf1b22e0)
Signed-off-by: NRoger Quadros <ext-roger.quadros@nokia.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In 2.6.25 we added UDP mem accounting.

This unfortunatly added a penalty when a frame is transmitted, since
we have at TX completion time to call sock_wfree() to perform necessary
memory accounting. This calls sock_def_write_space() and utimately
scheduler if any thread is waiting on the socket.
Thread(s) waiting for an incoming frame was scheduled, then had to sleep
again as event was meaningless.

(All threads waiting on a socket are using same sk_sleep anchor)

This adds lot of extra wakeups and increases latencies, as noted
by Christoph Lameter, and slows down softirq handler.

Reference : http://marc.info/?l=linux-netdev&m=124060437012283&w=2 

Fortunatly, Davide Libenzi recently added concept of keyed wakeups
into kernel, and particularly for sockets (see commit
37e5540b 
epoll keyed wakeups: make sockets use keyed wakeups)

Davide goal was to optimize epoll, but this new wakeup infrastructure
can help non epoll users as well, if they care to setup an appropriate
handler.

This patch introduces new DEFINE_WAIT_FUNC() helper and uses it
in wait_for_packet(), so that only relevant event can wakeup a thread
blocked in this function.

Trace of function calls from bnx2 TX completion bnx2_poll_work() is :
__kfree_skb()
 skb_release_head_state()
  sock_wfree()
   sock_def_write_space()
    __wake_up_sync_key()
     __wake_up_common()
      receiver_wake_function() : Stops here since thread is waiting for an INPUT
Reported-by: NChristoph Lameter <cl@linux.com>
Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NMike Rapoport <mike@compulab.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Right now we have no upper limit on the size of the route cache hash table.
On a 128GB POWER6 box it ends up as 32MB:

    IP route cache hash table entries: 4194304 (order: 9, 33554432 bytes)

It would be nice to cap this for memory consumption reasons, but a massive
hashtable also causes a significant spike when measuring OS jitter.

With a 32MB hashtable and 4 million entries, rt_worker_func is taking
5 ms to complete. On another system with more memory it's taking 14 ms.
Even though rt_worker_func does call cond_sched() to limit its impact,
in an HPC environment we want to keep all sources of OS jitter to a minimum.

With the patch applied we limit the number of entries to 512k which
can still be overriden by using the rt_entries boot option:

    IP route cache hash table entries: 524288 (order: 6, 4194304 bytes)

With this patch rt_worker_func now takes 0.460 ms on the same system.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Acked-by: NEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Move the entry about CAPI 2.0 to the beginning and add a URL.
Incorporate changes suggested by Randy Dunlap, thanks for proofreading.
Signed-off-by: NKarsten Keil <keil@b1-systems.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

isdn: document Kernel CAPI driver interface

Create a file Documentation/isdn/INTERFACE.CAPI describing the
interface between the kernel CAPI subsystem and ISDN device drivers,
analogous to the existing Documentation/isdn/INTERFACE for the old
isdn4linux subsystem. Also add kerneldoc comments to the exported
functions in drivers/isdn/capi/kcapi.c.

Impact: Documentation
Signed-off-by: NTilman Schmidt <tilman@imap.cc>
Signed-off-by: NKarsten Keil <keil@b1-systems.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After the merging of mISDN, state which files refer only to the
old isdn4linux subsystem.  Also add a few missing files.
Signed-off-by: NTilman Schmidt <tilman@imap.cc>
Signed-off-by: NKarsten Keil <keil@b1-systems.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The current code writes the PME enabled bit in PCI config space which is
wrong.  This was needed for pre-release hardware, and was not removed from
the driver.  Also, we need to clear the WUS (wake up status) after we
resume.  Otherwise we can't wake for the same event again since it's still
asserted in the hardware.  Plus, the multicast lists were being written
improperly, causing multicast WoL to fail.
Signed-off-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From: Stephen Hemminger <shemminger@vyatta.com>

The veth driver will oops if sysfs hooks are open while module is removed.

The net device destructor can not point to code in a module; basically
there are only two possible safe values: NULL - no destructor, or
free_netdev - free on last use
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When kernel inserts a temporary SA for IKE, it uses the wrong hash
value for dst list. Two hash values were calcultated before: one with
source address and one with a wildcard source address.

Bug hinted by Junwei Zhang <junwei.zhang@6wind.com>
Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes the tx_timeout() to properly handle the clean up of the
tx ring. It also sets the tx put pointer back to the correct position to
be in sync with HW.
Signed-off-by: NAyaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Unless I miss anything this should fix a bug.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If we failed to allocate new fragments for receive buffer,
the packet should be dropped and packets should be reused.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In case of mlx4_en_activate_cq() failure, the cleanup
code would go to rx_err and try to disable unactivated rings.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

	Currently, the VLAN event handler does not adjust the VLAN
device's carrier state when the real device or the VLAN device is set
administratively up or down.

	The following patch adds a transfer of operating state from the
real device to the VLAN device when the real device is administratively
set up or down, and sets the carrier state up or down during init, open
and close of the VLAN device.

	This permits observers above the VLAN device that care about the
carrier state (bonding's link monitor, for example) to receive updates
for administrative changes by more closely mimicing the behavior of real
devices.
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NPatrick McHardy <kaber@trash.net>

Related-to: commit 325fb5b4

The compat path suffers from a similar problem. It only uses a __be32
when all of the recent code uses, and expects, an nf_inet_addr
everywhere. As a result, addresses stored by xt_recents were
filled with whatever other stuff was on the stack following the be32.
Signed-off-by: NJan Engelhardt <jengelh@medozas.de>

With a minor compile fix from Roman.
Reported-and-tested-by: NRoman Hoog Antink <rha@open.ch>
Signed-off-by: NPatrick McHardy <kaber@trash.net>

This patch adds missing role attribute to the DCCP type, otherwise
the creation of entries is not of any use.

The attribute added is CTA_PROTOINFO_DCCP_ROLE which contains the
role of the conntrack original tuple.
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: NPatrick McHardy <kaber@trash.net>

Signed-off-by: NLaszlo Attila Toth <panther@balabit.hu>
Signed-off-by: NPatrick McHardy <kaber@trash.net>

Commit d0dba725 (netfilter: ctnetlink: add callbacks to the per-proto
nlattrs) changed the protocol registration function to abort if the
to-be registered protocol doesn't provide a new callback function.

The DCCP and UDP-Lite IPv6 protocols were missed in this conversion,
add the required callback pointer.
Reported-and-tested-by: NSteven Jan Springl <steven@springl.ukfsn.org>
Signed-off-by: NPatrick McHardy <kaber@trash.net>

This patch fixes a (bogus?) gcc warning during compilation:

net/netfilter/nf_conntrack_netlink.c:1234: warning: 'helpname' may be used uninitialized in this function
net/netfilter/nf_conntrack_netlink.c:991: warning: 'helpname' may be used uninitialized in this function

In fact, helpname is initialized by ctnetlink_parse_help() so
I cannot see a way to use it without being initialized.
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Patch "af_rose/x25: Sanity check the maximum user frame size"
(commit 83e0bbcb) from Alan Cox got
locking wrong. If we bail out due to user frame size being too large,
we must unlock the socket beforehand.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The NetLabel address selector mechanism has a problem where it can get
mistakenly remove the wrong selector when similar addresses are used.  The
problem is caused when multiple addresses are configured that have different
netmasks but the same address, e.g. 127.0.0.0/8 and 127.0.0.0/24.  This patch
fixes the problem.
Reported-by: NEtienne Basset <etienne.basset@numericable.fr>
Signed-off-by: NPaul Moore <paul.moore@hp.com>
Acked-by: NJames Morris <jmorris@namei.org>
Tested-by: NEtienne Basset <etienne.basset@numericable.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If using the UCC on a MPC8360 in RMII mode, don;t set
UCC_GETH_UPSMR_RPM bit in the upsmr register.
Signed-off-by: NHeiko Schocher <hs@denx.de>
Acked-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

While ifconfig eth0 up kernel calls open() of 8139 driver(8139too.c).
In rtl8139_hw_start() of rtl8139_open(), 8139 driver enable RX before
setting up the DMA buffer address. In this interval where RX was
enabled and DMA buffer address is not yet set up, any incoming
broadcast packet would be send to a strange physical address:
0x003e8800 which is the default value of DMA buffer address.
Unfortunately, this address is used by Linux kernel. So kernel panics.
This patch fix it by setting up DMA buffer address before RX enabled
and everything is fine even under broadcast packets attack.
Signed-off-by: NJonathan Lin <jon.lin@vatics.com>
Signed-off-by: NAmos Kong <jianjun@zeuux.org>
Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

AF_IUCV runs into a race when queuing incoming iucv messages
and receiving the resulting backlog.

If the Linux system is under pressure (high load or steal time),
the message queue grows up, but messages are not received and queued
onto the backlog queue. In that case, applications do not
receive any data with recvmsg() even if AF_IUCV puts incoming
messages onto the message queue.

The race can be avoided if the message queue spinlock in the
message_pending callback is spreaded across the entire callback
function.
Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add few more sk states in iucv_sock_shutdown().
Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reject incoming iucv messages if the receive direction has been shut down.
It avoids that the queue of outstanding messages increases and exceeds the
message limit of the iucv communication path.
Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If iucv_sock_recvmsg() is called with MSG_PEEK flag set, the skb is enqueued
twice. If the socket is then closed, the pointer to the skb is freed twice.

Remove the skb_queue_head() call for MSG_PEEK, because the skb_recv_datagram()
function already handles MSG_PEEK (does not dequeue the skb).
Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Make sure a second invocation of iucv_sock_close() guarantees proper
freeing of an iucv path.
Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A few issues wrt DMA were uncovered when using the driver with swiotlb.
- driver should not use memory after it has been mapped
- iwl3945's RX queue management cannot use all of iwlagn because
  the size of the RX buffer is different. Revert back to using
  iwl3945 specific routines that map/unmap memory.
- no need to "dma_syn_single_range_for_cpu" followed by pci_unmap_single,
  we can just call pci_unmap_single initially
- only map the memory area that will be used by device. this is especially
  relevant to the mapping of iwl_cmd. we should not map the entire
  structure because the meta data at the beginning of structure contains
  the address to be used later for unmapping. If the address to be used for
  unmapping is stored in mapped data it creates a problem.
- ensure that _if_ memory needs to be modified after it is mapped that we
  call _sync_single_for_cpu first, and then release it back to device with
  _sync_single_for_device
- we mapped the wrong length of data for host commands, with mapped length
  differing with length provided to device, fix that.

Thanks to Jason Andryuk <jandryuk@gmail.com> for significant bisecting
help to find these issues.

This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1964Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Tested-by: NJason Andryuk <jandryuk@gmail.com>
Tested-by: NBen Gamari <bgamari@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When debugging TX issues it is helpful to know the seq nr of the
frame being transmitted. The seq nr is printed as part of ucode's
log informing us which frame is being processed. Having this information
printed in driver log makes it easy to match activities between driver
and firmware.

Also make possible to print TX flags directly. These are already printed
as part of entire TX command, but having it printed directly in cpu format
makes it easier to look at.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes a build warning in mwl8.c.
(Marvell TOPDOG wireless driver)

The warning it fixes is: "large integer implicitly truncated to unsigned type."

The rx_ctrl member of the mwl8k_rx_desc struct is 8 bit (__u8 ), whereas trying
to assign it a 32 bit value (which is returned from  cpu_to_le32())
causes the compiler to issue
a truncation warning.
Signed-off-by: NRami Rosen <ramirose@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When checking whether or not a given frame needs to be
moved to be properly aligned to a 4-byte boundary, we
use & 4 which wasn't intended, this code should check
the lowest two bits.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It is expected that config interface will always succeed as mac80211
will only request what driver supports. The exception here is when a
device has rfkill enabled. At this time the rfkill state is unknown to
mac80211 and config interface can fail. When this happens we deal with
this error instead of printing a WARN.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Users reported lockup with work still trying to run
after module has been unloaded.

http://thread.gmane.org/gmane.linux.kernel.wireless.general/30594/focus=30601Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Reported-by: NTJ <ubuntu@tjworld.net>
Reported-by: NHuaxu Wan <huaxu.wan@linux.intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix the bug where some revisions of 6000 series hardware cannot
be used. Later versions of 6000 series have the EEPROM replaced by
OTP. For these devices to be used we need to expand valid EEPROM mask.
Signed-off-by: NJay Sternberg <jay.e.sternberg@linux.intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

sparse says:

drivers/net/wireless/atmel.c:1501:3: warning: Initializer entry defined twice
drivers/net/wireless/atmel.c:1505:3:   also defined here

and it's correct; atmel has its own ndo_change_mtu and
shouldn't use eth_change_mtu.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

pcnet_cs: add cis(firmware) of the Allied Telesis LA-PCM
Signed-off-by: NKen Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If creating a workqueue fails, don't jump to the error path where that
same workqueue is destroyed, since destroy_workqueue() can't handle a
NULL pointer.

This was spotted by the Coverity checker (CID 2617).
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>