ovl: default permissions

Add mount option "default_permissions" to alter the way permissions are
calculated.

Without this option and prior to this patch permissions were calculated by
underlying lower or upper filesystem.

With this option the permissions are calculated by overlayfs based on the
file owner, group and mode bits.

This has significance for example when a read-only exported NFS filesystem
is used as a lower layer.  In this case the underlying NFS filesystem will
reply with EROFS, in which case all we know is that the filesystem is
read-only.  But that's not what we are interested in, we are interested in
whether the access would be allowed if the filesystem wasn't read-only; the
server doesn't tell us that, and would need updating at various levels,
which doesn't seem practicable.

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>

ovl: free lower_mnt array in ovl_put_super

This fixes memory leak after umount.

Kmemleak report:

unreferenced object 0xffff8800ba791010 (size 8):
  comm "mount", pid 2394, jiffies 4294996294 (age 53.920s)
  hex dump (first 8 bytes):
    20 1c 13 02 00 88 ff ff                           .......
  backtrace:
    [<ffffffff811f8cd4>] create_object+0x124/0x2c0
    [<ffffffff817a059b>] kmemleak_alloc+0x7b/0xc0
    [<ffffffff811dffe6>] __kmalloc+0x106/0x340
    [<ffffffffa0152bfc>] ovl_fill_super+0x55c/0x9b0 [overlay]
    [<ffffffff81200ac4>] mount_nodev+0x54/0xa0
    [<ffffffffa0152118>] ovl_mount+0x18/0x20 [overlay]
    [<ffffffff81201ab3>] mount_fs+0x43/0x170
    [<ffffffff81220d34>] vfs_kern_mount+0x74/0x170
    [<ffffffff812233ad>] do_mount+0x22d/0xdf0
    [<ffffffff812242cb>] SyS_mount+0x7b/0xc0
    [<ffffffff817b6bee>] entry_SYSCALL_64_fastpath+0x12/0x76
    [<ffffffffffffffff>] 0xffffffffffffffff

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Fixes: dd662667e6d3 ("ovl: add mutli-layer infrastructure")
Cc: <stable@vger.kernel.org> # v4.0+

ovl: free stack of paths in ovl_fill_super

This fixes small memory leak after mount.

Kmemleak report:

unreferenced object 0xffff88003683fe00 (size 16):
  comm "mount", pid 2029, jiffies 4294909563 (age 33.380s)
  hex dump (first 16 bytes):
    20 27 1f bb 00 88 ff ff 40 4b 0f 36 02 88 ff ff   '......@K.6....
  backtrace:
    [<ffffffff811f8cd4>] create_object+0x124/0x2c0
    [<ffffffff817a059b>] kmemleak_alloc+0x7b/0xc0
    [<ffffffff811dffe6>] __kmalloc+0x106/0x340
    [<ffffffffa01b7a29>] ovl_fill_super+0x389/0x9a0 [overlay]
    [<ffffffff81200ac4>] mount_nodev+0x54/0xa0
    [<ffffffffa01b7118>] ovl_mount+0x18/0x20 [overlay]
    [<ffffffff81201ab3>] mount_fs+0x43/0x170
    [<ffffffff81220d34>] vfs_kern_mount+0x74/0x170
    [<ffffffff812233ad>] do_mount+0x22d/0xdf0
    [<ffffffff812242cb>] SyS_mount+0x7b/0xc0
    [<ffffffff817b6bee>] entry_SYSCALL_64_fastpath+0x12/0x76
    [<ffffffffffffffff>] 0xffffffffffffffff

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Fixes: a78d9f0d5d5c ("ovl: support multiple lower layers")
Cc: <stable@vger.kernel.org> # v4.0+

ovl: fix open in stacked overlay

If two overlayfs filesystems are stacked on top of each other, then we need
recursion in ovl_d_select_inode().

I guess d_backing_inode() is supposed to do that.  But currently it doesn't
and that functionality is open coded in vfs_open().  This is now copied
into ovl_d_select_inode() to fix this regression.

Reported-by: Alban Crequy <alban.crequy@gmail.com>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay...")
Cc: David Howells <dhowells@redhat.com>
Cc: <stable@vger.kernel.org> # v4.2+

ovl: fix dentry reference leak

In ovl_copy_up_locked(), newdentry is leaked if the function exits through
out_cleanup as this just to out after calling ovl_cleanup() - which doesn't
actually release the ref on newdentry.

The out_cleanup segment should instead exit through out2 as certainly
newdentry leaks - and possibly upper does also, though this isn't caught
given the catch of newdentry.

Without this fix, something like the following is seen:

BUG: Dentry ffff880023e9eb20{i=f861,n=#ffff880023e82d90} still in use (1) [unmount of tmpfs tmpfs]
BUG: Dentry ffff880023ece640{i=0,n=bigfile}  still in use (1) [unmount of tmpfs tmpfs]

when unmounting the upper layer after an error occurred in copyup.

An error can be induced by creating a big file in a lower layer with
something like:

dd if=/dev/zero of=/lower/a/bigfile bs=65536 count=1 seek=$((0xf000))

to create a large file (4.1G).  Overlay an upper layer that is too small
(on tmpfs might do) and then induce a copy up by opening it writably.

Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@vger.kernel.org> # v3.18+

ovl: use O_LARGEFILE in ovl_copy_up()

Open the lower file with O_LARGEFILE in ovl_copy_up().

Pass O_LARGEFILE unconditionally in ovl_copy_up_data() as it's purely for
catching 32-bit userspace dealing with a file large enough that it'll be
mishandled if the application isn't aware that there might be an integer
overflow.  Inside the kernel, there shouldn't be any problems.

Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@vger.kernel.org> # v3.18+

Linux 4.2

thermal: power_allocator: allocate with kcalloc what you free with kfree

Commit cf736ea6f902 ("thermal: power_allocator: do not use devm*
interfaces") forgot to change a devm_kcalloc() to just kcalloc(), but
it's corresponding devm_kfree() was changed to kfree().  Allocate with
kcalloc() to match the kfree().

Fixes: cf736ea6f902 ("thermal: power_allocator: do not use devm* interfaces")
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'for-4.2-fixes' of git://git./linux/kernel/git/tj/libata

Pull libata fixlet from Tejun Heo:
 "Simple blacklist entry addition"

* 'for-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  Add factory recertified Crucial M500s to blacklist

Merge tag 'sound-fix-4.2' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Here are stable fixes that have been gathered since rc8: fixes for
  HD-audio widget power control regressions since 4.1, a NULL fix for
  HD-audio HDMI, a noise fix for Conexant codecs and a quirk addition
  for USB-Audio DSD"

* tag 'sound-fix-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Fix path power activation
  ALSA: hda - Check all inputs for is_active_nid_for_any()
  ALSA: hda: fix possible NULL dereference
  ALSA: hda - Shutdown CX20722 on reboot/free to avoid spurious noises
  ALSA: usb: Add native DSD support for Gustard DAC-X20U

Merge tag 'powerpc-4.2-4' of git://git./linux/kernel/git/powerpc/linux

Pull powerpc fixes from Michael Ellerman:
 "Fix MSI/MSI-X on pseries from Guilherme"

* tag 'powerpc-4.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case
  PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code

Merge git://git./linux/kernel/git/davem/net

Pull networking fixes from David Miller:
 "Some straggler bug fixes here:

   1) Netlink_sendmsg() doesn't check iterator type properly in mmap
      case, from Ken-ichirou MATSUZAWA.

   2) Don't sleep in atomic context in bcmgenet driver, from Florian
      Fainelli.

   3) The pfkey_broadcast() code patch can't actually ever use anything
      other than GFP_ATOMIC.  And the cases that right now pass
      GFP_KERNEL or similar will currently trigger an RCU splat.  Just
      use GFP_ATOMIC unconditionally.  From David Ahern.

   4) Fix FD bit timings handling in pcan_usb driver, from Marc
      Kleine-Budde.

   5) Cache dst leaked in ip6_gre tunnel removal, fix from Huaibin Wang.

   6) Traversal into drivers/net/ethernet/renesas should be triggered by
      CONFIG_NET_VENDOR_RENESAS, not a particular driver's config
      option.  From Kazuya Mizuguchi.

   7) Fix regression in handling of igmp_join errors in vxlan, from
      Marcelo Ricardo Leitner.

   8) Make phy_{read,write}_mmd_indirect() properly take the mdio_lock
      mutex when programming the registers.  From Russell King.

   9) Fix non-forced handling in u32_destroy(), from WANG Cong.

  10) Test the EVENT_NO_RUNTIME_PM flag before it is cleared in
      usbnet_stop(), from Eugene Shatokhin.

  11) In sfc driver, don't fetch statistics firmware isn't capable of,
      from Bert Kenward.

  12) Verify ASCONF address parameter location in SCTP, from Xin Long"

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  sctp: donot reset the overall_error_count in SHUTDOWN_RECEIVE state
  sctp: asconf's process should verify address parameter is in the beginning
  sfc: only use vadaptor stats if firmware is capable
  net: phy: fixed: propagate fixed link values to struct
  usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared
  drivers: net: xgene: fix: Oops in linkwatch_fire_event
  cls_u32: complete the check for non-forced case in u32_destroy()
  net: fec: use reinit_completion() in mdio accessor functions
  net: phy: add locking to phy_read_mmd_indirect()/phy_write_mmd_indirect()
  vxlan: re-ignore EADDRINUSE from igmp_join
  net: compile renesas directory if NET_VENDOR_RENESAS is configured
  ip6_gre: release cached dst on tunnel removal
  phylib: Make PHYs children of their MDIO bus, not the bus' parent.
  can: pcan_usb: don't provide CAN FD bittimings by non-FD adapters
  net: Fix RCU splat in af_key
  net: bcmgenet: fix uncleaned dma flags
  net: bcmgenet: Avoid sleeping in bcmgenet_timeout
  netlink: mmap: fix tx type check

Merge branch 'libnvdimm-fixes' of git://git./linux/kernel/git/nvdimm/nvdimm

Pull nvdimm fixlet from Dan Williams:
 "This is a libnvdimm ABI fixup.

  I pushed back on this change quite hard given the late date, that it
  appears to be purely cosmetic, sysfs is not necessarily meant to be a
  user friendly UI, and the kernel interprets the reversed polarity of
  the ACPI_NFIT_MEM_ARMED flag correctly.  When this flag is set, the
  energy source of an NVDIMM is not armed and any new writes to the DIMM
  may not be preserved.

  However, Bob Moore warned me that it is important to get these things
  named correctly wherever they appear otherwise we run the risk of a
  less than cautious firmware engineer implementing the polarity the
  wrong way.  Once a mistake like that escapes into production platforms
  the flag becomes useless and we need to move to a new bit position.

  Bob has agreed to take a change through ACPICA to rename
  ACPI_NFIT_MEM_ARMED to ACPI_NFIT_MEM_NOT_ARMED, and the patch below
  from Toshi brings the sysfs representation of these flags in line with
  their respective polarities.

  Please pull for 4.2 as this is the first kernel to expose the ACPI
  NFIT sysfs representation, and this is likely a kernel that firmware
  developers will be using for checking out their NVDIMM enabling"

* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  nfit: Clarify memory device state flags strings

sctp: donot reset the overall_error_count in SHUTDOWN_RECEIVE state

Commit f8d960524328 ("sctp: Enforce retransmission limit during shutdown")
fixed a problem with excessive retransmissions in the SHUTDOWN_PENDING by not
resetting the association overall_error_count.  This allowed the association
to better enforce assoc.max_retrans limit.

However, the same issue still exists when the association is in SHUTDOWN_RECEIVED
state.  In this state, HB-ACKs will continue to reset the overall_error_count
for the association would extend the lifetime of association unnecessarily.

This patch solves this by resetting the overall_error_count whenever the current
state is small then SCTP_STATE_SHUTDOWN_PENDING.  As a small side-effect, we
end up also handling SCTP_STATE_SHUTDOWN_ACK_SENT and SCTP_STATE_SHUTDOWN_SENT
states, but they are not really impacted because we disable Heartbeats in those
states.

Fixes: Commit f8d960524328 ("sctp: Enforce retransmission limit during shutdown")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

sctp: asconf's process should verify address parameter is in the beginning

in sctp_process_asconf(), we get address parameter from the beginning of
the addip params. but we never check if it's really there. if the addr
param is not there, it still can pass sctp_verify_asconf(), then to be
handled by sctp_process_asconf(), it will not be safe.

so add a code in sctp_verify_asconf() to check the address parameter is in
the beginning, or return false to send abort.

note that this can also detect multiple address parameters, and reject it.

Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

nfit: Clarify memory device state flags strings

ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines
NVDIMM status as follows.  These bits indicate multiple info,
such as failures, pending event, and capability.

  Bit [0] set to 1 to indicate that the previous SAVE to the
  Memory Device failed.
  Bit [1] set to 1 to indicate that the last RESTORE from the
  Memory Device failed.
  Bit [2] set to 1 to indicate that platform flush of data to
  Memory Device failed. As a result, the restored data content
  may be inconsistent even if SAVE and RESTORE do not indicate
  failure.
  Bit [3] set to 1 to indicate that the Memory Device is observed
  to be not armed prior to OSPM hand off. A Memory Device is
  considered armed if it is able to accept persistent writes.
  Bit [4] set to 1 to indicate that the Memory Device observed
  SMART and health events prior to OSPM handoff.

/sys/bus/nd/devices/nmemX/nfit/flags shows this flags info.
The output strings associated with the bits are "save", "restore",
"smart", etc., which can be confusing as they may be interpreted
as positive status, i.e. save succeeded.

Change also the dev_info() message in acpi_nfit_register_dimms()
to be consistent with the sysfs flags strings.

Reported-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
[ross: rename 'not_arm' to 'not_armed']
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
[djbw: defer adding bit5, HEALTH_ENABLED, for now]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

sfc: only use vadaptor stats if firmware is capable

Some of the stats handling code differs based on SR-IOV support,
and SRIOV support is only available if full-featured firmware is
used.
Do not use vadaptor stats if firmware mode is not set to
full-featured.

Signed-off-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: phy: fixed: propagate fixed link values to struct

The fixed link values parsed from the device tree are stored in
the struct fixed_phy member status. The struct phy_device members
speed, duplex were not updated.

Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux

Pull amr64 kvm fix from Will Deacon:
 "We've uncovered a nasty bug in the arm64 KVM code which allows a badly
  behaved 32-bit guest to bring down the host.  The fix is simple (it's
  what I believe we call a "brown paper bag" bug) and I don't think it
  makes sense to sit on this, particularly as Russell ended up
  triggering this rather than just somebody noticing a potential problem
  by inspection.

  Usually arm64 KVM changes would go via Paolo's tree, but he's on
  holiday at the moment and the deal is that anything urgent gets
  shuffled via the arch trees, so here it is.

  Summary:

  Fix arm64 KVM issue when injecting an abort into a 32-bit guest, which
  would lead to an illegal exception return at EL2 and a subsequent host
  crash"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: KVM: Fix host crash when injecting a fault into a 32bit guest

arm64: KVM: Fix host crash when injecting a fault into a 32bit guest

When injecting a fault into a misbehaving 32bit guest, it seems
rather idiotic to also inject a 64bit fault that is only going
to corrupt the guest state. This leads to a situation where we
perform an illegal exception return at EL2 causing the host
to crash instead of killing the guest.

Just fix the stupid bug that has been there from day 1.

Cc: <stable@vger.kernel.org>
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

Merge branch 'for-linus' of git://git.kernel.dk/linux-block

Pull block fixes from Jens Axboe:
 "Two fixes in this pull request:

   - The writeback regression fix from Tejun, which has been weeks in
     the making.  This fixes a case where we would sometimes not issue
     writeback when we should have.

   - An older fix for a memory corruption issue in mtip32xx.  It was
     deferred since we wanted a better fix for this (driver should not
     have to handle that case), but given the timing, it's better to put
     the simple fix in for 4.2 release"

* 'for-linus' of git://git.kernel.dk/linux-block:
  mtip32x: fix regression introduced by blk-mq per-hctx flush
  writeback: sync_inodes_sb() must write out I_DIRTY_TIME inodes and always call wait_sb_inodes()

Add factory recertified Crucial M500s to blacklist

The Crucial M500 is known to have issues with queued TRIM commands, the
factory recertified SSDs use a different model number naming convention
which causes them to get ignored by the blacklist.

The new naming convention boils down to: s/Crucial_/FC/

Signed-off-by: Guillermo A. Amaral <g@maral.me>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case

Since commit 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if
kernel doesn't support MSI"), the setup of dev->msi_cap/msix_cap and the
disable of MSI/MSI-X interrupts isn't being done at PCI probe time, as
the logic responsible for this was moved in the aforementioned commit
from pci_device_add() to pci_setup_device(). The latter function is not
reachable on PowerPC pseries platform during Open Firmware PCI probing
time.

This exhibits as drivers not being able to enable MSI, eg:

  bnx2x 0000:01:00.0: no msix capability found

This patch calls pci_msi_setup_pci_dev() explicitly to disable MSI/MSI-X
during PCI probe time on pSeries platform.

Fixes: 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI")
[mpe: Flesh out change log and clarify comment]
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code

Commit 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel
doesn't support MSI") changed the location of the code that initialises
dev->msi_cap/msix_cap and then disables MSI/MSI-X interrupts at PCI
probe time in devices that have this flag set. It moved the code from
pci_msi_init_pci_dev() to a new function named pci_msi_setup_pci_dev(),
called by pci_setup_device().

The pseries PCI probing code does not call pci_setup_device(), so since
the aforementioned commit the function pci_msi_setup_pci_dev() is not
called and MSI/MSI-X interrupts are left enabled. Additionally because
dev->msi_cap/msix_cap are not initialised no driver can ever enable
MSI/MSI-X.

To fix this, the pseries PCI probe should manually call
pci_msi_setup_pci_dev(), so this patch makes it non-static.

Fixes: 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI")
[mpe: Update change log to mention dev->msi_cap/msix_cap]
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared

It is needed to check EVENT_NO_RUNTIME_PM bit of dev->flags in
usbnet_stop(), but its value should be read before it is cleared
when dev->flags is set to 0.

The problem was spotted and the fix was provided by
Oliver Neukum <oneukum@suse.de>.

Signed-off-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'for-linus' of git://git./linux/kernel/git/jmorris/linux-security

Pull LSM regression fix from James Morris.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  LSM: restore certain default error codes

Merge branch 'libnvdimm-fixes' of git://git./linux/kernel/git/nvdimm/nvdimm

Pull nvdimm fix from Dan Williams:
 "A single fix for status register read size in the nd_blk driver.

  The effect of getting the width of this register read wrong is that
  all I/O fails when the read returns non-zero.  Given the availability
  of ACPI 6 NFIT enabled platforms, this could reasonably wait to come
  in during the 4.3 merge window with a tag for 4.2-stable.  Otherwise,
  this makes the 4.2 kernel fully functional with devices that conform
  to the mmio-block-apertures defined in the ACPI 6 NFIT (NVDIMM
  Firmware Interface Table)"

* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  nfit, nd_blk: BLK status register is only 32 bits

drivers: net: xgene: fix: Oops in linkwatch_fire_event

[ 1065.801569] Internal error: Oops: 96000006 [#1] SMP
...
[ 1065.866655] Hardware name: AppliedMicro Mustang/Mustang, BIOS 1.1.0 Apr 22 2015
[ 1065.873937] Workqueue: events_power_efficient phy_state_machine
[ 1065.879837] task: fffffe01de105e80 ti: fffffe00bcf18000 task.ti: fffffe00bcf18000
[ 1065.887288] PC is at linkwatch_fire_event+0xac/0xc0
[ 1065.892141] LR is at linkwatch_fire_event+0xa0/0xc0
[ 1065.896995] pc : [<fffffe000060284c>] lr : [<fffffe0000602840>] pstate: 200001c5
[ 1065.904356] sp : fffffe00bcf1bd00
...
[ 1066.196813] Call Trace:
[ 1066.199248] [<fffffe000060284c>] linkwatch_fire_event+0xac/0xc0
[ 1066.205140] [<fffffe000061167c>] netif_carrier_off+0x54/0x64
[ 1066.210773] [<fffffe00004f1654>] phy_state_machine+0x120/0x3bc
[ 1066.216578] [<fffffe00000d8d10>] process_one_work+0x15c/0x3a8
[ 1066.222296] [<fffffe00000d9090>] worker_thread+0x134/0x470
[ 1066.227757] [<fffffe00000df014>] kthread+0xe0/0xf8
[ 1066.232525] Code: 97f65ee9 f9420660 d538d082 8b000042 (885f7c40)

The fix is to call phy_disconnect() from xgene_enet_mdio_remove,
which in turn call cancel_delayed_work_sync().

Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

cls_u32: complete the check for non-forced case in u32_destroy()

In commit 1e052be69d04 ("net_sched: destroy proto tp when all filters are gone")
I added a check in u32_destroy() to see if all real filters are gone
for each tp, however, that is only done for root_ht, same is needed
for others.

This can be reproduced by the following tc commands:

tc filter add dev eth0 parent 1:0 prio 5 handle 15: protocol ip u32 divisor 256
tc filter add dev eth0 protocol ip parent 1: prio 5 handle 15:2:2 u32
ht 15:2: match ip src 10.0.0.2 flowid 1:10
tc filter add dev eth0 protocol ip parent 1: prio 5 handle 15:2:3 u32
ht 15:2: match ip src 10.0.0.3 flowid 1:10

Fixes: 1e052be69d04 ("net_sched: destroy proto tp when all filters are gone")
Reported-by: Akshat Kakkar <akshat.1984@gmail.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

LSM: restore certain default error codes

While in most cases commit b1d9e6b064 ("LSM: Switch to lists of hooks")
retained previous error returns, in three cases it altered them without
any explanation in the commit message. Restore all of them - in the
security_old_inode_init_security() case this led to reiserfs using
uninitialized data, sooner or later crashing the system (the only other
user of this function - ocfs2 - was unaffected afaict, since it passes
pre-initialized structures).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>

nfit, nd_blk: BLK status register is only 32 bits

Only read 32 bits for the BLK status register in read_blk_stat().

The format and size of this register is defined in the
"NVDIMM Driver Writer's guide":

http://pmem.io/documents/NVDIMM_Driver_Writers_Guide.pdf

Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reported-by: Nicholas Moulin <nicholas.w.moulin@linux.intel.com>
Tested-by: Nicholas Moulin <nicholas.w.moulin@linux.intel.com>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

net: fec: use reinit_completion() in mdio accessor functions

Rather than re-initialising the entire completion on every mdio access,
use reinit_completion() which only resets the completion count.  This
avoids possible reinitialisation of the contained spinlock and waitqueue
while they may be in use (eg, mid-completion.)

Such an event could occur if there's a long delay in interrupt handling
causing the mdio accessor to time out, then a second access comes in
while the interrupt handler on a different CPU has called complete().
Another scenario where this has been observed is while locking has
been missing at the phy layer, allowing concurrent attempts to access
the MDIO bus.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: phy: add locking to phy_read_mmd_indirect()/phy_write_mmd_indirect()

The phy layer is missing locking for the above two functions - it
has been observed that two threads (userspace and the phy worker
thread) can race, entering the bus ->write or ->read functions
simultaneously.

This causes the FEC driver to initialise a completion while another
thread is waiting on it or while the interrupt is calling complete()
on it, which causes spinlock unlock-without-lock, spinlock lockups,
and completion timeouts.

Fixes: a59a4d192 ("phy: add the EEE support and the way to access to the MMD registers.")
Fixes: 0c1d77dfb ("net: libphy: Add phy specific function to access mmd phy registers")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

vxlan: re-ignore EADDRINUSE from igmp_join

Before 56ef9c909b40[1] it used to ignore all errors from igmp_join().
That commit enhanced that and made it error out whatever error happened
with igmp_join(), but that's not good because when using multicast
groups vxlan will try to join it multiple times if the socket is reused
and then the 2nd and further attempts will fail with EADDRINUSE.

As we don't track to which groups the socket is already subscribed, it's
okay to just ignore that error.

Fixes: 56ef9c909b40 ("vxlan: Move socket initialization to within rtnl scope")
Reported-by: John Nielsen <lists@jnielsen.net>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'linux-can-fixes-for-4.2-20150825' of git://git./linux/kernel/git/mkl/linux-can

Marc Kleine-Budde says:

====================
this is the updated pull request of one patch by me for the peak_usb
driver. It fixes the driver, so that non FD adapters don't provide CAN
FD bittimings.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

net: compile renesas directory if NET_VENDOR_RENESAS is configured

Currently the renesas ethernet driver directory is compiled if SH_ETH is
configured rather than NET_VENDOR_RENESAS. Although incorrect that was
quite harmless as until recently as SH_ETH configured the only driver in
the renesas directory. However, as of c156633f1353 ("Renesas Ethernet AVB
driver proper") the renesas directory includes another driver, configured
by RAVB, and it makes little sense for it to have a hidden dependency on
SH_ETH.

Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
[horms: rewrote changelog]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

ip6_gre: release cached dst on tunnel removal

When a tunnel is deleted, the cached dst entry should be released.

This problem may prevent the removal of a netns (seen with a x-netns IPv6
gre tunnel):
  unregister_netdevice: waiting for lo to become free. Usage count = 3

CC: Dmitry Kozlov <xeb@mail.ru>
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: huaibin Wang <huaibin.wang@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

mtip32x: fix regression introduced by blk-mq per-hctx flush

Hi,

After commit f70ced091707 (blk-mq: support per-distpatch_queue flush
machinery), the mtip32xx driver may oops upon module load due to walking
off the end of an array in mtip_init_cmd.  On initialization of the
flush_rq, init_request is called with request_index >= the maximum queue
depth the driver supports.  For mtip32xx, this value is used to index
into an array.  What this means is that the driver will walk off the end
of the array, and either oops or cause random memory corruption.

The problem is easily reproduced by doing modprobe/rmmod of the mtip32xx
driver in a loop.  I can typically reproduce the problem in about 30
seconds.

Now, in the case of mtip32xx, it actually doesn't support flush/fua, so
I think we can simply return without doing anything.  In addition, no
other mq-enabled driver does anything with the request_index passed into
init_request(), so no other driver is affected.  However, I'm not really
sure what is expected of drivers.  Ming, what did you envision drivers
would do when initializing the flush requests?

Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>

writeback: sync_inodes_sb() must write out I_DIRTY_TIME inodes and always call wait_sb_inodes()

e79729123f63 ("writeback: don't issue wb_writeback_work if clean")
updated writeback path to avoid kicking writeback work items if there
are no inodes to be written out; unfortunately, the avoidance logic
was too aggressive and broke sync_inodes_sb().

* sync_inodes_sb() must write out I_DIRTY_TIME inodes but I_DIRTY_TIME
  inodes dont't contribute to bdi/wb_has_dirty_io() tests and were
  being skipped over.

* inodes are taken off wb->b_dirty/io/more_io lists after writeback
  starts on them.  sync_inodes_sb() skipping wait_sb_inodes() when
  bdi_has_dirty_io() breaks it by making it return while writebacks
  are in-flight.

This patch fixes the breakages by

* Removing bdi_has_dirty_io() shortcut from bdi_split_work_to_wbs().
  The callers are already testing the condition.

* Removing bdi_has_dirty_io() shortcut from sync_inodes_sb() so that
  it always calls into bdi_split_work_to_wbs() and wait_sb_inodes().

* Making bdi_split_work_to_wbs() consider the b_dirty_time list for
  WB_SYNC_ALL writebacks.

Kudos to Eryu, Dave and Jan for tracking down the issue.

Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: e79729123f63 ("writeback: don't issue wb_writeback_work if clean")
Link: http://lkml.kernel.org/g/20150812101204.GE17933@dhcp-13-216.nay.redhat.com
Reported-and-bisected-by: Eryu Guan <eguan@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jan Kara <jack@suse.com>
Cc: Ted Ts'o <tytso@google.com>
Signed-off-by: Jens Axboe <axboe@fb.com>

phylib: Make PHYs children of their MDIO bus, not the bus' parent.

commit 18ee49ddb0d2 ("phylib: rename mii_bus::dev to mii_bus::parent")
changed the parent of PHY devices from the bus to the bus parent.

Then, commit 4dea547fef1b ("phylib: rework to prepare for OF
registration of PHYs") moved the code into phy_device.c

At this point, it is somewhat unclear why the change was seen as
necessary.  But, when we look at the device model tree in
/sys/devices, it is clearly incorrect.  The PHYs should be children of
their MDIO bus.

Change the PHY's parent device to be the MDIO bus device.

Cc: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: David Daney <david.daney@cavium.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 fix from Thomas Gleixner:
 "A single fix for a APIC regression introduced in 4.0 which went
  undetected until now.

  I screwed up the x2apic cleanup in a subtle way.  The screwup is only
  visible on systems which have x2apic preenabled in the BIOS and need
  to disable it during boot"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/apic: Fix fallout from x2apic cleanup

can: pcan_usb: don't provide CAN FD bittimings by non-FD adapters

The CAN FD data bittiming constants are provided via netlink only when there
are valid CAN FD constants available in priv->data_bittiming_const.

Due to the indirection of pointer assignments in the peak_usb driver the
priv->data_bittiming_const never becomes NULL - not even for non-FD adapters.

The data_bittiming_const points to zero'ed data which leads to this result
when running 'ip -details link show can0':

35: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can state STOPPED restart-ms 0
  pcan_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
  : dtseg1 0..0 dtseg2 0..0 dsjw 1..0 dbrp 0..0 dbrp-inc 0  <== BROKEN!
  clock 8000000

This patch changes the struct peak_usb_adapter::bittiming_const and struct
peak_usb_adapter::data_bittiming_const to pointers to fix the assignemnt
problems.

Cc: linux-stable <stable@vger.kernel.org> # >= 4.0
Reported-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

ALSA: hda - Fix path power activation

The widget power-saving code tries to turn up/down the power of each
widget in the I/O paths that are modified at each jack plug/unplug.
The recent report revealed that the power activation leaves some
widgets unpowered after plugging.  This is because
snd_hda_activate_path() turns on path->active flag at the end of the
function while the path power management is done before that.  Then
it's regarded as if nothing is active, and the driver turns off the
power.

The fix is simply to set the flag at the beginning of the function,
before trying to power up.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102521
Cc: <stable@vger.kernel.org> [v4.1+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - Check all inputs for is_active_nid_for_any()

The is_active_nid_for_any() function in the generic parser is supposed
to check all connections from/to the given widget, but the current
code checks only the first input connection (index = 0).

This patch corrects the code to check all inputs by passing -1 to
index argument.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102521
Cc: <stable@vger.kernel.org> [v4.1+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

nfsd: Add Jeff Layton as co-maintainer

Jeff has been doing a lot of development (including much of the
state-locking rewrite just as one example) plus lots of review and other
miscellaneous nfsd work, so let's acknowledge the status quo.

I'll continue to be the one to send regular pull requests but Jeff will
should be available to cover there occasionally too.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

net: Fix RCU splat in af_key

Hit the following splat testing VRF change for ipsec:

[  113.475692] ===============================
[  113.476194] [ INFO: suspicious RCU usage. ]
[  113.476667] 4.2.0-rc6-1+deb7u2+clUNRELEASED #3.2.65-1+deb7u2+clUNRELEASED Not tainted
[  113.477545] -------------------------------
[  113.478013] /work/monster-14/dsa/kernel.git/include/linux/rcupdate.h:568 Illegal context switch in RCU read-side critical section!
[  113.479288]
[  113.479288] other info that might help us debug this:
[  113.479288]
[  113.480207]
[  113.480207] rcu_scheduler_active = 1, debug_locks = 1
[  113.480931] 2 locks held by setkey/6829:
[  113.481371]  #0:  (&net->xfrm.xfrm_cfg_mutex){+.+.+.}, at: [<ffffffff814e9887>] pfkey_sendmsg+0xfb/0x213
[  113.482509]  #1:  (rcu_read_lock){......}, at: [<ffffffff814e767f>] rcu_read_lock+0x0/0x6e
[  113.483509]
[  113.483509] stack backtrace:
[  113.484041] CPU: 0 PID: 6829 Comm: setkey Not tainted 4.2.0-rc6-1+deb7u2+clUNRELEASED #3.2.65-1+deb7u2+clUNRELEASED
[  113.485422] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
[  113.486845]  0000000000000001 ffff88001d4c7a98 ffffffff81518af2 ffffffff81086962
[  113.487732]  ffff88001d538480 ffff88001d4c7ac8 ffffffff8107ae75 ffffffff8180a154
[  113.488628]  0000000000000b30 0000000000000000 00000000000000d0 ffff88001d4c7ad8
[  113.489525] Call Trace:
[  113.489813]  [<ffffffff81518af2>] dump_stack+0x4c/0x65
[  113.490389]  [<ffffffff81086962>] ? console_unlock+0x3d6/0x405
[  113.491039]  [<ffffffff8107ae75>] lockdep_rcu_suspicious+0xfa/0x103
[  113.491735]  [<ffffffff81064032>] rcu_preempt_sleep_check+0x45/0x47
[  113.492442]  [<ffffffff8106404d>] ___might_sleep+0x19/0x1c8
[  113.493077]  [<ffffffff81064268>] __might_sleep+0x6c/0x82
[  113.493681]  [<ffffffff81133190>] cache_alloc_debugcheck_before.isra.50+0x1d/0x24
[  113.494508]  [<ffffffff81134876>] kmem_cache_alloc+0x31/0x18f
[  113.495149]  [<ffffffff814012b5>] skb_clone+0x64/0x80
[  113.495712]  [<ffffffff814e6f71>] pfkey_broadcast_one+0x3d/0xff
[  113.496380]  [<ffffffff814e7b84>] pfkey_broadcast+0xb5/0x11e
[  113.497024]  [<ffffffff814e82d1>] pfkey_register+0x191/0x1b1
[  113.497653]  [<ffffffff814e9770>] pfkey_process+0x162/0x17e
[  113.498274]  [<ffffffff814e9895>] pfkey_sendmsg+0x109/0x213

In pfkey_sendmsg the net mutex is taken and then pfkey_broadcast takes
the RCU lock.

Since pfkey_broadcast takes the RCU lock the allocation argument is
pointless since GFP_ATOMIC must be used between the rcu_read_{,un}lock.
The one call outside of rcu can be done with GFP_KERNEL.

Fixes: 7f6b9dbd5afbd ("af_key: locking change")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ALSA: hda: fix possible NULL dereference

After a for-loop was replaced by list_for_each_entry, see
Commit bbbc7e8502c9 ("ALSA: hda - Allocate hda_pcm objects dynamically"),
Commit 751e2216899c ("ALSA: hda: fix possible null dereference"),
a possible NULL pointer dereference has been introduced; this patch adds
the NULL check on pcm->pcm, while leaving a potentially superfluous
check on pcm itself untouched.

Signed-off-by: Markus Osterhoff <linux-kernel@k-raum.org>
Cc: <stable@vger.kernel.org> #v4.1+
Signed-off-by: Takashi Iwai <tiwai@suse.de>

net: bcmgenet: fix uncleaned dma flags

Clean the dma flags of multiq ring buffer int the interface stop
process. This patch fixes that the genet is not running while the
interface is re-enabled.

$ ifup eth0 - running after booting
$ ifdown eth0
$ ifup eth0 - not running and occur tx_timeout

The bcmgenet_dma_disable() in bcmgenet_open() do clean ring16 dma flag
only. If the genet has multiq, the dma register is not cleaned. and
bcmgenet_init_dma() is not done correctly. in case
GENET_V2(tx_queues=4), tdma_ctrl has 0x1e after running
bcmgenet_dma_disable().

Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: bcmgenet: Avoid sleeping in bcmgenet_timeout

bcmgenet_timeout() executes in atomic context, yet we will invoke
napi_disable() which does sleep. Looking back at the changes, disabling
TX napi and re-enabling it is completely useless, since we reclaim all
TX buffers and re-enable interrupts, and wake up the TX queues.

Fixes: 13ea657806cf ("net: bcmgenet: improve TX timeout")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Linux 4.2-rc8

Merge tag 'scsi-fixes' of git://git./linux/kernel/git/jejb/scsi

Pull SCSI fixes from James Bottomley:
 "A couple of major (hang and deadlock) fixes with fortunately fairly
  rare triggering conditions.  The PM oops is only really triggered by
  people using enclosure services (rare) and the fnic driver is mostly
  used in enterprise environments"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  SCSI: Fix NULL pointer dereference in runtime PM
  fnic: Use the local variable instead of I/O flag to acquire io_req_lock in fnic_queuecommand() to avoid deadloack

netlink: mmap: fix tx type check

I can't send netlink message via mmaped netlink socket since

    commit: a8866ff6a5bce7d0ec465a63bc482a85c09b0d39
    netlink: make the check for "send from tx_ring" deterministic

msg->msg_iter.type is set to WRITE (1) at

    SYSCALL_DEFINE6(sendto, ...
        import_single_range(WRITE, ...
            iov_iter_init(1, WRITE, ...

call path, so that we need to check the type by iter_is_iovec()
to accept the WRITE.

Signed-off-by: Ken-ichirou MATSUZAWA <chamas@h4.dion.ne.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'upstream' of git://git.linux-mips.org/ralf/upstream-linus

Pull MIPS bug fixes from Ralf Baechle:
 "Two more fixes for 4.2.

  One fixes a build issue with the LLVM assembler - LLVM assembler macro
  names are case sensitive, GNU as macro names are insensitive; the
  other corrects a license string (GPL v2, not GPLv2) such that the
  module loader will recognice the license correctly"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  FIRMWARE: bcm47xx_nvram: Fix module license.
  MIPS: Fix LLVM build issue.

Merge branch 'for-linus' of git://git./linux/kernel/git/viro/vfs

Pull 9p regression fix from Al Viro:
 "Fix for breakage introduced when switching p9_client_{read,write}() to
  struct iov_iter * (went into 4.1)"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  9p: ensure err is initialized to 0 in p9_client_read/write

9p: ensure err is initialized to 0 in p9_client_read/write

Some use of those functions were providing unitialized values to those
functions. Notably, when reading 0 bytes from an empty file on a 9P
filesystem, the return code of read() was not 0.

Tested with this simple program:

    #include <assert.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>
    #include <unistd.h>

    int main(int argc, const char **argv)
    {
        assert(argc == 2);
        char buffer[256];
        int fd = open(argv[1], O_RDONLY|O_NOCTTY);
        assert(fd >= 0);
        assert(read(fd, buffer, 0) == 0);
        return 0;
    }

Cc: stable@vger.kernel.org # v4.1
Signed-off-by: Vincent Bernat <vincent@bernat.im>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm

Pull ARM fixes from Russell King:
 "Another couple of small ARM fixes.

  A patch from Masahiro Yamada who noticed that "make -jN all zImage"
  would end up generating bad images where N > 1, and a patch from
  Nicolas to fix the Marvell CPU user access optimisation code when page
  faults are disabled"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 8418/1: add boot image dependencies to not generate invalid images
  ARM: 8414/1: __copy_to_user_memcpy: fix mmap semaphore usage

Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 fixes from Ingo Molnar:
 "Various low level fixes: fix more fallout from the FPU rework and the
  asm entry code rework, plus an MSI rework fix, and an idle-tracing fix"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/fpu/math-emu: Fix crash in fork()
  x86/fpu/math-emu: Fix math-emu boot crash
  x86/idle: Restore trace_cpu_idle to mwait_idle() calls
  x86/irq: Build correct vector mapping for multiple MSI interrupts
  Revert "sched/x86_64: Don't save flags on context switch"

Merge branch 'perf-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull perf fixes from Ingo Molnar:
 "Tooling fixes: a 'perf record' deadlock fix plus debuggability fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf top: Show backtrace when handling a SIGSEGV on --stdio mode
  perf tools: Fix buildid processing
  perf tools: Make fork event processing more resilient
  perf tools: Avoid deadlock when map_groups are broken

x86/apic: Fix fallout from x2apic cleanup

In the recent x2apic cleanup I got two things really wrong:
1) The safety check in __disable_x2apic which allows the function to
   be called unconditionally is backwards. The check is there to
   prevent access to the apic MSR in case that the machine has no
   apic. Though right now it returns if the machine has an apic and
   therefor the disabling of x2apic is never invoked.

2) x2apic_disable() sets x2apic_mode to 0 after registering the local
   apic. That's wrong, because register_lapic_address() checks x2apic
   mode and therefor takes the wrong code path.

This results in boot failures on machines with x2apic preenabled by
BIOS and can also lead to an fatal MSR access on machines without
apic.

The solutions are simple:
1) Correct the sanity check for apic availability
2) Clear x2apic_mode _before_ calling register_lapic_address()

Fixes: 659006bf3ae3 'x86/x2apic: Split enable and setup function'
Reported-and-tested-by: Javier Monteagudo <javiermon@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1224764
Cc: stable@vger.kernel.org # 4.0+
Cc: Laura Abbott <labbott@redhat.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Borislav Petkov <bp@alien8.de>

Merge branch 'irq-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull irq fixes from Thomas Gleixner:
 "A series of small fixlets for a regression visible on OMAP devices
  caused by the conversion of the OMAP interrupt chips to hierarchical
  interrupt domains.  Mostly one liners on the driver side plus a small
  helper function in the core to avoid open coded mess in the drivers"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip/crossbar: Restore set_wake functionality
  irqchip/crossbar: Restore the mask on suspend behaviour
  ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanism
  irqchip/crossbar: Restore the irq_set_type() mechanism
  genirq: Introduce irq_chip_set_type_parent() helper
  genirq: Don't return ENOSYS in irq_chip_retrigger_hierarchy

Merge branch 'timers-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull timer fixes from Thomas Gleixner:
 "Two minimalistic fixes for 4.2 regressions:

   - Eric fixed a thinko in the timer_list base switching code caused by
     the overhaul of the timer wheel.  It can cause a cpu to see the
     wrong base for a timer while we move the timer around.

   - Guenter fixed a regression for IMX if booted w/o device tree, where
     the timer interrupt is not initialized and therefor the machine
     fails to boot"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  clocksource/imx: Fix boot with non-DT systems
  timer: Write timer->flags atomically

x86/fpu/math-emu: Fix crash in fork()

During later stages of math-emu bootup the following crash triggers:

 math_emulate: 0060:c100d0a8
 Kernel panic - not syncing: Math emulation needed in kernel
 CPU: 0 PID: 1511 Comm: login Not tainted 4.2.0-rc7+ #1012
 [...]
 Call Trace:
  [<c181d50d>] dump_stack+0x41/0x52
  [<c181c918>] panic+0x77/0x189
  [<c1003530>] ? math_error+0x140/0x140
  [<c164c2d7>] math_emulate+0xba7/0xbd0
  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
  [<c1109c3c>] ? __alloc_pages_nodemask+0x12c/0x870
  [<c136ac20>] ? proc_clear_tty+0x40/0x70
  [<c136ac6e>] ? session_clear_tty+0x1e/0x30
  [<c1003530>] ? math_error+0x140/0x140
  [<c1003575>] do_device_not_available+0x45/0x70
  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
  [<c18258e6>] error_code+0x5a/0x60
  [<c1003530>] ? math_error+0x140/0x140
  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
  [<c100c205>] arch_dup_task_struct+0x25/0x30
  [<c1048cea>] copy_process.part.51+0xea/0x1480
  [<c115a8e5>] ? dput+0x175/0x200
  [<c136af70>] ? no_tty+0x30/0x30
  [<c1157242>] ? do_vfs_ioctl+0x322/0x540
  [<c104a21a>] _do_fork+0xca/0x340
  [<c1057b06>] ? SyS_rt_sigaction+0x66/0x90
  [<c104a557>] SyS_clone+0x27/0x30
  [<c1824a80>] sysenter_do_call+0x12/0x12

The reason is the incorrect assumption in fpu_copy(), that FNSAVE
can be executed from math-emu kernels as well.

Don't try to copy the registers, the soft state will be copied
by fork anyway, so the child task inherits the parent task's
soft math state.

With this fix applied math-emu kernels boot up fine on modern
hardware and the 'no387 nofxsr' boot options.

Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Bobby Powers <bobbypowers@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

x86/fpu/math-emu: Fix math-emu boot crash

On a math-emu bootup the following crash occurs:

Initializing CPU#0
------------[ cut here ]------------
kernel BUG at arch/x86/kernel/traps.c:779!
invalid opcode: 0000 [#1] SMP
[...]
EIP is at do_device_not_available+0xe/0x70
[...]
Call Trace:
 [<c18238e6>] error_code+0x5a/0x60
 [<c1002bd0>] ? math_error+0x140/0x140
 [<c100bbd9>] ? fpu__init_cpu+0x59/0xa0
 [<c1012322>] cpu_init+0x202/0x330
 [<c104509f>] ? __native_set_fixmap+0x1f/0x30
 [<c1b56ab0>] trap_init+0x305/0x346
 [<c1b548af>] start_kernel+0x1a5/0x35d
 [<c1b542b4>] i386_start_kernel+0x82/0x86

The reason is that in the following commit:

  b1276c48e91b ("x86/fpu: Initialize fpregs in fpu__init_cpu_generic()")

I failed to consider math-emu's limitation that it cannot execute the
FNINIT instruction in kernel mode.

The long term fix might be to allow math-emu to execute (certain) kernel
mode FPU instructions, but for now apply the safe (albeit somewhat ugly)
fix: initialize the emulation state explicitly without trapping out to
the FPU emulator.

Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Add hch to .get_maintainer.ignore

While the idea behind get_maintainer seems highly useful it's
unfortunately way to trigger happy to grab people that once had a few
commits to files.  For someone like me who does a lot of tree-wide API
work that leads to an incredible amount of Cc spam.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: make page pfmemalloc check more robust

Commit c48a11c7ad26 ("netvm: propagate page->pfmemalloc to skb") added
checks for page->pfmemalloc to __skb_fill_page_desc():

        if (page->pfmemalloc && !page->mapping)
                skb->pfmemalloc = true;

It assumes page->mapping == NULL implies that page->pfmemalloc can be
trusted.  However, __delete_from_page_cache() can set set page->mapping
to NULL and leave page->index value alone.  Due to being in union, a
non-zero page->index will be interpreted as true page->pfmemalloc.

So the assumption is invalid if the networking code can see such a page.
And it seems it can.  We have encountered this with a NFS over loopback
setup when such a page is attached to a new skbuf.  There is no copying
going on in this case so the page confuses __skb_fill_page_desc which
interprets the index as pfmemalloc flag and the network stack drops
packets that have been allocated using the reserves unless they are to
be queued on sockets handling the swapping which is the case here and
that leads to hangs when the nfs client waits for a response from the
server which has been dropped and thus never arrive.

The struct page is already heavily packed so rather than finding another
hole to put it in, let's do a trick instead.  We can reuse the index
again but define it to an impossible value (-1UL).  This is the page
index so it should never see the value that large.  Replace all direct
users of page->pfmemalloc by page_is_pfmemalloc which will hide this
nastiness from unspoiled eyes.

The information will get lost if somebody wants to use page->index
obviously but that was the case before and the original code expected
that the information should be persisted somewhere else if that is
really needed (e.g.  what SLAB and SLUB do).

[akpm@linux-foundation.org: fix blooper in slub]
Fixes: c48a11c7ad26 ("netvm: propagate page->pfmemalloc to skb")
Signed-off-by: Michal Hocko <mhocko@suse.com>
Debugged-by: Vlastimil Babka <vbabka@suse.com>
Debugged-by: Jiri Bohac <jbohac@suse.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: <stable@vger.kernel.org> [3.6+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'pci-v4.2-fixes-2' of git://git./linux/kernel/git/helgaas/pci

Pull PCI fixes from Bjorn Helgaas:
 "These are fixes for ASPM-related NULL pointer dereference crashes on
  Sparc and PowerPC and 64-bit PCI address-related HPMC crashes on
  PA-RISC.  These are both caused by things we merged in the v4.2 merge
  window.  Details:

  Resource management
    - Don't use 64-bit bus addresses on PA-RISC

  Miscellaneous
    - Tolerate hierarchies with no Root Port"

* tag 'pci-v4.2-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI: Don't use 64-bit bus addresses on PA-RISC
  PCI: Tolerate hierarchies with no Root Port

Merge tag 'media/v4.2-3' of git://git./linux/kernel/git/mchehab/linux-media

Pull media fixes from Mauro Carvalho Chehab:

 - a regression fix at the videobuf2 core driver

 - fix error handling at mantis probing code

 - revert the IR encode patches, as the API is not mature enough.
   So, better to postpone the changes to a latter Kernel

 - fix Kconfig breakages on some randconfig scenarios.

* tag 'media/v4.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] mantis: Fix error handling in mantis_dma_init()
  Revert "[media] rc: rc-ir-raw: Add scancode encoder callback"
  Revert "[media] rc: rc-ir-raw: Add Manchester encoder (phase encoder) helper"
  Revert "[media] rc: ir-rc5-decoder: Add encode capability"
  Revert "[media] rc: ir-rc6-decoder: Add encode capability"
  Revert "[media] rc: rc-core: Add support for encode_wakeup drivers"
  Revert "[media] rc: rc-loopback: Add loopback of filter scancodes"
  Revert "[media] rc: nuvoton-cir: Add support for writing wakeup samples via sysfs filter callback"
  [media] vb2: Fix compilation breakage when !CONFIG_BUG
  [media] vb2: Only requeue buffers immediately once streaming is started
  [media] media/pci/cobalt: fix Kconfig and build when SND is not enabled
  [media] media/dvb: fix ts2020.c Kconfig and build

Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input

Pull input layer fix from Dmitry Torokhov:
 "A small fixup to gpio_keys_polled driver"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: gpio_keys_polled - request GPIO pin as input.

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "A bunch of i915 fixes, one revert a VBT fix that was a bit premature,
  and some braswell feature removal that the hw actually didn't support.

  One radeon race fix at boot, and one hlcdc build fix, one fix from
  Russell that fixes build as well with new audio features.

  This is hopefully all I have until -next"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon: fix hotplug race at startup
  drm/edid: add function to help find SADs
  drm/i915: Avoid TP3 on CHV
  drm/i915: remove HBR2 from chv supported list
  Revert "drm/i915: Add eDP intermediate frequencies for CHV"
  Revert "drm/i915: Allow parsing of variable size child device entries from VBT"
  drm/atmel-hlcdc: Compile suspend/resume for PM_SLEEP only
  drm/i915: Flag the execlists context object as dirty after every use

drm/radeon: fix hotplug race at startup

We apparantly get a hotplug irq before we've initialised
modesetting,

[drm] Loading R100 Microcode
BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [<c125f56f>] __mutex_lock_slowpath+0x23/0x91
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys
CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf67402 #111
Hardware name: MicroLink                               /D850MV                         , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003
Workqueue: events radeon_hotplug_work_func [radeon]
task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000
EIP: 0060:[<c125f56f>] EFLAGS: 00010282 CPU: 0
EIP is at __mutex_lock_slowpath+0x23/0x91
EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe
ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0
Stack:
 f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca
 f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0
 c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940
Call Trace:
 [<c103c4c1>] ? dequeue_task_fair+0xa4/0xb7
 [<c125f162>] ? mutex_lock+0x9/0xa
 [<f8b0faca>] ? radeon_hotplug_work_func+0x17/0x57 [radeon]
 [<c1034741>] ? process_one_work+0xfc/0x194
 [<c1034b58>] ? worker_thread+0x18d/0x218
 [<c10349cb>] ? rescuer_thread+0x1d5/0x1d5
 [<c103742a>] ? kthread+0x7b/0x80
 [<c12601c0>] ? ret_from_kernel_thread+0x20/0x30
 [<c10373af>] ? init_completion+0x18/0x18
Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63

Reported-and-Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Dave Airlie <airlied@redhat.com>

ALSA: hda - Shutdown CX20722 on reboot/free to avoid spurious noises

On shutdown/reboot of CX20722, first shut down all EAPDs, then
shut down the afg node to D3.

Failure to do so can lead to spurious noises from the internal speaker
directly after reboot (and before the codec is reinitialized again, i e
in BIOS setup or GRUB menus).

BugLink: https://bugs.launchpad.net/bugs/1487345
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb: Add native DSD support for Gustard DAC-X20U

This patch adds native DSD support for the Gustard DAC-X20U.

Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Merge tag 'drm-intel-fixes-2015-08-20' of git://anongit.freedesktop.org/drm-intel into drm-fixes

Revert of a VBT parsing commit that should've been queued for drm-next,
not v4.2. The revert unbreaks Braswell among other things.

Also on Braswell removal of DP HBR2/TP3 and intermediate eDP frequency
support. The code was optimistically added based on incorrect
documentation; the platform does not support them. These are cc: stable.

Finally a gpu state fix from Chris, also cc: stable.

* tag 'drm-intel-fixes-2015-08-20' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Avoid TP3 on CHV
  drm/i915: remove HBR2 from chv supported list
  Revert "drm/i915: Add eDP intermediate frequencies for CHV"
  Revert "drm/i915: Allow parsing of variable size child device entries from VBT"
  drm/i915: Flag the execlists context object as dirty after every use

Merge tag 'pm+acpi-4.2-rc8' of git://git./linux/kernel/git/rafael/linux-pm

Pull power management and ACPI fixes from Rafael Wysocki:
 "These fix a recent regression in the ACPI backlight code and a memory
  leak in the Exynos cpufreq driver.

  Specifics:

   - Fix a recently introduced issue in the ACPI backlight code which
     causes lockdep to complain about a circular lock dependency during
     initialization (Hans de Goede).

   - Fix a possible memory during initialization in the Exynos cpufreq
     driver (Shailendra Verma)"

* tag 'pm+acpi-4.2-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  cpufreq: exynos: Fix for memory leak in case SoC name does not match
  ACPI / video: Fix circular lock dependency issue in the video-detect code

Merge branches 'acpi-video' and 'cpufreq-fixes'

* acpi-video:
  ACPI / video: Fix circular lock dependency issue in the video-detect code

* cpufreq-fixes:
  cpufreq: exynos: Fix for memory leak in case SoC name does not match

PCI: Don't use 64-bit bus addresses on PA-RISC

Meelis and Helge reported that 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
caused HPMCs on A500 and hangs on rp5470.

PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so
prior to 3a9ad0b4fdcd, we always used 32-bit PCI addresses.  After
3a9ad0b4fdcd, we do use 64-bit PCI addresses in 64-bit kernels, and
apparently there's some PA-RISC problem related to them.

Fixes: 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t")
Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.ee
Reported-by: Meelis Roos <mroos@linux.ee>
Reported-by: Helge Deller <deller@gmx.de>
Tested-by: Helge Deller <deller@gmx.de>
Based-on-idea-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
CC: stable@vger.kernel.org # v3.19+

x86/idle: Restore trace_cpu_idle to mwait_idle() calls

Commit b253149b843f ("sched/idle/x86: Restore mwait_idle() to fix boot
hangs, to improve power savings and to improve performance") restores
mwait_idle(), but the trace_cpu_idle related calls are missing. This
causes powertop on my old desktop powered by Intel Core2 E6550 to
report zero wakeups and zero events.

Add them back to restore the proper behaviour.

Fixes: b253149b843f ("sched/idle/x86: Restore mwait_idle() to ...")
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Cc: <len.brown@intel.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1440046479-4262-1-git-send-email-jszhang@marvell.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Merge git://git./linux/kernel/git/davem/net

Pull networking fixes from David Miller:

 1) Out of bounds array access in 802.11 minstrel code, from Adrien
    Schildknecht.

 2) Don't use skb_get() in IGMP/MLD code paths, as this makes
    pskb_may_pull() BUG.  From Linus Luessing.

 3) Fix off by one in ipv4 route dumping code, from Andy Whitcroft.

 4) Fix deadlock in reqsk_queue_unlink(), from Eric Dumazet.

 5) Fix ppp device deregistration wrt.  netns deletion, from Guillaume
    Nault.

 6) Fix deadlock when creating per-cpu ipv6 routes, from Martin KaFai
    Lau.

 7) Fix memory leak in batman-adv code, from Sven Eckelmann.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  batman-adv: Fix memory leak on tt add with invalid vlan
  net: phy: fix semicolon.cocci warnings
  net: qmi_wwan: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module
  be2net: avoid vxlan offloading on multichannel configs
  ipv6: Fix a potential deadlock when creating pcpu rt
  ipv6: Add rt6_make_pcpu_route()
  ipv6: Remove un-used argument from ip6_dst_alloc()
  net: phy: workaround for buggy cable detection by LAN8700 after cable plugging
  net: ethernet: micrel: fix an error code
  ppp: fix device unregistration upon netns deletion
  net: phy: fix PHY_RUNNING in phy_state_machine
  Revert "net: limit tcp/udp rmem/wmem to SOCK_{RCV,SND}BUF_MIN"
  inet: fix potential deadlock in reqsk_queue_unlink()
  gianfar: Restore link state settings after MAC reset
  ipv4: off-by-one in continuation handling in /proc/net/route
  net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code
  mac80211: fix invalid read in minstrel_sort_best_tp_rates()

Merge tag 'for-linus-4.2-rc7-tag' of git://git./linux/kernel/git/xen/tip

Pull xen build fix from David Vrabel:
 "Fix i386 build with an (uncommon) configuration"

* tag 'for-linus-4.2-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  x86/xen: make CONFIG_XEN depend on CONFIG_X86_LOCAL_APIC

Merge tag 'sound-4.2' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Here are a small collecton of sound fix patches.

  The most significant one is the disablement of newly introduced
  topology API.  Its ABI couldn't be stabilized enough, so we decided to
  delay for 4.3 in the end.  Other than that, all oneliner fixes: a
  USB-audio runtime PM fix and a couple of HD-audio quirks"

* tag 'sound-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Add dock support for Thinkpad W541 (17aa:2211)
  ALSA: usb-audio: Fix runtime PM unbalance
  ASoC: topology: Disable use from userspace
  ASoC: topology: Add Kconfig option for topology
  ALSA: hda - Fix the white noise on Dell laptop

Input: gpio_keys_polled - request GPIO pin as input.

GPIOF_IN flag was lost in:
Commit 633a21d80b4a("input: gpio_keys_polled: Add support for GPIO
descriptors").

Without this flag, legacy code path (for non-descriptor GPIO declarations)
would configure GPIO as output (0 meaning GPIOF_DIR_OUT | GPIOF_INIT_LOW).

Cc: stable@vger.kernel.org
Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge git://git./linux/kernel/git/nab/target-pending

Pull SCSI target fixes from Nicholas Bellinger:
 "This contains a v4.2-rc specific RCU module unload regression bug-fix,
  a long-standing iscsi-target bug-fix for duplicate target_xfer_tags
  during NOP processing from Alexei, and two more small REPORT_LUNs
  emulation related patches to make Solaris FC host LUN scanning happy
  from Roland.

  There is also one patch not included that allows target-core to limit
  the number of fabric driver SGLs per I/O request using residuals, that
  is currently required as a work-around for FC hosts which don't honor
  EVPD block-limits settings.  At this point, it will most likely become
  for-next material"

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  target: Fix handling of small allocation lengths in REPORT LUNS
  target: REPORT LUNS should return LUN 0 even for dynamic ACLs
  target/iscsi: Fix double free of a TUR followed by a solicited NOPOUT
  target: Perform RCU callback barrier before backend/fabric unload

Merge branch 'fixes' of git://git./linux/kernel/git/evalenti/linux-soc-thermal

Pull thermal fixes from Eduardo Valentin:
 "Last minute fixes on the thermal-soc tree.  There is a fix of a long
  lasting bug in cpu cooling device, thanks for RMK for being pushing
  this"

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal:
  thermal/cpu_cooling: update policy limits if clipped_freq < policy->max
  thermal/cpu_cooling: rename max_freq as clipped_freq in notifier
  thermal/cpu_cooling: rename cpufreq_val as clipped_freq
  thermal/cpu_cooling: convert 'switch' block to 'if' block in notifier
  thermal/cpu_cooling: quit early after updating policy
  thermal/cpu_cooling: No need to initialize max_freq to 0
  thermal: cpu_cooling: fix lockdep problems in cpu_cooling
  thermal: power_allocator: do not use devm* interfaces

clocksource/imx: Fix boot with non-DT systems

Commit 6dd747825b20 ("ARM: imx: move timer resources into a structure")
moved initialization parameters into a data structure, but neglected to set
the irq field in that data structure for non-DT boots. This causes the system
to hang if a non-DT boot is attempted.

Fixes: 6dd747825b20 ("ARM: imx: move timer resources into a structure")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: http://lkml.kernel.org/r/1440066441-13930-1-git-send-email-linux@roeck-us.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86/xen: make CONFIG_XEN depend on CONFIG_X86_LOCAL_APIC

Since commit feb44f1f7a4ac299d1ab1c3606860e70b9b89d69 (x86/xen:
Provide a "Xen PV" APIC driver to support >255 VCPUs) Xen guests need
a full APIC driver and thus should depend on X86_LOCAL_APIC.

This fixes an i386 build failure with !SMP && !CONFIG_X86_UP_APIC by
disabling Xen support in this configuration.

Users needing Xen support in a non-SMP i386 kernel will need to enable
CONFIG_X86_UP_APIC.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: <stable@vger.kernel.org>

Merge tag 'perf-urgent-for-mingo' of git://git./linux/kernel/git/acme/linux into perf/urgent

Pull perf/urgent fixes from Arnaldo Carvalho de Melo:

  - Fix buildid processing done at the end of a 'perf record' session, a
    problem that happened in workloads involving lots of small short-lived
    processes.  That code was not asking the perf_session layer to order
    the events.

    Make the code more robust to handle some of the problems with such
    out-of-order events and fix 'perf record' to ask for ordered events
    on systems where we have perf_event_attr.sample_id_all.  (Adrian Hunter)

  - Show backtrace when handling a SIGSEGV in 'perf top --stdio' (Arnaldo Carvalho de Melo)

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

drm/edid: add function to help find SADs

Add a function to find the start of the SADs in the ELD.  This
complements the helper to retrieve the SAD count.

[airlied: this fixes a build problem with the alsa eld helper
which required this].

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm-atmel-hlcdc-fixes' of https://github.com/bbrezillon/linux-at91 into drm-fixes

single atmel hlcdc fix.

* 'drm-atmel-hlcdc-fixes' of https://github.com/bbrezillon/linux-at91:
  drm/atmel-hlcdc: Compile suspend/resume for PM_SLEEP only

irqchip/crossbar: Restore set_wake functionality

The TI crossbar irqchip doesn't provides any facility to configure the
wakeup sources, but the conversion to hierarchical irqdomains set the
irq_set_wake callback to irq_chip_set_wake_parent. The parent chip
(OMAP wakeupgen) has no irq_set_wake function either so the call will
fail with -ENOSYS. As a result the irq_set_wake() call in the resume
path will trigger an 'Unbalanced wake disable' warning.

Before the conversion the GIC irqchip was the top level irqchip and
correctly flagged with IRQCHIP_SKIP_SET_WAKE.

Restore the correct behaviour by removing the irq_set_type callback
from the crossbar irqchip and set the IRQCHIP_SKIP_SET_WAKE flag which
lets the irq_set_irq_wake() call from the driver succeed.

[ tglx: Massaged changelog ]

Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1439554830-19502-7-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

irqchip/crossbar: Restore the mask on suspend behaviour

The ARM GIC requires that all interrupts which are not used as a
wakeup source have to be masked during suspend.

The conversion of the crossbar irqchip to hierarchical irq domains
failed to mark the crossbar irqchip with the IRQCHIP_MASK_ON_SUSPEND
flag and therefor broke the suspend requirement of the GIC.

Before the conversion the flags were visible because the GIC was the
top level irqchip. After the conversion the crossbar irqchip is the
top level irq chip whose flags are evaluated in suspend_device_irq().
As the flag is not set the masking of the non-wakeup irqs is not
invoked which breaks suspend.

Add the IRQCHIP_MASK_ON_SUSPEND flag to the crossbar irqchip, so the
GIC interrupts get masked properly.

[ tglx: Massaged changelog ]

Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1439554830-19502-6-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanism

The conversion of the wakeupgen irqchip to hierarchical irq domains
failed to provide a mechanism to properly set the trigger type of an
interrupt.

The wakeupgen irq chip itself has no mechanism and therefor no
irq_set_type() callback. The code before the conversion relayed the
trigger configuration directly to the underlying GIC.

Restore the correct behaviour by setting the wakeupgen irq_set_type
callback to irq_chip_set_type_parent(). This propagates the
set_trigger() call to the underlying GIC irqchip.

[ tglx: Massaged changelog ]

Fixes: 7136d457f365 ('ARM: omap: convert wakeupgen to stacked domains')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1439554830-19502-5-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

irqchip/crossbar: Restore the irq_set_type() mechanism

The conversion of the crossbar irqchip to hierarchical irq domains
failed to provide a mechanism to properly set the trigger type of an
interrupt.

The crossbar irq chip itself has no mechanism and therefor no
irq_set_type() callback. The code before the conversion relayed the
trigger configuration directly to the underlying GIC.

Restore the correct behaviour by setting the crossbar irq_set_type
callback to irq_chip_set_type_parent(). This propagates the
set_trigger() call to the underlying GIC irqchip.

[ tglx: Massaged changelog ]

Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1439554830-19502-4-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

genirq: Introduce irq_chip_set_type_parent() helper

This helper is required for irq chips which do not implement a
irq_set_type callback and need to call down the irq domain hierarchy
for the actual trigger type change.

This helper is required to fix further wreckage caused by the
conversion of TI OMAP to hierarchical irq domains and therefor tagged
for stable.

[ tglx: Massaged changelog ]

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: <marc.zyngier@arm.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1439554830-19502-3-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

genirq: Don't return ENOSYS in irq_chip_retrigger_hierarchy

irq_chip_retrigger_hierarchy() returns -ENOSYS if it was not able to
find at least one .irq_retrigger() callback implemented in the IRQ
domain hierarchy.

That's wrong, because check_irq_resend() expects a 0 return value from
the callback in case that the hardware assisted resend was not
possible. If the return value is non zero the core code assumes
hardware resend success and the software resend is not invoked.

This results in lost interrupts on platforms where none of the parent
irq chips in the hierarchy implements the retrigger callback.

This is observable on TI OMAP, where the hierarchy is:

 ARM GIC <- OMAP wakeupgen <- TI Crossbar

Return 0 instead so the software resend mechanism gets invoked.

[ tglx: Massaged changelog ]

Fixes: 85f08c17de26 ('genirq: Introduce helper functions...')
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: <linux@arm.linux.org.uk>
Cc: <nsekhar@ti.com>
Cc: <jason@lakedaemon.net>
Cc: <balbi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <tony@atomide.com>
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1439554830-19502-2-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

PCI: Tolerate hierarchies with no Root Port

We should not assume any particular hardware topology.  Commit d0751b98dfa3
("PCI: Add dev->has_secondary_link to track downstream PCIe links") relied
on the assumption that every PCIe hierarchy is rooted at a Root Port.  But
we can't rely on any assumption about what hardware we will find; we just
have to deal with the world as it is.

On some platforms, PCIe devices (endpoints, switch upstream ports, etc.)
appear directly on the root bus, and there is no Root Port in the PCI bus
hierarchy.  For example, Meelis observed these top-level devices on a
Sparc V245:

  0000:02:00.0 PCI bridge to [bus 03-0d]    Switch Upstream Port
  0001:02:00.0 PCI bridge to [bus 03]       PCIe to PCI/PCI-X Bridge

These devices *look* like they have links going upstream, but there really
are no upstream devices.

In set_pcie_port_type(), we used the parent device to figure out which side
of a switch port has a link, so if the parent device did not exist, we
dereferenced a NULL parent pointer.

Check whether the parent device exists before dereferencing it.

Meelis observed this oops on Sparc V245 and T2000.  Ben Herrenschmidt says
this is also possible on IBM PowerVM guests on PowerPC.

[bhelgaas: changelog, comment]
Link: http://lkml.kernel.org/r/alpine.LRH.2.20.1508122118210.18637@math.ut.ee
Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: David S. Miller <davem@davemloft.net>

perf top: Show backtrace when handling a SIGSEGV on --stdio mode

It was just freezing instead of informing about the SEGV, fix it and
also print a backtrace, just like in the TUI mode and in 'perf trace'.

Tested by provoking a NULL deref when pressing 'z':

     0.31%  libc-2.20.so     [.] malloc_consolidate
     0.31%  ld-2.20.so       [.] _dl_relocate_object
     0.28%  cc1              [.] ht_lookup
     0.28%  cc1              [.] ira_init_register_move_cost
  perf: Segmentation fault
  Obtained 7 stack frames.
  perf(dump_stack+0x32) [0x4d69f2]
  perf(sighandler_dump_stack+0x29) [0x4d6a89]
  /lib64/libc.so.6(+0x34960) [0x7f5064333960]
  perf() [0x438790]
  /lib64/libpthread.so.0(+0x752a) [0x7f50663dd52a]
  /lib64/libc.so.6(clone+0x6d) [0x7f50643ff22d]
  #

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-pewrpzqd29rgmhu2wkk7fhww@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Fix buildid processing

After recording, 'perf record' post-processes the data to determine
which buildids are needed.

That processing must process the data in time order, if possible,
because otherwise dependent events, like forks and mmaps, will not make
sense.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Jiri Olsa <jolsa@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1439994561-27436-4-git-send-email-adrian.hunter@intel.com
[ Moved the sample_id_add to after trying to open the events, use pr_warning ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Make fork event processing more resilient

When processing a fork event, the tools lookup the parent thread by its
tid.  In a couple of cases, it is possible for that thread to have the
wrong pid.

That can happen if the data is being processed out of order, or if the
(fork) event that would have removed the erroneous thread was lost.

Assume the latter case, print a dump message, remove the erroneous
thread, create a new one with the correct pid, and keep going.

Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Jiri Olsa <jolsa@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1439994561-27436-3-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools: Avoid deadlock when map_groups are broken

Attempting to clone map groups onto themselves will deadlock.

It only happens because of other bugs, but the code should protect
itself anyway.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Jiri Olsa <jolsa@kernel.org>
Link: http://lkml.kernel.org/r/1439994561-27436-2-git-send-email-adrian.hunter@intel.com
[ Use pr_debug() instead of dump_fprintf() ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Merge tag 'asoc-v4.2-disable-topology' of git://git./linux/kernel/git/broonie/sound into for-linus

ASoC: Disable topology support for v4.2

The topology code merged in the v4.2 merge window introduced a new ABI
which was believed to be suitable for use but subsequently additional
work by the developers of this feature have revealed some problems that
need to be addressed.  In order to allow this to be done without having
to support the initial ABI add Kconfig to disable the build and also add
some #error statements to the UAPI header so users can't use them.