- Linux-stable-mirror - lists.linaro.org

[PATCH 0/3] scsi:ufs: Fix failure to read the string descriptor.

by Li Wei

This patch fix failure to read the string descriptor. In kernel v4.9.100,we encountered the following error info: [3.141326] ufshcd-hi3660 ff3b0000.ufs: ufshcd_read_desc_param: Failed reading descriptor. desc_id 0 param_offset 0 buff_len 31 ret 0 [3.141331] ufshcd-hi3660 ff3b0000.ufs: ufs_get_device_info: Failed reading Device Desc. err = -22 [3.141336] ufshcd-hi3660 ff3b0000.ufs: ufs_advertise_fixup_device: Failed getting device info. err = -22 [3.145923] ufs final power mode: gear = 3, lane = 2, pwr = 1, rate = 2 [3.145927] ufshcd-hi3660 ff3b0000.ufs: set TX_EQUALIZER 3.5db [3.157229] ufshcd-hi3660 ff3b0000.ufs: check TX_EQUALIZER DB value lane0 = 0x1 [3.157716] ufshcd-hi3660 ff3b0000.ufs: check TX_EQUALIZER DB value lane1 = 0x1 [3.190446] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.227484] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.263496] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.299509] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.335528] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.371501] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.407493] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.443501] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.479491] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 If failed to read device desc, card_data->wmanufacturerid and card_data->model will not get the correct value, meaning that hba->dev_quirks will no longer work. And some ufs device's quirks handling will even cause ufs can't work. In fact, our hikey960 board using Hynix ufs device failed to initialize on v4.9 because a quirk of the hynix device was not handled. We test with hikey960 & hikey970 boards in aosp-master hikey-linaro-4.9 (v4.9.100), this patch can solve the above problem perfectly. [3.223550] ufs final power mode: gear = 3, lane = 2, pwr = 1, rate = 2 [3.223565] ufshcd-hi3660 ff3b0000.ufs: set TX_EQUALIZER 3.5db [3.223609] ufs flash device must set VS_DebugSaveConfigTime 0x10 [3.226218] ufshcd-hi3660 ff3b0000.ufs: check TX_EQUALIZER DB value lane0 = 0x1 [3.226247] ufshcd-hi3660 ff3b0000.ufs: check TX_EQUALIZER DB value lane1 = 0x1 [3.226400] ufshcd-hi3660 ff3b0000.ufs: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0 [3.232847] scsi 0:0:0:49488: Well-known LUN SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.321453] scsi 0:0:0:49456: Well-known LUN SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.383820] scsi 0:0:0:49476: Well-known LUN SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.447615] scsi 0:0:0:0: Direct-Access SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.503504] sd 0:0:0:0: [sda] 1024 4096-byte logical blocks: (4.19 MB/4.00 MiB) [3.503863] sd 0:0:0:0: [sda] Write Protect is off [3.503867] sd 0:0:0:0: [sda] Mode Sense: 00 32 00 10 [3.503963] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [3.504017] scsi 0:0:0:1: Direct-Access SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.505615] sd 0:0:0:0: [sda] Attached SCSI disk [3.547425] sd 0:0:0:1: [sdb] 1024 4096-byte logical blocks: (4.19 MB/4.00 MiB) [3.547768] scsi 0:0:0:2: Direct-Access SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.548003] sd 0:0:0:1: [sdb] Write Protect is off [3.548005] sd 0:0:0:1: [sdb] Mode Sense: 00 32 00 10 [3.548428] sd 0:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA [3.553383] sd 0:0:0:1: [sdb] Attached SCSI disk [3.591547] sd 0:0:0:2: [sdc] 2048 4096-byte logical blocks: (8.39 MB/8.00 MiB) [3.592056] scsi 0:0:0:3: Direct-Access SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.593336] sd 0:0:0:2: [sdc] Write Protect is off [3.593340] sd 0:0:0:2: [sdc] Mode Sense: 00 32 00 10 [3.593638] sd 0:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA [3.596473] Alternate GPT is invalid, using primary GPT. [3.596480] sdc: sdc1 [3.597069] random: fast init done [3.597168] sd 0:0:0:2: [sdc] Attached SCSI disk [3.644460] sd 0:0:0:3: [sdd] 7805952 4096-byte logical blocks: (32.0 GB/29.8 GiB) [3.644867] sd 0:0:0:3: [sdd] Write Protect is off [3.644869] sd 0:0:0:3: [sdd] Mode Sense: 00 32 00 10 [3.644992] sd 0:0:0:3: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA [3.646506] Alternate GPT is invalid, using primary GPT. [3.646518] sdd: sdd1 sdd2 sdd3 sdd4 sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 sdd11 sdd12 sdd13 [3.647956] sd 0:0:0:3: [sdd] Attached SCSI disk We hope merge this patch to 4.9-stable to avoid other similar problems. Potomski, MichalX (1): scsi: ufs: Factor out ufshcd_read_desc_param Tomas Winkler (1): scsi: ufs: refactor device descriptor reading subhashj(a)codeaurora.org (1): scsi: ufs: fix failure to read the string descriptor drivers/scsi/ufs/ufs.h | 34 +++--- drivers/scsi/ufs/ufs_quirks.h | 28 +---- drivers/scsi/ufs/ufshcd.c | 272 +++++++++++++++++++++++++++++++----------- drivers/scsi/ufs/ufshcd.h | 16 +++ 4 files changed, 246 insertions(+), 104 deletions(-) -- 2.15.0

7 years, 5 months

2
4
0 0

[PATCH 0/2] 4.14 long term stable ZBC fixes

by Damien Le Moal

Patch 0aa3fdb8b3a6 ("scsi: sd_zbc: Fix potential memory leak") was added in 4.16 and 4.15 stable but did not make it to long term stable 4.14 (as far as I can tell). Patch ccce20fc7968 ("scsi: sd_zbc: Avoid that resetting a zone fails sporadically") is included in 4.16 but does not apply to 4.15 stable nor to 4.14 long term stable and requires extensive modifications. This small series provides a backport of both patches against 4.14. Please consider these patches for inclusion in this long term stable kernel. Bart Van Assche (1): scsi: sd_zbc: Avoid that resetting a zone fails sporadically Damien Le Moal (1): scsi: sd_zbc: Fix potential memory leak drivers/scsi/sd_zbc.c | 128 +++++++++++++++++++++++++----------------- 1 file changed, 76 insertions(+), 52 deletions(-) -- 2.17.0

7 years, 5 months

2
3
0 0

[PATCH ] dmaengine: usb-dmac: fix endless loop in usb_dmac_chan_terminate_all()

by Biju Das

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> commit d9f5efade2cfd729138a7cafb46d01044da40f5e upstream This patch fixes an issue that list_for_each_entry() in usb_dmac_chan_terminate_all() is possible to cause endless loop because this will move own desc to the desc_freed. So, this driver should use list_for_each_entry_safe() instead of list_for_each_entry(). Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> [biju: cherry-pick to 4.4] Signed-off-by: Biju Das <biju.das(a)bp.renesas.com> --- Hello Greg, I have observed a CPU lock condition with USB DMAC driver on koelsch platform. This patch fixes the issue on 4.4 stable. It is reproducible with ethernet(RNDIS/ECM) gadget configuration. regards, Biju drivers/dma/sh/usb-dmac.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c index 56410ea..6682b3e 100644 --- a/drivers/dma/sh/usb-dmac.c +++ b/drivers/dma/sh/usb-dmac.c @@ -448,7 +448,7 @@ usb_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl, static int usb_dmac_chan_terminate_all(struct dma_chan *chan) { struct usb_dmac_chan *uchan = to_usb_dmac_chan(chan); - struct usb_dmac_desc *desc; + struct usb_dmac_desc *desc, *_desc; unsigned long flags; LIST_HEAD(head); LIST_HEAD(list); @@ -459,7 +459,7 @@ static int usb_dmac_chan_terminate_all(struct dma_chan *chan) if (uchan->desc) uchan->desc = NULL; list_splice_init(&uchan->desc_got, &list); - list_for_each_entry(desc, &list, node) + list_for_each_entry_safe(desc, _desc, &list, node) list_move_tail(&desc->node, &uchan->desc_freed); spin_unlock_irqrestore(&uchan->vc.lock, flags); vchan_dma_desc_free_list(&uchan->vc, &head); -- 2.7.4

7 years, 5 months

2
1
0 0

[PATCH 0/3] Fix double address byte issue

by Fabrizio Castro

Hello Greg, Wolfram recommends the backporting of this series in order to improve the situation with a race condition. Do you think you can take this series for 4.4 stable? This series applies on 4.4.133, and depends on series: "Fix R-Car I2C data byte sent twice issue" Thanks, Fab Wolfram Sang (3): i2c: rcar: don't issue stop when HW does it automatically i2c: rcar: check master irqs before slave irqs i2c: rcar: revoke START request early drivers/i2c/busses/i2c-rcar.c | 36 ++++++++++++------------------------ 1 file changed, 12 insertions(+), 24 deletions(-) -- 2.7.4

7 years, 5 months

2
4
0 0

[PATCH 0/6] Fix R-Car I2C data byte sent twice issue

by Fabrizio Castro

Hello Greg, this series fixes an issue with the I2C driver of the Renesas R-Car and RZ/G1 family of chips. The issue is clearly visible with the CIP kernel (4.4) running on a iwg20d board from iWave due to the way the bq32000 driver/device is interacting with the I2C driver/controller. In the stable kernel (4.4) there is no support for the iwg20d, I tried to replicate the same problem on a Koelsch board with no success, but the problem is there. Do you think this series is suitable for (4.4) stable considering I can't reproduce the problem on the Koelsch board? This patches apply on top of 4.4.133. Thanks, Fab Wolfram Sang (6): i2c: rcar: make sure clocks are on when doing clock calculation i2c: rcar: rework hw init i2c: rcar: remove unused IOERROR state i2c: rcar: remove spinlock i2c: rcar: refactor setup of a msg i2c: rcar: init new messages in irq drivers/i2c/busses/i2c-rcar.c | 166 ++++++++++++++++++------------------------ 1 file changed, 72 insertions(+), 94 deletions(-) -- 2.7.4

7 years, 5 months

3
12
0 0

[PATCH v4.4.y..v4.14.y] tcp: avoid integer overflows in tcp_rcv_space_adjust()

by Guenter Roeck

From: Eric Dumazet <edumazet(a)google.com> commit 607065bad9931e72207b0cac365d7d4abc06bd99 upstream. When using large tcp_rmem[2] values (I did tests with 500 MB), I noticed overflows while computing rcvwin. Lets fix this before the following patch. Signed-off-by: Eric Dumazet <edumazet(a)google.com> Acked-by: Soheil Hassas Yeganeh <soheil(a)google.com> Acked-by: Wei Wang <weiwan(a)google.com> Acked-by: Neal Cardwell <ncardwell(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> [Backport: sysctl_tcp_rmem is not Namespace-ify'd in older kernels] Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> --- Applies cleanly to v4.4.y and v4.9.y; v4.14.y needs "git am -3". include/linux/tcp.h | 2 +- net/ipv4/tcp_input.c | 10 ++++++---- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/include/linux/tcp.h b/include/linux/tcp.h index 2260f92f1492..5b6df1a8dc74 100644 --- a/include/linux/tcp.h +++ b/include/linux/tcp.h @@ -324,7 +324,7 @@ struct tcp_sock { /* Receiver queue space */ struct { - int space; + u32 space; u32 seq; u32 time; } rcvq_space; diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index ed018760502e..23b95aead897 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -557,8 +557,8 @@ static inline void tcp_rcv_rtt_measure_ts(struct sock *sk, void tcp_rcv_space_adjust(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); + u32 copied; int time; - int copied; time = tcp_time_stamp - tp->rcvq_space.time; if (time < (tp->rcv_rtt_est.rtt >> 3) || tp->rcv_rtt_est.rtt == 0) @@ -580,12 +580,13 @@ void tcp_rcv_space_adjust(struct sock *sk) if (sysctl_tcp_moderate_rcvbuf && !(sk->sk_userlocks & SOCK_RCVBUF_LOCK)) { - int rcvwin, rcvmem, rcvbuf; + int rcvmem, rcvbuf; + u64 rcvwin; /* minimal window to cope with packet losses, assuming * steady state. Add some cushion because of small variations. */ - rcvwin = (copied << 1) + 16 * tp->advmss; + rcvwin = ((u64)copied << 1) + 16 * tp->advmss; /* If rate increased by 25%, * assume slow start, rcvwin = 3 * copied @@ -605,7 +606,8 @@ void tcp_rcv_space_adjust(struct sock *sk) while (tcp_win_from_space(rcvmem) < tp->advmss) rcvmem += 128; - rcvbuf = min(rcvwin / tp->advmss * rcvmem, sysctl_tcp_rmem[2]); + do_div(rcvwin, tp->advmss); + rcvbuf = min_t(u64, rcvwin * rcvmem, sysctl_tcp_rmem[2]); if (rcvbuf > sk->sk_rcvbuf) { sk->sk_rcvbuf = rcvbuf; -- 2.7.4

7 years, 5 months

2
1
0 0

[PATCH 0/3] Correct 4.9 stable commit 944e0fc51a89c98

by Juergen Gross

Above commit is a wrong backport, as it is based on a missing prerequisite patch. Correct that by reverting said commit, include the missing patch, and do the backport correctly. Juergen Gross (3): x86/amd: revert commit 944e0fc51a89c9827b98813d65dc083274777c7f xen: set cpu capabilities from xen_start_kernel() x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen arch/x86/xen/enlighten.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) -- 2.13.6

7 years, 5 months

2
4
0 0

stable release patches (gcc, clang)

by Guenter Roeck

Hi Greg, the following are some more patches for stable releases. I collected the following clang patches from chromeos-4.14. They are not really needed to build x86_64:defconfig in v4.14.y with clang (5.0), but they do fix a couple of build warnings if the respective drivers are enabled. I'll leave it up to you if you want to apply them or not. I did make sure that defconfig and allmodconfig still build using gcc with the patches applied. df16aaac26e9 kbuild: clang: remove crufty HOSTCFLAGS cad9946c2a43 drm/i915: Always sanity check engine state upon idling 531beb067c61 dma-buf: remove redundant initialization of sg_table 42b5122e828a drm/amd/powerplay: Fix enum mismatch fb239c1209bb rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c 271ef65b5882 ASoC: Intel: sst: remove redundant variable dma_dev_name d3b56c566d4b platform/chrome: cros_ec_lpc: remove redundant pointer request 0a5f41767444 kbuild: clang: disable unused variable warnings The following patch is needed in v4.4.y to be able to build arm:footbridge_defconfig with gcc 7.3.0. c9bd28233b6d irda: fix overly long udelay() Thanks, Guenter

7 years, 5 months

2
1
0 0

[patch 1/2] mm/huge_memory.c: __split_huge_page() use atomic ClearPageDirty()

by akpm＠linux-foundation.org

From: Hugh Dickins <hughd(a)google.com> Subject: mm/huge_memory.c: __split_huge_page() use atomic ClearPageDirty() Swapping load on huge=always tmpfs (with khugepaged tuned up to be very eager, but I'm not sure that is relevant) soon hung uninterruptibly, waiting for page lock in shmem_getpage_gfp()'s find_lock_entry(), most often when "cp -a" was trying to write to a smallish file. Debug showed that the page in question was not locked, and page->mapping NULL by now, but page->index consistent with having been in a huge page before. Reproduced in minutes on a 4.15 kernel, even with 4.17's 605ca5ede764 ("mm/huge_memory.c: reorder operations in __split_huge_page_tail()") added in; but took hours to reproduce on a 4.17 kernel (no idea why). The culprit proved to be the __ClearPageDirty() on tails beyond i_size in __split_huge_page(): the non-atomic __bitoperation may have been safe when 4.8's baa355fd3314 ("thp: file pages support for split_huge_page()") introduced it, but liable to erase PageWaiters after 4.10's 62906027091f ("mm: add PageWaiters indicating tasks are waiting for a page bit"). Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1805291841070.3197@eggly.anvils Fixes: 62906027091f ("mm: add PageWaiters indicating tasks are waiting for a page bit") Signed-off-by: Hugh Dickins <hughd(a)google.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru> Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/huge_memory.c~mm-huge_memoryc-__split_huge_page-use-atomic-clearpagedirty mm/huge_memory.c --- a/mm/huge_memory.c~mm-huge_memoryc-__split_huge_page-use-atomic-clearpagedirty +++ a/mm/huge_memory.c @@ -2431,7 +2431,7 @@ static void __split_huge_page(struct pag __split_huge_page_tail(head, i, lruvec, list); /* Some pages can be beyond i_size: drop them from page cache */ if (head[i].index >= end) { - __ClearPageDirty(head + i); + ClearPageDirty(head + i); __delete_from_page_cache(head + i, NULL); if (IS_ENABLED(CONFIG_SHMEM) && PageSwapBacked(head)) shmem_uncharge(head->mapping->host, 1); _

7 years, 5 months

1
0
0 0

FAILED: patch "[PATCH] tracing: Make the snapshot trigger work with instances" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2824f5033248600673e3e126a4d135363cbfd9ac Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> Date: Mon, 28 May 2018 10:56:36 -0400 Subject: [PATCH] tracing: Make the snapshot trigger work with instances The snapshot trigger currently only affects the main ring buffer, even when it is used by the instances. This can be confusing as the snapshot trigger is listed in the instance. > # cd /sys/kernel/tracing > # mkdir instances/foo > # echo snapshot > instances/foo/events/syscalls/sys_enter_fchownat/trigger > # echo top buffer > trace_marker > # echo foo buffer > instances/foo/trace_marker > # touch /tmp/bar > # chown rostedt /tmp/bar > # cat instances/foo/snapshot # tracer: nop # # # * Snapshot is freed * # # Snapshot commands: # echo 0 > snapshot : Clears and frees snapshot buffer # echo 1 > snapshot : Allocates snapshot buffer, if not already allocated. # Takes a snapshot of the main buffer. # echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free) # (Doesn't have to be '2' works with any number that # is not a '0' or '1') > # cat snapshot # tracer: nop # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | bash-1189 [000] .... 111.488323: tracing_mark_write: top buffer Not only did the snapshot occur in the top level buffer, but the instance snapshot buffer should have been allocated, and it is still free. Cc: stable(a)vger.kernel.org Fixes: 85f2b08268c01 ("tracing: Add basic event trigger framework") Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 414d7210b2ec..bcd93031d042 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -893,7 +893,7 @@ int __trace_bputs(unsigned long ip, const char *str) EXPORT_SYMBOL_GPL(__trace_bputs); #ifdef CONFIG_TRACER_SNAPSHOT -static void tracing_snapshot_instance(struct trace_array *tr) +void tracing_snapshot_instance(struct trace_array *tr) { struct tracer *tracer = tr->current_trace; unsigned long flags; @@ -949,7 +949,7 @@ static int resize_buffer_duplicate_size(struct trace_buffer *trace_buf, struct trace_buffer *size_buf, int cpu_id); static void set_buffer_entries(struct trace_buffer *buf, unsigned long val); -static int alloc_snapshot(struct trace_array *tr) +int tracing_alloc_snapshot_instance(struct trace_array *tr) { int ret; @@ -995,7 +995,7 @@ int tracing_alloc_snapshot(void) struct trace_array *tr = &global_trace; int ret; - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); WARN_ON(ret < 0); return ret; @@ -5408,7 +5408,7 @@ static int tracing_set_tracer(struct trace_array *tr, const char *buf) #ifdef CONFIG_TRACER_MAX_TRACE if (t->use_max_tr && !had_max_tr) { - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); if (ret < 0) goto out; } @@ -6451,7 +6451,7 @@ tracing_snapshot_write(struct file *filp, const char __user *ubuf, size_t cnt, } #endif if (!tr->allocated_snapshot) { - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); if (ret < 0) break; } @@ -7179,7 +7179,7 @@ ftrace_trace_snapshot_callback(struct trace_array *tr, struct ftrace_hash *hash, return ret; out_reg: - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); if (ret < 0) goto out; diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h index 6fb46a06c9dc..507954b4e058 100644 --- a/kernel/trace/trace.h +++ b/kernel/trace/trace.h @@ -1817,6 +1817,17 @@ static inline void __init trace_event_init(void) { } static inline void trace_event_eval_update(struct trace_eval_map **map, int len) { } #endif +#ifdef CONFIG_TRACER_SNAPSHOT +void tracing_snapshot_instance(struct trace_array *tr); +int tracing_alloc_snapshot_instance(struct trace_array *tr); +#else +static inline void tracing_snapshot_instance(struct trace_array *tr) { } +static inline int tracing_alloc_snapshot_instance(struct trace_array *tr) +{ + return 0; +} +#endif + extern struct trace_iterator *tracepoint_print_iter; #endif /* _LINUX_KERNEL_TRACE_H */ diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c index 9be317d388c5..8b5bdcf64871 100644 --- a/kernel/trace/trace_events_trigger.c +++ b/kernel/trace/trace_events_trigger.c @@ -643,6 +643,7 @@ event_trigger_callback(struct event_command *cmd_ops, trigger_data->count = -1; trigger_data->ops = trigger_ops; trigger_data->cmd_ops = cmd_ops; + trigger_data->private_data = file; INIT_LIST_HEAD(&trigger_data->list); INIT_LIST_HEAD(&trigger_data->named_list); @@ -1054,7 +1055,12 @@ static void snapshot_trigger(struct event_trigger_data *data, void *rec, struct ring_buffer_event *event) { - tracing_snapshot(); + struct trace_event_file *file = data->private_data; + + if (file) + tracing_snapshot_instance(file->tr); + else + tracing_snapshot(); } static void @@ -1077,7 +1083,7 @@ register_snapshot_trigger(char *glob, struct event_trigger_ops *ops, { int ret = register_trigger(glob, ops, data, file); - if (ret > 0 && tracing_alloc_snapshot() != 0) { + if (ret > 0 && tracing_alloc_snapshot_instance(file->tr) != 0) { unregister_trigger(glob, ops, data, file); ret = 0; }

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror