1. 01 Jun, 2016 38 commits
    • Jiri Slaby's avatar
      Bluetooth: vhci: purge unhandled skbs · 3295bfd3
      Jiri Slaby authored
      commit 13407376 upstream.
      
      The write handler allocates skbs and queues them into data->readq.
      Read side should read them, if there is any. If there is none, skbs
      should be dropped by hdev->flush. But this happens only if the device
      is HCI_UP, i.e. hdev->power_on work was triggered already. When it was
      not, skbs stay allocated in the queue when /dev/vhci is closed. So
      purge the queue in ->release.
      
      Program to reproduce:
      	#include <err.h>
      	#include <fcntl.h>
      	#include <stdio.h>
      	#include <unistd.h>
      
      	#include <sys/stat.h>
      	#include <sys/types.h>
      	#include <sys/uio.h>
      
      	int main()
      	{
      		char buf[] = { 0xff, 0 };
      		struct iovec iov = {
      			.iov_base = buf,
      			.iov_len = sizeof(buf),
      		};
      		int fd;
      
      		while (1) {
      			fd = open("/dev/vhci", O_RDWR);
      			if (fd < 0)
      				err(1, "open");
      
      			usleep(50);
      
      			if (writev(fd, &iov, 1) < 0)
      				err(1, "writev");
      
      			usleep(50);
      
      			close(fd);
      		}
      
      		return 0;
      	}
      
      Result:
      kmemleak: 4609 new suspected memory leaks
      unreferenced object 0xffff88059f4d5440 (size 232):
        comm "vhci", pid 1084, jiffies 4294912542 (age 37569.296s)
        hex dump (first 32 bytes):
          20 f0 23 87 05 88 ff ff 20 f0 23 87 05 88 ff ff   .#..... .#.....
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
      ...
          [<ffffffff81ece010>] __alloc_skb+0x0/0x5a0
          [<ffffffffa021886c>] vhci_create_device+0x5c/0x580 [hci_vhci]
          [<ffffffffa0219436>] vhci_write+0x306/0x4c8 [hci_vhci]
      
      Fixes: 23424c0d (Bluetooth: Add support creating virtual AMP controllers)
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3295bfd3
    • Jiri Slaby's avatar
      Bluetooth: vhci: fix open_timeout vs. hdev race · 1af4f24c
      Jiri Slaby authored
      commit 373a32c8 upstream.
      
      Both vhci_get_user and vhci_release race with open_timeout work. They
      both contain cancel_delayed_work_sync, but do not test whether the
      work actually created hdev or not. Since the work can be in progress
      and _sync will wait for finishing it, we can have data->hdev allocated
      when cancel_delayed_work_sync returns. But the call sites do 'if
      (data->hdev)' *before* cancel_delayed_work_sync.
      
      As a result:
      * vhci_get_user allocates a second hdev and puts it into
        data->hdev. The former is leaked.
      * vhci_release does not release data->hdev properly as it thinks there
        is none.
      
      Fix both cases by moving the actual test *after* the call to
      cancel_delayed_work_sync.
      
      This can be hit by this program:
      	#include <err.h>
      	#include <fcntl.h>
      	#include <stdio.h>
      	#include <stdlib.h>
      	#include <time.h>
      	#include <unistd.h>
      
      	#include <sys/stat.h>
      	#include <sys/types.h>
      
      	int main(int argc, char **argv)
      	{
      		int fd;
      
      		srand(time(NULL));
      
      		while (1) {
      			const int delta = (rand() % 200 - 100) * 100;
      
      			fd = open("/dev/vhci", O_RDWR);
      			if (fd < 0)
      				err(1, "open");
      
      			usleep(1000000 + delta);
      
      			close(fd);
      		}
      
      		return 0;
      	}
      
      And the result is:
      BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr ffff88006b0c1228
      Read of size 8 by task kworker/u13:1/32068
      =============================================================================
      BUG kmalloc-192 (Tainted: G            E     ): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040
      ...
      	kmem_cache_alloc_trace+0x150/0x190
      	vhci_open+0x50/0x330 [hci_vhci]
      	misc_open+0x35b/0x4e0
      	chrdev_open+0x23b/0x510
      ...
      INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040
      ...
      	__slab_free+0x204/0x310
      	vhci_release+0xa4/0xd0 [hci_vhci]
      ...
      INFO: Slab 0xffffea0001ac3000 objects=16 used=13 fp=0xffff88006b0c1e00 flags=0x5fffff80004080
      INFO: Object 0xffff88006b0c1200 @offset=4608 fp=0xffff88006b0c0600
      Bytes b4 ffff88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00  ...k............
      Object ffff88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff  ...k.......k....
      Object ffff88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff  .F.k.....F.k....
      Object ffff88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00  ................
      Object ffff88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff  @..k....@..k....
      Object ffff88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de  P.n.............
      Object ffff88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00  .........b......
      Object ffff88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff  ........8..k....
      Object ffff88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00  .. .............
      Object ffff88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff  ...........=....
      Object ffff88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00  . ..............
      Redzone ffff88006b0c12c0: bb bb bb bb bb bb bb bb                          ........
      Padding ffff88006b0c13f8: 00 00 00 00 00 00 00 00                          ........
      CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: G    B       E      4.4.6-0-default #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
      Workqueue: hci0 hci_cmd_work [bluetooth]
       00000000ffffffff ffffffff81926cfa ffff88006be37c68 ffff88006bc27180
       ffff88006b0c1200 ffff88006b0c1234 ffffffff81577993 ffffffff82489320
       ffff88006bc24240 0000000000000046 ffff88006a100000 000000026e51eb80
      Call Trace:
      ...
       [<ffffffff81ec8ebe>] ? skb_queue_tail+0x13e/0x150
       [<ffffffffa06e027c>] ? vhci_send_frame+0xac/0x100 [hci_vhci]
       [<ffffffffa0c61268>] ? hci_send_frame+0x188/0x320 [bluetooth]
       [<ffffffffa0c61515>] ? hci_cmd_work+0x115/0x310 [bluetooth]
       [<ffffffff811a1375>] ? process_one_work+0x815/0x1340
       [<ffffffff811a1f85>] ? worker_thread+0xe5/0x11f0
       [<ffffffff811a1ea0>] ? process_one_work+0x1340/0x1340
       [<ffffffff811b3c68>] ? kthread+0x1c8/0x230
      ...
      Memory state around the buggy address:
       ffff88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                        ^
       ffff88006b0c1280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff88006b0c1300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      
      Fixes: 23424c0d (Bluetooth: Add support creating virtual AMP controllers)
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1af4f24c
    • Adrian Hunter's avatar
      mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers · 7973b064
      Adrian Hunter authored
      commit 82296936 upstream.
      
      The CMD19/CMD14 bus width test has been found to be unreliable in
      some cases.  It is not essential, so simply remove it.
      Signed-off-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>
      7973b064
    • Matt Gumbel's avatar
      mmc: longer timeout for long read time quirk · 32971328
      Matt Gumbel authored
      commit 32ecd320 upstream.
      
      008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
      MMC_SEND_EXT_CSD in 450-600ms.
      
      This patch will...
      
      () Increase the long read time quirk timeout from 300ms to 600ms. Original
         author of that quirk says 300ms was only a guess and that the number
         may need to be raised in the future.
      
      () Add this specific MMC to the quirk
      Signed-off-by: default avatarMatt Gumbel <matthew.k.gumbel@intel.com>
      Signed-off-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>
      32971328
    • Gabriele Mazzotta's avatar
      dell-rbtn: Ignore ACPI notifications if device is suspended · 96cd084c
      Gabriele Mazzotta authored
      commit ff865123 upstream.
      
      Some BIOSes unconditionally send an ACPI notification to RBTN when the
      system is resuming from suspend. This makes dell-rbtn send an input
      event to userspace as if a function key was pressed. Prevent this by
      ignoring all the notifications received while the device is suspended.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=106031Signed-off-by: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Tested-by: default avatarAlex Hung <alex.hung@canonical.com>
      Reviewed-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96cd084c
    • Lv Zheng's avatar
      ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings · 419b1d21
      Lv Zheng authored
      commit 30c9bb0d upstream.
      
      The order of the _OSI related functionalities is as follows:
      
        acpi_blacklisted()
          acpi_dmi_osi_linux()
            acpi_osi_setup()
          acpi_osi_setup()
            acpi_update_interfaces() if "!*"
            <<<<<<<<<<<<<<<<<<<<<<<<
        parse_args()
          __setup("acpi_osi=")
            acpi_osi_setup_linux()
              acpi_update_interfaces() if "!*"
              <<<<<<<<<<<<<<<<<<<<<<<<
        acpi_early_init()
          acpi_initialize_subsystem()
            acpi_ut_initialize_interfaces()
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        acpi_bus_init()
          acpi_os_initialize1()
            acpi_install_interface_handler(acpi_osi_handler)
            acpi_osi_setup_late()
              acpi_update_interfaces() for "!"
              >>>>>>>>>>>>>>>>>>>>>>>>
        acpi_osi_handler()
      
      Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command
      line setting can override the DMI detection. That's why acpi_blacklisted()
      is put before __setup("acpi_osi=").
      
      Then we can notice the following wrong invocation order. There are
      acpi_update_interfaces() (marked by <<<<) calls invoked before
      acpi_ut_initialize_interfaces() (marked by ^^^^). This makes it impossible
      to use acpi_osi=!* correctly from OSI DMI table or from the command line.
      The use of acpi_osi=!* is meant to disable both ACPICA
      (acpi_gbl_supported_interfaces) and Linux specific strings
      (osi_setup_entries) while the ACPICA part should have stopped working
      because of the order issue.
      
      This patch fixes this issue by moving acpi_update_interfaces() to where
      it is invoked for acpi_osi=! (marked by >>>>) as this is ensured to be
      invoked after acpi_ut_initialize_interfaces() (marked by ^^^^). Linux
      specific strings are still handled in the original place in order to make
      the following command line working: acpi_osi=!* acpi_osi="Module Device".
      
      Note that since acpi_osi=!* is meant to further disable linux specific
      string comparing to the acpi_osi=!, there is no such use case in our bug
      fixing work and hence there is no one using acpi_osi=!* either from the
      command line or from the DMI quirks, this issue is just a theoretical
      issue.
      
      Fixes: 741d8128 (ACPI: Add facility to remove all _OSI strings)
      Tested-by: default avatarLukas Wunner <lukas@wunner.de>
      Tested-by: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      419b1d21
    • Adrian Hunter's avatar
      mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers · bb2b58c7
      Adrian Hunter authored
      commit 265984b3 upstream.
      
      The CMD19/CMD14 bus width test has been found to be unreliable in
      some cases.  It is not essential, so simply remove it.
      Signed-off-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>
      bb2b58c7
    • Adrian Hunter's avatar
      mmc: mmc: Fix partition switch timeout for some eMMCs · 98b0125d
      Adrian Hunter authored
      commit 1c447116 upstream.
      
      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.
      Signed-off-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>
      98b0125d
    • Oliver Hartkopp's avatar
      can: fix handling of unmodifiable configuration options · 24bf50bc
      Oliver Hartkopp authored
      commit bb208f14 upstream.
      
      As described in 'can: m_can: tag current CAN FD controllers as non-ISO'
      (6cfda7fb) it is possible to define fixed configuration options by
      setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'.
      This leads to the incovenience that the fixed configuration bits can not be
      passed by netlink even when they have the correct values (e.g. non-ISO, FD).
      
      This patch fixes that issue and not only allows fixed set bit values to be set
      again but now requires(!) to provide these fixed values at configuration time.
      A valid CAN FD configuration consists of a nominal/arbitration bittiming, a
      data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now
      enforced by a new can_validate() function. This fix additionally removed the
      inconsistency that was prohibiting the support of 'CANFD-only' controller
      drivers, like the RCar CAN FD.
      
      For this reason a new helper can_set_static_ctrlmode() has been introduced to
      provide a proper interface to handle static enabled CAN controller options.
      Reported-by: default avatarRamesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Reviewed-by: default avatarRamesh Shanmugasundaram  <ramesh.shanmugasundaram@bp.renesas.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24bf50bc
    • Marc Zyngier's avatar
      irqchip/gic-v3: Configure all interrupts as non-secure Group-1 · 9b68f12b
      Marc Zyngier authored
      commit 7c9b9730 upstream.
      
      The GICv3 driver wrongly assumes that it runs on the non-secure
      side of a secure-enabled system, while it could be on a system
      with a single security state, or a GICv3 with GICD_CTLR.DS set.
      
      Either way, it is important to configure this properly, or
      interrupts will simply not be delivered on this HW.
      Reported-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Tested-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b68f12b
    • Will Deacon's avatar
      irqchip/gic: Ensure ordering between read of INTACK and shared data · 3607d54e
      Will Deacon authored
      commit f86c4fbd upstream.
      
      When an IPI is generated by a CPU, the pattern looks roughly like:
      
        <write shared data>
        smp_wmb();
        <write to GIC to signal SGI>
      
      On the receiving CPU we rely on the fact that, once we've taken the
      interrupt, then the freshly written shared data must be visible to us.
      Put another way, the CPU isn't going to speculate taking an interrupt.
      
      Unfortunately, this assumption turns out to be broken.
      
      Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
      to read some shared_data. Before CPUx has done anything, a random
      peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
      CPUy then takes the IRQ and starts executing the entry code, heading
      towards gic_handle_irq. Furthermore, let's assume that a bunch of the
      previous interrupts handled by CPUy were SGIs, so the branch predictor
      kicks in and speculates that irqnr will be <16 and we're likely to
      head into handle_IPI. The prefetcher then grabs a speculative copy of
      shared_data which contains a stale value.
      
      Meanwhile, CPUx gets round to updating shared_data and asking the GIC
      to send an SGI to CPUy. Internally, the GIC decides that the SGI is
      more important than the peripheral interrupt (which hasn't yet been
      ACKed) but doesn't need to do anything to CPUy, because the IRQ line
      is already raised.
      
      CPUy then reads the ACK register on the GIC, sees the SGI value which
      confirms the branch prediction and we end up with a stale shared_data
      value.
      
      This patch fixes the problem by adding an smp_rmb() to the IPI entry
      code in gic_handle_irq. As it turns out, the combination of a control
      dependency and an ISB instruction from the EOI in the GICv3 driver is
      enough to provide the ordering we need, so we add a comment there
      justifying the absence of an explicit smp_rmb().
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3607d54e
    • Manfred Schlaegl's avatar
      Input: pwm-beeper - fix - scheduling while atomic · 02c23447
      Manfred Schlaegl authored
      commit f49cf3b8 upstream.
      
      Pwm config may sleep so defer it using a worker.
      
      On a Freescale i.MX53 based board we ran into "BUG: scheduling while
      atomic" because input_inject_event locks interrupts, but
      imx_pwm_config_v2 sleeps.
      
      Tested on Freescale i.MX53 SoC with 4.6.0.
      Signed-off-by: default avatarManfred Schlaegl <manfred.schlaegl@gmx.at>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02c23447
    • Roger Quadros's avatar
      mfd: omap-usb-tll: Fix scheduling while atomic BUG · c5215990
      Roger Quadros authored
      commit b49b927f upstream.
      
      We shouldn't be calling clk_prepare_enable()/clk_prepare_disable()
      in an atomic context.
      
      Fixes the following issue:
      
      [    5.830970] ehci-omap: OMAP-EHCI Host Controller driver
      [    5.830974] driver_register 'ehci-omap'
      [    5.895849] driver_register 'wl1271_sdio'
      [    5.896870] BUG: scheduling while atomic: udevd/994/0x00000002
      [    5.896876] 4 locks held by udevd/994:
      [    5.896904]  #0:  (&dev->mutex){......}, at: [<c049597c>] __driver_attach+0x60/0xac
      [    5.896923]  #1:  (&dev->mutex){......}, at: [<c049598c>] __driver_attach+0x70/0xac
      [    5.896946]  #2:  (tll_lock){+.+...}, at: [<c04c2630>] omap_tll_enable+0x2c/0xd0
      [    5.896966]  #3:  (prepare_lock){+.+...}, at: [<c05ce9c8>] clk_prepare_lock+0x48/0xe0
      [    5.897042] Modules linked in: wlcore_sdio(+) ehci_omap(+) dwc3_omap snd_soc_ts3a225e leds_is31fl319x bq27xxx_battery_i2c tsc2007 bq27xxx_battery bq2429x_charger ina2xx tca8418_keypad as5013 leds_tca6507 twl6040_vibra gpio_twl6040 bmp085_i2c(+) palmas_gpadc usb3503 palmas_pwrbutton bmg160_i2c(+) bmp085 bma150(+) bmg160_core bmp280 input_polldev snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap snd_pcm_dmaengine
      [    5.897048] Preemption disabled at:[<  (null)>]   (null)
      [    5.897051]
      [    5.897059] CPU: 0 PID: 994 Comm: udevd Not tainted 4.6.0-rc5-letux+ #233
      [    5.897062] Hardware name: Generic OMAP5 (Flattened Device Tree)
      [    5.897076] [<c010e714>] (unwind_backtrace) from [<c010af34>] (show_stack+0x10/0x14)
      [    5.897087] [<c010af34>] (show_stack) from [<c040aa7c>] (dump_stack+0x88/0xc0)
      [    5.897099] [<c040aa7c>] (dump_stack) from [<c020c558>] (__schedule_bug+0xac/0xd0)
      [    5.897111] [<c020c558>] (__schedule_bug) from [<c06f3d44>] (__schedule+0x88/0x7e4)
      [    5.897120] [<c06f3d44>] (__schedule) from [<c06f46d8>] (schedule+0x9c/0xc0)
      [    5.897129] [<c06f46d8>] (schedule) from [<c06f4904>] (schedule_preempt_disabled+0x14/0x20)
      [    5.897140] [<c06f4904>] (schedule_preempt_disabled) from [<c06f64e4>] (mutex_lock_nested+0x258/0x43c)
      [    5.897150] [<c06f64e4>] (mutex_lock_nested) from [<c05ce9c8>] (clk_prepare_lock+0x48/0xe0)
      [    5.897160] [<c05ce9c8>] (clk_prepare_lock) from [<c05d0e7c>] (clk_prepare+0x10/0x28)
      [    5.897169] [<c05d0e7c>] (clk_prepare) from [<c04c2668>] (omap_tll_enable+0x64/0xd0)
      [    5.897180] [<c04c2668>] (omap_tll_enable) from [<c04c1728>] (usbhs_runtime_resume+0x18/0x17c)
      [    5.897192] [<c04c1728>] (usbhs_runtime_resume) from [<c049d404>] (pm_generic_runtime_resume+0x2c/0x40)
      [    5.897202] [<c049d404>] (pm_generic_runtime_resume) from [<c049f180>] (__rpm_callback+0x38/0x68)
      [    5.897210] [<c049f180>] (__rpm_callback) from [<c049f220>] (rpm_callback+0x70/0x88)
      [    5.897218] [<c049f220>] (rpm_callback) from [<c04a0a00>] (rpm_resume+0x4ec/0x7ec)
      [    5.897227] [<c04a0a00>] (rpm_resume) from [<c04a0f48>] (__pm_runtime_resume+0x4c/0x64)
      [    5.897236] [<c04a0f48>] (__pm_runtime_resume) from [<c04958dc>] (driver_probe_device+0x30/0x70)
      [    5.897246] [<c04958dc>] (driver_probe_device) from [<c04959a4>] (__driver_attach+0x88/0xac)
      [    5.897256] [<c04959a4>] (__driver_attach) from [<c04940f8>] (bus_for_each_dev+0x50/0x84)
      [    5.897267] [<c04940f8>] (bus_for_each_dev) from [<c0494e40>] (bus_add_driver+0xcc/0x1e4)
      [    5.897276] [<c0494e40>] (bus_add_driver) from [<c0496914>] (driver_register+0xac/0xf4)
      [    5.897286] [<c0496914>] (driver_register) from [<c01018e0>] (do_one_initcall+0x100/0x1b8)
      [    5.897296] [<c01018e0>] (do_one_initcall) from [<c01c7a54>] (do_init_module+0x58/0x1c0)
      [    5.897304] [<c01c7a54>] (do_init_module) from [<c01c8a3c>] (SyS_finit_module+0x88/0x90)
      [    5.897313] [<c01c8a3c>] (SyS_finit_module) from [<c0107120>] (ret_fast_syscall+0x0/0x1c)
      [    5.912697] ------------[ cut here ]------------
      [    5.912711] WARNING: CPU: 0 PID: 994 at kernel/sched/core.c:2996 _raw_spin_unlock+0x28/0x58
      [    5.912717] DEBUG_LOCKS_WARN_ON(val > preempt_count())
      Reported-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Tested-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5215990
    • Vik Heyndrickx's avatar
      sched/loadavg: Fix loadavg artifacts on fully idle and on fully loaded systems · 1df73f18
      Vik Heyndrickx authored
      commit 20878232 upstream.
      
      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: 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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1df73f18
    • Andy Gross's avatar
      clk: qcom: msm8916: Fix crypto clock flags · aef53169
      Andy Gross authored
      commit 2a0974aa upstream.
      
      This patch adds the CLK_SET_RATE_PARENT flag for the crypto core and
      ahb blocks.  Without this flag, clk_set_rate can fail for certain
      frequency requests.
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      Fixes: 3966fab8 ("clk: qcom: Add MSM8916 Global Clock Controller support")
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aef53169
    • Corentin LABBE's avatar
      crypto: sun4i-ss - Replace spinlock_bh by spin_lock_irq{save|restore} · a80e1fbf
      Corentin LABBE authored
      commit bdb6cf9f upstream.
      
      The current sun4i-ss driver could generate data corruption when ciphering/deciphering.
      It occurs randomly on end of handled data.
      No root cause have been found and the only way to remove it is to replace
      all spin_lock_bh by their irq counterparts.
      
      Fixes: 6298e948 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
      Signed-off-by: default avatarLABBE Corentin <clabbe.montjoie@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a80e1fbf
    • Horia Geant?'s avatar
      crypto: talitos - fix ahash algorithms registration · efc1e73c
      Horia Geant? authored
      commit 3639ca84 upstream.
      
      Provide hardware state import/export functionality, as mandated by
      commit 8996eafd ("crypto: ahash - ensure statesize is non-zero")
      Reported-by: default avatarJonas Eymann <J.Eymann@gmx.net>
      Signed-off-by: default avatarHoria Geant? <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      efc1e73c
    • Catalin Vasile's avatar
      crypto: caam - fix caam_jr_alloc() ret code · fd97b4fb
      Catalin Vasile authored
      commit e930c765 upstream.
      
      caam_jr_alloc() used to return NULL if a JR device could not be
      allocated for a session. In turn, every user of this function used
      IS_ERR() function to verify if anything went wrong, which does NOT look
      for NULL values. This made the kernel crash if the sanity check failed,
      because the driver continued to think it had allocated a valid JR dev
      instance to the session and at some point it tries to do a caam_jr_free()
      on a NULL JR dev pointer.
      This patch is a fix for this issue.
      Signed-off-by: default avatarCatalin Vasile <cata.vasile@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd97b4fb
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Prevent overflow of size in ring_buffer_resize() · f1990231
      Steven Rostedt (Red Hat) authored
      commit 59643d15 upstream.
      
      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.
      
      Fixes: 83f40318 ("ring-buffer: Make removal of ring buffer pages atomic")
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1990231
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Use long for nr_pages to avoid overflow failures · dfb71aef
      Steven Rostedt (Red Hat) authored
      commit 9b94a8fb upstream.
      
      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
      
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfb71aef
    • John Stultz's avatar
      asix: Fix offset calculation in asix_rx_fixup() causing slow transmissions · 0e4d7a01
      John Stultz authored
      commit cd9e2e5d upstream.
      
      In testing with HiKey, we found that since
      commit 3f30b158 ("asix: On RX avoid creating bad Ethernet
      frames"),
      we're seeing lots of noise during network transfers:
      
      [  239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
      [  239.037310] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x54ebb5ec, offset 4
      [  239.045519] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xcdffe7a2, offset 4
      [  239.275044] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
      [  239.284355] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x1d36f59d, offset 4
      [  239.292541] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xaef3c1e9, offset 4
      [  239.518996] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
      [  239.528300] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x2881912, offset 4
      [  239.536413] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x5638f7e2, offset 4
      
      And network throughput ends up being pretty bursty and slow with
      a overall throughput of at best ~30kB/s (where as previously we
      got 1.1MB/s with the slower USB1.1 "full speed" host).
      
      We found the issue also was reproducible on a x86_64 system,
      using a "high-speed" USB2.0 port but the throughput did not
      measurably drop (possibly due to the scp transfer being cpu
      bound on my slow test hardware).
      
      After lots of debugging, I found the check added in the
      problematic commit seems to be calculating the offset
      incorrectly.
      
      In the normal case, in the main loop of the function, we do:
      (where offset is zero, or set to "offset += (copy_length + 1) &
      0xfffe" in the previous loop)
          rx->header = get_unaligned_le32(skb->data +
                                          offset);
          offset += sizeof(u32);
      
      But the problematic patch calculates:
          offset = ((rx->remaining + 1) & 0xfffe) + sizeof(u32);
          rx->header = get_unaligned_le32(skb->data + offset);
      
      Adding some debug logic to check those offset calculation used
      to find rx->header, the one in problematic code is always too
      large by sizeof(u32).
      
      Thus, this patch removes the incorrect " + sizeof(u32)" addition
      in the problematic calculation, and resolves the issue.
      
      Cc: Dean Jenkins <Dean_Jenkins@mentor.com>
      Cc: "David B. Robins" <linux@davidrobins.net>
      Cc: Mark Craske <Mark_Craske@mentor.com>
      Cc: Emil Goode <emilgoode@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: YongQin Liu <yongqin.liu@linaro.org>
      Cc: Guodong Xu <guodong.xu@linaro.org>
      Cc: Ivan Vecera <ivecera@redhat.com>
      Cc: linux-usb@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Reported-by: default avatarYongqin Liu <yongqin.liu@linaro.org>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e4d7a01
    • Stefan Metzmacher's avatar
      fs/cifs: correctly to anonymous authentication for the NTLM(v2) authentication · 6b83512b
      Stefan Metzmacher authored
      commit 1a967d6c upstream.
      
      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>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b83512b
    • Stefan Metzmacher's avatar
      fs/cifs: correctly to anonymous authentication for the NTLM(v1) authentication · 0e5e5bfd
      Stefan Metzmacher authored
      commit 777f69b8 upstream.
      
      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>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e5e5bfd
    • Stefan Metzmacher's avatar
      fs/cifs: correctly to anonymous authentication for the LANMAN authentication · 4dc80968
      Stefan Metzmacher authored
      commit fa8f3a35 upstream.
      
      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>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4dc80968
    • Stefan Metzmacher's avatar
      fs/cifs: correctly to anonymous authentication via NTLMSSP · 9ad66e14
      Stefan Metzmacher authored
      commit cfda35d9 upstream.
      
      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=11913Signed-off-by: default avatarStefan Metzmacher <metze@samba.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ad66e14
    • Steve French's avatar
      remove directory incorrectly tries to set delete on close on non-empty directories · b7d7ba31
      Steve French authored
      commit 897fba11 upstream.
      
      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>
      Acked-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7d7ba31
    • Matt Evans's avatar
      kvm: arm64: Fix EC field in inject_abt64 · 6ff3df20
      Matt Evans authored
      commit e4fe9e7d upstream.
      
      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>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ff3df20
    • Marc Zyngier's avatar
      arm/arm64: KVM: Enforce Break-Before-Make on Stage-2 page tables · ab858305
      Marc Zyngier authored
      commit d4b9e079 upstream.
      
      The ARM architecture mandates that when changing a page table entry
      from a valid entry to another valid entry, an invalid entry is first
      written, TLB invalidated, and only then the new entry being written.
      
      The current code doesn't respect this, directly writing the new
      entry and only then invalidating TLBs. Let's fix it up.
      Reported-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab858305
    • Julien Grall's avatar
      arm64: cpuinfo: Missing NULL terminator in compat_hwcap_str · 44f47d94
      Julien Grall authored
      commit f228b494 upstream.
      
      The loop that browses the array compat_hwcap_str will stop when a NULL
      is encountered, however NULL is missing at the end of array. This will
      lead to overrun until a NULL is found somewhere in the following memory.
      In reality, this works out because the compat_hwcap2_str array tends to
      follow immediately in memory, and that *is* terminated correctly.
      Furthermore, the unsigned int compat_elf_hwcap is checked before
      printing each capability, so we end up doing the right thing because
      the size of the two arrays is less than 32. Still, this is an obvious
      mistake and should be fixed.
      
      Note for backporting: commit 12d11817 ("arm64: Move
      /proc/cpuinfo handling code") moved this code in v4.4. Prior to that
      commit, the same change should be made in arch/arm64/kernel/setup.c.
      
      Fixes: 44b82b77 "arm64: Fix up /proc/cpuinfo"
      Signed-off-by: default avatarJulien Grall <julien.grall@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44f47d94
    • Catalin Marinas's avatar
      arm64: Implement pmdp_set_access_flags() for hardware AF/DBM · 7e1c1db0
      Catalin Marinas authored
      commit 282aa705 upstream.
      
      The update to the accessed or dirty states for block mappings must be
      done atomically on hardware with support for automatic AF/DBM. The
      ptep_set_access_flags() function has been fixed as part of commit
      66dbd6e6 ("arm64: Implement ptep_set_access_flags() for hardware
      AF/DBM"). This patch brings pmdp_set_access_flags() in line with the pte
      counterpart.
      
      Fixes: 2f4b829c ("arm64: Add support for hardware updates of the access and dirty pte bits")
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e1c1db0
    • Catalin Marinas's avatar
      arm64: Implement ptep_set_access_flags() for hardware AF/DBM · 098942bc
      Catalin Marinas authored
      commit 66dbd6e6 upstream.
      
      When hardware updates of the access and dirty states are enabled, the
      default ptep_set_access_flags() implementation based on calling
      set_pte_at() directly is potentially racy. This triggers the "racy dirty
      state clearing" warning in set_pte_at() because an existing writable PTE
      is overridden with a clean entry.
      
      There are two main scenarios for this situation:
      
      1. The CPU getting an access fault does not support hardware updates of
         the access/dirty flags. However, a different agent in the system
         (e.g. SMMU) can do this, therefore overriding a writable entry with a
         clean one could potentially lose the automatically updated dirty
         status
      
      2. A more complex situation is possible when all CPUs support hardware
         AF/DBM:
      
         a) Initial state: shareable + writable vma and pte_none(pte)
         b) Read fault taken by two threads of the same process on different
            CPUs
         c) CPU0 takes the mmap_sem and proceeds to handling the fault. It
            eventually reaches do_set_pte() which sets a writable + clean pte.
            CPU0 releases the mmap_sem
         d) CPU1 acquires the mmap_sem and proceeds to handle_pte_fault(). The
            pte entry it reads is present, writable and clean and it continues
            to pte_mkyoung()
         e) CPU1 calls ptep_set_access_flags()
      
         If between (d) and (e) the hardware (another CPU) updates the dirty
         state (clears PTE_RDONLY), CPU1 will override the PTR_RDONLY bit
         marking the entry clean again.
      
      This patch implements an arm64-specific ptep_set_access_flags() function
      to perform an atomic update of the PTE flags.
      
      Fixes: 2f4b829c ("arm64: Add support for hardware updates of the access and dirty pte bits")
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: default avatarMing Lei <tom.leiming@gmail.com>
      Tested-by: default avatarJulien Grall <julien.grall@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      [will: reworded comment]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      098942bc
    • Catalin Marinas's avatar
      arm64: Ensure pmd_present() returns false after pmd_mknotpresent() · 737b0679
      Catalin Marinas authored
      commit 5bb1cc0f upstream.
      
      Currently, pmd_present() only checks for a non-zero value, returning
      true even after pmd_mknotpresent() (which only clears the type bits).
      This patch converts pmd_present() to using pte_present(), similar to the
      other pmd_*() checks. As a side effect, it will return true for
      PROT_NONE mappings, though they are not yet used by the kernel with
      transparent huge pages.
      
      For consistency, also change pmd_mknotpresent() to only clear the
      PMD_SECT_VALID bit, even though the PMD_TABLE_BIT is already 0 for block
      mappings (no functional change). The unused PMD_SECT_PROT_NONE
      definition is removed as transparent huge pages use the pte page prot
      values.
      
      Fixes: 9c7e535f ("arm64: mm: Route pmd thp functions through pte equivalents")
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      737b0679
    • Catalin Marinas's avatar
      arm64: Fix typo in the pmdp_huge_get_and_clear() definition · f07f7491
      Catalin Marinas authored
      commit 911f56ee upstream.
      
      With hardware AF/DBM support, pmd modifications (transparent huge pages)
      should be performed atomically using load/store exclusive. The initial
      patches defined the get-and-clear function and __HAVE_ARCH_* macro
      without the "huge" word, leaving the pmdp_huge_get_and_clear() to the
      default, non-atomic implementation.
      
      Fixes: 2f4b829c ("arm64: Add support for hardware updates of the access and dirty pte bits")
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f07f7491
    • Eryu Guan's avatar
      ext4: iterate over buffer heads correctly in move_extent_per_page() · fa5613b1
      Eryu Guan authored
      commit 6ffe77ba upstream.
      
      In commit bcff2488 ("ext4: don't read blocks from disk after extents
      being swapped") bh is not updated correctly in the for loop and wrong
      data has been written to disk. generic/324 catches this on sub-page
      block size ext4.
      
      Fixes: bcff2488 ("ext4: don't read blocks from disk after extentsbeing swapped")
      Signed-off-by: default avatarEryu Guan <guaneryu@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa5613b1
    • Arnaldo Carvalho de Melo's avatar
      perf test: Fix build of BPF and LLVM on older glibc libraries · eef1195b
      Arnaldo Carvalho de Melo authored
      commit 916d4092 upstream.
      
        $ rpm -q glibc
        glibc-2.12-1.166.el6_7.1.x86_64
      
      <SNIP>
          CC       /tmp/build/perf/tests/llvm.o
        cc1: warnings being treated as errors
        tests/llvm.c: In function ‘test_llvm__fetch_bpf_obj’:
        tests/llvm.c:53: error: declaration of ‘index’ shadows a global declaration
        /usr/include/string.h:489: error: shadowed declaration is here
      <SNIP>
          CC       /tmp/build/perf/tests/bpf.o
        cc1: warnings being treated as errors
        tests/bpf.c: In function ‘__test__bpf’:
        tests/bpf.c:149: error: declaration of ‘index’ shadows a global declaration
        /usr/include/string.h:489: error: shadowed declaration is here
      <SNIP>
      
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: pi3orama@163.com
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Zefan Li <lizefan@huawei.com>
      Fixes: b31de018 ("perf test: Enhance the LLVM test: update basic BPF test program")
      Fixes: ba1fae43 ("perf test: Add 'perf test BPF'")
      Link: http://lkml.kernel.org/n/tip-akpo4r750oya2phxoh9e3447@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Nikolay Borisov <kernel@kyup.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eef1195b
    • Peter Zijlstra's avatar
      perf/core: Fix perf_event_open() vs. execve() race · c5174678
      Peter Zijlstra authored
      commit 79c9ce57 upstream.
      
      Jann reported that the ptrace_may_access() check in
      find_lively_task_by_vpid() is racy against exec().
      
      Specifically:
      
        perf_event_open()		execve()
      
        ptrace_may_access()
      				commit_creds()
        ...				if (get_dumpable() != SUID_DUMP_USER)
      				  perf_event_exit_task();
        perf_install_in_context()
      
      would result in installing a counter across the creds boundary.
      
      Fix this by wrapping lots of perf_event_open() in cred_guard_mutex.
      This should be fine as perf_event_exit_task() is already called with
      cred_guard_mutex held, so all perf locks already nest inside it.
      Reported-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarHe Kuang <hekuang@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5174678
    • Alexander Shishkin's avatar
      perf/x86/intel/pt: Generate PMI in the STOP region as well · a7a9e0ef
      Alexander Shishkin authored
      commit ab92b232 upstream.
      
      Currently, the PT driver always sets the PMI bit one region (page) before
      the STOP region so that we can wake up the consumer before we run out of
      room in the buffer and have to disable the event. However, we also need
      an interrupt in the last output region, so that we actually get to disable
      the event (if no more room from new data is available at that point),
      otherwise hardware just quietly refuses to start, but the event is
      scheduled in and we end up losing trace data till the event gets removed.
      
      For a cpu-wide event it is even worse since there may not be any
      re-scheduling at all and no chance for the ring buffer code to notice
      that its buffer is filled up and the event needs to be disabled (so that
      the consumer can re-enable it when it finishes reading the data out). In
      other words, all the trace data will be lost after the buffer gets filled
      up.
      
      This patch makes PT also generate a PMI when the last output region is
      full.
      Reported-by: default avatarMarkus Metzger <markus.t.metzger@intel.com>
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: vince@deater.net
      Link: http://lkml.kernel.org/r/1462886313-13660-2-git-send-email-alexander.shishkin@linux.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7a9e0ef
    • Josef Bacik's avatar
      Btrfs: don't use src fd for printk · e1ce8c2a
      Josef Bacik authored
      commit c79b4713 upstream.
      
      The fd we pass in may not be on a btrfs file system, so don't try to do
      BTRFS_I() on it.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1ce8c2a
  2. 19 May, 2016 2 commits