1. 27 Apr, 2017 22 commits
  2. 21 Apr, 2017 18 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.24 · 2f5e58ec
      Greg Kroah-Hartman authored
      2f5e58ec
    • Marcelo Ricardo Leitner's avatar
      sctp: deny peeloff operation on asocs with threads sleeping on it · 35b9d61e
      Marcelo Ricardo Leitner authored
      commit dfcb9f4f upstream.
      
      commit 2dcab598 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
      attempted to avoid a BUG_ON call when the association being used for a
      sendmsg() is blocked waiting for more sndbuf and another thread did a
      peeloff operation on such asoc, moving it to another socket.
      
      As Ben Hutchings noticed, then in such case it would return without
      locking back the socket and would cause two unlocks in a row.
      
      Further analysis also revealed that it could allow a double free if the
      application managed to peeloff the asoc that is created during the
      sendmsg call, because then sctp_sendmsg() would try to free the asoc
      that was created only for that call.
      
      This patch takes another approach. It will deny the peeloff operation
      if there is a thread sleeping on the asoc, so this situation doesn't
      exist anymore. This avoids the issues described above and also honors
      the syscalls that are already being handled (it can be multiple sendmsg
      calls).
      
      Joint work with Xin Long.
      
      Fixes: 2dcab598 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
      Cc: Alexander Popov <alex.popov@linux.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      35b9d61e
    • Mantas M's avatar
      net: ipv6: check route protocol when deleting routes · c67c2be7
      Mantas M authored
      commit c2ed1880 upstream.
      
      The protocol field is checked when deleting IPv4 routes, but ignored for
      IPv6, which causes problems with routing daemons accidentally deleting
      externally set routes (observed by multiple bird6 users).
      
      This can be verified using `ip -6 route del <prefix> proto something`.
      Signed-off-by: default avatarMantas Mikulėnas <grawity@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c67c2be7
    • Omar Sandoval's avatar
      virtio-console: avoid DMA from stack · 86c6667f
      Omar Sandoval authored
      commit c4baad50 upstream.
      
      put_chars() stuffs the buffer it gets into an sg, but that buffer may be
      on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it
      manifested as printks getting turned into NUL bytes).
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarAmit Shah <amit.shah@redhat.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86c6667f
    • Stefan Brüns's avatar
      cxusb: Use a dma capable buffer also for reading · fb003193
      Stefan Brüns authored
      commit 3f190e3a upstream.
      
      Commit 17ce039b ("[media] cxusb: don't do DMA on stack")
      added a kmalloc'ed bounce buffer for writes, but missed to do the same
      for reads. As the read only happens after the write is finished, we can
      reuse the same buffer.
      
      As dvb_usb_generic_rw handles a read length of 0 by itself, avoid calling
      it using the dvb_usb_generic_read wrapper function.
      Signed-off-by: default avatarStefan Brüns <stefan.bruens@rwth-aachen.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb003193
    • Stefan Brüns's avatar
      dvb-usb-firmware: don't do DMA on stack · 28d1e8b7
      Stefan Brüns authored
      commit 67b0503d upstream.
      
      The buffer allocation for the firmware data was changed in
      commit 43fab979 ("[media] dvb-usb: don't use stack for firmware load")
      but the same applies for the reset value.
      
      Fixes: 43fab979 ("[media] dvb-usb: don't use stack for firmware load")
      Signed-off-by: default avatarStefan Brüns <stefan.bruens@rwth-aachen.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28d1e8b7
    • Mauro Carvalho Chehab's avatar
      dvb-usb: don't use stack for firmware load · 36b62c08
      Mauro Carvalho Chehab authored
      commit 43fab979 upstream.
      
      As reported by Marc Duponcheel <marc@offline.be>, firmware load on
      dvb-usb is using the stack, with is not allowed anymore on default
      Kernel configurations:
      
      [ 1025.958836] dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)' in cold state, will try to load a firmware
      [ 1025.958853] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
      [ 1025.958855] dvb-usb: could not stop the USB controller CPU.
      [ 1025.958856] dvb-usb: error while transferring firmware (transferred size: -11, block size: 3)
      [ 1025.958856] dvb-usb: firmware download failed at 8 with -22
      [ 1025.958867] usbcore: registered new interface driver dvb_usb_dtt200u
      
      [    2.789902] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
      [    2.789905] ------------[ cut here ]------------
      [    2.789911] WARNING: CPU: 3 PID: 2196 at drivers/usb/core/hcd.c:1584 usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
      [    2.789912] transfer buffer not dma capable
      [    2.789912] Modules linked in: btusb dvb_usb_dtt200u(+) dvb_usb_af9035(+) btrtl btbcm dvb_usb dvb_usb_v2 btintel dvb_core bluetooth rc_core rfkill x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd drm_kms_helper syscopyarea sysfillrect pcspkr i2c_i801 sysimgblt fb_sys_fops drm i2c_smbus i2c_core r8169 lpc_ich mfd_core mii thermal fan rtc_cmos video button acpi_cpufreq processor snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd crc32c_intel ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd usbcore usb_common dm_mirror dm_region_hash dm_log dm_mod
      [    2.789936] CPU: 3 PID: 2196 Comm: systemd-udevd Not tainted 4.9.0-gentoo #1
      [    2.789937] Hardware name: ASUS All Series/H81I-PLUS, BIOS 0401 07/23/2013
      [    2.789938]  ffffc9000339b690 ffffffff812bd397 ffffc9000339b6e0 0000000000000000
      [    2.789939]  ffffc9000339b6d0 ffffffff81055c86 000006300339b6a0 ffff880116c0c000
      [    2.789941]  0000000000000000 0000000000000000 0000000000000001 ffff880116c08000
      [    2.789942] Call Trace:
      [    2.789945]  [<ffffffff812bd397>] dump_stack+0x4d/0x66
      [    2.789947]  [<ffffffff81055c86>] __warn+0xc6/0xe0
      [    2.789948]  [<ffffffff81055cea>] warn_slowpath_fmt+0x4a/0x50
      [    2.789952]  [<ffffffffa006d460>] usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
      [    2.789954]  [<ffffffff814ed5a8>] ? io_schedule_timeout+0xd8/0x110
      [    2.789956]  [<ffffffffa006e09c>] usb_hcd_submit_urb+0x9c/0x980 [usbcore]
      [    2.789958]  [<ffffffff812d0ebf>] ? copy_page_to_iter+0x14f/0x2b0
      [    2.789960]  [<ffffffff81126818>] ? pagecache_get_page+0x28/0x240
      [    2.789962]  [<ffffffff8118c2a0>] ? touch_atime+0x20/0xa0
      [    2.789964]  [<ffffffffa006f7c4>] usb_submit_urb+0x2c4/0x520 [usbcore]
      [    2.789967]  [<ffffffffa006feca>] usb_start_wait_urb+0x5a/0xe0 [usbcore]
      [    2.789969]  [<ffffffffa007000c>] usb_control_msg+0xbc/0xf0 [usbcore]
      [    2.789970]  [<ffffffffa067903d>] usb_cypress_writemem+0x3d/0x40 [dvb_usb]
      [    2.789972]  [<ffffffffa06791cf>] usb_cypress_load_firmware+0x4f/0x130 [dvb_usb]
      [    2.789973]  [<ffffffff8109dbbe>] ? console_unlock+0x2fe/0x5d0
      [    2.789974]  [<ffffffff8109e10c>] ? vprintk_emit+0x27c/0x410
      [    2.789975]  [<ffffffff8109e40a>] ? vprintk_default+0x1a/0x20
      [    2.789976]  [<ffffffff81124d76>] ? printk+0x43/0x4b
      [    2.789977]  [<ffffffffa0679310>] dvb_usb_download_firmware+0x60/0xd0 [dvb_usb]
      [    2.789979]  [<ffffffffa0679898>] dvb_usb_device_init+0x3d8/0x610 [dvb_usb]
      [    2.789981]  [<ffffffffa069e302>] dtt200u_usb_probe+0x92/0xd0 [dvb_usb_dtt200u]
      [    2.789984]  [<ffffffffa007420c>] usb_probe_interface+0xfc/0x270 [usbcore]
      [    2.789985]  [<ffffffff8138bf95>] driver_probe_device+0x215/0x2d0
      [    2.789986]  [<ffffffff8138c0e6>] __driver_attach+0x96/0xa0
      [    2.789987]  [<ffffffff8138c050>] ? driver_probe_device+0x2d0/0x2d0
      [    2.789988]  [<ffffffff81389ffb>] bus_for_each_dev+0x5b/0x90
      [    2.789989]  [<ffffffff8138b7b9>] driver_attach+0x19/0x20
      [    2.789990]  [<ffffffff8138b33c>] bus_add_driver+0x11c/0x220
      [    2.789991]  [<ffffffff8138c91b>] driver_register+0x5b/0xd0
      [    2.789994]  [<ffffffffa0072f6c>] usb_register_driver+0x7c/0x130 [usbcore]
      [    2.789994]  [<ffffffffa06a5000>] ? 0xffffffffa06a5000
      [    2.789996]  [<ffffffffa06a501e>] dtt200u_usb_driver_init+0x1e/0x20 [dvb_usb_dtt200u]
      [    2.789997]  [<ffffffff81000408>] do_one_initcall+0x38/0x140
      [    2.789998]  [<ffffffff8116001c>] ? __vunmap+0x7c/0xc0
      [    2.789999]  [<ffffffff81124fb0>] ? do_init_module+0x22/0x1d2
      [    2.790000]  [<ffffffff81124fe8>] do_init_module+0x5a/0x1d2
      [    2.790002]  [<ffffffff810c96b1>] load_module+0x1e11/0x2580
      [    2.790003]  [<ffffffff810c68b0>] ? show_taint+0x30/0x30
      [    2.790004]  [<ffffffff81177250>] ? kernel_read_file+0x100/0x190
      [    2.790005]  [<ffffffff810c9ffa>] SyS_finit_module+0xba/0xc0
      [    2.790007]  [<ffffffff814f13e0>] entry_SYSCALL_64_fastpath+0x13/0x94
      [    2.790008] ---[ end trace c78a74e78baec6fc ]---
      
      So, allocate the structure dynamically.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      [bwh: Backported to 4.9: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36b62c08
    • Kees Cook's avatar
      mm: Tighten x86 /dev/mem with zeroing reads · 2c0ad235
      Kees Cook authored
      commit a4866aa8 upstream.
      
      Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
      disallowed. However, on x86, the first 1MB was always allowed for BIOS
      and similar things, regardless of it actually being System RAM. It was
      possible for heap to end up getting allocated in low 1MB RAM, and then
      read by things like x86info or dd, which would trip hardened usercopy:
      
      usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)
      
      This changes the x86 exception for the low 1MB by reading back zeros for
      System RAM areas instead of blindly allowing them. More work is needed to
      extend this to mmap, but currently mmap doesn't go through usercopy, so
      hardened usercopy won't Oops the kernel.
      Reported-by: default avatarTommi Rantala <tommi.t.rantala@nokia.com>
      Tested-by: default avatarTommi Rantala <tommi.t.rantala@nokia.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2c0ad235
    • Thierry Reding's avatar
      rtc: tegra: Implement clock handling · ef793e6e
      Thierry Reding authored
      commit 5fa40869 upstream.
      
      Accessing the registers of the RTC block on Tegra requires the module
      clock to be enabled. This only works because the RTC module clock will
      be enabled by default during early boot. However, because the clock is
      unused, the CCF will disable it at late_init time. This causes the RTC
      to become unusable afterwards. This can easily be reproduced by trying
      to use the RTC:
      
      	$ hwclock --rtc /dev/rtc1
      
      This will hang the system. I ran into this by following up on a report
      by Martin Michlmayr that reboot wasn't working on Tegra210 systems. It
      turns out that the rtc-tegra driver's ->shutdown() implementation will
      hang the CPU, because of the disabled clock, before the system can be
      rebooted.
      
      What confused me for a while is that the same driver is used on prior
      Tegra generations where the hang can not be observed. However, as Peter
      De Schrijver pointed out, this is because on 32-bit Tegra chips the RTC
      clock is enabled by the tegra20_timer.c clocksource driver, which uses
      the RTC to provide a persistent clock. This code is never enabled on
      64-bit Tegra because the persistent clock infrastructure does not exist
      on 64-bit ARM.
      
      The proper fix for this is to add proper clock handling to the RTC
      driver in order to ensure that the clock is enabled when the driver
      requires it. All device trees contain the clock already, therefore
      no additional changes are required.
      Reported-by: default avatarMartin Michlmayr <tbm@cyrius.com>
      Acked-By Peter De Schrijver <pdeschrijver@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      [bwh: Backported to 4.9: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef793e6e
    • Lv Zheng's avatar
      ACPI / EC: Use busy polling mode when GPE is not enabled · 0dd96211
      Lv Zheng authored
      commit c3a696b6 upstream.
      
      When GPE is not enabled, it is not efficient to use the wait polling mode
      as it introduces an unexpected scheduler delay.
      So before the GPE handler is installed, this patch uses busy polling mode
      for all EC(s) and the logic can be applied to non boot EC(s) during the
      suspend/resume process.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=191561Tested-by: default avatarJakobus Schurz <jakobus.schurz@gmail.com>
      Tested-by: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0dd96211
    • Mohit Gambhir's avatar
      x86/xen: Fix APIC id mismatch warning on Intel · c07479f4
      Mohit Gambhir authored
      commit cc272163 upstream.
      
      This patch fixes the following warning message seen when booting the
      kernel as Dom0 with Xen on Intel machines.
      
      [0.003000] [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC: 1]
      
      The code generating the warning in validate_apic_and_package_id() matches
      cpu_data(cpu).apicid (initialized in init_intel()->
      detect_extended_topology() using cpuid) against the apicid returned from
      xen_apic_read(). Now, xen_apic_read() makes a hypercall to retrieve apicid
      for the boot  cpu but returns 0 otherwise. Hence the warning gets thrown
      for all but the boot cpu.
      
      The idea behind xen_apic_read() returning 0 for apicid is that the
      guests (even Dom0) should not need to know what physical processor their
      vcpus are running on. This is because we currently  do not have topology
      information in Xen and also because xen allows more vcpus than physical
      processors. However, boot cpu's apicid is required for loading
      xen-acpi-processor driver on AMD machines. Look at following patch for
      details:
      
      commit 558daa28 ("xen/apic: Return the APIC ID (and version) for CPU
      0.")
      
      So to get rid of the warning, this patch modifies
      xen_cpu_present_to_apicid() to return cpu_data(cpu).apicid instead of
      calling xen_apic_read().
      
      The warning is not seen on AMD machines because init_amd() populates
      cpu_data(cpu).apicid by calling hard_smp_processor_id()->xen_apic_read()
      as opposed to using apicid from cpuid as is done on Intel machines.
      Signed-off-by: default avatarMohit Gambhir <mohit.gambhir@oracle.com>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c07479f4
    • Lee, Chun-Yi's avatar
      platform/x86: acer-wmi: setup accelerometer when machine has appropriate notify event · 03470ba9
      Lee, Chun-Yi authored
      commit 98d610c3 upstream.
      
      The accelerometer event relies on the ACERWMID_EVENT_GUID notify.
      So, this patch changes the codes to setup accelerometer input device
      when detected ACERWMID_EVENT_GUID. It avoids that the accel input
      device created on every Acer machines.
      
      In addition, patch adds a clearly parsing logic of accelerometer hid
      to acer_wmi_get_handle_cb callback function. It is positive matching
      the "SENR" name with "BST0001" device to avoid non-supported hardware.
      Reported-by: default avatarBjørn Mork <bjorn@mork.no>
      Cc: Darren Hart <dvhart@infradead.org>
      Signed-off-by: default avatarLee, Chun-Yi <jlee@suse.com>
      [andy: slightly massage commit message]
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03470ba9
    • Andy Shevchenko's avatar
      ASoC: Intel: select DW_DMAC_CORE since it's mandatory · a6ca4946
      Andy Shevchenko authored
      commit ebf79091 upstream.
      
      Select DW_DMAC_CORE like the rest of glue drivers do, e.g.
      drivers/dma/dw/Kconfig.
      
      While here group selectors under SND_SOC_INTEL_HASWELL and
      SND_SOC_INTEL_BAYTRAIL.
      
      Make platforms, which are using a common SST firmware driver, to be
      dependent on DMADEVICES.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarLiam Girdwood <liam.r.girdwood@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a6ca4946
    • Jens Axboe's avatar
      nbd: fix 64-bit division · 25640e79
      Jens Axboe authored
      commit e88f72cb upstream.
      
      We have this:
      
      ERROR: "__aeabi_ldivmod" [drivers/block/nbd.ko] undefined!
      ERROR: "__divdi3" [drivers/block/nbd.ko] undefined!
      nbd.c:(.text+0x247c72): undefined reference to `__divdi3'
      
      due to a recent commit, that did 64-bit division. Use the proper
      divider function so that 32-bit compiles don't break.
      
      Fixes: ef77b515 ("nbd: use loff_t for blocksize and nbd_set_size args")
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      25640e79
    • Josef Bacik's avatar
      nbd: use loff_t for blocksize and nbd_set_size args · 7599166d
      Josef Bacik authored
      commit ef77b515 upstream.
      
      If we have large devices (say like the 40t drive I was trying to test with) we
      will end up overflowing the int arguments to nbd_set_size and not get the right
      size for our device.  Fix this by using loff_t everywhere so I don't have to
      think about this again.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      [bwh: Backported to 4.9: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7599166d
    • Ben Skeggs's avatar
      drm/nouveau/disp/mcp7x: disable dptmds workaround · 9c0c4352
      Ben Skeggs authored
      commit 7dfee682 upstream.
      
      The workaround appears to cause regressions on these boards, and from
      inspection of RM traces, NVIDIA don't appear to do it on them either.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Tested-by: default avatarRoy Spliet <nouveau@spliet.org>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9c0c4352
    • Vladimir Davydov's avatar
      mm: memcontrol: use special workqueue for creating per-memcg caches · 754ae7ef
      Vladimir Davydov authored
      commit 13583c3d upstream.
      
      Creating a lot of cgroups at the same time might stall all worker
      threads with kmem cache creation works, because kmem cache creation is
      done with the slab_mutex held.  The problem was amplified by commits
      801faf0d ("mm/slab: lockless decision to grow cache") in case of
      SLAB and 81ae6d03 ("mm/slub.c: replace kick_all_cpus_sync() with
      synchronize_sched() in kmem_cache_shrink()") in case of SLUB, which
      increased the maximal time the slab_mutex can be held.
      
      To prevent that from happening, let's use a special ordered single
      threaded workqueue for kmem cache creation.  This shouldn't introduce
      any functional changes regarding how kmem caches are created, as the
      work function holds the global slab_mutex during its whole runtime
      anyway, making it impossible to run more than one work at a time.  By
      using a single threaded workqueue, we just avoid creating a thread per
      each work.  Ordering is required to avoid a situation when a cgroup's
      work is put off indefinitely because there are other cgroups to serve,
      in other words to guarantee fairness.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=172981
      Link: http://lkml.kernel.org/r/20161004131417.GC1862@esperanzaSigned-off-by: default avatarVladimir Davydov <vdavydov.dev@gmail.com>
      Reported-by: default avatarDoug Smythies <dsmythies@telus.net>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      754ae7ef
    • Daeho Jeong's avatar
      ext4: fix inode checksum calculation problem if i_extra_size is small · b1574caf
      Daeho Jeong authored
      commit 05ac5aa1 upstream.
      
      We've fixed the race condition problem in calculating ext4 checksum
      value in commit b47820ed ("ext4: avoid modifying checksum fields
      directly during checksum veficationon"). However, by this change,
      when calculating the checksum value of inode whose i_extra_size is
      less than 4, we couldn't calculate the checksum value in a proper way.
      This problem was found and reported by Nix, Thank you.
      Reported-by: default avatarNix <nix@esperi.org.uk>
      Signed-off-by: default avatarDaeho Jeong <daeho.jeong@samsung.com>
      Signed-off-by: default avatarYoungjin Gil <youngjin.gil@samsung.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1574caf