1. 18 Apr, 2017 30 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.10.11 · 4c031101
      Greg Kroah-Hartman authored
      4c031101
    • Marek Szyprowski's avatar
      dma-buf: add support for compat ioctl · 2ef9c8dd
      Marek Szyprowski authored
      commit 888022c0 upstream.
      
      Add compat ioctl support to dma-buf. This lets one to use DMA_BUF_IOCTL_SYNC
      ioctl from 32bit application on 64bit kernel. Data structures for both 32
      and 64bit modes are same, so there is no need for additional translation
      layer.
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Link: http://patchwork.freedesktop.org/patch/msgid/1487683261-2655-1-git-send-email-m.szyprowski@samsung.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ef9c8dd
    • Andrey Konovalov's avatar
      net/packet: fix overflow in check for priv area size · 10e13823
      Andrey Konovalov authored
      commit 2b6867c2 upstream.
      
      Subtracting tp_sizeof_priv from tp_block_size and casting to int
      to check whether one is less then the other doesn't always work
      (both of them are unsigned ints).
      
      Compare them as is instead.
      
      Also cast tp_sizeof_priv to u64 before using BLK_PLUS_PRIV, as
      it can overflow inside BLK_PLUS_PRIV otherwise.
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      10e13823
    • Horia Geantă's avatar
      crypto: caam - fix invalid dereference in caam_rsa_init_tfm() · 50d60091
      Horia Geantă authored
      commit 33fa46d7 upstream.
      
      In case caam_jr_alloc() fails, ctx->dev carries the error code,
      thus accessing it with dev_err() is incorrect.
      
      Fixes: 8c419778 ("crypto: caam - add support for RSA algorithm")
      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>
      50d60091
    • Horia Geantă's avatar
      crypto: caam - fix RNG deinstantiation error checking · 41889ca0
      Horia Geantă authored
      commit 40c98cb5 upstream.
      
      RNG instantiation was previously fixed by
      commit 62743a41 ("crypto: caam - fix RNG init descriptor ret. code checking")
      while deinstantiation was not addressed.
      
      Since the descriptors used are similar, in the sense that they both end
      with a JUMP HALT command, checking for errors should be similar too,
      i.e. status code 7000_0000h should be considered successful.
      
      Fixes: 1005bccd ("crypto: caam - enable instantiation of all RNG4 state handles")
      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>
      41889ca0
    • Matt Redfearn's avatar
      MIPS: IRQ Stack: Fix erroneous jal to plat_irq_dispatch · 8e94a6f4
      Matt Redfearn authored
      commit c25f8064 upstream.
      
      Commit dda45f70 ("MIPS: Switch to the irq_stack in interrupts")
      changed both the normal and vectored interrupt handlers. Unfortunately
      the vectored version, "except_vec_vi_handler", was incorrectly modified
      to unconditionally jal to plat_irq_dispatch, rather than doing a jalr to
      the vectored handler that has been set up. This is ok for many platforms
      which set the vectored handler to plat_irq_dispatch anyway, but will
      cause problems with platforms that use other handlers.
      
      Fixes: dda45f70 ("MIPS: Switch to the irq_stack in interrupts")
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/15110/Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e94a6f4
    • Matt Redfearn's avatar
      MIPS: Select HAVE_IRQ_EXIT_ON_IRQ_STACK · 4a1fe14b
      Matt Redfearn authored
      commit 3cc3434f upstream.
      
      Since do_IRQ is now invoked on a separate IRQ stack, we select
      HAVE_IRQ_EXIT_ON_IRQ_STACK so that softirq's may be invoked directly
      from irq_exit(), rather than requiring do_softirq_own_stack.
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Acked-by: default avatarJason A. Donenfeld <jason@zx2c4.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/14744/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a1fe14b
    • Matt Redfearn's avatar
      MIPS: Switch to the irq_stack in interrupts · 2c7235db
      Matt Redfearn authored
      commit dda45f70 upstream.
      
      When enterring interrupt context via handle_int or except_vec_vi, switch
      to the irq_stack of the current CPU if it is not already in use.
      
      The current stack pointer is masked with the thread size and compared to
      the base or the irq stack. If it does not match then the stack pointer
      is set to the top of that stack, otherwise this is a nested irq being
      handled on the irq stack so the stack pointer should be left as it was.
      
      The in-use stack pointer is placed in the callee saved register s1. It
      will be saved to the stack when plat_irq_dispatch is invoked and can be
      restored once control returns here.
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Acked-by: default avatarJason A. Donenfeld <jason@zx2c4.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/14743/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2c7235db
    • Matt Redfearn's avatar
      MIPS: Only change $28 to thread_info if coming from user mode · b21e28ea
      Matt Redfearn authored
      commit 510d8636 upstream.
      
      The SAVE_SOME macro is used to save the execution context on all
      exceptions.
      If an exception occurs while executing user code, the stack is switched
      to the kernel's stack for the current task, and register $28 is switched
      to point to the current_thread_info, which is at the bottom of the stack
      region.
      If the exception occurs while executing kernel code, the stack is left,
      and this change ensures that register $28 is not updated. This is the
      correct behaviour when the kernel can be executing on the separate irq
      stack, because the thread_info will not be at the base of it.
      
      With this change, register $28 is only switched to it's kernel
      conventional usage of the currrent thread info pointer at the point at
      which execution enters kernel space. Doing it on every exception was
      redundant, but OK without an IRQ stack, but will be erroneous once that
      is introduced.
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Acked-by: default avatarJason A. Donenfeld <jason@zx2c4.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/14742/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b21e28ea
    • Matt Redfearn's avatar
      MIPS: Stack unwinding while on IRQ stack · ece65a60
      Matt Redfearn authored
      commit d42d8d10 upstream.
      
      Within unwind stack, check if the stack pointer being unwound is within
      the CPU's irq_stack and if so use that page rather than the task's stack
      page.
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Acked-by: default avatarJason A. Donenfeld <jason@zx2c4.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
      Cc: Maciej W. Rozycki <macro@imgtec.com>
      Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/14741/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ece65a60
    • Matt Redfearn's avatar
      MIPS: Introduce irq_stack · 6b720ff3
      Matt Redfearn authored
      commit fe8bd18f upstream.
      
      Allocate a per-cpu irq stack for use within interrupt handlers.
      
      Also add a utility function on_irq_stack to determine if a given stack
      pointer is within the irq stack for that cpu.
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Acked-by: default avatarJason A. Donenfeld <jason@zx2c4.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Aaron Tomlin <atomlin@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14740/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b720ff3
    • Stanislaw Gruszka's avatar
      rt2x00usb: do not anchor rx and tx urb's · 612973c5
      Stanislaw Gruszka authored
      commit 93c7018e upstream.
      
      We might kill TX or RX urb during rt2x00usb_flush_entry(), what can
      cause anchor list corruption like shown below:
      
      [ 2074.035633] WARNING: CPU: 2 PID: 14480 at lib/list_debug.c:33 __list_add+0xac/0xc0
      [ 2074.035634] list_add corruption. prev->next should be next (ffff88020f362c28), but was dead000000000100. (prev=ffff8801d161bb70).
      <snip>
      [ 2074.035670] Call Trace:
      [ 2074.035672]  [<ffffffff813bde47>] dump_stack+0x63/0x8c
      [ 2074.035674]  [<ffffffff810a2231>] __warn+0xd1/0xf0
      [ 2074.035676]  [<ffffffff810a22af>] warn_slowpath_fmt+0x5f/0x80
      [ 2074.035678]  [<ffffffffa073855d>] ? rt2x00usb_register_write_lock+0x3d/0x60 [rt2800usb]
      [ 2074.035679]  [<ffffffff813dbe4c>] __list_add+0xac/0xc0
      [ 2074.035681]  [<ffffffff81591c6c>] usb_anchor_urb+0x4c/0xa0
      [ 2074.035683]  [<ffffffffa07322af>] rt2x00usb_kick_rx_entry+0xaf/0x100 [rt2x00usb]
      [ 2074.035684]  [<ffffffffa0732322>] rt2x00usb_clear_entry+0x22/0x30 [rt2x00usb]
      
      To fix do not anchor TX and RX urb's, it is not needed as during
      shutdown we kill those urbs in rt2x00usb_free_entries().
      
      Cc: Vishal Thanki <vishalthanki@gmail.com>
      Fixes: 8b4c0009 ("rt2x00usb: Use usb anchor to manage URB")
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      612973c5
    • Stanislaw Gruszka's avatar
      rt2x00usb: fix anchor initialization · 244ff096
      Stanislaw Gruszka authored
      commit 0488a612 upstream.
      
      If device fail to initialize we can OOPS in rt2x00lib_remove_dev(), due
      to using uninitialized usb_anchor structure:
      
      [  855.435820] ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x1000 with error -19
      [  855.435826] ieee80211 phy3: rt2800_probe_rt: Error - Invalid RT chipset 0x0000, rev 0000 detected
      [  855.435829] ieee80211 phy3: rt2x00lib_probe_dev: Error - Failed to allocate device
      [  855.435845] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
      [  855.435900] IP: _raw_spin_lock_irq+0xd/0x30
      [  855.435926] PGD 0
      [  855.435953] Oops: 0002 [#1] SMP
      <snip>
      [  855.437011] Call Trace:
      [  855.437029]  ? usb_kill_anchored_urbs+0x27/0xc0
      [  855.437061]  rt2x00lib_remove_dev+0x190/0x1c0 [rt2x00lib]
      [  855.437097]  rt2x00lib_probe_dev+0x246/0x7a0 [rt2x00lib]
      [  855.437149]  ? ieee80211_roc_setup+0x9e/0xd0 [mac80211]
      [  855.437183]  ? __kmalloc+0x1af/0x1f0
      [  855.437207]  ? rt2x00usb_probe+0x13d/0xc50 [rt2x00usb]
      [  855.437240]  rt2x00usb_probe+0x155/0xc50 [rt2x00usb]
      [  855.437273]  rt2800usb_probe+0x15/0x20 [rt2800usb]
      [  855.437304]  usb_probe_interface+0x159/0x2d0
      [  855.437333]  driver_probe_device+0x2bb/0x460
      
      Patch changes initialization sequence to fix the problem.
      
      Cc: Vishal Thanki <vishalthanki@gmail.com>
      Fixes: 8b4c0009 ("rt2x00usb: Use usb anchor to manage URB")
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Cc: Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      244ff096
    • Tigran Mkrtchyan's avatar
      nfs: flexfiles: fix kernel OOPS if MDS returns unsupported DS type · df741f77
      Tigran Mkrtchyan authored
      commit f17f8a14 upstream.
      
      this fix aims to fix dereferencing of a mirror in an error state when MDS
      returns unsupported DS type (IOW, not v3), which causes the following oops:
      
      [  220.370709] BUG: unable to handle kernel NULL pointer dereference at 0000000000000065
      [  220.370842] IP: ff_layout_mirror_valid+0x2d/0x110 [nfs_layout_flexfiles]
      [  220.370920] PGD 0
      
      [  220.370972] Oops: 0000 [#1] SMP
      [  220.371013] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth nfs_layout_flexfiles rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_raw ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_security ebtable_filter ebtables ip6table_filter ip6_tables binfmt_misc intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel btrfs kvm arc4 snd_hda_codec_hdmi iwldvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate mac80211 xor uvcvideo
      [  220.371814]  videobuf2_vmalloc videobuf2_memops snd_hda_codec_idt mei_wdt videobuf2_v4l2 snd_hda_codec_generic iTCO_wdt ppdev videobuf2_core iTCO_vendor_support dell_rbtn dell_wmi iwlwifi sparse_keymap dell_laptop dell_smbios snd_hda_intel dcdbas videodev snd_hda_codec dell_smm_hwmon snd_hda_core media cfg80211 intel_uncore snd_hwdep raid6_pq snd_seq intel_rapl_perf snd_seq_device joydev i2c_i801 rfkill lpc_ich snd_pcm parport_pc mei_me parport snd_timer dell_smo8800 mei snd shpchp soundcore tpm_tis tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915 nouveau mxm_wmi ttm i2c_algo_bit drm_kms_helper crc32c_intel e1000e drm sdhci_pci firewire_ohci sdhci serio_raw mmc_core firewire_core ptp crc_itu_t pps_core wmi fjes video
      [  220.372568] CPU: 7 PID: 4988 Comm: cat Not tainted 4.10.5-200.fc25.x86_64 #1
      [  220.372647] Hardware name: Dell Inc. Latitude E6520/0J4TFW, BIOS A06 07/11/2011
      [  220.372729] task: ffff94791f6ea580 task.stack: ffffb72b88c0c000
      [  220.372802] RIP: 0010:ff_layout_mirror_valid+0x2d/0x110 [nfs_layout_flexfiles]
      [  220.372883] RSP: 0018:ffffb72b88c0f970 EFLAGS: 00010246
      [  220.372945] RAX: 0000000000000000 RBX: ffff9479015ca600 RCX: ffffffffffffffed
      [  220.373025] RDX: ffffffffffffffed RSI: ffff9479753dc980 RDI: 0000000000000000
      [  220.373104] RBP: ffffb72b88c0f988 R08: 000000000001c980 R09: ffffffffc0ea6112
      [  220.373184] R10: ffffef17477d9640 R11: ffff9479753dd6c0 R12: ffff9479211c7440
      [  220.373264] R13: ffff9478f45b7790 R14: 0000000000000001 R15: ffff9479015ca600
      [  220.373345] FS:  00007f555fa3e700(0000) GS:ffff9479753c0000(0000) knlGS:0000000000000000
      [  220.373435] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  220.373506] CR2: 0000000000000065 CR3: 0000000196044000 CR4: 00000000000406e0
      [  220.373586] Call Trace:
      [  220.373627]  nfs4_ff_layout_prepare_ds+0x5e/0x200 [nfs_layout_flexfiles]
      [  220.373708]  ff_layout_pg_init_read+0x81/0x160 [nfs_layout_flexfiles]
      [  220.373806]  __nfs_pageio_add_request+0x11f/0x4a0 [nfs]
      [  220.373886]  ? nfs_create_request.part.14+0x37/0x330 [nfs]
      [  220.373967]  nfs_pageio_add_request+0xb2/0x260 [nfs]
      [  220.374042]  readpage_async_filler+0xaf/0x280 [nfs]
      [  220.374103]  read_cache_pages+0xef/0x1b0
      [  220.374166]  ? nfs_read_completion+0x210/0x210 [nfs]
      [  220.374239]  nfs_readpages+0x129/0x200 [nfs]
      [  220.374293]  __do_page_cache_readahead+0x1d0/0x2f0
      [  220.374352]  ondemand_readahead+0x17d/0x2a0
      [  220.374403]  page_cache_sync_readahead+0x2e/0x50
      [  220.374460]  generic_file_read_iter+0x6c8/0x950
      [  220.374532]  ? nfs_mapping_need_revalidate_inode+0x17/0x40 [nfs]
      [  220.374617]  nfs_file_read+0x6e/0xc0 [nfs]
      [  220.374670]  __vfs_read+0xe2/0x150
      [  220.374715]  vfs_read+0x96/0x130
      [  220.374758]  SyS_read+0x55/0xc0
      [  220.374801]  entry_SYSCALL_64_fastpath+0x1a/0xa9
      [  220.374856] RIP: 0033:0x7f555f570bd0
      [  220.374900] RSP: 002b:00007ffeb73e1b38 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
      [  220.374986] RAX: ffffffffffffffda RBX: 00007f555f839ae0 RCX: 00007f555f570bd0
      [  220.375066] RDX: 0000000000020000 RSI: 00007f555fa41000 RDI: 0000000000000003
      [  220.375145] RBP: 0000000000021010 R08: ffffffffffffffff R09: 0000000000000000
      [  220.375226] R10: 00007f555fa40010 R11: 0000000000000246 R12: 0000000000022000
      [  220.375305] R13: 0000000000021010 R14: 0000000000001000 R15: 0000000000002710
      [  220.375386] Code: 66 66 90 55 48 89 e5 41 54 53 49 89 fc 48 83 ec 08 48 85 f6 74 2e 48 8b 4e 30 48 89 f3 48 81 f9 00 f0 ff ff 77 1e 48 85 c9 74 15 <48> 83 79 78 00 b8 01 00 00 00 74 2c 48 83 c4 08 5b 41 5c 5d c3
      [  220.375653] RIP: ff_layout_mirror_valid+0x2d/0x110 [nfs_layout_flexfiles] RSP: ffffb72b88c0f970
      [  220.375748] CR2: 0000000000000065
      [  220.403538] ---[ end trace bcdca752211b7da9 ]---
      Signed-off-by: default avatarTigran Mkrtchyan <tigran.mkrtchyan@desy.de>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df741f77
    • Mike Marshall's avatar
      orangefs: fix buffer size mis-match between kernel space and user space. · f536c205
      Mike Marshall authored
      commit eb68d032 upstream.
      
      The deamon through which the kernel module communicates with the userspace
      part of Orangefs, the "client-core", sends initialization data to the
      kernel module with ioctl. The initialization data was built by the
      client-core in a 2k buffer and copy_from_user'd into a 1k buffer
      in the kernel module. When more than 1k of initialization data needed
      to be sent, some was lost, reducing the usability of the control by which
      debug levels are set. This patch sets the kernel side buffer to 2K to
      match the userspace side...
      Signed-off-by: default avatarMike Marshall <hubcap@omnibond.com>
      Signed-off-by: default avatarMartin Brandenburg <martin@omnibond.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f536c205
    • Mike Marshall's avatar
      orangefs: Dan Carpenter influenced cleanups... · f20e76a4
      Mike Marshall authored
      commit 05973c2e upstream.
      
      This patch is simlar to one Dan Carpenter sent me, cleans
      up some return codes and whitespace errors. There was one
      place where he thought inserting an error message into
      the ring buffer might be too chatty, I hope I convinced him
      othewise. As a consolation <g> I changed a truly chatty
      error message in another location into a debug message,
      system-admins had already yelled at me about that one...
      Signed-off-by: default avatarMike Marshall <hubcap@omnibond.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f20e76a4
    • Ville Syrjälä's avatar
      drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks · b0125207
      Ville Syrjälä authored
      commit b7048ea1 upstream.
      
      Currently ILK-BDW explicitly disable LP1+ watermarks from their
      .init_clock_gating() hooks. Unfortunately that hook gets called way too
      late since by that time we've already initialized all the watermark
      state tracking which then gets out of sync with the hardware state.
      
      We may eventually want to consider killing off the explicit LP1+
      disable from .init_clock_gating(). In the meantime however, we can
      avoid the problem by reordering the init sequence such that
      intel_modeset_init_hw()->intel_init_clock_gating() gets called
      prior to the hardware state takeover.
      
      I suppose prior to the two stage watermark programming we were
      magically saved by something that forced the watermarks to be
      reprogrammed fully after .init_clock_gating() got called. But
      now that no longer happens.
      
      Note that the diff might look a bit odd as it kills off one
      call of intel_update_cdclk(), but that's fine because
      intel_modeset_init_hw() does the exact same thing. Previously
      we just did it twice.
      
      Actually even this new init sequence is pretty bogus as
      .init_clock_gating() really should be called before any gem
      hardware init since it can  configure various clock gating
      workarounds and whatnot that affect the GT side as well. Also
      intel_modeset_init() really should get split up into better
      defined init stages. Another "fun" detail is that
      intel_modeset_gem_init() is where RPS/RC6 gets configured.
      Why that is done from the display code is beyond me. I've
      decided to leave all this be for now, and just try to fix
      the init sequence enough for watermarks to work.
      
      Cc: Gabriele Mazzotta <gabriele.mzt@gmail.com>
      Cc: David Purton <dcpurton@marshwiggle.net>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reported-by: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Reported-by: default avatarDavid Purton <dcpurton@marshwiggle.net>
      Tested-by: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96645
      Fixes: ed4a6a7c ("drm/i915: Add two-stage ILK-style watermark programming (v11)")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170220140443.30891-1-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170315143158.31780-1-ville.syrjala@linux.intel.com
      (cherry picked from commit 5be6e334)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0125207
    • Chris Wilson's avatar
      drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker) · d5b5a4d3
      Chris Wilson authored
      commit 3d3d18f0 upstream.
      
      The rcu_barrier() takes the cpu_hotplug mutex which itself is not
      reclaim-safe, and so rcu_barrier() is illegal from inside the shrinker.
      
      [  309.661373] =========================================================
      [  309.661376] [ INFO: possible irq lock inversion dependency detected ]
      [  309.661380] 4.11.0-rc1-CI-CI_DRM_2333+ #1 Tainted: G        W
      [  309.661383] ---------------------------------------------------------
      [  309.661386] gem_exec_gttfil/6435 just changed the state of lock:
      [  309.661389]  (rcu_preempt_state.barrier_mutex){+.+.-.}, at: [<ffffffff81100731>] _rcu_barrier+0x31/0x160
      [  309.661399] but this lock took another, RECLAIM_FS-unsafe lock in the past:
      [  309.661402]  (cpu_hotplug.lock){+.+.+.}
      [  309.661404]
      
                     and interrupts could create inverse lock ordering between them.
      
      [  309.661410]
                     other info that might help us debug this:
      [  309.661414]  Possible interrupt unsafe locking scenario:
      
      [  309.661417]        CPU0                    CPU1
      [  309.661419]        ----                    ----
      [  309.661421]   lock(cpu_hotplug.lock);
      [  309.661425]                                local_irq_disable();
      [  309.661432]                                lock(rcu_preempt_state.barrier_mutex);
      [  309.661441]                                lock(cpu_hotplug.lock);
      [  309.661446]   <Interrupt>
      [  309.661448]     lock(rcu_preempt_state.barrier_mutex);
      [  309.661453]
                      *** DEADLOCK ***
      
      [  309.661460] 4 locks held by gem_exec_gttfil/6435:
      [  309.661464]  #0:  (sb_writers#10){.+.+.+}, at: [<ffffffff8120d83d>] vfs_write+0x17d/0x1f0
      [  309.661475]  #1:  (debugfs_srcu){......}, at: [<ffffffff81320491>] debugfs_use_file_start+0x41/0xa0
      [  309.661486]  #2:  (&attr->mutex){+.+.+.}, at: [<ffffffff8123a3e7>] simple_attr_write+0x37/0xe0
      [  309.661495]  #3:  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0091b4a>] i915_drop_caches_set+0x3a/0x150 [i915]
      [  309.661540]
                     the shortest dependencies between 2nd lock and 1st lock:
      [  309.661547]  -> (cpu_hotplug.lock){+.+.+.} ops: 829 {
      [  309.661553]     HARDIRQ-ON-W at:
      [  309.661560]                       __lock_acquire+0x5e5/0x1b50
      [  309.661565]                       lock_acquire+0xc9/0x220
      [  309.661572]                       __mutex_lock+0x6e/0x990
      [  309.661576]                       mutex_lock_nested+0x16/0x20
      [  309.661583]                       get_online_cpus+0x61/0x80
      [  309.661590]                       kmem_cache_create+0x25/0x1d0
      [  309.661596]                       debug_objects_mem_init+0x30/0x249
      [  309.661602]                       start_kernel+0x341/0x3fe
      [  309.661607]                       x86_64_start_reservations+0x2a/0x2c
      [  309.661612]                       x86_64_start_kernel+0x173/0x186
      [  309.661619]                       verify_cpu+0x0/0xfc
      [  309.661622]     SOFTIRQ-ON-W at:
      [  309.661627]                       __lock_acquire+0x611/0x1b50
      [  309.661632]                       lock_acquire+0xc9/0x220
      [  309.661636]                       __mutex_lock+0x6e/0x990
      [  309.661641]                       mutex_lock_nested+0x16/0x20
      [  309.661646]                       get_online_cpus+0x61/0x80
      [  309.661650]                       kmem_cache_create+0x25/0x1d0
      [  309.661655]                       debug_objects_mem_init+0x30/0x249
      [  309.661660]                       start_kernel+0x341/0x3fe
      [  309.661664]                       x86_64_start_reservations+0x2a/0x2c
      [  309.661669]                       x86_64_start_kernel+0x173/0x186
      [  309.661674]                       verify_cpu+0x0/0xfc
      [  309.661677]     RECLAIM_FS-ON-W at:
      [  309.661682]                          mark_held_locks+0x6f/0xa0
      [  309.661687]                          lockdep_trace_alloc+0xb3/0x100
      [  309.661693]                          kmem_cache_alloc_trace+0x31/0x2e0
      [  309.661699]                          __smpboot_create_thread.part.1+0x27/0xe0
      [  309.661704]                          smpboot_create_threads+0x61/0x90
      [  309.661709]                          cpuhp_invoke_callback+0x9c/0x8a0
      [  309.661713]                          cpuhp_up_callbacks+0x31/0xb0
      [  309.661718]                          _cpu_up+0x7a/0xc0
      [  309.661723]                          do_cpu_up+0x5f/0x80
      [  309.661727]                          cpu_up+0xe/0x10
      [  309.661734]                          smp_init+0x71/0xb3
      [  309.661738]                          kernel_init_freeable+0x94/0x19e
      [  309.661743]                          kernel_init+0x9/0xf0
      [  309.661748]                          ret_from_fork+0x2e/0x40
      [  309.661752]     INITIAL USE at:
      [  309.661757]                      __lock_acquire+0x234/0x1b50
      [  309.661761]                      lock_acquire+0xc9/0x220
      [  309.661766]                      __mutex_lock+0x6e/0x990
      [  309.661771]                      mutex_lock_nested+0x16/0x20
      [  309.661775]                      get_online_cpus+0x61/0x80
      [  309.661780]                      __cpuhp_setup_state+0x44/0x170
      [  309.661785]                      page_alloc_init+0x23/0x3a
      [  309.661790]                      start_kernel+0x124/0x3fe
      [  309.661794]                      x86_64_start_reservations+0x2a/0x2c
      [  309.661799]                      x86_64_start_kernel+0x173/0x186
      [  309.661804]                      verify_cpu+0x0/0xfc
      [  309.661807]   }
      [  309.661813]   ... key      at: [<ffffffff81e37690>] cpu_hotplug+0xb0/0x100
      [  309.661817]   ... acquired at:
      [  309.661821]    lock_acquire+0xc9/0x220
      [  309.661825]    __mutex_lock+0x6e/0x990
      [  309.661829]    mutex_lock_nested+0x16/0x20
      [  309.661833]    get_online_cpus+0x61/0x80
      [  309.661837]    _rcu_barrier+0x9f/0x160
      [  309.661841]    rcu_barrier+0x10/0x20
      [  309.661847]    netdev_run_todo+0x5f/0x310
      [  309.661852]    rtnl_unlock+0x9/0x10
      [  309.661856]    default_device_exit_batch+0x133/0x150
      [  309.661862]    ops_exit_list.isra.0+0x4d/0x60
      [  309.661866]    cleanup_net+0x1d8/0x2c0
      [  309.661872]    process_one_work+0x1f4/0x6d0
      [  309.661876]    worker_thread+0x49/0x4a0
      [  309.661881]    kthread+0x107/0x140
      [  309.661884]    ret_from_fork+0x2e/0x40
      
      [  309.661890] -> (rcu_preempt_state.barrier_mutex){+.+.-.} ops: 179 {
      [  309.661896]    HARDIRQ-ON-W at:
      [  309.661901]                     __lock_acquire+0x5e5/0x1b50
      [  309.661905]                     lock_acquire+0xc9/0x220
      [  309.661910]                     __mutex_lock+0x6e/0x990
      [  309.661914]                     mutex_lock_nested+0x16/0x20
      [  309.661919]                     _rcu_barrier+0x31/0x160
      [  309.661923]                     rcu_barrier+0x10/0x20
      [  309.661928]                     netdev_run_todo+0x5f/0x310
      [  309.661932]                     rtnl_unlock+0x9/0x10
      [  309.661936]                     default_device_exit_batch+0x133/0x150
      [  309.661941]                     ops_exit_list.isra.0+0x4d/0x60
      [  309.661946]                     cleanup_net+0x1d8/0x2c0
      [  309.661951]                     process_one_work+0x1f4/0x6d0
      [  309.661955]                     worker_thread+0x49/0x4a0
      [  309.661960]                     kthread+0x107/0x140
      [  309.661964]                     ret_from_fork+0x2e/0x40
      [  309.661968]    SOFTIRQ-ON-W at:
      [  309.661972]                     __lock_acquire+0x611/0x1b50
      [  309.661977]                     lock_acquire+0xc9/0x220
      [  309.661981]                     __mutex_lock+0x6e/0x990
      [  309.661986]                     mutex_lock_nested+0x16/0x20
      [  309.661990]                     _rcu_barrier+0x31/0x160
      [  309.661995]                     rcu_barrier+0x10/0x20
      [  309.661999]                     netdev_run_todo+0x5f/0x310
      [  309.662003]                     rtnl_unlock+0x9/0x10
      [  309.662008]                     default_device_exit_batch+0x133/0x150
      [  309.662013]                     ops_exit_list.isra.0+0x4d/0x60
      [  309.662017]                     cleanup_net+0x1d8/0x2c0
      [  309.662022]                     process_one_work+0x1f4/0x6d0
      [  309.662027]                     worker_thread+0x49/0x4a0
      [  309.662031]                     kthread+0x107/0x140
      [  309.662035]                     ret_from_fork+0x2e/0x40
      [  309.662039]    IN-RECLAIM_FS-W at:
      [  309.662043]                        __lock_acquire+0x638/0x1b50
      [  309.662048]                        lock_acquire+0xc9/0x220
      [  309.662053]                        __mutex_lock+0x6e/0x990
      [  309.662058]                        mutex_lock_nested+0x16/0x20
      [  309.662062]                        _rcu_barrier+0x31/0x160
      [  309.662067]                        rcu_barrier+0x10/0x20
      [  309.662089]                        i915_gem_shrink_all+0x33/0x40 [i915]
      [  309.662109]                        i915_drop_caches_set+0x141/0x150 [i915]
      [  309.662114]                        simple_attr_write+0xc7/0xe0
      [  309.662119]                        full_proxy_write+0x4f/0x70
      [  309.662124]                        __vfs_write+0x23/0x120
      [  309.662128]                        vfs_write+0xc6/0x1f0
      [  309.662133]                        SyS_write+0x44/0xb0
      [  309.662138]                        entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  309.662142]    INITIAL USE at:
      [  309.662147]                    __lock_acquire+0x234/0x1b50
      [  309.662151]                    lock_acquire+0xc9/0x220
      [  309.662156]                    __mutex_lock+0x6e/0x990
      [  309.662160]                    mutex_lock_nested+0x16/0x20
      [  309.662165]                    _rcu_barrier+0x31/0x160
      [  309.662169]                    rcu_barrier+0x10/0x20
      [  309.662174]                    netdev_run_todo+0x5f/0x310
      [  309.662178]                    rtnl_unlock+0x9/0x10
      [  309.662183]                    default_device_exit_batch+0x133/0x150
      [  309.662188]                    ops_exit_list.isra.0+0x4d/0x60
      [  309.662192]                    cleanup_net+0x1d8/0x2c0
      [  309.662197]                    process_one_work+0x1f4/0x6d0
      [  309.662202]                    worker_thread+0x49/0x4a0
      [  309.662206]                    kthread+0x107/0x140
      [  309.662210]                    ret_from_fork+0x2e/0x40
      [  309.662214]  }
      [  309.662220]  ... key      at: [<ffffffff81e4e1c8>] rcu_preempt_state+0x508/0x780
      [  309.662225]  ... acquired at:
      [  309.662229]    check_usage_forwards+0x12b/0x130
      [  309.662233]    mark_lock+0x360/0x6f0
      [  309.662237]    __lock_acquire+0x638/0x1b50
      [  309.662241]    lock_acquire+0xc9/0x220
      [  309.662245]    __mutex_lock+0x6e/0x990
      [  309.662249]    mutex_lock_nested+0x16/0x20
      [  309.662253]    _rcu_barrier+0x31/0x160
      [  309.662257]    rcu_barrier+0x10/0x20
      [  309.662279]    i915_gem_shrink_all+0x33/0x40 [i915]
      [  309.662298]    i915_drop_caches_set+0x141/0x150 [i915]
      [  309.662303]    simple_attr_write+0xc7/0xe0
      [  309.662307]    full_proxy_write+0x4f/0x70
      [  309.662311]    __vfs_write+0x23/0x120
      [  309.662315]    vfs_write+0xc6/0x1f0
      [  309.662319]    SyS_write+0x44/0xb0
      [  309.662323]    entry_SYSCALL_64_fastpath+0x1c/0xb1
      
      [  309.662329]
                     stack backtrace:
      [  309.662335] CPU: 1 PID: 6435 Comm: gem_exec_gttfil Tainted: G        W       4.11.0-rc1-CI-CI_DRM_2333+ #1
      [  309.662342] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011
      [  309.662348] Call Trace:
      [  309.662354]  dump_stack+0x67/0x92
      [  309.662359]  print_irq_inversion_bug.part.19+0x1a4/0x1b0
      [  309.662365]  check_usage_forwards+0x12b/0x130
      [  309.662369]  mark_lock+0x360/0x6f0
      [  309.662374]  ? print_shortest_lock_dependencies+0x1a0/0x1a0
      [  309.662379]  __lock_acquire+0x638/0x1b50
      [  309.662383]  ? __mutex_unlock_slowpath+0x3e/0x2e0
      [  309.662388]  ? trace_hardirqs_on+0xd/0x10
      [  309.662392]  ? _rcu_barrier+0x31/0x160
      [  309.662396]  lock_acquire+0xc9/0x220
      [  309.662400]  ? _rcu_barrier+0x31/0x160
      [  309.662404]  ? _rcu_barrier+0x31/0x160
      [  309.662409]  __mutex_lock+0x6e/0x990
      [  309.662412]  ? _rcu_barrier+0x31/0x160
      [  309.662416]  ? _rcu_barrier+0x31/0x160
      [  309.662421]  ? synchronize_rcu_expedited+0x35/0xb0
      [  309.662426]  ? _raw_spin_unlock_irqrestore+0x52/0x60
      [  309.662434]  mutex_lock_nested+0x16/0x20
      [  309.662438]  _rcu_barrier+0x31/0x160
      [  309.662442]  rcu_barrier+0x10/0x20
      [  309.662464]  i915_gem_shrink_all+0x33/0x40 [i915]
      [  309.662484]  i915_drop_caches_set+0x141/0x150 [i915]
      [  309.662489]  simple_attr_write+0xc7/0xe0
      [  309.662494]  full_proxy_write+0x4f/0x70
      [  309.662498]  __vfs_write+0x23/0x120
      [  309.662503]  ? rcu_read_lock_sched_held+0x75/0x80
      [  309.662507]  ? rcu_sync_lockdep_assert+0x2a/0x50
      [  309.662512]  ? __sb_start_write+0x102/0x210
      [  309.662516]  ? vfs_write+0x17d/0x1f0
      [  309.662520]  vfs_write+0xc6/0x1f0
      [  309.662524]  ? trace_hardirqs_on_caller+0xe7/0x200
      [  309.662529]  SyS_write+0x44/0xb0
      [  309.662533]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  309.662537] RIP: 0033:0x7f507eac24a0
      [  309.662541] RSP: 002b:00007fffda8720e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [  309.662548] RAX: ffffffffffffffda RBX: ffffffff81482bd3 RCX: 00007f507eac24a0
      [  309.662552] RDX: 0000000000000005 RSI: 00007fffda8720f0 RDI: 0000000000000005
      [  309.662557] RBP: ffffc9000048bf88 R08: 0000000000000000 R09: 000000000000002c
      [  309.662561] R10: 0000000000000014 R11: 0000000000000246 R12: 00007fffda872230
      [  309.662566] R13: 00007fffda872228 R14: 0000000000000201 R15: 00007fffda8720f0
      [  309.662572]  ? __this_cpu_preempt_check+0x13/0x20
      
      Fixes: 0eafec6d ("drm/i915: Enable lockless lookup of request tracking via RCU")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100192Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170314115019.18127-1-chris@chris-wilson.co.ukReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      (cherry picked from commit bd784b7c)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170321144531.12344-1-chris@chris-wilson.co.ukSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5b5a4d3
    • Chris Wilson's avatar
      drm/i915: Stop using RP_DOWN_EI on Baytrail · de357161
      Chris Wilson authored
      commit 8f68d591 upstream.
      
      On Baytrail, we manually calculate busyness over the evaluation interval
      to avoid issues with miscaluations with RC6 enabled. However, it turns
      out that the DOWN_EI interrupt generator is completely bust - it
      operates in two modes, continuous or never. Neither of which are
      conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
      compute everything from the UP_EI which does seem to correspond to the
      desired interval.
      
      v2: Fixup gen6_rps_pm_mask() as well
      v3: Inline vlv_c0_above() to combine the now identical elapsed
      calculation for up/down and simplify the threshold testing
      
      Fixes: 43cf3bf0 ("drm/i915: Improved w/a for rps on Baytrail")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-1-chris@chris-wilson.co.ukReviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170313170617.31564-1-chris@chris-wilson.co.uk
      (cherry picked from commit e0e8c7cb)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de357161
    • Kenneth Graunke's avatar
      drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters. · 29abfd4e
      Kenneth Graunke authored
      commit 0f5418e5 upstream.
      
      This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0
      (indicating the optional feature is not supported), and makes execbuf
      always return -EINVAL if the flags are used.
      
      Apparently, no userspace ever shipped which used this optional feature:
      I checked the git history of Mesa, xf86-video-intel, libva, and Beignet,
      and there were zero commits showing a use of these flags.  Kernel commit
      72bfa19c apparently introduced the feature prematurely.  According
      to Chris, the intention was to use this in cairo-drm, but "the use was
      broken for gen6", so I don't think it ever happened.
      
      'relative_constants_mode' has always been tracked per-device, but this
      has actually been wrong ever since hardware contexts were introduced, as
      the INSTPM register is saved (and automatically restored) as part of the
      render ring context. The software per-device value could therefore get
      out of sync with the hardware per-context value.  This meant that using
      them is actually unsafe: a client which tried to use them could damage
      the state of other clients, causing the GPU to interpret their BO
      offsets as absolute pointers, leading to bogus memory reads.
      
      These flags were also never ported to execlist mode, making them no-ops
      on Gen9+ (which requires execlists), and Gen8 in the default mode.
      
      On Gen8+, userspace can write these registers directly, achieving the
      same effect.  On Gen6-7.5, it likely makes sense to extend the command
      parser to support them.  I don't think anyone wants this on Gen4-5.
      
      Based on a patch by Dave Gordon.
      
      v3: Return -ENODEV for the getparam, as this is what we do for other
          obsolete features.  Suggested by Chris Wilson.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448Signed-off-by: default avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170215093446.21291-1-kenneth@whitecape.orgAcked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170313170433.26843-1-chris@chris-wilson.co.uk
      (cherry picked from commit ef0f411f)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29abfd4e
    • Chris Wilson's avatar
      drm/i915: Only enable hotplug interrupts if the display interrupts are enabled · b364cf79
      Chris Wilson authored
      commit 35a3abfd upstream.
      
      In order to prevent accessing the hpd registers outside of the display
      power wells, we should refrain from writing to the registers before the
      display interrupts are enabled.
      
      [    4.740136] WARNING: CPU: 1 PID: 221 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x44/0x50 [i915]
      [    4.740155] Unclaimed read from register 0x1e1110
      [    4.740168] Modules linked in: i915(+) intel_gtt drm_kms_helper prime_numbers
      [    4.740190] CPU: 1 PID: 221 Comm: systemd-udevd Not tainted 4.10.0-rc6+ #384
      [    4.740203] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
      [    4.740220] Call Trace:
      [    4.740236]  dump_stack+0x4d/0x6f
      [    4.740251]  __warn+0xc1/0xe0
      [    4.740265]  warn_slowpath_fmt+0x4a/0x50
      [    4.740281]  ? insert_work+0x77/0xc0
      [    4.740355]  ? fwtable_write32+0x90/0x130 [i915]
      [    4.740431]  __unclaimed_reg_debug+0x44/0x50 [i915]
      [    4.740507]  fwtable_read32+0xd8/0x130 [i915]
      [    4.740575]  i915_hpd_irq_setup+0xa5/0x100 [i915]
      [    4.740649]  intel_hpd_init+0x68/0x80 [i915]
      [    4.740716]  i915_driver_load+0xe19/0x1380 [i915]
      [    4.740784]  i915_pci_probe+0x32/0x90 [i915]
      [    4.740799]  pci_device_probe+0x8b/0xf0
      [    4.740815]  driver_probe_device+0x2b6/0x450
      [    4.740828]  __driver_attach+0xda/0xe0
      [    4.740841]  ? driver_probe_device+0x450/0x450
      [    4.740853]  bus_for_each_dev+0x5b/0x90
      [    4.740865]  driver_attach+0x19/0x20
      [    4.740878]  bus_add_driver+0x166/0x260
      [    4.740892]  driver_register+0x5b/0xd0
      [    4.740906]  ? 0xffffffffa0166000
      [    4.740920]  __pci_register_driver+0x47/0x50
      [    4.740985]  i915_init+0x5c/0x5e [i915]
      [    4.740999]  do_one_initcall+0x3e/0x160
      [    4.741015]  ? __vunmap+0x7c/0xc0
      [    4.741029]  ? kmem_cache_alloc+0xcf/0x120
      [    4.741045]  do_init_module+0x55/0x1c4
      [    4.741060]  load_module+0x1f3f/0x25b0
      [    4.741073]  ? __symbol_put+0x40/0x40
      [    4.741086]  ? kernel_read_file+0x100/0x190
      [    4.741100]  SYSC_finit_module+0xbc/0xf0
      [    4.741112]  SyS_finit_module+0x9/0x10
      [    4.741125]  entry_SYSCALL_64_fastpath+0x17/0x98
      [    4.741135] RIP: 0033:0x7f8559a140f9
      [    4.741145] RSP: 002b:00007fff7509a3e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      [    4.741161] RAX: ffffffffffffffda RBX: 00007f855aba02d1 RCX: 00007f8559a140f9
      [    4.741172] RDX: 0000000000000000 RSI: 000055b6db0914f0 RDI: 0000000000000011
      [    4.741183] RBP: 0000000000020000 R08: 0000000000000000 R09: 000000000000000e
      [    4.741193] R10: 0000000000000011 R11: 0000000000000246 R12: 000055b6db0854d0
      [    4.741204] R13: 000055b6db091150 R14: 0000000000000000 R15: 000055b6db035924
      
      v2: Set dev_priv->display_irqs_enabled to true for all platforms other
      than vlv/chv that manually control the display power domain.
      
      Fixes: 19625e85 ("drm/i915: Enable polling when we don't have hpd")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97798Suggested-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Lyude <cpaul@redhat.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Hans de Goede <jwrdegoede@fedoraproject.org>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170215131547.5064-1-chris@chris-wilson.co.uk
      Link: http://patchwork.freedesktop.org/patch/msgid/20170313170231.18633-1-chris@chris-wilson.co.uk
      (cherry picked from commit 262fd485)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b364cf79
    • Ville Syrjälä's avatar
      drm/i915: Reject HDMI 12bpc if the sink doesn't indicate support · 56613bca
      Ville Syrjälä authored
      commit 9c31b087 upstream.
      
      Check that the sink really declared 12bpc support before we enable it.
      This should not actually never happen since it's mandatory for HDMI
      sinks to support 12bpc if they support any deep color modes. But
      reality disagrees with the theory and there are actually sinks in
      the wild that violate the spec.
      
      v2: Fix the output_types check
          Update commit message to state that these things are in fact real
      
      Cc: Nicholas Sielicki <nicholas.sielicki@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99250Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170213175818.24958-1-ville.syrjala@linux.intel.comReviewed-by: default avatarShashank Sharma <shashank.sharma@intel.com>
      (cherry picked from commit c750bdd3)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56613bca
    • Mika Kuoppala's avatar
      drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3 · dba29c11
      Mika Kuoppala authored
      commit 34dc8993 upstream.
      
      Certain Baytrails, namely the 4 cpu core variants, have been
      plaqued by spurious system hangs, mostly occurring with light loads.
      
      Multiple bisects by various people point to a commit which changes the
      reclocking strategy for Baytrail to follow its bigger brethen:
      commit 8fb55197 ("drm/i915: Agressive downclocking on Baytrail")
      
      There is also a review comment attached to this commit from Deepak S
      on avoiding punit access on Cherryview and thus it was excluded on
      common reclocking path. By taking the same approach and omitting
      the punit access by not tweaking the thresholds when the hardware
      has been asked to move into different frequency, considerable gains
      in stability have been observed.
      
      With J1900 box, light render/video load would end up in system hang
      in usually less than 12 hours. With this patch applied, the cumulative
      uptime has now been 34 days without issues. To provoke system hang,
      light loads on both render and bsd engines in parallel have been used:
      glxgears >/dev/null 2>/dev/null &
      mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4
      
      So far, author has not witnessed system hang with above load
      and this patch applied. Reports from the tenacious people at
      kernel bugzilla are also promising.
      
      Considering that the punit access frequency with this patch is
      considerably less, there is a possibility that this will push
      the, still unknown, root cause past the triggering point on most loads.
      
      But as we now can reliably reproduce the hang independently,
      we can reduce the pain that users are having and use a
      static thresholds until a root cause is found.
      
      v3: don't break debugfs and simplification (Chris Wilson)
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: fritsch@xbmc.org
      Cc: miku@iki.fi
      Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
      CC: Michal Feix <michal@feix.cz>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Deepak S <deepak.s@linux.intel.com>
      Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1487166779-26945-1-git-send-email-mika.kuoppala@intel.com
      (cherry picked from commit 6067a27d)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dba29c11
    • Ville Syrjälä's avatar
      drm/i915: Nuke debug messages from the pipe update critical section · fccb5940
      Ville Syrjälä authored
      commit edd06b83 upstream.
      
      printks are slow so we should not be doing them from the vblank evade
      critical section. These could explain why we sometimes seem to
      blow past our 100 usec deadline.
      
      The problem has been there ever since commit bfd16b2a ("drm/i915:
      Make updating pipe without modeset atomic.") but it may not have
      been readily visible until commit e1edbd44 ("drm/i915: Complain
      if we take too long under vblank evasion.") increased our chances
      of noticing it.
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Fixes: bfd16b2a ("drm/i915: Make updating pipe without modeset atomic.")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170307205419.19447-1-ville.syrjala@linux.intel.comReviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      (cherry picked from commit c3f8ad57)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fccb5940
    • Chris Wilson's avatar
      drm/i915: Store a permanent error in obj->mm.pages · 29a9a6a3
      Chris Wilson authored
      commit 0d9dc306 upstream.
      
      Once the object has been truncated, it is unrecoverable. To facilitate
      detection of this state store the error in obj->mm.pages.
      
      This is required for the next patch which should be applied to v4.10
      (via stable), so we also need to mark this patch for backporting. In
      that regard, let's consider this to be a fix/improvement too.
      
      v2: Avoid dereferencing the ERR_PTR when freeing the object.
      
      Fixes: 1233e2db ("drm/i915: Move object backing storage manipulation to its own locking")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170307132031.32461-1-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      (cherry picked from commit 4e5462ee)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29a9a6a3
    • Imre Deak's avatar
      drm/i915/gen9: Increase PCODE request timeout to 50ms · 432ae452
      Imre Deak authored
      commit d253371c upstream.
      
      After
      commit 2c7d0602
      Author: Imre Deak <imre.deak@intel.com>
      Date:   Mon Dec 5 18:27:37 2016 +0200
      
          drm/i915/gen9: Fix PCODE polling during CDCLK change notification
      
      there is still one report of the CDCLK-change request timing out on a
      KBL machine, see the Reference link. On that machine the maximum time
      the request took to succeed was 34ms, so increase the timeout to 50ms.
      
      v2:
      - Change timeout from 100 to 50 ms to maintain the current 50 ms limit
        for atomic waits in the driver. (Chris, Tvrtko)
      
      Reference: https://bugs.freedesktop.org/show_bug.cgi?id=99345
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1487946730-17162-1-git-send-email-imre.deak@intel.com
      (cherry picked from commit 0129936d)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      432ae452
    • Chris Wilson's avatar
      drm/i915: Squelch any ktime/jiffie rounding errors for wait-ioctl · b93cb4cc
      Chris Wilson authored
      commit 89cf83d4 upstream.
      
      We wait upon jiffies, but report the time elapsed using a
      high-resolution timer. This discrepancy can lead to us timing out the
      wait prior to us reporting the elapsed time as complete.
      
      This restores the squelching lost in commit e95433c7 ("drm/i915:
      Rearrange i915_wait_request() accounting with callers").
      
      Fixes: e95433c7 ("drm/i915: Rearrange i915_wait_request() accounting with callers")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Matthew Auld <matthew.william.auld@gmail.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
      Link: http://patchwork.freedesktop.org/patch/msgid/20170216125441.30923-1-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      (cherry picked from commit c1d2061b)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b93cb4cc
    • Chris Wilson's avatar
      drm/i915/fbdev: Stop repeating tile configuration on stagnation · ec417098
      Chris Wilson authored
      commit b717a039 upstream.
      
      If we cease making progress in finding matching outputs for a tiled
      configuration, stop looping over the remaining unconfigured outputs.
      
      v2: Use conn_seq (instead of pass) to only apply tile configuration on
      first pass.
      
      Fixes: b0ee9e7f ("drm/fb: add support for tiled monitor configurations. (v2)")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tomasz Lis <tomasz.lis@intel.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Reviewed-by: default avatarTomasz Lis <tomasz.lis@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170224114306.4400-1-chris@chris-wilson.co.uk
      (cherry picked from commit 754a7659)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec417098
    • Maarten Lankhorst's avatar
      drm/i915: Move updating color management to before vblank evasion · 4f985d41
      Maarten Lankhorst authored
      commit 38230243 upstream.
      
      This cannot be done reliably during vblank evasasion
      since the color management registers are not double buffered.
      
      The original commit that moved it always during vblank evasion was
      wrong, so revert it to before vblank evasion again.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Fixes: 20a34e78 ("drm/i915: Update color management during vblank evasion.")
      Link: http://patchwork.freedesktop.org/patch/msgid/1488292128-14540-1-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      (cherry picked from commit 567f0792)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f985d41
    • Tvrtko Ursulin's avatar
      drm/i915: Fix forcewake active domain tracking · a8a20aec
      Tvrtko Ursulin authored
      commit 6aef6603 upstream.
      
      In commit 003342a5 ("drm/i915: Keep track of active
      forcewake domains in a bitmask") I forgot to adjust the
      newly introduce fw_domains_active state across reset.
      
      This caused the assert_forcewakes_inactive to trigger
      during suspend and resume if there were user held
      forcewakes.
      
      v2: Bitmask checks are required since vfuncs are not
          always present.
      
      v3: Move bitmask tracking to get/put vfunc for simplicity.
          (Chris Wilson)
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Fixes: 003342a5 ("drm/i915: Keep track of active forcewake domains in a bitmask")
      Testcase: igt/drv_suspend/forcewake
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: "Paneri, Praveen" <praveen.paneri@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170310093249.4484-1-tvrtko.ursulin@linux.intel.com
      (cherry picked from commit b8473050)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8a20aec
  2. 12 Apr, 2017 10 commits