1. 23 Mar, 2019 23 commits
  2. 19 Mar, 2019 17 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.19.30 · 7794d352
      Greg Kroah-Hartman authored
      7794d352
    • Zha Bin's avatar
      vhost/vsock: fix vhost vsock cid hashing inconsistent · 842bdbe8
      Zha Bin authored
      commit 7fbe078c upstream.
      
      The vsock core only supports 32bit CID, but the Virtio-vsock spec define
      CID (dst_cid and src_cid) as u64 and the upper 32bits is reserved as
      zero. This inconsistency causes one bug in vhost vsock driver. The
      scenarios is:
      
        0. A hash table (vhost_vsock_hash) is used to map an CID to a vsock
        object. And hash_min() is used to compute the hash key. hash_min() is
        defined as:
        (sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits)).
        That means the hash algorithm has dependency on the size of macro
        argument 'val'.
        0. In function vhost_vsock_set_cid(), a 64bit CID is passed to
        hash_min() to compute the hash key when inserting a vsock object into
        the hash table.
        0. In function vhost_vsock_get(), a 32bit CID is passed to hash_min()
        to compute the hash key when looking up a vsock for an CID.
      
      Because the different size of the CID, hash_min() returns different hash
      key, thus fails to look up the vsock object for an CID.
      
      To fix this bug, we keep CID as u64 in the IOCTLs and virtio message
      headers, but explicitly convert u64 to u32 when deal with the hash table
      and vsock core.
      
      Fixes: 834e772c ("vhost/vsock: fix use-after-free in network stack callers")
      Link: https://github.com/stefanha/virtio/blob/vsock/trunk/content.texSigned-off-by: default avatarZha Bin <zhabin@linux.alibaba.com>
      Reviewed-by: default avatarLiu Jiang <gerry@linux.alibaba.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarShengjing Zhu <i@zhsj.me>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      842bdbe8
    • Björn Töpel's avatar
      i40e: report correct statistics when XDP is enabled · 090ce34b
      Björn Töpel authored
      commit cdec2141 upstream.
      
      When XDP is enabled, the driver will report incorrect
      statistics. Received frames will reported as transmitted frames.
      
      This commits fixes the i40e implementation of ndo_get_stats64 (struct
      net_device_ops), so that iproute2 will report correct statistics
      (e.g. when running "ip -stats link show dev eth0") even when XDP is
      enabled.
      Reported-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Fixes: 74608d17 ("i40e: add support for XDP_TX action")
      Signed-off-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Emeric Brun <ebrun@haproxy.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      090ce34b
    • Gao Xiang's avatar
      staging: erofs: fix race when the managed cache is enabled · eab8018f
      Gao Xiang authored
      commit 51232df5 upstream.
      
      When the managed cache is enabled, the last reference count
      of a workgroup must be used for its workstation.
      
      Otherwise, it could lead to incorrect (un)freezes in
      the reclaim path, and it would be harmful.
      
      A typical race as follows:
      
      Thread 1 (In the reclaim path)  Thread 2
      workgroup_freeze(grp, 1)                                refcnt = 1
      ...
      workgroup_unfreeze(grp, 1)                              refcnt = 1
                                      workgroup_get(grp)      refcnt = 2 (x)
      workgroup_put(grp)                                      refcnt = 1 (x)
                                      ...unexpected behaviors
      
      * grp is detached but still used, which violates cache-managed
        freeze constraint.
      Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarGao Xiang <gaoxiang25@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eab8018f
    • Nicholas Kazlauskas's avatar
      drm: Block fb changes for async plane updates · 96ce54b2
      Nicholas Kazlauskas authored
      commit 25dc194b upstream.
      
      The prepare_fb call always happens on new_plane_state.
      
      The drm_atomic_helper_cleanup_planes checks to see if
      plane state pointer has changed when deciding to call cleanup_fb on
      either the new_plane_state or the old_plane_state.
      
      For a non-async atomic commit the state pointer is swapped, so this
      helper calls prepare_fb on the new_plane_state and cleanup_fb on the
      old_plane_state. This makes sense, since we want to prepare the
      framebuffer we are going to use and cleanup the the framebuffer we are
      no longer using.
      
      For the async atomic update helpers this differs. The async atomic
      update helpers perform in-place updates on the existing state. They call
      drm_atomic_helper_cleanup_planes but the state pointer is not swapped.
      This means that prepare_fb is called on the new_plane_state and
      cleanup_fb is called on the new_plane_state (not the old).
      
      In the case where old_plane_state->fb == new_plane_state->fb then
      there should be no behavioral difference between an async update
      and a non-async commit. But there are issues that arise when
      old_plane_state->fb != new_plane_state->fb.
      
      The first is that the new_plane_state->fb is immediately cleaned up
      after it has been prepared, so we're using a fb that we shouldn't
      be.
      
      The second occurs during a sequence of async atomic updates and
      non-async regular atomic commits. Suppose there are two framebuffers
      being interleaved in a double-buffering scenario, fb1 and fb2:
      
      - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
      - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
      - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
      
      We call cleanup_fb on fb2 twice in this example scenario, and any
      further use will result in use-after-free.
      
      The simple fix to this problem is to block framebuffer changes
      in the drm_atomic_helper_async_check function for now.
      
      v2: Move check by itself, add a FIXME (Daniel)
      
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Harry Wentland <harry.wentland@amd.com>
      Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
      Cc: <stable@vger.kernel.org> # v4.14+
      Fixes: fef9df8b ("drm/atomic: initial support for asynchronous plane update")
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Acked-by: default avatarAndrey Grodzovsky <andrey.grodzovsky@amd.com>
      Acked-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Reviewed-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Link: https://patchwork.freedesktop.org/patch/275364/Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96ce54b2
    • Xiao Ni's avatar
      It's wrong to add len to sector_nr in raid10 reshape twice · 27143c71
      Xiao Ni authored
      commit b761dcf1 upstream.
      
      In reshape_request it already adds len to sector_nr already. It's wrong to add len to
      sector_nr again after adding pages to bio. If there is bad block it can't copy one chunk
      at a time, it needs to goto read_more. Now the sector_nr is wrong. It can cause data
      corruption.
      
      Cc: stable@vger.kernel.org # v3.16+
      Signed-off-by: default avatarXiao Ni <xni@redhat.com>
      Signed-off-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      27143c71
    • kbuild test robot's avatar
      perf/x86/intel: Make dev_attr_allow_tsx_force_abort static · d6b577c6
      kbuild test robot authored
      commit c634dc6b upstream.
      
      Fixes: 400816f6 ("perf/x86/intel: Implement support for TSX Force Abort")
      Signed-off-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Cc: kbuild-all@01.org
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190313184243.GA10820@lkp-sb-ep06Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6b577c6
    • Peter Zijlstra's avatar
      perf/x86/intel: Fix memory corruption · 92c9a389
      Peter Zijlstra authored
      commit ede271b0 upstream.
      
      Through:
      
        validate_event()
          x86_pmu.get_event_constraints(.idx=-1)
            tfa_get_event_constraints()
              dyn_constraint()
      
      cpuc->constraint_list[-1] is used, which is an obvious out-of-bound access.
      
      In this case, simply skip the TFA constraint code, there is no event
      constraint with just PMC3, therefore the code will never result in the
      empty set.
      
      Fixes: 400816f6 ("perf/x86/intel: Implement support for TSX Force Abort")
      Reported-by: default avatarTony Jones <tonyj@suse.com>
      Reported-by: default avatar"DSouza, Nelson" <nelson.dsouza@intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarTony Jones <tonyj@suse.com>
      Tested-by: default avatar"DSouza, Nelson" <nelson.dsouza@intel.com>
      Cc: eranian@google.com
      Cc: jolsa@redhat.com
      Cc: stable@kernel.org
      Link: https://lkml.kernel.org/r/20190314130705.441549378@infradead.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      92c9a389
    • Jian-Hong Pan's avatar
      ALSA: hda/realtek: Enable headset MIC of Acer TravelMate X514-51T with ALC255 · 835bc1e2
      Jian-Hong Pan authored
      commit cbc05fd6 upstream.
      
      The Acer TravelMate X514-51T with ALC255 cannot detect the headset MIC
      until ALC255_FIXUP_ACER_HEADSET_MIC quirk applied.  Although, the
      internal DMIC uses another module - snd_soc_skl as the driver.  We still
      need the NID 0x1a in the quirk to enable the headset MIC.
      Signed-off-by: default avatarJian-Hong Pan <jian-hong@endlessm.com>
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      835bc1e2
    • Takashi Iwai's avatar
      ALSA: hda/realtek - Reduce click noise on Dell Precision 5820 headphone · be888d9a
      Takashi Iwai authored
      commit c0ca5ece upstream.
      
      Dell Precision 5820 with ALC3234 codec (which is equivalent with
      ALC255) shows click noises at (runtime) PM resume on the headphone.
      The biggest source of the noise comes from the cleared headphone pin
      control at resume, which is done via the standard shutup procedure.
      
      Although we have an override of the standard shutup callback to
      replace with NOP, this would skip other needed stuff (e.g. the pull
      down of headset power).  So, instead, this "fixes" the behavior of
      alc_fixup_no_shutup() by introducing spec->no_shutup_pins flag.
      When this flag is set, Realtek codec won't call the standard
      snd_hda_shutup_pins() & co.  Now alc_fixup_no_shutup() just sets this
      flag instead of overriding spec->shutup callback itself.  This allows
      us to apply the similar fix for other entries easily if needed in
      future.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be888d9a
    • Jian-Hong Pan's avatar
      ALSA: hda/realtek: Enable audio jacks of ASUS UX362FA with ALC294 · 8f6cf57e
      Jian-Hong Pan authored
      commit 8bb37a2a upstream.
      
      The ASUS UX362FA with ALC294 cannot detect the headset MIC and outputs
      through the internal speaker and the headphone.  This issue can be fixed
      by the quirk in the commit 4e051106 ALSA: hda/realtek: Enable audio
      jacks of ASUS UX533FD with ALC294.
      
      Besides, ASUS UX362FA and UX533FD have the same audio initial pin config
      values.  So, this patch replaces SND_PCI_QUIRK of UX533FD with a new
      SND_HDA_PIN_QUIRK which benefits both UX362FA and UX533FD.
      
      Fixes: 4e051106 ("ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294")
      Signed-off-by: default avatarJian-Hong Pan <jian-hong@endlessm.com>
      Signed-off-by: default avatarMing Shuo Chiu <chiu@endlessm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f6cf57e
    • Jaroslav Kysela's avatar
      ALSA: hda - add more quirks for HP Z2 G4 and HP Z240 · 5da055b1
      Jaroslav Kysela authored
      commit 167897f4 upstream.
      
      Apply the HP_MIC_NO_PRESENCE fixups for the more HP Z2 G4 and
      HP Z240 models.
      Reported-by: default avatarJeff Burrell <jeff.burrell@hp.com>
      Signed-off-by: default avatarJaroslav Kysela <perex@perex.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5da055b1
    • Takashi Iwai's avatar
      ALSA: hda: Extend i915 component bind timeout · 2191cd58
      Takashi Iwai authored
      commit cfc35f9c upstream.
      
      I set 10 seconds for the timeout of the i915 audio component binding
      with a hope that recent machines are fast enough to handle all probe
      tasks in that period, but I was too optimistic.  The binding may take
      longer than that, and this caused a problem on the machine with both
      audio and graphics driver modules loaded in parallel, as Paul Menzel
      experienced.  This problem haven't hit so often just because the KMS
      driver is loaded in initrd on most machines.
      
      As a simple workaround, extend the timeout to 60 seconds.
      
      Fixes: f9b54e19 ("ALSA: hda/i915: Allow delayed i915 audio component binding")
      Reported-by: default avatarPaul Menzel <pmenzel+alsa-devel@molgen.mpg.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2191cd58
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: fix construction of PCM frame for capture direction · 8b2d6639
      Takashi Sakamoto authored
      commit f97a0944 upstream.
      
      In data blocks of common isochronous packet for MOTU devices, PCM
      frames are multiplexed in a shape of '24 bit * 4 Audio Pack', described
      in IEC 61883-6. The frames are not aligned to quadlet.
      
      For capture PCM substream, ALSA firewire-motu driver constructs PCM
      frames by reading data blocks byte-by-byte. However this operation
      includes bug for lower byte of the PCM sample. This brings invalid
      content of the PCM samples.
      
      This commit fixes the bug.
      Reported-by: default avatarPeter Sjöberg <autopeter@gmail.com>
      Cc: <stable@vger.kernel.org> # v4.12+
      Fixes: 4641c939 ("ALSA: firewire-motu: add MOTU specific protocol layer")
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b2d6639
    • Takashi Sakamoto's avatar
      ALSA: bebob: use more identical mod_alias for Saffire Pro 10 I/O against Liquid Saffire 56 · bb2dde7c
      Takashi Sakamoto authored
      commit 7dc661bd upstream.
      
      ALSA bebob driver has an entry for Focusrite Saffire Pro 10 I/O. The
      entry matches vendor_id in root directory and model_id in unit
      directory of configuration ROM for IEEE 1394 bus.
      
      On the other hand, configuration ROM of Focusrite Liquid Saffire 56
      has the same vendor_id and model_id. This device is an application of
      TCAT Dice (TCD2220 a.k.a Dice Jr.) however ALSA bebob driver can be
      bound to it randomly instead of ALSA dice driver. At present, drivers
      in ALSA firewire stack can not handle this situation appropriately.
      
      This commit uses more identical mod_alias for Focusrite Saffire Pro 10
      I/O in ALSA bebob driver.
      
      $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
                     ROM header and bus information block
                     -----------------------------------------------------------------
      400  042a829d  bus_info_length 4, crc_length 42, crc 33437
      404  31333934  bus_name "1394"
      408  f0649222  irmc 1, cmc 1, isc 1, bmc 1, pmc 0, cyc_clk_acc 100,
                     max_rec 9 (1024), max_rom 2, gen 2, spd 2 (S400)
      40c  00130e01  company_id 00130e     |
      410  000606e0  device_id 01000606e0  | EUI-64 00130e01000606e0
      
                     root directory
                     -----------------------------------------------------------------
      414  0009d31c  directory_length 9, crc 54044
      418  04000014  hardware version
      41c  0c0083c0  node capabilities per IEEE 1394
      420  0300130e  vendor
      424  81000012  --> descriptor leaf at 46c
      428  17000006  model
      42c  81000016  --> descriptor leaf at 484
      430  130120c2  version
      434  d1000002  --> unit directory at 43c
      438  d4000006  --> dependent info directory at 450
      
                     unit directory at 43c
                     -----------------------------------------------------------------
      43c  0004707c  directory_length 4, crc 28796
      440  1200a02d  specifier id: 1394 TA
      444  13010001  version: AV/C
      448  17000006  model
      44c  81000013  --> descriptor leaf at 498
      
                     dependent info directory at 450
                     -----------------------------------------------------------------
      450  000637c7  directory_length 6, crc 14279
      454  120007f5  specifier id
      458  13000001  version
      45c  3affffc7  (immediate value)
      460  3b100000  (immediate value)
      464  3cffffc7  (immediate value)
      468  3d600000  (immediate value)
      
                     descriptor leaf at 46c
                     -----------------------------------------------------------------
      46c  00056f3b  leaf_length 5, crc 28475
      470  00000000  textual descriptor
      474  00000000  minimal ASCII
      478  466f6375  "Focu"
      47c  73726974  "srit"
      480  65000000  "e"
      
                     descriptor leaf at 484
                     -----------------------------------------------------------------
      484  0004a165  leaf_length 4, crc 41317
      488  00000000  textual descriptor
      48c  00000000  minimal ASCII
      490  50726f31  "Pro1"
      494  30494f00  "0IO"
      
                     descriptor leaf at 498
                     -----------------------------------------------------------------
      498  0004a165  leaf_length 4, crc 41317
      49c  00000000  textual descriptor
      4a0  00000000  minimal ASCII
      4a4  50726f31  "Pro1"
      4a8  30494f00  "0IO"
      
      $ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
                     ROM header and bus information block
                     -----------------------------------------------------------------
      400  040442e4  bus_info_length 4, crc_length 4, crc 17124
      404  31333934  bus_name "1394"
      408  e0ff8112  irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255,
                     max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400)
      40c  00130e04  company_id 00130e     |
      410  018001e9  device_id 04018001e9  | EUI-64 00130e04018001e9
      
                     root directory
                     -----------------------------------------------------------------
      414  00065612  directory_length 6, crc 22034
      418  0300130e  vendor
      41c  8100000a  --> descriptor leaf at 444
      420  17000006  model
      424  8100000e  --> descriptor leaf at 45c
      428  0c0087c0  node capabilities per IEEE 1394
      42c  d1000001  --> unit directory at 430
      
                     unit directory at 430
                     -----------------------------------------------------------------
      430  000418a0  directory_length 4, crc 6304
      434  1200130e  specifier id
      438  13000001  version
      43c  17000006  model
      440  8100000f  --> descriptor leaf at 47c
      
                     descriptor leaf at 444
                     -----------------------------------------------------------------
      444  00056f3b  leaf_length 5, crc 28475
      448  00000000  textual descriptor
      44c  00000000  minimal ASCII
      450  466f6375  "Focu"
      454  73726974  "srit"
      458  65000000  "e"
      
                     descriptor leaf at 45c
                     -----------------------------------------------------------------
      45c  000762c6  leaf_length 7, crc 25286
      460  00000000  textual descriptor
      464  00000000  minimal ASCII
      468  4c495155  "LIQU"
      46c  49445f53  "ID_S"
      470  41464649  "AFFI"
      474  52455f35  "RE_5"
      478  36000000  "6"
      
                     descriptor leaf at 47c
                     -----------------------------------------------------------------
      47c  000762c6  leaf_length 7, crc 25286
      480  00000000  textual descriptor
      484  00000000  minimal ASCII
      488  4c495155  "LIQU"
      48c  49445f53  "ID_S"
      490  41464649  "AFFI"
      494  52455f35  "RE_5"
      498  36000000  "6"
      
      Cc: <stable@vger.kernel.org> # v3.16+
      Fixes: 25784ec2 ("ALSA: bebob: Add support for Focusrite Saffire/SaffirePro series")
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb2dde7c
    • Peter Zijlstra's avatar
      perf/x86: Fixup typo in stub functions · a8eae05f
      Peter Zijlstra authored
      commit f764c58b upstream.
      
      Guenter reported a build warning for CONFIG_CPU_SUP_INTEL=n:
      
        > With allmodconfig-CONFIG_CPU_SUP_INTEL, this patch results in:
        >
        > In file included from arch/x86/events/amd/core.c:8:0:
        > arch/x86/events/amd/../perf_event.h:1036:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration
        >  static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
      
      While harmless (an unsed pointer is an unused pointer, no matter the type)
      it needs fixing.
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Fixes: d01b1f96 ("perf/x86/intel: Make cpuc allocations consistent")
      Link: http://lkml.kernel.org/r/20190315081410.GR5996@hirez.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8eae05f
    • Jaegeuk Kim's avatar
      f2fs: wait on atomic writes to count F2FS_CP_WB_DATA · 2835c059
      Jaegeuk Kim authored
      commit 31867b23 upstream.
      
      Otherwise, we can get wrong counts incurring checkpoint hang.
      
      IO_W (CP:  -24, Data:   24, Flush: (   0    0    1), Discard: (   0    0))
      
      Thread A                        Thread B
      - f2fs_write_data_pages
       -  __write_data_page
        - f2fs_submit_page_write
         - inc_page_count(F2FS_WB_DATA)
           type is F2FS_WB_DATA due to file is non-atomic one
      - f2fs_ioc_start_atomic_write
       - set_inode_flag(FI_ATOMIC_FILE)
                                      - f2fs_write_end_io
                                       - dec_page_count(F2FS_WB_CP_DATA)
                                         type is F2FS_WB_DATA due to file becomes
                                         atomic one
      
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2835c059