Commit 106c992a ("mm/hugetlb: add more arch-defined huge_pte
functions") added an include of <asm-generic/hugetlb.h> to each
architecture's <asm/hugetlb.h> (except s390).  Unfortunately metag was
missed which resulted in build errors when hugetlbfs is enabled (see
below).

Add the include for metag too to fix the build errors:

  mm/hugetlb.c In function 'make_huge_pte':
  mm/hugetlb.c +2250 : error: implicit declaration of function 'huge_pte_mkwrite'
  mm/hugetlb.c +2250 : error: implicit declaration of function 'huge_pte_mkdirty'
  ...
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull ARM fixes from Russell King:
 "The larger changes this time are

   - "ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page"
     which fixes more data corruption problems with O_DIRECT

   - "ARM: 7759/1: decouple CPU offlining from reboot/shutdown" which
     gets us back to working shutdown/reboot on SMP platforms

   - "ARM: 7752/1: errata: LoUIS bit field in CLIDR register is incorrect"
     which fixes a shutdown regression found in v3.10 on Versatile
     Express platforms.

  The remainder are the quite small, maybe one or two line changes"

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7759/1: decouple CPU offlining from reboot/shutdown
  ARM: 7756/1: zImage/virt: remove hyp-stub.S during distclean
  ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page
  ARM: 7754/1: Fix the CPU ID and the mask associated to the PJ4B
  ARM: 7753/1: map_init_section flushes incorrect pmd
  ARM: 7752/1: errata: LoUIS bit field in CLIDR register is incorrect

Pull ia64 build fix from Tony Luck:
 "Fix ia64 build breakage by adding newly needed #include"

We're still debating the patch that caused the build breakage, but this
fix seems like a good idea regardless of how that ends up being handled.

* tag 'please-pull-fixia64' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
  [IA64] Fix include dependency in asm/irqflags.h

Pull SLAB fix from Pekka Enberg:
 "A slab regression fix by Sasha Levin"

* 'slab/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux:
  slab: prevent warnings when allocating with __GFP_NOWARN

Pull sound fixes from Takashi Iwai:
 "Only driver/device-specific small fixes that are pretty safe to apply:

   - USB-audio Android and Logitech webcam fixes
   - HD-audio MacBook Air 4,2 quirk
   - Complete Dell headset quirk entries that were introduced in 3.10"

* tag 'sound-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Add models for Dell headset jacks
  ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam c310
  ALSA: hda - Fix pin configurations for MacBook Air 4,2
  ALSA: usb-audio: work around Android accessory firmware bug
  ALSA: hda - Headset mic support for three more machines

Pull media fixes from Mauro Carvalho Chehab:
 "Series of fixes for 3.10.  There are some usual driver fixes (mostly
  on s5p/exynos playform drivers), plus some fixes at V4L2 core"

* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (40 commits)
  [media] soc_camera: error dev remove and v4l2 call
  [media] sh_veu: fix the buffer size calculation
  [media] sh_veu: keep power supply until the m2m context is released
  [media] sh_veu: invoke v4l2_m2m_job_finish() even if a job has been aborted
  [media] v4l2-ioctl: don't print the clips list
  [media] v4l2-ctrls: V4L2_CTRL_CLASS_FM_RX controls are also valid radio controls
  [media] cx88: fix NULL pointer dereference
  [media] DocBook/media/v4l: update version number
  [media] exynos4-is: Remove "sysreg" clock handling
  [media] exynos4-is: Fix reported colorspace at FIMC-IS-ISP subdev
  [media] exynos4-is: Ensure fimc-is clocks are not enabled until properly configured
  [media] exynos4-is: Prevent NULL pointer dereference when firmware isn't loaded
  [media] s5p-mfc: Add NULL check for allocated buffer
  [media] s5p-mfc: added missing end-of-lines in debug messages
  [media] s5p-mfc: v4l2 controls setup routine moved to initialization code
  [media] s5p-mfc: separate encoder parameters for h264 and mpeg4
  [media] s5p-mfc: Remove special clock usage in driver
  [media] s5p-mfc: Remove unused s5p_mfc_get_decoded_status_v6() function
  [media] v4l2: mem2mem: save irq flags correctly
  [media] coda: v4l2-compliance fix: add VIDIOC_CREATE_BUFS support
  ...

Pull clock framework fixes from Mike Turquette:
 "Half of the fixes here are for Exynos5, fixing regressions in CPUfreq
  due to the common clock framework conversion as well as one fix which
  allows the platform to properly reboot again.

  One core framework fix patches up a memory leak, another fixes a build
  error for the SPEAr platform and finally a Tegra-specific fix allows
  PCIe to initialize properly on that platform again"

* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux:
  ARM: tegra30: clocks: Fix pciex clock registration
  clk: exynos5250: Add CLK_IGNORE_UNUSED flag for pmu clock
  clk: spear: fix build error for spear3xx
  clk: samsung: Fix pll36xx_recalc_rate to handle kdiv properly
  clk: exynos5250: Add sclk_mpll to the parent list of mout_cpu clock
  clk: exynos5250: Update cpufreq related clocks for EXYNOS5250
  clk: remove notifier from list before freeing it

asm/kregs.h isn't always included first, so we need an explicit include.

[Fix build breakage introduced by f21afc25
 smp.h: Use local_irq_{save,restore}() in !SMP version of on_each_cpu().]
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Add comments to machine_shutdown()/halt()/power_off()/restart() that
describe their purpose and/or requirements re: CPUs being active/not.

In machine_shutdown(), replace the call to smp_send_stop() with a call to
disable_nonboot_cpus(). This completely disables all but one CPU, thus
satisfying the requirement that only a single CPU be active for kexec.
Adjust Kconfig dependencies for this change.

In machine_halt()/power_off()/restart(), call smp_send_stop() directly,
rather than via machine_shutdown(); these functions don't need to
completely de-activate all CPUs using hotplug, but rather just quiesce
them.

Remove smp_kill_cpus(), and its call from smp_send_stop().
smp_kill_cpus() was indirectly calling smp_ops.cpu_kill() without calling
smp_ops.cpu_die() on the target CPUs first. At least some implementations
of smp_ops had issues with this; it caused cpu_kill() to hang on Tegra,
for example. Since smp_send_stop() is only used for shutdown, halt, and
power-off, there is no need to attempt any kind of CPU hotplug here.

Adjust Kconfig to reflect that machine_shutdown() (and hence kexec)
relies upon disable_nonboot_cpus(). However, this alone doesn't guarantee
that hotplug will work, or even that hotplug is implemented for a
particular piece of HW that a multi-platform zImage runs on. Hence, add
error-checking to machine_kexec() to determine whether it did work.
Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Tested-by: NZhangfei Gao <zhangfei.gao@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Make sure hyp-stub.S gets removed during make distclean,
this left over file was introduced in commit:

424e5994 ARM: zImage/virt: hyp mode entry support for the zImage loader
Signed-off-by: NMagnus Damm <damm@opensource.se>
Acked-by: NDave Martin <dave.martin@linaro.org>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit f8b63c18 made flush_kernel_dcache_page a no-op assuming that
the pages it needs to handle are kernel mapped only.  However, for
example when doing direct I/O, pages with user space mappings may
occur.

Thus, continue to do lazy flushing if there are no user space
mappings.  Otherwise, flush the kernel cache lines directly.
Signed-off-by: NSimon Baatz <gmbnomis@gmail.com>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: <stable@vger.kernel.org> # 3.2+
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This commit fixes the ID and mask for the PJ4B which was too
restrictive and didn't match the CPU of the Armada 370 SoC.
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This bug was introduced in commit e651eab0.
Some v4/v5 platforms failed to boot due to this.
Signed-off-by: NPo-Yu Chuang <ratbert.chuang@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

On Cortex-A9 before version r1p0, the LoUIS bit field of the CLIDR
register returns zero when it should return one. This leads to cache
maintenance operations which rely on this value to not function as
intended, causing data corruption.

The workaround for this errata is to detect affected CPUs and correct
the LoUIS value read.
Acked-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJon Medhurst <tixy@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

These headset jacks keep coming in on more and more platforms, and
it's possible I don't catch them all. Make it easier to test and
verify by making models.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Just like the previous fix for LogitechHD Webcam c270 in commit
11e7064f, c310 model also requires the
same workaround for avoiding the kernel warning.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59741
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

MacBook Air 4,2 requires the whole default pin configuration table to
be overridden by the driver, as usual, as Apple's machines don't set
up properly after boot.  Otherwise mic won't work, and other ill
effect may happen.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59381Reported-and-tested-by: NPeter John Hartman <peterjohnhartman@gmail.com>
Cc: <stable@vger.kernel.org> [v3.9+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the Android firmware enables the audio interfaces in accessory
mode, it always declares in the control interface's baInterfaceNr array
that interfaces 0 and 1 belong to the audio function.  However, the
accessory interface itself, if also enabled, already is at index 0 and
shifts the actual audio interface numbers to 1 and 2, which prevents the
PCM streaming interface from being seen by the host driver.

To get the PCM interface interface to work, detect when the descriptors
point to the (for this driver useless) accessory interface, and redirect
to the correct one.
Reported-by: NJeremy Rosen <jeremy.rosen@openwide.fr>
Tested-by: NJeremy Rosen <jeremy.rosen@openwide.fr>
Cc: <stable@vger.kernel.org>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

They need these quirks to have headset mic support.

BugLink: https://bugs.launchpad.net/bugs/1189363Tested-by: NShawn Wang <shawn.wang@canonical.com>
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Registering pciex as peripheral clock instead of fixed clock
as tegra_perih_reset_assert(deassert) api of this clock api
gives warning and ultimately does not succeed to assert(deassert)
Signed-off-by: NJay Agarwal <jagarwal@nvidia.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

When you copy some code, you are supposed to read it.  If nothing else,
there's a chance to spot and fix an obvious bug instead of sharing it...

X-Song: "I Got It From Agnes", by Tom Lehrer
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
[ Tom Lehrer? You're dating yourself, Al ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull ARM SoC fixes from Olof Johansson:
 "These are a little later than I planned on since I got caught up with
  handling merges for 3.11 most of the week.

  Another week, another batch of fixes for arm-soc platforms.

  Again, nothing controversial.  A few more than would be ideal, but all
  are valid fixes.  In particular the prima2 panic patch is critical
  since it fixes a problem where multiplatform kernels panic on all but
  prima2 hardware."

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: SAMSUNG: pm: Adjust for pinctrl- and DT-enabled platforms
  ARM: prima2: fix incorrect panic usage
  arm: mvebu: armada-xp-{gp,openblocks-ax3-4}: specify PCIe range
  ARM: Kirkwood: handle mv88f6282 cpu in __kirkwood_variant().
  ARM: omap3: clock: fix wrong container_of in clock36xx.c
  ARM: dts: OMAP5: Fix missing PWM capability to timer nodes
  ARM: dts: omap4-panda|sdp: Fix mux for twl6030 IRQ pin and msecure line
  ARM: dts: AM33xx: Fix properties on gpmc node
  arm: omap2: fix AM33xx hwmod infos for UART2
  ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Pull networking fixes from David Miller:

 1) Fix RTNL locking in batman-adv, from Matthias Schiffer.

 2) Don't allow non-passthrough macvlan devices to set NOPROMISC via
    netlink, otherwise we can end up with corrupted promisc counter
    values on the device.  From Michael S Tsirkin.

 3) Fix stmmac driver build with debugging defines enabled, from Dinh
    Nguyen.

 4) Make sure name string we give in socket address in AF_PACKET is NULL
    terminated, from Daniel Borkmann.

 5) Fix leaking of two uninitialized bytes of memory to userspace in
    l2tp, from Guillaume Nault.

 6) Clear IPCB(skb) before tunneling otherwise we touch dangling IP
    options state and crash.  From Saurabh Mohan.

 7) Fix suspend/resume for davinci_mdio by using suspend_late and
    resume_early.  From Mugunthan V N.

 8) Don't tag ip_tunnel_init_net and ip_tunnel_delete_net with
    __net_{init,exit}, they can be called outside of those contexts.
    From Eric Dumazet.

 9) Fix RX length error in sh_eth driver, from Yoshihiro Shimoda.

10) Fix missing sctp_outq initialization in some code paths of SCTP
    stack, from Neil Horman.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (21 commits)
  sctp: fully initialize sctp_outq in sctp_outq_init
  netiucv: Hold rtnl between name allocation and device registration.
  tulip: Properly check dma mapping result
  net: sh_eth: fix incorrect RX length error if R8A7740
  ip_tunnel: remove __net_init/exit from exported functions
  drivers: net: davinci_mdio: restore mdio clk divider in mdio resume
  drivers: net: davinci_mdio: moving mdio resume earlier than cpsw ethernet driver
  net/ipv4: ip_vti clear skb cb before tunneling.
  tg3: Wait for boot code to finish after power on
  l2tp: Fix sendmsg() return value
  l2tp: Fix PPP header erasure and memory leak
  bonding: fix igmp_retrans type and two related races
  bonding: reset master mac on first enslave failure
  packet: packet_getname_spkt: make sure string is always 0-terminated
  net: ethernet: stmicro: stmmac: Fix compile error when STMMAC_XMIT_DEBUG used
  be2net: Fix 32-bit DMA Mask handling
  xen-netback: don't de-reference vif pointer after having called xenvif_put()
  macvlan: don't touch promisc without passthrough
  batman-adv: Don't handle address updates when bla is disabled
  batman-adv: forward late OGMs from best next hop
  ...

Pull powerpc fixes from Benjamin Herrenschmidt:
 "So here are 3 fixes still for 3.10.  Fixes are simple, bugs are nasty
  (though not recent regressions, nasty enough) and all targeted at
  stable"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc: Fix missing/delayed calls to irq_work
  powerpc: Fix emulation of illegal instructions on PowerNV platform
  powerpc: Fix stack overflow crash in resume_kernel when ftracing

Thanks to commit f91eb62f ("init: scream bloody murder if interrupts
are enabled too early"), "bloody murder" is now being screamed.

With a MIPS OCTEON config, we use on_each_cpu() in our
irq_chip.irq_bus_sync_unlock() function.  This gets called in early as a
result of the time_init() call.  Because the !SMP version of
on_each_cpu() unconditionally enables irqs, we get:

    WARNING: at init/main.c:560 start_kernel+0x250/0x410()
    Interrupts were enabled early
    CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-rc5-Cavium-Octeon+ #801
    Call Trace:
      show_stack+0x68/0x80
      warn_slowpath_common+0x78/0xb0
      warn_slowpath_fmt+0x38/0x48
      start_kernel+0x250/0x410

Suggested fix: Do what we already do in the SMP version of
on_each_cpu(), and use local_irq_save/local_irq_restore.  Because we
need a flags variable, make it a static inline to avoid name space
issues.

[ Change from v1: Convert on_each_cpu to a static inline function, add
  #include <linux/irqflags.h> to avoid build breakage on some files.

  on_each_cpu_mask() and on_each_cpu_cond() suffer the same problem as
  on_each_cpu(), but they are not causing !SMP bugs for me, so I will
  defer changing them to a less urgent patch. ]
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull VFS fixes from Al Viro:
 "Several fixes + obvious cleanup (you've missed a couple of open-coded
  can_lookup() back then)"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  snd_pcm_link(): fix a leak...
  use can_lookup() instead of direct checks of ->i_op->lookup
  move exit_task_namespaces() outside of exit_notify()
  fput: task_work_add() can fail if the caller has passed exit_task_work()
  ncpfs: fix rmdir returns Device or resource busy

Pull xfs fixes from Ben Myers:
 - Remove noisy warnings about experimental support which spams the logs
 - Add padding to align directory and attr structures correctly
 - Set block number on child buffer on a root btree split
 - Disable verifiers during log recovery for non-CRC filesystems

* tag 'for-linus-v3.10-rc6' of git://oss.sgi.com/xfs/xfs:
  xfs: don't shutdown log recovery on validation errors
  xfs: ensure btree root split sets blkno correctly
  xfs: fix implicit padding in directory and attr CRC formats
  xfs: don't emit v5 superblock warnings on write

Pull char / misc fixes from Greg Kroah-Hartman:
 "Here are some small mei driver fixes for 3.10-rc6 that fix some
  reported problems"

* tag 'char-misc-3.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  mei: me: clear interrupts on the resume path
  mei: nfc: fix nfc device freeing
  mei: init: Flush scheduled work before resetting the device

Pull USB fixes from Greg Kroah-Hartman:
 "Here are some small USB driver fixes that resolve some reported
  problems for 3.10-rc6

  Nothing major, just 3 USB serial driver fixes, and two chipidea fixes"

* tag 'usb-3.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  usb: chipidea: fix id change handling
  usb: chipidea: fix no transceiver case
  USB: pl2303: fix device initialisation at open
  USB: spcp8x5: fix device initialisation at open
  USB: f81232: fix device initialisation at open

When replaying interrupts (as a result of the interrupt occurring
while soft-disabled), in the case of the decrementer, we are exclusively
testing for a pending timer target. However we also use decrementer
interrupts to trigger the new "irq_work", which in this case would
be missed.

This change the logic to force a replay in both cases of a timer
boundary reached and a decrementer interrupt having actually occurred
while disabled. The former test is still useful to catch cases where
a CPU having been hard-disabled for a long time completely misses the
interrupt due to a decrementer rollover.

CC: <stable@vger.kernel.org> [v3.4+]
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-by: NSteven Rostedt <rostedt@goodmis.org>

Normally, the kernel emulates a few instructions that are unimplemented
on some processors (e.g. the old dcba instruction), or privileged (e.g.
mfpvr).  The emulation of unimplemented instructions is currently not
working on the PowerNV platform.  The reason is that on these machines,
unimplemented and illegal instructions cause a hypervisor emulation
assist interrupt, rather than a program interrupt as on older CPUs.
Our vector for the emulation assist interrupt just calls
program_check_exception() directly, without setting the bit in SRR1
that indicates an illegal instruction interrupt.  This fixes it by
making the emulation assist interrupt set that bit before calling
program_check_interrupt().  With this, old programs that use no-longer
implemented instructions such as dcba now work again.

CC: <stable@vger.kernel.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

It's possible for us to crash when running with ftrace enabled, eg:

  Bad kernel stack pointer bffffd12 at c00000000000a454
  cpu 0x3: Vector: 300 (Data Access) at [c00000000ffe3d40]
      pc: c00000000000a454: resume_kernel+0x34/0x60
      lr: c00000000000335c: performance_monitor_common+0x15c/0x180
      sp: bffffd12
     msr: 8000000000001032
     dar: bffffd12
   dsisr: 42000000

If we look at current's stack (paca->__current->stack) we see it is
equal to c0000002ecab0000. Our stack is 16K, and comparing to
paca->kstack (c0000002ecab3e30) we can see that we have overflowed our
kernel stack. This leads to us writing over our struct thread_info, and
in this case we have corrupted thread_info->flags and set
_TIF_EMULATE_STACK_STORE.

Dumping the stack we see:

  3:mon> t c0000002ecab0000
  [c0000002ecab0000] c00000000002131c .performance_monitor_exception+0x5c/0x70
  [c0000002ecab0080] c00000000000335c performance_monitor_common+0x15c/0x180
  --- Exception: f01 (Performance Monitor) at c0000000000fb2ec .trace_hardirqs_off+0x1c/0x30
  [c0000002ecab0370] c00000000016fdb0 .trace_graph_entry+0xb0/0x280 (unreliable)
  [c0000002ecab0410] c00000000003d038 .prepare_ftrace_return+0x98/0x130
  [c0000002ecab04b0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
  [c0000002ecab0520] c0000000000d6b58 .idle_cpu+0x18/0x90
  [c0000002ecab05a0] c00000000000a934 .return_to_handler+0x0/0x34
  [c0000002ecab0620] c00000000001e660 .timer_interrupt+0x160/0x300
  [c0000002ecab06d0] c0000000000025dc decrementer_common+0x15c/0x180
  --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0
  [c0000002ecab09c0] c0000000000fe044 .trace_hardirqs_on+0x14/0x30 (unreliable)
  [c0000002ecab0fb0] c00000000016fe3c .trace_graph_entry+0x13c/0x280
  [c0000002ecab1050] c00000000003d038 .prepare_ftrace_return+0x98/0x130
  [c0000002ecab10f0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
  [c0000002ecab1160] c0000000000161f0 .__ppc64_runlatch_on+0x10/0x40
  [c0000002ecab11d0] c00000000000a934 .return_to_handler+0x0/0x34
  --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0

  ... and so on

__ppc64_runlatch_on() is called from RUNLATCH_ON in the exception entry
path. At that point the irq state is not consistent, ie. interrupts are
hard disabled (by the exception entry), but the paca soft-enabled flag
may be out of sync.

This leads to the local_irq_restore() in trace_graph_entry() actually
enabling interrupts, which we do not want. Because we have not yet
reprogrammed the decrementer we immediately take another decrementer
exception, and recurse.

The fix is twofold. Firstly make sure we call DISABLE_INTS before
calling RUNLATCH_ON. The badly named DISABLE_INTS actually reconciles
the irq state in the paca with the hardware, making it safe again to
call local_irq_save/restore().

Although that should be sufficient to fix the bug, we also mark the
runlatch routines as notrace. They are called very early in the
exception entry and we are asking for trouble tracing them. They are
also fairly uninteresting and tracing them just adds unnecessary
overhead.

[ This regression was introduced by fe1952fc
  "powerpc: Rework runlatch code" by myself --BenH
]

CC: <stable@vger.kernel.org> [v3.4+]
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

in case when snd_pcm_stream_linked(substream) is true, we end up leaking
group.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

a couple of places got missed back when Linus has introduced that one...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

exit_notify() does exit_task_namespaces() after
forget_original_parent(). This was needed to ensure that ->nsproxy
can't be cleared prematurely, an exiting child we are going to
reparent can do do_notify_parent() and use the parent's (ours) pid_ns.

However, after 32084504 "pidns: use task_active_pid_ns in
do_notify_parent" ->nsproxy != NULL is no longer needed, we rely
on task_active_pid_ns().

Move exit_task_namespaces() from exit_notify() to do_exit(), after
exit_fs() and before exit_task_work().

This solves the problem reported by Andrey, free_ipc_ns()->shm_destroy()
does fput() which needs task_work_add().

Note: this particular problem can be fixed if we change fput(), and
that change makes sense anyway. But there is another reason to move
the callsite. The original reason for exit_task_namespaces() from
the middle of exit_notify() was subtle and it has already gone away,
now this looks confusing. And this allows us do simplify exit_notify(),
we can avoid unlock/lock(tasklist) and we can use ->exit_state instead
of PF_EXITING in forget_original_parent().
Reported-by: NAndrey Vagin <avagin@openvz.org>
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: NAndrey Vagin <avagin@openvz.org>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

fput() assumes that it can't be called after exit_task_work() but
this is not true, for example free_ipc_ns()->shm_destroy() can do
this. In this case fput() silently leaks the file.

Change it to fallback to delayed_fput_work if task_work_add() fails.
The patch looks complicated but it is not, it changes the code from

	if (PF_KTHREAD) {
		schedule_work(...);
		return;
	}
	task_work_add(...)

to
	if (!PF_KTHREAD) {
		if (!task_work_add(...))
			return;
		/* fallback */
	}
	schedule_work(...);

As for shm_destroy() in particular, we could make another fix but I
think this change makes sense anyway. There could be another similar
user, it is not safe to assume that task_work_add() can't fail.
Reported-by: NAndrey Vagin <avagin@openvz.org>
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Unfortunately, we cannot guarantee that items logged multiple times
and replayed by log recovery do not take objects back in time. When
they are taken back in time, the go into an intermediate state which
is corrupt, and hence verification that occurs on this intermediate
state causes log recovery to abort with a corruption shutdown.

Instead of causing a shutdown and unmountable filesystem, don't
verify post-recovery items before they are written to disk. This is
less than optimal, but there is no way to detect this issue for
non-CRC filesystems If log recovery successfully completes, this
will be undone and the object will be consistent by subsequent
transactions that are replayed, so in most cases we don't need to
take drastic action.

For CRC enabled filesystems, leave the verifiers in place - we need
to call them to recalculate the CRCs on the objects anyway. This
recovery problem can be solved for such filesystems - we have a LSN
stamped in all metadata at writeback time that we can to determine
whether the item should be replayed or not. This is a separate piece
of work, so is not addressed by this patch.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NBen Myers <bpm@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

(cherry picked from commit 9222a9cf)

For CRC enabled filesystems, the BMBT is rooted in an inode, so it
passes through a different code path on root splits than the
freespace and inode btrees. This is much less traversed by xfstests
than the other trees. When testing on a 1k block size filesystem,
I've been seeing ASSERT failures in generic/234 like:

XFS: Assertion failed: cur->bc_btnum != XFS_BTNUM_BMAP || cur->bc_private.b.allocated == 0, file: fs/xfs/xfs_btree.c, line: 317

which are generally preceded by a lblock check failure. I noticed
this in the bmbt stats:

$ pminfo -f xfs.btree.block_map

xfs.btree.block_map.lookup
    value 39135

xfs.btree.block_map.compare
    value 268432

xfs.btree.block_map.insrec
    value 15786

xfs.btree.block_map.delrec
    value 13884

xfs.btree.block_map.newroot
    value 2

xfs.btree.block_map.killroot
    value 0
.....

Very little coverage of root splits and merges. Indeed, on a 4k
filesystem, block_map.newroot and block_map.killroot are both zero.
i.e. the code is not exercised at all, and it's the only generic
btree infrastructure operation that is not exercised by a default run
of xfstests.

Turns out that on a 1k filesystem, generic/234 accounts for one of
those two root splits, and that is somewhat of a smoking gun. In
fact, it's the same problem we saw in the directory/attr code where
headers are memcpy()d from one block to another without updating the
self describing metadata.

Simple fix - when copying the header out of the root block, make
sure the block number is updated correctly.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NBen Myers <bpm@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

(cherry picked from commit ade1335a)

Michael L. Semon has been testing CRC patches on a 32 bit system and
been seeing assert failures in the directory code from xfs/080.
Thanks to Michael's heroic efforts with printk debugging, we found
that the problem was that the last free space being left in the
directory structure was too small to fit a unused tag structure and
it was being corrupted and attempting to log a region out of bounds.
Hence the assert failure looked something like:

.....
#5 calling xfs_dir2_data_log_unused() 36 32
#1 4092 4095 4096
#2 8182 8183 4096
XFS: Assertion failed: first <= last && last < BBTOB(bp->b_length), file: fs/xfs/xfs_trans_buf.c, line: 568

Where #1 showed the first region of the dup being logged (i.e. the
last 4 bytes of a directory buffer) and #2 shows the corrupt values
being calculated from the length of the dup entry which overflowed
the size of the buffer.

It turns out that the problem was not in the logging code, nor in
the freespace handling code. It is an initial condition bug that
only shows up on 32 bit systems. When a new buffer is initialised,
where's the freespace that is set up:

[  172.316249] calling xfs_dir2_leaf_addname() from xfs_dir_createname()
[  172.316346] #9 calling xfs_dir2_data_log_unused()
[  172.316351] #1 calling xfs_trans_log_buf() 60 63 4096
[  172.316353] #2 calling xfs_trans_log_buf() 4094 4095 4096

Note the offset of the first region being logged? It's 60 bytes into
the buffer. Once I saw that, I pretty much knew that the bug was
going to be caused by this.

Essentially, all direct entries are rounded to 8 bytes in length,
and all entries start with an 8 byte alignment. This means that we
can decode inplace as variables are naturally aligned. With the
directory data supposedly starting on a 8 byte boundary, and all
entries padded to 8 bytes, the minimum freespace in a directory
block is supposed to be 8 bytes, which is large enough to fit a
unused data entry structure (6 bytes in size). The fact we only have
4 bytes of free space indicates a directory data block alignment
problem.

And what do you know - there's an implicit hole in the directory
data block header for the CRC format, which means the header is 60
byte on 32 bit intel systems and 64 bytes on 64 bit systems. Needs
padding. And while looking at the structures, I found the same
problem in the attr leaf header. Fix them both.

Note that this only affects 32 bit systems with CRCs enabled.
Everything else is just fine. Note that CRC enabled filesystems created
before this fix on such systems will not be readable with this fix
applied.
Reported-by: NMichael L. Semon <mlsemon35@gmail.com>
Debugged-by: NMichael L. Semon <mlsemon35@gmail.com>
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NBen Myers <bpm@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

(cherry picked from commit 8a1fd295)