--- /dev/null
+From 1d512cb77bdbda80f0dd0620a3b260d697fd581d Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Mon, 9 Nov 2015 00:33:58 +0000
+Subject: Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 1d512cb77bdbda80f0dd0620a3b260d697fd581d upstream.
+
+If we are using the NO_HOLES feature, we have a tiny time window when
+running delalloc for a nodatacow inode where we can race with a concurrent
+link or xattr add operation leading to a BUG_ON.
+
+This happens because at run_delalloc_nocow() we end up casting a leaf item
+of type BTRFS_INODE_[REF|EXTREF]_KEY or of type BTRFS_XATTR_ITEM_KEY to a
+file extent item (struct btrfs_file_extent_item) and then analyse its
+extent type field, which won't match any of the expected extent types
+(values BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]) and therefore trigger an
+explicit BUG_ON(1).
+
+The following sequence diagram shows how the race happens when running a
+no-cow dellaloc range [4K, 8K[ for inode 257 and we have the following
+neighbour leafs:
+
+ Leaf X (has N items) Leaf Y
+
+ [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ] [ (257 EXTENT_DATA 8192), ... ]
+ slot N - 2 slot N - 1 slot 0
+
+ (Note the implicit hole for inode 257 regarding the [0, 8K[ range)
+
+ CPU 1 CPU 2
+
+ run_dealloc_nocow()
+ btrfs_lookup_file_extent()
+ --> searches for a key with value
+ (257 EXTENT_DATA 4096) in the
+ fs/subvol tree
+ --> returns us a path with
+ path->nodes[0] == leaf X and
+ path->slots[0] == N
+
+ because path->slots[0] is >=
+ btrfs_header_nritems(leaf X), it
+ calls btrfs_next_leaf()
+
+ btrfs_next_leaf()
+ --> releases the path
+
+ hard link added to our inode,
+ with key (257 INODE_REF 500)
+ added to the end of leaf X,
+ so leaf X now has N + 1 keys
+
+ --> searches for the key
+ (257 INODE_REF 256), because
+ it was the last key in leaf X
+ before it released the path,
+ with path->keep_locks set to 1
+
+ --> ends up at leaf X again and
+ it verifies that the key
+ (257 INODE_REF 256) is no longer
+ the last key in the leaf, so it
+ returns with path->nodes[0] ==
+ leaf X and path->slots[0] == N,
+ pointing to the new item with
+ key (257 INODE_REF 500)
+
+ the loop iteration of run_dealloc_nocow()
+ does not break out the loop and continues
+ because the key referenced in the path
+ at path->nodes[0] and path->slots[0] is
+ for inode 257, its type is < BTRFS_EXTENT_DATA_KEY
+ and its offset (500) is less then our delalloc
+ range's end (8192)
+
+ the item pointed by the path, an inode reference item,
+ is (incorrectly) interpreted as a file extent item and
+ we get an invalid extent type, leading to the BUG_ON(1):
+
+ if (extent_type == BTRFS_FILE_EXTENT_REG ||
+ extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
+ (...)
+ } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
+ (...)
+ } else {
+ BUG_ON(1)
+ }
+
+The same can happen if a xattr is added concurrently and ends up having
+a key with an offset smaller then the delalloc's range end.
+
+So fix this by skipping keys with a type smaller than
+BTRFS_EXTENT_DATA_KEY.
+
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/inode.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/inode.c
++++ b/fs/btrfs/inode.c
+@@ -1286,8 +1286,14 @@ next_slot:
+ num_bytes = 0;
+ btrfs_item_key_to_cpu(leaf, &found_key, path->slots[0]);
+
+- if (found_key.objectid > ino ||
+- found_key.type > BTRFS_EXTENT_DATA_KEY ||
++ if (found_key.objectid > ino)
++ break;
++ if (WARN_ON_ONCE(found_key.objectid < ino) ||
++ found_key.type < BTRFS_EXTENT_DATA_KEY) {
++ path->slots[0]++;
++ goto next_slot;
++ }
++ if (found_key.type > BTRFS_EXTENT_DATA_KEY ||
+ found_key.offset > end)
+ break;
+
--- /dev/null
+From aeafbf8486c9e2bd53f5cc3c10c0b7fd7149d69c Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Fri, 6 Nov 2015 13:33:33 +0000
+Subject: Btrfs: fix race leading to incorrect item deletion when dropping extents
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit aeafbf8486c9e2bd53f5cc3c10c0b7fd7149d69c upstream.
+
+While running a stress test I got the following warning triggered:
+
+ [191627.672810] ------------[ cut here ]------------
+ [191627.673949] WARNING: CPU: 8 PID: 8447 at fs/btrfs/file.c:779 __btrfs_drop_extents+0x391/0xa50 [btrfs]()
+ (...)
+ [191627.701485] Call Trace:
+ [191627.702037] [<ffffffff8145f077>] dump_stack+0x4f/0x7b
+ [191627.702992] [<ffffffff81095de5>] ? console_unlock+0x356/0x3a2
+ [191627.704091] [<ffffffff8104b3b0>] warn_slowpath_common+0xa1/0xbb
+ [191627.705380] [<ffffffffa0664499>] ? __btrfs_drop_extents+0x391/0xa50 [btrfs]
+ [191627.706637] [<ffffffff8104b46d>] warn_slowpath_null+0x1a/0x1c
+ [191627.707789] [<ffffffffa0664499>] __btrfs_drop_extents+0x391/0xa50 [btrfs]
+ [191627.709155] [<ffffffff8115663c>] ? cache_alloc_debugcheck_after.isra.32+0x171/0x1d0
+ [191627.712444] [<ffffffff81155007>] ? kmemleak_alloc_recursive.constprop.40+0x16/0x18
+ [191627.714162] [<ffffffffa06570c9>] insert_reserved_file_extent.constprop.40+0x83/0x24e [btrfs]
+ [191627.715887] [<ffffffffa065422b>] ? start_transaction+0x3bb/0x610 [btrfs]
+ [191627.717287] [<ffffffffa065b604>] btrfs_finish_ordered_io+0x273/0x4e2 [btrfs]
+ [191627.728865] [<ffffffffa065b888>] finish_ordered_fn+0x15/0x17 [btrfs]
+ [191627.730045] [<ffffffffa067d688>] normal_work_helper+0x14c/0x32c [btrfs]
+ [191627.731256] [<ffffffffa067d96a>] btrfs_endio_write_helper+0x12/0x14 [btrfs]
+ [191627.732661] [<ffffffff81061119>] process_one_work+0x24c/0x4ae
+ [191627.733822] [<ffffffff810615b0>] worker_thread+0x206/0x2c2
+ [191627.734857] [<ffffffff810613aa>] ? process_scheduled_works+0x2f/0x2f
+ [191627.736052] [<ffffffff810613aa>] ? process_scheduled_works+0x2f/0x2f
+ [191627.737349] [<ffffffff810669a6>] kthread+0xef/0xf7
+ [191627.738267] [<ffffffff810f3b3a>] ? time_hardirqs_on+0x15/0x28
+ [191627.739330] [<ffffffff810668b7>] ? __kthread_parkme+0xad/0xad
+ [191627.741976] [<ffffffff81465592>] ret_from_fork+0x42/0x70
+ [191627.743080] [<ffffffff810668b7>] ? __kthread_parkme+0xad/0xad
+ [191627.744206] ---[ end trace bbfddacb7aaada8d ]---
+
+ $ cat -n fs/btrfs/file.c
+ 691 int __btrfs_drop_extents(struct btrfs_trans_handle *trans,
+ (...)
+ 758 btrfs_item_key_to_cpu(leaf, &key, path->slots[0]);
+ 759 if (key.objectid > ino ||
+ 760 key.type > BTRFS_EXTENT_DATA_KEY || key.offset >= end)
+ 761 break;
+ 762
+ 763 fi = btrfs_item_ptr(leaf, path->slots[0],
+ 764 struct btrfs_file_extent_item);
+ 765 extent_type = btrfs_file_extent_type(leaf, fi);
+ 766
+ 767 if (extent_type == BTRFS_FILE_EXTENT_REG ||
+ 768 extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
+ (...)
+ 774 } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
+ (...)
+ 778 } else {
+ 779 WARN_ON(1);
+ 780 extent_end = search_start;
+ 781 }
+ (...)
+
+This happened because the item we were processing did not match a file
+extent item (its key type != BTRFS_EXTENT_DATA_KEY), and even on this
+case we cast the item to a struct btrfs_file_extent_item pointer and
+then find a type field value that does not match any of the expected
+values (BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]). This scenario happens
+due to a tiny time window where a race can happen as exemplified below.
+For example, consider the following scenario where we're using the
+NO_HOLES feature and we have the following two neighbour leafs:
+
+ Leaf X (has N items) Leaf Y
+
+[ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ] [ (257 EXTENT_DATA 8192), ... ]
+ slot N - 2 slot N - 1 slot 0
+
+Our inode 257 has an implicit hole in the range [0, 8K[ (implicit rather
+than explicit because NO_HOLES is enabled). Now if our inode has an
+ordered extent for the range [4K, 8K[ that is finishing, the following
+can happen:
+
+ CPU 1 CPU 2
+
+ btrfs_finish_ordered_io()
+ insert_reserved_file_extent()
+ __btrfs_drop_extents()
+ Searches for the key
+ (257 EXTENT_DATA 4096) through
+ btrfs_lookup_file_extent()
+
+ Key not found and we get a path where
+ path->nodes[0] == leaf X and
+ path->slots[0] == N
+
+ Because path->slots[0] is >=
+ btrfs_header_nritems(leaf X), we call
+ btrfs_next_leaf()
+
+ btrfs_next_leaf() releases the path
+
+ inserts key
+ (257 INODE_REF 4096)
+ at the end of leaf X,
+ leaf X now has N + 1 keys,
+ and the new key is at
+ slot N
+
+ btrfs_next_leaf() searches for
+ key (257 INODE_REF 256), with
+ path->keep_locks set to 1,
+ because it was the last key it
+ saw in leaf X
+
+ finds it in leaf X again and
+ notices it's no longer the last
+ key of the leaf, so it returns 0
+ with path->nodes[0] == leaf X and
+ path->slots[0] == N (which is now
+ < btrfs_header_nritems(leaf X)),
+ pointing to the new key
+ (257 INODE_REF 4096)
+
+ __btrfs_drop_extents() casts the
+ item at path->nodes[0], slot
+ path->slots[0], to a struct
+ btrfs_file_extent_item - it does
+ not skip keys for the target
+ inode with a type less than
+ BTRFS_EXTENT_DATA_KEY
+ (BTRFS_INODE_REF_KEY < BTRFS_EXTENT_DATA_KEY)
+
+ sees a bogus value for the type
+ field triggering the WARN_ON in
+ the trace shown above, and sets
+ extent_end = search_start (4096)
+
+ does the if-then-else logic to
+ fixup 0 length extent items created
+ by a past bug from hole punching:
+
+ if (extent_end == key.offset &&
+ extent_end >= search_start)
+ goto delete_extent_item;
+
+ that evaluates to true and it ends
+ up deleting the key pointed to by
+ path->slots[0], (257 INODE_REF 4096),
+ from leaf X
+
+The same could happen for example for a xattr that ends up having a key
+with an offset value that matches search_start (very unlikely but not
+impossible).
+
+So fix this by ensuring that keys smaller than BTRFS_EXTENT_DATA_KEY are
+skipped, never casted to struct btrfs_file_extent_item and never deleted
+by accident. Also protect against the unexpected case of getting a key
+for a lower inode number by skipping that key and issuing a warning.
+
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/file.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+--- a/fs/btrfs/file.c
++++ b/fs/btrfs/file.c
+@@ -736,8 +736,16 @@ next_slot:
+ }
+
+ btrfs_item_key_to_cpu(leaf, &key, path->slots[0]);
+- if (key.objectid > ino ||
+- key.type > BTRFS_EXTENT_DATA_KEY || key.offset >= end)
++
++ if (key.objectid > ino)
++ break;
++ if (WARN_ON_ONCE(key.objectid < ino) ||
++ key.type < BTRFS_EXTENT_DATA_KEY) {
++ ASSERT(del_nr == 0);
++ path->slots[0]++;
++ goto next_slot;
++ }
++ if (key.type > BTRFS_EXTENT_DATA_KEY || key.offset >= end)
+ break;
+
+ fi = btrfs_item_ptr(leaf, path->slots[0],
+@@ -755,8 +763,8 @@ next_slot:
+ extent_end = key.offset +
+ btrfs_file_extent_inline_len(leaf, fi);
+ } else {
+- WARN_ON(1);
+- extent_end = search_start;
++ /* can't happen */
++ BUG();
+ }
+
+ if (extent_end <= search_start) {
--- /dev/null
+From 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 Mon Sep 17 00:00:00 2001
+From: Daeho Jeong <daeho.jeong@samsung.com>
+Date: Sun, 18 Oct 2015 17:02:56 -0400
+Subject: ext4, jbd2: ensure entering into panic after recording an error in superblock
+
+From: Daeho Jeong <daeho.jeong@samsung.com>
+
+commit 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 upstream.
+
+If a EXT4 filesystem utilizes JBD2 journaling and an error occurs, the
+journaling will be aborted first and the error number will be recorded
+into JBD2 superblock and, finally, the system will enter into the
+panic state in "errors=panic" option. But, in the rare case, this
+sequence is little twisted like the below figure and it will happen
+that the system enters into panic state, which means the system reset
+in mobile environment, before completion of recording an error in the
+journal superblock. In this case, e2fsck cannot recognize that the
+filesystem failure occurred in the previous run and the corruption
+wouldn't be fixed.
+
+Task A Task B
+ext4_handle_error()
+-> jbd2_journal_abort()
+ -> __journal_abort_soft()
+ -> __jbd2_journal_abort_hard()
+ | -> journal->j_flags |= JBD2_ABORT;
+ |
+ | __ext4_abort()
+ | -> jbd2_journal_abort()
+ | | -> __journal_abort_soft()
+ | | -> if (journal->j_flags & JBD2_ABORT)
+ | | return;
+ | -> panic()
+ |
+ -> jbd2_journal_update_sb_errno()
+
+Tested-by: Hobin Woo <hobin.woo@samsung.com>
+Signed-off-by: Daeho Jeong <daeho.jeong@samsung.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/super.c | 12 ++++++++++--
+ fs/jbd2/journal.c | 6 +++++-
+ include/linux/jbd2.h | 1 +
+ 3 files changed, 16 insertions(+), 3 deletions(-)
+
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -400,9 +400,13 @@ static void ext4_handle_error(struct sup
+ ext4_msg(sb, KERN_CRIT, "Remounting filesystem read-only");
+ sb->s_flags |= MS_RDONLY;
+ }
+- if (test_opt(sb, ERRORS_PANIC))
++ if (test_opt(sb, ERRORS_PANIC)) {
++ if (EXT4_SB(sb)->s_journal &&
++ !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
++ return;
+ panic("EXT4-fs (device %s): panic forced after error\n",
+ sb->s_id);
++ }
+ }
+
+ void __ext4_error(struct super_block *sb, const char *function,
+@@ -576,8 +580,12 @@ void __ext4_abort(struct super_block *sb
+ jbd2_journal_abort(EXT4_SB(sb)->s_journal, -EIO);
+ save_error_info(sb, function, line);
+ }
+- if (test_opt(sb, ERRORS_PANIC))
++ if (test_opt(sb, ERRORS_PANIC)) {
++ if (EXT4_SB(sb)->s_journal &&
++ !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
++ return;
+ panic("EXT4-fs panic from previous error\n");
++ }
+ }
+
+ void ext4_msg(struct super_block *sb, const char *prefix, const char *fmt, ...)
+--- a/fs/jbd2/journal.c
++++ b/fs/jbd2/journal.c
+@@ -2049,8 +2049,12 @@ static void __journal_abort_soft (journa
+
+ __jbd2_journal_abort_hard(journal);
+
+- if (errno)
++ if (errno) {
+ jbd2_journal_update_sb_errno(journal);
++ write_lock(&journal->j_state_lock);
++ journal->j_flags |= JBD2_REC_ERR;
++ write_unlock(&journal->j_state_lock);
++ }
+ }
+
+ /**
+--- a/include/linux/jbd2.h
++++ b/include/linux/jbd2.h
+@@ -977,6 +977,7 @@ struct journal_s
+ #define JBD2_ABORT_ON_SYNCDATA_ERR 0x040 /* Abort the journal on file
+ * data write error in ordered
+ * mode */
++#define JBD2_REC_ERR 0x080 /* The errno in the sb has been recorded */
+
+ /*
+ * Function declarations for the journaling transaction and buffer
--- /dev/null
+From 100ceb66d5c40cc0c7018e06a9474302470be73c Mon Sep 17 00:00:00 2001
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Tue, 3 Nov 2015 01:46:21 +0100
+Subject: firewire: ohci: fix JMicron JMB38x IT context discovery
+
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+commit 100ceb66d5c40cc0c7018e06a9474302470be73c upstream.
+
+Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo
+controllers: Often or even most of the time, the controller is
+initialized with the message "added OHCI v1.10 device as card 0, 4 IR +
+0 IT contexts, quirks 0x10". With 0 isochronous transmit DMA contexts
+(IT contexts), applications like audio output are impossible.
+
+However, OHCI-1394 demands that at least 4 IT contexts are implemented
+by the link layer controller, and indeed JMicron JMB38x do implement
+four of them. Only their IsoXmitIntMask register is unreliable at early
+access.
+
+With my own JMB381 single function controller I found:
+ - I can reproduce the problem with a lower probability than Craig's.
+ - If I put a loop around the section which clears and reads
+ IsoXmitIntMask, then either the first or the second attempt will
+ return the correct initial mask of 0x0000000f. I never encountered
+ a case of needing more than a second attempt.
+ - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet)
+ before the first write, the subsequent read will return the correct
+ result.
+ - If I merely ignore a wrong read result and force the known real
+ result, later isochronous transmit DMA usage works just fine.
+
+So let's just fix this chip bug up by the latter method. Tested with
+JMB381 on kernel 3.13 and 4.3.
+
+Since OHCI-1394 generally requires 4 IT contexts at a minium, this
+workaround is simply applied whenever the initial read of IsoXmitIntMask
+returns 0, regardless whether it's a JMicron chip or not. I never heard
+of this issue together with any other chip though.
+
+I am not 100% sure that this fix works on the OHCI-1394 part of JMB380
+and JMB388 combo controllers exactly the same as on the JMB381 single-
+function controller, but so far I haven't had a chance to let an owner
+of a combo chip run a patched kernel.
+
+Strangely enough, IsoRecvIntMask is always reported correctly, even
+though it is probed right before IsoXmitIntMask.
+
+Reported-by: Clifford Dunn
+Reported-by: Craig Moore <craig.moore@qenos.com>
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/firewire/ohci.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/firewire/ohci.c
++++ b/drivers/firewire/ohci.c
+@@ -3670,6 +3670,11 @@ static int pci_probe(struct pci_dev *dev
+
+ reg_write(ohci, OHCI1394_IsoXmitIntMaskSet, ~0);
+ ohci->it_context_support = reg_read(ohci, OHCI1394_IsoXmitIntMaskSet);
++ /* JMicron JMB38x often shows 0 at first read, just ignore it */
++ if (!ohci->it_context_support) {
++ ohci_notice(ohci, "overriding IsoXmitIntMask\n");
++ ohci->it_context_support = 0xf;
++ }
+ reg_write(ohci, OHCI1394_IsoXmitIntMaskClear, ~0);
+ ohci->it_context_mask = ohci->it_context_support;
+ ohci->n_it = hweight32(ohci->it_context_mask);
--- /dev/null
+From c812012f9ca7cf89c9e1a1cd512e6c3b5be04b85 Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@poochiereds.net>
+Date: Wed, 25 Nov 2015 13:50:11 -0500
+Subject: nfs: if we have no valid attrs, then don't declare the attribute cache valid
+
+From: Jeff Layton <jlayton@poochiereds.net>
+
+commit c812012f9ca7cf89c9e1a1cd512e6c3b5be04b85 upstream.
+
+If we pass in an empty nfs_fattr struct to nfs_update_inode, it will
+(correctly) not update any of the attributes, but it then clears the
+NFS_INO_INVALID_ATTR flag, which indicates that the attributes are
+up to date. Don't clear the flag if the fattr struct has no valid
+attrs to apply.
+
+Reviewed-by: Steve French <steve.french@primarydata.com>
+Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/inode.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/fs/nfs/inode.c
++++ b/fs/nfs/inode.c
+@@ -1503,7 +1503,11 @@ static int nfs_update_inode(struct inode
+ nfsi->attrtimeo_timestamp = now;
+ }
+ }
+- invalid &= ~NFS_INO_INVALID_ATTR;
++
++ /* Don't declare attrcache up to date if there were no attrs! */
++ if (fattr->valid != 0)
++ invalid &= ~NFS_INO_INVALID_ATTR;
++
+ /* Don't invalidate the data if we were to blame */
+ if (!(S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode)
+ || S_ISLNK(inode->i_mode)))
--- /dev/null
+From c68a027c05709330fe5b2f50c50d5fa02124b5d8 Mon Sep 17 00:00:00 2001
+From: Benjamin Coddington <bcodding@redhat.com>
+Date: Fri, 20 Nov 2015 09:56:20 -0500
+Subject: nfs4: start callback_ident at idr 1
+
+From: Benjamin Coddington <bcodding@redhat.com>
+
+commit c68a027c05709330fe5b2f50c50d5fa02124b5d8 upstream.
+
+If clp->cl_cb_ident is zero, then nfs_cb_idr_remove_locked() skips removing
+it when the nfs_client is freed. A decoding or server bug can then find
+and try to put that first nfs_client which would lead to a crash.
+
+Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
+Fixes: d6870312659d ("nfs4client: convert to idr_alloc()")
+Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/nfs4client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/nfs/nfs4client.c
++++ b/fs/nfs/nfs4client.c
+@@ -32,7 +32,7 @@ static int nfs_get_cb_ident_idr(struct n
+ return ret;
+ idr_preload(GFP_KERNEL);
+ spin_lock(&nn->nfs_client_lock);
+- ret = idr_alloc(&nn->cb_ident_idr, clp, 0, 0, GFP_NOWAIT);
++ ret = idr_alloc(&nn->cb_ident_idr, clp, 1, 0, GFP_NOWAIT);
+ if (ret >= 0)
+ clp->cl_cb_ident = ret;
+ spin_unlock(&nn->nfs_client_lock);
broadcom-fix-phy_id_bcm5481-entry-in-the-id-table.patch
ipv6-distinguish-frag-queues-by-device-for-multicast-and-link-local-packets.patch
ipv6-sctp-implement-sctp_v6_destroy_sock.patch
+btrfs-fix-race-leading-to-incorrect-item-deletion-when-dropping-extents.patch
+btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch
+ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch
+firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch
+nfs4-start-callback_ident-at-idr-1.patch
+nfs-if-we-have-no-valid-attrs-then-don-t-declare-the-attribute-cache-valid.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
