Re: [kernel-hardening] Re: [PATCH v3] scripts: add leaking_addresses.pl
./leaking_addresses.pl --dont_walk_abs /proc --dont_walk_abs /sys Unknown option: dont_walk_abs Unknown option: dont_walk_abs 06.11.2017 20:27, Linus Torvalds пишет: > David - you can see the patch on patchwork: > > https://patchwork.kernel.org/patch/10042605/ > > and try it out yourself. >
Re: [kernel-hardening] Re: [PATCH v3] scripts: add leaking_addresses.pl
./leaking_addresses.pl --dont_walk_abs /proc --dont_walk_abs /sys Unknown option: dont_walk_abs Unknown option: dont_walk_abs 06.11.2017 20:27, Linus Torvalds пишет: > David - you can see the patch on patchwork: > > https://patchwork.kernel.org/patch/10042605/ > > and try it out yourself. >
Re: [ANNOUNCE] 4.0.4-rt1
09.06.2015 19:45, Fernando Lopez-Lezcano пишет: This is still happening, about once a day. John Dulaney help me set up a crash kernel dump (thanks!) so now I have a kernel core dump for this one, Asus,Fedora,CGROUPS, iptables,snd_ac97,radeon,raid1,kvm - this realtime system? :D -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 4.0.4-rt1
09.06.2015 19:45, Fernando Lopez-Lezcano пишет: This is still happening, about once a day. John Dulaney help me set up a crash kernel dump (thanks!) so now I have a kernel core dump for this one, Asus,Fedora,CGROUPS, iptables,snd_ac97,radeon,raid1,kvm - this realtime system? :D -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 4.0.4-rt1
09.06.2015 19:45, Fernando Lopez-Lezcano пишет: This is still happening, about once a day. John Dulaney help me set up a crash kernel dump (thanks!) so now I have a kernel core dump for this one, Asus,Fedora,CGROUPS, iptables,snd_ac97,radeon,raid1,kvm - this realtime system? :D -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 4.0.4-rt1
09.06.2015 19:45, Fernando Lopez-Lezcano пишет: This is still happening, about once a day. John Dulaney help me set up a crash kernel dump (thanks!) so now I have a kernel core dump for this one, Asus,Fedora,CGROUPS, iptables,snd_ac97,radeon,raid1,kvm - this realtime system? :D -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 4.0.4-rt1
20.05.2015 00:39, Sebastian Andrzej Siewior пишет:
Dear RT folks!
I'm pleased to announce the v4.0.4-rt1 patch set.
Guys, 4.0.4-rt1 freezing after
# sysctl -w vm.drop_caches=3 && memhog `free -k | grep Mem | awk '{print
$4"k"}'` 2>&1 >/dev/null;
- CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL
- Debian 8
- Nvidia blob 346.47 (GeForce GT 740)
- Google Chrome 43.0.2357.65 (64-bit)
--
Pavel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 4.0.4-rt1
20.05.2015 00:39, Sebastian Andrzej Siewior пишет:
Dear RT folks!
I'm pleased to announce the v4.0.4-rt1 patch set.
Guys, 4.0.4-rt1 freezing after
# sysctl -w vm.drop_caches=3 memhog `free -k | grep Mem | awk '{print
$4k}'` 21 /dev/null;
- CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL
- Debian 8
- Nvidia blob 346.47 (GeForce GT 740)
- Google Chrome 43.0.2357.65 (64-bit)
--
Pavel.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 4.0.4-rt1
20.05.2015 00:39, Sebastian Andrzej Siewior пишет: Dear RT folks! I'm pleased to announce the v4.0.4-rt1 patch set. While work stable. \m/ TYAN S8225 2 x AMD Opteron(tm) Processor 4386 16Gb DDR3 ECC Reg. Nvidia GeForce GT740 (blob driver) CONFIG_NO_HZ_COMMON=y CONFIG_NO_HZ_FULL=y CONFIG_NO_HZ_FULL_ALL=y ... # cyclictest -S -c 1 -m -p 99 --latency=0 --policy=fifo # /dev/cpu_dma_latency set to 0us WARN: Running on unknown kernel version...YMMV policy: fifo: loadavg: 1.57 1.70 1.55 1/557 19347 T: 0 (18369) P:99 I:1000 C: 26617 Min: 6 Act: 13 Avg: 12 Max:1614 T: 1 (18370) P:99 I:1500 C: 17742 Min: 6 Act: 18 Avg: 19 Max:1700 T: 2 (18371) P:99 I:2000 C: 13304 Min: 8 Act: 19 Avg: 20 Max:1620 T: 3 (18372) P:99 I:2500 C: 10642 Min: 6 Act: 16 Avg: 17 Max: 73 T: 4 (18373) P:99 I:3000 C: 8867 Min: 8 Act: 20 Avg: 20 Max:1497 T: 5 (18374) P:99 I:3500 C: 7599 Min: 8 Act: 20 Avg: 20 Max: 90 T: 6 (18375) P:99 I:4000 C: 6648 Min: 6 Act: 18 Avg: 19 Max: 94 T: 7 (18376) P:99 I:4500 C: 5908 Min: 9 Act: 18 Avg: 19 Max:1172 T: 8 (18377) P:99 I:5000 C: 5317 Min: 6 Act: 17 Avg: 20 Max: 66 T: 9 (18378) P:99 I:5500 C: 4832 Min: 7 Act: 24 Avg: 19 Max: 100 T:10 (18379) P:99 I:6000 C: 4429 Min: 7 Act: 14 Avg: 19 Max:1216 T:11 (18380) P:99 I:6500 C: 4088 Min: 8 Act: 14 Avg: 20 Max: 827 T:12 (18381) P:99 I:7000 C: 3795 Min: 7 Act: 17 Avg: 18 Max: 77 T:13 (18382) P:99 I:7500 C: 3542 Min: 6 Act: 18 Avg: 20 Max: 71 T:14 (18383) P:99 I:8000 C: 3320 Min: 8 Act: 19 Avg: 20 Max: 73 T:15 (18384) P:99 I:8500 C: 3124 Min: 6 Act: 23 Avg: 19 Max: 75 -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 4.0.4-rt1
20.05.2015 00:39, Sebastian Andrzej Siewior пишет: Dear RT folks! I'm pleased to announce the v4.0.4-rt1 patch set. While work stable. \m/ TYAN S8225 2 x AMD Opteron(tm) Processor 4386 16Gb DDR3 ECC Reg. Nvidia GeForce GT740 (blob driver) CONFIG_NO_HZ_COMMON=y CONFIG_NO_HZ_FULL=y CONFIG_NO_HZ_FULL_ALL=y ... # cyclictest -S -c 1 -m -p 99 --latency=0 --policy=fifo # /dev/cpu_dma_latency set to 0us WARN: Running on unknown kernel version...YMMV policy: fifo: loadavg: 1.57 1.70 1.55 1/557 19347 T: 0 (18369) P:99 I:1000 C: 26617 Min: 6 Act: 13 Avg: 12 Max:1614 T: 1 (18370) P:99 I:1500 C: 17742 Min: 6 Act: 18 Avg: 19 Max:1700 T: 2 (18371) P:99 I:2000 C: 13304 Min: 8 Act: 19 Avg: 20 Max:1620 T: 3 (18372) P:99 I:2500 C: 10642 Min: 6 Act: 16 Avg: 17 Max: 73 T: 4 (18373) P:99 I:3000 C: 8867 Min: 8 Act: 20 Avg: 20 Max:1497 T: 5 (18374) P:99 I:3500 C: 7599 Min: 8 Act: 20 Avg: 20 Max: 90 T: 6 (18375) P:99 I:4000 C: 6648 Min: 6 Act: 18 Avg: 19 Max: 94 T: 7 (18376) P:99 I:4500 C: 5908 Min: 9 Act: 18 Avg: 19 Max:1172 T: 8 (18377) P:99 I:5000 C: 5317 Min: 6 Act: 17 Avg: 20 Max: 66 T: 9 (18378) P:99 I:5500 C: 4832 Min: 7 Act: 24 Avg: 19 Max: 100 T:10 (18379) P:99 I:6000 C: 4429 Min: 7 Act: 14 Avg: 19 Max:1216 T:11 (18380) P:99 I:6500 C: 4088 Min: 8 Act: 14 Avg: 20 Max: 827 T:12 (18381) P:99 I:7000 C: 3795 Min: 7 Act: 17 Avg: 18 Max: 77 T:13 (18382) P:99 I:7500 C: 3542 Min: 6 Act: 18 Avg: 20 Max: 71 T:14 (18383) P:99 I:8000 C: 3320 Min: 8 Act: 19 Avg: 20 Max: 73 T:15 (18384) P:99 I:8500 C: 3124 Min: 6 Act: 23 Avg: 19 Max: 75 -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 4.0.4-rt1
20.05.2015 01:33, Carsten Emde пишет: Hi Sebastian, I'm pleased to announce the v4.0.4-rt1 patch set. First smoke test on an Intel Gulftown 980X: Compiled and booted without problem, no regression of real-time capabilities so far. Maybe soon rebase to 4.1.0. By the time we will release our patches will also be tested? -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 4.0.4-rt1
20.05.2015 00:39, Sebastian Andrzej Siewior пишет: Dear RT folks! I'm pleased to announce the v4.0.4-rt1 patch set. Patch worked with 4.1.0-rc2, exclude at91rm9200_time.c --- cut --- can't find file to patch at input line 700 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff --git a/arch/arm/mach-at91/at91rm9200_time.c b/arch/arm/mach-at91/at91rm9200_time.c |index b00d09555f2b..cc873c12181d 100644 |--- a/arch/arm/mach-at91/at91rm9200_time.c |+++ b/arch/arm/mach-at91/at91rm9200_time.c -- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored --- cut --- -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 4.0.4-rt1
20.05.2015 00:39, Sebastian Andrzej Siewior пишет: Dear RT folks! I'm pleased to announce the v4.0.4-rt1 patch set. Patch worked with 4.1.0-rc2, exclude at91rm9200_time.c --- cut --- can't find file to patch at input line 700 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff --git a/arch/arm/mach-at91/at91rm9200_time.c b/arch/arm/mach-at91/at91rm9200_time.c |index b00d09555f2b..cc873c12181d 100644 |--- a/arch/arm/mach-at91/at91rm9200_time.c |+++ b/arch/arm/mach-at91/at91rm9200_time.c -- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored --- cut --- -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 4.0.4-rt1
20.05.2015 01:33, Carsten Emde пишет: Hi Sebastian, I'm pleased to announce the v4.0.4-rt1 patch set. First smoke test on an Intel Gulftown 980X: Compiled and booted without problem, no regression of real-time capabilities so far. Maybe soon rebase to 4.1.0. By the time we will release our patches will also be tested? -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.2.63-rt92
31.10.2014 01:07, Steven Rostedt пишет: Dear RT Folks, I'm pleased to announce the 3.2.63-rt92 stable release. Cool!!! For latest, stable,... 3.14/3.16/3.18 will be? -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.2.63-rt92
31.10.2014 01:07, Steven Rostedt пишет: Dear RT Folks, I'm pleased to announce the 3.2.63-rt92 stable release. Cool!!! For latest, stable,... 3.14/3.16/3.18 will be? -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT 0/4] Linux 3.2.60-rt89-rc1
16.07.2014 14:28, Rolf Peukert пишет: On 15.07.2014 01:05, Pavel Vasilyev wrote: 15.07.2014 00:06, Steven Rostedt пишет: Dear RT Folks, This is the RT stable review cycle of patch 3.2.60-rt89-rc1. Actually 3.2.61 kernel/irq/manage.c kernel/rtmutex.c This files FUZZED :( Just for the record, the (incremental) patch applies and runs without problems on an 3.2.60-rt88 (built for ARM). I'm about 3.2.61 -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT 0/4] Linux 3.2.60-rt89-rc1
16.07.2014 14:28, Rolf Peukert пишет: On 15.07.2014 01:05, Pavel Vasilyev wrote: 15.07.2014 00:06, Steven Rostedt пишет: Dear RT Folks, This is the RT stable review cycle of patch 3.2.60-rt89-rc1. Actually 3.2.61 kernel/irq/manage.c kernel/rtmutex.c This files FUZZED :( Just for the record, the (incremental) patch applies and runs without problems on an 3.2.60-rt88 (built for ARM). I'm about 3.2.61 -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT 0/4] Linux 3.2.60-rt89-rc1
15.07.2014 00:06, Steven Rostedt пишет: Dear RT Folks, This is the RT stable review cycle of patch 3.2.60-rt89-rc1. Actually 3.2.61 kernel/irq/manage.c kernel/rtmutex.c This files FUZZED :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT 0/4] Linux 3.2.60-rt89-rc1
15.07.2014 00:06, Steven Rostedt пишет: Dear RT Folks, This is the RT stable review cycle of patch 3.2.60-rt89-rc1. Actually 3.2.61 kernel/irq/manage.c kernel/rtmutex.c This files FUZZED :( -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.14.10-rt7
09.07.2014 15:34, Henrik Austad пишет: On Wed, Jul 09, 2014 at 02:01:58PM +0400, Pavel Vasilyev wrote: 07.07.2014 18:34, Thomas Gleixner пишет: A few words on the status and the future of RT: --- The situation since last years RTLWS (https://lwn.net/Articles/572740/) has not improved at all, it's worse than before. While shortly after RTLWS quite some people promised to whip up proper funding, nothing has materialized and my personal situation is worse than before. Create site, add PayPal [DONATE] button. But.. where would they donate money? Jokes aside, setting up an easy way to support the project wouldn't be such a bad idea. Is this something we (tglx) could talk (convince) linuxfoundation into hosting? Linux foundation || OSADL || Independent hosting ... Why not? Grsecurity project so lives. When I worked actively with grsecurity, 10-20$ sent almost every month. Now they found sponsors, сreated commercial technical support. -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.14.10-rt7
07.07.2014 18:34, Thomas Gleixner пишет: This time with proper Subject line :) Dear RT Folks, I'm pleased to announce the 3.14.10-rt7 release. 3.14.10-rt6 is a not announced update to 3.14.10 without any RT changes aside of resolving the patch conflicts. Changes since 3.14.10-rt6: * Do not clear PF_NO_SETAFFINITY flag in select_fallback_rq() - from Steven * Prevent workqueue deadlock/stall observed with XFS A few words on the status and the future of RT: --- The situation since last years RTLWS (https://lwn.net/Articles/572740/) has not improved at all, it's worse than before. While shortly after RTLWS quite some people promised to whip up proper funding, nothing has materialized and my personal situation is worse than before. Create site, add PayPal [DOANTE] button. -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.14.10-rt7
07.07.2014 18:34, Thomas Gleixner пишет: This time with proper Subject line :) Dear RT Folks, I'm pleased to announce the 3.14.10-rt7 release. 3.14.10-rt6 is a not announced update to 3.14.10 without any RT changes aside of resolving the patch conflicts. Changes since 3.14.10-rt6: * Do not clear PF_NO_SETAFFINITY flag in select_fallback_rq() - from Steven * Prevent workqueue deadlock/stall observed with XFS A few words on the status and the future of RT: --- The situation since last years RTLWS (https://lwn.net/Articles/572740/) has not improved at all, it's worse than before. While shortly after RTLWS quite some people promised to whip up proper funding, nothing has materialized and my personal situation is worse than before. Create site, add PayPal [DOANTE] button. -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.14.10-rt7
09.07.2014 15:34, Henrik Austad пишет: On Wed, Jul 09, 2014 at 02:01:58PM +0400, Pavel Vasilyev wrote: 07.07.2014 18:34, Thomas Gleixner пишет: A few words on the status and the future of RT: --- The situation since last years RTLWS (https://lwn.net/Articles/572740/) has not improved at all, it's worse than before. While shortly after RTLWS quite some people promised to whip up proper funding, nothing has materialized and my personal situation is worse than before. Create site, add PayPal [DONATE] button. But.. where would they donate money? Jokes aside, setting up an easy way to support the project wouldn't be such a bad idea. Is this something we (tglx) could talk (convince) linuxfoundation into hosting? Linux foundation || OSADL || Independent hosting ... Why not? Grsecurity project so lives. When I worked actively with grsecurity, 10-20$ sent almost every month. Now they found sponsors, сreated commercial technical support. -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] rt/aio: fix rcu garbage collection might_sleep() splat
09.06.2014 10:22, Mike Galbraith пишет:
On Mon, 2014-06-09 at 05:17 +0200, Mike Galbraith wrote:
On Mon, 2014-06-09 at 10:08 +0800, Lai Jiangshan wrote:
Hi, rt-people
@@ -522,7 +524,9 @@ static void free_ioctx_users(struct perc
struct kioctx *ctx = container_of(ref, struct kioctx, users);
struct kiocb *req;
+ preempt_enable_rt();
spin_lock_irq(>ctx_lock);
+ local_irq_disable_rt();
while (!list_empty(>active_reqs)) {
req = list_first_entry(>active_reqs,
@@ -536,6 +540,8 @@ static void free_ioctx_users(struct perc
percpu_ref_kill(>reqs);
percpu_ref_put(>reqs);
+ preempt_disable_rt();
+ local_irq_enable_rt();
I think, enable_/disable_ must be as mirror reflections
preempt_enable_rt();
local_irq_disable_rt();
do_something();
local_irq_enable_rt();
preempt_disable_rt();
--
Pavel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] rt/aio: fix rcu garbage collection might_sleep() splat
09.06.2014 10:22, Mike Galbraith пишет:
On Mon, 2014-06-09 at 05:17 +0200, Mike Galbraith wrote:
On Mon, 2014-06-09 at 10:08 +0800, Lai Jiangshan wrote:
Hi, rt-people
@@ -522,7 +524,9 @@ static void free_ioctx_users(struct perc
struct kioctx *ctx = container_of(ref, struct kioctx, users);
struct kiocb *req;
+ preempt_enable_rt();
spin_lock_irq(ctx-ctx_lock);
+ local_irq_disable_rt();
while (!list_empty(ctx-active_reqs)) {
req = list_first_entry(ctx-active_reqs,
@@ -536,6 +540,8 @@ static void free_ioctx_users(struct perc
percpu_ref_kill(ctx-reqs);
percpu_ref_put(ctx-reqs);
+ preempt_disable_rt();
+ local_irq_enable_rt();
I think, enable_/disable_ must be as mirror reflections
preempt_enable_rt();
local_irq_disable_rt();
do_something();
local_irq_enable_rt();
preempt_disable_rt();
--
Pavel.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.14.3-rt5
09.05.2014 22:12, Sebastian Andrzej Siewior пишет: The delta patch against v3.14.3-rt4 is appended below and can be found Where delta from 3 to 4 ? -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.14.3-rt5
09.05.2014 22:12, Sebastian Andrzej Siewior пишет: The delta patch against v3.14.3-rt4 is appended below and can be found Where delta from 3 to 4 ? -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT 0/3] Linux 3.2.57-rt84-rc1
28.04.2014 17:39, Steven Rostedt пишет: On Mon, 28 Apr 2014 02:15:28 +0400 Pavel Vasilyev wrote: 27.04.2014 18:39, Steven Rostedt пишет: Dear RT Folks, This is the RT stable review cycle of patch 3.2.57-rt84-rc1. Please scream at me if I messed something up. Please test the patches too. More than two years our thin clients (about 5000 machines, Intel Atom, x86_32) work with RCU_BOOST. CONFIG_RCU_BOOST=y CONFIG_RCU_BOOST_PRIO=80 CONFIG_RCU_BOOST_DELAY=400 Is this just a confirmation of having RCU_BOOST default y for PREEMPT_RT is a good thing? Only 3.2-rt -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT 0/3] Linux 3.2.57-rt84-rc1
28.04.2014 17:39, Steven Rostedt пишет: On Mon, 28 Apr 2014 02:15:28 +0400 Pavel Vasilyev pa...@pavlinux.ru wrote: 27.04.2014 18:39, Steven Rostedt пишет: Dear RT Folks, This is the RT stable review cycle of patch 3.2.57-rt84-rc1. Please scream at me if I messed something up. Please test the patches too. More than two years our thin clients (about 5000 machines, Intel Atom, x86_32) work with RCU_BOOST. CONFIG_RCU_BOOST=y CONFIG_RCU_BOOST_PRIO=80 CONFIG_RCU_BOOST_DELAY=400 Is this just a confirmation of having RCU_BOOST default y for PREEMPT_RT is a good thing? Only 3.2-rt -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT 0/3] Linux 3.2.57-rt84-rc1
27.04.2014 18:39, Steven Rostedt пишет: Dear RT Folks, This is the RT stable review cycle of patch 3.2.57-rt84-rc1. Please scream at me if I messed something up. Please test the patches too. More than two years our thin clients (about 5000 machines, Intel Atom, x86_32) work with RCU_BOOST. CONFIG_RCU_BOOST=y CONFIG_RCU_BOOST_PRIO=80 CONFIG_RCU_BOOST_DELAY=400 -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT 0/3] Linux 3.2.57-rt84-rc1
27.04.2014 18:39, Steven Rostedt пишет: Dear RT Folks, This is the RT stable review cycle of patch 3.2.57-rt84-rc1. Please scream at me if I messed something up. Please test the patches too. More than two years our thin clients (about 5000 machines, Intel Atom, x86_32) work with RCU_BOOST. CONFIG_RCU_BOOST=y CONFIG_RCU_BOOST_PRIO=80 CONFIG_RCU_BOOST_DELAY=400 -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.14-rt1
11.04.2014 22:57, Sebastian Andrzej Siewior пишет: Dear RT folks! I'm pleased to announce the v3.14-rt1 patch set. Hray! -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.14-rt1
11.04.2014 22:57, Sebastian Andrzej Siewior пишет: Dear RT folks! I'm pleased to announce the v3.14-rt1 patch set. Hray! -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.12.12-rt19
24.02.2014 01:13, Thomas Gleixner пишет: > On Sun, 23 Feb 2014, Pavel Vasilyev wrote: >> 23.02.2014 23:13, Pavel Vasilyev пишет: >> >>> But not -rt1, -rt2, -rt3 -rt4, -rt99 >> >> Or >> >> 3.12-rt1, >> 3.12-rt2, >> ... >> 3.12-rt33, >> ... >> 3.12-rt111, >> ... >> 3.12-rt999 >> ... >> >> Now, to have to roll back all my changes, then work -rt patch, >> then impose SUBLEVEL mainline diff, then last -rt patch, then my сhanges. > > So we need a different numbering scheme just because your workflow is > completely backwards? No, because in positional number systems, an increase in the senior level, junior reset, but not stays the same. Mainline kernel and patches is senior level. -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.12-rt19
23.02.2014 23:13, Pavel Vasilyev пишет: > But not -rt1, -rt2, -rt3 -rt4, -rt99 Or 3.12-rt1, 3.12-rt2, ... 3.12-rt33, ... 3.12-rt111, ... 3.12-rt999 ... Now, to have to roll back all my changes, then work -rt patch, then impose SUBLEVEL mainline diff, then last -rt patch, then my сhanges. -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.12-rt19
23.02.2014 22:47, Sebastian Andrzej Siewior пишет: > Dear RT folks! > > I'm pleased to announce the v3.12.12-rt19 patch set. Can you create new -RT number for new SUBLEVEL patch? 3.12.10-rt1 3.12.10-rt2 3.12.10-rt3 3.12.10-rt4 3.12.11-rt1 3.12.11-rt2 3.12.11-rt3 ... ... ... 3.12.12-rt1 3.12.12-rt1 But not -rt1, -rt2, -rt3 -rt4, -rt99 signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.12-rt19
23.02.2014 22:47, Sebastian Andrzej Siewior пишет: Dear RT folks! I'm pleased to announce the v3.12.12-rt19 patch set. Can you create new -RT number for new SUBLEVEL patch? 3.12.10-rt1 3.12.10-rt2 3.12.10-rt3 3.12.10-rt4 3.12.11-rt1 3.12.11-rt2 3.12.11-rt3 ... ... ... 3.12.12-rt1 3.12.12-rt1 But not -rt1, -rt2, -rt3 -rt4, -rt99 signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.12-rt19
23.02.2014 23:13, Pavel Vasilyev пишет: But not -rt1, -rt2, -rt3 -rt4, -rt99 Or 3.12-rt1, 3.12-rt2, ... 3.12-rt33, ... 3.12-rt111, ... 3.12-rt999 ... Now, to have to roll back all my changes, then work -rt patch, then impose SUBLEVEL mainline diff, then last -rt patch, then my сhanges. -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.12-rt19
24.02.2014 01:13, Thomas Gleixner пишет: On Sun, 23 Feb 2014, Pavel Vasilyev wrote: 23.02.2014 23:13, Pavel Vasilyev пишет: But not -rt1, -rt2, -rt3 -rt4, -rt99 Or 3.12-rt1, 3.12-rt2, ... 3.12-rt33, ... 3.12-rt111, ... 3.12-rt999 ... Now, to have to roll back all my changes, then work -rt patch, then impose SUBLEVEL mainline diff, then last -rt patch, then my сhanges. So we need a different numbering scheme just because your workflow is completely backwards? No, because in positional number systems, an increase in the senior level, junior reset, but not stays the same. Mainline kernel and patches is senior level. -- Pavel. signature.asc Description: OpenPGP digital signature
Next longterm
Does anyone know what the next version of the kernel will be longterm? -- Pavel. signature.asc Description: OpenPGP digital signature
Next longterm
Does anyone know what the next version of the kernel will be longterm? -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.8-rt11
27.01.2014 12:44, Sebastian Andrzej Siewior пишет: > On 01/26/2014 10:25 PM, Pavel Vasilyev wrote: >> 25.01.2014 17:45, Sebastian Andrzej Siewior пишет: >>> Dear RT folks! >> >> >> Gentlemen, let's have a month of stress testing! Divide tasks >> testing subsystem: USB, NET, MM, ACPI, AUDIO, VIDEO By CPUs: >> ARM/PPC/X86/X86_64... >> >> Purely on observations noted that in September 2013, the quality >> and stability of the code has deteriorated dramatically. > > By September 2k13, do you mean a specific v3.10-RT release? > Any after 3.2.x-rt Maybe I'm doing something wrong, but: 1) All kernels (3.2, 3.8, 3.12, 3.13,...) are working normally without patches; 2) 3.2 works fine in CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL modes; 3) 3.10 not works at all, even without -RT patches; 4) 3.12 work only as CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL in uniprocessor mode (maxcpus=0, nosmp). Newer patches (Oct.-Dec.) did not work, even in RT_BASE mode. Varia hardware: One Opteron 285, 2-cpus (4 cores). Six Intel Atoms devices kernels compiled as x86_32. I have my patches, but I tested both with them and without them. --- Behold! 3.12.8-rt11, RT_FULL mode, kernel cmdline: init=/bin/bash 1. bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell 2. in single mode: After 2 minutes timeout: see screenshot http://i59.fastpic.ru/big/2014/0127/bc/0f9e04536181286f820ecaae5a8481bc.jpg 3. command killall -15 freezed system! Kernel compiled with debug information starts to work normally, but of course slower. :D -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.8-rt11
27.01.2014 12:44, Sebastian Andrzej Siewior пишет: On 01/26/2014 10:25 PM, Pavel Vasilyev wrote: 25.01.2014 17:45, Sebastian Andrzej Siewior пишет: Dear RT folks! Gentlemen, let's have a month of stress testing! Divide tasks testing subsystem: USB, NET, MM, ACPI, AUDIO, VIDEO By CPUs: ARM/PPC/X86/X86_64... Purely on observations noted that in September 2013, the quality and stability of the code has deteriorated dramatically. By September 2k13, do you mean a specific v3.10-RT release? Any after 3.2.x-rt Maybe I'm doing something wrong, but: 1) All kernels (3.2, 3.8, 3.12, 3.13,...) are working normally without patches; 2) 3.2 works fine in CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL modes; 3) 3.10 not works at all, even without -RT patches; 4) 3.12 work only as CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL in uniprocessor mode (maxcpus=0, nosmp). Newer patches (Oct.-Dec.) did not work, even in RT_BASE mode. Varia hardware: One Opteron 285, 2-cpus (4 cores). Six Intel Atoms devices kernels compiled as x86_32. I have my patches, but I tested both with them and without them. --- Behold! 3.12.8-rt11, RT_FULL mode, kernel cmdline: init=/bin/bash 1. bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell 2. in single mode: After 2 minutes timeout: see screenshot http://i59.fastpic.ru/big/2014/0127/bc/0f9e04536181286f820ecaae5a8481bc.jpg 3. command killall -15 freezed system! Kernel compiled with debug information starts to work normally, but of course slower. :D -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.8-rt11
25.01.2014 17:45, Sebastian Andrzej Siewior пишет: > Dear RT folks! Gentlemen, let's have a month of stress testing! Divide tasks testing subsystem: USB, NET, MM, ACPI, AUDIO, VIDEO By CPUs: ARM/PPC/X86/X86_64... Purely on observations noted that in September 2013, the quality and stability of the code has deteriorated dramatically. -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.8-rt11
25.01.2014 17:45, Sebastian Andrzej Siewior пишет: > I'm pleased to announce the v3.12.8-rt11 patch set. Nothing has changed, it does not boot from September, and will not boot. 3.2-54-rt77 - works perfectly. Same hardware, same config. -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.8-rt11
25.01.2014 17:45, Sebastian Andrzej Siewior пишет: I'm pleased to announce the v3.12.8-rt11 patch set. Nothing has changed, it does not boot from September, and will not boot. 3.2-54-rt77 - works perfectly. Same hardware, same config. -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.8-rt11
25.01.2014 17:45, Sebastian Andrzej Siewior пишет: Dear RT folks! Gentlemen, let's have a month of stress testing! Divide tasks testing subsystem: USB, NET, MM, ACPI, AUDIO, VIDEO By CPUs: ARM/PPC/X86/X86_64... Purely on observations noted that in September 2013, the quality and stability of the code has deteriorated dramatically. -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [PATCH RT 0/8] Linux 3.2.53-rt76-rc1
16.01.2014 20:08, Steven Rostedt пишет: > On Thu, 16 Jan 2014 18:36:32 +0400 > Pavel Vasilyev wrote: > >> >> $ xz -cd /tmp/patch-3.2.53-rt75-rt76-rc1.patch.xz | patch -p1 --dry-run > Did you start with v3.2.53-rt75? No, 3.2.54, already corrected. -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [PATCH RT 0/8] Linux 3.2.53-rt76-rc1
16.01.2014 18:18, Steven Rostedt пишет: > On Thu, 16 Jan 2014 13:41:16 +0400 > Pavel Vasilyev wrote: > >> 16.01.2014 05:58, Steven Rostedt пишет: >>> Dear RT Folks, >>> >>> This is the RT stable review cycle of patch 3.2.53-rt76-rc1. >> >> Yap..., mainline is 3.2.54 ! >> > > Yeah, but I already had the -rt specific changes merged into 3.2.53 > before 3.2.54 was released, and then I discovered the cpu hotplug bug. > I did not want to release that -rc until it was solved. Now that it is, > I can release this one and then move to 3.2.54. $ xz -cd /tmp/patch-3.2.53-rt75-rt76-rc1.patch.xz | patch -p1 --dry-run checking file arch/arm/kernel/smp_tlb.c checking file arch/tile/include/asm/smp.h checking file arch/tile/kernel/smp.c checking file drivers/net/wireless/orinoco/orinoco_usb.c checking file drivers/usb/gadget/f_fs.c checking file drivers/usb/gadget/inode.c checking file fs/buffer.c checking file include/linux/smp.h Hunk #1 succeeded at 117 with fuzz 1 (offset 16 lines). Hunk #2 FAILED at 147. 1 out of 2 hunks FAILED checking file include/linux/spinlock_rt.h checking file kernel/cpu.c checking file kernel/rtmutex.c checking file kernel/smp.c Hunk #1 FAILED at 712. 1 out of 1 hunk FAILED checking file kernel/softirq.c checking file kernel/timer.c checking file localversion-rt include/linux/smp.h REJECT: #define on_each_cpu_mask() and #define on_each_cpu_cond() and same in kernel/smp.c -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [PATCH RT 0/8] Linux 3.2.53-rt76-rc1
16.01.2014 05:58, Steven Rostedt пишет: > Dear RT Folks, > > This is the RT stable review cycle of patch 3.2.53-rt76-rc1. Yap..., mainline is 3.2.54 ! -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [PATCH RT 0/8] Linux 3.2.53-rt76-rc1
16.01.2014 05:58, Steven Rostedt пишет: Dear RT Folks, This is the RT stable review cycle of patch 3.2.53-rt76-rc1. Yap..., mainline is 3.2.54 ! -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [PATCH RT 0/8] Linux 3.2.53-rt76-rc1
16.01.2014 18:18, Steven Rostedt пишет: On Thu, 16 Jan 2014 13:41:16 +0400 Pavel Vasilyev pa...@pavlinux.ru wrote: 16.01.2014 05:58, Steven Rostedt пишет: Dear RT Folks, This is the RT stable review cycle of patch 3.2.53-rt76-rc1. Yap..., mainline is 3.2.54 ! Yeah, but I already had the -rt specific changes merged into 3.2.53 before 3.2.54 was released, and then I discovered the cpu hotplug bug. I did not want to release that -rc until it was solved. Now that it is, I can release this one and then move to 3.2.54. $ xz -cd /tmp/patch-3.2.53-rt75-rt76-rc1.patch.xz | patch -p1 --dry-run checking file arch/arm/kernel/smp_tlb.c checking file arch/tile/include/asm/smp.h checking file arch/tile/kernel/smp.c checking file drivers/net/wireless/orinoco/orinoco_usb.c checking file drivers/usb/gadget/f_fs.c checking file drivers/usb/gadget/inode.c checking file fs/buffer.c checking file include/linux/smp.h Hunk #1 succeeded at 117 with fuzz 1 (offset 16 lines). Hunk #2 FAILED at 147. 1 out of 2 hunks FAILED checking file include/linux/spinlock_rt.h checking file kernel/cpu.c checking file kernel/rtmutex.c checking file kernel/smp.c Hunk #1 FAILED at 712. 1 out of 1 hunk FAILED checking file kernel/softirq.c checking file kernel/timer.c checking file localversion-rt include/linux/smp.h REJECT: #define on_each_cpu_mask() and #define on_each_cpu_cond() and same in kernel/smp.c -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [PATCH RT 0/8] Linux 3.2.53-rt76-rc1
16.01.2014 20:08, Steven Rostedt пишет: On Thu, 16 Jan 2014 18:36:32 +0400 Pavel Vasilyev pa...@pavlinux.ru wrote: $ xz -cd /tmp/patch-3.2.53-rt75-rt76-rc1.patch.xz | patch -p1 --dry-run Did you start with v3.2.53-rt75? No, 3.2.54, already corrected. -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.6-rt9
24.12.2013 19:47, Mike Galbraith пишет: > On Mon, 2013-12-23 at 23:50 +0100, Sebastian Andrzej Siewior wrote: > crash> bt > PID: 508TASK: 8802739ba340 CPU: 16 COMMAND: "ksoftirqd/16" YES!!! And ARM code broke :) -- Pavel. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.6-rt9
24.12.2013 19:47, Mike Galbraith пишет: On Mon, 2013-12-23 at 23:50 +0100, Sebastian Andrzej Siewior wrote: crash bt PID: 508TASK: 8802739ba340 CPU: 16 COMMAND: ksoftirqd/16 YES!!! And ARM code broke :) -- Pavel. signature.asc Description: OpenPGP digital signature
Re: 3.12.5 CRASH/FREEZE
20.12.2013 19:05, Sebastian Andrzej Siewior пишет: > On 12/20/2013 03:57 PM, Pavel Vasilyev wrote: ... The last two years I have worked with 3.2 kernel and patches for it. Recently, we have a new equipment that partially works with version 3.2.53. Therefore it was decided to move to version 3.12. What was my surprise that none of the 15 (or old models, or new )computers does not start with the same .configs on a new version of the kernel and rt-patches. :) -- Pavel. signature.asc Description: OpenPGP digital signature
Re: 3.12.5 CRASH/FREEZE
20.12.2013 19:05, Sebastian Andrzej Siewior пишет: > On 12/20/2013 03:57 PM, Pavel Vasilyev wrote: >> >> Same bug if attach to ehci hub. >> >> ksoftird/0 process of loading the CPU upto 100% Sometimes process >> irq17/0 - ehci_hcd or xhci_hcd. After taking the camera out of the >> socket, the load does not fall, keyboard and console blocked > > Okay, but this problem is unique to your webcam. Keyboard & mice to > work as usual? > Could please provide me the addr2line either for the ehci or xhci? I've > been browsing to the code and I didn't see anything obvious. > Too many bugs, too many computers ... 3.12.5-rt7 work ONLY in UP-mode!!! cmdline: nosmp maxcpus=1 In SMP mode, problems arise in different places on different computers. On Intel Atom - USB, webcam and console. On the Opteron 285 system does not boot, can't mount devtmpfs, XFS partitions ... I can not get to catch the error and find a place neither in debug mode or in normal. Because everything is frozen completely, and get to the console or logs is not possible. I described one situation where had run top and see that the process ksoftirqd/0 use CPU upto 100% P.S. 3.12.5-rt7 still work Basic-RT mode. -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12.5 CRASH/FREEZE
20.12.2013 19:05, Sebastian Andrzej Siewior пишет: On 12/20/2013 03:57 PM, Pavel Vasilyev wrote: Same bug if attach to ehci hub. ksoftird/0 process of loading the CPU upto 100% Sometimes process irq17/0 - ehci_hcd or xhci_hcd. After taking the camera out of the socket, the load does not fall, keyboard and console blocked Okay, but this problem is unique to your webcam. Keyboard mice to work as usual? Could please provide me the addr2line either for the ehci or xhci? I've been browsing to the code and I didn't see anything obvious. Too many bugs, too many computers ... 3.12.5-rt7 work ONLY in UP-mode!!! cmdline: nosmp maxcpus=1 In SMP mode, problems arise in different places on different computers. On Intel Atom - USB, webcam and console. On the Opteron 285 system does not boot, can't mount devtmpfs, XFS partitions ... I can not get to catch the error and find a place neither in debug mode or in normal. Because everything is frozen completely, and get to the console or logs is not possible. I described one situation where had run top and see that the process ksoftirqd/0 use CPU upto 100% P.S. 3.12.5-rt7 still work Basic-RT mode. -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12.5 CRASH/FREEZE
20.12.2013 19:05, Sebastian Andrzej Siewior пишет: On 12/20/2013 03:57 PM, Pavel Vasilyev wrote: ... The last two years I have worked with 3.2 kernel and patches for it. Recently, we have a new equipment that partially works with version 3.2.53. Therefore it was decided to move to version 3.12. What was my surprise that none of the 15 (or old models, or new )computers does not start with the same .configs on a new version of the kernel and rt-patches. :) -- Pavel. signature.asc Description: OpenPGP digital signature
Re: 3.12.5 CRASH/FREEZE
20.12.2013 18:10, Sebastian Andrzej Siewior пишет: > * Pavel Vasilyev | 2013-12-13 00:29:52 [+0400]: > >> On startup, if USB webcam (uvcvideo) attached in usb-hole >> >> NMI backtrace for cpu 0 >> CPU: 0 PID: 35 Comm: irq/43-xhci_hcd Not tainted 3.12.5-plx #6 > >> [] xhci_queue_isoc_tx_prepare+0x39c/0x950 >> [] xhci_urb_enqueue+0x22f/0x540 >> [] usb_hcd_submit_urb+0x65/0x280 >> [] usb_submit_urb+0x170/0x3a0 >> [] uvc_video_complete+0xb8/0xd0 >> [] __usb_hcd_giveback_urb+0x45/0xa0 >> [] usb_hcd_giveback_urb+0x38/0xf0 >> [] handle_tx_event+0x3af/0xda0 >> [] xhci_irq+0x1a2/0x6c0 >> [] xhci_msi_irq+0xa/0x10 >> [] irq_forced_thread_fn+0x21/0x70 >> [] irq_thread+0x106/0x220 >> [] kthread+0xd0/0xe0 >> [] ret_from_kernel_thread+0x1b/0x28 > > This looks like uvc is resubmitting the URB on completion. Nothing > unusual. Howver it seems that then CPU gets stuck in > xhci_queue_isoc_tx_prepare() for some reason. Could you try map c13aa59c Same bug if attach to ehci hub. ksoftird/0 process of loading the CPU upto 100% Sometimes process irq17/0 - ehci_hcd or xhci_hcd. After taking the camera out of the socket, the load does not fall, keyboard and console blocked > to the source line? Something like > addr2lin -e xhci-hcd.ko -i c13aa59c > > should do the trick but of the module of this trace. > What does the -plx stand for in localversion? Do you have any custom > patches on your kernel? No patches, just local flag. -- Pavel. signature.asc Description: OpenPGP digital signature
Re: 3.12.5 CRASH/FREEZE
20.12.2013 18:10, Sebastian Andrzej Siewior пишет: * Pavel Vasilyev | 2013-12-13 00:29:52 [+0400]: On startup, if USB webcam (uvcvideo) attached in usb-hole NMI backtrace for cpu 0 CPU: 0 PID: 35 Comm: irq/43-xhci_hcd Not tainted 3.12.5-plx #6 [c13aa59c] xhci_queue_isoc_tx_prepare+0x39c/0x950 [c139d35f] xhci_urb_enqueue+0x22f/0x540 [c1375745] usb_hcd_submit_urb+0x65/0x280 [c13777a0] usb_submit_urb+0x170/0x3a0 [c13e1ee8] uvc_video_complete+0xb8/0xd0 [c1374625] __usb_hcd_giveback_urb+0x45/0xa0 [c1374bd8] usb_hcd_giveback_urb+0x38/0xf0 [c13a84cf] handle_tx_event+0x3af/0xda0 [c13a9082] xhci_irq+0x1a2/0x6c0 [c13a95aa] xhci_msi_irq+0xa/0x10 [c1084c31] irq_forced_thread_fn+0x21/0x70 [c1085046] irq_thread+0x106/0x220 [c1057110] kthread+0xd0/0xe0 [c15083b7] ret_from_kernel_thread+0x1b/0x28 This looks like uvc is resubmitting the URB on completion. Nothing unusual. Howver it seems that then CPU gets stuck in xhci_queue_isoc_tx_prepare() for some reason. Could you try map c13aa59c Same bug if attach to ehci hub. ksoftird/0 process of loading the CPU upto 100% Sometimes process irq17/0 - ehci_hcd or xhci_hcd. After taking the camera out of the socket, the load does not fall, keyboard and console blocked to the source line? Something like addr2lin -e xhci-hcd.ko -i c13aa59c should do the trick but of the module of this trace. What does the -plx stand for in localversion? Do you have any custom patches on your kernel? No patches, just local flag. -- Pavel. signature.asc Description: OpenPGP digital signature
3.12.5 CRASH/FREEZE
On startup, if USB webcam (uvcvideo) attached in usb-hole NMI backtrace for cpu 1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.12.5-plx #6 Hardware name: PEGATRON CORPORATION SAISHIAT2/IPPCR-SS, BIOS 0308 10/31/2012 task: f60a4420 ti: f60b4000 task.ti: f60b4000 EIP: 0060:[] EFLAGS: 00200246 CPU: 1 EIP is at poll_idle+0x95/0xb0 EAX: EBX: f67d13d8 ECX: 0019 EDX: f60b4000 ESI: af9fbf64 EDI: 00a7 EBP: f60b5f54 ESP: f60b5f44 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 CR0: 80050033 CR2: b7ec2000 CR3: 35768000 CR4: 000407b0 Stack: c1648af0 f67d13d8 c1648ae0 f60b5f78 c13f3ddf af9fbbd8 00a7 c1679f24 c1678a00 f67cedc0 f60b5f80 c100ba68 f60b5f8c c1084272 0001 f60b5fb4 c1025018 02100800 360b5fb4 Call Trace: [] cpuidle_idle_call+0x9f/0x1c0 [] arch_cpu_idle+0x8/0x20 [] cpu_startup_entry+0xe2/0x110 [] start_secondary+0x1a8/0x210 Code: 8d b6 00 00 00 00 3d ff ff ff 7f 77 e0 89 43 08 8b 45 f0 83 c4 04 5b 5e 5f 5d c3 8d 76 00 89 e2 81 e2 00 e0 ff ff f3 90 8b 42 08 08 75 97 8b 42 08 f6 c4 02 75 8f eb ed 8d b6 00 00 00 00 8d NMI backtrace for cpu 0 CPU: 0 PID: 35 Comm: irq/43-xhci_hcd Not tainted 3.12.5-plx #6 Hardware name: PEGATRON CORPORATION SAISHIAT2/IPPCR-SS, BIOS 0308 10/31/2012 task: f58f8da0 ti: f590 task.ti: f590 EIP: 0060:[] EFLAGS: 0046 CPU: 0 EIP is at default_send_IPI_mask_logical+0x78/0xa0 EAX: 0c00 EBX: 0300 ECX: c163d200 EDX: f000 ESI: 0c00 EDI: 0006 EBP: f5901ba8 ESP: f5901b94 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 CR0: 80050033 CR2: b7ec2417 CR3: 35166000 CR4: 000407b0 Stack: 0006 0002 2710 26c8 c1641140 f5901bb8 c1027d70 2710 26c8 f5901bc8 c1027f31 c15d69cd f67c1c60 f5901c14 c10a987b c1603e90 000927c9 026b 026a 26c8 aea0554e f5901bf0 f5901c14 Call Trace: [] default_send_IPI_all+0x80/0x90 [] arch_trigger_all_cpu_backtrace+0x41/0x70 [] rcu_check_callbacks+0x2db/0x650 [] ? scheduler_tick+0xad/0x120 [] update_process_times+0x45/0x60 [] tick_handle_periodic+0x3a/0x1f0 [] smp_apic_timer_interrupt+0x54/0x90 [] apic_timer_interrupt+0x2a/0x30 [] ? inc_enq+0x12/0x170 [] xhci_queue_isoc_tx_prepare+0x39c/0x950 [] ? smp_apic_timer_interrupt+0x59/0x90 [] xhci_urb_enqueue+0x22f/0x540 [] usb_hcd_submit_urb+0x65/0x280 [] ? uvc_video_decode_isoc+0x149/0x220 [] usb_submit_urb+0x170/0x3a0 [] ? irq_exit+0x56/0x70 [] uvc_video_complete+0xb8/0xd0 [] __usb_hcd_giveback_urb+0x45/0xa0 [] usb_hcd_giveback_urb+0x38/0xf0 [] handle_tx_event+0x3af/0xda0 [] ? irq_exit+0x56/0x70 [] ? smp_apic_timer_interrupt+0x59/0x90 [] ? common_interrupt+0x29/0x2e [] xhci_irq+0x1a2/0x6c0 [] ? apic_timer_interrupt+0x2a/0x30 [] xhci_msi_irq+0xa/0x10 [] irq_forced_thread_fn+0x21/0x70 [] irq_thread+0x106/0x220 [] ? irq_finalize_oneshot.part.40+0xc0/0xc0 [] ? irq_thread_fn+0x40/0x40 [] kthread+0xd0/0xe0 [] ? set_affinity_thread+0x140/0x140 [] ret_from_kernel_thread+0x1b/0x28 [] ? kthread_flush_work_fn+0x10/0x10 Code: 80 e5 10 75 ee c1 e3 18 89 98 10 c3 ff ff 89 d0 09 f0 81 ce 00 04 00 00 83 fa 02 8b 15 44 d5 63 c1 0f 44 c6 89 82 00 c3 ff ff 57 <9d> 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d c3 89 55 f0 ff 90 b4 00 INFO: NMI handler (arch_trigger_all_cpu_backtrace_handler) took too long to run: 71.797 msecs --- 3.2.53 - works fine :) signature.asc Description: OpenPGP digital signature
3.12.5 CRASH/FREEZE
On startup, if USB webcam (uvcvideo) attached in usb-hole NMI backtrace for cpu 1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.12.5-plx #6 Hardware name: PEGATRON CORPORATION SAISHIAT2/IPPCR-SS, BIOS 0308 10/31/2012 task: f60a4420 ti: f60b4000 task.ti: f60b4000 EIP: 0060:[c13f3be5] EFLAGS: 00200246 CPU: 1 EIP is at poll_idle+0x95/0xb0 EAX: EBX: f67d13d8 ECX: 0019 EDX: f60b4000 ESI: af9fbf64 EDI: 00a7 EBP: f60b5f54 ESP: f60b5f44 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 CR0: 80050033 CR2: b7ec2000 CR3: 35768000 CR4: 000407b0 Stack: c1648af0 f67d13d8 c1648ae0 f60b5f78 c13f3ddf af9fbbd8 00a7 c1679f24 c1678a00 f67cedc0 f60b5f80 c100ba68 f60b5f8c c1084272 0001 f60b5fb4 c1025018 02100800 360b5fb4 Call Trace: [c13f3ddf] cpuidle_idle_call+0x9f/0x1c0 [c100ba68] arch_cpu_idle+0x8/0x20 [c1084272] cpu_startup_entry+0xe2/0x110 [c1025018] start_secondary+0x1a8/0x210 Code: 8d b6 00 00 00 00 3d ff ff ff 7f 77 e0 89 43 08 8b 45 f0 83 c4 04 5b 5e 5f 5d c3 8d 76 00 89 e2 81 e2 00 e0 ff ff f3 90 8b 42 08 a8 08 75 97 8b 42 08 f6 c4 02 75 8f eb ed 8d b6 00 00 00 00 8d NMI backtrace for cpu 0 CPU: 0 PID: 35 Comm: irq/43-xhci_hcd Not tainted 3.12.5-plx #6 Hardware name: PEGATRON CORPORATION SAISHIAT2/IPPCR-SS, BIOS 0308 10/31/2012 task: f58f8da0 ti: f590 task.ti: f590 EIP: 0060:[c1027c38] EFLAGS: 0046 CPU: 0 EIP is at default_send_IPI_mask_logical+0x78/0xa0 EAX: 0c00 EBX: 0300 ECX: c163d200 EDX: f000 ESI: 0c00 EDI: 0006 EBP: f5901ba8 ESP: f5901b94 DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 CR0: 80050033 CR2: b7ec2417 CR3: 35166000 CR4: 000407b0 Stack: 0006 0002 2710 26c8 c1641140 f5901bb8 c1027d70 2710 26c8 f5901bc8 c1027f31 c15d69cd f67c1c60 f5901c14 c10a987b c1603e90 000927c9 026b 026a 26c8 aea0554e f5901bf0 f5901c14 Call Trace: [c1027d70] default_send_IPI_all+0x80/0x90 [c1027f31] arch_trigger_all_cpu_backtrace+0x41/0x70 [c10a987b] rcu_check_callbacks+0x2db/0x650 [c106491d] ? scheduler_tick+0xad/0x120 [c1044f15] update_process_times+0x45/0x60 [c109282a] tick_handle_periodic+0x3a/0x1f0 [c10264d4] smp_apic_timer_interrupt+0x54/0x90 [c1508042] apic_timer_interrupt+0x2a/0x30 [c13a55b2] ? inc_enq+0x12/0x170 [c13aa59c] xhci_queue_isoc_tx_prepare+0x39c/0x950 [c10264d9] ? smp_apic_timer_interrupt+0x59/0x90 [c139d35f] xhci_urb_enqueue+0x22f/0x540 [c1375745] usb_hcd_submit_urb+0x65/0x280 [c13e3029] ? uvc_video_decode_isoc+0x149/0x220 [c13777a0] usb_submit_urb+0x170/0x3a0 [c103cd06] ? irq_exit+0x56/0x70 [c13e1ee8] uvc_video_complete+0xb8/0xd0 [c1374625] __usb_hcd_giveback_urb+0x45/0xa0 [c1374bd8] usb_hcd_giveback_urb+0x38/0xf0 [c13a84cf] handle_tx_event+0x3af/0xda0 [c103cd06] ? irq_exit+0x56/0x70 [c10264d9] ? smp_apic_timer_interrupt+0x59/0x90 [c15088a9] ? common_interrupt+0x29/0x2e [c13a9082] xhci_irq+0x1a2/0x6c0 [c1508042] ? apic_timer_interrupt+0x2a/0x30 [c13a95aa] xhci_msi_irq+0xa/0x10 [c1084c31] irq_forced_thread_fn+0x21/0x70 [c1085046] irq_thread+0x106/0x220 [c1084c10] ? irq_finalize_oneshot.part.40+0xc0/0xc0 [c1084cc0] ? irq_thread_fn+0x40/0x40 [c1057110] kthread+0xd0/0xe0 [c1084f40] ? set_affinity_thread+0x140/0x140 [c15083b7] ret_from_kernel_thread+0x1b/0x28 [c1057040] ? kthread_flush_work_fn+0x10/0x10 Code: 80 e5 10 75 ee c1 e3 18 89 98 10 c3 ff ff 89 d0 09 f0 81 ce 00 04 00 00 83 fa 02 8b 15 44 d5 63 c1 0f 44 c6 89 82 00 c3 ff ff 57 9d 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d c3 89 55 f0 ff 90 b4 00 INFO: NMI handler (arch_trigger_all_cpu_backtrace_handler) took too long to run: 71.797 msecs --- 3.2.53 - works fine :) signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] 3.12.1-rt4
[ cut here ] WARNING: CPU: 1 PID: 10 at kernel/time/tick-sched.c:191 0x8107bac6() NO_HZ FULL will not work with unstable sched clock Modules linked in: CPU: 1 PID: 10 Comm: rcuop/0 Not tainted 3.12.2-rt4 #3 Hardware name: TYAN Computer Corp. S2895/S2895, BIOS 2004Q3 11/18/2008 0009 88027fc83ea8 81501a58 0039 88027fc83ef8 88027fc83ee8 8102f992 00012700 ata3.00: configured for UDMA/100 88027fc8d580 0001 880272894020 88027fc0d700 Call Trace: [] 0x81501a58 [] 0x8102f992 [] 0x8102fa61 [] 0x8107bac6 [] 0x8107c8f4 [] 0x8103405d [] 0x81006fff [] 0x815085f7 [] ? 0x81007083 [] ? 0x81506865 [] ? 0x81095961 [] ? 0x81095860 [] 0x8104d0dd [] ? 0x8104d030 [] 0x8150763c [] ? 0x8104d030 ---[ end trace 53ca152639ff2a59 ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.12.1-rt4
[ cut here ] WARNING: CPU: 1 PID: 10 at kernel/time/tick-sched.c:191 0x8107bac6() NO_HZ FULL will not work with unstable sched clock Modules linked in: CPU: 1 PID: 10 Comm: rcuop/0 Not tainted 3.12.2-rt4 #3 Hardware name: TYAN Computer Corp. S2895/S2895, BIOS 2004Q3 11/18/2008 0009 88027fc83ea8 81501a58 0039 88027fc83ef8 88027fc83ee8 8102f992 00012700 ata3.00: configured for UDMA/100 88027fc8d580 0001 880272894020 88027fc0d700 Call Trace: IRQ [81501a58] 0x81501a58 [8102f992] 0x8102f992 [8102fa61] 0x8102fa61 [8107bac6] 0x8107bac6 [8107c8f4] 0x8107c8f4 [8103405d] 0x8103405d [81006fff] 0x81006fff [815085f7] 0x815085f7 EOI [81007083] ? 0x81007083 [81506865] ? 0x81506865 [81095961] ? 0x81095961 [81095860] ? 0x81095860 [8104d0dd] 0x8104d0dd [8104d030] ? 0x8104d030 [8150763c] 0x8150763c [8104d030] ? 0x8104d030 ---[ end trace 53ca152639ff2a59 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1
07.08.2012 21:24, Alan Stern пишет: On Tue, 7 Aug 2012, Pavel Vasilyev wrote: 06.08.2012 23:59, Alan Stern пишет: On Mon, 6 Aug 2012, Pavel Vasilyev wrote: http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux Interestingly, many (all?) of the changes in that patch are wrong because they don't try to match the terminating '\0'. As a result, they will match against extensions of the target string as well as the target string itself. strNcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L270 memcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L651 Yes. So if s contains "abcde" then memcmp(s, "abc", 3) and strncmp(s, "abc", 3) will both return 0, and memcmp(s, "abc", 4) and strncmp(s, "abc", 4) will both return 1. No matter what is contained in *s, "abcde" or "abcxxx", are important first N bytes. The second example, you see, a little bit stupid, and devoid of logic. :) Maybe yes, maybe no. It all depends on what you want. For example, if you're looking for "on" or "off", what should you do when the user writes "onoff"? You could accept it as meaning the same as "on", but if you were being careful then you would want to reject it as a meaningless value. The users should't be allowed to think! There is "on" - the size of 2 bytes, or "off" - 3 bytes, other variations - user error. We do not create a kernel with artificial intelligence? ;) -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] ACPI: replace strlen(string) with sizeof(string) -1
07.08.2012 21:24, Alan Stern пишет: On Tue, 7 Aug 2012, Pavel Vasilyev wrote: 06.08.2012 23:59, Alan Stern пишет: On Mon, 6 Aug 2012, Pavel Vasilyev wrote: http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux Interestingly, many (all?) of the changes in that patch are wrong because they don't try to match the terminating '\0'. As a result, they will match against extensions of the target string as well as the target string itself. strNcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L270 memcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L651 Yes. So if s contains abcde then memcmp(s, abc, 3) and strncmp(s, abc, 3) will both return 0, and memcmp(s, abc, 4) and strncmp(s, abc, 4) will both return 1. No matter what is contained in *s, abcde or abcxxx, are important first N bytes. The second example, you see, a little bit stupid, and devoid of logic. :) Maybe yes, maybe no. It all depends on what you want. For example, if you're looking for on or off, what should you do when the user writes onoff? You could accept it as meaning the same as on, but if you were being careful then you would want to reject it as a meaningless value. The users should't be allowed to think! There is on - the size of 2 bytes, or off - 3 bytes, other variations - user error. We do not create a kernel with artificial intelligence? ;) -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1
06.08.2012 23:59, Alan Stern пишет: On Mon, 6 Aug 2012, Pavel Vasilyev wrote: http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux Interestingly, many (all?) of the changes in that patch are wrong because they don't try to match the terminating '\0'. As a result, they will match against extensions of the target string as well as the target string itself. strNcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L270 memcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L651 Yes. So if s contains "abcde" then memcmp(s, "abc", 3) and strncmp(s, "abc", 3) will both return 0, and memcmp(s, "abc", 4) and strncmp(s, "abc", 4) will both return 1. No matter what is contained in *s, "abcde" or "abcxxx", are important first N bytes. The second example, you see, a little bit stupid, and devoid of logic. :) -- Pavel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1
06.08.2012 20:28, Alan Stern пишет:
On Mon, 6 Aug 2012, Pavel Vasilyev wrote:
06.08.2012 18:36, Alan Stern пишет:
On Mon, 6 Aug 2012, Pavel Machek wrote:
On Thu 2012-07-26 21:39:38, Len Brown wrote:
...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.
What about introducing something like streq() to do this
automatically? This is ugly
#define streq(a, b) ... if (_buildin_constant(b)) ...
?
- if (!strncmp(val, "enable", strlen("enable"))) {
+ if (!strncmp(val, "enable", sizeof("enable") - 1)) {
While you're at it, there's no point using strncmp when you know the
length of one of the strings beforehand. Just use memcmp, and don't
subtract 1 from the sizeof value.
http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux
Interestingly, many (all?) of the changes in that patch are wrong
because they don't try to match the terminating '\0'. As a result,
they will match against extensions of the target string as well as the
target string itself.
strNcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L270
memcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L651
--
Pavel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1
06.08.2012 18:36, Alan Stern пишет:
On Mon, 6 Aug 2012, Pavel Machek wrote:
On Thu 2012-07-26 21:39:38, Len Brown wrote:
...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.
What about introducing something like streq() to do this
automatically? This is ugly
#define streq(a, b) ... if (_buildin_constant(b)) ...
?
- if (!strncmp(val, "enable", strlen("enable"))) {
+ if (!strncmp(val, "enable", sizeof("enable") - 1)) {
While you're at it, there's no point using strncmp when you know the
length of one of the strings beforehand. Just use memcmp, and don't
subtract 1 from the sizeof value.
http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux
:)
--
Pavel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] ACPI: replace strlen(string) with sizeof(string) -1
06.08.2012 18:36, Alan Stern пишет:
On Mon, 6 Aug 2012, Pavel Machek wrote:
On Thu 2012-07-26 21:39:38, Len Brown wrote:
...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.
What about introducing something like streq() to do this
automatically? This is ugly
#define streq(a, b) ... if (_buildin_constant(b)) ...
?
- if (!strncmp(val, enable, strlen(enable))) {
+ if (!strncmp(val, enable, sizeof(enable) - 1)) {
While you're at it, there's no point using strncmp when you know the
length of one of the strings beforehand. Just use memcmp, and don't
subtract 1 from the sizeof value.
http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux
:)
--
Pavel.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] ACPI: replace strlen(string) with sizeof(string) -1
06.08.2012 20:28, Alan Stern пишет:
On Mon, 6 Aug 2012, Pavel Vasilyev wrote:
06.08.2012 18:36, Alan Stern пишет:
On Mon, 6 Aug 2012, Pavel Machek wrote:
On Thu 2012-07-26 21:39:38, Len Brown wrote:
...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.
What about introducing something like streq() to do this
automatically? This is ugly
#define streq(a, b) ... if (_buildin_constant(b)) ...
?
- if (!strncmp(val, enable, strlen(enable))) {
+ if (!strncmp(val, enable, sizeof(enable) - 1)) {
While you're at it, there's no point using strncmp when you know the
length of one of the strings beforehand. Just use memcmp, and don't
subtract 1 from the sizeof value.
http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux
Interestingly, many (all?) of the changes in that patch are wrong
because they don't try to match the terminating '\0'. As a result,
they will match against extensions of the target string as well as the
target string itself.
strNcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L270
memcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L651
--
Pavel.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] ACPI: replace strlen(string) with sizeof(string) -1
06.08.2012 23:59, Alan Stern пишет: On Mon, 6 Aug 2012, Pavel Vasilyev wrote: http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=41157;list=linux Interestingly, many (all?) of the changes in that patch are wrong because they don't try to match the terminating '\0'. As a result, they will match against extensions of the target string as well as the target string itself. strNcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L270 memcmp compare N bytes - http://lxr.linux.no/#linux+v3.5/lib/string.c#L651 Yes. So if s contains abcde then memcmp(s, abc, 3) and strncmp(s, abc, 3) will both return 0, and memcmp(s, abc, 4) and strncmp(s, abc, 4) will both return 1. No matter what is contained in *s, abcde or abcxxx, are important first N bytes. The second example, you see, a little bit stupid, and devoid of logic. :) -- Pavel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
