* acpi-thermal:
  ACPI / thermal: Use acpi_bus_attach_private_data() to attach private data

* acpi-video:
  ACPI / video: Add 4 new models to the use_native_backlight DMI list
  ACPI / video: Add use native backlight quirk for the ThinkPad W530
  ACPI / video: Unregister the backlight device if a raw one shows up later
  backlight: Add backlight device (un)registration notification
  nouveau: Don't check acpi_video_backlight_support() before registering backlight
  acer-wmi: Add Aspire 5741 to video_vendor_dmi_table
  acer-wmi: Switch to acpi_video_unregister_backlight
  ACPI / video: Add an acpi_video_unregister_backlight function
  ACPI / video: Don't register acpi_video_resume notifier without backlight devices
  ACPI / video: change acpi-video brightness_switch_enabled default to 0

* acpica: (63 commits)
  ACPICA: Namespace: Remove _PRP method support.
  ACPI: Fix x86 regression related to early mapping size limitation
  ACPICA: Tables: Add mechanism to control early table checksum verification.
  ACPICA: acpidump: Fix repetitive table dump in -n mode.
  ACPI: Clean up acpi_os_map/unmap_memory() to eliminate __iomem.
  ACPICA: Clean up redudant definitions already defined elsewhere
  ACPICA: Linux headers: Add <asm/acenv.h> to remove mis-ordered inclusion of <asm/acpi.h>
  ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h>
  ACPICA: Linux headers: Remove ACPI_PREEMPTION_POINT() due to no usages.
  ACPICA: Update version to 20140424.
  ACPICA: Comment/format update, no functional change.
  ACPICA: Events: Update GPE handling and initialization code.
  ACPICA: Remove extraneous error message for large number of GPEs.
  ACPICA: Tables: Remove old mechanism to validate if XSDT contains NULL entries.
  ACPICA: Tables: Add new mechanism to skip NULL entries in RSDT and XSDT.
  ACPICA: acpidump: Add support to force using RSDT.
  ACPICA: Back port of improvements on exception code.
  ACPICA: Back port of _PRP update.
  ACPICA: acpidump: Fix truncated RSDP signature validation.
  ACPICA: Linux header: Add support for stubbed externals.
  ...

* acpi-enumeration:
  ACPI / scan: use platform bus type by default for _HID enumeration
  ACPI / scan: always register ACPI LPSS scan handler
  ACPI / scan: always register memory hotplug scan handler
  ACPI / scan: always register container scan handler
  ACPI / scan: Change the meaning of missing .attach() in scan handlers
  ACPI / scan: introduce platform_id device PNP type flag
  ACPI / scan: drop unsupported serial IDs from PNP ACPI scan handler ID list
  ACPI / scan: drop IDs that do not comply with the ACPI PNP ID rule
  ACPI / PNP: use device ID list for PNPACPI device enumeration
  ACPI / scan: .match() callback for ACPI scan handlers

* acpi-lpss:
  ACPI / LPSS: support for fractional divider clock
  ACPI / LPSS: custom power domain for LPSS

* pm-clk:
  clk: new basic clk type for fractional divider

* acpi-platform:
  ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices
  ACPI / platform: add IDs for Broadcom Bluetooth and GPS chips

* acpi-pm:
  ACPI / PM: Export rest of the subsys PM callbacks
  ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend
  ACPI / PM: Hold ACPI scan lock over the "freeze" sleep state
  ACPI / PM: Export acpi_target_system_state() to modules

* acpi-battery:
  ACPI / battery: wakeup the system only when necessary
  power_supply: allow power supply devices registered w/o wakeup source
  ACPI / battery: introduce support for POWER_SUPPLY_PROP_CAPACITY_LEVEL
  ACPI / battery: Accelerate battery resume callback

* pm-sleep:
  PM / hibernate: fixed typo in comment
  PM / sleep: unregister wakeup source when disabling device wakeup
  PM / sleep: Introduce command line argument for sleep state enumeration
  PM / sleep: Use valid_state() for platform-dependent sleep states only
  PM / sleep: Add state field to pm_states[] entries
  PM / sleep: Update device PM documentation to cover direct_complete
  PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
  PM / hibernate: Fix memory corruption in resumedelay_setup()
  PM / hibernate: convert simple_strtoul to kstrtoul
  PM / hibernate: Documentation: Fix script for unswapping
  PM / hibernate: no kernel_power_off when pm_power_off NULL
  PM / hibernate: use unsigned local variables in swsusp_show_speed()

* pm-cpuidle:
  PM / suspend: Always use deepest C-state in the "freeze" sleep state
  cpuidle / menu: move repeated correction factor check to init
  cpuidle / menu: Return (-1) if there are no suitable states
  cpuidle: Combine cpuidle_enabled() with cpuidle_select()
  ARM: clps711x: Add cpuidle driver

* acpi-tables:
  ACPI: Fix conflict between customized DSDT and DSDT local copy

* acpi-general:
  ACPI: Add acpi_bus_attach_private_data() to attach data to ACPI handle

* acpi-processor:
  ACPI / processor: Fix STARTING/DYING action in acpi_cpu_soft_notify()
  ACPI / processor: Check if LAPIC is present during initialization
  ACPI / ia64: introduce variable acpi_lapic into ia64

* acpi-pad:
  ACPI / PAD: Use time_before() for time comparison
  ACPI / PAD: call schedule() when need_resched() is true

* acpi-scan:
  ACPI / scan: do not scan fixed hardware on HW-reduced platform

* acpi-hotplug:
  ACPI: add dynamic_debug support
  ACPI / notify: Clean up handling of hotplug events

* acpi-pci:
  ACPI / PCI: Stub out pci_acpi_crs_quirks() and make it x86 specific

The _PRP method is not going to be a part of the ACPI standard. This patch
removes its support code introduced by the following commits:
 1. ACPICA: Predefined names: Add support for the _PRP method.
 2. ACPICA: Update for _PRP predefined name.
 3. ACPICA: Add support for _LPD and _PRP methods.
 4. ACPICA: Back port of _PRP update.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This change makes the busy calculation using 64 bit math which prevents
overflow for large values of aperf/mperf.

Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: NDoug Smythies <dsmythies@telus.net>
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The PID assumes that samples are of equal time, which for a deferable
timers this is not true when the system goes idle.  This causes the
PID to take a long time to converge to the min P state and depending
on the pattern of the idle load can make the P state appear stuck.

The hold-off value of three sample times before using the scaling is
to give a grace period for applications that have high performance
requirements and spend a lot of time idle,  The poster child for this
behavior is the ffmpeg benchmark in the Phoronix test suite.

Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Changing to fixed point math throughout the busy calculation in
commit e66c1768 (Change busy calculation to use fixed point
math.) Introduced some inaccuracies by rounding the busy value at two
points in the calculation.  This change removes roundings and moves
the rounding to the output of the PID where the calculations are
complete and the value returned as an integer.

Fixes: e66c1768 (intel_pstate: Change busy calculation to use fixed point math.)
Reported-by: NDoug Smythies <dsmythies@telus.net>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit fcb6a15c (intel_pstate: Take core C0 time into account for core
busy calculation) introduced a regression referenced below.  The issue
with "lockup" after suspend that this commit was addressing is now dealt
with in the suspend path.

Fixes: fcb6a15c (intel_pstate: Take core C0 time into account for core busy calculation)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=66581
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75121Reported-by: NDoug Smythies <dsmythies@telus.net>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull powerpc fix from Ben Herrenschmidt:
 "Here's just one trivial patch to wire up sys_renameat2 which I seem to
  have completely missed so far.

  (My test build scripts fwd me warnings but miss the ones generated for
  missing syscalls)"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc: Wire renameat2() syscall

Pull MIPS fixes from Ralf Baechle:
 "A fair number of fixes across the field.  Nothing terribly
  complicated; the one liners in below changelog should be fairly
  descriptive.

  Noteworthy is the SB1 change which the result of changes to binutils
  resulting in one big gas warning for most files being assembled as
  well as the asid_cache and branch emulation fixes which fix corruption
  or possible uninteded behaviour of kernel or application code.  The
  remainder of fixes are more platforms or subsystem specific"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: R46000: Fix Micro-assembler field overflow for R4600 V2
  MIPS: ptrace: Avoid smp_processor_id() in preemptible code
  MIPS: Lemote 2F: cs5536: mfgpt: use raw locks
  MIPS: SB1: Fix excessive kernel warnings.
  MIPS: RC32434: fix broken PCI resource initialization
  MIPS: malta: memory.c: Initialize the 'memsize' variable
  MIPS: Fix typo when reporting cache and ftlb errors for ImgTec cores
  MIPS: Fix inconsistancy of __NR_Linux_syscalls value
  MIPS: Fix branch emulation of branch likely instructions.
  MIPS: Fix a typo error in AUDIT_ARCH definition
  MIPS: Change type of asid_cache to unsigned long

Pull scheduler fixes from Ingo Molnar:
 "Various fixlets, mostly related to the (root-only) SCHED_DEADLINE
  policy, but also a hotplug bug fix and a fix for a NR_CPUS related
  overallocation bug causing a suspend/resume regression"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched: Fix hotplug vs. set_cpus_allowed_ptr()
  sched/cpupri: Replace NR_CPUS arrays
  sched/deadline: Replace NR_CPUS arrays
  sched/deadline: Restrict user params max value to 2^63 ns
  sched/deadline: Change sched_getparam() behaviour vs SCHED_DEADLINE
  sched: Disallow sched_attr::sched_policy < 0
  sched: Make sched_setattr() correctly return -EFBIG

Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Fix a trivial comment typo (s/mam/map) in kernel/power/swap.c.
Signed-off-by: NNiv Yehezkel <executerx@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The following warning message is triggered:
 WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:136 __early_ioremap+0x11f/0x1f2()
 Modules linked in:
 CPU: 0 PID: 0 Comm: swapper Not tainted 3.15.0-rc1-00017-g86dfc6f3-dirty #298
 Hardware name: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x036.091920111209 09/19/2011
  0000000000000009 ffffffff81b75c40 ffffffff817c627b 0000000000000000
  ffffffff81b75c78 ffffffff81067b5d 000000000000007b 8000000000000563
  00000000b96b20dc 0000000000000001 ffffffffff300e0c ffffffff81b75c88
 Call Trace:
  [<ffffffff817c627b>] dump_stack+0x45/0x56
  [<ffffffff81067b5d>] warn_slowpath_common+0x7d/0xa0
  [<ffffffff81067c3a>] warn_slowpath_null+0x1a/0x20
  [<ffffffff81d4b9d5>] __early_ioremap+0x11f/0x1f2
  [<ffffffff81d4bc5b>] early_ioremap+0x13/0x15
  [<ffffffff81d2b8f3>] __acpi_map_table+0x13/0x18
  [<ffffffff817b8d1a>] acpi_os_map_memory+0x26/0x14e
  [<ffffffff813ff018>] acpi_tb_acquire_table+0x42/0x70
  [<ffffffff813ff086>] acpi_tb_validate_table+0x27/0x37
  [<ffffffff813ff0e5>] acpi_tb_verify_table+0x22/0xd8
  [<ffffffff813ff6a8>] acpi_tb_install_non_fixed_table+0x60/0x1c9
  [<ffffffff81d61024>] acpi_tb_parse_root_table+0x218/0x26a
  [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
  [<ffffffff81d610cd>] acpi_initialize_tables+0x57/0x59
  [<ffffffff81d5f25d>] acpi_table_init+0x1b/0x99
  [<ffffffff81d2bca0>] acpi_boot_table_init+0x1e/0x85
  [<ffffffff81d23043>] setup_arch+0x99d/0xcc6
  [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
  [<ffffffff81d1bbbe>] start_kernel+0x8b/0x415
  [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
  [<ffffffff81d1b5ee>] x86_64_start_reservations+0x2a/0x2c
  [<ffffffff81d1b72e>] x86_64_start_kernel+0x13e/0x14d
 ---[ end trace 11ae599a1898f4e7 ]---
when installing the following table during early stage:
 ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL  S2600CP  00004000 INTL 20100331)
The regression is caused by the size limitation of the x86 early IO mapping.

The root cause is:
 1. ACPICA doesn't split IO memory mapping and table mapping;
 2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map
    mechanism during early boot stage, which is more suitable for only IO
    mappings.

This patch fixes this issue by utilizing acpi_gbl_verify_table_checksum to
disable the table mapping during early stage and enabling it again for the
late stage. In this way, the normal code path is not affected. Then after
the code related to the root cause is cleaned up, the early checksum
verification can be easily re-enabled.

A new boot parameter - acpi_force_table_verification is introduced for
the platforms that require the checksum verification to stop loading bad
tables.

This fix also covers the checksum verification for the table overrides. Now
large tables can also be overridden using the initrd override mechanism.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reported-and-tested-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It is reported that Linux x86 kernel cannot map large tables. The following
large SSDT table on such platform fails to pass checksum verification and
cannot be installed:
 ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL  S2600CP  00004000 INTL 20100331)

It sounds strange that in the 64-bit virtual memory address space, we
cannot map a single ACPI table to do checksum verification. The root cause
is:
 1. ACPICA doesn't split IO memory mapping and table mapping;
 2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map
    mechanism during early boot stage, which is more suitable for only IO
    mappings.

ACPICA originally only mapped table header for signature validation, and
this header mapping is required by OSL override mechanism. There was no
checksum verification because we could not map the whole table using this
OSL. While the following ACPICA commit enforces checksum verification by
mapping the whole table during Linux boot stage and it finally triggers
this issue on some platforms:
 Commit: 86dfc6f3
 Subject: ACPICA: Tables: Fix table checksums verification before installation.

Before doing further cleanups for the OSL table mapping and override
implementation, this patch introduces an option for such OSPMs to
temporarily discard the checksum verification feature. It then can be
re-enabled easily when the ACPICA and the underlying OSL is ready.

This patch also deletes a comment around the limitation of mappings because
it is not correct. The limitation is not how many times we can map in the
early stage, but the OSL mapping facility may not be suitable for mapping
the ACPI tables and thus may complain us the size limitation.

The acpi_tb_verify_table() is renamed to acpi_tb_verify_temp_table() due to the
work around added, it now only applies to the table descriptor that hasn't
been installed and cannot be used in other cases. Lv Zheng.
Tested-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull core futex/rtmutex fixes from Thomas Gleixner:
 "Three fixlets for long standing issues in the futex/rtmutex code
  unearthed by Dave Jones syscall fuzzer:

   - Add missing early deadlock detection checks in the futex code
   - Prevent user space from attaching a futex to kernel threads
   - Make the deadlock detector of rtmutex work again

  Looks large, but is more comments than code change"

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  rtmutex: Fix deadlock detector for real
  futex: Prevent attaching to kernel threads
  futex: Add another early deadlock detection check

Pull drm fixes from Dave Airlie:
 "Mostly quiet now:

  i915:
    fixing userspace visiblie issues, all stable marked

  radeon:
    one more pll fix, two crashers, one suspend/resume regression"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon: Resume fbcon last
  drm/radeon: only allocate necessary size for vm bo list
  drm/radeon: don't allow RADEON_GEM_DOMAIN_CPU for command submission
  drm/radeon: avoid crash if VM command submission isn't available
  drm/radeon: lower the ref * post PLL maximum once more
  drm/i915: Prevent negative relocation deltas from wrapping
  drm/i915: Only copy back the modified fields to userspace from execbuffer
  drm/i915: Fix dynamic allocation of physical handles

lock_parent() very much on purpose does nested locking of dentries, and
is careful to maintain the right order (lock parent first).  But because
it didn't annotate the nested locking order, lockdep thought it might be
a deadlock on d_lock, and complained.

Add the proper annotation for the inner locking of the child dentry to
make lockdep happy.

Introduced by commit 046b961b ("shrink_dentry_list(): take parent's
->d_lock earlier").
Reported-and-tested-by: NJosh Boyer <jwboyer@fedoraproject.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

So a few people complained that

commit 177cf92d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 1 22:14:59 2014 +0200

    drm/crtc-helpers: fix dpms on logic

which was merged into 3.15-rc1, broke resume on radeons. Strangely git
bisect lead everyone to

commit 25f397a4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jul 19 18:57:11 2013 +0200

    drm/crtc-helper: explicit DPMS on after modeset

which was merged long ago and actually part of 3.14.

Digging deeper I've noticed (again) that the call to
drm_helper_resume_force_mode in the radeon resume handlers was a no-op
previously because everything gets shut down on suspend. radeon does
this with explicit calls to drm_helper_connector_dpms with DPMS_OFF.
But with 177c we now force the dpms state to ON, so suddenly
resume_force_mode actually forced the crtcs back on.

This is the intention of the change after all, the problem is that
radeon resumes the fbdev console layer _before_ restoring the display,
through calling fb_set_suspend. And fbcon does an immediate ->set_par,
which in turn causes the same forced mode restore to happen.

Two concurrent modeset operations didn't lead to happiness. Fix this
by delaying the fbcon resume until the end of the readeon resum
functions.

v2: Fix up a bit of the spelling fail.

References: https://lkml.org/lkml/2014/5/29/1043
References: https://lkml.org/lkml/2014/5/2/388
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74751Tested-by: NKen Moffat <zarniwhoop@ntlworld.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ken Moffat <zarniwhoop@ntlworld.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@gmail.com>

this is the next pull request for stashed up radeon fixes for 3.15. This is finally calming down with only four patches in this pull request.

* 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
  drm/radeon: only allocate necessary size for vm bo list
  drm/radeon: don't allow RADEON_GEM_DOMAIN_CPU for command submission
  drm/radeon: avoid crash if VM command submission isn't available
  drm/radeon: lower the ref * post PLL maximum once more

Pull input subsystem fixes from Dmitry Torokhov:
 "A couple of driver/build fixups and also redone quirk for Synaptics
  touchpads on Lenovo boxes (now using PNP IDs instead of DMI data to
  limit number of quirks)"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: synaptics - change min/max quirk table to pnp-id matching
  Input: synaptics - add a matches_pnp_id helper function
  Input: synaptics - T540p - unify with other LEN0034 models
  Input: synaptics - add min/max quirk for the ThinkPad W540
  Input: ambakmi - request a shared interrupt for AMBA KMI devices
  Input: pxa27x-keypad - fix generating scancode
  Input: atmel-wm97xx - only build for AVR32
  Input: fix ps2/serio module dependency

Pull firewire fix from Stefan Richter:
 "A regression fix for the IEEE 1394 subsystem: re-enable IRQ-based
  asynchronous request reception at addresses below 128 TB"

* tag 'firewire-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
  firewire: revert to 4 GB RDMA, fix protocols using Memory Space

Pull device-mapper fixes from Mike Snitzer:
 "A dm-cache stable fix to split discards on cache block boundaries
  because dm-cache cannot yet handle discards that span cache blocks.

  Really fix a dm-mpath LOCKDEP warning that was introduced in -rc1.

  Add a 'no_space_timeout' control to dm-thinp to restore the ability to
  queue IO indefinitely when no data space is available.  This fixes a
  change in behavior that was introduced in -rc6 where the timeout
  couldn't be disabled"

* tag 'dm-3.15-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm mpath: really fix lockdep warning
  dm cache: always split discards on cache block boundaries
  dm thin: add 'no_space_timeout' dm-thin-pool module param

While I play inhouse patches with much memory pressure on qemu-kvm,
3.14 kernel was randomly crashed. The reason was kernel stack overflow.

When I investigated the problem, the callstack was a little bit deeper
by involve with reclaim functions but not direct reclaim path.

I tried to diet stack size of some functions related with alloc/reclaim
so did a hundred of byte but overflow was't disappeard so that I encounter
overflow by another deeper callstack on reclaim/allocator path.

Of course, we might sweep every sites we have found for reducing
stack usage but I'm not sure how long it saves the world(surely,
lots of developer start to add nice features which will use stack
agains) and if we consider another more complex feature in I/O layer
and/or reclaim path, it might be better to increase stack size(
meanwhile, stack usage on 64bit machine was doubled compared to 32bit
while it have sticked to 8K. Hmm, it's not a fair to me and arm64
already expaned to 16K. )

So, my stupid idea is just let's expand stack size and keep an eye
toward stack consumption on each kernel functions via stacktrace of ftrace.
For example, we can have a bar like that each funcion shouldn't exceed 200K
and emit the warning when some function consumes more in runtime.
Of course, it could make false positive but at least, it could make a
chance to think over it.

I guess this topic was discussed several time so there might be
strong reason not to increase kernel stack size on x86_64, for me not
knowing so Ccing x86_64 maintainers, other MM guys and virtio
maintainers.

Here's an example call trace using up the kernel stack:

         Depth    Size   Location    (51 entries)
         -----    ----   --------
   0)     7696      16   lookup_address
   1)     7680      16   _lookup_address_cpa.isra.3
   2)     7664      24   __change_page_attr_set_clr
   3)     7640     392   kernel_map_pages
   4)     7248     256   get_page_from_freelist
   5)     6992     352   __alloc_pages_nodemask
   6)     6640       8   alloc_pages_current
   7)     6632     168   new_slab
   8)     6464       8   __slab_alloc
   9)     6456      80   __kmalloc
  10)     6376     376   vring_add_indirect
  11)     6000     144   virtqueue_add_sgs
  12)     5856     288   __virtblk_add_req
  13)     5568      96   virtio_queue_rq
  14)     5472     128   __blk_mq_run_hw_queue
  15)     5344      16   blk_mq_run_hw_queue
  16)     5328      96   blk_mq_insert_requests
  17)     5232     112   blk_mq_flush_plug_list
  18)     5120     112   blk_flush_plug_list
  19)     5008      64   io_schedule_timeout
  20)     4944     128   mempool_alloc
  21)     4816      96   bio_alloc_bioset
  22)     4720      48   get_swap_bio
  23)     4672     160   __swap_writepage
  24)     4512      32   swap_writepage
  25)     4480     320   shrink_page_list
  26)     4160     208   shrink_inactive_list
  27)     3952     304   shrink_lruvec
  28)     3648      80   shrink_zone
  29)     3568     128   do_try_to_free_pages
  30)     3440     208   try_to_free_pages
  31)     3232     352   __alloc_pages_nodemask
  32)     2880       8   alloc_pages_current
  33)     2872     200   __page_cache_alloc
  34)     2672      80   find_or_create_page
  35)     2592      80   ext4_mb_load_buddy
  36)     2512     176   ext4_mb_regular_allocator
  37)     2336     128   ext4_mb_new_blocks
  38)     2208     256   ext4_ext_map_blocks
  39)     1952     160   ext4_map_blocks
  40)     1792     384   ext4_writepages
  41)     1408      16   do_writepages
  42)     1392      96   __writeback_single_inode
  43)     1296     176   writeback_sb_inodes
  44)     1120      80   __writeback_inodes_wb
  45)     1040     160   wb_writeback
  46)      880     208   bdi_writeback_workfn
  47)      672     144   process_one_work
  48)      528     112   worker_thread
  49)      416     240   kthread
  50)      176     176   ret_from_fork

[ Note: the problem is exacerbated by certain gcc versions that seem to
  generate much bigger stack frames due to apparently bad coalescing of
  temporaries and generating too many spills.  Rusty saw gcc-4.6.4 using
  35% more stack on the virtio path than 4.8.2 does, for example.

  Minchan not only uses such a bad gcc version (4.6.3 in his case), but
  some of the stack use is due to debugging (CONFIG_DEBUG_PAGEALLOC is
  what causes that kernel_map_pages() frame, for example). But we're
  clearly getting too close.

  The VM code also seems to have excessive stack frames partly for the
  same compiler reason, triggered by excessive inlining and lots of
  function arguments.

  We need to improve on our stack use, but in the meantime let's do this
  simple stack increase too.  Unlike most earlier reports, there is
  nothing simple that stands out as being really horribly wrong here,
  apart from the fact that the stack frames are just bigger than they
  should need to be.        - Linus ]
Signed-off-by: NMinchan Kim <minchan@kernel.org>
Cc: Peter Anvin <hpa@zytor.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Michael S Tsirkin <mst@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: PJ Waskiewicz <pjwaskiewicz@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull vfs dcache livelock fix from Al Viro:
 "Fixes for livelocks in shrink_dentry_list() introduced by fixes to
  shrink list corruption; the root cause was that trylock of parent's
  ->d_lock could be disrupted by d_walk() happening on other CPUs,
  resulting in shrink_dentry_list() making no progress *and* the same
  d_walk() being called again and again for as long as
  shrink_dentry_list() doesn't get past that mess.

  The solution is to have shrink_dentry_list() treat that trylock
  failure not as 'try to do the same thing again', but 'lock them in the
  right order'"

* 'for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  dentry_kill() doesn't need the second argument now
  dealing with the rest of shrink_dentry_list() livelock
  shrink_dentry_list(): take parent's ->d_lock earlier
  expand dentry_kill(dentry, 0) in shrink_dentry_list()
  split dentry_kill()
  lift the "already marked killed" case into shrink_dentry_list()

it's 1 in the only remaining caller.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

We have the same problem with ->d_lock order in the inner loop, where
we are dropping references to ancestors.  Same solution, basically -
instead of using dentry_kill() we use lock_parent() (introduced in the
previous commit) to get that lock in a safe way, recheck ->d_count
(in case if lock_parent() has ended up dropping and retaking ->d_lock
and somebody managed to grab a reference during that window), trylock
the inode->i_lock and use __dentry_kill() to do the rest.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

The cause of livelocks there is that we are taking ->d_lock on
dentry and its parent in the wrong order, forcing us to use
trylock on the parent's one.  d_walk() takes them in the right
order, and unfortunately it's not hard to create a situation
when shrink_dentry_list() can't make progress since trylock
keeps failing, and shrink_dcache_parent() or check_submounts_and_drop()
keeps calling d_walk() disrupting the very shrink_dentry_list() it's
waiting for.

Solution is straightforward - if that trylock fails, let's unlock
the dentry itself and take locks in the right order.  We need to
stabilize ->d_parent without holding ->d_lock, but that's doable
using RCU.  And we'd better do that in the very beginning of the
loop in shrink_dentry_list(), since the checks on refcount, etc.
would need to be redone anyway.

That deals with a half of the problem - killing dentries on the
shrink list itself.  Another one (dropping their parents) is
in the next commit.

locking parent is interesting - it would be easy to do rcu_read_lock(),
lock whatever we think is a parent, lock dentry itself and check
if the parent is still the right one.  Except that we need to check
that *before* locking the dentry, or we are risking taking ->d_lock
out of order.  Fortunately, once the D1 is locked, we can check if
D2->d_parent is equal to D1 without the need to lock D2; D2->d_parent
can start or stop pointing to D1 only under D1->d_lock, so taking
D1->d_lock is enough.  In other words, the right solution is
rcu_read_lock/lock what looks like parent right now/check if it's
still our parent/rcu_read_unlock/lock the child.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>