1. 14 Feb, 2017 19 commits
  2. 09 Feb, 2017 21 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.48 · 6a1bd906
      Greg Kroah-Hartman authored
      6a1bd906
    • Toshi Kani's avatar
      base/memory, hotplug: fix a kernel oops in show_valid_zones() · 87ebcc53
      Toshi Kani authored
      commit a96dfddb upstream.
      
      Reading a sysfs "memoryN/valid_zones" file leads to the following oops
      when the first page of a range is not backed by struct page.
      show_valid_zones() assumes that 'start_pfn' is always valid for
      page_zone().
      
       BUG: unable to handle kernel paging request at ffffea017a000000
       IP: show_valid_zones+0x6f/0x160
      
      This issue may happen on x86-64 systems with 64GiB or more memory since
      their memory block size is bumped up to 2GiB.  [1] An example of such
      systems is desribed below.  0x3240000000 is only aligned by 1GiB and
      this memory block starts from 0x3200000000, which is not backed by
      struct page.
      
       BIOS-e820: [mem 0x0000003240000000-0x000000603fffffff] usable
      
      Since test_pages_in_a_zone() already checks holes, fix this issue by
      extending this function to return 'valid_start' and 'valid_end' for a
      given range.  show_valid_zones() then proceeds with the valid range.
      
      [1] 'Commit bdee237c ("x86: mm: Use 2GB memory block size on
          large-memory x86-64 systems")'
      
      Link: http://lkml.kernel.org/r/20170127222149.30893-3-toshi.kani@hpe.comSigned-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Zhang Zhen <zhenzhang.zhang@huawei.com>
      Cc: Reza Arbab <arbab@linux.vnet.ibm.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: <stable@vger.kernel.org>	[4.4+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      87ebcc53
    • Thomas Gleixner's avatar
      x86/irq: Make irq activate operations symmetric · 374d0669
      Thomas Gleixner authored
      commit aaaec6fc upstream.
      
      The recent commit which prevents double activation of interrupts unearthed
      interesting code in x86. The code (ab)uses irq_domain_activate_irq() to
      reconfigure an already activated interrupt. That trips over the prevention
      code now.
      
      Fix it by deactivating the interrupt before activating the new configuration.
      
      Fixes: 08d85f3e "irqdomain: Avoid activating interrupts more than once"
      Reported-and-tested-by: default avatarMike Galbraith <efault@gmx.de>
      Reported-and-tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311901580.3457@nanosSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      374d0669
    • Bjørn Mork's avatar
      USB: serial: option: add device ID for HP lt2523 (Novatel E371) · 94c0517f
      Bjørn Mork authored
      commit 5d03a2fd upstream.
      
      Yet another laptop vendor rebranded Novatel E371.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94c0517f
    • Vincent Pelletier's avatar
      usb: gadget: f_fs: Assorted buffer overflow checks. · 9cf89ade
      Vincent Pelletier authored
      commit 83e526f2 upstream.
      
      OS descriptor head, when flagged as provided, is accessed without
      checking if it fits in provided buffer. Verify length before access.
      Also, there are other places where buffer length it checked
      after accessing offsets which are potentially past the end. Check
      buffer length before as well to fail cleanly.
      Signed-off-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Acked-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9cf89ade
    • Lukáš Lalinský's avatar
      USB: Add quirk for WORLDE easykey.25 MIDI keyboard · e4c1e664
      Lukáš Lalinský authored
      commit d9b2997e upstream.
      
      Add a quirk for WORLDE easykey.25 MIDI keyboard (idVendor=0218,
      idProduct=0401). The device reports that it has config string
      descriptor at index 3, but when the system selects the configuration
      and tries to get the description, it returns a -EPROTO error,
      the communication restarts and this keeps repeating over and over again.
      Not requesting the string descriptor makes the device work correctly.
      
      Relevant info from Wireshark:
      
      [...]
      
      CONFIGURATION DESCRIPTOR
          bLength: 9
          bDescriptorType: 0x02 (CONFIGURATION)
          wTotalLength: 101
          bNumInterfaces: 2
          bConfigurationValue: 1
          iConfiguration: 3
          Configuration bmAttributes: 0xc0  SELF-POWERED  NO REMOTE-WAKEUP
              1... .... = Must be 1: Must be 1 for USB 1.1 and higher
              .1.. .... = Self-Powered: This device is SELF-POWERED
              ..0. .... = Remote Wakeup: This device does NOT support remote wakeup
          bMaxPower: 50  (100mA)
      
      [...]
      
           45 0.369104       host                  2.38.0                USB      64     GET DESCRIPTOR Request STRING
      
      [...]
      
      URB setup
          bmRequestType: 0x80
              1... .... = Direction: Device-to-host
              .00. .... = Type: Standard (0x00)
              ...0 0000 = Recipient: Device (0x00)
          bRequest: GET DESCRIPTOR (6)
          Descriptor Index: 0x03
          bDescriptorType: 0x03
          Language Id: English (United States) (0x0409)
          wLength: 255
      
           46 0.369255       2.38.0                host                  USB      64     GET DESCRIPTOR Response STRING[Malformed Packet]
      
      [...]
      
      Frame 46: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0
      USB URB
          [Source: 2.38.0]
          [Destination: host]
          URB id: 0xffff88021f62d480
          URB type: URB_COMPLETE ('C')
          URB transfer type: URB_CONTROL (0x02)
          Endpoint: 0x80, Direction: IN
          Device: 38
          URB bus id: 2
          Device setup request: not relevant ('-')
          Data: present (0)
          URB sec: 1484896277
          URB usec: 455031
          URB status: Protocol error (-EPROTO) (-71)
          URB length [bytes]: 0
          Data length [bytes]: 0
          [Request in: 45]
          [Time from request: 0.000151000 seconds]
          Unused Setup Header
          Interval: 0
          Start frame: 0
          Copy of Transfer Flags: 0x00000200
          Number of ISO descriptors: 0
      [Malformed Packet: USB]
          [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
              [Malformed Packet (Exception occurred)]
              [Severity level: Error]
              [Group: Malformed]
      Signed-off-by: default avatarLukáš Lalinský <lukas@oxygene.sk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4c1e664
    • Marcel J.E. Mol's avatar
      USB: serial: pl2303: add ATEN device ID · b4b3442e
      Marcel J.E. Mol authored
      commit d07830db upstream.
      
      Seems that ATEN serial-to-usb devices using pl2303 exist with
      different device ids. This patch adds a missing device ID so it
      is recognised by the driver.
      Signed-off-by: default avatarMarcel J.E. Mol <marcel@mesa.nl>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4b3442e
    • Aleksander Morgado's avatar
      USB: serial: qcserial: add Dell DW5570 QDL · 244e7f00
      Aleksander Morgado authored
      commit 24d615a6 upstream.
      
      The Dell DW5570 is a re-branded Sierra Wireless MC8805 which will by
      default boot with vid 0x413c and pid 0x81a3. When triggered QDL download
      mode, the device switches to pid 0x81a6 and provides the standard TTY
      used for firmware upgrade.
      Signed-off-by: default avatarAleksander Morgado <aleksander@aleksander.es>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      244e7f00
    • Radim Krčmář's avatar
      KVM: x86: do not save guest-unsupported XSAVE state · f4f09b79
      Radim Krčmář authored
      commit 00c87e9a upstream.
      
      Saving unsupported state prevents migration when the new host does not
      support a XSAVE feature of the original host, even if the feature is not
      exposed to the guest.
      
      We've masked host features with guest-visible features before, with
      4344ee98 ("KVM: x86: only copy XSAVE state for the supported
      features") and dropped it when implementing XSAVES.  Do it again.
      
      Fixes: df1daba7 ("KVM: x86: support XSAVES usage in the host")
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f4f09b79
    • Jason Gerecke's avatar
      HID: wacom: Fix poor prox handling in 'wacom_pl_irq' · 8b51676d
      Jason Gerecke authored
      commit 282e4637 upstream.
      
      Commit 025bcc15 performed cleanup work on the 'wacom_pl_irq' function, making
      it follow the standards used in the rest of the codebase. The change
      unintiontionally allowed the function to send input events from reports
      that are not marked as being in prox. This can cause problems as the
      report values for X, Y, etc. are not guaranteed to be correct. In
      particular, occasionally the tablet will send a report with these values
      set to zero. If such a report is received it can caus an unexpected jump
      in the XY position.
      
      This patch surrounds more of the processing code with a proximity check,
      preventing these zeroed reports from overwriting the current state. To
      be safe, only the tool type and ABS_MISC events should be reported when
      the pen is marked as being out of prox.
      
      Fixes: 025bcc15 ("HID: wacom: Simplify 'wacom_pl_irq'")
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarPing Cheng <pingc@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b51676d
    • Douglas Miller's avatar
      percpu-refcount: fix reference leak during percpu-atomic transition · b3c8c31e
      Douglas Miller authored
      commit 966d2b04 upstream.
      
      percpu_ref_tryget() and percpu_ref_tryget_live() should return
      "true" IFF they acquire a reference. But the return value from
      atomic_long_inc_not_zero() is a long and may have high bits set,
      e.g. PERCPU_COUNT_BIAS, and the return value of the tryget routines
      is bool so the reference may actually be acquired but the routines
      return "false" which results in a reference leak since the caller
      assumes it does not need to do a corresponding percpu_ref_put().
      
      This was seen when performing CPU hotplug during I/O, as hangs in
      blk_mq_freeze_queue_wait where percpu_ref_kill (blk_mq_freeze_queue_start)
      raced with percpu_ref_tryget (blk_mq_timeout_work).
      Sample stack trace:
      
      __switch_to+0x2c0/0x450
      __schedule+0x2f8/0x970
      schedule+0x48/0xc0
      blk_mq_freeze_queue_wait+0x94/0x120
      blk_mq_queue_reinit_work+0xb8/0x180
      blk_mq_queue_reinit_prepare+0x84/0xa0
      cpuhp_invoke_callback+0x17c/0x600
      cpuhp_up_callbacks+0x58/0x150
      _cpu_up+0xf0/0x1c0
      do_cpu_up+0x120/0x150
      cpu_subsys_online+0x64/0xe0
      device_online+0xb4/0x120
      online_store+0xb4/0xc0
      dev_attr_store+0x68/0xa0
      sysfs_kf_write+0x80/0xb0
      kernfs_fop_write+0x17c/0x250
      __vfs_write+0x6c/0x1e0
      vfs_write+0xd0/0x270
      SyS_write+0x6c/0x110
      system_call+0x38/0xe0
      
      Examination of the queue showed a single reference (no PERCPU_COUNT_BIAS,
      and __PERCPU_REF_DEAD, __PERCPU_REF_ATOMIC set) and no requests.
      However, conditions at the time of the race are count of PERCPU_COUNT_BIAS + 0
      and __PERCPU_REF_DEAD and __PERCPU_REF_ATOMIC set.
      
      The fix is to make the tryget routines use an actual boolean internally instead
      of the atomic long result truncated to a int.
      
      Fixes: e625305b percpu-refcount: make percpu_ref based on longs instead of ints
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=190751Signed-off-by: default avatarDouglas Miller <dougmill@linux.vnet.ibm.com>
      Reviewed-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Fixes: e625305b ("percpu-refcount: make percpu_ref based on longs instead of ints")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3c8c31e
    • Gabriel Krisman Bertazi's avatar
      mmc: sdhci: Ignore unexpected CARD_INT interrupts · 3a8e2178
      Gabriel Krisman Bertazi authored
      commit 161e6d44 upstream.
      
      One of our kernelCI boxes hanged at boot because a faulty eSDHC device
      was triggering spurious CARD_INT interrupts for SD cards, causing CMD52
      reads, which are not allowed for SD devices.  This adds a sanity check
      to the interruption path, preventing that illegal command from getting
      sent if the CARD_INT interruption should be disabled.
      
      This quirk allows that particular machine to resume boot despite the
      faulty hardware, instead of getting hung dealing with thousands of
      mishandled interrupts.
      Suggested-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarGabriel Krisman Bertazi <krisman@collabora.co.uk>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a8e2178
    • Oliver Hartkopp's avatar
      can: bcm: fix hrtimer/tasklet termination in bcm op removal · 85fb980a
      Oliver Hartkopp authored
      commit a06393ed upstream.
      
      When removing a bcm tx operation either a hrtimer or a tasklet might run.
      As the hrtimer triggers its associated tasklet and vice versa we need to
      take care to mutually terminate both handlers.
      Reported-by: default avatarMichael Josenhans <michael.josenhans@web.de>
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Tested-by: default avatarMichael Josenhans <michael.josenhans@web.de>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      85fb980a
    • Michal Hocko's avatar
      mm, fs: check for fatal signals in do_generic_file_read() · 4025ab36
      Michal Hocko authored
      commit 5abf186a upstream.
      
      do_generic_file_read() can be told to perform a large request from
      userspace.  If the system is under OOM and the reading task is the OOM
      victim then it has an access to memory reserves and finishing the full
      request can lead to the full memory depletion which is dangerous.  Make
      sure we rather go with a short read and allow the killed task to
      terminate.
      
      Link: http://lkml.kernel.org/r/20170201092706.9966-3-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4025ab36
    • Toshi Kani's avatar
      mm/memory_hotplug.c: check start_pfn in test_pages_in_a_zone() · e86a8769
      Toshi Kani authored
      commit deb88a2a upstream.
      
      Patch series "fix a kernel oops when reading sysfs valid_zones", v2.
      
      A sysfs memory file is created for each 2GiB memory block on x86-64 when
      the system has 64GiB or more memory.  [1] When the start address of a
      memory block is not backed by struct page, i.e.  a memory range is not
      aligned by 2GiB, reading its 'valid_zones' attribute file leads to a
      kernel oops.  This issue was observed on multiple x86-64 systems with
      more than 64GiB of memory.  This patch-set fixes this issue.
      
      Patch 1 first fixes an issue in test_pages_in_a_zone(), which does not
      test the start section.
      
      Patch 2 then fixes the kernel oops by extending test_pages_in_a_zone()
      to return valid [start, end).
      
      Note for stable kernels: The memory block size change was made by commit
      bdee237c ("x86: mm: Use 2GB memory block size on large-memory x86-64
      systems"), which was accepted to 3.9.  However, this patch-set depends
      on (and fixes) the change to test_pages_in_a_zone() made by commit
      5f0f2887 ("mm/memory_hotplug.c: check for missing sections in
      test_pages_in_a_zone()"), which was accepted to 4.4.
      
      So, I recommend that we backport it up to 4.4.
      
      [1] 'Commit bdee237c ("x86: mm: Use 2GB memory block size on
          large-memory x86-64 systems")'
      
      This patch (of 2):
      
      test_pages_in_a_zone() does not check 'start_pfn' when it is aligned by
      section since 'sec_end_pfn' is set equal to 'pfn'.  Since this function
      is called for testing the range of a sysfs memory file, 'start_pfn' is
      always aligned by section.
      
      Fix it by properly setting 'sec_end_pfn' to the next section pfn.
      
      Also make sure that this function returns 1 only when the range belongs
      to a zone.
      
      Link: http://lkml.kernel.org/r/20170127222149.30893-2-toshi.kani@hpe.comSigned-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Cc: Andrew Banman <abanman@sgi.com>
      Cc: Reza Arbab <arbab@linux.vnet.ibm.com>
      Cc: Greg KH <greg@kroah.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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e86a8769
    • Rabin Vincent's avatar
      cifs: initialize file_info_lock · 920bba10
      Rabin Vincent authored
      commit 81ddd8c0 upstream.
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      
      file_info_lock is not initalized in initiate_cifs_search(), leading to the
      following splat after a simple "mount.cifs ... dir && ls dir/":
      
       BUG: spinlock bad magic on CPU#0, ls/486
        lock: 0xffff880009301110, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
       CPU: 0 PID: 486 Comm: ls Not tainted 4.9.0 #27
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
        ffffc900042f3db0 ffffffff81327533 0000000000000000 ffff880009301110
        ffffc900042f3dd0 ffffffff810baf75 ffff880009301110 ffffffff817ae077
        ffffc900042f3df0 ffffffff810baff6 ffff880009301110 ffff880008d69900
       Call Trace:
        [<ffffffff81327533>] dump_stack+0x65/0x92
        [<ffffffff810baf75>] spin_dump+0x85/0xe0
        [<ffffffff810baff6>] spin_bug+0x26/0x30
        [<ffffffff810bb159>] do_raw_spin_lock+0xe9/0x130
        [<ffffffff8159ad2f>] _raw_spin_lock+0x1f/0x30
        [<ffffffff8127e50d>] cifs_closedir+0x4d/0x100
        [<ffffffff81181cfd>] __fput+0x5d/0x160
        [<ffffffff81181e3e>] ____fput+0xe/0x10
        [<ffffffff8109410e>] task_work_run+0x7e/0xa0
        [<ffffffff81002512>] exit_to_usermode_loop+0x92/0xa0
        [<ffffffff810026f9>] syscall_return_slowpath+0x49/0x50
        [<ffffffff8159b484>] entry_SYSCALL_64_fastpath+0xa7/0xa9
      
      Fixes: 3afca265 ("Clarify locking of cifs file and tcon structures and make more granular")
      Signed-off-by: default avatarRabin Vincent <rabinv@axis.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      920bba10
    • Dan Streetman's avatar
      zswap: disable changing params if init fails · 7aeb95ce
      Dan Streetman authored
      commit d7b028f5 upstream.
      
      Add zswap_init_failed bool that prevents changing any of the module
      params, if init_zswap() fails, and set zswap_enabled to false.  Change
      'enabled' param to a callback, and check zswap_init_failed before
      allowing any change to 'enabled', 'zpool', or 'compressor' params.
      
      Any driver that is built-in to the kernel will not be unloaded if its
      init function returns error, and its module params remain accessible for
      users to change via sysfs.  Since zswap uses param callbacks, which
      assume that zswap has been initialized, changing the zswap params after
      a failed initialization will result in WARNING due to the param
      callbacks expecting a pool to already exist.  This prevents that by
      immediately exiting any of the param callbacks if initialization failed.
      
      This was reported here:
        https://marc.info/?l=linux-mm&m=147004228125528&w=4
      
      And fixes this WARNING:
        [  429.723476] WARNING: CPU: 0 PID: 5140 at mm/zswap.c:503 __zswap_pool_current+0x56/0x60
      
      The warning is just noise, and not serious.  However, when init fails,
      zswap frees all its percpu dstmem pages and its kmem cache.  The kmem
      cache might be serious, if kmem_cache_alloc(NULL, gfp) has problems; but
      the percpu dstmem pages are definitely a problem, as they're used as
      temporary buffer for compressed pages before copying into place in the
      zpool.
      
      If the user does get zswap enabled after an init failure, then zswap
      will likely Oops on the first page it tries to compress (or worse, start
      corrupting memory).
      
      Fixes: 90b0fc26 ("zswap: change zpool/compressor at runtime")
      Link: http://lkml.kernel.org/r/20170124200259.16191-2-ddstreet@ieee.orgSigned-off-by: default avatarDan Streetman <dan.streetman@canonical.com>
      Reported-by: default avatarMarcin Miroslaw <marcin@mejor.pl>
      Cc: Seth Jennings <sjenning@redhat.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7aeb95ce
    • J. Bruce Fields's avatar
      svcrpc: fix oops in absence of krb5 module · 5dadebc6
      J. Bruce Fields authored
      commit 034dd34f upstream.
      
      Olga Kornievskaia says: "I ran into this oops in the nfsd (below)
      (4.10-rc3 kernel). To trigger this I had a client (unsuccessfully) try
      to mount the server with krb5 where the server doesn't have the
      rpcsec_gss_krb5 module built."
      
      The problem is that rsci.cred is copied from a svc_cred structure that
      gss_proxy didn't properly initialize.  Fix that.
      
      [120408.542387] general protection fault: 0000 [#1] SMP
      ...
      [120408.565724] CPU: 0 PID: 3601 Comm: nfsd Not tainted 4.10.0-rc3+ #16
      [120408.567037] Hardware name: VMware, Inc. VMware Virtual =
      Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
      [120408.569225] task: ffff8800776f95c0 task.stack: ffffc90003d58000
      [120408.570483] RIP: 0010:gss_mech_put+0xb/0x20 [auth_rpcgss]
      ...
      [120408.584946]  ? rsc_free+0x55/0x90 [auth_rpcgss]
      [120408.585901]  gss_proxy_save_rsc+0xb2/0x2a0 [auth_rpcgss]
      [120408.587017]  svcauth_gss_proxy_init+0x3cc/0x520 [auth_rpcgss]
      [120408.588257]  ? __enqueue_entity+0x6c/0x70
      [120408.589101]  svcauth_gss_accept+0x391/0xb90 [auth_rpcgss]
      [120408.590212]  ? try_to_wake_up+0x4a/0x360
      [120408.591036]  ? wake_up_process+0x15/0x20
      [120408.592093]  ? svc_xprt_do_enqueue+0x12e/0x2d0 [sunrpc]
      [120408.593177]  svc_authenticate+0xe1/0x100 [sunrpc]
      [120408.594168]  svc_process_common+0x203/0x710 [sunrpc]
      [120408.595220]  svc_process+0x105/0x1c0 [sunrpc]
      [120408.596278]  nfsd+0xe9/0x160 [nfsd]
      [120408.597060]  kthread+0x101/0x140
      [120408.597734]  ? nfsd_destroy+0x60/0x60 [nfsd]
      [120408.598626]  ? kthread_park+0x90/0x90
      [120408.599448]  ret_from_fork+0x22/0x30
      
      Fixes: 1d658336 "SUNRPC: Add RPC based upcall mechanism for RPCGSS auth"
      Cc: Simo Sorce <simo@redhat.com>
      Reported-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Tested-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5dadebc6
    • Kinglong Mee's avatar
      NFSD: Fix a null reference case in find_or_create_lock_stateid() · 2b4e56fd
      Kinglong Mee authored
      commit d19fb70d upstream.
      
      nfsd assigns the nfs4_free_lock_stateid to .sc_free in init_lock_stateid().
      
      If nfsd doesn't go through init_lock_stateid() and put stateid at end,
      there is a NULL reference to .sc_free when calling nfs4_put_stid(ns).
      
      This patch let the nfs4_stid.sc_free assignment to nfs4_alloc_stid().
      
      Fixes: 356a95ec "nfsd: clean up races in lock stateid searching..."
      Signed-off-by: default avatarKinglong Mee <kinglongmee@gmail.com>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b4e56fd
    • Darren Stevens's avatar
      powerpc: Add missing error check to prom_find_boot_cpu() · f584bb6d
      Darren Stevens authored
      commit af2b7fa1 upstream.
      
      prom_init.c calls 'instance-to-package' twice, but the return
      is not checked during prom_find_boot_cpu(). The result is then
      passed to prom_getprop(), which could be PROM_ERROR. Add a return check
      to prevent this.
      
      This was found on a pasemi system, where CFE doesn't have a working
      'instance-to package' prom call.
      
      Before Commit 5c0484e2 ('powerpc: Endian safe trampoline') the area
      around addr 0 was mostly 0's and this doesn't cause a problem. Once the
      macro 'FIXUP_ENDIAN' has been added to head_64.S, the low memory area
      now has non-zero values, which cause the prom_getprop() call
      to hang.
      
      mpe: Also confirmed that under SLOF if 'instance-to-package' did fail
      with PROM_ERROR we would crash in SLOF. So the bug is not specific to
      CFE, it's just that other open firmwares don't trigger it because they
      have a working 'instance-to-package'.
      
      Fixes: 5c0484e2 ("powerpc: Endian safe trampoline")
      Signed-off-by: default avatarDarren Stevens <darren@stevens-zone.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f584bb6d
    • Gavin Shan's avatar
      powerpc/eeh: Fix wrong flag passed to eeh_unfreeze_pe() · 9b993e2c
      Gavin Shan authored
      commit f05fea5b upstream.
      
      In __eeh_clear_pe_frozen_state(), we should pass the flag's value
      instead of its address to eeh_unfreeze_pe(). The isolated flag is
      cleared if no error returned from __eeh_clear_pe_frozen_state(). We
      never observed the error from the function. So the isolated flag should
      have been always cleared, no real issue is caused because of the misused
      @flag.
      
      This fixes the code by passing the value of @flag to eeh_unfreeze_pe().
      
      Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b993e2c