linux-stable.git/net, branch v3.0.1

cfg80211: really ignore the regulatory request

2011-08-05T04:58:41+00:00

commit a203c2aa4cefccb879c879b8e1cad1a09a679e55 upstream.

At the beginning of wiphy_update_regulatory() a check is performed
whether the request is to be ignored. Then the request is sent to
the driver nevertheless. This happens even if last_request points
to NULL, leading to a crash in the driver:

 [] (lbs_set_11d_domain_info+0x28/0x1e4 [libertas]) from [] (wiphy_update_regulatory+0x4d0/0x4f4)
 [] (wiphy_update_regulatory+0x4d0/0x4f4) from [] (wiphy_register+0x354/0x420)
 [] (wiphy_register+0x354/0x420) from [] (lbs_cfg_register+0x80/0x164 [libertas])
 [] (lbs_cfg_register+0x80/0x164 [libertas]) from [] (lbs_start_card+0x20/0x88 [libertas])
 [] (lbs_start_card+0x20/0x88 [libertas]) from [] (if_sdio_probe+0x898/0x9c0 [libertas_sdio])

Fix this by returning early. Also remove the out: label as it is
not any longer needed.

Signed-off-by: Sven Neumann 
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg 
Cc: Daniel Mack 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

svcrpc: fix list-corrupting race on nfsd shutdown

2011-08-05T04:58:40+00:00

commit ebc63e531cc6a457595dd110b07ac530eae788c3 upstream.

After commit 3262c816a3d7fb1eaabce633caa317887ed549ae "[PATCH] knfsd:
split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no
longer removed its xpt_ready (then sk_ready) field from whatever list it
was on, noting that there was no point since the whole list was about to
be destroyed anyway.

That was mostly true, but forgot that a few svc_xprt_enqueue()'s might
still be hanging around playing with the about-to-be-destroyed list, and
could get themselves into trouble writing to freed memory if we left
this xprt on the list after freeing it.

(This is actually functionally identical to a patch made first by Ben
Greear, but with more comments.)

Cc: gnb@fmeh.org
Reported-by: Ben Greear 
Tested-by: Ben Greear 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

mac80211: Restart STA timers only on associated state

2011-08-05T04:58:35+00:00

commit 676b58c27475a9defccc025fea1cbd2b141ee539 upstream.

A panic was observed when the device is failed to resume properly,
and there are no running interfaces. ieee80211_reconfig tries
to restart STA timers on unassociated state.

Signed-off-by: Rajkumar Manoharan 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ethtool: Allow zero-length register dumps again

2011-08-05T04:58:34+00:00

commit 67ae7cf1eeda777f79259c4c6cb17a0bd28dee71 upstream.

Some drivers (ab)use the ethtool_ops::get_regs operation to expose
only a hardware revision ID.  Commit
a77f5db361ed9953b5b749353ea2c7fed2bf8d93 ('ethtool: Allocate register
dump buffer with vmalloc()') had the side-effect of breaking these, as
vmalloc() returns a null pointer for size=0 whereas kmalloc() did not.

For backward-compatibility, allow zero-length dumps again.

Reported-by: Kalle Valo 
Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bridge: send proper message_age in config BPDU

2011-08-05T04:58:31+00:00

commit 0c03150e7ea8f7fcd03cfef29385e0010b22ee92 upstream.

A bridge topology with three systems:

      +------+  +------+
      | A(2) |--| B(1) |
      +------+  +------+
           \    /
          +------+
          | C(3) |
          +------+

What is supposed to happen:
 * bridge with the lowest ID is elected root (for example: B)
 * C detects that A->C is higher cost path and puts in blocking state

What happens. Bridge with lowest id (B) is elected correctly as
root and things start out fine initially. But then config BPDU
doesn't get transmitted from A -> C. Because of that
the link from A-C is transistioned to the forwarding state.

The root cause of this is that the configuration messages
is generated with bogus message age, and dropped before
sending.

In the standardmessage_age is supposed to be:
  the time since the generation of the Configuration BPDU by
  the Root that instigated the generation of this Configuration BPDU.

Reimplement this by recording the timestamp (age + jiffies) when
recording config information. The old code incorrectly used the time
elapsed on the ageing timer which was incorrect.

See also:
  https://bugzilla.vyatta.com/show_bug.cgi?id=7164

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client

2011-07-20T05:10:28+00:00

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
  ceph: fix file mode calculation

ceph: fix file mode calculation

2011-07-19T18:25:04+00:00

open(2) must always include one of O_RDONLY, O_WRONLY, or O_RDWR.  No need
for any O_APPEND special case.

Passing O_WRONLY|O_RDWR is undefined according to the man page, but the
Linux VFS interprets this as O_RDWR, so we'll do the same.

This fixes open(2) with flags O_RDWR|O_APPEND, which was incorrectly being
translated to readonly.

Reported-by: Fyodor Ustinov 
Signed-off-by: Sage Weil

Bluetooth: Fix crash with incoming L2CAP connections

2011-07-16T17:14:44+00:00

Another regression fix considering incomming l2cap connections with
defer_setup enabled. In situations when incomming connection is
extracted with l2cap_sock_accept, it's bt_sock info will have
'parent' member zerroed, but 'parent' may be used unconditionally
in l2cap_conn_start() and l2cap_security_cfm() when defer_setup
is enabled.

Backtrace:
[] (l2cap_security_cfm+0x0/0x2ac [bluetooth]) from [] (hci_event_pac
ket+0xc2c/0x4aa4 [bluetooth])
[] (hci_event_packet+0x0/0x4aa4 [bluetooth]) from [] (hci_rx_task+0x
cc/0x27c [bluetooth])
[] (hci_rx_task+0x0/0x27c [bluetooth]) from [] (tasklet_action+0xa0/
0x15c)
[] (tasklet_action+0x0/0x15c) from [] (__do_softirq+0x98/0x130)
 r7:00000101 r6:00000018 r5:00000001 r4:efc46000
[] (__do_softirq+0x0/0x130) from [] (do_softirq+0x4c/0x58)
[] (do_softirq+0x0/0x58) from [] (run_ksoftirqd+0xb0/0x1b4)
 r4:efc46000 r3:00000001
[] (run_ksoftirqd+0x0/0x1b4) from [] (kthread+0x84/0x8c)
 r7:00000000 r6:c008f530 r5:efc47fc4 r4:efc41f08
[] (kthread+0x0/0x8c) from [] (do_exit+0x0/0x5f0)

Signed-off-by: Ilia Kolomisnky 
Signed-off-by: Gustavo F. Padovan 
Signed-off-by: David S. Miller

Bluetooth: Fix regression in L2CAP connection procedure

2011-07-16T17:14:44+00:00

Caused by the following commit, partially revert it.

commit 9fa7e4f76f3658ba1f44fbdb95c77e7df3f53f95
Author: Gustavo F. Padovan 
Date:   Thu Jun 30 16:11:30 2011 -0300

    Bluetooth: Fix regression with incoming L2CAP connections

    PTS test A2DP/SRC/SRC_SET/TC_SRC_SET_BV_02_I revealed that
    ( probably after the df3c3931e commit ) the l2cap connection
    could not be established in case when the "Auth Complete" HCI
    event does not arive before the initiator send "Configuration
    request", in which case l2cap replies with "Command rejected"
    since the channel is still in BT_CONNECT2 state.

Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Gustavo F. Padovan 
Signed-off-by: David S. Miller

net: remove NETIF_F_ALL_TX_OFFLOADS

2011-07-14T22:18:49+00:00

There is no software fallback implemented for SCTP or FCoE checksumming,
and so it should not be passed on by software devices like bridge or bonding.

For VLAN devices, this is different. First, the driver for underlying device
should be prepared to get offloaded packets even when the feature is disabled
(especially if it advertises it in vlan_features). Second, devices under
VLANs do not get replaced without tearing down the VLAN first.

This fixes a mess I accidentally introduced while converting bonding to
ndo_fix_features.

NETIF_F_SOFT_FEATURES are removed from BOND_VLAN_FEATURES because they
are unused as of commit 712ae51afd.

Signed-off-by: Michał Mirosław 
Signed-off-by: David S. Miller