1. 27 Nov, 2014 40 commits
    • Stephan Mueller's avatar
      quirk for Lenovo Yoga 3: no rfkill switch · 87cca01a
      Stephan Mueller authored
      commit 725c7f61 upstream.
      
      The Yoga 3 does not contain any physical rfkill switch. Therefore
      disable the rfkill switch identically to the Yoga 2 approach.
      Signed-off-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      87cca01a
    • Nadav Amit's avatar
      KVM: x86: Don't report guest userspace emulation error to userspace · 7dd767ff
      Nadav Amit authored
      commit a2b9e6c1 upstream.
      
      Commit fc3a9157 ("KVM: X86: Don't report L2 emulation failures to
      user-space") disabled the reporting of L2 (nested guest) emulation failures to
      userspace due to race-condition between a vmexit and the instruction emulator.
      The same rational applies also to userspace applications that are permitted by
      the guest OS to access MMIO area or perform PIO.
      
      This patch extends the current behavior - of injecting a #UD instead of
      reporting it to userspace - also for guest userspace code.
      Signed-off-by: default avatarNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7dd767ff
    • Alex Deucher's avatar
      drm/radeon: initialize sadb to NULL in the audio code · 2b73646c
      Alex Deucher authored
      commit 83d04c39 upstream.
      
      Fixes kfree of the sadb buffer when it's NULL.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2b73646c
    • Andreas Larsson's avatar
      sparc32: Implement xchg and atomic_xchg using ATOMIC_HASH locks · 4f7e7dca
      Andreas Larsson authored
      commit 1a17fdc4 upstream.
      
      Atomicity between xchg and cmpxchg cannot be guaranteed when xchg is
      implemented with a swap and cmpxchg is implemented with locks.
      Without this, e.g. mcs_spin_lock and mcs_spin_unlock are broken.
      Signed-off-by: default avatarAndreas Larsson <andreas@gaisler.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4f7e7dca
    • David S. Miller's avatar
      sparc64: Do irq_{enter,exit}() around generic_smp_call_function*(). · 816dcf66
      David S. Miller authored
      commit ab5c7809 upstream.
      
      Otherwise rcu_irq_{enter,exit}() do not happen and we get dumps like:
      
      ====================
      [  188.275021] ===============================
      [  188.309351] [ INFO: suspicious RCU usage. ]
      [  188.343737] 3.18.0-rc3-00068-g20f3963d-dirty #54 Not tainted
      [  188.394786] -------------------------------
      [  188.429170] include/linux/rcupdate.h:883 rcu_read_lock() used
      illegally while idle!
      [  188.505235]
      other info that might help us debug this:
      
      [  188.554230]
      RCU used illegally from idle CPU!
      rcu_scheduler_active = 1, debug_locks = 0
      [  188.637587] RCU used illegally from extended quiescent state!
      [  188.690684] 3 locks held by swapper/7/0:
      [  188.721932]  #0:  (&x->wait#11){......}, at: [<0000000000495de8>] complete+0x8/0x60
      [  188.797994]  #1:  (&p->pi_lock){-.-.-.}, at: [<000000000048510c>] try_to_wake_up+0xc/0x400
      [  188.881343]  #2:  (rcu_read_lock){......}, at: [<000000000048a910>] select_task_rq_fair+0x90/0xb40
      [  188.973043]stack backtrace:
      [  188.993879] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.18.0-rc3-00068-g20f3963d-dirty #54
      [  189.076187] Call Trace:
      [  189.089719]  [0000000000499360] lockdep_rcu_suspicious+0xe0/0x100
      [  189.147035]  [000000000048a99c] select_task_rq_fair+0x11c/0xb40
      [  189.202253]  [00000000004852d8] try_to_wake_up+0x1d8/0x400
      [  189.252258]  [000000000048554c] default_wake_function+0xc/0x20
      [  189.306435]  [0000000000495554] __wake_up_common+0x34/0x80
      [  189.356448]  [00000000004955b4] __wake_up_locked+0x14/0x40
      [  189.406456]  [0000000000495e08] complete+0x28/0x60
      [  189.448142]  [0000000000636e28] blk_end_sync_rq+0x8/0x20
      [  189.496057]  [0000000000639898] __blk_mq_end_request+0x18/0x60
      [  189.550249]  [00000000006ee014] scsi_end_request+0x94/0x180
      [  189.601286]  [00000000006ee334] scsi_io_completion+0x1d4/0x600
      [  189.655463]  [00000000006e51c4] scsi_finish_command+0xc4/0xe0
      [  189.708598]  [00000000006ed958] scsi_softirq_done+0x118/0x140
      [  189.761735]  [00000000006398ec] __blk_mq_complete_request_remote+0xc/0x20
      [  189.827383]  [00000000004c75d0] generic_smp_call_function_single_interrupt+0x150/0x1c0
      [  189.906581]  [000000000043e514] smp_call_function_single_client+0x14/0x40
      ====================
      
      Based almost entirely upon a patch by Paul E. McKenney.
      Reported-by: default avatarMeelis Roos <mroos@linux.ee>
      Tested-by: default avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      816dcf66
    • David S. Miller's avatar
      sparc64: Fix crashes in schizo_pcierr_intr_other(). · c0dabb8f
      David S. Miller authored
      commit 7da89a2a upstream.
      
      Meelis Roos reports crashes during bootup on a V480 that look like
      this:
      
      ====================
      [   61.300577] PCI: Scanning PBM /pci@9,600000
      [   61.304867] schizo f009b070: PCI host bridge to bus 0003:00
      [   61.310385] pci_bus 0003:00: root bus resource [io  0x7ffe9000000-0x7ffe9ffffff] (bus address [0x0000-0xffffff])
      [   61.320515] pci_bus 0003:00: root bus resource [mem 0x7fb00000000-0x7fbffffffff] (bus address [0x00000000-0xffffffff])
      [   61.331173] pci_bus 0003:00: root bus resource [bus 00]
      [   61.385344] Unable to handle kernel NULL pointer dereference
      [   61.390970] tsk->{mm,active_mm}->context = 0000000000000000
      [   61.396515] tsk->{mm,active_mm}->pgd = fff000b000002000
      [   61.401716]               \|/ ____ \|/
      [   61.401716]               "@'/ .. \`@"
      [   61.401716]               /_| \__/ |_\
      [   61.401716]                  \__U_/
      [   61.416362] swapper/0(0): Oops [#1]
      [   61.419837] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-rc1-00422-g2cc91884-dirty #24
      [   61.427975] task: fff000b0fd8e9c40 ti: fff000b0fd928000 task.ti: fff000b0fd928000
      [   61.435426] TSTATE: 0000004480e01602 TPC: 00000000004455e4 TNPC: 00000000004455e8 Y: 00000000    Not tainted
      [   61.445230] TPC: <schizo_pcierr_intr+0x104/0x560>
      [   61.449897] g0: 0000000000000000 g1: 0000000000000000 g2: 0000000000a10f78 g3: 000000000000000a
      [   61.458563] g4: fff000b0fd8e9c40 g5: fff000b0fdd82000 g6: fff000b0fd928000 g7: 000000000000000a
      [   61.467229] o0: 000000000000003d o1: 0000000000000000 o2: 0000000000000006 o3: fff000b0ffa5fc7e
      [   61.475894] o4: 0000000000060000 o5: c000000000000000 sp: fff000b0ffa5f3c1 ret_pc: 00000000004455cc
      [   61.484909] RPC: <schizo_pcierr_intr+0xec/0x560>
      [   61.489500] l0: fff000b0fd8e9c40 l1: 0000000000a20800 l2: 0000000000000000 l3: 000000000119a430
      [   61.498164] l4: 0000000001742400 l5: 00000000011cfbe0 l6: 00000000011319c0 l7: fff000b0fd8ea348
      [   61.506830] i0: 0000000000000000 i1: fff000b0fdb34000 i2: 0000000320000000 i3: 0000000000000000
      [   61.515497] i4: 00060002010b003f i5: 0000040004e02000 i6: fff000b0ffa5f481 i7: 00000000004a9920
      [   61.524175] I7: <handle_irq_event_percpu+0x40/0x140>
      [   61.529099] Call Trace:
      [   61.531531]  [00000000004a9920] handle_irq_event_percpu+0x40/0x140
      [   61.537681]  [00000000004a9a58] handle_irq_event+0x38/0x80
      [   61.543145]  [00000000004ac77c] handle_fasteoi_irq+0xbc/0x200
      [   61.548860]  [00000000004a9084] generic_handle_irq+0x24/0x40
      [   61.554500]  [000000000042be0c] handler_irq+0xac/0x100
      ====================
      
      The problem is that pbm->pci_bus->self is NULL.
      
      This code is trying to go through the standard PCI config space
      interfaces to read the PCI controller's PCI_STATUS register.
      
      This doesn't work, because we more often than not do not enumerate
      the PCI controller as a bonafide PCI device during the OF device
      node scan.  Therefore bus->self remains NULL.
      
      Existing common code for PSYCHO and PSYCHO-like PCI controllers
      handles this properly, by doing the config space access directly.
      
      Do the same here, pbm->pci_ops->{read,write}().
      Reported-by: default avatarMeelis Roos <mroos@linux.ee>
      Tested-by: default avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c0dabb8f
    • Dwight Engen's avatar
      sunvdc: don't call VD_OP_GET_VTOC · a4f4bd0c
      Dwight Engen authored
      commit 85b0c6e6 upstream.
      
      The VD_OP_GET_VTOC operation will succeed only if the vdisk backend has a
      VTOC label, otherwise it will fail. In particular, it will return error
      48 (ENOTSUP) if the disk has an EFI label. VTOC disk labels are already
      handled by directly reading the disk in block/partitions/sun.c (enabled by
      CONFIG_SUN_PARTITION which defaults to y on SPARC). Since port->label is
      unused in the driver, remove the call and the field.
      Signed-off-by: default avatarDwight Engen <dwight.engen@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a4f4bd0c
    • Dwight Engen's avatar
      vio: fix reuse of vio_dring slot · 03f0d176
      Dwight Engen authored
      commit d0aedcd4 upstream.
      
      vio_dring_avail() will allow use of every dring entry, but when the last
      entry is allocated then dr->prod == dr->cons which is indistinguishable from
      the ring empty condition. This causes the next allocation to reuse an entry.
      When this happens in sunvdc, the server side vds driver begins nack'ing the
      messages and ends up resetting the ldc channel. This problem does not effect
      sunvnet since it checks for < 2.
      
      The fix here is to just never allocate the very last dring slot so that full
      and empty are not the same condition. The request start path was changed to
      check for the ring being full a bit earlier, and to stop the blk_queue if
      there is no space left. The blk_queue will be restarted once the ring is
      only half full again. The number of ring entries was increased to 512 which
      matches the sunvnet and Solaris vdc drivers, and greatly reduces the
      frequency of hitting the ring full condition and the associated blk_queue
      stop/starting. The checks in sunvent were adjusted to account for
      vio_dring_avail() returning 1 less.
      
      Orabug: 19441666
      OraBZ: 14983
      Signed-off-by: default avatarDwight Engen <dwight.engen@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      03f0d176
    • Dwight Engen's avatar
      sunvdc: limit each sg segment to a page · 486db7c9
      Dwight Engen authored
      commit 5eed69ff upstream.
      
      ldc_map_sg() could fail its check that the number of pages referred to
      by the sg scatterlist was <= the number of cookies.
      
      This fixes the issue by doing a similar thing to the xen-blkfront driver,
      ensuring that the scatterlist will only ever contain a segment count <=
      port->ring_cookies, and each segment will be page aligned, and <= page
      size. This ensures that the scatterlist is always mappable.
      
      Orabug: 19347817
      OraBZ: 15945
      Signed-off-by: default avatarDwight Engen <dwight.engen@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      486db7c9
    • Allen Pais's avatar
      sunvdc: compute vdisk geometry from capacity · b2210eb6
      Allen Pais authored
      commit de5b73f0 upstream.
      
      The LDom diskserver doesn't return reliable geometry data. In addition,
      the types for all fields in the vio_disk_geom are u16, which were being
      truncated in the cast into the u8's of the Linux struct hd_geometry.
      
      Modify vdc_getgeo() to compute the geometry from the disk's capacity in a
      manner consistent with xen-blkfront::blkif_getgeo().
      Signed-off-by: default avatarDwight Engen <dwight.engen@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b2210eb6
    • Allen Pais's avatar
      sunvdc: add cdrom and v1.1 protocol support · 39a83081
      Allen Pais authored
      commit 9bce2182 upstream.
      
      Interpret the media type from v1.1 protocol to support CDROM/DVD.
      
      For v1.0 protocol, a disk's size continues to be calculated from the
      geometry returned by the vdisk server. The geometry returned by the server
      can be less than the actual number of sectors available in the backing
      image/device due to the rounding in the division used to compute the
      geometry in the vdisk server.
      
      In v1.1 protocol a disk's actual size in sectors is returned during the
      handshake. Use this size when v1.1 protocol is negotiated. Since this size
      will always be larger than the former geometry computed size, disks created
      under v1.0 will be forwards compatible to v1.1, but not vice versa.
      Signed-off-by: default avatarDwight Engen <dwight.engen@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      39a83081
    • Enric Balletbo i Serra's avatar
      smsc911x: power-up phydev before doing a software reset. · 9bc045c6
      Enric Balletbo i Serra authored
      commit ccf899a2 upstream.
      
      With commit be9dad1f ("net: phy: suspend phydev when going
      to HALTED"), the PHY device will be put in a low-power mode using
      BMCR_PDOWN if the the interface is set down. The smsc911x driver does
      a software_reset opening the device driver (ndo_open). In such case,
      the PHY must be powered-up before access to any register and before
      calling the software_reset function. Otherwise, as the PHY is powered
      down the software reset fails and the interface can not be enabled
      again.
      
      This patch fixes this scenario that is easy to reproduce setting down
      the network interface and setting up again.
      
          $ ifconfig eth0 down
          $ ifconfig eth0 up
          ifconfig: SIOCSIFFLAGS: Input/output error
      Signed-off-by: default avatarEnric Balletbo i Serra <eballetbo@iseebcn.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9bc045c6
    • Hiroaki SHIMODA's avatar
      netlink: Properly unbind in error conditions. · 1b1a5bb6
      Hiroaki SHIMODA authored
      commit 6251edd9 upstream.
      
      Even if netlink_kernel_cfg::unbind is implemented the unbind() method is
      not called, because cfg->unbind is omitted in __netlink_kernel_create().
      And fix wrong argument of test_bit() and off by one problem.
      
      At this point, no unbind() method is implemented, so there is no real
      issue.
      
      Fixes: 4f520900 ("netlink: have netlink per-protocol bind function return an error code.")
      Signed-off-by: default avatarHiroaki SHIMODA <shimoda.hiroaki@gmail.com>
      Cc: Richard Guy Briggs <rgb@redhat.com>
      Acked-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1b1a5bb6
    • Eric Dumazet's avatar
      ipv6: fix IPV6_PKTINFO with v4 mapped · b828096e
      Eric Dumazet authored
      commit 5337b5b7 upstream.
      
      Use IS_ENABLED(CONFIG_IPV6), to enable this code if IPv6 is
      a module.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Fixes: c8e6ad08 ("ipv6: honor IPV6_PKTINFO with v4 mapped addresses on sendmsg")
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b828096e
    • Daniel Borkmann's avatar
      net: sctp: fix memory leak in auth key management · 6bd693b5
      Daniel Borkmann authored
      commit 4184b2a7 upstream.
      
      A very minimal and simple user space application allocating an SCTP
      socket, setting SCTP_AUTH_KEY setsockopt(2) on it and then closing
      the socket again will leak the memory containing the authentication
      key from user space:
      
      unreferenced object 0xffff8800837047c0 (size 16):
        comm "a.out", pid 2789, jiffies 4296954322 (age 192.258s)
        hex dump (first 16 bytes):
          01 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff816d7e8e>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811c88d8>] __kmalloc+0xe8/0x270
          [<ffffffffa0870c23>] sctp_auth_create_key+0x23/0x50 [sctp]
          [<ffffffffa08718b1>] sctp_auth_set_key+0xa1/0x140 [sctp]
          [<ffffffffa086b383>] sctp_setsockopt+0xd03/0x1180 [sctp]
          [<ffffffff815bfd94>] sock_common_setsockopt+0x14/0x20
          [<ffffffff815beb61>] SyS_setsockopt+0x71/0xd0
          [<ffffffff816e58a9>] system_call_fastpath+0x12/0x17
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      This is bad because of two things, we can bring down a machine from
      user space when auth_enable=1, but also we would leave security sensitive
      keying material in memory without clearing it after use. The issue is
      that sctp_auth_create_key() already sets the refcount to 1, but after
      allocation sctp_auth_set_key() does an additional refcount on it, and
      thus leaving it around when we free the socket.
      
      Fixes: 65b07e5d ("[SCTP]: API updates to suport SCTP-AUTH extensions.")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6bd693b5
    • Daniel Borkmann's avatar
      net: sctp: fix NULL pointer dereference in af->from_addr_param on malformed packet · 1cfecc6b
      Daniel Borkmann authored
      commit e40607cb upstream.
      
      An SCTP server doing ASCONF will panic on malformed INIT ping-of-death
      in the form of:
      
        ------------ INIT[PARAM: SET_PRIMARY_IP] ------------>
      
      While the INIT chunk parameter verification dissects through many things
      in order to detect malformed input, it misses to actually check parameters
      inside of parameters. E.g. RFC5061, section 4.2.4 proposes a 'set primary
      IP address' parameter in ASCONF, which has as a subparameter an address
      parameter.
      
      So an attacker may send a parameter type other than SCTP_PARAM_IPV4_ADDRESS
      or SCTP_PARAM_IPV6_ADDRESS, param_type2af() will subsequently return 0
      and thus sctp_get_af_specific() returns NULL, too, which we then happily
      dereference unconditionally through af->from_addr_param().
      
      The trace for the log:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000078
      IP: [<ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp]
      PGD 0
      Oops: 0000 [#1] SMP
      [...]
      Pid: 0, comm: swapper Not tainted 2.6.32-504.el6.x86_64 #1 Bochs Bochs
      RIP: 0010:[<ffffffffa01e9c62>]  [<ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp]
      [...]
      Call Trace:
       <IRQ>
       [<ffffffffa01f2add>] ? sctp_bind_addr_copy+0x5d/0xe0 [sctp]
       [<ffffffffa01e1fcb>] sctp_sf_do_5_1B_init+0x21b/0x340 [sctp]
       [<ffffffffa01e3751>] sctp_do_sm+0x71/0x1210 [sctp]
       [<ffffffffa01e5c09>] ? sctp_endpoint_lookup_assoc+0xc9/0xf0 [sctp]
       [<ffffffffa01e61f6>] sctp_endpoint_bh_rcv+0x116/0x230 [sctp]
       [<ffffffffa01ee986>] sctp_inq_push+0x56/0x80 [sctp]
       [<ffffffffa01fcc42>] sctp_rcv+0x982/0xa10 [sctp]
       [<ffffffffa01d5123>] ? ipt_local_in_hook+0x23/0x28 [iptable_filter]
       [<ffffffff8148bdc9>] ? nf_iterate+0x69/0xb0
       [<ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0
       [<ffffffff8148bf86>] ? nf_hook_slow+0x76/0x120
       [<ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0
      [...]
      
      A minimal way to address this is to check for NULL as we do on all
      other such occasions where we know sctp_get_af_specific() could
      possibly return with NULL.
      
      Fixes: d6de3097 ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1cfecc6b
    • Marcelo Leitner's avatar
      vxlan: Do not reuse sockets for a different address family · 6437cf7e
      Marcelo Leitner authored
      commit 19ca9fc1 upstream.
      
      Currently, we only match against local port number in order to reuse
      socket. But if this new vxlan wants an IPv6 socket and a IPv4 one bound
      to that port, vxlan will reuse an IPv4 socket as IPv6 and a panic will
      follow. The following steps reproduce it:
      
         # ip link add vxlan6 type vxlan id 42 group 229.10.10.10 \
             srcport 5000 6000 dev eth0
         # ip link add vxlan7 type vxlan id 43 group ff0e::110 \
             srcport 5000 6000 dev eth0
         # ip link set vxlan6 up
         # ip link set vxlan7 up
         <panic>
      
      [    4.187481] BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
      ...
      [    4.188076] Call Trace:
      [    4.188085]  [<ffffffff81667c4a>] ? ipv6_sock_mc_join+0x3a/0x630
      [    4.188098]  [<ffffffffa05a6ad6>] vxlan_igmp_join+0x66/0xd0 [vxlan]
      [    4.188113]  [<ffffffff810a3430>] process_one_work+0x220/0x710
      [    4.188125]  [<ffffffff810a33c4>] ? process_one_work+0x1b4/0x710
      [    4.188138]  [<ffffffff810a3a3b>] worker_thread+0x11b/0x3a0
      [    4.188149]  [<ffffffff810a3920>] ? process_one_work+0x710/0x710
      
      So address family must also match in order to reuse a socket.
      Reported-by: default avatarJean-Tsung Hsiao <jhsiao@redhat.com>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <mleitner@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6437cf7e
    • Karl Beldan's avatar
      net: mv643xx_eth: reclaim TX skbs only when released by the HW · 0d795012
      Karl Beldan authored
      commit 2c2a9cbd upstream.
      
      ATM, txq_reclaim will dequeue and free an skb for each tx desc released
      by the hw that has TX_LAST_DESC set. However, in case of TSO, each
      hw desc embedding the last part of a segment has TX_LAST_DESC set,
      losing the one-to-one 'last skb frag'/'TX_LAST_DESC set' correspondance,
      which causes data corruption.
      
      Fix this by checking TX_ENABLE_INTERRUPT instead of TX_LAST_DESC, and
      warn when trying to dequeue from an empty txq (which can be symptomatic
      of releasing skbs prematurely).
      
      Fixes: 3ae8f4e0 ('net: mv643xx_eth: Implement software TSO')
      Reported-by: default avatarSlawomir Gajzner <slawomir.gajzner@gmail.com>
      Reported-by: default avatarJulien D'Ascenzio <jdascenzio@yahoo.fr>
      Signed-off-by: default avatarKarl Beldan <karl.beldan@rivierawaves.com>
      Cc: Ian Campbell <ijc@hellion.org.uk>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0d795012
    • Steffen Klassert's avatar
      gre6: Move the setting of dev->iflink into the ndo_init functions. · 9c5425d7
      Steffen Klassert authored
      commit f03eb128 upstream.
      
      Otherwise it gets overwritten by register_netdev().
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9c5425d7
    • Steffen Klassert's avatar
      sit: Use ipip6_tunnel_init as the ndo_init function. · 5e146414
      Steffen Klassert authored
      commit ebe084aa upstream.
      
      ipip6_tunnel_init() sets the dev->iflink via a call to
      ipip6_tunnel_bind_dev(). After that, register_netdevice()
      sets dev->iflink = -1. So we loose the iflink configuration
      for ipv6 tunnels. Fix this by using ipip6_tunnel_init() as the
      ndo_init function. Then ipip6_tunnel_init() is called after
      dev->iflink is set to -1 from register_netdevice().
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5e146414
    • Steffen Klassert's avatar
      vti6: Use vti6_dev_init as the ndo_init function. · 3510081a
      Steffen Klassert authored
      commit 16a0231b upstream.
      
      vti6_dev_init() sets the dev->iflink via a call to
      vti6_link_config(). After that, register_netdevice()
      sets dev->iflink = -1. So we loose the iflink configuration
      for vti6 tunnels. Fix this by using vti6_dev_init() as the
      ndo_init function. Then vti6_dev_init() is called after
      dev->iflink is set to -1 from register_netdevice().
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3510081a
    • Steffen Klassert's avatar
      ip6_tunnel: Use ip6_tnl_dev_init as the ndo_init function. · 6ca9a33e
      Steffen Klassert authored
      commit 6c6151da upstream.
      
      ip6_tnl_dev_init() sets the dev->iflink via a call to
      ip6_tnl_link_config(). After that, register_netdevice()
      sets dev->iflink = -1. So we loose the iflink configuration
      for ipv6 tunnels. Fix this by using ip6_tnl_dev_init() as the
      ndo_init function. Then ip6_tnl_dev_init() is called after
      dev->iflink is set to -1 from register_netdevice().
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6ca9a33e
    • NeilBrown's avatar
      md: Always set RECOVERY_NEEDED when clearing RECOVERY_FROZEN · 9ac298cb
      NeilBrown authored
      commit 45eaf45d upstream.
      
      md_check_recovery will skip any recovery and also clear
      MD_RECOVERY_NEEDED if MD_RECOVERY_FROZEN is set.
      So when we clear _FROZEN, we must set _NEEDED and ensure that
      md_check_recovery gets run.
      Otherwise we could miss out on something that is needed.
      
      In particular, this can make it impossible to remove a
      failed device from an array is the  'recovery-needed' processing
      didn't happen.
      Suitable for stable kernels since 3.13.
      Reported-and-tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Fixes: 30b8feb7Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9ac298cb
    • Stefan Richter's avatar
      firewire: cdev: prevent kernel stack leaking into ioctl arguments · cec4c7e4
      Stefan Richter authored
      commit eaca2d8e upstream.
      
      Found by the UC-KLEE tool:  A user could supply less input to
      firewire-cdev ioctls than write- or write/read-type ioctl handlers
      expect.  The handlers used data from uninitialized kernel stack then.
      
      This could partially leak back to the user if the kernel subsequently
      generated fw_cdev_event_'s (to be read from the firewire-cdev fd)
      which notably would contain the _u64 closure field which many of the
      ioctl argument structures contain.
      
      The fact that the handlers would act on random garbage input is a
      lesser issue since all handlers must check their input anyway.
      
      The fix simply always null-initializes the entire ioctl argument buffer
      regardless of the actual length of expected user input.  That is, a
      runtime overhead of memset(..., 40) is added to each firewirew-cdev
      ioctl() call.  [Comment from Clemens Ladisch:  This part of the stack is
      most likely to be already in the cache.]
      
      Remarks:
        - There was never any leak from kernel stack to the ioctl output
          buffer itself.  IOW, it was not possible to read kernel stack by a
          read-type or write/read-type ioctl alone; the leak could at most
          happen in combination with read()ing subsequent event data.
        - The actual expected minimum user input of each ioctl from
          include/uapi/linux/firewire-cdev.h is, in bytes:
          [0x00] = 32, [0x05] =  4, [0x0a] = 16, [0x0f] = 20, [0x14] = 16,
          [0x01] = 36, [0x06] = 20, [0x0b] =  4, [0x10] = 20, [0x15] = 20,
          [0x02] = 20, [0x07] =  4, [0x0c] =  0, [0x11] =  0, [0x16] =  8,
          [0x03] =  4, [0x08] = 24, [0x0d] = 20, [0x12] = 36, [0x17] = 12,
          [0x04] = 20, [0x09] = 24, [0x0e] =  4, [0x13] = 40, [0x18] =  4.
      Reported-by: default avatarDavid Ramos <daramos@stanford.edu>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cec4c7e4
    • Pali Rohár's avatar
      Input: alps - ignore bad data on Dell Latitudes E6440 and E7440 · 6755d937
      Pali Rohár authored
      commit a7ef82ae upstream.
      
      Sometimes on Dell Latitude laptops psmouse/alps driver receive invalid ALPS
      protocol V3 packets with bit7 set in last byte. More often it can be
      reproduced on Dell Latitude E6440 or E7440 with closed lid and pushing
      cover above touchpad.
      
      If bit7 in last packet byte is set then it is not valid ALPS packet. I was
      told that ALPS devices never send these packets. It is not know yet who
      send those packets, it could be Dell EC, bug in BIOS and also bug in
      touchpad firmware...
      
      With this patch alps driver does not process those invalid packets, but
      instead of reporting PSMOUSE_BAD_DATA, getting into out of sync state,
      getting back in sync with the next byte and spam dmesg we return
      PSMOUSE_FULL_PACKET. If driver is truly out of sync we'll fail the checks
      on the next byte and report PSMOUSE_BAD_DATA then.
      Signed-off-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Tested-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6755d937
    • Tang Chen's avatar
      mem-hotplug: reset node present pages when hot-adding a new pgdat · c8d462c8
      Tang Chen authored
      commit 0bd85420 upstream.
      
      When memory is hot-added, all the memory is in offline state.  So clear
      all zones' present_pages because they will be updated in online_pages()
      and offline_pages().  Otherwise, /proc/zoneinfo will corrupt:
      
      When the memory of node2 is offline:
      
        # cat /proc/zoneinfo
        ......
        Node 2, zone   Movable
        ......
              spanned  8388608
              present  8388608
              managed  0
      
      When we online memory on node2:
      
        # cat /proc/zoneinfo
        ......
        Node 2, zone   Movable
        ......
              spanned  8388608
              present  16777216
              managed  8388608
      Signed-off-by: default avatarTang Chen <tangchen@cn.fujitsu.com>
      Reviewed-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c8d462c8
    • Tang Chen's avatar
      mem-hotplug: reset node managed pages when hot-adding a new pgdat · 0cc5277d
      Tang Chen authored
      commit f784a3f1 upstream.
      
      In free_area_init_core(), zone->managed_pages is set to an approximate
      value for lowmem, and will be adjusted when the bootmem allocator frees
      pages into the buddy system.
      
      But free_area_init_core() is also called by hotadd_new_pgdat() when
      hot-adding memory.  As a result, zone->managed_pages of the newly added
      node's pgdat is set to an approximate value in the very beginning.
      
      Even if the memory on that node has node been onlined,
      /sys/device/system/node/nodeXXX/meminfo has wrong value:
      
        hot-add node2 (memory not onlined)
        cat /sys/device/system/node/node2/meminfo
        Node 2 MemTotal:       33554432 kB
        Node 2 MemFree:               0 kB
        Node 2 MemUsed:        33554432 kB
        Node 2 Active:                0 kB
      
      This patch fixes this problem by reset node managed pages to 0 after
      hot-adding a new node.
      
      1. Move reset_managed_pages_done from reset_node_managed_pages() to
         reset_all_zones_managed_pages()
      2. Make reset_node_managed_pages() non-static
      3. Call reset_node_managed_pages() in hotadd_new_pgdat() after pgdat
         is initialized
      Signed-off-by: default avatarTang Chen <tangchen@cn.fujitsu.com>
      Signed-off-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0cc5277d
    • Weijie Yang's avatar
      zram: avoid kunmap_atomic() of a NULL pointer · cbfecaff
      Weijie Yang authored
      commit c4065152 upstream.
      
      zram could kunmap_atomic() a NULL pointer in a rare situation: a zram
      page becomes a full-zeroed page after a partial write io.  The current
      code doesn't handle this case and performs kunmap_atomic() on a NULL
      pointer, which panics the kernel.
      
      This patch fixes this issue.
      Signed-off-by: default avatarWeijie Yang <weijie.yang@samsung.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Dan Streetman <ddstreet@ieee.org>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Cc: Weijie Yang <weijie.yang.kh@gmail.com>
      Acked-by: default avatarJerome Marchand <jmarchan@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cbfecaff
    • Nathan Lynch's avatar
      ARM: 8198/1: make kuser helpers depend on MMU · a7001a90
      Nathan Lynch authored
      commit 08b964ff upstream.
      
      The kuser helpers page is not set up on non-MMU systems, so it does
      not make sense to allow CONFIG_KUSER_HELPERS to be enabled when
      CONFIG_MMU=n.  Allowing it to be set on !MMU results in an oops in
      set_tls (used in execve and the arm_syscall trap handler):
      
      Unhandled exception: IPSR = 00000005 LR = fffffff1
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc1-00041-ga30465a #216
      task: 8b838000 ti: 8b82a000 task.ti: 8b82a000
      PC is at flush_thread+0x32/0x40
      LR is at flush_thread+0x21/0x40
      pc : [<8f00157a>]    lr : [<8f001569>]    psr: 4100000b
      sp : 8b82be20  ip : 00000000  fp : 8b83c000
      r10: 00000001  r9 : 88018c84  r8 : 8bb85000
      r7 : 8b838000  r6 : 00000000  r5 : 8bb77400  r4 : 8b82a000
      r3 : ffff0ff0  r2 : 8b82a000  r1 : 00000000  r0 : 88020354
      xPSR: 4100000b
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc1-00041-ga30465a #216
      [<8f002bc1>] (unwind_backtrace) from [<8f002033>] (show_stack+0xb/0xc)
      [<8f002033>] (show_stack) from [<8f00265b>] (__invalid_entry+0x4b/0x4c)
      
      As best I can tell this issue existed for the set_tls ARM syscall
      before commit fbfb872f "ARM: 8148/1: flush TLS and thumbee
      register state during exec" consolidated the TLS manipulation code
      into the set_tls helper function, but now that we're using it to flush
      register state during execve, !MMU users encounter the oops at the
      first exec.
      
      Prevent CONFIG_MMU=n configurations from enabling
      CONFIG_KUSER_HELPERS.
      
      Fixes: fbfb872f (ARM: 8148/1: flush TLS and thumbee register state during exec)
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Reported-by: default avatarStefan Agner <stefan@agner.ch>
      Acked-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a7001a90
    • Will Deacon's avatar
      ARM: 8191/1: decompressor: ensure I-side picks up relocated code · ab959ea5
      Will Deacon authored
      commit 238962ac upstream.
      
      To speed up decompression, the decompressor sets up a flat, cacheable
      mapping of memory. However, when there is insufficient space to hold
      the page tables for this mapping, we don't bother to enable the caches
      and subsequently skip all the cache maintenance hooks.
      
      Skipping the cache maintenance before jumping to the relocated code
      allows the processor to predict the branch and populate the I-cache
      with stale data before the relocation loop has completed (since a
      bootloader may have SCTLR.I set, which permits normal, cacheable
      instruction fetches regardless of SCTLR.M).
      
      This patch moves the cache maintenance check into the maintenance
      routines themselves, allowing the v6/v7 versions to invalidate the
      I-cache regardless of the MMU state.
      Reported-by: default avatarMarc Carino <marc.ceeeee@gmail.com>
      Tested-by: default avatarJulien Grall <julien.grall@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ab959ea5
    • Ilya Dryomov's avatar
      libceph: do not crash on large auth tickets · 6280bef9
      Ilya Dryomov authored
      commit aaef3170 upstream.
      
      Large (greater than 32k, the value of PAGE_ALLOC_COSTLY_ORDER) auth
      tickets will have their buffers vmalloc'ed, which leads to the
      following crash in crypto:
      
      [   28.685082] BUG: unable to handle kernel paging request at ffffeb04000032c0
      [   28.686032] IP: [<ffffffff81392b42>] scatterwalk_pagedone+0x22/0x80
      [   28.686032] PGD 0
      [   28.688088] Oops: 0000 [#1] PREEMPT SMP
      [   28.688088] Modules linked in:
      [   28.688088] CPU: 0 PID: 878 Comm: kworker/0:2 Not tainted 3.17.0-vm+ #305
      [   28.688088] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [   28.688088] Workqueue: ceph-msgr con_work
      [   28.688088] task: ffff88011a7f9030 ti: ffff8800d903c000 task.ti: ffff8800d903c000
      [   28.688088] RIP: 0010:[<ffffffff81392b42>]  [<ffffffff81392b42>] scatterwalk_pagedone+0x22/0x80
      [   28.688088] RSP: 0018:ffff8800d903f688  EFLAGS: 00010286
      [   28.688088] RAX: ffffeb04000032c0 RBX: ffff8800d903f718 RCX: ffffeb04000032c0
      [   28.688088] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8800d903f750
      [   28.688088] RBP: ffff8800d903f688 R08: 00000000000007de R09: ffff8800d903f880
      [   28.688088] R10: 18df467c72d6257b R11: 0000000000000000 R12: 0000000000000010
      [   28.688088] R13: ffff8800d903f750 R14: ffff8800d903f8a0 R15: 0000000000000000
      [   28.688088] FS:  00007f50a41c7700(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000
      [   28.688088] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [   28.688088] CR2: ffffeb04000032c0 CR3: 00000000da3f3000 CR4: 00000000000006b0
      [   28.688088] Stack:
      [   28.688088]  ffff8800d903f698 ffffffff81392ca8 ffff8800d903f6e8 ffffffff81395d32
      [   28.688088]  ffff8800dac96000 ffff880000000000 ffff8800d903f980 ffff880119b7e020
      [   28.688088]  ffff880119b7e010 0000000000000000 0000000000000010 0000000000000010
      [   28.688088] Call Trace:
      [   28.688088]  [<ffffffff81392ca8>] scatterwalk_done+0x38/0x40
      [   28.688088]  [<ffffffff81392ca8>] scatterwalk_done+0x38/0x40
      [   28.688088]  [<ffffffff81395d32>] blkcipher_walk_done+0x182/0x220
      [   28.688088]  [<ffffffff813990bf>] crypto_cbc_encrypt+0x15f/0x180
      [   28.688088]  [<ffffffff81399780>] ? crypto_aes_set_key+0x30/0x30
      [   28.688088]  [<ffffffff8156c40c>] ceph_aes_encrypt2+0x29c/0x2e0
      [   28.688088]  [<ffffffff8156d2a3>] ceph_encrypt2+0x93/0xb0
      [   28.688088]  [<ffffffff8156d7da>] ceph_x_encrypt+0x4a/0x60
      [   28.688088]  [<ffffffff8155b39d>] ? ceph_buffer_new+0x5d/0xf0
      [   28.688088]  [<ffffffff8156e837>] ceph_x_build_authorizer.isra.6+0x297/0x360
      [   28.688088]  [<ffffffff8112089b>] ? kmem_cache_alloc_trace+0x11b/0x1c0
      [   28.688088]  [<ffffffff8156b496>] ? ceph_auth_create_authorizer+0x36/0x80
      [   28.688088]  [<ffffffff8156ed83>] ceph_x_create_authorizer+0x63/0xd0
      [   28.688088]  [<ffffffff8156b4b4>] ceph_auth_create_authorizer+0x54/0x80
      [   28.688088]  [<ffffffff8155f7c0>] get_authorizer+0x80/0xd0
      [   28.688088]  [<ffffffff81555a8b>] prepare_write_connect+0x18b/0x2b0
      [   28.688088]  [<ffffffff81559289>] try_read+0x1e59/0x1f10
      
      This is because we set up crypto scatterlists as if all buffers were
      kmalloc'ed.  Fix it.
      Signed-off-by: default avatarIlya Dryomov <idryomov@redhat.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6280bef9
    • Paul Mackerras's avatar
      Fix thinko in iov_iter_single_seg_count · bdba73df
      Paul Mackerras authored
      commit ad0eab92 upstream.
      
      The branches of the if (i->type & ITER_BVEC) statement in
      iov_iter_single_seg_count() are the wrong way around; if ITER_BVEC is
      clear then we use i->bvec, when we should be using i->iov.  This fixes
      it.
      
      In my case, the symptom that this caused was that a KVM guest doing
      filesystem operations on a virtual disk would result in one of qemu's
      threads on the host going into an infinite loop in
      generic_perform_write().  The loop would hit the copied == 0 case and
      call iov_iter_single_seg_count() to reduce the number of bytes to try
      to process, but because of the error, iov_iter_single_seg_count()
      would just return i->count and the loop made no progress and continued
      forever.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bdba73df
    • William Cohen's avatar
      Correct the race condition in aarch64_insn_patch_text_sync() · 219e9b7b
      William Cohen authored
      commit 899d5933 upstream.
      
      When experimenting with patches to provide kprobes support for aarch64
      smp machines would hang when inserting breakpoints into kernel code.
      The hangs were caused by a race condition in the code called by
      aarch64_insn_patch_text_sync().  The first processor in the
      aarch64_insn_patch_text_cb() function would patch the code while other
      processors were still entering the function and incrementing the
      cpu_count field.  This resulted in some processors never observing the
      exit condition and exiting the function.  Thus, processors in the
      system hung.
      
      The first processor to enter the patching function performs the
      patching and signals that the patching is complete with an increment
      of the cpu_count field. When all the processors have incremented the
      cpu_count field the cpu_count will be num_cpus_online()+1 and they
      will return to normal execution.
      
      Fixes: ae164807 arm64: introduce interfaces to hotpatch kernel and module code
      Signed-off-by: default avatarWilliam Cohen <wcohen@redhat.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      219e9b7b
    • Kyle McMartin's avatar
      arm64: __clear_user: handle exceptions on strb · 73d908ca
      Kyle McMartin authored
      commit 97fc1543 upstream.
      
      ARM64 currently doesn't fix up faults on the single-byte (strb) case of
      __clear_user... which means that we can cause a nasty kernel panic as an
      ordinary user with any multiple PAGE_SIZE+1 read from /dev/zero.
      i.e.: dd if=/dev/zero of=foo ibs=1 count=1 (or ibs=65537, etc.)
      
      This is a pretty obscure bug in the general case since we'll only
      __do_kernel_fault (since there's no extable entry for pc) if the
      mmap_sem is contended. However, with CONFIG_DEBUG_VM enabled, we'll
      always fault.
      
      if (!down_read_trylock(&mm->mmap_sem)) {
      	if (!user_mode(regs) && !search_exception_tables(regs->pc))
      		goto no_context;
      retry:
      	down_read(&mm->mmap_sem);
      } else {
      	/*
      	 * The above down_read_trylock() might have succeeded in
      	 * which
      	 * case, we'll have missed the might_sleep() from
      	 * down_read().
      	 */
      	might_sleep();
      	if (!user_mode(regs) && !search_exception_tables(regs->pc))
      		goto no_context;
      }
      
      Fix that by adding an extable entry for the strb instruction, since it
      touches user memory, similar to the other stores in __clear_user.
      Signed-off-by: default avatarKyle McMartin <kyle@redhat.com>
      Reported-by: default avatarMiloš Prchlík <mprchlik@redhat.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      73d908ca
    • Mark Rutland's avatar
      arm64: efi: Fix stub cache maintenance · d856a4f7
      Mark Rutland authored
      commit 9b0b2658 upstream.
      
      While efi-entry.S mentions that efi_entry() will have relocated the
      kernel image, it actually means that efi_entry will have placed a copy
      of the kernel in the appropriate location, and until this is branched to
      at the end of efi_entry.S, all instructions are executed from the
      original image.
      
      Thus while the flush in efi_entry.S does ensure that the copy is visible
      to noncacheable accesses, it does not guarantee that this is true for
      the image instructions are being executed from. This could have
      disasterous effects when the MMU and caches are disabled if the image
      has not been naturally evicted to the PoC.
      
      Additionally, due to a missing dsb following the ic ialluis, the new
      kernel image is not necessarily clean in the I-cache when it is branched
      to, with similar potentially disasterous effects.
      
      This patch adds additional flushing to ensure that the currently
      executing stub text is flushed to the PoC and is thus visible to
      noncacheable accesses. As it is placed after the instructions cache
      maintenance for the new image and __flush_dcache_area already contains a
      dsb, we do not need to add a separate barrier to ensure completion of
      the icache maintenance.
      
      Comments are updated to clarify the situation with regard to the two
      images and the maintenance required for both.
      
      Fixes: 3c7f2550Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarJoel Schopp <joel.schopp@amd.com>
      Reviewed-by: default avatarRoy Franz <roy.franz@linaro.org>
      Tested-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Ian Campbell <ijc@hellion.org.uk>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d856a4f7
    • Takashi Iwai's avatar
      ALSA: hda - Add mute LED control for Lenovo Ideapad Z560 · 882ab5d6
      Takashi Iwai authored
      commit 3542aed7 upstream.
      
      Lenovo Ideapad Z560 has a mute LED that is controlled via EAPD pin
      0x1b on CX20585 codec.  (EAPD bit on corresponds to mute LED on.)
      The machine doesn't need other EAPD, so the fixup concentrates on
      controlling EAPD 0x1b following the vmaster state (but inversely).
      
      Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=665315Reported-by: default avatarSzymon Kowalczyk <fazerxlo@o2.pl>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      882ab5d6
    • Trond Myklebust's avatar
      ce37df67
    • Trond Myklebust's avatar
      NFSv4: Ensure that we call FREE_STATEID when NFSv4.x stateids are revoked · 6bcacd76
      Trond Myklebust authored
      commit c606bb88 upstream.
      
      NFSv4.x (x>0) requires us to call TEST_STATEID+FREE_STATEID if a stateid is
      revoked. We will currently fail to do this if the stateid is a delegation.
      
      http://lkml.kernel.org/r/CAN-5tyHwG=Cn2Q9KsHWadewjpTTy_K26ee+UnSvHvG4192p-Xw@mail.gmail.comSigned-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6bcacd76
    • Trond Myklebust's avatar
      NFSv4: Fix races between nfs_remove_bad_delegation() and delegation return · c37089e0
      Trond Myklebust authored
      commit 869f9dfa upstream.
      
      Any attempt to call nfs_remove_bad_delegation() while a delegation is being
      returned is currently a no-op. This means that we can end up looping
      forever in nfs_end_delegation_return() if something causes the delegation
      to be revoked.
      This patch adds a mechanism whereby the state recovery code can communicate
      to the delegation return code that the delegation is no longer valid and
      that it should not be used when reclaiming state.
      It also changes the return value for nfs4_handle_delegation_recall_error()
      to ensure that nfs_end_delegation_return() does not reattempt the lock
      reclaim before state recovery is done.
      
      http://lkml.kernel.org/r/CAN-5tyHwG=Cn2Q9KsHWadewjpTTy_K26ee+UnSvHvG4192p-Xw@mail.gmail.comSigned-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c37089e0
    • Trond Myklebust's avatar
      NFSv4.1: nfs41_clear_delegation_stateid shouldn't trust NFS_DELEGATED_STATE · 90a9d2d8
      Trond Myklebust authored
      commit 0c116cad upstream.
      
      This patch removes the assumption made previously, that we only need to
      check the delegation stateid when it matches the stateid on a cached
      open.
      
      If we believe that we hold a delegation for this file, then we must assume
      that its stateid may have been revoked or expired too. If we don't test it
      then our state recovery process may end up caching open/lock state in a
      situation where it should not.
      We therefore rename the function nfs41_clear_delegation_stateid as
      nfs41_check_delegation_stateid, and change it to always run through the
      delegation stateid test and recovery process as outlined in RFC5661.
      
      http://lkml.kernel.org/r/CAN-5tyHwG=Cn2Q9KsHWadewjpTTy_K26ee+UnSvHvG4192p-Xw@mail.gmail.comSigned-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      90a9d2d8