From: Masami Hiramatsu <mhiramat(a)kernel.org>
Fix to allow user to enable probe events on unloaded modules.
This operations was allowed before commit 60d53e2c3b75 ("tracing/probe:
Split trace_event related data from trace_probe"), because if users
need to probe module init functions, they have to enable those probe
events before loading module.
Link: http://lkml.kernel.org/r/156879693733.31056.9331322616994665167.stgit@devno…
Cc: stable(a)vger.kernel.org
Fixes: 60d53e2c3b75 ("tracing/probe: Split trace_event related data from trace_probe")
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
kernel/trace/trace_kprobe.c | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 7579c53bb053..0ba3239c0270 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -371,31 +371,24 @@ static int enable_trace_kprobe(struct trace_event_call *call,
if (enabled)
return 0;
- enabled = false;
list_for_each_entry(pos, trace_probe_probe_list(tp), list) {
tk = container_of(pos, struct trace_kprobe, tp);
if (trace_kprobe_has_gone(tk))
continue;
ret = __enable_trace_kprobe(tk);
- if (ret) {
- if (enabled) {
- __disable_trace_kprobe(tp);
- enabled = false;
- }
+ if (ret)
break;
- }
enabled = true;
}
- if (!enabled) {
- /* No probe is enabled. Roll back */
+ if (ret) {
+ /* Failed to enable one of them. Roll back all */
+ if (enabled)
+ __disable_trace_kprobe(tp);
if (file)
trace_probe_remove_file(tp, file);
else
trace_probe_clear_flag(tp, TP_FLAG_PROFILE);
- if (!ret)
- /* Since all probes are gone, this is not available */
- ret = -EADDRNOTAVAIL;
}
return ret;
--
2.20.1
From: Tom Zanussi <zanussi(a)kernel.org>
Original changelog from Steve Rostedt (except last sentence which
explains the problem, and the Fixes: tag):
I performed a three way histogram with the following commands:
echo 'irq_lat u64 lat pid_t pid' > synthetic_events
echo 'wake_lat u64 lat u64 irqlat pid_t pid' >> synthetic_events
echo 'hist:keys=common_pid:irqts=common_timestamp.usecs if function == 0xffffffff81200580' > events/timer/hrtimer_start/trigger
echo 'hist:keys=common_pid:lat=common_timestamp.usecs-$irqts:onmatch(timer.hrtimer_start).irq_lat($lat,pid) if common_flags & 1' > events/sched/sched_waking/trigger
echo 'hist:keys=pid:wakets=common_timestamp.usecs,irqlat=lat' > events/synthetic/irq_lat/trigger
echo 'hist:keys=next_pid:lat=common_timestamp.usecs-$wakets,irqlat=$irqlat:onmatch(synthetic.irq_lat).wake_lat($lat,$irqlat,next_pid)' > events/sched/sched_switch/trigger
echo 1 > events/synthetic/wake_lat/enable
Basically I wanted to see:
hrtimer_start (calling function tick_sched_timer)
Note:
# grep tick_sched_timer /proc/kallsyms
ffffffff81200580 t tick_sched_timer
And save the time of that, and then record sched_waking if it is called
in interrupt context and with the same pid as the hrtimer_start, it
will record the latency between that and the waking event.
I then look at when the task that is woken is scheduled in, and record
the latency between the wakeup and the task running.
At the end, the wake_lat synthetic event will show the wakeup to
scheduled latency, as well as the irq latency in from hritmer_start to
the wakeup. The problem is that I found this:
<idle>-0 [007] d... 190.485261: wake_lat: lat=27 irqlat=190485230 pid=698
<idle>-0 [005] d... 190.485283: wake_lat: lat=40 irqlat=190485239 pid=10
<idle>-0 [002] d... 190.488327: wake_lat: lat=56 irqlat=190488266 pid=335
<idle>-0 [005] d... 190.489330: wake_lat: lat=64 irqlat=190489262 pid=10
<idle>-0 [003] d... 190.490312: wake_lat: lat=43 irqlat=190490265 pid=77
<idle>-0 [005] d... 190.493322: wake_lat: lat=54 irqlat=190493262 pid=10
<idle>-0 [005] d... 190.497305: wake_lat: lat=35 irqlat=190497267 pid=10
<idle>-0 [005] d... 190.501319: wake_lat: lat=50 irqlat=190501264 pid=10
The irqlat seemed quite large! Investigating this further, if I had
enabled the irq_lat synthetic event, I noticed this:
<idle>-0 [002] d.s. 249.429308: irq_lat: lat=164968 pid=335
<idle>-0 [002] d... 249.429369: wake_lat: lat=55 irqlat=249429308 pid=335
Notice that the timestamp of the irq_lat "249.429308" is awfully
similar to the reported irqlat variable. In fact, all instances were
like this. It appeared that:
irqlat=$irqlat
Wasn't assigning the old $irqlat to the new irqlat variable, but
instead was assigning the $irqts to it.
The issue is that assigning the old $irqlat to the new irqlat variable
creates a variable reference alias, but the alias creation code
forgets to make sure the alias uses the same var_ref_idx to access the
reference.
Link: http://lkml.kernel.org/r/1567375321.5282.12.camel@kernel.org
Cc: Linux Trace Devel <linux-trace-devel(a)vger.kernel.org>
Cc: linux-rt-users <linux-rt-users(a)vger.kernel.org>
Cc: stable(a)vger.kernel.org
Fixes: 7e8b88a30b085 ("tracing: Add hist trigger support for variable reference aliases")
Reported-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Tom Zanussi <zanussi(a)kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
kernel/trace/trace_events_hist.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 3a6e42aa08e6..9468bd8d44a2 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -2804,6 +2804,8 @@ static struct hist_field *create_alias(struct hist_trigger_data *hist_data,
return NULL;
}
+ alias->var_ref_idx = var_ref->var_ref_idx;
+
return alias;
}
--
2.20.1
The patch titled
Subject: lib/lzo/lzo1x_compress.c: fix alignment bug in lzo-rle
has been added to the -mm tree. Its filename is
lib-lzo-fix-alignment-bug-in-lzo-rle.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/lib-lzo-fix-alignment-bug-in-lzo-r…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/lib-lzo-fix-alignment-bug-in-lzo-r…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Dave Rodgman <dave.rodgman(a)arm.com>
Subject: lib/lzo/lzo1x_compress.c: fix alignment bug in lzo-rle
Fix an unaligned access which breaks on platforms where this is not
permitted (e.g., Sparc).
Link: http://lkml.kernel.org/r/20190912145502.35229-1-dave.rodgman@arm.com
Signed-off-by: Dave Rodgman <dave.rodgman(a)arm.com>
Cc: Dave Rodgman <dave.rodgman(a)arm.com>
Cc: Markus F.X.J. Oberhumer <markus(a)oberhumer.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
lib/lzo/lzo1x_compress.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
--- a/lib/lzo/lzo1x_compress.c~lib-lzo-fix-alignment-bug-in-lzo-rle
+++ a/lib/lzo/lzo1x_compress.c
@@ -83,17 +83,19 @@ next:
ALIGN((uintptr_t)ir, 4)) &&
(ir < limit) && (*ir == 0))
ir++;
- for (; (ir + 4) <= limit; ir += 4) {
- dv = *((u32 *)ir);
- if (dv) {
+ if (IS_ALIGNED((uintptr_t)ir, 4)) {
+ for (; (ir + 4) <= limit; ir += 4) {
+ dv = *((u32 *)ir);
+ if (dv) {
# if defined(__LITTLE_ENDIAN)
- ir += __builtin_ctz(dv) >> 3;
+ ir += __builtin_ctz(dv) >> 3;
# elif defined(__BIG_ENDIAN)
- ir += __builtin_clz(dv) >> 3;
+ ir += __builtin_clz(dv) >> 3;
# else
# error "missing endian definition"
# endif
- break;
+ break;
+ }
}
}
#endif
_
Patches currently in -mm which might be from dave.rodgman(a)arm.com are
lib-lzo-fix-alignment-bug-in-lzo-rle.patch
When devm_thermal_zone_of_sensor_register() is called from
hwmon_thermal_add_sensor() it is possible that the relevant sensor is
missing an OF node. In this case thermal_zone_of_sensor_register() returns
-EINVAL which causes hwmon_thermal_add_sensor() to fail as well. This patch
changes relevant return code of thermal_zone_of_sensor_register() to
-ENODEV, which is tolerated by hwmon_thermal_add_sensor().
Here is a particular case of such behaviour: the Marvell ethernet PHYs
driver registers hwmon device for the built-in temperature sensor (see
drivers/net/phy/marvell.c). Since the sensor doesn't have associated OF
node devm_hwmon_device_register() returns error which ultimately causes
failure of the PHY driver's probe function.
Fixes: 4e5e4705bf69 ("thermal: introduce device tree parser")
Signed-off-by: Peter Mamonov <pmamonov(a)gmail.com>
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Cc: stable(a)vger.kernel.org
---
drivers/thermal/of-thermal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index dc5093be553e..34b0cc173f4a 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -493,7 +493,7 @@ thermal_zone_of_sensor_register(struct device *dev, int sensor_id, void *data,
if (!dev || !dev->of_node) {
of_node_put(np);
- return ERR_PTR(-EINVAL);
+ return ERR_PTR(-ENODEV);
}
sensor_np = of_node_get(dev->of_node);
--
2.23.0
Hi Stable team,
Can we please backport dc8635b78cd8669c37e230058d18c33af7451ab1 ("kernel/exit.c:
export abort() to modules")
0-Day kernel test infra reports ARC 4.x.y builds failing after backport of
af1be2e21203867cb958aace ("ARC: handle gcc generated __builtin_trap for older
compiler")
Thx
-Vineet
The above referenced commit has problems on older non-rbTree kernels.
AFAICS, the commit has only been backported to 4.14 up to now, but the
commit that fdfc5c8594c2 is fixing (namely ce5ec440994b ("tcp: ensure epoll
edge trigger wakeup when write queue is empty"), is in v4.2.
Christoph Paasch (2):
tcp: Reset send_head when removing skb from write-queue
tcp: Don't dequeue SYN/FIN-segments from write-queue
net/ipv4/tcp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.21.0
Hello,
We ran automated tests on a patchset that was proposed for merging into this
kernel tree. The patches were applied to:
Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Commit: 1e2ba4a74fa7 - Linux 5.2.16
The results of these automated tests are provided below.
Overall result: PASSED
Merge: OK
Compile: OK
Tests: OK
All kernel binaries, config files, and logs are available for download here:
https://artifacts.cki-project.org/pipelines/174825
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
Merge testing
-------------
We cloned this repository and checked out the following commit:
Repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Commit: 1e2ba4a74fa7 - Linux 5.2.16
We grabbed the 2c7c18b99299 commit of the stable queue repository.
We then merged the patchset with `git am`:
usb-usbcore-fix-slab-out-of-bounds-bug-during-device-reset.patch
media-tm6000-double-free-if-usb-disconnect-while-streaming.patch
phy-renesas-rcar-gen3-usb2-disable-clearing-vbus-in-over-current.patch
net-hns3-adjust-hns3_uninit_phy-s-location-in-the-hns3_client_uninit.patch
netfilter-nf_flow_table-set-default-timeout-after-successful-insertion.patch
hid-wacom-generic-read-hid_dg_contactmax-from-any-feature-report.patch
input-elan_i2c-remove-lenovo-legion-y7000-pnpid.patch
sunrpc-handle-connection-breakages-correctly-in-call_status.patch
media-stm32-dcmi-fix-irq-0-case.patch
nfs-disable-client-side-deduplication.patch
powerpc-mm-radix-use-the-right-page-size-for-vmemmap-mapping.patch
scripts-decode_stacktrace-match-basepath-using-shell-prefix-operator-not-regex.patch
net-hns-fix-led-configuration-for-marvell-phy.patch
net-aquantia-fix-limit-of-vlan-filters.patch
ip6_gre-fix-a-dst-leak-in-ip6erspan_tunnel_xmit.patch
net-sched-fix-race-between-deactivation-and-dequeue-for-nolock-qdisc.patch
net_sched-let-qdisc_put-accept-null-pointer.patch
udp-correct-reuseport-selection-with-connected-sockets.patch
xen-netfront-do-not-assume-sk_buff_head-list-is-empty-in-error-handling.patch
net-dsa-fix-load-order-between-dsa-drivers-and-taggers.patch
kvm-coalesced_mmio-add-bounds-checking.patch
firmware-google-check-if-size-is-valid-when-decoding-vpd-data.patch
serial-sprd-correct-the-wrong-sequence-of-arguments.patch
tty-serial-atmel-reschedule-tx-after-rx-was-started.patch
mwifiex-fix-three-heap-overflow-at-parsing-element-in-cfg80211_ap_settings.patch
nl80211-fix-possible-spectre-v1-for-cqm-rssi-thresholds.patch
Compile testing
---------------
We compiled the kernel for 3 architectures:
aarch64:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
ppc64le:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
x86_64:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
Hardware testing
----------------
We booted each kernel and ran the following tests:
aarch64:
⚡ Internal infrastructure issues prevented one or more tests (marked
with ⚡⚡⚡) from running on this architecture.
This is not the fault of the kernel that was tested.
ppc64le:
⚡ Internal infrastructure issues prevented one or more tests (marked
with ⚡⚡⚡) from running on this architecture.
This is not the fault of the kernel that was tested.
x86_64:
⚡ Internal infrastructure issues prevented one or more tests (marked
with ⚡⚡⚡) from running on this architecture.
This is not the fault of the kernel that was tested.
Test sources: https://github.com/CKI-project/tests-beaker
💚 Pull requests are welcome for new tests or improvements to existing tests!
Waived tests
------------
If the test run included waived tests, they are marked with 🚧. Such tests are
executed but their results are not taken into account. Tests are waived when
their results are not reliable enough, e.g. when they're just introduced or are
being fixed.
Hi,
Please include the following patch in 4.14 and 4.19, where it applies
cleanly and has been tested by us.
commit bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 upstream
("binfmt_elf: move brk out of mmap when doing direct loader exec")
Thanks,
- Frank