Pull i2c fixes from Wolfram Sang:
 "A couple of bugfixes for I2C drivers.

  Because the changes for the piix4 driver are larger than usual, the
  patches have been in linux-next for more than a week with no reports
  coming in. The rest is usual stuff"

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: omap: Fix error handling for clk_get()
  i2c: piix4: Disable completely the IMC during SMBUS_BLOCK_DATA
  i2c: piix4: Fix SMBus port selection for AMD Family 17h chips
  i2c: imx: fix misleading bus recovery debug message
  i2c: imx: use IRQF_SHARED mode to request IRQ
  i2c: ismt: Separate I2C block read from SMBus block read

Merge branch 'fixes-v4.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

Pull key handling fixes from James Morris:
 "This includes a fix for the capabilities code from Colin King, and a
  set of further fixes for the keys subsystem. From David:

   - Fix a bunch of places where kernel drivers may access revoked
     user-type keys and don't do it correctly.

   - Fix some ecryptfs bits.

   - Fix big_key to require CONFIG_CRYPTO.

   - Fix a couple of bugs in the asymmetric key type.

   - Fix a race between updating and finding negative keys.

   - Prevent add_key() from updating uninstantiated keys.

   - Make loading of key flags and expiry time atomic when not holding
     locks"

* 'fixes-v4.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  commoncap: move assignment of fs_ns to avoid null pointer dereference
  pkcs7: Prevent NULL pointer dereference, since sinfo is not always set.
  KEYS: load key flags and expiry time atomically in proc_keys_show()
  KEYS: Load key expiry time atomically in keyring_search_iterator()
  KEYS: load key flags and expiry time atomically in key_validate()
  KEYS: don't let add_key() update an uninstantiated key
  KEYS: Fix race between updating and finding a negative key
  KEYS: checking the input id parameters before finding asymmetric key
  KEYS: Fix the wrong index when checking the existence of second id
  security/keys: BIG_KEY requires CONFIG_CRYPTO
  ecryptfs: fix dereference of NULL user_key_payload
  fscrypt: fix dereference of NULL user_key_payload
  lib/digsig: fix dereference of NULL user_key_payload
  FS-Cache: fix dereference of NULL user_key_payload
  KEYS: encrypted: fix dereference of NULL user_key_payload

Pull power management fix from Rafael Wysocki:
 "This reverts a problematic commit modifying the turbostat utility that
  went in during the 4.13 cycle (Len Brown)"

* tag 'pm-4.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  Revert "tools/power turbostat: stop migrating, unless '-m'"

Because many of RCU's files have not been included into docbook, a
number of errors have accumulated.  This commit fixes them.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Commit 764f8079 ("doc: Add RCU files to docbook-generation files")
added :external: options for RCU source files in the file
Documentation/core-api/kernel-api.rst.  However, this now means nothing,
so this commit removes them.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

This introduces a "register private expedited" membarrier command which
allows eventual removal of important memory barrier constraints on the
scheduler fast-paths. It changes how the "private expedited" membarrier
command (new to 4.14) is used from user-space.

This new command allows processes to register their intent to use the
private expedited command.  This affects how the expedited private
command introduced in 4.14-rc is meant to be used, and should be merged
before 4.14 final.

Processes are now required to register before using
MEMBARRIER_CMD_PRIVATE_EXPEDITED, otherwise that command returns EPERM.

This fixes a problem that arose when designing requested extensions to
sys_membarrier() to allow JITs to efficiently flush old code from
instruction caches.  Several potential algorithms are much less painful
if the user register intent to use this functionality early on, for
example, before the process spawns the second thread.  Registering at
this time removes the need to interrupt each and every thread in that
process at the first expedited sys_membarrier() system call.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull parisc fixes from Helge Deller:
 "Three small important fixes for the parisc architecture:

   - Export __cmpxchg_u64() symbol on 32bit kernel too. This unbreaks
     building the kernel with ixgbe kernel module. From Guenter Roeck.

   - Fix 64-bit atomic cmpxchg kernel helper function for 32-bit kernel
     in LWS code for userspace. This unbreaks e.g. the 64-bit variant of
     the glibc function __sync_fetch_and_add() with a 32-bit parisc
     kernel. From John David Anglin, tagged for backport to v3.13+.

   - Detect nonsynchronous CPU-internal cr16 cycle counters more
     reliable. This avoids stalled CPU warnings by the kernel soft
     lockup detector. From me, tagged for backport to v4.13+"

* 'parisc-4.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Fix detection of nonsynchronous cr16 cycle counters
  parisc: Export __cmpxchg_u64 unconditionally
  parisc: Fix double-word compare and exchange in LWS code on 32-bit kernels

Pull sound fixes from Takashi Iwai:
 "We've got slightly more fixes than wished, but heading to a good
  shape. Most of changes are about HD-audio fixes, one for a buggy code
  that went into 4.13, and another for avoiding a crash due to buggy
  BIOS.

  Apart from HD-audio, a sequencer core change that is only for UP
  config (which must be pretty rare nowadays), and a USB-audio quirk as
  usual"

* tag 'sound-4.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Fix incorrect TLV callback check introduced during set_fs() removal
  ALSA: hda: Remove superfluous '-' added by printk conversion
  ALSA: hda: Abort capability probe at invalid register read
  ALSA: seq: Enable 'use' locking in all configurations
  ALSA: usb-audio: Add native DSD support for Pro-Ject Pre Box S2 Digital

For CPUs which have an unknown or invalid CPU location (physical location)
assume that their cycle counters aren't syncronized across CPUs.
Signed-off-by: Helge Deller <deller@gmx.de>
Fixes: c8c37359 ("parisc: Enhance detection of synchronous cr16 clocksources")
Cc: stable@vger.kernel.org # 4.13+
Signed-off-by: Helge Deller <deller@gmx.de>

__cmpxchg_u64 is built and used outside CONFIG_64BIT and thus needs to
be exported. This fixes the following build error seen when building
parisc:allmodconfig.

ERROR: "__cmpxchg_u64" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Helge Deller <deller@gmx.de>

As discussed on the debian-hppa list, double-wordcompare and exchange
operations fail on 32-bit kernels.  Looking at the code, I realized that
the ",ma" completer does the wrong thing in the  "ldw,ma  4(%r26), %r29"
instruction.  This increments %r26 and causes the following store to
write to the wrong location.

Note by Helge Deller:
The patch applies cleanly to stable kernel series if this upstream
commit is merged in advance:
f4125cfd ("parisc: Avoid trashing sr2 and sr3 in LWS code").
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Tested-by: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
Fixes: 89206491 ("parisc: Implement new LWS CAS supporting 64 bit operations.")
Cc: stable@vger.kernel.org # 3.13+
Signed-off-by: Helge Deller <deller@gmx.de>

The pointer fs_ns is assigned from inode->i_ib->s_user_ns before
a null pointer check on inode, hence if inode is actually null we
will get a null pointer dereference on this assignment. Fix this
by only dereferencing inode after the null pointer check on
inode.

Detected by CoverityScan CID#1455328 ("Dereference before null check")

Fixes: 8db6c34f ("Introduce v3 namespaced file capabilities")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: stable@vger.kernel.org
Acked-by: Serge Hallyn <serge@hallyn.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>

Pull xfs fixes from Darrick Wong:

 - fix some more CONFIG_XFS_RT related build problems

 - fix data loss when writeback at eof races eofblocks gc and loses

 - invalidate page cache after fs finishes a dio write

 - remove dirty page state when invalidating pages so releasepage does
   the right thing when handed a dirty page

* tag 'xfs-4.14-fixes-6' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
  xfs: move two more RT specific functions into CONFIG_XFS_RT
  xfs: trim writepage mapping to within eof
  fs: invalidate page cache after end_io() in dio completion
  xfs: cancel dirty pages on invalidation

Pull block fixes from Jens Axboe:
 "Three small fixes:

   - A fix for skd, it was using kfree() to free a structure allocate
     with kmem_cache_alloc().

   - Stable fix for nbd, fixing a regression using the normal ioctl
     based tools.

   - Fix for a previous fix in this series, that fixed up
     inconsistencies between buffered and direct IO"

* 'for-linus' of git://git.kernel.dk/linux-block:
  fs: Avoid invalidation in interrupt context in dio_complete()
  nbd: don't set the device size until we're connected
  skd: Use kmem_cache_free

Merge tag 'enforcement-4.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull enforcement policy update from Greg KH:
 "Documentation: Add a file explaining the requested Linux kernel
  license enforcement policy

  Here's a new file to the kernel's Documentation directory. It adds a
  short document describing the views of how the Linux kernel community
  feels about enforcing the license of the kernel.

  The patch has been reviewed by a large number of kernel developers
  already, as seen by their acks on the patch, and their agreement of
  the statement with their names on it. The location of the file was
  also agreed upon by the Documentation maintainer, so all should be
  good there.

  For some background information about this statement, see this article
  written by some of the kernel developers involved in drafting it:

	http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/

  and this article that answers a number of questions that came up in
  the discussion of this statement with the kernel developer community:

	http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/

  If anyone has any further questions about it, please let me, and the
  TAB members, know and we will be glad to help answer them"

* tag 'enforcement-4.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  Documentation: Add a file explaining the Linux kernel license enforcement policy

Pull s390 fixes from Martin Schwidefsky:
 "Two bug fixes:

   - A fix for cputime accounting vs CPU hotplug

   - Add two options to zfcpdump_defconfig to make SCSI dump work again"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390: fix zfcpdump-config
  s390/cputime: fix guest/irq/softirq times after CPU hotplug

Pull tracing fix from Steven Rostedt:
 "Testing a new trace event format, I triggered a bug by doing:

    # modprobe trace-events-sample
    # echo 1 > /sys/kernel/debug/tracing/events/sample-trace/enable
    # rmmod trace-events-sample

  This would cause an oops. The issue is that I added another trace
  event sample that reused a reg function of another trace event to
  create a thread to call the tracepoints. The problem was that the reg
  function couldn't handle nested calls (reg; reg; unreg; unreg;) and
  created two threads (instead of one) and only removed one on exit.

  This isn't a critical bug as the bug is only in sample code. But
  sample code should be free of known bugs to prevent others from
  copying it. This is why this is also marked for stable"

* tag 'trace-v4.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing/samples: Fix creation and deletion of simple_thread_fn creation

The commit 99b5c5bb ("ALSA: hda - Remove the use of set_fs()")
converted the get_kctl_0dB_offset() call for killing set_fs() usage in
HD-audio codec code.  The conversion assumed that the TLV callback
used in HD-audio code is only snd_hda_mixer_amp() and applies the TLV
calculation locally.

Although this assumption is correct, and all slave kctls are actually
with that callback, the current code is still utterly buggy; it
doesn't hit this condition and falls back to the next check.  It's
because the function gets called after adding slave kctls to vmaster.
By assigning a slave kctl, the slave kctl object is faked inside
vmaster code, and the whole kctl ops are overridden.  Thus the
callback op points to a different value from what we've assumed.

More badly, as reported by the KERNEXEC and UDEREF features of PaX,
the code flow turns into the unexpected pitfall.  The next fallback
check is SNDRV_CTL_ELEM_ACCESS_TLV_READ access bit, and this always
hits for each kctl with TLV.  Then it evaluates the callback function
pointer wrongly as if it were a TLV array.  Although currently its
side-effect is fairly limited, this incorrect reference may lead to an
unpleasant result.

For addressing the regression, this patch introduces a new helper to
vmaster code, snd_ctl_apply_vmaster_slaves().  This works similarly
like the existing map_slaves() in hda_codec.c: it loops over the slave
list of the given master, and applies the given function to each
slave.  Then the initializer function receives the right kctl object
and we can compare the correct pointer instead of the faked one.

Also, for catching the similar breakage in future, give an error
message when the unexpected TLV callback is found and bail out
immediately.

Fixes: 99b5c5bb ("ALSA: hda - Remove the use of set_fs()")
Reported-by: PaX Team <pageexec@freemail.hu>
Cc: <stable@vger.kernel.org> # v4.13
Signed-off-by: Takashi Iwai <tiwai@suse.de>

While converting the error messages to the standard macros in the
commit 4e76a883 ("ALSA: hda - Replace with standard printk"), a
superfluous '-' slipped in the code mistakenly.  Its influence is
almost negligible, merely shows a dB value as negative integer instead
of positive integer (or vice versa) in the rare error message.
So let's kill this embarrassing byte to show more correct value.

Fixes: 4e76a883 ("ALSA: hda - Replace with standard printk")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The loop in snd_hdac_bus_parse_capabilities() may go to nirvana when
it hits an invalid register value read:

 BUG: unable to handle kernel paging request at ffffad5dc41f3fff
 IP: pci_azx_readl+0x5/0x10 [snd_hda_intel]
 Call Trace:
  snd_hdac_bus_parse_capabilities+0x3c/0x1f0 [snd_hda_core]
  azx_probe_continue+0x7d5/0x940 [snd_hda_intel]
  .....

This happened on a new Intel machine, and we need to check the value
and abort the loop accordingly.

[Note: the fixes tag below indicates only the commit where this patch
 can be applied; the original problem was introduced even before that
 commit]

Fixes: 6720b384 ("ALSA: hda - move bus_parse_capabilities to core")
Cc: <stable@vger.kernel.org>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The ASN.1 parser does not necessarily set the sinfo field,
this patch prevents a NULL pointer dereference on broken
input.

Fixes: 99db4435 ("PKCS#7: Appropriately restrict authenticated attributes and content type")
Signed-off-by: Eric Sesterhenn <eric.sesterhenn@x41-dsec.de>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: stable@vger.kernel.org # 4.3+

In proc_keys_show(), the key semaphore is not held, so the key ->flags
and ->expiry can be changed concurrently.  We therefore should read them
atomically just once.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>

Similar to the case for key_validate(), we should load the key ->expiry
once atomically in keyring_search_iterator(), since it can be changed
concurrently with the flags whenever the key semaphore isn't held.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>

In key_validate(), load the flags and expiry time once atomically, since
these can change concurrently if key_validate() is called without the
key semaphore held.  And we don't want to get inconsistent results if a
variable is referenced multiple times.  For example, key->expiry was
referenced in both 'if (key->expiry)' and in 'if (now.tv_sec >=
key->expiry)', making it theoretically possible to see a spurious
EKEYEXPIRED while the expiration time was being removed, i.e. set to 0.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>

Currently, when passed a key that already exists, add_key() will call the
key's ->update() method if such exists.  But this is heavily broken in the
case where the key is uninstantiated because it doesn't call
__key_instantiate_and_link().  Consequently, it doesn't do most of the
things that are supposed to happen when the key is instantiated, such as
setting the instantiation state, clearing KEY_FLAG_USER_CONSTRUCT and
awakening tasks waiting on it, and incrementing key->user->nikeys.

It also never takes key_construction_mutex, which means that
->instantiate() can run concurrently with ->update() on the same key.  In
the case of the "user" and "logon" key types this causes a memory leak, at
best.  Maybe even worse, the ->update() methods of the "encrypted" and
"trusted" key types actually just dereference a NULL pointer when passed an
uninstantiated key.

Change key_create_or_update() to wait interruptibly for the key to finish
construction before continuing.

This patch only affects *uninstantiated* keys.  For now we still allow a
negatively instantiated key to be updated (thereby positively
instantiating it), although that's broken too (the next patch fixes it)
and I'm not sure that anyone actually uses that functionality either.

Here is a simple reproducer for the bug using the "encrypted" key type
(requires CONFIG_ENCRYPTED_KEYS=y), though as noted above the bug
pertained to more than just the "encrypted" key type:

    #include <stdlib.h>
    #include <unistd.h>
    #include <keyutils.h>

    int main(void)
    {
        int ringid = keyctl_join_session_keyring(NULL);

        if (fork()) {
            for (;;) {
                const char payload[] = "update user:foo 32";

                usleep(rand() % 10000);
                add_key("encrypted", "desc", payload, sizeof(payload), ringid);
                keyctl_clear(ringid);
            }
        } else {
            for (;;)
                request_key("encrypted", "desc", "callout_info", ringid);
        }
    }

It causes:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
    IP: encrypted_update+0xb0/0x170
    PGD 7a178067 P4D 7a178067 PUD 77269067 PMD 0
    PREEMPT SMP
    CPU: 0 PID: 340 Comm: reproduce Tainted: G      D         4.14.0-rc1-00025-g428490e3 #796
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    task: ffff8a467a39a340 task.stack: ffffb15c40770000
    RIP: 0010:encrypted_update+0xb0/0x170
    RSP: 0018:ffffb15c40773de8 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff8a467a275b00 RCX: 0000000000000000
    RDX: 0000000000000005 RSI: ffff8a467a275b14 RDI: ffffffffb742f303
    RBP: ffffb15c40773e20 R08: 0000000000000000 R09: ffff8a467a275b17
    R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000
    R13: 0000000000000000 R14: ffff8a4677057180 R15: ffff8a467a275b0f
    FS:  00007f5d7fb08700(0000) GS:ffff8a467f200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000018 CR3: 0000000077262005 CR4: 00000000001606f0
    Call Trace:
     key_create_or_update+0x2bc/0x460
     SyS_add_key+0x10c/0x1d0
     entry_SYSCALL_64_fastpath+0x1f/0xbe
    RIP: 0033:0x7f5d7f211259
    RSP: 002b:00007ffed03904c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8
    RAX: ffffffffffffffda RBX: 000000003b2a7955 RCX: 00007f5d7f211259
    RDX: 00000000004009e4 RSI: 00000000004009ff RDI: 0000000000400a04
    RBP: 0000000068db8bad R08: 000000003b2a7955 R09: 0000000000000004
    R10: 000000000000001a R11: 0000000000000246 R12: 0000000000400868
    R13: 00007ffed03905d0 R14: 0000000000000000 R15: 0000000000000000
    Code: 77 28 e8 64 34 1f 00 45 31 c0 31 c9 48 8d 55 c8 48 89 df 48 8d 75 d0 e8 ff f9 ff ff 85 c0 41 89 c4 0f 88 84 00 00 00 4c 8b 7d c8 <49> 8b 75 18 4c 89 ff e8 24 f8 ff ff 85 c0 41 89 c4 78 6d 49 8b
    RIP: encrypted_update+0xb0/0x170 RSP: ffffb15c40773de8
    CR2: 0000000000000018

Cc: <stable@vger.kernel.org> # v2.6.12+
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Biggers <ebiggers@google.com>

Consolidate KEY_FLAG_INSTANTIATED, KEY_FLAG_NEGATIVE and the rejection
error into one field such that:

 (1) The instantiation state can be modified/read atomically.

 (2) The error can be accessed atomically with the state.

 (3) The error isn't stored unioned with the payload pointers.

This deals with the problem that the state is spread over three different
objects (two bits and a separate variable) and reading or updating them
atomically isn't practical, given that not only can uninstantiated keys
change into instantiated or rejected keys, but rejected keys can also turn
into instantiated keys - and someone accessing the key might not be using
any locking.

The main side effect of this problem is that what was held in the payload
may change, depending on the state.  For instance, you might observe the
key to be in the rejected state.  You then read the cached error, but if
the key semaphore wasn't locked, the key might've become instantiated
between the two reads - and you might now have something in hand that isn't
actually an error code.

The state is now KEY_IS_UNINSTANTIATED, KEY_IS_POSITIVE or a negative error
code if the key is negatively instantiated.  The key_is_instantiated()
function is replaced with key_is_positive() to avoid confusion as negative
keys are also 'instantiated'.

Additionally, barriering is included:

 (1) Order payload-set before state-set during instantiation.

 (2) Order state-read before payload-read when using the key.

Further separate barriering is necessary if RCU is being used to access the
payload content after reading the payload pointers.

Fixes: 146aa8b1 ("KEYS: Merge the type-specific data with the payload data")
Cc: stable@vger.kernel.org # v4.4+
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>

For finding asymmetric key, the input id_0 and id_1 parameters can
not be NULL at the same time. This patch adds the BUG_ON checking
for id_0 and id_1.

Cc: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>

Fix the wrong index number when checking the existence of second
id in function of finding asymmetric key. The id_1 is the second
id that the index in array must be 1 but not 0.

Fixes: 9eb02989 (KEYS: Generalise x509_request_asymmetric_key())
Cc: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>

The recent rework introduced a possible randconfig build failure
when CONFIG_CRYPTO configured to only allow modules:

security/keys/big_key.o: In function `big_key_crypt':
big_key.c:(.text+0x29f): undefined reference to `crypto_aead_setkey'
security/keys/big_key.o: In function `big_key_init':
big_key.c:(.init.text+0x1a): undefined reference to `crypto_alloc_aead'
big_key.c:(.init.text+0x45): undefined reference to `crypto_aead_setauthsize'
big_key.c:(.init.text+0x77): undefined reference to `crypto_destroy_tfm'
crypto/gcm.o: In function `gcm_hash_crypt_remain_continue':
gcm.c:(.text+0x167): undefined reference to `crypto_ahash_finup'
crypto/gcm.o: In function `crypto_gcm_exit_tfm':
gcm.c:(.text+0x847): undefined reference to `crypto_destroy_tfm'

When we 'select CRYPTO' like the other users, we always get a
configuration that builds.

Fixes: 428490e3 ("security/keys: rewrite all of big_key crypto")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Howells <dhowells@redhat.com>

The 'use' locking macros are no-ops if neither SMP or SND_DEBUG is
enabled.  This might once have been OK in non-preemptible
configurations, but even in that case snd_seq_read() may sleep while
relying on a 'use' lock.  So always use the proper implementations.

Cc: stable@vger.kernel.org
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This reverts commit c91fc851.

That change caused a C6 and PC6 residency regression on large idle systems.

Users also complained about new output indicating jitter:

turbostat: cpu6 jitter 3794 9142
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: 4.13+ <stable@vger.kernel.org> # v4.13+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Otherwise we can get the following if the fck alias is missing:

Unable to handle kernel paging request at virtual address fffffffe
...
PC is at clk_get_rate+0x8/0x10
LR is at omap_i2c_probe+0x278/0x6ec
...
[<c056eb08>] (clk_get_rate) from [<c06f4f08>] (omap_i2c_probe+0x278/0x6ec)
[<c06f4f08>] (omap_i2c_probe) from [<c0610944>] (platform_drv_probe+0x50/0xb0)
[<c0610944>] (platform_drv_probe) from [<c060e900>] (driver_probe_device+0x264/0x2ec)
[<c060e900>] (driver_probe_device) from [<c060cda0>] (bus_for_each_drv+0x70/0xb8)
[<c060cda0>] (bus_for_each_drv) from [<c060e5b0>] (__device_attach+0xcc/0x13c)
[<c060e5b0>] (__device_attach) from [<c060db10>] (bus_probe_device+0x88/0x90)
[<c060db10>] (bus_probe_device) from [<c060df68>] (deferred_probe_work_func+0x4c/0x14c)
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Pull SCSI fixes from James Bottomley:
 "Four mostly error leg fixes and one more important regression in a
  prior commit (the qla2xxx one)"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: fc: check for rport presence in fc_block_scsi_eh
  scsi: qla2xxx: Fix uninitialized work element
  scsi: libiscsi: fix shifting of DID_REQUEUE host byte
  scsi: libfc: fix a deadlock in fc_rport_work
  scsi: fixup kernel warning during rmmod()

Commit 7496946a ("tracing: Add samples of DECLARE_EVENT_CLASS() and
DEFINE_EVENT()") added template examples for all the events. It created a
DEFINE_EVENT_FN() example which reused the foo_bar_reg and foo_bar_unreg
functions.

Enabling both the TRACE_EVENT_FN() and DEFINE_EVENT_FN() example trace
events caused the foo_bar_reg to be called twice, creating the test thread
twice. The foo_bar_unreg would remove it only once, even if it was called
multiple times, leaving a thread existing when the module is unloaded,
causing an oops.

Add a ref count and allow foo_bar_reg() and foo_bar_unreg() be called by
multiple trace events.

Cc: stable@vger.kernel.org
Fixes: 7496946a ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

Currently we try to defer completion of async DIO to the process context
in case there are any mapped pages associated with the inode so that we
can invalidate the pages when the IO completes. However the check is racy
and the pages can be mapped afterwards. If this happens we might end up
calling invalidate_inode_pages2_range() in dio_complete() in interrupt
context which could sleep. This can be reproduced by generic/451.

Fix this by passing the information whether we can or can't invalidate
to the dio_complete(). Thanks Eryu Guan for reporting this and Jan Kara
for suggesting a fix.

Fixes: 332391a9 ("fs: Fix page cache inconsistency when mixing buffered and AIO DIO")
Reported-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Tested-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Pull media fixes from Mauro Carvalho Chehab:
 "Core fixes:
   - cec: Respond to unregistered initiators, when applicable
   - dvb_frontend: only use kref after initialized

  Driver-specific fixes:
   - qcom, camss: Make function vfe_set_selection static
   - qcom: VIDEO_QCOM_CAMSS should depend on HAS_DMA
   - s5p-cec: add NACK detection support
   - media: staging/imx: Fix uninitialized variable warning
   - dib3000mc: i2c transfers over usb cannot be done from stack
   - venus: init registered list on streamoff"

* tag 'media/v4.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  media: dvb_frontend: only use kref after initialized
  media: platform: VIDEO_QCOM_CAMSS should depend on HAS_DMA
  media: cec: Respond to unregistered initiators, when applicable
  media: s5p-cec: add NACK detection support
  media: staging/imx: Fix uninitialized variable warning
  media: qcom: camss: Make function vfe_set_selection static
  media: venus: init registered list on streamoff
  media: dvb: i2c transfers over usb cannot be done from stack

The last cleanup introduced two harmless warnings:

fs/xfs/xfs_fsmap.c:480:1: warning: '__xfs_getfsmap_rtdev' defined but not used
fs/xfs/xfs_fsmap.c:372:1: warning: 'xfs_getfsmap_rtdev_rtbitmap_helper' defined but not used

This moves those two functions as well.

Fixes: bb9c2e54 ("xfs: move more RT specific code under CONFIG_XFS_RT")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>

The writeback rework in commit fbcc0256 ("xfs: Introduce
writeback context for writepages") introduced a subtle change in
behavior with regard to the block mapping used across the
->writepages() sequence. The previous xfs_cluster_write() code would
only flush pages up to EOF at the time of the writepage, thus
ensuring that any pages due to file-extending writes would be
handled on a separate cycle and with a new, updated block mapping.

The updated code establishes a block mapping in xfs_writepage_map()
that could extend beyond EOF if the file has post-eof preallocation.
Because we now use the generic writeback infrastructure and pass the
cached mapping to each writepage call, there is no implicit EOF
limit in place. If eofblocks trimming occurs during ->writepages(),
any post-eof portion of the cached mapping becomes invalid. The
eofblocks code has no means to serialize against writeback because
there are no pages associated with post-eof blocks. Therefore if an
eofblocks trim occurs and is followed by a file-extending buffered
write, not only has the mapping become invalid, but we could end up
writing a page to disk based on the invalid mapping.

Consider the following sequence of events:

- A buffered write creates a delalloc extent and post-eof
  speculative preallocation.
- Writeback starts and on the first writepage cycle, the delalloc
  extent is converted to real blocks (including the post-eof blocks)
  and the mapping is cached.
- The file is closed and xfs_release() trims post-eof blocks. The
  cached writeback mapping is now invalid.
- Another buffered write appends the file with a delalloc extent.
- The concurrent writeback cycle picks up the just written page
  because the writeback range end is LLONG_MAX. xfs_writepage_map()
  attributes it to the (now invalid) cached mapping and writes the
  data to an incorrect location on disk (and where the file offset is
  still backed by a delalloc extent).

This problem is reproduced by xfstests test generic/464, which
triggers racing writes, appends, open/closes and writeback requests.

To address this problem, trim the mapping used during writeback to
within EOF when the mapping is validated. This ensures the mapping
is revalidated for any pages encountered beyond EOF as of the time
the current mapping was cached or last validated.
Reported-by: Eryu Guan <eguan@redhat.com>
Diagnosed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>

Commit 332391a9 ("fs: Fix page cache inconsistency when mixing
buffered and AIO DIO") moved page cache invalidation from
iomap_dio_rw() to iomap_dio_complete() for iomap based direct write
path, but before the dio->end_io() call, and it re-introdued the bug
fixed by commit c771c14b ("iomap: invalidate page caches should
be after iomap_dio_complete() in direct write").

I found this because fstests generic/418 started failing on XFS with
v4.14-rc3 kernel, which is the regression test for this specific
bug.

So similarly, fix it by moving dio->end_io() (which does the
unwritten extent conversion) before page cache invalidation, to make
sure next buffer read reads the final real allocations not unwritten
extents. I also add some comments about why should end_io() go first
in case we get it wrong again in the future.

Note that, there's no such problem in the non-iomap based direct
write path, because we didn't remove the page cache invalidation
after the ->direct_IO() in generic_file_direct_write() call, but I
decided to fix dio_complete() too so we don't leave a landmine
there, also be consistent with iomap_dio_complete().

Fixes: 332391a9 ("fs: Fix page cache inconsistency when mixing buffered and AIO DIO")
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>