Merge tag 'nfs-for-3.15-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs

Pull NFS client updates from Trond Myklebust:
 "Highlights include:

   - Stable fix for a use after free issue in the NFSv4.1 open code
   - Fix the SUNRPC bi-directional RPC code to account for TCP segmentation
   - Optimise usage of readdirplus when confronted with 'ls -l' situations
   - Soft mount bugfixes
   - NFS over RDMA bugfixes
   - NFSv4 close locking fixes
   - Various NFSv4.x client state management optimisations
   - Rename/unlink code cleanups"

* tag 'nfs-for-3.15-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: (28 commits)
  nfs: pass string length to pr_notice message about readdir loops
  NFSv4: Fix a use-after-free problem in open()
  SUNRPC: rpc_restart_call/rpc_restart_call_prepare should clear task->tk_status
  SUNRPC: Don't let rpc_delay() clobber non-timeout errors
  SUNRPC: Ensure call_connect_status() deals correctly with SOFTCONN tasks
  SUNRPC: Ensure call_status() deals correctly with SOFTCONN tasks
  NFSv4: Ensure we respect soft mount timeouts during trunking discovery
  NFSv4: Schedule recovery if nfs40_walk_client_list() is interrupted
  NFS: advertise only supported callback netids
  SUNRPC: remove KERN_INFO from dprintk() call sites
  SUNRPC: Fix large reads on NFS/RDMA
  NFS: Clean up: revert increase in READDIR RPC buffer max size
  SUNRPC: Ensure that call_bind times out correctly
  SUNRPC: Ensure that call_connect times out correctly
  nfs: emit a fsnotify_nameremove call in sillyrename codepath
  nfs: remove synchronous rename code
  nfs: convert nfs_rename to use async_rename infrastructure
  nfs: make nfs_async_rename non-static
  nfs: abstract out code needed to complete a sillyrename
  NFSv4: Clear the open state flags if the new stateid does not match
  ...
i2c: cadence: fix Kconfig dependency

During development, the driver first really needed to depend on
COMMON_CLK only. Later, it was switched to writel_relaxed, but it was
forgotten to update the dependencies, so build errors occured:

config: make ARCH=i386 allyesconfig

All error/warnings:

   drivers/i2c/busses/i2c-cadence.c: In function 'cdns_i2c_clear_bus_hold':
>> drivers/i2c/busses/i2c-cadence.c:168:3: error: implicit declaration
>> of function 'writel_relaxed' [-Werror=implicit-function-declaration]

Use a very safe dependency for now.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
arm64: fix !CONFIG_COMPAT build failures

Recent arm64 builds using CONFIG_ARM64_64K_PAGES are failing with:

  arch/arm64/kernel/perf_regs.c: In function ‘perf_reg_abi’:
  arch/arm64/kernel/perf_regs.c:41:2: error: implicit declaration of function ‘is_compat_thread’

  arch/arm64/kernel/perf_event.c:1398:2: error: unknown type name ‘compat_uptr_t’

This is due to some recent arm64 perf commits with compat support:

  commit 23c7d70d55c6d9:
    ARM64: perf: add support for frame pointer unwinding in compat mode

  commit 2ee0d7fd36a3f8:
    ARM64: perf: add support for perf registers API

Those patches make the arm64 kernel unbuildable if CONFIG_COMPAT is not
defined and CONFIG_ARM64_64K_PAGES depends on !CONFIG_COMPAT. This patch
allows the arm64 kernel to build with and without CONFIG_COMPAT.

Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
powerpc: Correct emulated mtfsf instruction

The emulated (CONFIG_MATH_EMULATION_FULL)
PowerPC Floating Point instruction mtfsf
does not correctly copy bits from its source
register to the Floating Point Status and Register (FPSCR).

The error is in the preparation of the mask used to
select the bits to be copied from the source to the FPSCR.

Execution of the mtfsf instruction does not produce the same
results on a MPC8548 platform (emulated floating point)
as on MPC7410 or 440EP platforms (hardware floating point).

This error has been detected using a Freescale MPC8548
based platform and the patch below tested using that platform.

The patch is based on the patch(es) provided by
Gabriel Paubert and analysis by Gabriel, James Yang and David Laight.

Signed-off-by: Stephen Chivers <schivers@csc.com>
Signed-off-by: Gabriel Paubert <paubert@iram.es>
Tested-by: Stephen Chivers <schivers@csc.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/le: Enable RTAS events support

The current kernel code assumes big endian and parses RTAS events all
wrong. The most visible effect is that we cannot honor EPOW events,
meaning, for example, we cannot shut down a guest properly from the
hypervisor.

This new patch is largely inspired by Nathan's work: we get rid of all
the bit fields in the RTAS event structures (even the unused ones, for
consistency). We also introduce endian safe accessors for the fields used
by the kernel (trivial rtas_error_type() accessor added for consistency).

Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/tm: Disable IRQ in tm_recheckpoint

We can't take an IRQ when we're about to do a trechkpt as our GPR state is set
to user GPR values.

We've hit this when running some IBM Java stress tests in the lab resulting in
the following dump:

  cpu 0x3f: Vector: 700 (Program Check) at [c000000007eb3d40]
      pc: c000000000050074: restore_gprs+0xc0/0x148
      lr: 00000000b52a8184
      sp: ac57d360
     msr: 8000000100201030
    current = 0xc00000002c500000
    paca    = 0xc000000007dbfc00     softe: 0     irq_happened: 0x00
      pid   = 34535, comm = Pooled Thread #
  R00 = 00000000b52a8184   R16 = 00000000b3e48fda
  R01 = 00000000ac57d360   R17 = 00000000ade79bd8
  R02 = 00000000ac586930   R18 = 000000000fac9bcc
  R03 = 00000000ade60000   R19 = 00000000ac57f930
  R04 = 00000000f6624918   R20 = 00000000ade79be8
  R05 = 00000000f663f238   R21 = 00000000ac218a54
  R06 = 0000000000000002   R22 = 000000000f956280
  R07 = 0000000000000008   R23 = 000000000000007e
  R08 = 000000000000000a   R24 = 000000000000000c
  R09 = 00000000b6e69160   R25 = 00000000b424cf00
  R10 = 0000000000000181   R26 = 00000000f66256d4
  R11 = 000000000f365ec0   R27 = 00000000b6fdcdd0
  R12 = 00000000f66400f0   R28 = 0000000000000001
  R13 = 00000000ada71900   R29 = 00000000ade5a300
  R14 = 00000000ac2185a8   R30 = 00000000f663f238
  R15 = 0000000000000004   R31 = 00000000f6624918
  pc  = c000000000050074 restore_gprs+0xc0/0x148
  cfar= c00000000004fe28 dont_restore_vec+0x1c/0x1a4
  lr  = 00000000b52a8184
  msr = 8000000100201030   cr  = 24804888
  ctr = 0000000000000000   xer = 0000000000000000   trap =  700

This moves tm_recheckpoint to a C function and moves the tm_restore_sprs into
that function.  It then adds IRQ disabling over the trechkpt critical section.
It also sets the TEXASR FS in the signals code to ensure this is never set now
that we explictly write the TM sprs in tm_recheckpoint.

Signed-off-by: Michael Neuling <mikey@neuling.org>
cc: stable@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc: Adjust CPU_FTR_SMT on all platforms

For historical reasons that code was under #ifdef CONFIG_PPC_PSERIES
but it applies equally to all 64-bit platforms.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc: Make boot_cpuid common between 32 and 64-bit

Move the definition to setup-common.c and set the init value
to -1 on both 32 and 64-bit (it was 0 on 64-bit).

Additionally add a check to prom.c to garantee that the init
value has been udpated after the DT scan.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/prom: early_init_dt_scan_cpus() updates cpu features only once

All our cpu feature updates were done for every CPU in the device-tree,
thus overwriting the cputable bits over and over again. Instead do them
only for the boot CPU.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/ppc64: Gracefully handle early interrupts

If we take an interrupt such as a trap caused by a BUG_ON before the
MMU has been setup, the interrupt handlers try to enable virutal mode
and cause a recursive crash, making the original problem very hard
to debug.

This fixes it by adjusting the "kernel_msr" value in the PACA so that
it only has MSR_IR and MSR_DR (translation for instruction and data)
set after the MMU has been initialized for the processor.

We may still not have a console yet but at least we don't get into
a recursive fault (and early debug console or memory dump via JTAG
of the kernel buffer *will* give us the proper error).

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/ppc64: Do not turn AIL (reloc-on interrupts) too early

Turn them on at the same time as we allow MSR_IR/DR in the paca
kernel MSR, ie, after the MMU has been setup enough to be able
to handle relocated access to the linear mapping.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/powernv: Add opal_notifier_unregister() and export to modules

opal_notifier_register() is missing a pending "unregister" variant
and should be exposed to modules.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
tty/hvc_opal: Kick the HVC thread on OPAL console events

The firmware can notify us when new input data is available, so
let's make sure we wakeup the HVC thread in that case.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/powernv: Fix endian issues with OPAL async code

OPAL defines opal_msg as a big endian struct so we have to
byte swap it on little endian builds.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Btrfs: do not reset last_snapshot after relocation

This was done to allow NO_COW to continue to be NO_COW after relocation but it
is not right.  When relocating we will convert blocks to FULL_BACKREF that we
relocate.  We can leave some of these full backref blocks behind if they are not
cow'ed out during the relocation, like if we fail the relocation with ENOSPC and
then just drop the reloc tree.  Then when we go to cow the block again we won't
lookup the extent flags because we won't think there has been a snapshot
recently which means we will do our normal ref drop thing instead of adding back
a tree ref and dropping the shared ref.  This will cause btrfs_free_extent to
blow up because it can't find the ref we are trying to free.  This was found
with my ref verifying tool.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Btrfs: check for an extent_op on the locked ref

We could have possibly added an extent_op to the locked_ref while we dropped
locked_ref->lock, so check for this case as well and loop around.  Otherwise we
could lose flag updates which would lead to extent tree corruption.  Thanks,

cc: stable@vger.kernel.org
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Btrfs: don't clear uptodate if the eb is under IO

So I have an awful exercise script that will run snapshot, balance and
send/receive in parallel.  This sometimes would crash spectacularly and when it
came back up the fs would be completely hosed.  Turns out this is because of a
bad interaction of balance and send/receive.  Send will hold onto its entire
path for the whole send, but its blocks could get relocated out from underneath
it, and because it doesn't old tree locks theres nothing to keep this from
happening.  So it will go to read in a slot with an old transid, and we could
have re-allocated this block for something else and it could have a completely
different transid.  But because we think it is invalid we clear uptodate and
re-read in the block.  If we do this before we actually write out the new block
we could write back stale data to the fs, and boom we're screwed.

Now we definitely need to fix this disconnect between send and balance, but we
really really need to not allow ourselves to accidently read in stale data over
new data.  So make sure we check if the extent buffer is not under io before
clearing uptodate, this will kick back EIO to the caller instead of reading in
stale data and keep us from corrupting the fs.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Btrfs: remove transaction from send

Lets try this again.  We can deadlock the box if we send on a box and try to
write onto the same fs with the app that is trying to listen to the send pipe.
This is because the writer could get stuck waiting for a transaction commit
which is being blocked by the send.  So fix this by making sure looking at the
commit roots is always going to be consistent.  We do this by keeping track of
which roots need to have their commit roots swapped during commit, and then
taking the commit_root_sem and swapping them all at once.  Then make sure we
take a read lock on the commit_root_sem in cases where we search the commit root
to make sure we're always looking at a consistent view of the commit roots.
Previously we had problems with this because we would swap a fs tree commit root
and then swap the extent tree commit root independently which would cause the
backref walking code to screw up sometimes.  With this patch we no longer
deadlock and pass all the weird send/receive corner cases.  Thanks,

Reportedy-by: Hugo Mills <hugo@carfax.org.uk>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
f2fs: introduce f2fs_issue_flush to avoid redundant flush issue

Some storage devices show relatively high latencies to complete cache_flush
commands, even though their normal IO speed is prettry much high. In such
the case, it needs to merge cache_flush commands as much as possible to avoid
issuing them redundantly.
So, this patch introduces a mount option, "-o flush_merge", to mitigate such
the overhead.

If this option is enabled by user, F2FS merges the cache_flush commands and then
issues just one cache_flush on behalf of them. Once the single command is
finished, F2FS sends a completion signal to all the pending threads.

Note that, this option can be used under a workload consisting of very intensive
concurrent fsync calls, while the storage handles cache_flush commands slowly.

Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
staging: r8723au: Fix build problem when RFKILL is not selected

The kbuild test robot reports the following build errors for x86_64-randconfig-c1-0407:

All error/warnings:

   net/built-in.o: In function `wiphy_new':
>> (.text+0x7684c): undefined reference to `rfkill_alloc'
   net/built-in.o: In function `wiphy_rfkill_start_polling':
>> (.text+0x76da4): undefined reference to `rfkill_resume_polling'
   net/built-in.o: In function `wiphy_rfkill_stop_polling':
>> (.text+0x76de9): undefined reference to `rfkill_pause_polling'
   net/built-in.o: In function `wiphy_unregister':
>> (.text+0x76ec9): undefined reference to `rfkill_unregister'
   net/built-in.o: In function `wiphy_rfkill_set_hw_state':
>> (.text+0x771bc): undefined reference to `rfkill_set_hw_state'
   net/built-in.o: In function `wiphy_register':
>> (.text+0x77968): undefined reference to `rfkill_register'
   net/built-in.o: In function `wiphy_register':
>> (.text+0x77981): undefined reference to `rfkill_destroy'
   net/built-in.o: In function `cfg80211_rfkill_sync_work':
>> core.c:(.text+0x788ad): undefined reference to `rfkill_blocked'
   net/built-in.o: In function `cfg80211_dev_free':
>> (.text+0x78a7b): undefined reference to `rfkill_destroy'
   net/built-in.o: In function `cfg80211_netdev_notifier_call':
>> core.c:(.text+0x79203): undefined reference to `rfkill_blocked'
   net/built-in.o: In function `nl80211_start_p2p_device':

These undefined sysbols are all satisfied if a "select RFKILL" is added to
Kconfig. This "fix" leads to another problem as follows:

>> nl80211.c:(.text+0x9032e): undefined reference to `rfkill_blocked'
net/rfkill/Kconfig:4:error: recursive dependency detected!
net/rfkill/Kconfig:4:   symbol RFKILL is selected by R8723AU
drivers/staging/rtl8723au/Kconfig:1:    symbol R8723AU depends on USB
drivers/usb/Kconfig:41: symbol USB is selected by MOUSE_APPLETOUCH
drivers/input/mouse/Kconfig:162:        symbol MOUSE_APPLETOUCH depends on INPUT
drivers/input/Kconfig:8:        symbol INPUT is selected by ACPI_CMPC
drivers/platform/x86/Kconfig:635:       symbol ACPI_CMPC depends on RFKILL

To avoid substituting one build error for another, I added a "depends on RFKILL".
My suspicion is that this particular error is caused by a kbuild bug, or that the
selection of INPUT by ACPI_CMPC is wrong. In any case, that will be solved separately.

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
Cc: kbuild-all@01.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>