04 Feb, 2017

28 commits

  • [ Upstream commit 0fb44559ffd67de8517098b81f675fa0210f13f0 ]

    Dmitry reported a deadlock scenario:

    unix_bind() path:
    u->bindlock ==> sb_writer

    do_splice() path:
    sb_writer ==> pipe->mutex ==> u->bindlock

    In the unix_bind() code path, unix_mknod() does not have to
    be done with u->bindlock held, since it is a pure fs operation,
    so we can just move unix_mknod() out.

    Reported-by: Dmitry Vyukov
    Tested-by: Dmitry Vyukov
    Cc: Rainer Weikusat
    Cc: Al Viro
    Signed-off-by: Cong Wang
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    WANG Cong
     
  • [ Upstream commit 6a0b76c04ec157c88ca943debf78a8ee58469f2d ]

    Runtime suspend shouldn't be executed if the tx queue is not empty,
    because the device is not idle.

    Signed-off-by: Hayes Wang
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    hayeswang
     
  • [ Upstream commit 9f427a0e474a67b454420c131709600d44850486 ]

    MPLS multipath for LSR is broken -- always selecting the first nexthop
    in the one label case. For example:

    $ ip -f mpls ro ls
    100
    nexthop as to 200 via inet 172.16.2.2 dev virt12
    nexthop as to 300 via inet 172.16.3.2 dev virt13
    101
    nexthop as to 201 via inet6 2000:2::2 dev virt12
    nexthop as to 301 via inet6 2000:3::2 dev virt13

    In this example incoming packets have a single MPLS labels which means
    BOS bit is set. The BOS bit is passed from mpls_forward down to
    mpls_multipath_hash which never processes the hash loop because BOS is 1.

    Update mpls_multipath_hash to process the entire label stack. mpls_hdr_len
    tracks the total mpls header length on each pass (on pass N mpls_hdr_len
    is N * sizeof(mpls_shim_hdr)). When the label is found with the BOS set
    it verifies the skb has sufficient header for ipv4 or ipv6, and find the
    IPv4 and IPv6 header by using the last mpls_hdr pointer and adding 1 to
    advance past it.

    With these changes I have verified the code correctly sees the label,
    BOS, IPv4 and IPv6 addresses in the network header and icmp/tcp/udp
    traffic for ipv4 and ipv6 are distributed across the nexthops.

    Fixes: 1c78efa8319ca ("mpls: flow-based multipath selection")
    Acked-by: Robert Shearman
    Signed-off-by: David Ahern
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    David Ahern
     
  • [ Upstream commit b6677449dff674cf5b81429b11d5c7f358852ef9 ]

    Any bridge options specified during link creation (e.g. ip link add)
    are ignored as br_dev_newlink() does not process them.
    Use br_changelink() to do it.

    Fixes: 133235161721 ("bridge: implement rtnl_link_ops->changelink")
    Signed-off-by: Ivan Vecera
    Reviewed-by: Jiri Pirko
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Ivan Vecera
     
  • [ Upstream commit e048fc50d7bde23136e098e04a324d7e3404408d ]

    A driver using dev_alloc_page() must not reuse a page allocated from
    emergency memory reserve.

    Otherwise all packets using this page will be immediately dropped,
    unless for very specific sockets having SOCK_MEMALLOC bit set.

    This issue might be hard to debug, because only a fraction of received
    packets would be dropped.

    Fixes: 4415a0319f92 ("net/mlx5e: Implement RX mapped page cache for page recycle")
    Signed-off-by: Eric Dumazet
    Cc: Tariq Toukan
    Cc: Saeed Mahameed
    Acked-by: Saeed Mahameed
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Eric Dumazet
     
  • [ Upstream commit 0dbd7ff3ac5017a46033a9d0a87a8267d69119d9 ]

    Found that if we run LTP netstress test with large MSS (65K),
    the first attempt from server to send data comparable to this
    MSS on fastopen connection will be delayed by the probe timer.

    Here is an example:

    < S seq 0:0 win 43690 options [mss 65495 wscale 7 tfo cookie] length 32
    > S. seq 0:0 ack 1 win 43690 options [mss 65495 wscale 7] length 0
    < . ack 1 win 342 length 0

    Inside tcp_sendmsg(), tcp_send_mss() returns max MSS in 'mss_now',
    as well as in 'size_goal'. This results the segment not queued for
    transmition until all the data copied from user buffer. Then, inside
    __tcp_push_pending_frames(), it breaks on send window test and
    continues with the check probe timer.

    Fragmentation occurs in tcp_write_wakeup()...

    +0.2 > P. seq 1:43777 ack 1 win 342 length 43776
    < . ack 43777, win 1365 length 0
    > P. seq 43777:65001 ack 1 win 342 options [...] length 21224
    ...

    This also contradicts with the fact that we should bound to the half
    of the window if it is large.

    Fix this flaw by correctly initializing max_window. Before that, it
    could have large values that affect further calculations of 'size_goal'.

    Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
    Signed-off-by: Alexey Kodanev
    Acked-by: Eric Dumazet
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Alexey Kodanev
     
  • [ Upstream commit 03e4deff4987f79c34112c5ba4eb195d4f9382b0 ]

    Just like commit 4acd4945cd1e ("ipv6: addrconf: Avoid calling
    netdevice notifiers with RCU read-side lock"), it is unnecessary
    to make addrconf_disable_change() use RCU iteration over the
    netdev list, since it already holds the RTNL lock, or we may meet
    Illegal context switch in RCU read-side critical section.

    Signed-off-by: Kefeng Wang
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Kefeng Wang
     
  • [ Upstream commit 9ed59592e3e379b2e9557dc1d9e9ec8fcbb33f16]

    Trying to add an mpls encap route when the MPLS modules are not loaded
    hangs. For example:

    CONFIG_MPLS=y
    CONFIG_NET_MPLS_GSO=m
    CONFIG_MPLS_ROUTING=m
    CONFIG_MPLS_IPTUNNEL=m

    $ ip route add 10.10.10.10/32 encap mpls 100 via inet 10.100.1.2

    The ip command hangs:
    root 880 826 0 21:25 pts/0 00:00:00 ip route add 10.10.10.10/32 encap mpls 100 via inet 10.100.1.2

    $ cat /proc/880/stack
    [] call_usermodehelper_exec+0xd6/0x134
    [] __request_module+0x27b/0x30a
    [] lwtunnel_build_state+0xe4/0x178
    [] fib_create_info+0x47f/0xdd4
    [] fib_table_insert+0x90/0x41f
    [] inet_rtm_newroute+0x4b/0x52
    ...

    modprobe is trying to load rtnl-lwt-MPLS:

    root 881 5 0 21:25 ? 00:00:00 /sbin/modprobe -q -- rtnl-lwt-MPLS

    and it hangs after loading mpls_router:

    $ cat /proc/881/stack
    [] rtnl_lock+0x12/0x14
    [] register_netdevice_notifier+0x16/0x179
    [] mpls_init+0x25/0x1000 [mpls_router]
    [] do_one_initcall+0x8e/0x13f
    [] do_init_module+0x5a/0x1e5
    [] load_module+0x13bd/0x17d6
    ...

    The problem is that lwtunnel_build_state is called with rtnl lock
    held preventing mpls_init from registering.

    Given the potential references held by the time lwtunnel_build_state it
    can not drop the rtnl lock to the load module. So, extract the module
    loading code from lwtunnel_build_state into a new function to validate
    the encap type. The new function is called while converting the user
    request into a fib_config which is well before any table, device or
    fib entries are examined.

    Fixes: 745041e2aaf1 ("lwtunnel: autoload of lwt modules")
    Signed-off-by: David Ahern
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    David Ahern
     
  • [ Upstream commit cd33b3e0da43522ff8e8f2b2b71d3d08298512b0 ]

    Commit a1cba5613edf ("net: phy: Add Broadcom phy library for common
    interfaces") make the BCM63xx PHY driver utilize bcm_phy_config_intr()
    which would appear to do the right thing, except that it does not write
    to the MII_BCM63XX_IR register but to MII_BCM54XX_ECR which is
    different.

    This would be causing invalid link parameters and events from being
    generated by the PHY interrupt.

    Fixes: a1cba5613edf ("net: phy: Add Broadcom phy library for common interfaces")
    Signed-off-by: Daniel Gonzalez Cabanelas
    Signed-off-by: Florian Fainelli
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Daniel Gonzalez Cabanelas
     
  • [ Upstream commit 7be2c82cfd5d28d7adb66821a992604eb6dd112e ]

    Ashizuka reported a highmem oddity and sent a patch for freescale
    fec driver.

    But the problem root cause is that core networking stack
    must ensure no skb with highmem fragment is ever sent through
    a device that does not assert NETIF_F_HIGHDMA in its features.

    We need to call illegal_highdma() from harmonize_features()
    regardless of CSUM checks.

    Fixes: ec5f06156423 ("net: Kill link between CSUM and SG features.")
    Signed-off-by: Eric Dumazet
    Cc: Pravin Shelar
    Reported-by: "Ashizuka, Yuusuke"
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Eric Dumazet
     
  • [ Upstream commit d5ff72d9af73bc3cbaa3edb541333a851f8c7295 ]

    vxlan->cfg.dst_port is in network byte order, so an htons()
    is needed here. Also reduced comment length to stay closer
    to 80 column width (still slightly over, however).

    Fixes: e1e5314de08b ("vxlan: implement GPE")
    Signed-off-by: Lance Richardson
    Acked-by: Jiri Benc
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Lance Richardson
     
  • [ Upstream commit 6391a4481ba0796805d6581e42f9f0418c099e34 ]

    Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
    xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
    fixing this by adding a hint (has_data_valid) and set it only on the
    receiving path.

    Cc: Rolf Neugebauer
    Signed-off-by: Jason Wang
    Acked-by: Rolf Neugebauer
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Jason Wang
     
  • [ Upstream commit 501db511397fd6efff3aa5b4e8de415b55559550 ]

    This patch part reverts fd2a0437dc33 and e858fae2b0b8 which introduced a
    subtle change in how the virtio_net flags are derived from the SKBs
    ip_summed field.

    With the above commits, the flags are set to VIRTIO_NET_HDR_F_DATA_VALID
    when ip_summed == CHECKSUM_UNNECESSARY, thus treating it differently to
    ip_summed == CHECKSUM_NONE, which should be the same.

    Further, the virtio spec 1.0 / CS04 explicitly says that
    VIRTIO_NET_HDR_F_DATA_VALID must not be set by the driver.

    Fixes: fd2a0437dc33 ("virtio_net: introduce virtio_net_hdr_{from,to}_skb")
    Fixes: e858fae2b0b8 (" virtio_net: use common code for virtio_net_hdr and skb GSO conversion")
    Signed-off-by: Rolf Neugebauer
    Acked-by: Michael S. Tsirkin
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Rolf Neugebauer
     
  • [ Upstream commit 0faa9cb5b3836a979864a6357e01d2046884ad52 ]

    Demonstrating the issue:

    .. add a drop action
    $sudo $TC actions add action drop index 10

    .. retrieve it
    $ sudo $TC -s actions get action gact index 10

    action order 1: gact action drop
    random type none pass val 0
    index 10 ref 2 bind 0 installed 29 sec used 29 sec
    Action statistics:
    Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    backlog 0b 0p requeues 0

    ... bug 1 above: reference is two.
    Reference is actually 1 but we forget to subtract 1.

    ... do a GET again and we see the same issue
    try a few times and nothing changes
    ~$ sudo $TC -s actions get action gact index 10

    action order 1: gact action drop
    random type none pass val 0
    index 10 ref 2 bind 0 installed 31 sec used 31 sec
    Action statistics:
    Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    backlog 0b 0p requeues 0

    ... lets try to bind the action to a filter..
    $ sudo $TC qdisc add dev lo ingress
    $ sudo $TC filter add dev lo parent ffff: protocol ip prio 1 \
    u32 match ip dst 127.0.0.1/32 flowid 1:1 action gact index 10

    ... and now a few GETs:
    $ sudo $TC -s actions get action gact index 10

    action order 1: gact action drop
    random type none pass val 0
    index 10 ref 3 bind 1 installed 204 sec used 204 sec
    Action statistics:
    Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    backlog 0b 0p requeues 0

    $ sudo $TC -s actions get action gact index 10

    action order 1: gact action drop
    random type none pass val 0
    index 10 ref 4 bind 1 installed 206 sec used 206 sec
    Action statistics:
    Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    backlog 0b 0p requeues 0

    $ sudo $TC -s actions get action gact index 10

    action order 1: gact action drop
    random type none pass val 0
    index 10 ref 5 bind 1 installed 235 sec used 235 sec
    Action statistics:
    Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    backlog 0b 0p requeues 0

    .... as can be observed the reference count keeps going up.

    After the fix

    $ sudo $TC actions add action drop index 10
    $ sudo $TC -s actions get action gact index 10

    action order 1: gact action drop
    random type none pass val 0
    index 10 ref 1 bind 0 installed 4 sec used 4 sec
    Action statistics:
    Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    backlog 0b 0p requeues 0

    $ sudo $TC -s actions get action gact index 10

    action order 1: gact action drop
    random type none pass val 0
    index 10 ref 1 bind 0 installed 6 sec used 6 sec
    Action statistics:
    Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    backlog 0b 0p requeues 0

    $ sudo $TC qdisc add dev lo ingress
    $ sudo $TC filter add dev lo parent ffff: protocol ip prio 1 \
    u32 match ip dst 127.0.0.1/32 flowid 1:1 action gact index 10

    $ sudo $TC -s actions get action gact index 10

    action order 1: gact action drop
    random type none pass val 0
    index 10 ref 2 bind 1 installed 32 sec used 32 sec
    Action statistics:
    Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    backlog 0b 0p requeues 0

    $ sudo $TC -s actions get action gact index 10

    action order 1: gact action drop
    random type none pass val 0
    index 10 ref 2 bind 1 installed 33 sec used 33 sec
    Action statistics:
    Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    backlog 0b 0p requeues 0

    Fixes: aecc5cefc389 ("net sched actions: fix GETing actions")
    Signed-off-by: Jamal Hadi Salim
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Jamal Hadi Salim
     
  • [ Upstream commit 8a367e74c0120ef68c8c70d5a025648c96626dff ]

    The ax.25 socket connection timed out & the sock struct has been
    previously taken down ie. sock struct is now a NULL pointer. Checking
    the sock_flag causes the segfault. Check if the socket struct pointer
    is NULL before checking sock_flag. This segfault is seen in
    timed out netrom connections.

    Please submit to -stable.

    Signed-off-by: Basil Gunn
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Basil Gunn
     
  • [ Upstream commit 02ca0423fd65a0a9c4d70da0dbb8f4b8503f08c7 ]

    With ip6gre we have a tunnel header which also makes the tunnel MTU
    smaller. We need to reserve room for it. Previously we were using up
    space reserved for the Tunnel Encapsulation Limit option
    header (RFC 2473).

    Also, after commit b05229f44228 ("gre6: Cleanup GREv6 transmit path,
    call common GRE functions") our contract with the caller has
    changed. Now we check if the packet length exceeds the tunnel MTU after
    the tunnel header has been pushed, unlike before.

    This is reflected in the check where we look at the packet length minus
    the size of the tunnel header, which is already accounted for in tunnel
    MTU.

    Fixes: b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE functions")
    Signed-off-by: Jakub Sitnicki
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Jakub Sitnicki
     
  • [ Upstream commit 8ec3e8a192ba6f13be4522ee81227c792c86fb1a ]

    Due to alignment requirements of the hardware transmissions are split into
    two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
    followed by a descriptor for rest of the packet.

    In the case of IP packets the first descriptor will never be zero due to
    the way that the stack aligns buffers for IP packets. However, for non-IP
    packets it may be zero.

    In that case it has been reported that timeouts occur, presumably because
    transmission stops at the first zero-length DMA descriptor and thus the
    packet is not transmitted. However, in my environment a BUG is triggered as
    follows:

    [ 20.381417] ------------[ cut here ]------------
    [ 20.386054] kernel BUG at lib/swiotlb.c:495!
    [ 20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [ 20.395805] Modules linked in:
    [ 20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f #162
    [ 20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
    [ 20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
    [ 20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
    [ 20.424625] LR is at map_single+0x4c/0x98
    [ 20.428629] pc : [] lr : [] pstate: 800001c5
    [ 20.436019] sp : ffff80063a71f9b0
    [ 20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
    [ 20.444636] x27: ffff000008ed5000 x26: 0000000000000000
    [ 20.449944] x25: 000000067abe2adc x24: 0000000000000000
    [ 20.455252] x23: 0000000000200000 x22: 0000000000000001
    [ 20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
    [ 20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
    [ 20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
    [ 20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
    [ 20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
    [ 20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
    [ 20.492407] x9 : 0000000000000000 x8 : 0000000000000000
    [ 20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
    [ 20.503028] x5 : 0000000000000000 x4 : 0000000000000001
    [ 20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
    [ 20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
    [ 20.518958]
    [ 20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
    [ 20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
    [ 20.532543] f9a0: ffff80063a71fa30 ffff00000839c680
    [ 20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
    [ 20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
    [ 20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
    [ 20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
    [ 20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
    [ 20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
    [ 20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
    [ 20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
    [ 20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
    [ 20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
    [ 20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
    [ 20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
    [ 20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
    [ 20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
    [ 20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
    [ 20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
    [ 20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
    [ 20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
    [ 20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
    [ 20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
    [ 20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
    [ 20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
    [ 20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
    [ 20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
    [ 20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
    [ 20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
    [ 20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
    [ 20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
    [ 20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
    [ 20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    [ 20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
    [ 20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
    [ 20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
    [ 20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
    [ 20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
    [ 20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
    [ 20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
    [ 20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
    [ 20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
    [ 20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
    [ 20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
    [ 20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
    [ 20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
    [ 20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
    [ 20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
    [ 20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
    [ 20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
    [ 20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
    [ 20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
    [ 20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
    [ 20.931867] Call trace:
    [ 20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
    [ 20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
    [ 20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
    [ 20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
    [ 20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
    [ 20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
    [ 20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
    [ 20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
    [ 20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
    [ 21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
    [ 21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
    [ 21.016097] [] swiotlb_tbl_map_single+0x178/0x2ec
    [ 21.022362] [] map_single+0x4c/0x98
    [ 21.027411] [] swiotlb_map_page+0xa4/0x138
    [ 21.033072] [] __swiotlb_map_page+0x20/0x7c
    [ 21.038821] [] ravb_start_xmit+0x174/0x668
    [ 21.044484] [] dev_hard_start_xmit+0x8c/0x120
    [ 21.050407] [] sch_direct_xmit+0x108/0x1a0
    [ 21.056064] [] __dev_queue_xmit+0x194/0x4cc
    [ 21.061807] [] dev_queue_xmit+0x10/0x18
    [ 21.067214] [] packet_sendmsg+0xf40/0x1220
    [ 21.072873] [] sock_sendmsg+0x18/0x2c
    [ 21.078097] [] SyS_sendto+0xb0/0xf0
    [ 21.083150] [] el0_svc_naked+0x24/0x28
    [ 21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
    [ 21.094611] ---[ end trace 5bc544ad491f3814 ]---
    [ 21.099234] Kernel panic - not syncing: Fatal exception in interrupt
    [ 21.105587] Kernel Offset: disabled
    [ 21.109073] Memory Limit: none
    [ 21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

    Fixes: 2f45d1902acf ("ravb: minimize TX data copying")
    Signed-off-by: Masaru Nagai
    Acked-by: Sergei Shtylyov
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Masaru Nagai
     
  • [ Upstream commit 8cf699ec849f4ca1413cea01289bd7d37dbcc626 ]

    Disable BH around the call to napi_schedule() to avoid following warning

    [ 52.095499] NOHZ: local_softirq_pending 08
    [ 52.421291] NOHZ: local_softirq_pending 08
    [ 52.608313] NOHZ: local_softirq_pending 08

    Fixes: 8d59de8f7bb3 ("net/mlx4_en: Process all completions in RX rings after port goes up")
    Signed-off-by: Eric Dumazet
    Cc: Erez Shitrit
    Cc: Eugenia Emantayev
    Cc: Tariq Toukan
    Acked-by: Tariq Toukan
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Eric Dumazet
     
  • [ Upstream commit 75f01a4c9cc291ff5cb28ca1216adb163b7a20ee ]

    When executing conntrack actions on skbuffs with checksum mode
    CHECKSUM_COMPLETE, the checksum must be updated to account for
    header pushes and pulls. Otherwise we get "hw csum failure"
    logs similar to this (ICMP packet received on geneve tunnel
    via ixgbe NIC):

    [ 405.740065] genev_sys_6081: hw csum failure
    [ 405.740106] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G I 4.10.0-rc3+ #1
    [ 405.740108] Call Trace:
    [ 405.740110]
    [ 405.740113] dump_stack+0x63/0x87
    [ 405.740116] netdev_rx_csum_fault+0x3a/0x40
    [ 405.740118] __skb_checksum_complete+0xcf/0xe0
    [ 405.740120] nf_ip_checksum+0xc8/0xf0
    [ 405.740124] icmp_error+0x1de/0x351 [nf_conntrack_ipv4]
    [ 405.740132] nf_conntrack_in+0xe1/0x550 [nf_conntrack]
    [ 405.740137] ? find_bucket.isra.2+0x62/0x70 [openvswitch]
    [ 405.740143] __ovs_ct_lookup+0x95/0x980 [openvswitch]
    [ 405.740145] ? netif_rx_internal+0x44/0x110
    [ 405.740149] ovs_ct_execute+0x147/0x4b0 [openvswitch]
    [ 405.740153] do_execute_actions+0x22e/0xa70 [openvswitch]
    [ 405.740157] ovs_execute_actions+0x40/0x120 [openvswitch]
    [ 405.740161] ovs_dp_process_packet+0x84/0x120 [openvswitch]
    [ 405.740166] ovs_vport_receive+0x73/0xd0 [openvswitch]
    [ 405.740168] ? udp_rcv+0x1a/0x20
    [ 405.740170] ? ip_local_deliver_finish+0x93/0x1e0
    [ 405.740172] ? ip_local_deliver+0x6f/0xe0
    [ 405.740174] ? ip_rcv_finish+0x3a0/0x3a0
    [ 405.740176] ? ip_rcv_finish+0xdb/0x3a0
    [ 405.740177] ? ip_rcv+0x2a7/0x400
    [ 405.740180] ? __netif_receive_skb_core+0x970/0xa00
    [ 405.740185] netdev_frame_hook+0xd3/0x160 [openvswitch]
    [ 405.740187] __netif_receive_skb_core+0x1dc/0xa00
    [ 405.740194] ? ixgbe_clean_rx_irq+0x46d/0xa20 [ixgbe]
    [ 405.740197] __netif_receive_skb+0x18/0x60
    [ 405.740199] netif_receive_skb_internal+0x40/0xb0
    [ 405.740201] napi_gro_receive+0xcd/0x120
    [ 405.740204] gro_cell_poll+0x57/0x80 [geneve]
    [ 405.740206] net_rx_action+0x260/0x3c0
    [ 405.740209] __do_softirq+0xc9/0x28c
    [ 405.740211] irq_exit+0xd9/0xf0
    [ 405.740213] do_IRQ+0x51/0xd0
    [ 405.740215] common_interrupt+0x93/0x93

    Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
    Signed-off-by: Lance Richardson
    Acked-by: Pravin B Shelar
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Lance Richardson
     
  • [ Upstream commit 003c941057eaa868ca6fedd29a274c863167230d ]

    Fix up a data alignment issue on sparc by swapping the order
    of the cookie byte array field with the length field in
    struct tcp_fastopen_cookie, and making it a proper union
    to clean up the typecasting.

    This addresses log complaints like these:
    log_unaligned: 113 callbacks suppressed
    Kernel unaligned access at TPC[976490] tcp_try_fastopen+0x2d0/0x360
    Kernel unaligned access at TPC[9764ac] tcp_try_fastopen+0x2ec/0x360
    Kernel unaligned access at TPC[9764c8] tcp_try_fastopen+0x308/0x360
    Kernel unaligned access at TPC[9764e4] tcp_try_fastopen+0x324/0x360
    Kernel unaligned access at TPC[976490] tcp_try_fastopen+0x2d0/0x360

    Cc: Eric Dumazet
    Signed-off-by: Shannon Nelson
    Acked-by: Eric Dumazet
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Shannon Nelson
     
  • [ Upstream commit 148d3d021cf9724fcf189ce4e525a094bbf5ce89 ]

    The __bcm_sysport_tx_reclaim() function is used to reclaim transmit
    resources in different places within the driver. Most of them should
    not affect the state of the transit flow control.

    Introduce bcm_sysport_tx_clean() which cleans the ring, but does not
    re-enable flow control towards the networking stack, and make
    bcm_sysport_tx_reclaim() do the actual transmit queue flow control.

    Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
    Signed-off-by: Florian Fainelli
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Florian Fainelli
     
  • [ Upstream commit 8a430ed50bb1b19ca14a46661f3b1b35f2fb5c39 ]

    rtm_table is an 8-bit field while table ids are allowed up to u32. Commit
    709772e6e065 ("net: Fix routing tables with id > 255 for legacy software")
    added the preference to set rtm_table in dumps to RT_TABLE_COMPAT if the
    table id is > 255. The table id returned on get route requests should do
    the same.

    Fixes: c36ba6603a11 ("net: Allow user to get table id from route lookup")
    Signed-off-by: David Ahern
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    David Ahern
     
  • [ Upstream commit ea7a80858f57d8878b1499ea0f1b8a635cc48de7 ]

    Handle failure in lwtunnel_fill_encap adding attributes to skb.

    Fixes: 571e722676fe ("ipv4: support for fib route lwtunnel encap attributes")
    Fixes: 19e42e451506 ("ipv6: support for fib route lwtunnel encap attributes")
    Signed-off-by: David Ahern
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    David Ahern
     
  • [ Upstream commit 28e46a0f2e03ab4ed0e23cace1ea89a68c8c115b ]

    The event_data starts from address 0x00-0x0C and not from 0x08-0x014. This
    leads to duplication with other fields in the Event Queue Element such as
    sub-type, cqn and owner.

    Fixes: eda6500a987a0 ("mlxsw: Add PCI bus implementation")
    Signed-off-by: Elad Raz
    Signed-off-by: Jiri Pirko
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Elad Raz
     
  • [ Upstream commit 400fc0106dd8c27ed84781c929c1a184785b9c79 ]

    During transmission the skb is checked for headroom in order to
    add vendor specific header. In case the skb needs to be re-allocated,
    skb_realloc_headroom() is called to make a private copy of the original,
    but doesn't release it. Current code assumes that the original skb is
    released during reallocation and only releases it at the error path
    which causes a memory leak.

    Fix this by adding the original skb release to the main path.

    Fixes: d003462a50de ("mlxsw: Simplify mlxsw_sx_port_xmit function")
    Signed-off-by: Arkadi Sharshevsky
    Signed-off-by: Jiri Pirko
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Arkadi Sharshevsky
     
  • [ Upstream commit 36bf38d158d3482119b3e159c0619b3c1539b508 ]

    During transmission the skb is checked for headroom in order to
    add vendor specific header. In case the skb needs to be re-allocated,
    skb_realloc_headroom() is called to make a private copy of the original,
    but doesn't release it. Current code assumes that the original skb is
    released during reallocation and only releases it at the error path
    which causes a memory leak.

    Fix this by adding the original skb release to the main path.

    Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC")
    Signed-off-by: Arkadi Sharshevsky
    Reviewed-by: Ido Schimmel
    Signed-off-by: Jiri Pirko
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Arkadi Sharshevsky
     
  • [ Upstream commit 0719e72ccb801829a3d735d187ca8417f0930459 ]

    The receive callback (in tasklet context) is using RCU to get reference
    to associated VF network device but this is not safe. RCU read lock
    needs to be held. Found by running with full lockdep debugging
    enabled.

    Fixes: f207c10d9823 ("hv_netvsc: use RCU to protect vf_netdev")
    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    stephen hemminger
     
  • [ Upstream commit 19c0f40d4fca3a47b8f784a627f0467f0138ccc8 ]

    Fix the hw rx checksum is always enabled, and the user couldn't switch
    it to sw rx checksum.

    Note that the RTL_VER_01 only support sw rx checksum only. Besides,
    the hw rx checksum for RTL_VER_02 is disabled after
    commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.

    Signed-off-by: Hayes Wang
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    hayeswang
     

01 Feb, 2017

12 commits

  • Greg Kroah-Hartman
     
  • commit 4fc020d864647ea3ae8cb8f17d63e48e87ebd0bf upstream.

    The WaDisableLSQCROPERFforOCL workaround has the side effect of
    disabling an L3SQ optimization that has huge performance implications
    and is unlikely to be necessary for the correct functioning of usual
    graphic workloads. Userspace is free to re-enable the workaround on
    demand, and is generally in a better position to determine whether the
    workaround is necessary than the DRM is (e.g. only during the
    execution of compute kernels that rely on both L3 fences and HDC R/W
    requests).

    The same workaround seems to apply to BDW (at least to production
    stepping G1) and SKL as well (the internal workaround database claims
    that it does for all steppings, while the BSpec workaround table only
    mentions pre-production steppings), but the DRM doesn't do anything
    beyond whitelisting the L3SQCREG4 register so userspace can enable it
    when it sees fit. Do the same on KBL platforms.

    Improves performance of the GFXBench4 gl_manhattan31 benchmark by 60%,
    and gl_4 (AKA car chase) by 14% on a KBL GT2 running Mesa master --
    This is followed by a regression of 35% and 10% respectively for the
    same benchmarks and platform caused by my recent patch series
    switching userspace to use the dataport constant cache instead of the
    sampler to implement uniform pull constant loads, which caused us to
    hit more heavily the L3 cache (and on platforms other than KBL had the
    opposite effect of improving performance of the same two benchmarks).
    The overall effect on KBL of this change combined with the recent
    userspace change is respectively 4.6% and 2.6%. SynMark2 OglShMapPcf
    was affected by the constant cache changes (though it improved as it
    did on other platforms rather than regressing), but is not
    significantly affected by this patch (with statistical significance of
    5% and sample size 20).

    v2: Drop some more code to avoid unused variable warning.

    Fixes: 738fa1b3123f ("drm/i915/kbl: Add WaDisableLSQCROPERFforOCL")
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99256
    Signed-off-by: Francisco Jerez
    Cc: Matthew Auld
    Cc: Eero Tamminen
    Cc: Jani Nikula
    Cc: Mika Kuoppala
    Cc: beignet@lists.freedesktop.org
    Reviewed-by: Mika Kuoppala
    [Removed double Fixes tag]
    Signed-off-by: Mika Kuoppala
    Link: http://patchwork.freedesktop.org/patch/msgid/1484217894-20505-1-git-send-email-mika.kuoppala@intel.com
    (cherry picked from commit 8726f2faa371514fba2f594d799db95203dfeee0)
    Signed-off-by: Jani Nikula
    [ Francisco Jerez: Rebase on v4.9 branch. ]
    Signed-off-by: Francisco Jerez
    Signed-off-by: Greg Kroah-Hartman

    Francisco Jerez
     
  • commit 321027c1fe77f892f4ea07846aeae08cefbbb290 upstream.

    Di Shen reported a race between two concurrent sys_perf_event_open()
    calls where both try and move the same pre-existing software group
    into a hardware context.

    The problem is exactly that described in commit:

    f63a8daa5812 ("perf: Fix event->ctx locking")

    ... where, while we wait for a ctx->mutex acquisition, the event->ctx
    relation can have changed under us.

    That very same commit failed to recognise sys_perf_event_context() as an
    external access vector to the events and thereby didn't apply the
    established locking rules correctly.

    So while one sys_perf_event_open() call is stuck waiting on
    mutex_lock_double(), the other (which owns said locks) moves the group
    about. So by the time the former sys_perf_event_open() acquires the
    locks, the context we've acquired is stale (and possibly dead).

    Apply the established locking rules as per perf_event_ctx_lock_nested()
    to the mutex_lock_double() for the 'move_group' case. This obviously means
    we need to validate state after we acquire the locks.

    Reported-by: Di Shen (Keen Lab)
    Tested-by: John Dias
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Alexander Shishkin
    Cc: Arnaldo Carvalho de Melo
    Cc: Arnaldo Carvalho de Melo
    Cc: Jiri Olsa
    Cc: Kees Cook
    Cc: Linus Torvalds
    Cc: Min Chong
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: Thomas Gleixner
    Cc: Vince Weaver
    Fixes: f63a8daa5812 ("perf: Fix event->ctx locking")
    Link: http://lkml.kernel.org/r/20170106131444.GZ3174@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Peter Zijlstra
     
  • commit 3674534b775354516e5c148ea48f51d4d1909a78 upstream.

    When memory.move_charge_at_immigrate is enabled and precharges are
    depleted during move, mem_cgroup_move_charge_pte_range() will attempt to
    increase the size of the precharge.

    Prevent precharges from ever looping by setting __GFP_NORETRY. This was
    probably the intention of the GFP_KERNEL & ~__GFP_NORETRY, which is
    pointless as written.

    Fixes: 0029e19ebf84 ("mm: memcontrol: remove explicit OOM parameter in charge path")
    Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1701130208510.69402@chino.kir.corp.google.com
    Signed-off-by: David Rientjes
    Acked-by: Michal Hocko
    Cc: Johannes Weiner
    Cc: Vladimir Davydov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    David Rientjes
     
  • commit 5a00b6c2438460b870a451f14593fc40d3c7edf6 upstream.

    The commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
    starts refusing misconfigured interrupt handlers. This makes
    intel_mid_powerbtn not working anymore.

    Add a mandatory flag to a threaded IRQ request in the driver.

    Fixes: 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
    Signed-off-by: Andy Shevchenko
    Signed-off-by: Greg Kroah-Hartman

    Andy Shevchenko
     
  • commit 63d762b88cb5510f2bfdb5112ced18cde867ae61 upstream.

    There is an off-by-one error so we don't unregister priv->pdev_mux[0].
    Also it's slightly simpler as a while loop instead of a for loop.

    Fixes: 58cbbee2391c ("x86/platform/mellanox: Introduce support for Mellanox systems platform")
    Signed-off-by: Dan Carpenter
    Acked-by: Vadim Pasternak
    Signed-off-by: Andy Shevchenko
    Signed-off-by: Greg Kroah-Hartman

    Dan Carpenter
     
  • commit f7f6634d23830ff74335734fbdb28ea109c1f349 upstream.

    Once DMA API usage is enabled, it becomes apparent that virtio-mmio is
    inadvertently relying on the default 32-bit DMA mask, which leads to
    problems like rapidly exhausting SWIOTLB bounce buffers.

    Ensure that we set the appropriate 64-bit DMA mask whenever possible,
    with the coherent mask suitably limited for the legacy vring as per
    a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for legacy virtio
    devices").

    Cc: Andy Lutomirski
    Cc: Michael S. Tsirkin
    Reported-by: Jean-Philippe Brucker
    Fixes: b42111382f0e ("virtio_mmio: Use the DMA API if enabled")
    Signed-off-by: Robin Murphy
    Signed-off-by: Michael S. Tsirkin
    Signed-off-by: Greg Kroah-Hartman

    Robin Murphy
     
  • commit 8a1f780e7f28c7c1d640118242cf68d528c456cd upstream.

    online_{kernel|movable} is used to change the memory zone to
    ZONE_{NORMAL|MOVABLE} and online the memory.

    To check that memory zone can be changed, zone_can_shift() is used.
    Currently the function returns minus integer value, plus integer
    value and 0. When the function returns minus or plus integer value,
    it means that the memory zone can be changed to ZONE_{NORNAL|MOVABLE}.

    But when the function returns 0, there are two meanings.

    One of the meanings is that the memory zone does not need to be changed.
    For example, when memory is in ZONE_NORMAL and onlined by online_kernel
    the memory zone does not need to be changed.

    Another meaning is that the memory zone cannot be changed. When memory
    is in ZONE_NORMAL and onlined by online_movable, the memory zone may
    not be changed to ZONE_MOVALBE due to memory online limitation(see
    Documentation/memory-hotplug.txt). In this case, memory must not be
    onlined.

    The patch changes the return type of zone_can_shift() so that memory
    online operation fails when memory zone cannot be changed as follows:

    Before applying patch:
    # grep -A 35 "Node 2" /proc/zoneinfo
    Node 2, zone Normal

    node_scanned 0
    spanned 8388608
    present 7864320
    managed 7864320
    # echo online_movable > memory4097/state
    # grep -A 35 "Node 2" /proc/zoneinfo
    Node 2, zone Normal

    node_scanned 0
    spanned 8388608
    present 8388608
    managed 8388608

    online_movable operation succeeded. But memory is onlined as
    ZONE_NORMAL, not ZONE_MOVABLE.

    After applying patch:
    # grep -A 35 "Node 2" /proc/zoneinfo
    Node 2, zone Normal

    node_scanned 0
    spanned 8388608
    present 7864320
    managed 7864320
    # echo online_movable > memory4097/state
    bash: echo: write error: Invalid argument
    # grep -A 35 "Node 2" /proc/zoneinfo
    Node 2, zone Normal

    node_scanned 0
    spanned 8388608
    present 7864320
    managed 7864320

    online_movable operation failed because of failure of changing
    the memory zone from ZONE_NORMAL to ZONE_MOVABLE

    Fixes: df429ac03936 ("memory-hotplug: more general validation of zone during online")
    Link: http://lkml.kernel.org/r/2f9c3837-33d7-b6e5-59c0-6ca4372b2d84@gmail.com
    Signed-off-by: Yasuaki Ishimatsu
    Reviewed-by: Reza Arbab
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Yasuaki Ishimatsu
     
  • commit 04ff5a095d662e0879f0eb04b9247e092210aeff upstream.

    The commit 658b476c742f ("pinctrl: baytrail: Add debounce configuration")
    implements debounce for Baytrail pin control, but seems wasn't tested properly.

    The register which keeps debounce value is separated from the configuration
    one. Writing wrong values to the latter will guarantee wrong behaviour of the
    driver and even might break something physically.

    Besides above there is missed case how to disable it, which is actually done
    through the bit in configuration register.

    Rectify implementation here by using proper register for debounce value.

    Fixes: 658b476c742f ("pinctrl: baytrail: Add debounce configuration")
    Cc: Cristina Ciocan
    Signed-off-by: Andy Shevchenko
    Acked-by: Mika Westerberg
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Andy Shevchenko
     
  • commit df1539c25cce98e2ac69881958850c6535240707 upstream.

    Fix the pin-mux values for the MDC, MDIO, MDIO_INTL, PHYRSTL pins.

    Fixes: 1e359ab1285e ("pinctrl: uniphier: add Ethernet pin-mux settings")
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Masahiro Yamada
     
  • commit ecc8995363ee6231b32dad61c955b371b79cc4cf upstream.

    PADCFGLOCK (and PADCFGLOCK_TX) offset in Broxton actually starts at 0x060
    and not 0x090 as used in the driver. Fix it to use the correct offset.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Mika Westerberg
     
  • commit c739c0a7c3c2472d7562b8f802cdce44d2597c8b upstream.

    A rare randconfig build failure shows up in this driver when
    the CRC32 helper is not there:

    drivers/media/built-in.o: In function `s5k4ecgx_s_power':
    s5k4ecgx.c:(.text+0x9eb4): undefined reference to `crc32_le'

    This adds the 'select' that all other users of this function have.

    Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann