Some BMCs don't let you clear the receive irq bit in the global
enables.  This is kind of silly, but they give an error if you
try to clear it.  Compensate for this by detecting the situation
and working around it.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NThomas D <whissi@whissi.de>
Reviewed-by: NThomas D <whissi@whissi.de>

Pull SCSI fixes from James Bottomley:
 "This is our remaining set of three fixes for 4.0: two oops fixes(one
  for cable pulls triggering oopses and the other be2iscsi specific) and
  one warn on in sysfs on multipath devices using enclosures"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  Defer processing of REQ_PREEMPT requests for blocked devices
  be2iscsi: Fix kernel panic when device initialization fails
  enclosure: fix WARN_ON removing an adapter in multi-path devices

Pull SCSI target fixes from Nicholas Bellinger:
 "Just a few small fixes:

  Two from Andy, the first addresses a v4.0 target specific regression
  to a user visible configfs attribute, and the second adds a set of
  missing brackets around IPv6 discovery portal information within
  iscsi-target.

  And one from Mike that fixes an OOPs regression in traditional
  iscsi-target when an iovec allocation fails, that has been present
  since v3.10.y code.  (CC'd to stable)"

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  iscsi target: fix oops when adding reject pdu
  iscsi-target: TargetAddress in SendTargets should bracket ipv6 addresses
  target: Allow userspace to write 1 to attrib/emulate_fua_write

This fixes a oops due to a double list add when adding a reject PDU for
iscsit_allocate_iovecs allocation failures. The cmd has already been
added to the conn_cmd_list in iscsit_setup_scsi_cmd, so this has us call
iscsit_reject_cmd.

Note that for ERL0 the reject PDU is not actually sent, so this patch
is not completely tested. Just verified we do not oops. The problem is the
add reject functions return -1 which is returned all the way up to
iscsi_target_rx_thread which for ERL0 will drop the connection.
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Pull sound fixes from Takashi Iwai:
 "Here are fixes gathered for 4.0-final; one FireFire endian fix, two
  USB-audio quirks, and three HD-audio quirks.

  All relatively small and device-specific fixes, should be pretty safe
  to apply"

* tag 'sound-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: usb - Creative USB X-Fi Pro SB1095 volume knob support
  ALSA: hda - Fix headphone pin config for Lifebook T731
  ALSA: bebob: fix to processing in big-endian machine for sending cue
  ALSA: hda/realtek - Make more stable to get pin sense for ALC283
  ALSA: usb-audio: don't try to get Benchmark DAC1 sample rate
  ALSA: hda/realtek - Support Dell headset mode for ALC256

Pull arch/nios2 fixes from Ley Foon Tan:
 "There are 3 arch/nios2 fixes for 4.0 final:

   - fix cache coherency issue when debugging with gdb

   - move restart_block to struct task_struct (aligned with other
     architectures)

   - fix for missing registers defines for ptrace"

* tag 'nios2-fixes-v4.0-final' of git://git.rocketboards.org/linux-socfpga-next:
  nios2: fix cache coherency issue when debug with gdb
  nios2: add missing ptrace registers defines
  nios2: signal: Move restart_block to struct task_struct

Remove the end address checking for flushda function. We need to flush
each address line for flushda instruction, from start to end address.
This is because flushda instruction only flush the cache if tag and line
fields are matched.

Change to use ldwio instruction (bypass cache) to load the instruction
that causing trap. Our interest is the actual instruction that executed
by the processor, this should be uncached.
Note, EA address might be an userspace cached address.
Signed-off-by: NLey Foon Tan <lftan@altera.com>

Pull power management and ACPI fixes from Rafael Wysocki:
 "These are stable-candidate fixes of some recently reported issues in
  the cpufreq core, cpuidle core, the ACPI cpuidle driver and the
  hibernate core.

  Specifics:

   - Revert a 3.17 hibernate commit that was supposed to fix an issue
     related to e820 reserved regions, but broke resume from hibernation
     on Lenovo x230 (Rafael J Wysocki).

   - Prevent the ACPI cpuidle driver from overwriting the name and
     description of the C0 state set by the core when the list of
     C-states changes (Thomas Schlichter).

   - Remove the no longer needed state_count field from struct
     cpuidle_device which prevents the list of C-states shown by the
     sysfs interface from becoming incorrect when the current number of
     them is different from the number of C-states on boot (Bartlomiej
     Zolnierkiewicz).

   - The cpufreq core updates the policy object of the only online CPU
     during system resume to make it reflect the current hardware state,
     but it always assumes that CPU to be CPU0 which need not be the
     case, so fix the code to avoid that assumption (Viresh Kumar)"

* tag 'pm+acpi-4.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  Revert "PM / hibernate: avoid unsafe pages in e820 reserved regions"
  cpuidle: ACPI: do not overwrite name and description of C0
  cpuidle: remove state_count field from struct cpuidle_device
  cpufreq: Schedule work for the first-online CPU on resume

* pm-sleep:
  Revert "PM / hibernate: avoid unsafe pages in e820 reserved regions"

* pm-cpufreq:
  cpufreq: Schedule work for the first-online CPU on resume

* pm-cpuidle:
  cpuidle: ACPI: do not overwrite name and description of C0
  cpuidle: remove state_count field from struct cpuidle_device

Pull PCI fixes from Bjorn Helgaas:
 "Here are some fixes for v4.0.  I apologize for how late they are.  We
  were hoping for some better fixes, but couldn't get them polished in
  time.  These fix:

   - a Xen domU oops with PCI passthrough devices
   - a sparc T5 boot failure
   - a STM SPEAr13xx crash (use after initdata freed)
   - a cpcihp hotplug driver thinko
   - an AER thinko that printed stack junk

  Details:

  Enumeration
    - Don't look for ACPI hotplug parameters if ACPI is disabled (Bjorn Helgaas)

  Resource management
    - Revert "sparc/PCI: Clip bridge windows to fit in upstream windows" (Bjorn Helgaas)

  AER
    - Avoid info leak in __print_tlp_header() (Rasmus Villemoes)

  PCI device hotplug
    - Add missing curly braces in cpci_configure_slot() (Dan Carpenter)

  ST Microelectronics SPEAr13xx host bridge driver
    - Drop __initdata from spear13xx_pcie_driver (Matwey V. Kornilov)

* tag 'pci-v4.0-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  Revert "sparc/PCI: Clip bridge windows to fit in upstream windows"
  PCI: Don't look for ACPI hotplug parameters if ACPI is disabled
  PCI: cpcihp: Add missing curly braces in cpci_configure_slot()
  PCI/AER: Avoid info leak in __print_tlp_header()
  PCI: spear: Drop __initdata from spear13xx_pcie_driver

Adds an entry for Creative USB X-Fi to the rc_config array in
mixer_quirks.c to allow use of volume knob on the device.
Adds support for newer X-Fi Pro card, known as "Model No. SB1095"
with USB ID "041e:3237"
Signed-off-by: NDmitry M. Fedin <dmitry.fedin@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

These are all register available in nios2.
Signed-off-by: NLey Foon Tan <lftan@altera.com>

Pull drm fixes from Dave Airlie:
 "Final drm fixes: one core locking imbalance regression, and a bunch of
  i915 baytrail s/r fixes"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm: fix drm_mode_getconnector() locking imbalance regression
  drm/i915/vlv: remove wait for previous GFX clk disable request
  drm/i915/chv: Remove Wait for a previous gfx force-off
  drm/i915/vlv: save/restore the power context base reg

Pull ceph revert from Sage Weil:
 "This corrects a recent misadventure with __GFP_MEMALLOC and
  PF_MEMALLOC; it turns out it's not a good fit for RBD and we're better
  off relying on dirty page throttling"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
  Revert "libceph: use memalloc flags for net IO"

Merge misc fixes from Andrew Morton:
 "Three fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  mm: numa: disable change protection for vma(VM_HUGETLB)
  include/linux/dmapool.h: declare struct device
  mm: move zone lock to a different cache line than order-0 free page lists

Unlike most (all?) other copies from user space, kernel module loading
is almost unlimited in size.  So we do a potentially huge
"copy_from_user()" when we copy the module data from user space to the
kernel buffer, which can be a latency concern when preemption is
disabled (or voluntary).

Also, because 'copy_from_user()' clears the tail of the kernel buffer on
failures, even a *failed* copy can end up wasting a lot of time.

Normally neither of these are concerns in real life, but they do trigger
when doing stress-testing with trinity.  Running in a VM seems to add
its own overheadm causing trinity module load testing to even trigger
the watchdog.

The simple fix is to just chunk up the module loading, so that it never
tries to copy insanely big areas in one go.  That bounds the latency,
and also the amount of (unnecessarily, in this case) cleared memory for
the failure case.
Reported-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The rule for 'copy_from_user()' is that it zeroes the remaining kernel
buffer even when the copy fails halfway, just to make sure that we don't
leave uninitialized kernel memory around.  Because even if we check for
errors, some kernel buffers stay around after thge copy (think page
cache).

However, the x86-64 logic for user copies uses a copy_user_generic()
function for all the cases, that set the "zerorest" flag for any fault
on the source buffer.  Which meant that it didn't just try to clear the
kernel buffer after a failure in copy_from_user(), it also tried to
clear the destination user buffer for the "copy_in_user()" case.

Not only is that pointless, it also means that the clearing code has to
worry about the tail clearing taking page faults for the user buffer
case.  Which is just stupid, since that case shouldn't happen in the
first place.

Get rid of the whole "zerorest" thing entirely, and instead just check
if the destination is in kernel space or not.  And then just use
memset() to clear the tail of the kernel buffer if necessary.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

three commits, all cc: stable, to address Baytrail
suspend/resume issues.

* tag 'drm-intel-fixes-2015-04-08' of git://anongit.freedesktop.org/drm-intel:
  drm/i915/vlv: remove wait for previous GFX clk disable request
  drm/i915/chv: Remove Wait for a previous gfx force-off
  drm/i915/vlv: save/restore the power context base reg

Some BIOS version of Fujitsu Lifebook T731 seems to set up the
headphone pin (0x21) without the assoc number 0x0f while it's set only
to the output on the docking port (0x1a).  With the recent commit
[03ad6a8c: ALSA: hda - Fix "PCM" name being used on one DAC when
 there are two DACs], this resulted in the weird mixer element
mapping where the headphone on the laptop is assigned as a shared
volume with the speaker and the docking port is assigned as an
individual headphone.

This patch improves the situation by correcting the headphone pin
config to the more appropriate value.
Reported-and-tested-by: NTaylor Smock <smocktaylor@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

SCSI transport drivers and SCSI LLDs block a SCSI device if the
transport layer is not operational. This means that in this state
no requests should be processed, even if the REQ_PREEMPT flag has
been set. This patch avoids that a rescan shortly after a cable
pull sporadically triggers the following kernel oops:

BUG: unable to handle kernel paging request at ffffc9001a6bc084
IP: [<ffffffffa04e08f2>] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib]
Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task ffff880534aae100)
Call Trace:
 [<ffffffffa0718135>] srp_post_send+0x65/0x70 [ib_srp]
 [<ffffffffa071b9df>] srp_queuecommand+0x1cf/0x3e0 [ib_srp]
 [<ffffffffa0001ff1>] scsi_dispatch_cmd+0x101/0x280 [scsi_mod]
 [<ffffffffa0009ad1>] scsi_request_fn+0x411/0x4d0 [scsi_mod]
 [<ffffffff81223b37>] __blk_run_queue+0x27/0x30
 [<ffffffff8122a8d2>] blk_execute_rq_nowait+0x82/0x110
 [<ffffffff8122a9c2>] blk_execute_rq+0x62/0xf0
 [<ffffffffa000b0e8>] scsi_execute+0xe8/0x190 [scsi_mod]
 [<ffffffffa000b2f3>] scsi_execute_req+0xa3/0x130 [scsi_mod]
 [<ffffffffa000c1aa>] scsi_probe_lun+0x17a/0x450 [scsi_mod]
 [<ffffffffa000ce86>] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod]
 [<ffffffffa000dc2f>] __scsi_scan_target+0xdf/0x1f0 [scsi_mod]
 [<ffffffffa000dfa3>] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod]
 [<ffffffffa000edfb>] scsi_scan+0xdb/0xe0 [scsi_mod]
 [<ffffffffa000ee13>] store_scan+0x13/0x20 [scsi_mod]
 [<ffffffff811c8d9b>] sysfs_write_file+0xcb/0x160
 [<ffffffff811589de>] vfs_write+0xce/0x140
 [<ffffffff81158b53>] sys_write+0x53/0xa0
 [<ffffffff81464592>] system_call_fastpath+0x16/0x1b
 [<00007f611c9d9300>] 0x7f611c9d92ff
Reported-by: NMax Gurtuvoy <maxg@mellanox.com>
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

Kernel panic was happening as iscsi_host_remove() was called on
a host which was not yet added.
Signed-off-by: NJohn Soni Jose <sony.john-n@emulex.com>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

Some M-Audio devices require to receive bootup command just after
powering on, while codes in BeBoB driver doesn't work properly in
big-endian machine because the command should be aligned by
little-endian.

This commit fixes this bug. This fix should go to stable kernel.

Cc: Takayuki Shiroma <t.shiroma.oki@gmail.com>
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This reverts commit d63e2e1f.

David Ahern reported that d63e2e1f breaks booting on an 8-socket T5
sparc system.  He also verified that the system boots with d63e2e1f
reverted.  Yinghai has some fixes, but they need a little more polishing
than we can do before v4.0.

Link: http://lkml.kernel.org/r/5514391F.2030300@oracle.com	# report
Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org # patches
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.19+

Booting a v3.18 or newer Xen domU kernel with PCI devices passed through
results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0
hypervisor and 32-bit domU):

  BUG: unable to handle kernel paging request at 0030303e
  IP: [<c06ed0e6>] acpi_ns_validate_handle+0x12/0x1a
  Call Trace:
   [<c06eda4d>] ? acpi_evaluate_object+0x31/0x1fc
   [<c06b78e1>] ? pci_get_hp_params+0x111/0x4e0
   [<c0407bc7>] ? xen_force_evtchn_callback+0x17/0x30
   [<c04085fb>] ? xen_restore_fl_direct_reloc+0x4/0x4
   [<c0699d34>] ? pci_device_add+0x24/0x450

Don't look for ACPI configuration information if ACPI has been disabled.

I don't think this is the best fix, because we can boot plain Linux (no
Xen) with "acpi=off", and we don't need this check in pci_get_hp_params().
There should be a better fix that would make Xen domU work the same way.
The domU kernel has ACPI support but it has no AML.  There should be a way
to initialize the ACPI data structures so things fail gracefully rather
than oopsing.  This is an interim fix to address the regression.

Fixes: 6cd33649 ("PCI: Add pci_configure_device() during enumeration")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301Reported-by: NMichael D Labriola <mlabriol@gdeb.com>
Tested-by: NMichael D Labriola <mlabriol@gdeb.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.18+

Pin sense will active when power pin is wake up.
Power pin will not wake up immediately during resume state.
Add some delay to wait for power pin activated.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

See https://lkml.org/lkml/2014/10/29/643 and commit f56141e3
("all arches, signal: move restart_block to struct task_struct")
Signed-off-by: NLey Foon Tan <lftan@altera.com>

Regression in commit 2caa80e7
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Feb 22 11:38:36 2015 +0100

    drm: Fix deadlock due to getconnector locking changes

If the drm_connector_find() call returns NULL, we should no longer
call drm_modeset_unlock() to avoid locking imbalance.
Signed-off-by: NTommi Rantala <tt.rantala@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

"The domainname can be specified as either a DNS host name, a
dotted-decimal IPv4 address, or a bracketed IPv6 address as specified
in [RFC2732]."

See https://bugzilla.redhat.com/show_bug.cgi?id=1206868Reported-by: NKyle Brantley <kyle@averageurl.com>
Signed-off-by: NAndy Grover <agrover@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Pull media updates from Mauro Carvalho Chehab:
 "A series of fixup patches for version 4.0:

   - one VB2 core fixup, when stopping the stream;
   - one VB2 core fixup for dma-contig memory type;
   - driver fixes at rtl28xx, s5p (tv, jpeg, mfc, soc-camera, sh_veu,
     cx23885, gspca"

* tag 'media/v3.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] rtl28xxu: return success for unimplemented FE callback
  [media] rtl2832: disable regmap register cache
  [media] vb2: Fix dma_dir setting for dma-contig mem type
  [media] media: s5p-mfc: fix broken pointer cast on 64bit arch
  [media] media: s5p-mfc: fix mmap support for 64bit arch
  [media] cx23885: fix querycap
  [media] sh_veu: v4l2_dev wasn't set
  [media] s5p-mfc: Fix NULL pointer dereference caused by not set q->lock
  [media] s5p-jpeg: exynos3250: fix erroneous reset procedure
  [media] s5p-tv: hdmi needs I2C support
  [media] s5p-jpeg: Initialize cb and cr to zero
  [media] media: fix gspca drivers build dependencies
  [media] soc-camera: Fix devm_kfree() in soc_of_bind()
  [media] media: atmel-isi: increase the burst length to improve the performance
  [media] vb2: fix 'UNBALANCED' warnings when calling vb2_thread_stop()

Currently when a process accesses a hugetlb range protected with
PROTNONE, unexpected COWs are triggered, which finally puts the hugetlb
subsystem into a broken/uncontrollable state, where for example
h->resv_huge_pages is subtracted too much and wraps around to a very
large number, and the free hugepage pool is no longer maintainable.

This patch simply stops changing protection for vma(VM_HUGETLB) to fix
the problem.  And this also allows us to avoid useless overhead of minor
faults.
Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Suggested-by: NMel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: David Rientjes <rientjes@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

dmapool uses struct device in function arguments but relies on an
implicit inclusion to declare struct device causing warnings in some
configurations:

  include/linux/dmapool.h:31:7: warning: 'struct device' declared inside parameter list

Fix this by adding a struct device declaration to the file.
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Huang Ying reported the following problem due to commit 3484b2de ("mm:
rearrange zone fields into read-only, page alloc, statistics and page
reclaim lines") from the Intel performance tests

    24b7e581  3484b2de
    ----------------  --------------------------
             %stddev     %change         %stddev
                 \          |                \
        152288 \261  0%     -46.2%      81911 \261  0%  aim7.jobs-per-min
           237 \261  0%     +85.6%        440 \261  0%  aim7.time.elapsed_time
           237 \261  0%     +85.6%        440 \261  0%  aim7.time.elapsed_time.max
         25026 \261  0%     +70.7%      42712 \261  0%  aim7.time.system_time
       2186645 \261  5%     +32.0%    2885949 \261  4%  aim7.time.voluntary_context_switches
       4576561 \261  1%     +24.9%    5715773 \261  0%  aim7.time.involuntary_context_switches

The problem is specific to very large machines under stress.  It was not
reproducible with the machines I had used to justify the original patch
because large numbers of CPUs are required.  When pressure is high enough,
the cache line is bouncing between CPUs trying to acquire the lock and the
holder of the lock adjusting free lists.  The intention was that the
acquirer of the lock would automatically have the cache line holding the
free lists but according to Huang, this is not a universal win.

One possibility is to move the zone lock to its own cache line but it
increases the size of the zone.  This patch moves the lock to the other
end of the free lists where they do not contend under high pressure.  It
does mean the page allocator paths now require more cache lines but Huang
reports that it restores performance to previous levels on large machines

             %stddev     %change         %stddev
                 \          |                \
         84568 \261  1%     +94.3%     164280 \261  1%  aim7.jobs-per-min
       2881944 \261  2%     -35.1%    1870386 \261  8%  aim7.time.voluntary_context_switches
           681 \261  1%      -3.4%        658 \261  0%  aim7.time.user_time
       5538139 \261  0%     -12.1%    4867884 \261  0%  aim7.time.involuntary_context_switches
         44174 \261  1%     -46.0%      23848 \261  1%  aim7.time.system_time
           426 \261  1%     -48.4%        219 \261  1%  aim7.time.elapsed_time
           426 \261  1%     -48.4%        219 \261  1%  aim7.time.elapsed_time.max
           468 \261  1%     -43.1%        266 \261  2%  uptime.boot
Signed-off-by: NMel Gorman <mgorman@suse.de>
Reported-by: NHuang Ying <ying.huang@intel.com>
Tested-by: NHuang Ying <ying.huang@intel.com>
Acked-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 89baaa57.

Dirty page throttling should be sufficient for us in the general case
so there is no need to use __GFP_MEMALLOC - it would be needed only in
the swap-over-rbd case, which we currently don't support.  (It would
probably take approximately the commit that is being reverted to add
that support, but we would also need the "swap" option to distinguish
from the general case and make sure swap ceph_client-s aren't shared
with anything else.)  See ceph-devel threads [1] and [2] for the
details of why enabling pfmemalloc reserves for all cases is a bad
thing.

On top of potential system lockups related to drained emergency
reserves, this turned out to cause ceph lockups in case peers are on
the same host and communicating via loopback due to sk_filter()
dropping pfmemalloc skbs on the receiving side because the receiving
loopback socket is not tagged with SOCK_MEMALLOC.

[1] "SOCK_MEMALLOC vs loopback"
    http://www.spinics.net/lists/ceph-devel/msg22998.html
[2] "[PATCH] libceph: don't set memalloc flags in loopback case"
    http://www.spinics.net/lists/ceph-devel/msg23392.html

Conflicts:
	net/ceph/messenger.c [ context: tcp_nodelay option ]

Cc: Mike Christie <michaelc@cs.wisc.edu>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Sage Weil <sage@redhat.com>
Cc: stable@vger.kernel.org # 3.18+, needs backporting
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
Acked-by: NMike Christie <michaelc@cs.wisc.edu>
Acked-by: NMel Gorman <mgorman@suse.de>

Looks like it was introduced in:

commit 650ad970
Author: Imre Deak <imre.deak@intel.com>
Date:   Fri Apr 18 16:35:02 2014 +0300

    drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of

but I'm not sure why.  It has caused problems for us in the past (see
85250ddf "drm/i915/chv: Remove Wait for a previous gfx force-off"
and 8d4eee9c "drm/i915: vlv: increase timeout when forcing on the
GFX clock") and doesn't seem to be required, so let's just drop it.

References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NDarren Hart <dvhart@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Cc: stable@vger.kernel.org # c9c52e24: drm/i915/chv: Remove Wait ...
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence
Signed-off-by: NDeepak S <deepak.s@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this
reg.  If it's unlocked, we can just restore the previous value, and if
it's locked (in case the BIOS re-programmed it for us) the write will be
ignored and we'll still have "did it move" sanity check in the PM code to
warn us if something is still amiss.

References: https://bugs.freedesktop.org/show_bug.cgi?id=89611Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NDarren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Commit 84c91b7a (PM / hibernate: avoid unsafe pages in e820 reserved
regions) is reported to make resume from hibernation on Lenovo x230
unreliable, so revert it.

We will revisit the issue the commit in question was supposed to fix
in the future.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=96111Reported-by: Nrhn <kebuac.rhn@porcupinefactory.org>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull networking fixes from David Miller:

 1) In TCP, don't register an FRTO for cumulatively ACK'd data that was
    previously SACK'd, from Neal Cardwell.

 2) Need to hold RNL mutex in ipv4 multicast code namespace cleanup,
    from Cong WANG.

 3) Similarly we have to hold RNL mutex for fib_rules_unregister(), also
    from Cong WANG.

 4) Revert and rework netns nsid allocation fix, from Nicolas Dichtel.

 5) When we encapsulate for a tunnel device, skb->sk still points to the
    user socket.  So this leads to cases where we retraverse the
    ipv4/ipv6 output path with skb->sk being of some other address
    family (f.e. AF_PACKET).  This can cause things to crash since the
    ipv4 output path is dereferencing an AF_PACKET socket as if it were
    an ipv4 one.

    The short term fix for 'net' and -stable is to elide these socket
    checks once we've entered an encapsulation sequence by testing
    xmit_recursion.

    Longer term we have a better solution wherein we pass the tunnel's
    socket down through the output paths, but that is way too invasive
    for 'net' and -stable.

    From Hannes Frederic Sowa.

 6) l2tp_init() failure path forgets to unregister per-net ops, from
    Cong WANG.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  net/mlx4_core: Fix error message deprecation for ConnectX-2 cards
  net: dsa: fix filling routing table from OF description
  l2tp: unregister l2tp_net_ops on failure path
  mvneta: dont call mvneta_adjust_link() manually
  ipv6: protect skb->sk accesses from recursive dereference inside the stack
  netns: don't allocate an id for dead netns
  Revert "netns: don't clear nsid too early on removal"
  ip6mr: call del_timer_sync() in ip6mr_free_table()
  net: move fib_rules_unregister() under rtnl lock
  ipv4: take rtnl_lock and mark mrt table as freed on namespace cleanup
  tcp: fix FRTO undo on cumulative ACK of SACKed range
  xen-netfront: transmit fully GSO-sized packets

Commit 1daa4303 ("net/mlx4_core: Deprecate error message at
ConnectX-2 cards startup to debug") did the deprecation only for port 1
of the card. Need to deprecate for port 2 as well.

Fixes: 1daa4303 ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug")
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>