From: Greg Kroah-Hartman Date: Fri, 11 Dec 2015 17:19:08 +0000 (-0800) Subject: 3.10-stable patches X-Git-Tag: v4.1.15~15 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1319a2c0ae946a219feb694e4e28a706fdcaa75c;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch btrfs-fix-race-leading-to-incorrect-item-deletion-when-dropping-extents.patch ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch nfs-if-we-have-no-valid-attrs-then-don-t-declare-the-attribute-cache-valid.patch nfs4-start-callback_ident-at-idr-1.patch --- diff --git a/queue-3.10/btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch b/queue-3.10/btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch new file mode 100644 index 00000000000..5530b87a016 --- /dev/null +++ b/queue-3.10/btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch @@ -0,0 +1,122 @@ +From 1d512cb77bdbda80f0dd0620a3b260d697fd581d Mon Sep 17 00:00:00 2001 +From: Filipe Manana +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 + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + diff --git a/queue-3.10/btrfs-fix-race-leading-to-incorrect-item-deletion-when-dropping-extents.patch b/queue-3.10/btrfs-fix-race-leading-to-incorrect-item-deletion-when-dropping-extents.patch new file mode 100644 index 00000000000..d8733da74a5 --- /dev/null +++ b/queue-3.10/btrfs-fix-race-leading-to-incorrect-item-deletion-when-dropping-extents.patch @@ -0,0 +1,198 @@ +From aeafbf8486c9e2bd53f5cc3c10c0b7fd7149d69c Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Fri, 6 Nov 2015 13:33:33 +0000 +Subject: Btrfs: fix race leading to incorrect item deletion when dropping extents + +From: Filipe Manana + +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] [] dump_stack+0x4f/0x7b + [191627.702992] [] ? console_unlock+0x356/0x3a2 + [191627.704091] [] warn_slowpath_common+0xa1/0xbb + [191627.705380] [] ? __btrfs_drop_extents+0x391/0xa50 [btrfs] + [191627.706637] [] warn_slowpath_null+0x1a/0x1c + [191627.707789] [] __btrfs_drop_extents+0x391/0xa50 [btrfs] + [191627.709155] [] ? cache_alloc_debugcheck_after.isra.32+0x171/0x1d0 + [191627.712444] [] ? kmemleak_alloc_recursive.constprop.40+0x16/0x18 + [191627.714162] [] insert_reserved_file_extent.constprop.40+0x83/0x24e [btrfs] + [191627.715887] [] ? start_transaction+0x3bb/0x610 [btrfs] + [191627.717287] [] btrfs_finish_ordered_io+0x273/0x4e2 [btrfs] + [191627.728865] [] finish_ordered_fn+0x15/0x17 [btrfs] + [191627.730045] [] normal_work_helper+0x14c/0x32c [btrfs] + [191627.731256] [] btrfs_endio_write_helper+0x12/0x14 [btrfs] + [191627.732661] [] process_one_work+0x24c/0x4ae + [191627.733822] [] worker_thread+0x206/0x2c2 + [191627.734857] [] ? process_scheduled_works+0x2f/0x2f + [191627.736052] [] ? process_scheduled_works+0x2f/0x2f + [191627.737349] [] kthread+0xef/0xf7 + [191627.738267] [] ? time_hardirqs_on+0x15/0x28 + [191627.739330] [] ? __kthread_parkme+0xad/0xad + [191627.741976] [] ret_from_fork+0x42/0x70 + [191627.743080] [] ? __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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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) { diff --git a/queue-3.10/ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch b/queue-3.10/ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch new file mode 100644 index 00000000000..94481275c84 --- /dev/null +++ b/queue-3.10/ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch @@ -0,0 +1,104 @@ +From 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 Mon Sep 17 00:00:00 2001 +From: Daeho Jeong +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 + +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 +Signed-off-by: Daeho Jeong +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.10/firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch b/queue-3.10/firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch new file mode 100644 index 00000000000..6c0d0eceda9 --- /dev/null +++ b/queue-3.10/firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch @@ -0,0 +1,71 @@ +From 100ceb66d5c40cc0c7018e06a9474302470be73c Mon Sep 17 00:00:00 2001 +From: Stefan Richter +Date: Tue, 3 Nov 2015 01:46:21 +0100 +Subject: firewire: ohci: fix JMicron JMB38x IT context discovery + +From: Stefan Richter + +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 +Signed-off-by: Stefan Richter +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.10/nfs-if-we-have-no-valid-attrs-then-don-t-declare-the-attribute-cache-valid.patch b/queue-3.10/nfs-if-we-have-no-valid-attrs-then-don-t-declare-the-attribute-cache-valid.patch new file mode 100644 index 00000000000..be844972d81 --- /dev/null +++ b/queue-3.10/nfs-if-we-have-no-valid-attrs-then-don-t-declare-the-attribute-cache-valid.patch @@ -0,0 +1,39 @@ +From c812012f9ca7cf89c9e1a1cd512e6c3b5be04b85 Mon Sep 17 00:00:00 2001 +From: Jeff Layton +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 + +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 +Signed-off-by: Jeff Layton +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman + +--- + 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))) diff --git a/queue-3.10/nfs4-start-callback_ident-at-idr-1.patch b/queue-3.10/nfs4-start-callback_ident-at-idr-1.patch new file mode 100644 index 00000000000..c7c27c6aece --- /dev/null +++ b/queue-3.10/nfs4-start-callback_ident-at-idr-1.patch @@ -0,0 +1,33 @@ +From c68a027c05709330fe5b2f50c50d5fa02124b5d8 Mon Sep 17 00:00:00 2001 +From: Benjamin Coddington +Date: Fri, 20 Nov 2015 09:56:20 -0500 +Subject: nfs4: start callback_ident at idr 1 + +From: Benjamin Coddington + +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 +Fixes: d6870312659d ("nfs4client: convert to idr_alloc()") +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.10/series b/queue-3.10/series index 7c6d287ca4d..1190c12b41a 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -11,3 +11,9 @@ net-ip6mr-fix-static-mfc-dev-leaks-on-table-destruction.patch 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