From 0d84c4222f6ddc77eee3b8a5173f636e0da08998 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 2 Oct 2017 11:42:28 +0200 Subject: [PATCH] 4.4-stable patches added patches: crypto-talitos-don-t-provide-setkey-for-non-hmac-hashing-algs.patch crypto-talitos-fix-sha224.patch kvm-ppc-book3s-fix-race-and-leak-in-kvm_vm_ioctl_create_spapr_tce.patch md-raid5-fix-a-race-condition-in-stripe-batch.patch md-raid5-preserve-stripe_on_unplug_list-in-break_stripe_batch_list.patch scsi-scsi_transport_iscsi-fix-the-issue-that-iscsi_if_rx-doesn-t-parse-nlmsg-properly.patch tracing-erase-irqsoff-trace-with-empty-write.patch tracing-fix-trace_pipe-behavior-for-instance-traces.patch --- ...ide-setkey-for-non-hmac-hashing-algs.patch | 42 ++++++ queue-4.4/crypto-talitos-fix-sha224.patch | 39 ++++++ ...eak-in-kvm_vm_ioctl_create_spapr_tce.patch | 123 ++++++++++++++++++ ...fix-a-race-condition-in-stripe-batch.patch | 69 ++++++++++ ...plug_list-in-break_stripe_batch_list.patch | 48 +++++++ ...i_if_rx-doesn-t-parse-nlmsg-properly.patch | 61 +++++++++ queue-4.4/series | 8 ++ ...erase-irqsoff-trace-with-empty-write.patch | 51 ++++++++ ...ce_pipe-behavior-for-instance-traces.patch | 46 +++++++ 9 files changed, 487 insertions(+) create mode 100644 queue-4.4/crypto-talitos-don-t-provide-setkey-for-non-hmac-hashing-algs.patch create mode 100644 queue-4.4/crypto-talitos-fix-sha224.patch create mode 100644 queue-4.4/kvm-ppc-book3s-fix-race-and-leak-in-kvm_vm_ioctl_create_spapr_tce.patch create mode 100644 queue-4.4/md-raid5-fix-a-race-condition-in-stripe-batch.patch create mode 100644 queue-4.4/md-raid5-preserve-stripe_on_unplug_list-in-break_stripe_batch_list.patch create mode 100644 queue-4.4/scsi-scsi_transport_iscsi-fix-the-issue-that-iscsi_if_rx-doesn-t-parse-nlmsg-properly.patch create mode 100644 queue-4.4/tracing-erase-irqsoff-trace-with-empty-write.patch create mode 100644 queue-4.4/tracing-fix-trace_pipe-behavior-for-instance-traces.patch diff --git a/queue-4.4/crypto-talitos-don-t-provide-setkey-for-non-hmac-hashing-algs.patch b/queue-4.4/crypto-talitos-don-t-provide-setkey-for-non-hmac-hashing-algs.patch new file mode 100644 index 00000000000..325462372f6 --- /dev/null +++ b/queue-4.4/crypto-talitos-don-t-provide-setkey-for-non-hmac-hashing-algs.patch @@ -0,0 +1,42 @@ +From 56136631573baa537a15e0012055ffe8cfec1a33 Mon Sep 17 00:00:00 2001 +From: LEROY Christophe +Date: Tue, 12 Sep 2017 11:03:39 +0200 +Subject: crypto: talitos - Don't provide setkey for non hmac hashing algs. + +From: LEROY Christophe + +commit 56136631573baa537a15e0012055ffe8cfec1a33 upstream. + +Today, md5sum fails with error -ENOKEY because a setkey +function is set for non hmac hashing algs, see strace output below: + +mmap(NULL, 378880, PROT_READ, MAP_SHARED, 6, 0) = 0x77f50000 +accept(3, 0, NULL) = 7 +vmsplice(5, [{"bin/\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 378880}], 1, SPLICE_F_MORE|SPLICE_F_GIFT) = 262144 +splice(4, NULL, 7, NULL, 262144, SPLICE_F_MORE) = -1 ENOKEY (Required key not available) +write(2, "Generation of hash for file kcap"..., 50) = 50 +munmap(0x77f50000, 378880) = 0 + +This patch ensures that setkey() function is set only +for hmac hashing. + +Signed-off-by: Christophe Leroy +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/crypto/talitos.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/crypto/talitos.c ++++ b/drivers/crypto/talitos.c +@@ -2770,7 +2770,8 @@ static struct talitos_crypto_alg *talito + t_alg->algt.alg.hash.final = ahash_final; + t_alg->algt.alg.hash.finup = ahash_finup; + t_alg->algt.alg.hash.digest = ahash_digest; +- t_alg->algt.alg.hash.setkey = ahash_setkey; ++ if (!strncmp(alg->cra_name, "hmac", 4)) ++ t_alg->algt.alg.hash.setkey = ahash_setkey; + t_alg->algt.alg.hash.import = ahash_import; + t_alg->algt.alg.hash.export = ahash_export; + diff --git a/queue-4.4/crypto-talitos-fix-sha224.patch b/queue-4.4/crypto-talitos-fix-sha224.patch new file mode 100644 index 00000000000..16529afc51b --- /dev/null +++ b/queue-4.4/crypto-talitos-fix-sha224.patch @@ -0,0 +1,39 @@ +From afd62fa26343be6445479e75de9f07092a061459 Mon Sep 17 00:00:00 2001 +From: LEROY Christophe +Date: Wed, 13 Sep 2017 12:44:51 +0200 +Subject: crypto: talitos - fix sha224 + +From: LEROY Christophe + +commit afd62fa26343be6445479e75de9f07092a061459 upstream. + +Kernel crypto tests report the following error at startup + +[ 2.752626] alg: hash: Test 4 failed for sha224-talitos +[ 2.757907] 00000000: 30 e2 86 e2 e7 8a dd 0d d7 eb 9f d5 83 fe f1 b0 +00000010: 2d 5a 6c a5 f9 55 ea fd 0e 72 05 22 + +This patch fixes it + +Signed-off-by: Christophe Leroy +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/crypto/talitos.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/crypto/talitos.c ++++ b/drivers/crypto/talitos.c +@@ -1749,9 +1749,9 @@ static int common_nonsnoop_hash(struct t + req_ctx->swinit = 0; + } else { + desc->ptr[1] = zero_entry; +- /* Indicate next op is not the first. */ +- req_ctx->first = 0; + } ++ /* Indicate next op is not the first. */ ++ req_ctx->first = 0; + + /* HMAC key */ + if (ctx->keylen) diff --git a/queue-4.4/kvm-ppc-book3s-fix-race-and-leak-in-kvm_vm_ioctl_create_spapr_tce.patch b/queue-4.4/kvm-ppc-book3s-fix-race-and-leak-in-kvm_vm_ioctl_create_spapr_tce.patch new file mode 100644 index 00000000000..60118bacef4 --- /dev/null +++ b/queue-4.4/kvm-ppc-book3s-fix-race-and-leak-in-kvm_vm_ioctl_create_spapr_tce.patch @@ -0,0 +1,123 @@ +From paulus@ozlabs.org Mon Oct 2 11:13:24 2017 +From: Paul Mackerras +Date: Tue, 12 Sep 2017 15:54:14 +1000 +Subject: KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce() +To: stable@vger.kernel.org +Message-ID: <20170912055414.qlxo5qyflbnearna@oak.ozlabs.ibm.com> +Content-Disposition: inline + +From: Paul Mackerras + +commit 47c5310a8dbe7c2cb9f0083daa43ceed76c257fa upstream, with part +of commit edd03602d97236e8fea13cd76886c576186aa307 folded in. + +Nixiaoming pointed out that there is a memory leak in +kvm_vm_ioctl_create_spapr_tce() if the call to anon_inode_getfd() +fails; the memory allocated for the kvmppc_spapr_tce_table struct +is not freed, and nor are the pages allocated for the iommu +tables. + +David Hildenbrand pointed out that there is a race in that the +function checks early on that there is not already an entry in the +stt->iommu_tables list with the same LIOBN, but an entry with the +same LIOBN could get added between then and when the new entry is +added to the list. + +This fixes both problems. To simplify things, we now call +anon_inode_getfd() before placing the new entry in the list. The +check for an existing entry is done while holding the kvm->lock +mutex, immediately before adding the new entry to the list. + +[paulus@ozlabs.org - folded in that part of edd03602d972 ("KVM: + PPC: Book3S HV: Protect updates to spapr_tce_tables list", 2017-08-28) + which restructured the code that 47c5310a8dbe modified, to avoid + a build failure caused by the absence of put_unused_fd(). + Also removed the locked memory accounting, since it doesn't exist + in this version, and adjusted the commit message.] + +Fixes: 54738c097163 ("KVM: PPC: Accelerate H_PUT_TCE by implementing it in real mode") +Reported-by: Nixiaoming +Reported-by: David Hildenbrand +Signed-off-by: Paul Mackerras +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kvm/book3s_64_vio.c | 46 ++++++++++++++++++++++----------------- + 1 file changed, 27 insertions(+), 19 deletions(-) + +--- a/arch/powerpc/kvm/book3s_64_vio.c ++++ b/arch/powerpc/kvm/book3s_64_vio.c +@@ -101,22 +101,17 @@ long kvm_vm_ioctl_create_spapr_tce(struc + struct kvm_create_spapr_tce *args) + { + struct kvmppc_spapr_tce_table *stt = NULL; ++ struct kvmppc_spapr_tce_table *siter; + long npages; + int ret = -ENOMEM; + int i; + +- /* Check this LIOBN hasn't been previously allocated */ +- list_for_each_entry(stt, &kvm->arch.spapr_tce_tables, list) { +- if (stt->liobn == args->liobn) +- return -EBUSY; +- } +- + npages = kvmppc_stt_npages(args->window_size); + + stt = kzalloc(sizeof(*stt) + npages * sizeof(struct page *), + GFP_KERNEL); + if (!stt) +- goto fail; ++ return ret; + + stt->liobn = args->liobn; + stt->window_size = args->window_size; +@@ -128,23 +123,36 @@ long kvm_vm_ioctl_create_spapr_tce(struc + goto fail; + } + +- kvm_get_kvm(kvm); +- + mutex_lock(&kvm->lock); +- list_add(&stt->list, &kvm->arch.spapr_tce_tables); ++ ++ /* Check this LIOBN hasn't been previously allocated */ ++ ret = 0; ++ list_for_each_entry(siter, &kvm->arch.spapr_tce_tables, list) { ++ if (siter->liobn == args->liobn) { ++ ret = -EBUSY; ++ break; ++ } ++ } ++ ++ if (!ret) ++ ret = anon_inode_getfd("kvm-spapr-tce", &kvm_spapr_tce_fops, ++ stt, O_RDWR | O_CLOEXEC); ++ ++ if (ret >= 0) { ++ list_add(&stt->list, &kvm->arch.spapr_tce_tables); ++ kvm_get_kvm(kvm); ++ } + + mutex_unlock(&kvm->lock); + +- return anon_inode_getfd("kvm-spapr-tce", &kvm_spapr_tce_fops, +- stt, O_RDWR | O_CLOEXEC); ++ if (ret >= 0) ++ return ret; + +-fail: +- if (stt) { +- for (i = 0; i < npages; i++) +- if (stt->pages[i]) +- __free_page(stt->pages[i]); ++ fail: ++ for (i = 0; i < npages; i++) ++ if (stt->pages[i]) ++ __free_page(stt->pages[i]); + +- kfree(stt); +- } ++ kfree(stt); + return ret; + } diff --git a/queue-4.4/md-raid5-fix-a-race-condition-in-stripe-batch.patch b/queue-4.4/md-raid5-fix-a-race-condition-in-stripe-batch.patch new file mode 100644 index 00000000000..4337724c9b6 --- /dev/null +++ b/queue-4.4/md-raid5-fix-a-race-condition-in-stripe-batch.patch @@ -0,0 +1,69 @@ +From 3664847d95e60a9a943858b7800f8484669740fc Mon Sep 17 00:00:00 2001 +From: Shaohua Li +Date: Fri, 25 Aug 2017 10:40:02 -0700 +Subject: md/raid5: fix a race condition in stripe batch + +From: Shaohua Li + +commit 3664847d95e60a9a943858b7800f8484669740fc upstream. + +We have a race condition in below scenario, say have 3 continuous stripes, sh1, +sh2 and sh3, sh1 is the stripe_head of sh2 and sh3: + +CPU1 CPU2 CPU3 +handle_stripe(sh3) + stripe_add_to_batch_list(sh3) + -> lock(sh2, sh3) + -> lock batch_lock(sh1) + -> add sh3 to batch_list of sh1 + -> unlock batch_lock(sh1) + clear_batch_ready(sh1) + -> lock(sh1) and batch_lock(sh1) + -> clear STRIPE_BATCH_READY for all stripes in batch_list + -> unlock(sh1) and batch_lock(sh1) +->clear_batch_ready(sh3) +-->test_and_clear_bit(STRIPE_BATCH_READY, sh3) +--->return 0 as sh->batch == NULL + -> sh3->batch_head = sh1 + -> unlock (sh2, sh3) + +In CPU1, handle_stripe will continue handle sh3 even it's in batch stripe list +of sh1. By moving sh3->batch_head assignment in to batch_lock, we make it +impossible to clear STRIPE_BATCH_READY before batch_head is set. + +Thanks Stephane for helping debug this tricky issue. + +Reported-and-tested-by: Stephane Thiell +Signed-off-by: Shaohua Li +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid5.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -818,6 +818,14 @@ static void stripe_add_to_batch_list(str + spin_unlock(&head->batch_head->batch_lock); + goto unlock_out; + } ++ /* ++ * We must assign batch_head of this stripe within the ++ * batch_lock, otherwise clear_batch_ready of batch head ++ * stripe could clear BATCH_READY bit of this stripe and ++ * this stripe->batch_head doesn't get assigned, which ++ * could confuse clear_batch_ready for this stripe ++ */ ++ sh->batch_head = head->batch_head; + + /* + * at this point, head's BATCH_READY could be cleared, but we +@@ -825,8 +833,6 @@ static void stripe_add_to_batch_list(str + */ + list_add(&sh->batch_list, &head->batch_list); + spin_unlock(&head->batch_head->batch_lock); +- +- sh->batch_head = head->batch_head; + } else { + head->batch_head = head; + sh->batch_head = head->batch_head; diff --git a/queue-4.4/md-raid5-preserve-stripe_on_unplug_list-in-break_stripe_batch_list.patch b/queue-4.4/md-raid5-preserve-stripe_on_unplug_list-in-break_stripe_batch_list.patch new file mode 100644 index 00000000000..2f90c859718 --- /dev/null +++ b/queue-4.4/md-raid5-preserve-stripe_on_unplug_list-in-break_stripe_batch_list.patch @@ -0,0 +1,48 @@ +From 184a09eb9a2fe425e49c9538f1604b05ed33cfef Mon Sep 17 00:00:00 2001 +From: Dennis Yang +Date: Wed, 6 Sep 2017 11:02:35 +0800 +Subject: md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list + +From: Dennis Yang + +commit 184a09eb9a2fe425e49c9538f1604b05ed33cfef upstream. + +In release_stripe_plug(), if a stripe_head has its STRIPE_ON_UNPLUG_LIST +set, it indicates that this stripe_head is already in the raid5_plug_cb +list and release_stripe() would be called instead to drop a reference +count. Otherwise, the STRIPE_ON_UNPLUG_LIST bit would be set for this +stripe_head and it will get queued into the raid5_plug_cb list. + +Since break_stripe_batch_list() did not preserve STRIPE_ON_UNPLUG_LIST, +A stripe could be re-added to plug list while it is still on that list +in the following situation. If stripe_head A is added to another +stripe_head B's batch list, in this case A will have its +batch_head != NULL and be added into the plug list. After that, +stripe_head B gets handled and called break_stripe_batch_list() to +reset all the batched stripe_head(including A which is still on +the plug list)'s state and reset their batch_head to NULL. +Before the plug list gets processed, if there is another write request +comes in and get stripe_head A, A will have its batch_head == NULL +(cleared by calling break_stripe_batch_list() on B) and be added to +plug list once again. + +Signed-off-by: Dennis Yang +Signed-off-by: Shaohua Li +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid5.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -4264,7 +4264,8 @@ static void break_stripe_batch_list(stru + + set_mask_bits(&sh->state, ~(STRIPE_EXPAND_SYNC_FLAGS | + (1 << STRIPE_PREREAD_ACTIVE) | +- (1 << STRIPE_DEGRADED)), ++ (1 << STRIPE_DEGRADED) | ++ (1 << STRIPE_ON_UNPLUG_LIST)), + head_sh->state & (1 << STRIPE_INSYNC)); + + sh->check_state = head_sh->check_state; diff --git a/queue-4.4/scsi-scsi_transport_iscsi-fix-the-issue-that-iscsi_if_rx-doesn-t-parse-nlmsg-properly.patch b/queue-4.4/scsi-scsi_transport_iscsi-fix-the-issue-that-iscsi_if_rx-doesn-t-parse-nlmsg-properly.patch new file mode 100644 index 00000000000..646dd0a21e9 --- /dev/null +++ b/queue-4.4/scsi-scsi_transport_iscsi-fix-the-issue-that-iscsi_if_rx-doesn-t-parse-nlmsg-properly.patch @@ -0,0 +1,61 @@ +From c88f0e6b06f4092995688211a631bb436125d77b Mon Sep 17 00:00:00 2001 +From: Xin Long +Date: Sun, 27 Aug 2017 20:25:26 +0800 +Subject: scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly + +From: Xin Long + +commit c88f0e6b06f4092995688211a631bb436125d77b upstream. + +ChunYu found a kernel crash by syzkaller: + +[ 651.617875] kasan: CONFIG_KASAN_INLINE enabled +[ 651.618217] kasan: GPF could be caused by NULL-ptr deref or user memory access +[ 651.618731] general protection fault: 0000 [#1] SMP KASAN +[ 651.621543] CPU: 1 PID: 9539 Comm: scsi Not tainted 4.11.0.cov #32 +[ 651.621938] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 +[ 651.622309] task: ffff880117780000 task.stack: ffff8800a3188000 +[ 651.622762] RIP: 0010:skb_release_data+0x26c/0x590 +[...] +[ 651.627260] Call Trace: +[ 651.629156] skb_release_all+0x4f/0x60 +[ 651.629450] consume_skb+0x1a5/0x600 +[ 651.630705] netlink_unicast+0x505/0x720 +[ 651.632345] netlink_sendmsg+0xab2/0xe70 +[ 651.633704] sock_sendmsg+0xcf/0x110 +[ 651.633942] ___sys_sendmsg+0x833/0x980 +[ 651.637117] __sys_sendmsg+0xf3/0x240 +[ 651.638820] SyS_sendmsg+0x32/0x50 +[ 651.639048] entry_SYSCALL_64_fastpath+0x1f/0xc2 + +It's caused by skb_shared_info at the end of sk_buff was overwritten by +ISCSI_KEVENT_IF_ERROR when parsing nlmsg info from skb in iscsi_if_rx. + +During the loop if skb->len == nlh->nlmsg_len and both are sizeof(*nlh), +ev = nlmsg_data(nlh) will acutally get skb_shinfo(SKB) instead and set a +new value to skb_shinfo(SKB)->nr_frags by ev->type. + +This patch is to fix it by checking nlh->nlmsg_len properly there to +avoid over accessing sk_buff. + +Reported-by: ChunYu Wang +Signed-off-by: Xin Long +Acked-by: Chris Leech +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/scsi_transport_iscsi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/scsi/scsi_transport_iscsi.c ++++ b/drivers/scsi/scsi_transport_iscsi.c +@@ -3697,7 +3697,7 @@ iscsi_if_rx(struct sk_buff *skb) + uint32_t group; + + nlh = nlmsg_hdr(skb); +- if (nlh->nlmsg_len < sizeof(*nlh) || ++ if (nlh->nlmsg_len < sizeof(*nlh) + sizeof(*ev) || + skb->len < nlh->nlmsg_len) { + break; + } diff --git a/queue-4.4/series b/queue-4.4/series index b65120ccc7e..985397e53ed 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -1,2 +1,10 @@ cifs-release-auth_key.response-for-reconnect.patch mac80211-flush-hw_roc_start-work-before-cancelling-the-roc.patch +kvm-ppc-book3s-fix-race-and-leak-in-kvm_vm_ioctl_create_spapr_tce.patch +tracing-fix-trace_pipe-behavior-for-instance-traces.patch +tracing-erase-irqsoff-trace-with-empty-write.patch +md-raid5-fix-a-race-condition-in-stripe-batch.patch +md-raid5-preserve-stripe_on_unplug_list-in-break_stripe_batch_list.patch +scsi-scsi_transport_iscsi-fix-the-issue-that-iscsi_if_rx-doesn-t-parse-nlmsg-properly.patch +crypto-talitos-don-t-provide-setkey-for-non-hmac-hashing-algs.patch +crypto-talitos-fix-sha224.patch diff --git a/queue-4.4/tracing-erase-irqsoff-trace-with-empty-write.patch b/queue-4.4/tracing-erase-irqsoff-trace-with-empty-write.patch new file mode 100644 index 00000000000..316e2bfaa73 --- /dev/null +++ b/queue-4.4/tracing-erase-irqsoff-trace-with-empty-write.patch @@ -0,0 +1,51 @@ +From 8dd33bcb7050dd6f8c1432732f930932c9d3a33e Mon Sep 17 00:00:00 2001 +From: Bo Yan +Date: Mon, 18 Sep 2017 10:03:35 -0700 +Subject: tracing: Erase irqsoff trace with empty write + +From: Bo Yan + +commit 8dd33bcb7050dd6f8c1432732f930932c9d3a33e upstream. + +One convenient way to erase trace is "echo > trace". However, this +is currently broken if the current tracer is irqsoff tracer. This +is because irqsoff tracer use max_buffer as the default trace +buffer. + +Set the max_buffer as the one to be cleared when it's the trace +buffer currently in use. + +Link: http://lkml.kernel.org/r/1505754215-29411-1-git-send-email-byan@nvidia.com + +Cc: +Fixes: 4acd4d00f ("tracing: give easy way to clear trace buffer") +Signed-off-by: Bo Yan +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/trace.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -3226,11 +3226,17 @@ static int tracing_open(struct inode *in + /* If this file was open for write, then erase contents */ + if ((file->f_mode & FMODE_WRITE) && (file->f_flags & O_TRUNC)) { + int cpu = tracing_get_cpu(inode); ++ struct trace_buffer *trace_buf = &tr->trace_buffer; ++ ++#ifdef CONFIG_TRACER_MAX_TRACE ++ if (tr->current_trace->print_max) ++ trace_buf = &tr->max_buffer; ++#endif + + if (cpu == RING_BUFFER_ALL_CPUS) +- tracing_reset_online_cpus(&tr->trace_buffer); ++ tracing_reset_online_cpus(trace_buf); + else +- tracing_reset(&tr->trace_buffer, cpu); ++ tracing_reset(trace_buf, cpu); + } + + if (file->f_mode & FMODE_READ) { diff --git a/queue-4.4/tracing-fix-trace_pipe-behavior-for-instance-traces.patch b/queue-4.4/tracing-fix-trace_pipe-behavior-for-instance-traces.patch new file mode 100644 index 00000000000..e8ebbf97d06 --- /dev/null +++ b/queue-4.4/tracing-fix-trace_pipe-behavior-for-instance-traces.patch @@ -0,0 +1,46 @@ +From 75df6e688ccd517e339a7c422ef7ad73045b18a2 Mon Sep 17 00:00:00 2001 +From: Tahsin Erdogan +Date: Sun, 17 Sep 2017 03:23:48 -0700 +Subject: tracing: Fix trace_pipe behavior for instance traces + +From: Tahsin Erdogan + +commit 75df6e688ccd517e339a7c422ef7ad73045b18a2 upstream. + +When reading data from trace_pipe, tracing_wait_pipe() performs a +check to see if tracing has been turned off after some data was read. +Currently, this check always looks at global trace state, but it +should be checking the trace instance where trace_pipe is located at. + +Because of this bug, cat instances/i1/trace_pipe in the following +script will immediately exit instead of waiting for data: + +cd /sys/kernel/debug/tracing +echo 0 > tracing_on +mkdir -p instances/i1 +echo 1 > instances/i1/tracing_on +echo 1 > instances/i1/events/sched/sched_process_exec/enable +cat instances/i1/trace_pipe + +Link: http://lkml.kernel.org/r/20170917102348.1615-1-tahsin@google.com + +Fixes: 10246fa35d4f ("tracing: give easy way to clear trace buffer") +Signed-off-by: Tahsin Erdogan +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/trace.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -4701,7 +4701,7 @@ static int tracing_wait_pipe(struct file + * + * iter->pos will be 0 if we haven't read anything. + */ +- if (!tracing_is_on() && iter->pos) ++ if (!tracer_tracing_is_on(iter->tr) && iter->pos) + break; + + mutex_unlock(&iter->mutex); -- 2.47.3