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>
f2fs: check the acl's validity before setting

Before setting the acl, call posix_acl_valid() to check if it is
valid or not.

Signed-off-by: zhangzhen <zhenzhang.zhang@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
f2fs: fix wrong statistics of inline data

If we remove a file that has inline data after mount, our statistics turns to
inaccurate.

cat /sys/kernel/debug/f2fs/status
  - Inline_data Inode: 4294967295

Let's add stat_inc_inline_inode() to stat inline info of the file when lookup.

Change log from v1:
 o stat in f2fs_lookup() instead of in do_read_inode() for excluding wrong stat.

Signed-off-by: Chao Yu <chao2.yu@samsung.com>
Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Revert "HID: microsoft: Add ID's for Surface Type/Touch Cover 2"

This reverts commit 117309c51dca42121f70cacec801511b76acf75c.

The MS Surface Pro 2 has an USB composite device with 3 interfaces
- interface 0 - sensor hub
- interface 1 - wacom digitizer
- interface 2 - the keyboard cover, if one is attached
This USB composite device changes it product id dependent on if and which
keyboard cover is attached. Adding the covers to hid_have_special_driver
prevents loading the right hid drivers for the other two interfaces, all 3
get loaded with hid-microsoft. We don't even need hid-microsoft for the
keyboards. We have to revert this to load the right hid modules for each
interface.

CC: stable@vger.kernel.org # kernel 3.14 only
Signed-off-by: Derya <derya.kiran@yahoo.de>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: core: do not scan constant input report

The Microsoft Surface Type/Touch Cover 2 is a fancy device which advertised
itself as a multitouch device but with constant input reports.
This way, hid_scan_report() gives the group MULTITOUCH to it, but
hid-multitouch can not handle it due to the constant collection ignored
by hid-input.

To prevent such crap in the future, and while we do not fix this particular
device, make the scan_report coherent with hid-input.c, and ignore constant
input reports.

CC: stable@vger.kernel.org # 3.12+
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Target/file: place escape values for protection information format

No need to actually compute protection information when formatting

Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Target/dif: Introduce protection-passthough-only mode

Some transports (iSCSI/iSER/SRP/FC) support hardware INSERT/STRIP
capabilities while other transports like loopback/vhost-scsi need
perform this is software.

This patch allows fabrics using SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC
to signal the early LUN scan handling case where PROTECT CDB bits
are set, but no fabric buffer has been provided.

For transports which use generic new command these buffers have yet
to be allocated.

Also this way, target may support protection information
against legacy initiators (writes are inserted and reads
are stripped).

(Only set prot_pto for loopback during early special case - nab)

Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Target/core: Remove prot_handover use for now

This is not going to be supported soon - so drop it.

Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Target/iscsi: Add T10-PI indication for iscsi_portal_group

In case an iscsi portal group will be defined as t10_pi enabled,
all connections on top of it will support protected transactions.

T10-PI support may require extra reource allocation and maintenance by
the transport layer, so we don't want to apply them on non-t10_pi network
portals. This is a hook for the iscsi target layer to signal the transport
at connection establishment that this connection will carry protected
transactions.

Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Target/configfs: Expose iSCSI network portal group T10-PI support

User may enable T10-PI support per network portal group. any connection
established on top of it, will be required to serve protected transactions.

Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>