linux-stable.git, branch v4.8.8

Linux 4.8.8

2016-11-15T06:49:06+00:00

scsi: megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression

2016-11-15T06:48:54+00:00

commit 5e5ec1759dd663a1d5a2f10930224dd009e500e8 upstream.

This patch will fix regression caused by commit 1e793f6fc0db ("scsi:
megaraid_sas: Fix data integrity failure for JBOD (passthrough)
devices").

The problem was that the MEGASAS_IS_LOGICAL macro did not have braces
and as a result the driver ended up exposing a lot of non-existing SCSI
devices (all SCSI commands to channels 1,2,3 were returned as
SUCCESS-DID_OK by driver).

[mkp: clarified patch description]

Fixes: 1e793f6fc0db920400574211c48f9157a37e3945
Reported-by: Jens Axboe 
Signed-off-by: Kashyap Desai 
Signed-off-by: Sumit Saxena 
Tested-by: Sumit Saxena 
Reviewed-by: Tomas Henzl 
Tested-by: Jens Axboe 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices

2016-11-15T06:48:54+00:00

commit 1e793f6fc0db920400574211c48f9157a37e3945 upstream.

Commit 02b01e010afe ("megaraid_sas: return sync cache call with
success") modified the driver to successfully complete SYNCHRONIZE_CACHE
commands without passing them to the controller. Disk drive caches are
only explicitly managed by controller firmware when operating in RAID
mode. So this commit effectively disabled writeback cache flushing for
any drives used in JBOD mode, leading to data integrity failures.

[mkp: clarified patch description]

Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
Signed-off-by: Kashyap Desai 
Signed-off-by: Sumit Saxena 
Reviewed-by: Tomas Henzl 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Ewan D. Milne 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: gadget: properly account queued requests

2016-11-15T06:48:54+00:00

commit a9c3ca5fae6bf73770f0576eaf57d5f1305ef4b3 upstream.

Some requests could be accounted for multiple
times. Let's fix that so each and every requests is
accounted for only once.

Fixes: 55a0237f8f47 ("usb: dwc3: gadget: use allocated/queued reqs for LST bit")
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

arch/powerpc: Update parameters for csum_tcpudp_magic & csum_tcpudp_nofold

2016-11-15T06:48:54+00:00

[ Upstream commit f9d4286b9516b02e795214412d36885f572b57ad ]

Commit 01cfbad "ipv4: Update parameters for csum_tcpudp_magic to their
original types" changed parameters for csum_tcpudp_magic and
csum_tcpudp_nofold for many platforms but not for PowerPC.

Fixes: 01cfbad "ipv4: Update parameters for csum_tcpudp_magic to their original types"
Cc: Alexander Duyck 
Signed-off-by: Ivan Vecera 
Acked-by: Alexander Duyck 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

packet: on direct_xmit, limit tso and csum to supported devices

2016-11-15T06:48:53+00:00

[ Upstream commit 104ba78c98808ae837d1f63aae58c183db5505df ]

When transmitting on a packet socket with PACKET_VNET_HDR and
PACKET_QDISC_BYPASS, validate device support for features requested
in vnet_hdr.

Drop TSO packets sent to devices that do not support TSO or have the
feature disabled. Note that the latter currently do process those
packets correctly, regardless of not advertising the feature.

Because of SKB_GSO_DODGY, it is not sufficient to test device features
with netif_needs_gso. Full validate_xmit_skb is needed.

Switch to software checksum for non-TSO packets that request checksum
offload if that device feature is unsupported or disabled. Note that
similar to the TSO case, device drivers may perform checksum offload
correctly even when not advertising it.

When switching to software checksum, packets hit skb_checksum_help,
which has two BUG_ON checksum not in linear segment. Packet sockets
always allocate at least up to csum_start + csum_off + 2 as linear.

Tested by running github.com/wdebruij/kerneltools/psock_txring_vnet.c

  ethtool -K eth0 tso off tx on
  psock_txring_vnet -d $dst -s $src -i eth0 -l 2000 -n 1 -q -v
  psock_txring_vnet -d $dst -s $src -i eth0 -l 2000 -n 1 -q -v -N

  ethtool -K eth0 tx off
  psock_txring_vnet -d $dst -s $src -i eth0 -l 1000 -n 1 -q -v -G
  psock_txring_vnet -d $dst -s $src -i eth0 -l 1000 -n 1 -q -v -G -N

v2:
  - add EXPORT_SYMBOL_GPL(validate_xmit_skb_list)

Fixes: d346a3fae3ff ("packet: introduce PACKET_QDISC_BYPASS socket option")
Signed-off-by: Willem de Bruijn 
Acked-by: Eric Dumazet 
Acked-by: Daniel Borkmann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ip6_tunnel: Update skb->protocol to ETH_P_IPV6 in ip6_tnl_xmit()

2016-11-15T06:48:53+00:00

[ Upstream commit ae148b085876fa771d9ef2c05f85d4b4bf09ce0d ]

This patch updates skb->protocol to ETH_P_IPV6 in ip6_tnl_xmit() when an
IPv6 header is installed to a socket buffer.

This is not a cosmetic change.  Without updating this value, GSO packets
transmitted through an ipip6 tunnel have the protocol of ETH_P_IP and
skb_mac_gso_segment() will attempt to call gso_segment() for IPv4,
which results in the packets being dropped.

Fixes: b8921ca83eed ("ip4ip6: Support for GSO/GRO")
Signed-off-by: Eli Cooper 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sctp: validate chunk len before actually using it

2016-11-15T06:48:53+00:00

[ Upstream commit bf911e985d6bbaa328c20c3e05f4eb03de11fdd6 ]

Andrey Konovalov reported that KASAN detected that SCTP was using a slab
beyond the boundaries. It was caused because when handling out of the
blue packets in function sctp_sf_ootb() it was checking the chunk len
only after already processing the first chunk, validating only for the
2nd and subsequent ones.

The fix is to just move the check upwards so it's also validated for the
1st chunk.

Reported-by: Andrey Konovalov 
Tested-by: Andrey Konovalov 
Signed-off-by: Marcelo Ricardo Leitner 
Reviewed-by: Xin Long 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net sched filters: fix notification of filter delete with proper handle

2016-11-15T06:48:53+00:00

[ Upstream commit 9ee7837449b3d6f0fcf9132c6b5e5aaa58cc67d4 ]

Daniel says:

While trying out [1][2], I noticed that tc monitor doesn't show the
correct handle on delete:

$ tc monitor
qdisc clsact ffff: dev eno1 parent ffff:fff1
filter dev eno1 ingress protocol all pref 49152 bpf handle 0x2a [...]
deleted filter dev eno1 ingress protocol all pref 49152 bpf handle 0xf3be0c80

some context to explain the above:
The user identity of any tc filter is represented by a 32-bit
identifier encoded in tcm->tcm_handle. Example 0x2a in the bpf filter
above. A user wishing to delete, get or even modify a specific filter
uses this handle to reference it.
Every classifier is free to provide its own semantics for the 32 bit handle.
Example: classifiers like u32 use schemes like 800:1:801 to describe
the semantics of their filters represented as hash table, bucket and
node ids etc.
Classifiers also have internal per-filter representation which is different
from this externally visible identity. Most classifiers set this
internal representation to be a pointer address (which allows fast retrieval
of said filters in their implementations). This internal representation
is referenced with the "fh" variable in the kernel control code.

When a user successfuly deletes a specific filter, by specifying the correct
tcm->tcm_handle, an event is generated to user space which indicates
which specific filter was deleted.

Before this patch, the "fh" value was sent to user space as the identity.
As an example what is shown in the sample bpf filter delete event above
is 0xf3be0c80. This is infact a 32-bit truncation of 0xffff8807f3be0c80
which happens to be a 64-bit memory address of the internal filter
representation (address of the corresponding filter's struct cls_bpf_prog);

After this patch the appropriate user identifiable handle as encoded
in the originating request tcm->tcm_handle is generated in the event.
One of the cardinal rules of netlink rules is to be able to take an
event (such as a delete in this case) and reflect it back to the
kernel and successfully delete the filter. This patch achieves that.

Note, this issue has existed since the original TC action
infrastructure code patch back in 2004 as found in:
https://git.kernel.org/cgit/linux/kernel/git/history/history.git/commit/

[1] http://patchwork.ozlabs.org/patch/682828/
[2] http://patchwork.ozlabs.org/patch/682829/

Fixes: 4e54c4816bfe ("[NET]: Add tc extensions infrastructure.")
Reported-by: Daniel Borkmann 
Acked-by: Cong Wang 
Signed-off-by: Jamal Hadi Salim 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: ipv6: Do not consider link state for nexthop validation

2016-11-15T06:48:53+00:00

[ Upstream commit d5d32e4b76687f4df9ad3ba8d3702b7347f51fa6 ]

Similar to IPv4, do not consider link state when validating next hops.

Currently, if the link is down default routes can fail to insert:
 $ ip -6 ro add vrf blue default via 2100:2::64 dev eth2
 RTNETLINK answers: No route to host

With this patch the command succeeds.

Fixes: 8c14586fc320 ("net: ipv6: Use passed in table for nexthop lookups")
Signed-off-by: David Ahern 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman