1. 30 Nov, 2017 20 commits
  2. 29 Nov, 2017 2 commits
  3. 28 Nov, 2017 13 commits
    • Linus Torvalds's avatar
      Merge tag 'drm-for-v4.15-part2-fixes' of git://people.freedesktop.org/~airlied/linux · 43f462f1
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
      
       - TTM regression fix for some virt gpus (bochs vga)
      
       - a few i915 stable fixes
      
       - one vc4 fix
      
       - one uapi fix
      
      * tag 'drm-for-v4.15-part2-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/ttm: don't attempt to use hugepages if dma32 requested (v2)
        drm/vblank: Pass crtc_id to page_flip_ioctl.
        drm/i915: Fix init_clock_gating for resume
        drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM
        drm/i915: Clear breadcrumb node when cancelling signaling
        drm/i915/gvt: ensure -ve return value is handled correctly
        drm/i915: Re-register PMIC bus access notifier on runtime resume
        drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2
        drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
        drm/vc4: Account for interrupts in flight
      43f462f1
    • Takashi Iwai's avatar
      Revert "ALSA: usb-audio: Fix potential zero-division at parsing FU" · 3c02a6d9
      Takashi Iwai authored
      The commit 8428a8eb ("ALSA: usb-audio: Fix potential zero-division
      at parsing FU") is utterly bogus and breaks the case with csize=1
      instead of fixing anything.  Just take it back again.
      Reported-by: default avatarJörg Otte <jrg.otte@gmail.com>
      Fixes: 8428a8eb ("ALSA: usb-audio: Fix potential zero-division at parsing FU"
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3c02a6d9
    • Joonas Lahtinen's avatar
      Merge tag 'gvt-fixes-2017-11-28' of https://github.com/intel/gvt-linux into drm-intel-fixes · 05dfe9f2
      Joonas Lahtinen authored
      gvt-fixes-2017-11-28
      
      - regression fix for sane request alloc (Fred)
      - locking fix (Changbin)
      - fix invalid addr mask (Xiong)
      - compression regression fix (Weinan)
      - fix default pipe enable for virtual display (Xiaolin)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      05dfe9f2
    • Xiong Zhang's avatar
      drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition · b721b65a
      Xiong Zhang authored
      For ADDR_4K_MASK, bit[45..12] should be 1, all other bits
      should be 0. The current definition wrongly set bit[46] as 1
      also. This path fixes this.
      
      v2: Add commit message, fixes and cc stable.(Zhenyu)
      
      Fixes: 2707e444("drm/i915/gvt: vGPU graphics memory virtualization")
      Signed-off-by: default avatarXiong Zhang <xiong.y.zhang@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      b721b65a
    • Xiaolin Zhang's avatar
      drm/i915/gvt: enabled pipe A default on creating vgpu · 7e605902
      Xiaolin Zhang authored
      when i915 driver unloading, it will shutdown all CRTCs and
      it will introudce kernel panic when conducting igt drv_module_reload
      test case under guest environment (bug reported by XENGT-468) as below:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
      IP: intel_edp_backlight_off+0xe/0x7c [i915]
      RIP: 0010:intel_edp_backlight_off+0xe/0x7c [i915]
      Call Trace:
       intel_disable_ddi+0xb3/0xbc [i915]
       intel_modeset_setup_hw_state+0x654/0xb4c [i915]
       intel_modeset_init+0x9f1/0xe69 [i915]
       ? intel_i2c_reset+0x3d/0x40 [i915]
       ? intel_setup_gmbus+0xba/0x249 [i915]
       i915_driver_load+0xae5/0xcc0 [i915]
       i915_pci_probe+0x3a/0x3c [i915]
       local_pci_probe+0x38/0x7b
       pci_device_probe+0xec/0x12b
       driver_probe_device+0x134/0x294
       __driver_attach+0x6a/0x8c
       ? driver_probe_device+0x294/0x294
       bus_for_each_dev+0x68/0x80
       driver_attach+0x19/0x1b
       bus_add_driver+0xea/0x1d3
       ? 0xffffffffa03cd000
       driver_register+0x85/0xc1
       ? 0xffffffffa03cd000
       __pci_register_driver+0x55/0x57
       i915_init+0x57/0x5a [i915]
       do_one_initcall+0x8a/0x12e
       ? __vunmap+0x8d/0x93
       ? kmem_cache_alloc_trace+0x96/0x11c
       do_init_module+0x5a/0x1e1
      
      in this case, active connector detected but no active pipe
      available, so it will hang to disable connector.
      
      to fix, on vgpu creating, to report active pipe available for
      guest.
      Signed-off-by: default avatarXiaolin Zhang <xiaolin.zhang@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      7e605902
    • fred gao's avatar
      drm/i915/gvt: Move request alloc to dispatch_workload path only · c3c80f07
      fred gao authored
      Previously the performance is improved through the workload auditing
      and shadowing ahead of vGPU scheduling, however, there is the case that
      more requests are allocated in submit_context before the previous request
      is added, the timeline will hold its seqno which is later.
      
      This patch is to move the request alloc to dispatch_workload function,
      where is the same place as request is added.
      
      It will fix the issue of kernel BUG for (timeline->seqno != request->fence.seqno)
      check when add_request.
      
      Fixes: 89ea20b9 ("drm/i915/gvt: Factor out scan and shadow from workload dispatch")
      Signed-off-by: default avatarChuanxiao Dong <chuanxiao.dong@intel.com>
      Signed-off-by: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      (cherry picked from commit f2880e04)
      c3c80f07
    • Weinan Li's avatar
      drm/i915/gvt: remove skl_misc_ctl_write handler · bf3a26b3
      Weinan Li authored
      With different settings of compressed data hash mode between VMs and host
      may cause gpu issues.
      
      Commit: 1999f108 ("drm/i915/gvt: Disable compression workaround for Gen9")
      disable compression workaround of guest in gvt host to align with host.
      
      Commit: 93564044 ("drm/i915: Switch over to the LLC/eLLC hotspot avoidance
      hash mode for CCS") add compression workaround, then we can remove the
      skl_misc_ctl_write hanlder.
      
      Better solution should be always keeping same settings as host, and bypass
      the write request from VMs, but it need to fetch data from host's
      "Context".
      
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: default avatarWeinan Li <weinan.z.li@intel.com>
      Signed-off-by: default avatarXiong Zhang <xiong.y.zhang@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      bf3a26b3
    • Changbin Du's avatar
      drm/i915/gvt: Fix unsafe locking caused by spin_unlock_bh · 679fd3eb
      Changbin Du authored
      The caller of shadow_context_status_change may disable irqs. So it is not
      safe to use spin_unlock_bh in such context. Let's switch to irqsave version
      for safety.
      
      ------------[ cut here ]------------
      WARNING: CPU: 2 PID: 4504 at kernel/softirq.c:161 __local_bh_enable_ip+0x46/0x60
      [  168.797710] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.2.8 01/26/2016
      [  168.797712] task: ffff8c693d22db80 task.stack: ffffb51b482bc000
      [  168.797718] RIP: 0010:__local_bh_enable_ip+0x46/0x60
      [  168.797721] RSP: 0018:ffffb51b482bfa10 EFLAGS: 00010046
      [  168.797724] RAX: 0000000000000046 RBX: ffff8c6900278000 RCX: 00000000ffffffff
      [  168.797726] RDX: 0000000000000001 RSI: 0000000000000200 RDI: ffffffffc06a0330
      [  168.797728] RBP: ffffb51b482bfa10 R08: 0000000000000000 R09: ffff8c690027cb90
      [  168.797730] R10: ffffb51b482bfa40 R11: 00000004072f0001 R12: 0000000000000000
      [  168.797732] R13: 0000000000000000 R14: ffff8c690027ca9c R15: 0000000000000000
      [  168.797735] FS:  00007ff187c56700(0000) GS:ffff8c6959d00000(0000) knlGS:0000000000000000
      [  168.797738] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  168.797740] CR2: 0000562bc0c3991f CR3: 0000000430614006 CR4: 00000000003606e0
      [  168.797742] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  168.797744] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  168.797745] Call Trace:
      [  168.797755]  _raw_spin_unlock_bh+0x1e/0x20
      [  168.797826]  shadow_context_status_change+0x120/0x1e0 [i915]
      [  168.797831]  notifier_call_chain+0x4a/0x70
      [  168.797834]  atomic_notifier_call_chain+0x1a/0x20
      [  168.797896]  execlists_cancel_port_requests+0x4f/0x80 [i915]
      [  168.797956]  reset_common_ring+0x30/0x100 [i915]
      [  168.798007]  i915_gem_reset_engine+0x114/0x330 [i915]
      [  168.798060]  ? i915_gem_retire_requests+0x75/0x180 [i915]
      [  168.798111]  i915_gem_reset+0x3e/0xb0 [i915]
      [  168.798149]  i915_reset+0x10b/0x1c0 [i915]
      [  168.798187]  i915_reset_device+0x209/0x220 [i915]
      [  168.798225]  ? gen8_gt_irq_ack+0x170/0x170 [i915]
      [  168.798229]  ? __queue_work+0x430/0x430
      [  168.798270]  i915_handle_error+0x285/0x420 [i915]
      [  168.798275]  ? mntput+0x24/0x40
      [  168.798281]  ? terminate_walk+0x8e/0xf0
      [  168.798328]  i915_wedged_set+0x84/0xc0 [i915]
      [  168.798333]  simple_attr_write+0xab/0xc0
      [  168.798337]  full_proxy_write+0x54/0x90
      [  168.798343]  __vfs_write+0x37/0x170
      [  168.798349]  ? common_file_perm+0x4c/0x100
      [  168.798355]  ? apparmor_file_permission+0x1a/0x20
      [  168.798361]  ? security_file_permission+0x3b/0xc0
      [  168.798365]  vfs_write+0xb8/0x1b0
      [  168.798370]  SyS_write+0x55/0xc0
      [  168.798376]  entry_SYSCALL_64_fastpath+0x1e/0xa9
      
      Fixes: 0e86cc9c ("drm/i915/gvt: implement per-vm mmio switching optimization")
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      679fd3eb
    • Arnd Bergmann's avatar
      drm/i915: fix intel_backlight_device_register declaration · ac29fc66
      Arnd Bergmann authored
      The alternative intel_backlight_device_register() definition apparently
      never got used, but I have now run into a case of i915 being compiled
      without CONFIG_BACKLIGHT_CLASS_DEVICE, resulting in a number of
      identical warnings:
      
      drivers/gpu/drm/i915/intel_drv.h:1739:12: error: 'intel_backlight_device_register' defined but not used [-Werror=unused-function]
      
      This marks the function as 'inline', which was surely the original
      intention here.
      
      Fixes: 1ebaa0b9 ("drm/i915: Move backlight registration to connector registration")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171127151239.1813673-1-arnd@arndb.de
      (cherry picked from commit 2de2d0b0)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      ac29fc66
    • Chris Wilson's avatar
      drm/i915/fbdev: Serialise early hotplug events with async fbdev config · a45b30a6
      Chris Wilson authored
      As both the hotplug event and fbdev configuration run asynchronously, it
      is possible for them to run concurrently. If configuration fails, we were
      freeing the fbdev causing a use-after-free in the hotplug event.
      
      <7>[ 3069.935211] [drm:intel_fb_initial_config [i915]] Not using firmware configuration
      <7>[ 3069.935225] [drm:drm_setup_crtcs] looking for cmdline mode on connector 77
      <7>[ 3069.935229] [drm:drm_setup_crtcs] looking for preferred mode on connector 77 0
      <7>[ 3069.935233] [drm:drm_setup_crtcs] found mode 3200x1800
      <7>[ 3069.935236] [drm:drm_setup_crtcs] picking CRTCs for 8192x8192 config
      <7>[ 3069.935253] [drm:drm_setup_crtcs] desired mode 3200x1800 set on crtc 43 (0,0)
      <7>[ 3069.935323] [drm:intelfb_create [i915]] no BIOS fb, allocating a new one
      <4>[ 3069.967737] general protection fault: 0000 [#1] PREEMPT SMP
      <0>[ 3069.977453] ---------------------------------
      <4>[ 3069.977457] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mei_me mii prime_numbers mei i2c_hid pinctrl_geminilake pinctrl_intel [last unloaded: i915]
      <4>[ 3069.977492] CPU: 1 PID: 15414 Comm: kworker/1:0 Tainted: G     U          4.14.0-CI-CI_DRM_3388+ #1
      <4>[ 3069.977497] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
      <4>[ 3069.977508] Workqueue: events output_poll_execute
      <4>[ 3069.977512] task: ffff880177734e40 task.stack: ffffc90001fe4000
      <4>[ 3069.977519] RIP: 0010:__lock_acquire+0x109/0x1b60
      <4>[ 3069.977523] RSP: 0018:ffffc90001fe7bb0 EFLAGS: 00010002
      <4>[ 3069.977526] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000282 RCX: 0000000000000000
      <4>[ 3069.977530] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880170d4efd0
      <4>[ 3069.977534] RBP: ffffc90001fe7c70 R08: 0000000000000001 R09: 0000000000000000
      <4>[ 3069.977538] R10: 0000000000000000 R11: ffffffff81899609 R12: ffff880170d4efd0
      <4>[ 3069.977542] R13: ffff880177734e40 R14: 0000000000000001 R15: 0000000000000000
      <4>[ 3069.977547] FS:  0000000000000000(0000) GS:ffff88017fc80000(0000) knlGS:0000000000000000
      <4>[ 3069.977551] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      <4>[ 3069.977555] CR2: 00007f7e8b7bcf04 CR3: 0000000003e0f000 CR4: 00000000003406e0
      <4>[ 3069.977559] Call Trace:
      <4>[ 3069.977565]  ? mark_held_locks+0x64/0x90
      <4>[ 3069.977571]  ? _raw_spin_unlock_irq+0x24/0x50
      <4>[ 3069.977575]  ? _raw_spin_unlock_irq+0x24/0x50
      <4>[ 3069.977579]  ? trace_hardirqs_on_caller+0xde/0x1c0
      <4>[ 3069.977583]  ? _raw_spin_unlock_irq+0x2f/0x50
      <4>[ 3069.977588]  ? finish_task_switch+0xa5/0x210
      <4>[ 3069.977592]  ? lock_acquire+0xaf/0x200
      <4>[ 3069.977596]  lock_acquire+0xaf/0x200
      <4>[ 3069.977600]  ? __mutex_lock+0x5e9/0x9b0
      <4>[ 3069.977604]  _raw_spin_lock+0x2a/0x40
      <4>[ 3069.977608]  ? __mutex_lock+0x5e9/0x9b0
      <4>[ 3069.977612]  __mutex_lock+0x5e9/0x9b0
      <4>[ 3069.977616]  ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
      <4>[ 3069.977621]  ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
      <4>[ 3069.977625]  drm_fb_helper_hotplug_event.part.19+0x16/0xa0
      <4>[ 3069.977630]  output_poll_execute+0x8d/0x180
      <4>[ 3069.977635]  process_one_work+0x22e/0x660
      <4>[ 3069.977640]  worker_thread+0x48/0x3a0
      <4>[ 3069.977644]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
      <4>[ 3069.977649]  kthread+0x102/0x140
      <4>[ 3069.977653]  ? process_one_work+0x660/0x660
      <4>[ 3069.977657]  ? kthread_create_on_node+0x40/0x40
      <4>[ 3069.977662]  ret_from_fork+0x27/0x40
      <4>[ 3069.977666] Code: 8d 62 f8 c3 49 81 3c 24 e0 fa 3c 82 41 be 00 00 00 00 45 0f 45 f0 83 fe 01 77 86 89 f0 49 8b 44 c4 08 48 85 c0 0f 84 76 ff ff ff <f0> ff 80 38 01 00 00 8b 1d 62 f9 e8 01 45 8b 85 b8 08 00 00 85
      <1>[ 3069.977707] RIP: __lock_acquire+0x109/0x1b60 RSP: ffffc90001fe7bb0
      <4>[ 3069.977712] ---[ end trace 4ad012eb3af62df7 ]---
      
      In order to keep the dev_priv->ifbdev alive after failure, we have to
      avoid the free and leave it empty until we unload the module (which is
      less than ideal, but a necessary evil for simplicity). Then we can use
      intel_fbdev_sync() to serialise the hotplug event with the configuration.
      The serialisation between the two was removed in commit 934458c2
      ("Revert "drm/i915: Fix races on fbdev""), but the use after free is much
      older, commit 366e39b4 ("drm/i915: Tear down fbdev if initialization
      fails")
      
      Fixes: 366e39b4 ("drm/i915: Tear down fbdev if initialization fails")
      Fixes: 934458c2 ("Revert "drm/i915: Fix races on fbdev"")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarLukas Wunner <lukas@wunner.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171125194155.355-1-chris@chris-wilson.co.uk
      (cherry picked from commit ad88d7fc)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      a45b30a6
    • Ville Syrjälä's avatar
      drm/i915: Prevent zero length "index" write · 56350fb8
      Ville Syrjälä authored
      The hardware always writes one or two bytes in the index portion of
      an indexed transfer. Make sure the message we send as the index
      doesn't have a zero length.
      
      Cc: stable@vger.kernel.org
      Cc: Daniel Kurtz <djkurtz@chromium.org>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Sean Paul <seanpaul@chromium.org>
      Fixes: 56f9eac0 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit bb9e0d4b)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      56350fb8
    • Ville Syrjälä's avatar
      drm/i915: Don't try indexed reads to alternate slave addresses · ae5c631e
      Ville Syrjälä authored
      We can only specify the one slave address to indexed reads/writes.
      Make sure the messages we check are destined to the same slave
      address before deciding to do an indexed transfer.
      
      Cc: stable@vger.kernel.org
      Cc: Daniel Kurtz <djkurtz@chromium.org>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Sean Paul <seanpaul@chromium.org>
      Fixes: 56f9eac0 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit c4deb62d)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      ae5c631e
    • Linus Torvalds's avatar
      proc: don't report kernel addresses in /proc/<pid>/stack · 8f5abe84
      Linus Torvalds authored
      This just changes the file to report them as zero, although maybe even
      that could be removed.  I checked, and at least procps doesn't actually
      seem to parse the 'stack' file at all.
      
      And since the file doesn't necessarily even exist (it requires
      CONFIG_STACKTRACE), possibly other tools don't really use it either.
      
      That said, in case somebody parses it with tools, just having that zero
      there should keep such tools happy.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8f5abe84
  4. 27 Nov, 2017 5 commits
    • Linus Torvalds's avatar
      Rename superblock flags (MS_xyz -> SB_xyz) · 1751e8a6
      Linus Torvalds authored
      This is a pure automated search-and-replace of the internal kernel
      superblock flags.
      
      The s_flags are now called SB_*, with the names and the values for the
      moment mirroring the MS_* flags that they're equivalent to.
      
      Note how the MS_xyz flags are the ones passed to the mount system call,
      while the SB_xyz flags are what we then use in sb->s_flags.
      
      The script to do this was:
      
          # places to look in; re security/*: it generally should *not* be
          # touched (that stuff parses mount(2) arguments directly), but
          # there are two places where we really deal with superblock flags.
          FILES="drivers/mtd drivers/staging/lustre fs ipc mm \
                  include/linux/fs.h include/uapi/linux/bfs_fs.h \
                  security/apparmor/apparmorfs.c security/apparmor/include/lib.h"
          # the list of MS_... constants
          SYMS="RDONLY NOSUID NODEV NOEXEC SYNCHRONOUS REMOUNT MANDLOCK \
                DIRSYNC NOATIME NODIRATIME BIND MOVE REC VERBOSE SILENT \
                POSIXACL UNBINDABLE PRIVATE SLAVE SHARED RELATIME KERNMOUNT \
                I_VERSION STRICTATIME LAZYTIME SUBMOUNT NOREMOTELOCK NOSEC BORN \
                ACTIVE NOUSER"
      
          SED_PROG=
          for i in $SYMS; do SED_PROG="$SED_PROG -e s/MS_$i/SB_$i/g"; done
      
          # we want files that contain at least one of MS_...,
          # with fs/namespace.c and fs/pnode.c excluded.
          L=$(for i in $SYMS; do git grep -w -l MS_$i $FILES; done| sort|uniq|grep -v '^fs/namespace.c'|grep -v '^fs/pnode.c')
      
          for f in $L; do sed -i $f $SED_PROG; done
      Requested-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1751e8a6
    • Thomas Meyer's avatar
      auxdisplay: img-ascii-lcd: Only build on archs that have IOMEM · 141cbfba
      Thomas Meyer authored
      This avoids the MODPOST error:
      
        ERROR: "devm_ioremap_resource" [drivers/auxdisplay/img-ascii-lcd.ko] undefined!
      Signed-off-by: default avatarThomas Meyer <thomas@m3y3r.de>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      141cbfba
    • Kirill A. Shutemov's avatar
      mm, thp: Do not make pmd/pud dirty without a reason · 152e93af
      Kirill A. Shutemov authored
      Currently we make page table entries dirty all the time regardless of
      access type and don't even consider if the mapping is write-protected.
      The reasoning is that we don't really need dirty tracking on THP and
      making the entry dirty upfront may save some time on first write to the
      page.
      
      Unfortunately, such approach may result in false-positive
      can_follow_write_pmd() for huge zero page or read-only shmem file.
      
      Let's only make page dirty only if we about to write to the page anyway
      (as we do for small pages).
      
      I've restructured the code to make entry dirty inside
      maybe_p[mu]d_mkwrite(). It also takes into account if the vma is
      write-protected.
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Hugh Dickins <hughd@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      152e93af
    • Kirill A. Shutemov's avatar
      mm, thp: Do not make page table dirty unconditionally in touch_p[mu]d() · a8f97366
      Kirill A. Shutemov authored
      Currently, we unconditionally make page table dirty in touch_pmd().
      It may result in false-positive can_follow_write_pmd().
      
      We may avoid the situation, if we would only make the page table entry
      dirty if caller asks for write access -- FOLL_WRITE.
      
      The patch also changes touch_pud() in the same way.
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Hugh Dickins <hughd@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a8f97366
    • Daniel Vetter's avatar
      Merge tag 'v4.15-rc1' into drm-misc-fixes · 1420edf7
      Daniel Vetter authored
      Linux 4.15-rc1
      
      Pull in the merge window to resync. Dave didn't get his -fixes pull
      landed in time, and now there's another rockchip fix pending, so
      fast-forwarding isn't possible, hence backmerge.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      1420edf7