1. 25 Dec, 2017 13 commits
  2. 20 Dec, 2017 27 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.107 · 96c00ece
      Greg Kroah-Hartman authored
      96c00ece
    • Miaoqing Pan's avatar
      ath9k: fix tx99 potential info leak · a815c0a3
      Miaoqing Pan authored
      
      [ Upstream commit ee0a4718 ]
      
      When the user sets count to zero the string buffer would remain
      completely uninitialized which causes the kernel to parse its
      own stack data, potentially leading to an info leak. In addition
      to that, the string might be not terminated properly when the
      user data does not contain a 0-terminator.
      Signed-off-by: default avatarMiaoqing Pan <miaoqing@codeaurora.org>
      Reviewed-by: default avatarChristoph Böhmwalder <christoph@boehmwalder.at>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a815c0a3
    • Alex Vesker's avatar
      IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop · 26c66554
      Alex Vesker authored
      
      [ Upstream commit b4b678b0 ]
      
      When ndo_open and ndo_stop are called RTNL lock should be held.
      In this specific case ipoib_ib_dev_open calls the offloaded ndo_open
      which re-sets the number of TX queue assuming RTNL lock is held.
      Since RTNL lock is not held, RTNL assert will fail.
      Signed-off-by: default avatarAlex Vesker <valex@mellanox.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      26c66554
    • Bart Van Assche's avatar
      RDMA/cma: Avoid triggering undefined behavior · 112814db
      Bart Van Assche authored
      
      [ Upstream commit c0b64f58 ]
      
      According to the C standard the behavior of computations with
      integer operands is as follows:
      * A computation involving unsigned operands can never overflow,
        because a result that cannot be represented by the resulting
        unsigned integer type is reduced modulo the number that is one
        greater than the largest value that can be represented by the
        resulting type.
      * The behavior for signed integer underflow and overflow is
        undefined.
      
      Hence only use unsigned integers when checking for integer
      overflow.
      
      This patch is what I came up with after having analyzed the
      following smatch warnings:
      
      drivers/infiniband/core/cma.c:3448: cma_resolve_ib_udp() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len'
      drivers/infiniband/core/cma.c:3505: cma_connect_ib() warn: signed overflow undefined. 'offset + conn_param->private_data_len < conn_param->private_data_len'
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@wdc.com>
      Acked-by: default avatarSean Hefty <sean.hefty@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      112814db
    • Alexander Duyck's avatar
      macvlan: Only deliver one copy of the frame to the macvlan interface · 4bbb4913
      Alexander Duyck authored
      
      [ Upstream commit dd6b9c2c ]
      
      This patch intoduces a slight adjustment for macvlan to address the fact
      that in source mode I was seeing two copies of any packet addressed to the
      macvlan interface being delivered where there should have been only one.
      
      The issue appears to be that one copy was delivered based on the source MAC
      address and then the second copy was being delivered based on the
      destination MAC address. To fix it I am just treating a unicast address
      match as though it is not a match since source based macvlan isn't supposed
      to be matching based on the destination MAC anyway.
      
      Fixes: 79cf79ab ("macvlan: add source mode")
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4bbb4913
    • Jan Kara's avatar
      udf: Avoid overflow when session starts at large offset · b8d510ff
      Jan Kara authored
      
      [ Upstream commit abdc0eb0 ]
      
      When session starts beyond offset 2^31 the arithmetics in
      udf_check_vsd() would overflow. Make sure the computation is done in
      large enough type.
      Reported-by: default avatarCezary Sliwa <sliwa@ifpan.edu.pl>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8d510ff
    • Dan Carpenter's avatar
      scsi: bfa: integer overflow in debugfs · a114af87
      Dan Carpenter authored
      
      [ Upstream commit 3e351275 ]
      
      We could allocate less memory than intended because we do:
      
      	bfad->regdata = kzalloc(len << 2, GFP_KERNEL);
      
      The shift can overflow leading to a crash.  This is debugfs code so the
      impact is very small.  I fixed the network version of this in March with
      commit 13e2d518 ("bna: integer overflow bug in debugfs").
      
      Fixes: ab2a9ba1 ("[SCSI] bfa: add debugfs support")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a114af87
    • weiping zhang's avatar
      scsi: sd: change allow_restart to bool in sysfs interface · 798f0850
      weiping zhang authored
      
      [ Upstream commit 658e9a6d ]
      
      /sys/class/scsi_disk/0:2:0:0/allow_restart can be changed to 0
      unexpectedly by writing an invalid string such as the following:
      
      echo asdf > /sys/class/scsi_disk/0:2:0:0/allow_restart
      Signed-off-by: default avatarweiping zhang <zhangweiping@didichuxing.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      798f0850
    • weiping zhang's avatar
      scsi: sd: change manage_start_stop to bool in sysfs interface · c387c02d
      weiping zhang authored
      
      [ Upstream commit 623401ee ]
      
      /sys/class/scsi_disk/0:2:0:0/manage_start_stop can be changed to 0
      unexpectly by writing an invalid string.
      Signed-off-by: default avatarweiping zhang <zhangweiping@didichuxing.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c387c02d
    • Jia-Ju Bai's avatar
      vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend · 2e03af22
      Jia-Ju Bai authored
      
      [ Upstream commit 42c8eb3f ]
      
      The driver may sleep under a spinlock, and the function call path is:
      vt6655_suspend (acquire the spinlock)
        pci_set_power_state
          __pci_start_power_transition (drivers/pci/pci.c)
            msleep --> may sleep
      
      To fix it, pci_set_power_state is called without having a spinlock.
      
      This bug is found by my static analysis tool and my code review.
      Signed-off-by: default avatarJia-Ju Bai <baijiaju1990@163.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e03af22
    • Kurt Garloff's avatar
      scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry · 930fb06d
      Kurt Garloff authored
      
      [ Upstream commit 909cf3e1 ]
      
      All EMC SYMMETRIX support REPORT_LUNS, even if configured to report
      SCSI-2 for whatever reason.
      Signed-off-by: default avatarKurt Garloff <garloff@suse.de>
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      930fb06d
    • NeilBrown's avatar
      raid5: Set R5_Expanded on parity devices as well as data. · 24bc48af
      NeilBrown authored
      
      [ Upstream commit 235b6003 ]
      
      When reshaping a fully degraded raid5/raid6 to a larger
      nubmer of devices, the new device(s) are not in-sync
      and so that can make the newly grown stripe appear to be
      "failed".
      To avoid this, we set the R5_Expanded flag to say "Even though
      this device is not fully in-sync, this block is safe so
      don't treat the device as failed for this stripe".
      This flag is set for data devices, not not for parity devices.
      
      Consequently, if you have a RAID6 with two devices that are partly
      recovered and a spare, and start a reshape to include the spare,
      then when the reshape gets past the point where the recovery was
      up to, it will think the stripes are failed and will get into
      an infinite loop, failing to make progress.
      
      So when contructing parity on an EXPAND_READY stripe,
      set R5_Expanded.
      Reported-by: default avatarCurt <lightspd@gmail.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24bc48af
    • Linus Walleij's avatar
      pinctrl: adi2: Fix Kconfig build problem · 09379498
      Linus Walleij authored
      
      [ Upstream commit 1c363531 ]
      
      The build robot is complaining on Blackfin:
      
      drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup':
      >> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing
         pointer to incomplete type 'struct gpio_port_t'
            writew(readw(&regs->port_fer) & ~BIT(offset),
                              ^~
      drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq':
      >> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing
      pointer to incomplete type 'struct bfin_pint_regs'
            if (readl(&regs->invert_set) & pintbit)
                           ^~
      It seems the driver need to include <asm/gpio.h> and <asm/irq.h>
      to compile.
      
      The Blackfin architecture was re-defining the Kconfig
      PINCTRL symbol which is not OK, so replaced this with
      PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2
      just like most arches do.
      
      Further, the old GPIO driver symbol GPIO_ADI was possible to
      select at the same time as selecting PINCTRL. This was not
      working because the arch-local <asm/gpio.h> header contains
      an explicit #ifndef PINCTRL clause making compilation break
      if you combine them. The same is true for DEBUG_MMRS.
      
      Make sure the ADI2 pinctrl driver is not selected at the same
      time as the old GPIO implementation. (This should be converted
      to use gpiolib or pincontrol and move to drivers/...) Also make
      sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at
      the same time as the new PINCTRL implementation, and only make
      PINCTRL_ADI2 selectable for the Blackfin families that actually
      have it.
      
      This way it is still possible to add e.g. I2C-based pin
      control expanders on the Blackfin.
      
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Huanhuan Feng <huanhuan.feng@analog.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09379498
    • Bin Liu's avatar
      usb: musb: da8xx: fix babble condition handling · 5f2dbdff
      Bin Liu authored
      commit bd3486de upstream.
      
      When babble condition happens, the musb controller might automatically
      turns off VBUS. On DA8xx platform, the controller generates drvvbus
      interrupt for turning off VBUS along with the babble interrupt.
      
      In this case, we should handle the babble interrupt first and recover
      from the babble condition.
      
      This change ignores the drvvbus interrupt if babble interrupt is also
      generated at the same time, so the babble recovery routine works
      properly.
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f2dbdff
    • nixiaoming's avatar
      tty fix oops when rmmod 8250 · 68d3bc40
      nixiaoming authored
      
      [ Upstream commit c79dde62 ]
      
      After rmmod 8250.ko
      tty_kref_put starts kwork (release_one_tty) to release proc interface
      oops when accessing driver->driver_name in proc_tty_unregister_driver
      
      Use jprobe, found driver->driver_name point to 8250.ko
      static static struct uart_driver serial8250_reg
      .driver_name= serial,
      
      Use name in proc_dir_entry instead of driver->driver_name to fix oops
      
      test on linux 4.1.12:
      
      BUG: unable to handle kernel paging request at ffffffffa01979de
      IP: [<ffffffff81310f40>] strchr+0x0/0x30
      PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: ... ...  [last unloaded: 8250]
      CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G           O    4.1.12 #1
      Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 12/21/2015
      Workqueue: events release_one_tty
      task: ffff88085b684960 ti: ffff880852884000 task.ti: ffff880852884000
      RIP: 0010:[<ffffffff81310f40>]  [<ffffffff81310f40>] strchr+0x0/0x30
      RSP: 0018:ffff880852887c90  EFLAGS: 00010282
      RAX: ffffffff81a5eca0 RBX: ffffffffa01979de RCX: 0000000000000004
      RDX: ffff880852887d10 RSI: 000000000000002f RDI: ffffffffa01979de
      RBP: ffff880852887cd8 R08: 0000000000000000 R09: ffff88085f5d94d0
      R10: 0000000000000195 R11: 0000000000000000 R12: ffffffffa01979de
      R13: ffff880852887d00 R14: ffffffffa01979de R15: ffff88085f02e840
      FS:  0000000000000000(0000) GS:ffff88085f5c0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffffffa01979de CR3: 0000000001a0c000 CR4: 00000000001406e0
      Stack:
       ffffffff812349b1 ffff880852887cb8 ffff880852887d10 ffff88085f5cd6c2
       ffff880852800a80 ffffffffa01979de ffff880852800a84 0000000000000010
       ffff88085bb28bd8 ffff880852887d38 ffffffff812354f0 ffff880852887d08
      Call Trace:
       [<ffffffff812349b1>] ? __xlate_proc_name+0x71/0xd0
       [<ffffffff812354f0>] remove_proc_entry+0x40/0x180
       [<ffffffff815f6811>] ? _raw_spin_lock_irqsave+0x41/0x60
       [<ffffffff813be520>] ? destruct_tty_driver+0x60/0xe0
       [<ffffffff81237c68>] proc_tty_unregister_driver+0x28/0x40
       [<ffffffff813be548>] destruct_tty_driver+0x88/0xe0
       [<ffffffff813be5bd>] tty_driver_kref_put+0x1d/0x20
       [<ffffffff813becca>] release_one_tty+0x5a/0xd0
       [<ffffffff81074159>] process_one_work+0x139/0x420
       [<ffffffff810745a1>] worker_thread+0x121/0x450
       [<ffffffff81074480>] ? process_scheduled_works+0x40/0x40
       [<ffffffff8107a16c>] kthread+0xec/0x110
       [<ffffffff81080000>] ? tg_rt_schedulable+0x210/0x220
       [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80
       [<ffffffff815f7292>] ret_from_fork+0x42/0x70
       [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80
      Signed-off-by: default avatarnixiaoming <nixiaoming@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      68d3bc40
    • Michael Ellerman's avatar
      powerpc/perf/hv-24x7: Fix incorrect comparison in memord · afa8f0a7
      Michael Ellerman authored
      
      [ Upstream commit 05c14c03 ]
      
      In the hv-24x7 code there is a function memord() which tries to
      implement a sort function return -1, 0, 1. However one of the
      conditions is incorrect, such that it can never be true, because we
      will have already returned.
      
      I don't believe there is a bug in practice though, because the
      comparisons are an optimisation prior to calling memcmp().
      
      Fix it by swapping the second comparision, so it can be true.
      Reported-by: default avatarDavid Binderman <dcb314@hotmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afa8f0a7
    • Martin Wilck's avatar
      scsi: hpsa: destroy sas transport properties before scsi_host · 28a5b0e4
      Martin Wilck authored
      
      [ Upstream commit dfb2e6f4 ]
      
      This patch cleans up a lot of warnings when unloading the driver.
      
      A current example of the stack trace starts with:
          [  142.570715] sysfs group 'power' not found for kobject 'port-5:0'
      There can be hundreds of these messages during a driver unload.
      
      I am resubmitting this patch on behalf of Martin Wilck with his
      permission.
      
      His original patch can be found here:
      https://www.spinics.net/lists/linux-scsi/msg102085.html
      
      This patch did not help until Hannes's
      commit 9441284fbc39 ("scsi-fixup-kernel-warning-during-rmmod")
      was applied to the kernel.
      
      ---------------------------
      Original patch description:
      ---------------------------
      
      Unloading the hpsa driver causes warnings
      
      [ 1063.793652] WARNING: CPU: 1 PID: 4850 at ../fs/sysfs/group.c:237 device_del+0x54/0x240()
      [ 1063.793659] sysfs group ffffffff81cf21a0 not found for kobject 'port-2:0'
      
      with two different stacks:
      1)
      [ 1063.793774]  [<ffffffff81448af4>] device_del+0x54/0x240
      [ 1063.793780]  [<ffffffff8145178a>] transport_remove_classdev+0x4a/0x60
      [ 1063.793784]  [<ffffffff81451216>] attribute_container_device_trigger+0xa6/0xb0
      [ 1063.793802]  [<ffffffffa0105d46>] sas_port_delete+0x126/0x160 [scsi_transport_sas]
      [ 1063.793819]  [<ffffffffa036ebcc>] hpsa_free_sas_port+0x3c/0x70 [hpsa]
      
      2)
      [ 1063.797103]  [<ffffffff81448af4>] device_del+0x54/0x240
      [ 1063.797118]  [<ffffffffa0105d4e>] sas_port_delete+0x12e/0x160 [scsi_transport_sas]
      [ 1063.797134]  [<ffffffffa036ebcc>] hpsa_free_sas_port+0x3c/0x70 [hpsa]
      
      This is caused by the fact that host device hostX is deleted before the
      SAS transport devices hostX/port-a:b.
      
      This patch fixes this by reverting the order of device deletions.
      Tested-by: default avatarDon Brace <don.brace@microsemi.com>
      Reviewed-by: default avatarDon Brace <don.brace@microsemi.com>
      Signed-off-by: default avatarMartin Wilck <mwilck@suse.de>
      Signed-off-by: default avatarDon Brace <don.brace@microsemi.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28a5b0e4
    • Martin Wilck's avatar
      scsi: hpsa: cleanup sas_phy structures in sysfs when unloading · 942eb7dd
      Martin Wilck authored
      
      [ Upstream commit 55ca38b4 ]
      
      I am resubmitting this patch on behalf of Martin Wilck with his
      permission.
      
      The original patch can be found here:
      https://www.spinics.net/lists/linux-scsi/msg102083.html
      
      This patch did not help until Hannes's
      commit 9441284fbc39 ("scsi-fixup-kernel-warning-during-rmmod")
      was applied to the kernel.
      
      --------------------------------------
      Original patch description from Martin:
      --------------------------------------
      
      When the hpsa module is unloaded using rmmod, dangling
      symlinks remain under /sys/class/sas_phy. Fix this by
      calling sas_phy_delete() rather than sas_phy_free (which,
      according to comments, should not be called for PHYs that
      have been set up successfully, anyway).
      Tested-by: default avatarDon Brace <don.brace@microsemi.com>
      Reviewed-by: default avatarDon Brace <don.brace@microsemi.com>
      Signed-off-by: default avatarMartin Wilck <mwilck@suse.de>
      Signed-off-by: default avatarDon Brace <don.brace@microsemi.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      942eb7dd
    • Alex Williamson's avatar
      PCI: Detach driver before procfs & sysfs teardown on device remove · ec662d65
      Alex Williamson authored
      
      [ Upstream commit 16b6c8bb ]
      
      When removing a device, for example a VF being removed due to SR-IOV
      teardown, a "soft" hot-unplug via 'echo 1 > remove' in sysfs, or an actual
      hot-unplug, we first remove the procfs and sysfs attributes for the device
      before attempting to release the device from any driver bound to it.
      Unbinding the driver from the device can take time.  The device might need
      to write out data or it might be actively in use.  If it's in use by
      userspace through a vfio driver, the unbind might block until the user
      releases the device.  This leads to a potentially non-trivial amount of
      time where the device exists, but we've torn down the interfaces that
      userspace uses to examine devices, for instance lspci might generate this
      sort of error:
      
        pcilib: Cannot open /sys/bus/pci/devices/0000:01:0a.3/config
        lspci: Unable to read the standard configuration space header of device 0000:01:0a.3
      
      We don't seem to have any dependence on this teardown ordering in the
      kernel, so let's unbind the driver first, which is also more symmetric with
      the instantiation of the device in pci_bus_add_device().
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec662d65
    • Christoph Hellwig's avatar
      xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real · 02922f3b
      Christoph Hellwig authored
      
      [ Upstream commit 5e422f5e ]
      
      There was one spot in xfs_bmap_add_extent_unwritten_real that didn't use the
      passed in new extent state but always converted to normal, leading to wrong
      behavior when converting from normal to unwritten.
      
      Only found by code inspection, it seems like this code path to move partial
      extent from written to unwritten while merging it with the next extent is
      rarely exercised.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02922f3b
    • Brian Foster's avatar
      xfs: fix log block underflow during recovery cycle verification · f267a139
      Brian Foster authored
      
      [ Upstream commit 9f2a4505 ]
      
      It is possible for mkfs to format very small filesystems with too
      small of an internal log with respect to the various minimum size
      and block count requirements. If this occurs when the log happens to
      be smaller than the scan window used for cycle verification and the
      scan wraps the end of the log, the start_blk calculation in
      xlog_find_head() underflows and leads to an attempt to scan an
      invalid range of log blocks. This results in log recovery failure
      and a failed mount.
      
      Since there may be filesystems out in the wild with this kind of
      geometry, we cannot simply refuse to mount. Instead, cap the scan
      window for cycle verification to the size of the physical log. This
      ensures that the cycle verification proceeds as expected when the
      scan wraps the end of the log.
      Reported-by: default avatarZorro Lang <zlang@redhat.com>
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f267a139
    • Jiri Slaby's avatar
      l2tp: cleanup l2tp_tunnel_delete calls · 92eff81a
      Jiri Slaby authored
      
      [ Upstream commit 4dc12ffe ]
      
      l2tp_tunnel_delete does not return anything since commit 62b982ee
      ("l2tp: fix race condition in l2tp_tunnel_delete").  But call sites of
      l2tp_tunnel_delete still do casts to void to avoid unused return value
      warnings.
      
      Kill these now useless casts.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Sabrina Dubroca <sd@queasysnail.net>
      Cc: Guillaume Nault <g.nault@alphalink.fr>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Acked-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      92eff81a
    • tang.junhui's avatar
      bcache: fix wrong cache_misses statistics · 230c4ba4
      tang.junhui authored
      
      [ Upstream commit c1573137 ]
      
      Currently, Cache missed IOs are identified by s->cache_miss, but actually,
      there are many situations that missed IOs are not assigned a value for
      s->cache_miss in cached_dev_cache_miss(), for example, a bypassed IO
      (s->iop.bypass = 1), or the cache_bio allocate failed. In these situations,
      it will go to out_put or out_submit, and s->cache_miss is null, which leads
      bch_mark_cache_accounting() to treat this IO as a hit IO.
      
      [ML: applied by 3-way merge]
      Signed-off-by: default avatartang.junhui <tang.junhui@zte.com.cn>
      Reviewed-by: default avatarMichael Lyle <mlyle@lyle.org>
      Reviewed-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      230c4ba4
    • Liang Chen's avatar
      bcache: explicitly destroy mutex while exiting · 27125237
      Liang Chen authored
      
      [ Upstream commit 330a4db8 ]
      
      mutex_destroy does nothing most of time, but it's better to call
      it to make the code future proof and it also has some meaning
      for like mutex debug.
      
      As Coly pointed out in a previous review, bcache_exit() may not be
      able to handle all the references properly if userspace registers
      cache and backing devices right before bch_debug_init runs and
      bch_debug_init failes later. So not exposing userspace interface
      until everything is ready to avoid that issue.
      Signed-off-by: default avatarLiang Chen <liangchen.linux@gmail.com>
      Reviewed-by: default avatarMichael Lyle <mlyle@lyle.org>
      Reviewed-by: default avatarColy Li <colyli@suse.de>
      Reviewed-by: default avatarEric Wheeler <bcache@linux.ewheeler.net>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      27125237
    • Bob Peterson's avatar
      GFS2: Take inode off order_write list when setting jdata flag · ab9b3db4
      Bob Peterson authored
      
      [ Upstream commit cc555b09 ]
      
      This patch fixes a deadlock caused when the jdata flag is set for
      inodes that are already on the ordered write list. Since it is
      on the ordered write list, log_flush calls gfs2_ordered_write which
      calls filemap_fdatawrite. But since the inode had the jdata flag
      set, that calls gfs2_jdata_writepages, which tries to start a new
      transaction. A new transaction cannot be started because it tries
      to acquire the log_flush rwsem which is already locked by the log
      flush operation.
      
      The bottom line is: We cannot switch an inode from ordered to jdata
      until we eliminate any ordered data pages (via log flush) or any
      log_flush operation afterward will create the circular dependency
      above. So we need to flush the log before setting the diskflags to
      switch the file mode, then we need to remove the inode from the
      ordered writes list.
      
      Before this patch, the log flush was done for jdata->ordered, but
      that's wrong. If we're going from jdata to ordered, we don't need
      to call gfs2_log_flush because the call to filemap_fdatawrite will
      do it for us:
      
         filemap_fdatawrite() -> __filemap_fdatawrite_range()
            __filemap_fdatawrite_range() -> do_writepages()
               do_writepages() -> gfs2_jdata_writepages()
                  gfs2_jdata_writepages() -> gfs2_log_flush()
      
      This patch modifies function do_gfs2_set_flags so that if a file
      has its jdata flag set, and it's already on the ordered write list,
      the log will be flushed and it will be removed from the list
      before setting the flag.
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      Acked-by: default avatarAbhijith Das <adas@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab9b3db4
    • Daniel Lezcano's avatar
      thermal/drivers/step_wise: Fix temperature regulation misbehavior · 2a5bb128
      Daniel Lezcano authored
      
      [ Upstream commit 07209fcf ]
      
      There is a particular situation when the cooling device is cpufreq and the heat
      dissipation is not efficient enough where the temperature increases little by
      little until reaching the critical threshold and leading to a SoC reset.
      
      The behavior is reproducible on a hikey6220 with bad heat dissipation (eg.
      stacked with other boards).
      
      Running a simple C program doing while(1); for each CPU of the SoC makes the
      temperature to reach the passive regulation trip point and ends up to the
      maximum allowed temperature followed by a reset.
      
      This issue has been also reported by running the libhugetlbfs test suite.
      
      What is observed is a ping pong between two cpu frequencies, 1.2GHz and 900MHz
      while the temperature continues to grow.
      
      It appears the step wise governor calls get_target_state() the first time with
      the throttle set to true and the trend to 'raising'. The code selects logically
      the next state, so the cpu frequency decreases from 1.2GHz to 900MHz, so far so
      good. The temperature decreases immediately but still stays greater than the
      trip point, then get_target_state() is called again, this time with the
      throttle set to true *and* the trend to 'dropping'. From there the algorithm
      assumes we have to step down the state and the cpu frequency jumps back to
      1.2GHz. But the temperature is still higher than the trip point, so
      get_target_state() is called with throttle=1 and trend='raising' again, we jump
      to 900MHz, then get_target_state() is called with throttle=1 and
      trend='dropping', we jump to 1.2GHz, etc ... but the temperature does not
      stabilizes and continues to increase.
      
      [  237.922654] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
      [  237.922678] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
      [  237.922690] thermal cooling_device0: cur_state=0
      [  237.922701] thermal cooling_device0: old_target=0, target=1
      [  238.026656] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
      [  238.026680] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1
      [  238.026694] thermal cooling_device0: cur_state=1
      [  238.026707] thermal cooling_device0: old_target=1, target=0
      [  238.134647] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
      [  238.134667] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
      [  238.134679] thermal cooling_device0: cur_state=0
      [  238.134690] thermal cooling_device0: old_target=0, target=1
      
      In this situation the temperature continues to increase while the trend is
      oscillating between 'dropping' and 'raising'. We need to keep the current state
      untouched if the throttle is set, so the temperature can decrease or a higher
      state could be selected, thus preventing this oscillation.
      
      Keeping the next_target untouched when 'throttle' is true at 'dropping' time
      fixes the issue.
      
      The following traces show the governor does not change the next state if
      trend==2 (dropping) and throttle==1.
      
      [ 2306.127987] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
      [ 2306.128009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
      [ 2306.128021] thermal cooling_device0: cur_state=0
      [ 2306.128031] thermal cooling_device0: old_target=0, target=1
      [ 2306.231991] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
      [ 2306.232016] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1
      [ 2306.232030] thermal cooling_device0: cur_state=1
      [ 2306.232042] thermal cooling_device0: old_target=1, target=1
      [ 2306.335982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
      [ 2306.336006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=1
      [ 2306.336021] thermal cooling_device0: cur_state=1
      [ 2306.336034] thermal cooling_device0: old_target=1, target=1
      [ 2306.439984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
      [ 2306.440008] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0
      [ 2306.440022] thermal cooling_device0: cur_state=1
      [ 2306.440034] thermal cooling_device0: old_target=1, target=0
      
      [ ... ]
      
      After a while, if the temperature continues to increase, the next state becomes
      2 which is 720MHz on the hikey. That results in the temperature stabilizing
      around the trip point.
      
      [ 2455.831982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
      [ 2455.832006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=0
      [ 2455.832019] thermal cooling_device0: cur_state=1
      [ 2455.832032] thermal cooling_device0: old_target=1, target=1
      [ 2455.935985] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
      [ 2455.936013] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0
      [ 2455.936027] thermal cooling_device0: cur_state=1
      [ 2455.936040] thermal cooling_device0: old_target=1, target=1
      [ 2456.043984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
      [ 2456.044009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0
      [ 2456.044023] thermal cooling_device0: cur_state=1
      [ 2456.044036] thermal cooling_device0: old_target=1, target=1
      [ 2456.148001] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
      [ 2456.148028] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
      [ 2456.148042] thermal cooling_device0: cur_state=1
      [ 2456.148055] thermal cooling_device0: old_target=1, target=2
      [ 2456.252009] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
      [ 2456.252041] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0
      [ 2456.252058] thermal cooling_device0: cur_state=2
      [ 2456.252075] thermal cooling_device0: old_target=2, target=1
      
      IOW, this change is needed to keep the state for a cooling device if the
      temperature trend is oscillating while the temperature increases slightly.
      
      Without this change, the situation above leads to a catastrophic crash by a
      hardware reset on hikey. This issue has been reported to happen on an OMAP
      dra7xx also.
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Leo Yan <leo.yan@linaro.org>
      Tested-by: default avatarKeerthy <j-keerthy@ti.com>
      Reviewed-by: default avatarKeerthy <j-keerthy@ti.com>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a5bb128
    • Gao Feng's avatar
      ppp: Destroy the mutex when cleanup · 561b9d99
      Gao Feng authored
      
      [ Upstream commit f02b2320 ]
      
      The mutex_destroy only makes sense when enable DEBUG_MUTEX. For the
      good readbility, it's better to invoke it in exit func when the init
      func invokes mutex_init.
      Signed-off-by: default avatarGao Feng <gfree.wind@vip.163.com>
      Acked-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      561b9d99