linux-stable.git/drivers, branch v3.12.23

vxlan: use dev->needed_headroom instead of dev->hard_header_len

2014-06-23T08:28:05+00:00

[ Upstream commit 2853af6a2ea1a8ed09b09dd4fb578e7f435e8d34 ]

When we mirror packets from a vxlan tunnel to other device,
the mirror device should see the same packets (that is, without
outer header). Because vxlan tunnel sets dev->hard_header_len,
tcf_mirred() resets mac header back to outer mac, the mirror device
actually sees packets with outer headers

Vxlan tunnel should set dev->needed_headroom instead of
dev->hard_header_len, like what other ip tunnels do. This fixes
the above problem.

Cc: "David S. Miller" 
Cc: stephen hemminger 
Cc: Pravin B Shelar 
Signed-off-by: Cong Wang 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

net: force a list_del() in unregister_netdevice_many()

2014-06-23T08:28:03+00:00

[ Upstream commit 87757a917b0b3c0787e0563c679762152be81312 ]

unregister_netdevice_many() API is error prone and we had too
many bugs because of dangling LIST_HEAD on stacks.

See commit f87e6f47933e3e ("net: dont leave active on stack LIST_HEAD")

In fact, instead of making sure no caller leaves an active list_head,
just force a list_del() in the callee. No one seems to need to access
the list after unregister_netdevice_many()

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

net: qmi_wwan: add Olivetti Olicard modems

2014-06-23T08:28:02+00:00

[ Upstream commit ba6de0f5304ccdc45ae260e7e0feb6e0ef2dd558 ]

Lars writes: "I'm only 99% sure that the net interfaces are qmi
interfaces, nothing to lose by adding them in my opinion."

And I tend to agree based on the similarity with the two Olicard
modems we already have here.

Reported-by: Lars Melin 
Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

sh_eth: fix SH7619/771x support

2014-06-23T08:28:01+00:00

[ Upstream commit d8b0426af5b67973585712c9af36b86f6ea97815 ]

Commit 4a55530f38e4 (net: sh_eth: modify the definitions of register) managed
to leave out the E-DMAC register entries in sh_eth_offset_fast_sh3_sh2[], thus
totally breaking SH7619/771x support.  Add the missing entries using  the data
from before that commit.

Signed-off-by: Sergei Shtylyov 
Acked-by: Yoshihiro Shimoda 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

sh_eth: use RNC mode for packet reception

2014-06-23T08:28:01+00:00

[ Upstream commit 530aa2d0d9d55ab2775d47621ddf4b5b15bc1110 ]

The current behaviour of the sh_eth driver is not to use the RNC bit
for the receive ring. This means that every packet recieved is not only
generating an IRQ but it also stops the receive ring DMA as well until
the driver re-enables it after unloading the packet.

This means that a number of the following errors are generated due to
the receive packet FIFO overflowing due to nowhere to put packets:

	net eth0: Receive FIFO Overflow

Since feedback from Yoshihiro Shimoda shows that every supported LSI
for this driver should have the bit enabled it seems the best way is
to remove the RMCR default value from the per-system data and just
write it when initialising the RMCR value. This is discussed in
the message (http://www.spinics.net/lists/netdev/msg284912.html).

I have tested the 0x00000001 configuration with NFS root filesystem and
the driver has not failed yet.  There are further test reports from
Sergei Shtylov and others for both the R8A7790 and R8A7791.

There is also feedback fron Cao Minh Hiep[1] which reports the
same issue in (http://comments.gmane.org/gmane.linux.network/316285)
showing this fixes issues with losing UDP datagrams under iperf.

Tested-by: Sergei Shtylyov 
Signed-off-by: Ben Dooks 
Acked-by: Yoshihiro Shimoda 
Acked-by: Simon Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

team: fix mtu setting

2014-06-23T08:28:00+00:00

[ Upstream commit 9d0d68faea6962d62dd501cd6e71ce5cc8ed262b ]

Now it is not possible to set mtu to team device which has a port
enslaved to it. The reason is that when team_change_mtu() calls
dev_set_mtu() for port device, notificator for NETDEV_PRECHANGEMTU
event is called and team_device_event() returns NOTIFY_BAD forbidding
the change. So fix this by returning NOTIFY_DONE here in case team is
changing mtu in team_change_mtu().

Introduced-by: 3d249d4c "net: introduce ethernet teaming device"
Signed-off-by: Jiri Pirko 
Acked-by: Flavio Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

qlcnic: info leak in qlcnic_dcb_peer_app_info()

2014-06-23T08:27:57+00:00

[ Upstream commit 7df566bbdd0af0785542b89466a937e94257fcfb ]

This function is called from dcbnl_build_peer_app().  The "info"
struct isn't initialized at all so we disclose 2 bytes of uninitialized
stack data.  We should clear it before passing it to the user.

Fixes: 48365e485275 ('qlcnic: dcb: Add support for CEE Netlink interface.')
Signed-off-by: Dan Carpenter 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

net: Use netlink_ns_capable to verify the permisions of netlink messages

2014-06-23T08:27:57+00:00

[ Upstream commit 90f62cf30a78721641e08737bda787552428061e ]

It is possible by passing a netlink socket to a more privileged
executable and then to fool that executable into writing to the socket
data that happens to be valid netlink message to do something that
privileged executable did not intend to do.

To keep this from happening replace bare capable and ns_capable calls
with netlink_capable, netlink_net_calls and netlink_ns_capable calls.
Which act the same as the previous calls except they verify that the
opener of the socket had the desired permissions as well.

Reported-by: Andy Lutomirski 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

iscsi-target: Reject mutual authentication with reflected CHAP_C

2014-06-23T08:27:53+00:00

commit 1d2b60a5545942b1376cb48c1d55843d71e3a08f upstream.

This patch adds an explicit check in chap_server_compute_md5() to ensure
the CHAP_C value received from the initiator during mutual authentication
does not match the original CHAP_C provided by the target.

This is in line with RFC-3720, section 8.2.1:

   Originators MUST NOT reuse the CHAP challenge sent by the Responder
   for the other direction of a bidirectional authentication.
   Responders MUST check for this condition and close the iSCSI TCP
   connection if it occurs.

Reported-by: Tejas Vaykole 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Jiri Slaby

rtc: rtc-at91rm9200: fix infinite wait for ACKUPD irq

2014-06-23T08:27:53+00:00

commit 2fe121e1f5aa3bf31b418a9790db6c400e922291 upstream.

The rtc user must wait at least 1 sec between each time/calandar update
(see atmel's datasheet chapter "Updating Time/Calendar").

Use the 1Hz interrupt to update the at91_rtc_upd_rdy flag and wait for
the at91_rtc_wait_upd_rdy event if the rtc is not ready.

This patch fixes a deadlock in an uninterruptible wait when the RTC is
updated more than once every second.  AFAICT the bug is here from the
beginning, but I think we should at least backport this fix to 3.10 and
the following longterm and stable releases.

Signed-off-by: Boris BREZILLON 
Reported-by: Bryan Evenson 
Tested-by: Bryan Evenson 
Cc: Andrew Victor 
Cc: Nicolas Ferre 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby