1. 06 Jun, 2016 40 commits
    • Ricky Liang's avatar
      Input: uinput - handle compat ioctl for UI_SET_PHYS · 8a1a3f78
      Ricky Liang authored
      [ Upstream commit affa80bd ]
      
      When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS
      ioctl needs to be treated with special care, as it has the pointer
      size encoded in the command.
      Signed-off-by: default avatarRicky Liang <jcliang@chromium.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      8a1a3f78
    • Matt Evans's avatar
      kvm: arm64: Fix EC field in inject_abt64 · fb4e7a0a
      Matt Evans authored
      [ Upstream commit e4fe9e7d ]
      
      The EC field of the constructed ESR is conditionally modified by ORing in
      ESR_ELx_EC_DABT_LOW for a data abort.  However, ESR_ELx_EC_SHIFT is missing
      from this condition.
      Signed-off-by: default avatarMatt Evans <matt.evans@arm.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      fb4e7a0a
    • Kai-Heng Feng's avatar
      ALSA: hda - Fix headphone noise on Dell XPS 13 9360 · 0d4a4eba
      Kai-Heng Feng authored
      [ Upstream commit 423cd785 ]
      
      The headphone has noise when playing sound or switching microphone sources.
      It uses the same codec on XPS 13 9350, but with different subsystem ID.
      Applying the fixup can solve the issue.
      Also, changing the model name to better differentiate models.
      
      v2: Reorder by device ID.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      0d4a4eba
    • David Henningsson's avatar
      ALSA: hda - Fix headphone mic input on a few Dell ALC293 machines · 71f788d6
      David Henningsson authored
      [ Upstream commit c04017ea ]
      
      These laptops support both headphone, headset and mic modes
      for the 3.5mm jack.
      
      Cc: stable@vger.kernel.org
      BugLink: https://bugs.launchpad.net/bugs/1526330Signed-off-by: default avatarDavid Henningsson <david.henningsson@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      71f788d6
    • Sachin Prabhu's avatar
      cifs: Create dedicated keyring for spnego operations · f1f125da
      Sachin Prabhu authored
      [ Upstream commit b74cb9a8 ]
      
      The session key is the default keyring set for request_key operations.
      This session key is revoked when the user owning the session logs out.
      Any long running daemon processes started by this session ends up with
      revoked session keyring which prevents these processes from using the
      request_key mechanism from obtaining the krb5 keys.
      
      The problem has been reported by a large number of autofs users. The
      problem is also seen with multiuser mounts where the share may be used
      by processes run by a user who has since logged out. A reproducer using
      automount is available on the Red Hat bz.
      
      The patch creates a new keyring which is used to cache cifs spnego
      upcalls.
      
      Red Hat bz: 1267754
      Signed-off-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      Reported-by: default avatarScott Mayhew <smayhew@redhat.com>
      Reviewed-by: default avatarShirish Pargaonkar <shirishpargaonkar@gmail.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f1f125da
    • Mark Brown's avatar
      ASoC: ak4642: Enable cache usage to fix crashes on resume · ded044fc
      Mark Brown authored
      [ Upstream commit d3030d11 ]
      
      The ak4642 driver is using a regmap cache sync to restore the
      configuration of the chip on resume but (as Peter observed) does not
      actually define a register cache which means that the resume is never
      going to work and we trigger asserts in regmap.  Fix this by enabling
      caching.
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reported-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ded044fc
    • Axel Lin's avatar
      ASoC: ak4642: Fix up max_register setting · 141afa30
      Axel Lin authored
      [ Upstream commit f8ea6ceb ]
      
      The max_register setting for ak4642, ak4643 and ak4648 are wrong, fix it.
      
      According to the datasheet:
              the maximum valid register for ak4642 is 0x1f
              the maximum valid register for ak4643 is 0x24
              the maximum valid register for ak4648 is 0x27
      
      The default settings for ak4642 and ak4643 are the same for 0x0 ~ 0x1f
      registers, so it's fine to use the same reg_default table with differnt
      num_reg_defaults setting.
      Signed-off-by: default avatarAxel Lin <axel.lin@ingics.com>
      Tested-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      141afa30
    • Dave Chinner's avatar
      xfs: skip stale inodes in xfs_iflush_cluster · 4b126ba9
      Dave Chinner authored
      [ Upstream commit 7d3aa7fe ]
      
      We don't write back stale inodes so we should skip them in
      xfs_iflush_cluster, too.
      
      cc: <stable@vger.kernel.org> # 3.10.x-
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4b126ba9
    • Dave Chinner's avatar
      xfs: fix inode validity check in xfs_iflush_cluster · 3eeb7e76
      Dave Chinner authored
      [ Upstream commit 51b07f30 ]
      
      Some careless idiot(*) wrote crap code in commit 1a3e8f3d ("xfs:
      convert inode cache lookups to use RCU locking") back in late 2010,
      and so xfs_iflush_cluster checks the wrong inode for whether it is
      still valid under RCU protection. Fix it to lock and check the
      correct inode.
      
      (*) Careless-idiot: Dave Chinner <dchinner@redhat.com>
      
      cc: <stable@vger.kernel.org> # 3.10.x-
      Discovered-by: default avatarBrain Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      3eeb7e76
    • Dave Chinner's avatar
      xfs: xfs_iflush_cluster fails to abort on error · 6659d794
      Dave Chinner authored
      [ Upstream commit b1438f47 ]
      
      When a failure due to an inode buffer occurs, the error handling
      fails to abort the inode writeback correctly. This can result in the
      inode being reclaimed whilst still in the AIL, leading to
      use-after-free situations as well as filesystems that cannot be
      unmounted as the inode log items left in the AIL never get removed.
      
      Fix this by ensuring fatal errors from xfs_imap_to_bp() result in
      the inode flush being aborted correctly.
      
      cc: <stable@vger.kernel.org> # 3.10.x-
      Reported-by: default avatarShyam Kaushik <shyam@zadarastorage.com>
      Diagnosed-by: default avatarShyam Kaushik <shyam@zadarastorage.com>
      Tested-by: default avatarShyam Kaushik <shyam@zadarastorage.com>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      6659d794
    • Daniel Lezcano's avatar
      cpuidle: Fix cpuidle_state_is_coupled() argument in cpuidle_enter() · c504b774
      Daniel Lezcano authored
      [ Upstream commit e7387da5 ]
      
      Commit 0b89e9aa (cpuidle: delay enabling interrupts until all
      coupled CPUs leave idle) rightfully fixed a regression by letting
      the coupled idle state framework to handle local interrupt enabling
      when the CPU is exiting an idle state.
      
      The current code checks if the idle state is coupled and, if so, it
      will let the coupled code to enable interrupts. This way, it can
      decrement the ready-count before handling the interrupt. This
      mechanism prevents the other CPUs from waiting for a CPU which is
      handling interrupts.
      
      But the check is done against the state index returned by the back
      end driver's ->enter functions which could be different from the
      initial index passed as parameter to the cpuidle_enter_state()
      function.
      
       entered_state = target_state->enter(dev, drv, index);
      
       [ ... ]
      
       if (!cpuidle_state_is_coupled(drv, entered_state))
      	local_irq_enable();
      
       [ ... ]
      
      If the 'index' is referring to a coupled idle state but the
      'entered_state' is *not* coupled, then the interrupts are enabled
      again. All CPUs blocked on the sync barrier may busy loop longer
      if the CPU has interrupts to handle before decrementing the
      ready-count. That's consuming more energy than saving.
      
      Fixes: 0b89e9aa (cpuidle: delay enabling interrupts until all coupled CPUs leave idle)
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
      [ rjw: Subject & changelog ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      c504b774
    • Xunlei Pang's avatar
      cpuidle/coupled: Remove redundant 'dev' argument of cpuidle_state_is_coupled() · d3bbf7b3
      Xunlei Pang authored
      [ Upstream commit 4c1ed5a6 ]
      
      For cpuidle_state_is_coupled(), 'dev' is not used, so remove it.
      Signed-off-by: default avatarXunlei Pang <pang.xunlei@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d3bbf7b3
    • Steve French's avatar
      remove directory incorrectly tries to set delete on close on non-empty directories · cde02e3a
      Steve French authored
      [ Upstream commit 897fba11 ]
      
      Wrong return code was being returned on SMB3 rmdir of
      non-empty directory.
      
      For SMB3 (unlike for cifs), we attempt to delete a directory by
      set of delete on close flag on the open. Windows clients set
      this flag via a set info (SET_FILE_DISPOSITION to set this flag)
      which properly checks if the directory is empty.
      
      With this patch on smb3 mounts we correctly return
       "DIRECTORY NOT EMPTY"
      on attempts to remove a non-empty directory.
      Signed-off-by: default avatarSteve French <steve.french@primarydata.com>
      CC: Stable <stable@vger.kernel.org>
      Acked-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      cde02e3a
    • Stefan Metzmacher's avatar
      fs/cifs: correctly to anonymous authentication for the NTLM(v2) authentication · b6044542
      Stefan Metzmacher authored
      [ Upstream commit 1a967d6c ]
      
      Only server which map unknown users to guest will allow
      access using a non-null NTLMv2_Response.
      
      For Samba it's the "map to guest = bad user" option.
      
      BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913Signed-off-by: default avatarStefan Metzmacher <metze@samba.org>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b6044542
    • Stefan Metzmacher's avatar
      fs/cifs: correctly to anonymous authentication for the NTLM(v1) authentication · 6842cd24
      Stefan Metzmacher authored
      [ Upstream commit 777f69b8 ]
      
      Only server which map unknown users to guest will allow
      access using a non-null NTChallengeResponse.
      
      For Samba it's the "map to guest = bad user" option.
      
      BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913Signed-off-by: default avatarStefan Metzmacher <metze@samba.org>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      6842cd24
    • Stefan Metzmacher's avatar
      fs/cifs: correctly to anonymous authentication for the LANMAN authentication · 8f83c449
      Stefan Metzmacher authored
      [ Upstream commit fa8f3a35 ]
      
      Only server which map unknown users to guest will allow
      access using a non-null LMChallengeResponse.
      
      For Samba it's the "map to guest = bad user" option.
      
      BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913Signed-off-by: default avatarStefan Metzmacher <metze@samba.org>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      8f83c449
    • Stefan Metzmacher's avatar
      fs/cifs: correctly to anonymous authentication via NTLMSSP · f39b1793
      Stefan Metzmacher authored
      [ Upstream commit cfda35d9 ]
      
      See [MS-NLMP] 3.2.5.1.2 Server Receives an AUTHENTICATE_MESSAGE from the Client:
      
         ...
         Set NullSession to FALSE
         If (AUTHENTICATE_MESSAGE.UserNameLen == 0 AND
            AUTHENTICATE_MESSAGE.NtChallengeResponse.Length == 0 AND
            (AUTHENTICATE_MESSAGE.LmChallengeResponse == Z(1)
             OR
             AUTHENTICATE_MESSAGE.LmChallengeResponse.Length == 0))
             -- Special case: client requested anonymous authentication
             Set NullSession to TRUE
         ...
      
      Only server which map unknown users to guest will allow
      access using a non-null NTChallengeResponse.
      
      For Samba it's the "map to guest = bad user" option.
      
      BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913
      
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarStefan Metzmacher <metze@samba.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f39b1793
    • Lyude's avatar
      drm/fb_helper: Fix references to dev->mode_config.num_connector · 9a2257ff
      Lyude authored
      [ Upstream commit 255f0e7c ]
      
      During boot, MST hotplugs are generally expected (even if no physical
      hotplugging occurs) and result in DRM's connector topology changing.
      This means that using num_connector from the current mode configuration
      can lead to the number of connectors changing under us. This can lead to
      some nasty scenarios in fbcon:
      
      - We allocate an array to the size of dev->mode_config.num_connectors.
      - MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
      - We try to loop through each element in the array using the new value
        of dev->mode_config.num_connectors, and end up going out of bounds
        since dev->mode_config.num_connectors is now larger then the array we
        allocated.
      
      fb_helper->connector_count however, will always remain consistent while
      we do a modeset in fb_helper.
      
      Note: This is just polish for 4.7, Dave Airlie's drm_connector
      refcounting fixed these bugs for real. But it's good enough duct-tape
      for stable kernel backporting, since backporting the refcounting
      changes is way too invasive.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      [danvet: Clarify why we need this. Also remove the now unused "dev"
      local variable to appease gcc.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.comSigned-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      9a2257ff
    • Lyude's avatar
      drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config() · d648fcdb
      Lyude authored
      [ Upstream commit 14a3842a ]
      
      During boot time, MST devices usually send a ton of hotplug events
      irregardless of whether or not any physical hotplugs actually occurred.
      Hotplugs mean connectors being created/destroyed, and the number of DRM
      connectors changing under us. This isn't a problem if we use
      fb_helper->connector_count since we only set it once in the code,
      however if we use num_connector from struct drm_mode_config we risk it's
      value changing under us. On top of that, there's even a chance that
      dev->mode_config.num_connector != fb_helper->connector_count. If the
      number of connectors happens to increase under us, we'll end up using
      the wrong array size for memcpy and start writing beyond the actual
      length of the array, occasionally resulting in kernel panics.
      
      Note: This is just polish for 4.7, Dave Airlie's drm_connector
      refcounting fixed these bugs for real. But it's good enough duct-tape
      for stable kernel backporting, since backporting the refcounting
      changes is way too invasive.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      [danvet: Clarify why we need this.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-2-git-send-email-cpaul@redhat.comSigned-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d648fcdb
    • Maciej W. Rozycki's avatar
      MIPS: MSA: Fix a link error on `_init_msa_upper' with older GCC · f52a1b99
      Maciej W. Rozycki authored
      [ Upstream commit e49d3848 ]
      
      Fix a build regression from commit c9017757 ("MIPS: init upper 64b
      of vector registers when MSA is first used"):
      
      arch/mips/built-in.o: In function `enable_restore_fp_context':
      traps.c:(.text+0xbb90): undefined reference to `_init_msa_upper'
      traps.c:(.text+0xbb90): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'
      traps.c:(.text+0xbef0): undefined reference to `_init_msa_upper'
      traps.c:(.text+0xbef0): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'
      
      to !CONFIG_CPU_HAS_MSA configurations with older GCC versions, which are
      unable to figure out that calls to `_init_msa_upper' are indeed dead.
      Of the many ways to tackle this failure choose the approach we have
      already taken in `thread_msa_context_live'.
      
      [ralf@linux-mips.org: Drop patch segment to junk file.]
      Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
      Cc: stable@vger.kernel.org # v3.16+
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13271/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f52a1b99
    • Prarit Bhargava's avatar
      PCI: Disable all BAR sizing for devices with non-compliant BARs · 8f25a2f3
      Prarit Bhargava authored
      [ Upstream commit ad67b437 ]
      
      b84106b4 ("PCI: Disable IO/MEM decoding for devices with non-compliant
      BARs") disabled BAR sizing for BARs 0-5 of devices that don't comply with
      the PCI spec.  But it didn't do anything for expansion ROM BARs, so we
      still try to size them, resulting in warnings like this on Broadwell-EP:
      
        pci 0000:ff:12.0: BAR 6: failed to assign [mem size 0x00000001 pref]
      
      Move the non-compliant BAR check from __pci_read_base() up to
      pci_read_bases() so it applies to the expansion ROM BAR as well as
      to BARs 0-5.
      
      Note that direct callers of __pci_read_base(), like sriov_init(), will now
      bypass this check.  We haven't had reports of devices with broken SR-IOV
      BARs yet.
      
      [bhelgaas: changelog]
      Fixes: b84106b4 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs")
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Ingo Molnar <mingo@redhat.com>
      CC: "H. Peter Anvin" <hpa@zytor.com>
      CC: Andi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      8f25a2f3
    • Adrian Hunter's avatar
      mmc: mmc: Fix partition switch timeout for some eMMCs · a8716599
      Adrian Hunter authored
      [ Upstream commit 1c447116 ]
      
      Some eMMCs set the partition switch timeout too low.
      
      Now typically eMMCs are considered a critical component (e.g. because
      they store the root file system) and consequently are expected to be
      reliable.  Thus we can neglect the use case where eMMCs can't switch
      reliably and we might want a lower timeout to facilitate speedy
      recovery.
      
      Although we could employ a quirk for the cards that are affected (if
      we could identify them all), as described above, there is little
      benefit to having a low timeout, so instead simply set a minimum
      timeout.
      
      The minimum is set to 300ms somewhat arbitrarily - the examples that
      have been seen had a timeout of 10ms but were sometimes taking 60-70ms.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      a8716599
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Prevent overflow of size in ring_buffer_resize() · ab2cfdb8
      Steven Rostedt (Red Hat) authored
      [ Upstream commit 59643d15 ]
      
      If the size passed to ring_buffer_resize() is greater than MAX_LONG - BUF_PAGE_SIZE
      then the DIV_ROUND_UP() will return zero.
      
      Here's the details:
      
        # echo 18014398509481980 > /sys/kernel/debug/tracing/buffer_size_kb
      
      tracing_entries_write() processes this and converts kb to bytes.
      
       18014398509481980 << 10 = 18446744073709547520
      
      and this is passed to ring_buffer_resize() as unsigned long size.
      
       size = DIV_ROUND_UP(size, BUF_PAGE_SIZE);
      
      Where DIV_ROUND_UP(a, b) is (a + b - 1)/b
      
      BUF_PAGE_SIZE is 4080 and here
      
       18446744073709547520 + 4080 - 1 = 18446744073709551599
      
      where 18446744073709551599 is still smaller than 2^64
      
       2^64 - 18446744073709551599 = 17
      
      But now 18446744073709551599 / 4080 = 4521260802379792
      
      and size = size * 4080 = 18446744073709551360
      
      This is checked to make sure its still greater than 2 * 4080,
      which it is.
      
      Then we convert to the number of buffer pages needed.
      
       nr_page = DIV_ROUND_UP(size, BUF_PAGE_SIZE)
      
      but this time size is 18446744073709551360 and
      
       2^64 - (18446744073709551360 + 4080 - 1) = -3823
      
      Thus it overflows and the resulting number is less than 4080, which makes
      
        3823 / 4080 = 0
      
      an nr_pages is set to this. As we already checked against the minimum that
      nr_pages may be, this causes the logic to fail as well, and we crash the
      kernel.
      
      There's no reason to have the two DIV_ROUND_UP() (that's just result of
      historical code changes), clean up the code and fix this bug.
      
      Cc: stable@vger.kernel.org # 3.5+
      Fixes: 83f40318 ("ring-buffer: Make removal of ring buffer pages atomic")
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ab2cfdb8
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Use long for nr_pages to avoid overflow failures · 453babf1
      Steven Rostedt (Red Hat) authored
      [ Upstream commit 9b94a8fb ]
      
      The size variable to change the ring buffer in ftrace is a long. The
      nr_pages used to update the ring buffer based on the size is int. On 64 bit
      machines this can cause an overflow problem.
      
      For example, the following will cause the ring buffer to crash:
      
       # cd /sys/kernel/debug/tracing
       # echo 10 > buffer_size_kb
       # echo 8556384240 > buffer_size_kb
      
      Then you get the warning of:
      
       WARNING: CPU: 1 PID: 318 at kernel/trace/ring_buffer.c:1527 rb_update_pages+0x22f/0x260
      
      Which is:
      
        RB_WARN_ON(cpu_buffer, nr_removed);
      
      Note each ring buffer page holds 4080 bytes.
      
      This is because:
      
       1) 10 causes the ring buffer to have 3 pages.
          (10kb requires 3 * 4080 pages to hold)
      
       2) (2^31 / 2^10  + 1) * 4080 = 8556384240
          The value written into buffer_size_kb is shifted by 10 and then passed
          to ring_buffer_resize(). 8556384240 * 2^10 = 8761737461760
      
       3) The size passed to ring_buffer_resize() is then divided by BUF_PAGE_SIZE
          which is 4080. 8761737461760 / 4080 = 2147484672
      
       4) nr_pages is subtracted from the current nr_pages (3) and we get:
          2147484669. This value is saved in a signed integer nr_pages_to_update
      
       5) 2147484669 is greater than 2^31 but smaller than 2^32, a signed int
          turns into the value of -2147482627
      
       6) As the value is a negative number, in update_pages_handler() it is
          negated and passed to rb_remove_pages() and 2147482627 pages will
          be removed, which is much larger than 3 and it causes the warning
          because not all the pages asked to be removed were removed.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=118001
      
      Cc: stable@vger.kernel.org # 2.6.28+
      Fixes: 7a8e76a3 ("tracing: unified trace buffer")
      Reported-by: default avatarHao Qin <QEver.cn@gmail.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      453babf1
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Move recursive check to per_cpu descriptor · d6bdff22
      Steven Rostedt (Red Hat) authored
      [ Upstream commit 58a09ec6 ]
      
      Instead of using a global per_cpu variable to perform the recursive
      checks into the ring buffer, use the already existing per_cpu descriptor
      that is part of the ring buffer itself.
      
      Not only does this simplify the code, it also allows for one ring buffer
      to be used within the guts of the use of another ring buffer. For example
      trace_printk() can now be used within the ring buffer to record changes
      done by an instance into the main ring buffer. The recursion checks
      will prevent the trace_printk() itself from causing recursive issues
      with the main ring buffer (it is just ignored), but the recursive
      checks wont prevent the trace_printk() from recording other ring buffers.
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d6bdff22
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Add unlikelys to make fast path the default · ac4e03df
      Steven Rostedt (Red Hat) authored
      [ Upstream commit 3205f806 ]
      
      I was running the trace_event benchmark and noticed that the times
      to record a trace_event was all over the place. I looked at the assembly
      of the ring_buffer_lock_reserver() and saw this:
      
       <ring_buffer_lock_reserve>:
             31 c0                   xor    %eax,%eax
             48 83 3d 76 47 bd 00    cmpq   $0x1,0xbd4776(%rip)        # ffffffff81d10d60 <ring_buffer_flags>
             01
             55                      push   %rbp
             48 89 e5                mov    %rsp,%rbp
             75 1d                   jne    ffffffff8113c60d <ring_buffer_lock_reserve+0x2d>
             65 ff 05 69 e3 ec 7e    incl   %gs:0x7eece369(%rip)        # a960 <__preempt_count>
             8b 47 08                mov    0x8(%rdi),%eax
             85 c0                   test   %eax,%eax
       +---- 74 12                   je     ffffffff8113c610 <ring_buffer_lock_reserve+0x30>
       |     65 ff 0d 5b e3 ec 7e    decl   %gs:0x7eece35b(%rip)        # a960 <__preempt_count>
       |     0f 84 85 00 00 00       je     ffffffff8113c690 <ring_buffer_lock_reserve+0xb0>
       |     31 c0                   xor    %eax,%eax
       |     5d                      pop    %rbp
       |     c3                      retq
       |     90                      nop
       +---> 65 44 8b 05 48 e3 ec    mov    %gs:0x7eece348(%rip),%r8d        # a960 <__preempt_count>
             7e
             41 81 e0 ff ff ff 7f    and    $0x7fffffff,%r8d
             b0 08                   mov    $0x8,%al
             65 8b 0d 58 36 ed 7e    mov    %gs:0x7eed3658(%rip),%ecx        # fc80 <current_context>
             41 f7 c0 00 ff 1f 00    test   $0x1fff00,%r8d
             74 1e                   je     ffffffff8113c64f <ring_buffer_lock_reserve+0x6f>
             41 f7 c0 00 00 10 00    test   $0x100000,%r8d
             b0 01                   mov    $0x1,%al
             75 13                   jne    ffffffff8113c64f <ring_buffer_lock_reserve+0x6f>
             41 81 e0 00 00 0f 00    and    $0xf0000,%r8d
             49 83 f8 01             cmp    $0x1,%r8
             19 c0                   sbb    %eax,%eax
             83 e0 02                and    $0x2,%eax
             83 c0 02                add    $0x2,%eax
             85 c8                   test   %ecx,%eax
             75 ab                   jne    ffffffff8113c5fe <ring_buffer_lock_reserve+0x1e>
             09 c8                   or     %ecx,%eax
             65 89 05 24 36 ed 7e    mov    %eax,%gs:0x7eed3624(%rip)        # fc80 <current_context>
      
      The arrow is the fast path.
      
      After adding the unlikely's, the fast path looks a bit better:
      
       <ring_buffer_lock_reserve>:
             31 c0                   xor    %eax,%eax
             48 83 3d 76 47 bd 00    cmpq   $0x1,0xbd4776(%rip)        # ffffffff81d10d60 <ring_buffer_flags>
             01
             55                      push   %rbp
             48 89 e5                mov    %rsp,%rbp
             75 7b                   jne    ffffffff8113c66b <ring_buffer_lock_reserve+0x8b>
             65 ff 05 69 e3 ec 7e    incl   %gs:0x7eece369(%rip)        # a960 <__preempt_count>
             8b 47 08                mov    0x8(%rdi),%eax
             85 c0                   test   %eax,%eax
             0f 85 9f 00 00 00       jne    ffffffff8113c6a1 <ring_buffer_lock_reserve+0xc1>
             65 8b 0d 57 e3 ec 7e    mov    %gs:0x7eece357(%rip),%ecx        # a960 <__preempt_count>
             81 e1 ff ff ff 7f       and    $0x7fffffff,%ecx
             b0 08                   mov    $0x8,%al
             65 8b 15 68 36 ed 7e    mov    %gs:0x7eed3668(%rip),%edx        # fc80 <current_context>
             f7 c1 00 ff 1f 00       test   $0x1fff00,%ecx
             75 50                   jne    ffffffff8113c670 <ring_buffer_lock_reserve+0x90>
             85 d0                   test   %edx,%eax
             75 7d                   jne    ffffffff8113c6a1 <ring_buffer_lock_reserve+0xc1>
             09 d0                   or     %edx,%eax
             65 89 05 53 36 ed 7e    mov    %eax,%gs:0x7eed3653(%rip)        # fc80 <current_context>
             65 8b 05 fc da ec 7e    mov    %gs:0x7eecdafc(%rip),%eax        # a130 <cpu_number>
             89 c2                   mov    %eax,%edx
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ac4e03df
    • Paul Burton's avatar
      MIPS: Disable preemption during prctl(PR_SET_FP_MODE, ...) · daf7322b
      Paul Burton authored
      [ Upstream commit bd239f1e ]
      
      Whilst a PR_SET_FP_MODE prctl is performed there are decisions made
      based upon whether the task is executing on the current CPU. This may
      change if we're preempted, so disable preemption to avoid such changes
      for the lifetime of the mode switch.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Fixes: 9791554b ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
      Reviewed-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
      Tested-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: stable <stable@vger.kernel.org> # v4.0+
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13144/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      daf7322b
    • Maciej W. Rozycki's avatar
      MIPS: ptrace: Prevent writes to read-only FCSR bits · 49dc90fd
      Maciej W. Rozycki authored
      [ Upstream commit abf378be ]
      
      Correct the cases missed with commit 9b26616c ("MIPS: Respect the
      ISA level in FCSR handling") and prevent writes to read-only FCSR bits
      there.
      
      This in particular applies to FP context initialisation where any IEEE
      754-2008 bits preset by `mips_set_personality_nan' are cleared before
      the relevant ptrace(2) call takes effect and the PTRACE_POKEUSR request
      addressing FPC_CSR where no masking of read-only FCSR bits is done.
      
      Remove the FCSR clearing from FP context initialisation then and unify
      PTRACE_POKEUSR/FPC_CSR and PTRACE_SETFPREGS handling, by factoring out
      code from `ptrace_setfpregs' and calling it from both places.
      
      This mostly matters to soft float configurations where the emulator can
      be switched this way to a mode which should not be accessible and cannot
      be set with the CTC1 instruction.  With hard float configurations any
      effect is transient anyway as read-only bits will retain their values at
      the time the FP context is restored.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
      Cc: stable@vger.kernel.org # v4.0+
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13239/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      49dc90fd
    • Maciej W. Rozycki's avatar
      MIPS: ptrace: Fix FP context restoration FCSR regression · ba1ccd8e
      Maciej W. Rozycki authored
      [ Upstream commit 42495484 ]
      
      Fix a floating-point context restoration regression introduced with
      commit 9b26616c ("MIPS: Respect the ISA level in FCSR handling")
      that causes a Floating Point exception and consequently a kernel oops
      with hard float configurations when one or more FCSR Enable and their
      corresponding Cause bits are set both at a time via a ptrace(2) call.
      
      To do so reinstate Cause bit masking originally introduced with commit
      b1442d39 ("MIPS: Prevent user from setting FCSR cause bits") to
      address this exact problem and then inadvertently removed from the
      PTRACE_SETFPREGS request with the commit referred above.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
      Cc: stable@vger.kernel.org # v4.0+
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13238/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ba1ccd8e
    • Paul Burton's avatar
      MIPS: math-emu: Fix jalr emulation when rd == $0 · fc39f274
      Paul Burton authored
      [ Upstream commit ab4a92e6 ]
      
      When emulating a jalr instruction with rd == $0, the code in
      isBranchInstr was incorrectly writing to GPR $0 which should actually
      always remain zeroed. This would lead to any further instructions
      emulated which use $0 operating on a bogus value until the task is next
      context switched, at which point the value of $0 in the task context
      would be restored to the correct zero by a store in SAVE_SOME. Fix this
      by not writing to rd if it is $0.
      
      Fixes: 102cedc3 ("MIPS: microMIPS: Floating point support.")
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Maciej W. Rozycki <macro@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable <stable@vger.kernel.org> # v3.10
      Patchwork: https://patchwork.linux-mips.org/patch/13160/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      fc39f274
    • James Hogan's avatar
      MIPS: Fix uapi include in exported asm/siginfo.h · 4a16f41b
      James Hogan authored
      [ Upstream commit 987e5b83 ]
      
      Since commit 8cb48fe1 ("MIPS: Provide correct siginfo_t.si_stime"),
      MIPS' uapi/asm/siginfo.h has included uapi/asm-generic/siginfo.h
      directly before defining MIPS' struct siginfo, in order to get the
      necessary definitions needed for the siginfo struct without the generic
      copy_siginfo() hitting compiler errors due to struct siginfo not yet
      being defined.
      
      Now that the generic copy_siginfo() is moved out to linux/signal.h we
      can safely include asm-generic/siginfo.h before defining the MIPS
      specific struct siginfo, which avoids the uapi/ include as well as
      breakage due to generic copy_siginfo() being defined before struct
      siginfo.
      Reported-by: default avatarChristopher Ferris <cferris@google.com>
      Fixes: 8cb48fe1 ("MIPS: Provide correct siginfo_t.si_stime")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Petr Malat <oss@malat.biz>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 4.0-
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4a16f41b
    • James Hogan's avatar
      SIGNAL: Move generic copy_siginfo() to signal.h · 175c6485
      James Hogan authored
      [ Upstream commit ca9eb49a ]
      
      The generic copy_siginfo() is currently defined in
      asm-generic/siginfo.h, after including uapi/asm-generic/siginfo.h which
      defines the generic struct siginfo. However this makes it awkward for an
      architecture to use it if it has to define its own struct siginfo (e.g.
      MIPS and potentially IA64), since it means that asm-generic/siginfo.h
      can only be included after defining the arch-specific siginfo, which may
      be problematic if the arch-specific definition needs definitions from
      uapi/asm-generic/siginfo.h.
      
      It is possible to work around this by first including
      uapi/asm-generic/siginfo.h to get the constants before defining the
      arch-specific siginfo, and include asm-generic/siginfo.h after. However
      uapi headers can't be included by other uapi headers, so that first
      include has to be in an ifdef __kernel__, with the non __kernel__ case
      including the non-UAPI header instead.
      
      Instead of that mess, move the generic copy_siginfo() definition into
      linux/signal.h, which allows an arch-specific uapi/asm/siginfo.h to
      include asm-generic/siginfo.h and define the arch-specific siginfo, and
      for the generic copy_siginfo() to see that arch-specific definition.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Petr Malat <oss@malat.biz>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Christopher Ferris <cferris@google.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: <stable@vger.kernel.org> # 4.0-
      Patchwork: https://patchwork.linux-mips.org/patch/12478/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      175c6485
    • Paul Burton's avatar
      MIPS: Sync icache & dcache in set_pte_at · de444b25
      Paul Burton authored
      [ Upstream commit 37d22a0d ]
      
      It's possible for pages to become visible prior to update_mmu_cache
      running if a thread within the same address space preempts the current
      thread or runs simultaneously on another CPU. That is, the following
      scenario is possible:
      
          CPU0                            CPU1
      
          write to page
          flush_dcache_page
          flush_icache_page
          set_pte_at
                                          map page
          update_mmu_cache
      
      If CPU1 maps the page in between CPU0's set_pte_at, which marks it valid
      & visible, and update_mmu_cache where the dcache flush occurs then CPU1s
      icache will fill from stale data (unless it fills from the dcache, in
      which case all is good, but most MIPS CPUs don't have this property).
      Commit 4d46a67a ("MIPS: Fix race condition in lazy cache flushing.")
      attempted to fix that by performing the dcache flush in
      flush_icache_page such that it occurs before the set_pte_at call makes
      the page visible. However it has the problem that not all code that
      writes to pages exposed to userland call flush_icache_page. There are
      many callers of set_pte_at under mm/ and only 2 of them do call
      flush_icache_page. Thus the race window between a page becoming visible
      & being coherent between the icache & dcache remains open in some cases.
      
      To illustrate some of the cases, a WARN was added to __update_cache with
      this patch applied that triggered in cases where a page about to be
      flushed from the dcache was not the last page provided to
      flush_icache_page. That is, backtraces were obtained for cases in which
      the race window is left open without this patch. The 2 standout examples
      follow.
      
      When forking a process:
      
      [   15.271842] [<80417630>] __update_cache+0xcc/0x188
      [   15.277274] [<80530394>] copy_page_range+0x56c/0x6ac
      [   15.282861] [<8042936c>] copy_process.part.54+0xd40/0x17ac
      [   15.289028] [<80429f80>] do_fork+0xe4/0x420
      [   15.293747] [<80413808>] handle_sys+0x128/0x14c
      
      When exec'ing an ELF binary:
      
      [   14.445964] [<80417630>] __update_cache+0xcc/0x188
      [   14.451369] [<80538d88>] move_page_tables+0x414/0x498
      [   14.457075] [<8055d848>] setup_arg_pages+0x220/0x318
      [   14.462685] [<805b0f38>] load_elf_binary+0x530/0x12a0
      [   14.468374] [<8055ec3c>] search_binary_handler+0xbc/0x214
      [   14.474444] [<8055f6c0>] do_execveat_common+0x43c/0x67c
      [   14.480324] [<8055f938>] do_execve+0x38/0x44
      [   14.485137] [<80413808>] handle_sys+0x128/0x14c
      
      These code paths write into a page, call flush_dcache_page then call
      set_pte_at without flush_icache_page inbetween. The end result is that
      the icache can become corrupted & userland processes may execute
      unexpected or invalid code, typically resulting in a reserved
      instruction exception, a trap or a segfault.
      
      Fix this race condition fully by performing any cache maintenance
      required to keep the icache & dcache in sync in set_pte_at, before the
      page is made valid. This has the added bonus of ensuring the cache
      maintenance always happens in one location, rather than being duplicated
      in flush_icache_page & update_mmu_cache. It also matches the way other
      architectures solve the same problem (see arm, ia64 & powerpc).
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Reported-by: default avatarIonela Voinescu <ionela.voinescu@imgtec.com>
      Cc: Lars Persson <lars.persson@axis.com>
      Fixes: 4d46a67a ("MIPS: Fix race condition in lazy cache flushing.")
      Cc: Steven J. Hill <sjhill@realitydiluted.com>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable <stable@vger.kernel.org> # v4.1+
      Patchwork: https://patchwork.linux-mips.org/patch/12722/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      de444b25
    • Paul Burton's avatar
      MIPS: Handle highmem pages in __update_cache · 8c99d761
      Paul Burton authored
      [ Upstream commit f4281bba ]
      
      The following patch will expose __update_cache to highmem pages. Handle
      them by mapping them in for the duration of the cache maintenance, just
      like in __flush_dcache_page. The code for that isn't shared because we
      need the page address in __update_cache so sharing became messy. Given
      that the entirity is an extra 5 lines, just duplicate it.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Lars Persson <lars.persson@axis.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable <stable@vger.kernel.org> # v4.1+
      Patchwork: https://patchwork.linux-mips.org/patch/12721/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      8c99d761
    • Paul Burton's avatar
      MIPS: Flush highmem pages in __flush_dcache_page · e7c735b0
      Paul Burton authored
      [ Upstream commit 234859e4 ]
      
      When flush_dcache_page is called on an executable page, that page is
      about to be provided to userland & we can presume that the icache
      contains no valid entries for its address range. However if the icache
      does not fill from the dcache then we cannot presume that the pages
      content has been written back as far as the memories that the dcache
      will fill from (ie. L2 or further out).
      
      This was being done for lowmem pages, but not for highmem which can lead
      to icache corruption. Fix this by mapping highmem pages & flushing their
      content from the dcache in __flush_dcache_page before providing the page
      to userland, just as is done for lowmem pages.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Lars Persson <lars.persson@axis.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/12720/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e7c735b0
    • Guilherme G. Piccoli's avatar
      Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell" · deee8f00
      Guilherme G. Piccoli authored
      [ Upstream commit c2078d9e ]
      
      This reverts commit 89a51df5.
      
      The function eeh_add_device_early() is used to perform EEH
      initialization in devices added later on the system, like in
      hotplug/DLPAR scenarios. Since the commit 89a51df5 ("powerpc/eeh:
      Fix crash in eeh_add_device_early() on Cell") a new check was introduced
      in this function - Cell has no EEH capabilities which led to kernel oops
      if hotplug was performed, so checking for eeh_enabled() was introduced
      to avoid the issue.
      
      However, in architectures that EEH is present like pSeries or PowerNV,
      we might reach a case in which no PCI devices are present on boot time
      and so EEH is not initialized. Then, if a device is added via DLPAR for
      example, eeh_add_device_early() fails because eeh_enabled() is false,
      and EEH end up not being enabled at all.
      
      This reverts the aforementioned patch since a new verification was
      introduced by the commit d91dafc0 ("powerpc/eeh: Delay probing EEH
      device during hotplug") and so the original Cell issue does not happen
      anymore.
      
      Cc: stable@vger.kernel.org # v4.1+
      Reviewed-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      deee8f00
    • Gavin Shan's avatar
      powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover() · 75d03a9e
      Gavin Shan authored
      [ Upstream commit 5a0cdbfd ]
      
      The function eeh_pe_reset_and_recover() is used to recover EEH
      error when the passthrou device are transferred to guest and
      backwards. The content in the device's config space will be lost
      on PE reset issued in the middle of the recovery. The function
      saves/restores it before/after the reset. However, config access
      to some adapters like Broadcom BCM5719 at this point will causes
      fenced PHB. The config space is always blocked and we save 0xFF's
      that are restored at late point. The memory BARs are totally
      corrupted, causing another EEH error upon access to one of the
      memory BARs.
      
      This restores the config space on those adapters like BCM5719
      from the content saved to the EEH device when it's populated,
      to resolve above issue.
      
      Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
      Cc: stable@vger.kernel.org #v3.18+
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      75d03a9e
    • Gavin Shan's avatar
      powerpc/eeh: Don't report error in eeh_pe_reset_and_recover() · b7ccd2a2
      Gavin Shan authored
      [ Upstream commit affeb0f2 ]
      
      The function eeh_pe_reset_and_recover() is used to recover EEH
      error when the passthrough device are transferred to guest and
      backwards, meaning the device's driver is vfio-pci or none.
      When the driver is vfio-pci that provides error_detected() error
      handler only, the handler simply stops the guest and it's not
      expected behaviour. On the other hand, no error handlers will
      be called if we don't have a bound driver.
      
      This ignores the error handler in eeh_pe_reset_and_recover()
      that reports the error to device driver to avoid the exceptional
      behaviour.
      
      Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
      Cc: stable@vger.kernel.org #v3.18+
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b7ccd2a2
    • Sasha Levin's avatar
      sched/loadavg: Fix loadavg artifacts on fully idle and on fully loaded systems · 18fc6569
      Sasha Levin authored
      [ Upstream commit 20878232 ]
      
      Systems show a minimal load average of 0.00, 0.01, 0.05 even when they
      have no load at all.
      
      Uptime and /proc/loadavg on all systems with kernels released during the
      last five years up until kernel version 4.6-rc5, show a 5- and 15-minute
      minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on
      idle systems, but the way the kernel calculates this value prevents it
      from getting lower than the mentioned values.
      
      Likewise but not as obviously noticeable, a fully loaded system with no
      processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99, 0.95
      (multiplied by number of cores).
      
      Once the (old) load becomes 93 or higher, it mathematically can never
      get lower than 93, even when the active (load) remains 0 forever.
      This results in the strange 0.00, 0.01, 0.05 uptime values on idle
      systems.  Note: 93/2048 = 0.0454..., which rounds up to 0.05.
      
      It is not correct to add a 0.5 rounding (=1024/2048) here, since the
      result from this function is fed back into the next iteration again,
      so the result of that +0.5 rounding value then gets multiplied by
      (2048-2037), and then rounded again, so there is a virtual "ghost"
      load created, next to the old and active load terms.
      
      By changing the way the internally kept value is rounded, that internal
      value equivalent now can reach 0.00 on idle, and 1.00 on full load. Upon
      increasing load, the internally kept load value is rounded up, when the
      load is decreasing, the load value is rounded down.
      
      The modified code was tested on nohz=off and nohz kernels. It was tested
      on vanilla kernel 4.6-rc5 and on centos 7.1 kernel 3.10.0-327. It was
      tested on single, dual, and octal cores system. It was tested on virtual
      hosts and bare hardware. No unwanted effects have been observed, and the
      problems that the patch intended to fix were indeed gone.
      Tested-by: default avatarDamien Wyart <damien.wyart@free.fr>
      Signed-off-by: default avatarVik Heyndrickx <vik.heyndrickx@veribox.net>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: <stable@vger.kernel.org>
      Cc: Doug Smythies <dsmythies@telus.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 0f004f5a ("sched: Cure more NO_HZ load average woes")
      Link: http://lkml.kernel.org/r/e8d32bff-d544-7748-72b5-3c86cc71f09f@veribox.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      18fc6569
    • Sasha Levin's avatar
      rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring · fa5c124f
      Sasha Levin authored
      [ Upstream commit cf968937 ]
      
      We can't use kfree_skb in irq disable context, because spin_lock_irqsave
      make sure we are always in irq disable context, use dev_kfree_skb_irq
      instead of kfree_skb is better than dev_kfree_skb_any.
      
      This patch fix below kernel warning:
      [ 7612.095528] ------------[ cut here ]------------
      [ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 __local_bh_enable_ip+0x58/0x80()
      [ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist rtl_pci rtlwifi rtl8723_common
      [ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: G        W       4.4.0+ #4
      [ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 ) 08/27/2015
      [ 7612.095574]  00000000 00000000 da37fc70 c12ce7c5 00000000 da37fca0 c104cc59 c19d4454
      [ 7612.095584]  00000003 0000116c c19d4784 00000096 c10508a8 c10508a8 00000200 c1b42400
      [ 7612.095594]  f29be780 da37fcb0 c104ccad 00000009 00000000 da37fcbc c10508a8 f21f08b8
      [ 7612.095604] Call Trace:
      [ 7612.095614]  [<c12ce7c5>] dump_stack+0x41/0x5c
      [ 7612.095620]  [<c104cc59>] warn_slowpath_common+0x89/0xc0
      [ 7612.095628]  [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
      [ 7612.095634]  [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
      [ 7612.095640]  [<c104ccad>] warn_slowpath_null+0x1d/0x20
      [ 7612.095646]  [<c10508a8>] __local_bh_enable_ip+0x58/0x80
      [ 7612.095653]  [<c16b7d34>] destroy_conntrack+0x64/0xa0
      [ 7612.095660]  [<c16b300f>] nf_conntrack_destroy+0xf/0x20
      [ 7612.095665]  [<c1677565>] skb_release_head_state+0x55/0xa0
      [ 7612.095670]  [<c16775bb>] skb_release_all+0xb/0x20
      [ 7612.095674]  [<c167760b>] __kfree_skb+0xb/0x60
      [ 7612.095679]  [<c16776f0>] kfree_skb+0x30/0x70
      [ 7612.095686]  [<f81b869d>] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
      [ 7612.095692]  [<f81b869d>] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
      [ 7612.095698]  [<f81b87f9>] rtl_pci_start+0x19/0x190 [rtl_pci]
      [ 7612.095705]  [<f81970e6>] rtl_op_start+0x56/0x90 [rtlwifi]
      [ 7612.095712]  [<c17e3f16>] drv_start+0x36/0xc0
      [ 7612.095717]  [<c17f5ab3>] ieee80211_do_open+0x2d3/0x890
      [ 7612.095725]  [<c16820fe>] ? call_netdevice_notifiers_info+0x2e/0x60
      [ 7612.095730]  [<c17f60bd>] ieee80211_open+0x4d/0x50
      [ 7612.095736]  [<c16891b3>] __dev_open+0xa3/0x130
      [ 7612.095742]  [<c183fa53>] ? _raw_spin_unlock_bh+0x13/0x20
      [ 7612.095748]  [<c1689499>] __dev_change_flags+0x89/0x140
      [ 7612.095753]  [<c127c70d>] ? selinux_capable+0xd/0x10
      [ 7612.095759]  [<c1689589>] dev_change_flags+0x29/0x60
      [ 7612.095765]  [<c1700b93>] devinet_ioctl+0x553/0x670
      [ 7612.095772]  [<c12db758>] ? _copy_to_user+0x28/0x40
      [ 7612.095777]  [<c17018b5>] inet_ioctl+0x85/0xb0
      [ 7612.095783]  [<c166e647>] sock_ioctl+0x67/0x260
      [ 7612.095788]  [<c166e5e0>] ? sock_fasync+0x80/0x80
      [ 7612.095795]  [<c115c99b>] do_vfs_ioctl+0x6b/0x550
      [ 7612.095800]  [<c127c812>] ? selinux_file_ioctl+0x102/0x1e0
      [ 7612.095807]  [<c10a8914>] ? timekeeping_suspend+0x294/0x320
      [ 7612.095813]  [<c10a256a>] ? __hrtimer_run_queues+0x14a/0x210
      [ 7612.095820]  [<c1276e24>] ? security_file_ioctl+0x34/0x50
      [ 7612.095827]  [<c115cef0>] SyS_ioctl+0x70/0x80
      [ 7612.095832]  [<c1001804>] do_fast_syscall_32+0x84/0x120
      [ 7612.095839]  [<c183ff91>] sysenter_past_esp+0x36/0x55
      [ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---
      Signed-off-by: default avatarWang YanQing <udknight@gmail.com>
      Cc: Stable <stable@vger.kernel.org>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      fa5c124f