1. 11 Aug, 2017 24 commits
  2. 06 Aug, 2017 16 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.12.5 · 45100eec
      Greg Kroah-Hartman authored
      45100eec
    • Chris Brandt's avatar
      mmc: tmio-mmc: fix bad pointer math · b5dd7985
      Chris Brandt authored
      commit 9c284c41 upstream.
      
      The existing code gives an incorrect pointer value.
      The buffer pointer 'buf' was of type unsigned short *, and 'count' was a
      number in bytes. A cast of buf should have been used.
      
      However, instead of casting, just change the code to use u32 pointers.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Fixes: 8185e51f: ("mmc: tmio-mmc: add support for 32bit data port")
      Signed-off-by: default avatarChris Brandt <chris.brandt@renesas.com>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      b5dd7985
    • Al Viro's avatar
      dentry name snapshots · 75791420
      Al Viro authored
      commit 49d31c2f upstream.
      
      take_dentry_name_snapshot() takes a safe snapshot of dentry name;
      if the name is a short one, it gets copied into caller-supplied
      structure, otherwise an extra reference to external name is grabbed
      (those are never modified).  In either case the pointer to stable
      string is stored into the same structure.
      
      dentry must be held by the caller of take_dentry_name_snapshot(),
      but may be freely dropped afterwards - the snapshot will stay
      until destroyed by release_dentry_name_snapshot().
      
      Intended use:
      	struct name_snapshot s;
      
      	take_dentry_name_snapshot(&s, dentry);
      	...
      	access s.name
      	...
      	release_dentry_name_snapshot(&s);
      
      Replaces fsnotify_oldname_...(), gets used in fsnotify to obtain the name
      to pass down with event.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75791420
    • Valentin Vidic's avatar
      ipmi/watchdog: fix watchdog timeout set on reboot · fe57e31e
      Valentin Vidic authored
      commit 860f01e9 upstream.
      
      systemd by default starts watchdog on reboot and sets the timer to
      ShutdownWatchdogSec=10min.  Reboot handler in ipmi_watchdog than reduces
      the timer to 120s which is not enough time to boot a Xen machine with
      a lot of RAM.  As a result the machine is rebooted the second time
      during the long run of (XEN) Scrubbing Free RAM.....
      
      Fix this by setting the timer to 120s only if it was previously
      set to a low value.
      Signed-off-by: default avatarValentin Vidic <Valentin.Vidic@CARNet.hr>
      Signed-off-by: default avatarCorey Minyard <cminyard@mvista.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe57e31e
    • Annie Cherkaev's avatar
      isdn/i4l: fix buffer overflow · cd043db8
      Annie Cherkaev authored
      commit 9f5af546 upstream.
      
      This fixes a potential buffer overflow in isdn_net.c caused by an
      unbounded strcpy.
      
      [ ISDN seems to be effectively unmaintained, and the I4L driver in
        particular is long deprecated, but in case somebody uses this..
          - Linus ]
      Signed-off-by: default avatarJiten Thakkar <jitenmt@gmail.com>
      Signed-off-by: default avatarAnnie Cherkaev <annie.cherk@gmail.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd043db8
    • Imre Deak's avatar
      drm/i915: Fix scaler init during CRTC HW state readout · 9ec2ee3a
      Imre Deak authored
      commit 283d6860 upstream.
      
      The scaler allocation code depends on a non-zero default value for the
      crtc scaler_id, so make sure we initialize the scaler state accordingly
      even if the crtc is off. This fixes at least an initial YUV420 modeset
      (added in a follow-up patchset by Shashank) when booting with the screen
      off: after the initial HW readout and modeset which enables the scaler a
      subsequent modeset will disable the scaler which isn't properly
      allocated. This results in a funky HW state where the pipe scaler HW
      registers can't be modified and the normally black screen is grey and
      shifted to the right or jitters.
      
      The problem was revealed by Shashank's YUV420 patchset and first
      reported by Ville.
      
      v2:
      - In the stable tag also include versions which need backporting (Jani)
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chandra Konduru <chandra.konduru@intel.com>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Reported-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Fixes: a1b2278e ("drm/i915: skylake panel fitting using shared scalers")
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarMahesh Kumar <mahesh1.kumar@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170720112820.26816-1-imre.deak@intel.comSigned-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      (cherry picked from commit 5fb9dadf)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ec2ee3a
    • Ben Skeggs's avatar
      drm/nouveau/bar/gf100: fix access to upper half of BAR2 · 7a4337a6
      Ben Skeggs authored
      commit 38bcb208 upstream.
      
      Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
      mapped over the end of VRAM, even when the rest of the BAR has been set
      to virtual mode.
      
      We inherited our initial value from RM, but I'm not aware of any reason
      we need to keep it that way.
      
      This fixes severe GPU hang/lockup issues revealed by Wayland on F26.
      
      Shout-out to NVIDIA for the quick response with the potential cause!
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a4337a6
    • Ilia Mirkin's avatar
      drm/nouveau/disp/nv50-: bump max chans to 21 · 3de4f5de
      Ilia Mirkin authored
      commit a90e049c upstream.
      
      GP102's cursors go from chan 17..20. Increase the array size to hold
      their data properly.
      
      Fixes: e50fcff1 ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices")
      Signed-off-by: default avatarIlia Mirkin <imirkin@alum.mit.edu>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3de4f5de
    • Sinclair Yeh's avatar
      drm/vmwgfx: Limit max desktop dimensions to 8Kx8K · 631c3a0a
      Sinclair Yeh authored
      commit 7b009e76 upstream.
      
      This was originally chosen to be an arbitrarily large number.  However,
      some user mode may actually try to set a 16Kx16K mode and run into other
      issues.
      
      Since 8Kx8K is the current texture limit for Mesa LLVM driver, we will
      just use this limit for now.
      Signed-off-by: default avatarSinclair Yeh <syeh@vmware.com>
      Reviewed-by: default avatarBrian Paul <brianp@vmware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      631c3a0a
    • Sinclair Yeh's avatar
      drm/vmwgfx: Fix gcc-7.1.1 warning · 555ac1e5
      Sinclair Yeh authored
      commit fcfffdd8 upstream.
      
      The current code does not look correct, and the reason for it is
      probably lost.  Since this now generates a compiler warning,
      fix it to what makes sense.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSinclair Yeh <syeh@vmware.com>
      Reviewed-by: default avatarBrian Paul <brianp@vmware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      555ac1e5
    • Ofer Heifetz's avatar
      md/raid5: add thread_group worker async_tx_issue_pending_all · 9425c1fd
      Ofer Heifetz authored
      commit 7e96d559 upstream.
      
      Since thread_group worker and raid5d kthread are not in sync, if
      worker writes stripe before raid5d then requests will be waiting
      for issue_pendig.
      
      Issue observed when building raid5 with ext4, in some build runs
      jbd2 would get hung and requests were waiting in the HW engine
      waiting to be issued.
      
      Fix this by adding a call to async_tx_issue_pending_all in the
      raid5_do_work.
      Signed-off-by: default avatarOfer Heifetz <oferh@marvell.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9425c1fd
    • Shaohua Li's avatar
      md/raid1: fix writebehind bio clone · 270c1bc3
      Shaohua Li authored
      commit 16d56e2f upstream.
      
      After bio is submitted, we should not clone it as its bi_iter might be
      invalid by driver. This is the case of behind_master_bio. In certain
      situration, we could dispatch behind_master_bio immediately for the
      first disk and then clone it for other disks.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=196383Reported-and-tested-by: default avatarMarkus <m4rkusxxl@web.de>
      Reviewed-by: default avatarMing Lei <ming.lei@redhat.com>
      Fix: 841c1316(md: raid1: improve write behind)
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      270c1bc3
    • Ming Lei's avatar
      md: remove 'idx' from 'struct resync_pages' · b70f86ce
      Ming Lei authored
      commit 022e510f upstream.
      
      bio_add_page() won't fail for resync bio, and the page index for each
      bio is same, so remove it.
      
      More importantly the 'idx' of 'struct resync_pages' is initialized in
      mempool allocator function, the current way is wrong since mempool is
      only responsible for allocation, we can't use that for initialization.
      Suggested-by: default avatarNeilBrown <neilb@suse.com>
      Reported-by: default avatarNeilBrown <neilb@suse.com>
      Reported-and-tested-by: default avatarPatrick <dto@gmx.net>
      Fixes: f0250618(md: raid10: don't use bio's vec table to manage resync pages)
      Fixes: 98d30c58(md: raid1: don't use bio's vec table to manage resync pages)
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b70f86ce
    • Mikulas Patocka's avatar
      dm integrity: test for corrupted disk format during table load · bce72191
      Mikulas Patocka authored
      commit bc86a41e upstream.
      
      If the dm-integrity superblock was corrupted in such a way that the
      journal_sections field was zero, the integrity target would deadlock
      because it would wait forever for free space in the journal.
      
      Detect this situation and refuse to activate the device.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Fixes: 7eada909 ("dm: add integrity target")
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bce72191
    • Mikulas Patocka's avatar
      dm integrity: fix inefficient allocation of journal space · d2df849c
      Mikulas Patocka authored
      commit 9dd59727 upstream.
      
      When using a block size greater than 512 bytes, the dm-integrity target
      allocates journal space inefficiently.  It allocates one journal entry
      for each 512-byte chunk of data, fills an entry for each block of data
      and leaves the remaining entries unused.
      
      This issue doesn't cause data corruption, but all the unused journal
      entries degrade performance severely.
      
      For example, with 4k blocks and an 8k bio, it would allocate 16 journal
      entries but only use 2 entries.  The remaining 14 entries were left
      unused.
      
      Fix this by adding the missing 'log2_sectors_per_block' shifts that are
      required to have each journal entry map to a full block.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Fixes: 7eada909 ("dm: add integrity target")
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2df849c
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Fix host crash on changing HPT size · 85fcbf3d
      Paul Mackerras authored
      commit ef427198 upstream.
      
      Commit f98a8bf9 ("KVM: PPC: Book3S HV: Allow KVM_PPC_ALLOCATE_HTAB
      ioctl() to change HPT size", 2016-12-20) changed the behaviour of
      the KVM_PPC_ALLOCATE_HTAB ioctl so that it now allocates a new HPT
      and new revmap array if there was a previously-allocated HPT of a
      different size from the size being requested.  In this case, we need
      to reset the rmap arrays of the memslots, because the rmap arrays
      will contain references to HPTEs which are no longer valid.  Worse,
      these references are also references to slots in the new revmap
      array (which parallels the HPT), and the new revmap array contains
      random contents, since it doesn't get zeroed on allocation.
      
      The effect of having these stale references to slots in the revmap
      array that contain random contents is that subsequent calls to
      functions such as kvmppc_add_revmap_chain will crash because they
      will interpret the non-zero contents of the revmap array as HPTE
      indexes and thus index outside of the revmap array.  This leads to
      host crashes such as the following.
      
      [ 7072.862122] Unable to handle kernel paging request for data at address 0xd000000c250c00f8
      [ 7072.862218] Faulting instruction address: 0xc0000000000e1c78
      [ 7072.862233] Oops: Kernel access of bad area, sig: 11 [#1]
      [ 7072.862286] SMP NR_CPUS=1024
      [ 7072.862286] NUMA
      [ 7072.862325] PowerNV
      [ 7072.862378] Modules linked in: kvm_hv vhost_net vhost tap xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm iw_cxgb3 mlx5_ib ib_core ses enclosure scsi_transport_sas ipmi_powernv ipmi_devintf ipmi_msghandler powernv_op_panel i2c_opal nfsd auth_rpcgss oid_registry
      [ 7072.863085]  nfs_acl lockd grace sunrpc kvm_pr kvm xfs libcrc32c scsi_dh_alua dm_service_time radeon lpfc nvme_fc nvme_fabrics nvme_core scsi_transport_fc i2c_algo_bit tg3 drm_kms_helper ptp pps_core syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm dm_multipath i2c_core cxgb3 mlx5_core mdio [last unloaded: kvm_hv]
      [ 7072.863381] CPU: 72 PID: 56929 Comm: qemu-system-ppc Not tainted 4.12.0-kvm+ #59
      [ 7072.863457] task: c000000fe29e7600 task.stack: c000001e3ffec000
      [ 7072.863520] NIP: c0000000000e1c78 LR: c0000000000e2e3c CTR: c0000000000e25f0
      [ 7072.863596] REGS: c000001e3ffef560 TRAP: 0300   Not tainted  (4.12.0-kvm+)
      [ 7072.863658] MSR: 9000000100009033 <SF,HV,EE,ME,IR,DR,RI,LE,TM[E]>
      [ 7072.863667]   CR: 44082882  XER: 20000000
      [ 7072.863767] CFAR: c0000000000e2e38 DAR: d000000c250c00f8 DSISR: 42000000 SOFTE: 1
      GPR00: c0000000000e2e3c c000001e3ffef7e0 c000000001407d00 d000000c250c00f0
      GPR04: d00000006509fb70 d00000000b3d2048 0000000003ffdfb7 0000000000000000
      GPR08: 00000001007fdfb7 00000000c000000f d0000000250c0000 000000000070f7bf
      GPR12: 0000000000000008 c00000000fdad000 0000000010879478 00000000105a0d78
      GPR16: 00007ffaf4080000 0000000000001190 0000000000000000 0000000000010000
      GPR20: 4001ffffff000415 d00000006509fb70 0000000004091190 0000000ee1881190
      GPR24: 0000000003ffdfb7 0000000003ffdfb7 00000000007fdfb7 c000000f5c958000
      GPR28: d00000002d09fb70 0000000003ffdfb7 d00000006509fb70 d00000000b3d2048
      [ 7072.864439] NIP [c0000000000e1c78] kvmppc_add_revmap_chain+0x88/0x130
      [ 7072.864503] LR [c0000000000e2e3c] kvmppc_do_h_enter+0x84c/0x9e0
      [ 7072.864566] Call Trace:
      [ 7072.864594] [c000001e3ffef7e0] [c000001e3ffef830] 0xc000001e3ffef830 (unreliable)
      [ 7072.864671] [c000001e3ffef830] [c0000000000e2e3c] kvmppc_do_h_enter+0x84c/0x9e0
      [ 7072.864751] [c000001e3ffef920] [d00000000b38d878] kvmppc_map_vrma+0x168/0x200 [kvm_hv]
      [ 7072.864831] [c000001e3ffef9e0] [d00000000b38a684] kvmppc_vcpu_run_hv+0x1284/0x1300 [kvm_hv]
      [ 7072.864914] [c000001e3ffefb30] [d00000000f465664] kvmppc_vcpu_run+0x44/0x60 [kvm]
      [ 7072.865008] [c000001e3ffefb60] [d00000000f461864] kvm_arch_vcpu_ioctl_run+0x114/0x290 [kvm]
      [ 7072.865152] [c000001e3ffefbe0] [d00000000f453c98] kvm_vcpu_ioctl+0x598/0x7a0 [kvm]
      [ 7072.865292] [c000001e3ffefd40] [c000000000389328] do_vfs_ioctl+0xd8/0x8c0
      [ 7072.865410] [c000001e3ffefde0] [c000000000389be4] SyS_ioctl+0xd4/0x130
      [ 7072.865526] [c000001e3ffefe30] [c00000000000b760] system_call+0x58/0x6c
      [ 7072.865644] Instruction dump:
      [ 7072.865715] e95b2110 793a0020 7b4926e4 7f8a4a14 409e0098 807c000c 786326e4 7c6a1a14
      [ 7072.865857] 935e0008 7bbd0020 813c000c 913e000c <93a30008> 93bc000c 48000038 60000000
      [ 7072.866001] ---[ end trace 627b6e4bf8080edc ]---
      
      Note that to trigger this, it is necessary to use a recent upstream
      QEMU (or other userspace that resizes the HPT at CAS time), specify
      a maximum memory size substantially larger than the current memory
      size, and boot a guest kernel that does not support HPT resizing.
      
      This fixes the problem by resetting the rmap arrays when the old HPT
      is freed.
      
      Fixes: f98a8bf9 ("KVM: PPC: Book3S HV: Allow KVM_PPC_ALLOCATE_HTAB ioctl() to change HPT size")
      Reviewed-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      85fcbf3d