Menu
▾
▴
user-mode-linux-user
You can subscribe to this list here.
| 1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(15) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2000 |
Jan
(6) |
Feb
(1) |
Mar
(39) |
Apr
(13) |
May
(24) |
Jun
(11) |
Jul
(23) |
Aug
(85) |
Sep
(12) |
Oct
(103) |
Nov
(79) |
Dec
(112) |
| 2001 |
Jan
(52) |
Feb
(82) |
Mar
(84) |
Apr
(65) |
May
(105) |
Jun
(188) |
Jul
(174) |
Aug
(182) |
Sep
(103) |
Oct
(137) |
Nov
(143) |
Dec
(98) |
| 2002 |
Jan
(258) |
Feb
(236) |
Mar
(386) |
Apr
(307) |
May
(238) |
Jun
(170) |
Jul
(252) |
Aug
(230) |
Sep
(278) |
Oct
(394) |
Nov
(336) |
Dec
(194) |
| 2003 |
Jan
(290) |
Feb
(182) |
Mar
(175) |
Apr
(220) |
May
(209) |
Jun
(286) |
Jul
(279) |
Aug
(164) |
Sep
(208) |
Oct
(324) |
Nov
(204) |
Dec
(380) |
| 2004 |
Jan
(344) |
Feb
(332) |
Mar
(395) |
Apr
(357) |
May
(349) |
Jun
(352) |
Jul
(279) |
Aug
(269) |
Sep
(374) |
Oct
(442) |
Nov
(428) |
Dec
(253) |
| 2005 |
Jan
(225) |
Feb
(219) |
Mar
(245) |
Apr
(249) |
May
(203) |
Jun
(157) |
Jul
(171) |
Aug
(194) |
Sep
(200) |
Oct
(232) |
Nov
(190) |
Dec
(195) |
| 2006 |
Jan
(158) |
Feb
(190) |
Mar
(235) |
Apr
(161) |
May
(134) |
Jun
(169) |
Jul
(117) |
Aug
(161) |
Sep
(170) |
Oct
(297) |
Nov
(230) |
Dec
(205) |
| 2007 |
Jan
(197) |
Feb
(132) |
Mar
(151) |
Apr
(97) |
May
(109) |
Jun
(99) |
Jul
(57) |
Aug
(110) |
Sep
(56) |
Oct
(119) |
Nov
(39) |
Dec
(45) |
| 2008 |
Jan
(101) |
Feb
(116) |
Mar
(141) |
Apr
(98) |
May
(133) |
Jun
(61) |
Jul
(43) |
Aug
(76) |
Sep
(20) |
Oct
(32) |
Nov
(22) |
Dec
(41) |
| 2009 |
Jan
(35) |
Feb
(15) |
Mar
(18) |
Apr
(13) |
May
(13) |
Jun
(26) |
Jul
(12) |
Aug
(32) |
Sep
(21) |
Oct
(41) |
Nov
(35) |
Dec
(12) |
| 2010 |
Jan
(3) |
Feb
(35) |
Mar
(28) |
Apr
(20) |
May
(5) |
Jun
(14) |
Jul
(6) |
Aug
(8) |
Sep
(20) |
Oct
(20) |
Nov
(10) |
Dec
(12) |
| 2011 |
Jan
(14) |
Feb
(10) |
Mar
(14) |
Apr
(14) |
May
(13) |
Jun
(43) |
Jul
(13) |
Aug
(50) |
Sep
(30) |
Oct
(23) |
Nov
(15) |
Dec
(49) |
| 2012 |
Jan
(15) |
Feb
(28) |
Mar
(7) |
Apr
|
May
(12) |
Jun
(13) |
Jul
(28) |
Aug
(11) |
Sep
(19) |
Oct
(27) |
Nov
(5) |
Dec
(25) |
| 2013 |
Jan
(18) |
Feb
(19) |
Mar
(56) |
Apr
(26) |
May
(38) |
Jun
(24) |
Jul
(42) |
Aug
(24) |
Sep
(4) |
Oct
(3) |
Nov
(18) |
Dec
(4) |
| 2014 |
Jan
(10) |
Feb
(9) |
Mar
(3) |
Apr
|
May
(12) |
Jun
(34) |
Jul
(8) |
Aug
(18) |
Sep
(3) |
Oct
(27) |
Nov
(2) |
Dec
(1) |
| 2015 |
Jan
|
Feb
(10) |
Mar
(49) |
Apr
(2) |
May
(4) |
Jun
(7) |
Jul
(1) |
Aug
(17) |
Sep
(7) |
Oct
(35) |
Nov
(40) |
Dec
(4) |
| 2016 |
Jan
(9) |
Feb
|
Mar
(6) |
Apr
|
May
(10) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
(4) |
May
(31) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Richard W. <ri...@no...> - 2012-12-30 09:41:01
|
Am Sun, 30 Dec 2012 01:37:31 +0300 schrieb Sergei Trofimovich <sl...@ge...>: > arch/um/os-Linux/signal.c:18:8: error: conflicting types for > 'sig_info' In file included > from /home/slyfox/linux-2.6/arch/um/os-Linux/signal.c:12:0: > arch/um/include/shared/as-layout.h:64:15: note: previous declaration > of 'sig_info' was here > > Signed-off-by: Sergei Trofimovich <sl...@ge...> > CC: Jeff Dike <jd...@ad...> > CC: Richard Weinberger <ri...@no...> > CC: "Martin Pärtel" <mar...@gm...> > CC: Al Viro <vi...@ze...> > CC: use...@li... > CC: use...@li... > CC: lin...@vg... > --- I think both patches need to be backported to -stable. I'll add the tag and push the patches ASAP to Linus. Thanks, //richard |
|
From: Sergei T. <sl...@ge...> - 2012-12-29 22:38:21
|
arch/um/os-Linux/start_up.c: In function 'check_coredump_limit': arch/um/os-Linux/start_up.c:338:16: error: storage size of 'lim' isn't known arch/um/os-Linux/start_up.c:339:2: error: implicit declaration of function 'getrlimit' [-Werror=implicit-function-declaration] Signed-off-by: Sergei Trofimovich <sl...@ge...> CC: Jeff Dike <jd...@ad...> CC: Richard Weinberger <ri...@no...> CC: Al Viro <vi...@ze...> CC: use...@li... CC: use...@li... CC: lin...@vg... --- arch/um/os-Linux/start_up.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/um/os-Linux/start_up.c b/arch/um/os-Linux/start_up.c index da4b9e9..337518c 100644 --- a/arch/um/os-Linux/start_up.c +++ b/arch/um/os-Linux/start_up.c @@ -15,6 +15,8 @@ #include <sys/mman.h> #include <sys/stat.h> #include <sys/wait.h> +#include <sys/time.h> +#include <sys/resource.h> #include <asm/unistd.h> #include <init.h> #include <os.h> -- 1.8.0.2 |
|
From: Sergei T. <sl...@ge...> - 2012-12-29 22:38:21
|
arch/um/os-Linux/signal.c:18:8: error: conflicting types for 'sig_info'
In file included from /home/slyfox/linux-2.6/arch/um/os-Linux/signal.c:12:0:
arch/um/include/shared/as-layout.h:64:15: note: previous declaration of 'sig_info' was here
Signed-off-by: Sergei Trofimovich <sl...@ge...>
CC: Jeff Dike <jd...@ad...>
CC: Richard Weinberger <ri...@no...>
CC: "Martin Pärtel" <mar...@gm...>
CC: Al Viro <vi...@ze...>
CC: use...@li...
CC: use...@li...
CC: lin...@vg...
---
arch/um/os-Linux/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/um/os-Linux/signal.c b/arch/um/os-Linux/signal.c
index b1469fe..9d9f1b4 100644
--- a/arch/um/os-Linux/signal.c
+++ b/arch/um/os-Linux/signal.c
@@ -15,7 +15,7 @@
#include <sysdep/mcontext.h>
#include "internal.h"
-void (*sig_info[NSIG])(int, siginfo_t *, struct uml_pt_regs *) = {
+void (*sig_info[NSIG])(int, struct siginfo *, struct uml_pt_regs *) = {
[SIGTRAP] = relay_signal,
[SIGFPE] = relay_signal,
[SIGILL] = relay_signal,
--
1.8.0.2
|
|
From: Kieran G. <kie...@gm...> - 2012-12-26 01:13:46
|
Just a continuation of my previous email, I have since compiled UML with v3.7 from Linux-next, the bug appears there too. The dumped process still exists as a zombie process as long as the rest of the UML session is running. It doesn't have anything to do with my Debian based UML environment it was booting, it occurred even with a UML BusyBox file-system. My config for the v3.7 is attached, did I stuff up my config somewhere? Some more info Core was generated by `./Linux-3.7.0-uml mem=512M eth0=tuntap,tap0 ubd0=BusyBox-1.13.2-amd64-root_fs'. Program terminated with signal 11, Segmentation fault. #0 0x0000000060053b8a in sigsuspend (set=0x807bef28) at kernel/signal.c:3264 Registers: rax 0x0 0 rbx 0x10 16 rcx 0x6034a330 1614062384 rdx 0x0 0 rsi 0x807befb7 2155605943 rdi 0x807bef28 2155605800 rbp 0x807bef18 0x807bef18 rsp 0x807bef08 0x807bef08 r8 0x1e2d8 123608 r9 0x807befe8 2155605992 r10 0x807bee78 2155605624 r11 0x246 582 r12 0x6034a380 1614062464 r13 0x60053b60 1610955616 r14 0x603a196c 1614420332 r15 0x60f7c840 1626851392 rip 0x60053b8a 0x60053b8a <sigsuspend+42> eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x63 99 gs 0x0 0 Disassemble: 3264 current->saved_sigmask = current->blocked; 0x0000000060053b76 <+22>: 48 8b 10 mov (%rax),%rdx (rdx becomes zero, not a good sign) 0x0000000060053b87 <+39>: 48 8b 00 mov (%rax),%rax (the same zero gets loaded into rax) => 0x0000000060053b8a <+42>: 48 8b 80 38 07 00 00 mov 0x738(%rax),%rax (and we dereference it) 0x0000000060053b91 <+49>: 48 89 82 48 07 00 00 mov %rax,0x748(%rdx) Yay, a NULL pointer dereference bug :/ From, Kieran Grant |
|
From: Kieran G. <kie...@gm...> - 2012-12-25 01:28:06
|
Hey all,
I just compiled uml of the linux-next tree (at commit
3979da72b0f2453dcf625e8ba4a8085e9562523b) using distcc, in case that
shouldn't be using for kernel builds as well as 3.8.0-rc1 without distcc
and I get a core file generated during boot process on host.
config file for both versions and start up info for linux-next of uml
processes attached.
I'm booting with an image of Debian 6.0 (straight from debootstrap with
stable, plus installed vim, and some other goodies on it, plus nginx),
it creates a core file on host, uml keeps booting and shows no message
at all about why the core file is generated.
GDB says for linux-next:
Core was generated by `./linux-3.8.0-rc1-next-20121224-uml mem=512M
ubd0=./fs eth0=tuntap,tap0'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000600371e5 in sigsuspend (set=0x7f37df50) at
kernel/signal.c:3329
3329 current->saved_sigmask = current->blocked;
(gdb) bt full
#0 0x00000000600371e5 in sigsuspend (set=0x7f37df50) at
kernel/signal.c:3329
No locals.
#1 0x0000000060015504 in winch_thread (arg=<optimised out>)
at arch/um/drivers/chan_user.c:210
data = <optimised out>
sigs = {__val = {18446744067132882943,
18446744073709551615 <repeats 15 times>}}
pty_fd = 16
pipe_fd = 18
count = <optimised out>
c = 1 '\001'
#2 0x000000006027e599 in clone ()
No symbol table info available.
#3 0x0000000000000000 in ?? ()
And for 3.8.0-rc1:
Core was generated by `./linux-3.8.0-rc1-uml mem=512M ubd0=./fs
eth0=tuntap,tap0'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000060047ba0 in sigsuspend (set=0x81291f40) at
kernel/signal.c:3329
3329 current->saved_sigmask = current->blocked;
(gdb) bt full
#0 0x0000000060047ba0 in sigsuspend (set=0x81291f40) at
kernel/signal.c:3329
No locals.
#1 0x000000006001d86e in winch_thread (arg=<optimised out>) at
arch/um/drivers/chan_user.c:210
data = <optimised out>
sigs = {__val = {18446744067132882943, 18446744073709551615
<repeats 15 times>}}
pty_fd = <optimised out>
pipe_fd = 21
count = <optimised out>
c = 1 '\001'
#2 0x0000000060303939 in clone ()
No symbol table info available.
#3 0x0000000000000000 in ?? ()
No symbol table info available.
Any ideas?
From,
Kieran Grant
|
|
From: Sasha L. <sas...@or...> - 2012-12-20 19:14:25
|
Signed-off-by: Sasha Levin <sas...@or...>
---
arch/x86/um/fault.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/um/fault.c b/arch/x86/um/fault.c
index 8784ab3..84ac7f7 100644
--- a/arch/x86/um/fault.c
+++ b/arch/x86/um/fault.c
@@ -20,7 +20,7 @@ int arch_fixup(unsigned long address, struct uml_pt_regs *regs)
const struct exception_table_entry *fixup;
fixup = search_exception_tables(address);
- if (fixup != 0) {
+ if (fixup) {
UPT_IP(regs) = fixup->fixup;
return 1;
}
--
1.8.0
|
|
From: Toralf F. <tor...@gm...> - 2012-12-20 16:34:08
|
Hello,
I got the following warning from an UML guest (32 bit Gentoo Linux, linux-v3.7-11091-gf01af9f)
and wonder now whether this worth to be reported to the LKML or not :
* Starting local
[ ok ]
------------[ cut here ]------------
WARNING: at kernel/mutex-debug.c:65 mutex_remove_waiter+0xbe/0xf0()
39667d3c: [<0833b538>] dump_stack+0x22/0x24
39667d54: [<0807d61a>] warn_slowpath_common+0x5a/0x80
39667d7c: [<0807d6e3>] warn_slowpath_null+0x23/0x30
39667d8c: [<080b2cde>] mutex_remove_waiter+0xbe/0xf0
39667da4: [<0833f1c6>] __mutex_lock_slowpath+0x1d6/0x210
39667ddc: [<0833f212>] mutex_lock+0x12/0x30
39667df0: [<081394f5>] ep_scan_ready_list.isra.21+0x25/0x160
39667e28: [<0813a379>] sys_epoll_wait+0x319/0x400
39667eac: [<08062af2>] handle_syscall+0x82/0xb0
39667ef4: [<08074f3d>] userspace+0x46d/0x590
39667fec: [<0805f7cc>] fork_handler+0x6c/0x70
39667ffc: [<00000000>] 0x0
---[ end trace 91e04670b2a3768e ]---
EIP: 0073:[<0000014a>] CPU: 0 Tainted: G W ESP: 007b:083ee1be EFLAGS: 00010286
Tainted: G W
EAX: 00008282 EBX: 08409788 ECX: 08409788 EDX: 084003c0
ESI: 083feb0c EDI: 083feba0 EBP: 083f64db DS: 007b ES: 007b
083fe74c: [<0807978f>] show_regs+0x10f/0x120
083fe768: [<08061f72>] segv+0x62/0x2b0
083fe818: [<08062233>] segv_handler+0x73/0x80
083fe840: [<08071af8>] sig_handler_common+0xb8/0xe0
083feac4: [<08071c3d>] sig_handler+0x3d/0x50
083fead4: [<0807178b>] hard_handler+0x6b/0xa0
083feafc: [<b77bb40c>] 0xb77bb40c
Kernel panic - not syncing: Segfault with no mm
083fe728: [<0833b538>] dump_stack+0x22/0x24
083fe740: [<0833b5b4>] panic+0x7a/0x18b
083fe768: [<08061f7e>] segv+0x6e/0x2b0
083fe818: [<08062233>] segv_handler+0x73/0x80
083fe840: [<08071af8>] sig_handler_common+0xb8/0xe0
083feac4: [<08071c3d>] sig_handler+0x3d/0x50
083fead4: [<0807178b>] hard_handler+0x6b/0xa0
083feafc: [<b77bb40c>] 0xb77bb40c
EIP: 0073:[<b77bb424>] CPU: 0 Tainted: G W ESP: 007b:bfab4cb4 EFLAGS: 00000286
Tainted: G W
EAX: 00000000 EBX: 00002c46 ECX: 00000013 EDX: 00002c46
ESI: 00002c42 EDI: bfab4d48 EBP: bfab4ce8 DS: 007b ES: 007b
083fe6dc: [<0807978f>] show_regs+0x10f/0x120
083fe6f8: [<0806259c>] panic_exit+0x2c/0x50
083fe708: [<0809e158>] notifier_call_chain+0x38/0x60
083fe730: [<0809e2a3>] atomic_notifier_call_chain+0x23/0x30
083fe740: [<0833b5dc>] panic+0xa2/0x18b
083fe768: [<08061f7e>] segv+0x6e/0x2b0
083fe818: [<08062233>] segv_handler+0x73/0x80
083fe840: [<08071af8>] sig_handler_common+0xb8/0xe0
083feac4: [<08071c3d>] sig_handler+0x3d/0x50
083fead4: [<0807178b>] hard_handler+0x6b/0xa0
083feafc: [<b77bb40c>] 0xb77bb40c
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
|
|
From: Toralf F. <tor...@gm...> - 2012-12-17 23:12:40
|
This is still related to investigate an issue with a hanging UML/crashing UML (32 bit Gentoo Linux as host and guest).
The following output was derived from the gdb - does it contain any helpful information ?
The host kernel is 3.7.1, the guest ran a linux-v3.7-9431-gfa4c95b kernel
0x0805f27c in from_irq_stack (nested=0) at arch/um/kernel/irq.c:462
462 current->stack = to;
(gdb) cont
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x0805f27c in from_irq_stack (nested=0) at arch/um/kernel/irq.c:462
462 current->stack = to;
(gdb) bt
#0 0x0805f27c in from_irq_stack (nested=0) at arch/um/kernel/irq.c:462
#1 0x080717dd in hard_handler (sig=<optimized out>, si=0x83fdb0c <cpu0_irqstack+2828>,
p=0x83fdb8c <cpu0_irqstack+2956>) at arch/um/os-Linux/signal.c:175
#2 <signal handler called>
#3 get_symbol_pos (addr=134759829, symbolsize=0x383e9170, offset=0x383e916c)
at kernel/kallsyms.c:219
#4 0x080b728e in kallsyms_lookup (addr=134759829, symbolsize=0x383e9170, offset=0x383e916c,
modname=0x383e9168, namebuf=0x383e91a1 "") at kernel/kallsyms.c:295
#5 0x080b7327 in __sprint_symbol (buffer=0x383e91a1 "", address=134759829, symbol_offset=0,
add_offset=1) at kernel/kallsyms.c:354
#6 0x080b74da in sprint_symbol (buffer=0x383e91a1 "", address=134759829) at kernel/kallsyms.c:385
#7 0x082677d7 in symbol_string (buf=0x84c8343 <textbuf.25117+35> "---\n",
end=0x84c8700 <cont> "Netdevice 0 (72:ef:3d:35:64:64) : xes 6 to 9)e...No, enabling workaround",
ptr=<optimized out>, ext=83 'S', spec=...) at lib/vsprintf.c:537
#8 0x0826814d in pointer (fmt=<optimized out>, buf=0x84c8343 <textbuf.25117+35> "---\n",
end=<optimized out>, ptr=0x8084595 <local_bh_enable+69>, spec=...) at lib/vsprintf.c:1054
#9 0x08267f1a in vsnprintf (
buf=0x84c8320 <textbuf.25117> "\001\064WARNING: at kernel/softirq.c:160 ---\n", size=992,
fmt=0x83aec3a "pS()\n", args=0x383e93a0 "\225E\b\b") at lib/vsprintf.c:1442
#10 0x08268467 in vscnprintf (
buf=0x84c8320 <textbuf.25117> "\001\064WARNING: at kernel/softirq.c:160 ---\n", size=992,
fmt=0x83aec25 "\001\064WARNING: at %s:%d %pS()\n", args=0x383e9394 "\034\355:\b\240")
at lib/vsprintf.c:1548
#11 0x0807eff8 in vprintk_emit (facility=0, level=-1, dict=0x0, dictlen=0,
fmt=0x83aec25 "\001\064WARNING: at %s:%d %pS()\n", args=0x383e9394 "\034\355:\b\240")
at kernel/printk.c:1545
#12 0x0833a37d in printk (fmt=0x83aec25 "\001\064WARNING: at %s:%d %pS()\n") at kernel/printk.c:1687
#13 0x0807d630 in warn_slowpath_common (file=0x83aed1c "kernel/softirq.c", line=160,
caller=<optimized out>, taint=9, args=0x0) at kernel/panic.c:413
---Type <return> to continue, or q <return> to quit---
#14 0x0807d713 in warn_slowpath_null (file=0x83aed1c "kernel/softirq.c", line=160)
at kernel/panic.c:454
#15 0x08084595 in _local_bh_enable_ip (ip=<optimized out>) at kernel/softirq.c:160
#16 local_bh_enable () at kernel/softirq.c:187
#17 0x082aa680 in rcu_read_unlock_bh () at include/linux/rcupdate.h:827
#18 dev_queue_xmit (skb=0x381c6e40) at net/core/dev.c:2735
#19 0x082ccaa2 in neigh_hh_output (skb=<optimized out>, hh=<optimized out>)
at include/net/neighbour.h:356
#20 dst_neigh_output (skb=0x381c6e40, n=0x3841d900, dst=<optimized out>) at include/net/dst.h:412
#21 ip_finish_output2 (skb=0x381c6e40) at net/ipv4/ip_output.c:201
#22 ip_finish_output (skb=<optimized out>) at net/ipv4/ip_output.c:234
#23 0x082ccb43 in ip_output (skb=0x381c6e40) at net/ipv4/ip_output.c:307
#24 0x082cbb23 in dst_output (skb=0x381c6e40) at include/net/dst.h:449
#25 ip_local_out (skb=0x381c6e40) at net/ipv4/ip_output.c:110
#26 0x082cbcce in ip_build_and_send_pkt (skb=0x381c6e40, sk=0x382b0a00, saddr=1090562240,
daddr=4261456064, opt=0x0) at net/ipv4/ip_output.c:162
#27 0x082e874a in tcp_v4_conn_request (sk=0x382b0a00, skb=0x381c6780) at net/ipv4/tcp_ipv4.c:1646
#28 0x082df88c in tcp_rcv_state_process (sk=0x382b0a00, skb=0x381c6780, th=0x38269562, len=40)
at net/ipv4/tcp_input.c:5942
#29 0x082e6577 in tcp_v4_do_rcv (sk=0x382b0a00, skb=0x381c6780) at net/ipv4/tcp_ipv4.c:1890
#30 0x082e90fe in tcp_v4_rcv (skb=0x381c6780) at net/ipv4/tcp_ipv4.c:2030
#31 0x082c82be in ip_local_deliver_finish (skb=0x381c6780) at net/ipv4/ip_input.c:225
#32 ip_local_deliver (skb=0x381c6780) at net/ipv4/ip_input.c:263
#33 0x082c87ca in dst_input (skb=0x381c6780) at include/net/dst.h:455
#34 ip_rcv_finish (skb=0x381c6780) at net/ipv4/ip_input.c:373
#35 ip_rcv (skb=<optimized out>, dev=0x380f2000, pt=0x841fcc0 <ip_packet_type>, orig_dev=0x380f2000)
at net/ipv4/ip_input.c:451
#36 0x082a7c70 in __netif_receive_skb (skb=0x381c6780) at net/core/dev.c:3456
#37 0x082a7d39 in process_backlog (napi=0x8422600 <softnet_data+64>, quota=1) at net/core/dev.c:3925
---Type <return> to continue, or q <return> to quit---
#38 0x082ab412 in net_rx_action (h=0x84c8fcc <softirq_vec+12>) at net/core/dev.c:4083
#39 0x080843d2 in __do_softirq () at kernel/softirq.c:247
#40 0x08084536 in do_softirq () at kernel/softirq.c:295
#41 0x0808473d in invoke_softirq () at kernel/softirq.c:329
#42 irq_exit () at kernel/softirq.c:348
#43 0x0805ee8a in do_IRQ (irq=5, regs=0x383e9820) at arch/um/kernel/irq.c:295
#44 0x0805ef05 in sigio_handler (sig=29, unused_si=0x0, regs=0x383e9820) at arch/um/kernel/irq.c:53
#45 0x08071b28 in sig_handler_common (sig=29, si=0x0, mc=0x0) at arch/um/os-Linux/signal.c:44
#46 0x08071a4b in unblock_signals () at arch/um/os-Linux/signal.c:282
#47 0x08071bce in set_signals (enable=1) at arch/um/os-Linux/signal.c:302
#48 0x0808453e in arch_local_irq_restore (flags=1)
at /home/tfoerste/devel/linux/arch/um/include/asm/irqflags.h:16
#49 do_softirq () at kernel/softirq.c:297
#50 0x080845d7 in _local_bh_enable_ip (ip=<optimized out>) at kernel/softirq.c:176
#51 local_bh_enable () at kernel/softirq.c:187
#52 0x082ccac4 in rcu_read_unlock_bh () at include/linux/rcupdate.h:827
#53 ip_finish_output2 (skb=0x3817b0b0) at net/ipv4/ip_output.c:203
#54 ip_finish_output (skb=<optimized out>) at net/ipv4/ip_output.c:234
#55 0x082ccb43 in ip_output (skb=0x3817b0b0) at net/ipv4/ip_output.c:307
#56 0x082cbb23 in dst_output (skb=0x3817b0b0) at include/net/dst.h:449
#57 ip_local_out (skb=0x3817b0b0) at net/ipv4/ip_output.c:110
#58 0x082cbfdd in ip_queue_xmit (skb=0x3817b0b0, fl=0x382b15c8) at net/ipv4/ip_output.c:403
#59 0x082e1e77 in tcp_transmit_skb (sk=0x382b1400, skb=0x3817b0b0, clone_it=<optimized out>,
gfp_mask=32) at net/ipv4/tcp_output.c:1106
#60 0x082e288c in tcp_write_xmit (sk=0x382b1400, mss_now=1448, nonagle=1, push_one=0, gfp=32)
at net/ipv4/tcp_output.c:2029
#61 0x082e2a68 in __tcp_push_pending_frames (sk=0x382b1400, cur_mss=1448, nonagle=1)
at net/ipv4/tcp_output.c:2068
#62 0x082d4474 in tcp_push (nonagle=<optimized out>, mss_now=1448, flags=64, sk=0x382b1400)
---Type <return> to continue, or q <return> to quit---
at net/ipv4/tcp.c:636
#63 tcp_sendmsg (iocb=0x383e9d68, sk=0x382b1400, msg=0x383e9d20, size=826) at net/ipv4/tcp.c:1225
#64 0x082f75b3 in inet_sendmsg (iocb=0x383e9d68, sock=0x37cea900, msg=0x383e9d20, size=826)
at net/ipv4/af_inet.c:784
#65 0x082980ec in __sock_sendmsg_nosec (size=<optimized out>, msg=0x383e9d20, sock=0x37cea900,
iocb=0x383e9d68) at net/socket.c:628
#66 __sock_sendmsg (size=<optimized out>, msg=0x383e9d20, sock=0x37cea900, iocb=0x383e9d68)
at net/socket.c:636
#67 do_sock_write (nr_segs=2, iov=0x383e9e18, iocb=0x383e9d68, msg=0x383e9d20, file=<optimized out>)
at net/socket.c:974
#68 sock_aio_write (iocb=0x383e9d68, iov=0x383e9e18, nr_segs=2, pos=0) at net/socket.c:989
#69 0x081002f6 in do_sync_readv_writev (filp=0x3838a080, iov=0x383e9e18, nr_segs=2, len=826,
ppos=0x383e9e94, fn=0x8297fd0 <sock_aio_write>) at fs/read_write.c:572
#70 0x081005bf in do_readv_writev (type=1, file=0x3838a080, uvector=<optimized out>, nr_segs=2,
pos=0x383e9e94) at fs/read_write.c:730
#71 0x08100763 in vfs_writev (file=0x3838a080, vec=0x4b448bd0, vlen=2, pos=0x383e9e94)
at fs/read_write.c:768
#72 0x08100870 in sys_writev (fd=13, vec=0x4b448bd0, vlen=2) at fs/read_write.c:800
#73 0x08062b22 in handle_syscall (r=0x383ccd50) at arch/um/kernel/skas/syscall.c:35
#74 0x08074f6d in handle_trap (local_using_sysemu=<optimized out>, regs=0x383ccd50, pid=10301)
at arch/um/os-Linux/skas/process.c:193
#75 userspace (regs=0x383ccd50) at arch/um/os-Linux/skas/process.c:426
#76 0x0805f7fc in fork_handler () at arch/um/kernel/process.c:160
#77 0x00000002 in ?? ()
(
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
|
|
From: H. P. A. <hp...@zy...> - 2012-12-13 21:36:38
|
On 12/13/2012 11:05 AM, Borislav Petkov wrote: > > Ok, I grok it now. So, in most cases, mce.ip comes from pt_regs.ip which > is unsigned long so we're fine for both 32- and 64-bit. There's only the > case with precise RIP reporting where we get the rip from an MSR but > even then, it should be 4 bytes on 32-bit since our addresses there are > 4 bytes. > > So, actually struct mce should've had ->ip defined as an unsigned long > from the very beginning. But we can't change that now because this > struct is shared with userspace :( > Good thing, then,. otherwise we'd have a compat headache. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. |
|
From: Joe P. <jo...@pe...> - 2012-12-13 19:13:37
|
Use the new vsprintf extension to avoid any possible
message interleaving.
Signed-off-by: Joe Perches <jo...@pe...>
Acked-by: Tony Luck <ton...@in...>
Acked-by: Borislav Petkov <bp...@al...>
---
V2: mce.c: Add cast to (unsigned long) before cast to (void *)
to quiet the compiler on x86-32
arch/x86/kernel/cpu/mcheck/mce.c | 13 +++++++------
arch/x86/kernel/dumpstack.c | 5 ++---
arch/x86/kernel/process_32.c | 2 +-
arch/x86/mm/mmio-mod.c | 4 ++--
arch/x86/um/sysrq_32.c | 9 +++------
5 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 80dbda8..996f98a 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -242,13 +242,14 @@ static void print_mce(struct mce *m)
m->extcpu, m->mcgstatus, m->bank, m->status);
if (m->ip) {
- pr_emerg(HW_ERR "RIP%s %02x:<%016Lx> ",
- !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
- m->cs, m->ip);
-
if (m->cs == __KERNEL_CS)
- print_symbol("{%s}", m->ip);
- pr_cont("\n");
+ pr_emerg(HW_ERR "RIP%s %02x:<%016Lx> {%pSR}\n",
+ !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
+ m->cs, m->ip, (void *)(unsigned long)m->ip);
+ else
+ pr_emerg(HW_ERR "RIP%s %02x:<%016Lx>\n",
+ !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
+ m->cs, m->ip);
}
pr_emerg(HW_ERR "TSC %llx ", m->tsc);
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index ae42418b..b6e5bdb 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -281,9 +281,8 @@ int __kprobes __die(const char *str, struct pt_regs *regs, long err)
sp = kernel_stack_pointer(regs);
savesegment(ss, ss);
}
- printk(KERN_EMERG "EIP: [<%08lx>] ", regs->ip);
- print_symbol("%s", regs->ip);
- printk(" SS:ESP %04x:%08lx\n", ss, sp);
+ printk(KERN_EMERG "EIP: [<%08lx>] %pSR SS:ESP %04x:%08lx\n",
+ regs->ip, (void *)regs->ip, ss, sp);
#else
/* Executive summary in case the oops scrolled away */
printk(KERN_ALERT "RIP ");
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index b5a8905..0db77e0 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -89,7 +89,7 @@ void __show_regs(struct pt_regs *regs, int all)
printk(KERN_DEFAULT "EIP: %04x:[<%08lx>] EFLAGS: %08lx CPU: %d\n",
(u16)regs->cs, regs->ip, regs->flags,
smp_processor_id());
- print_symbol("EIP is at %s\n", regs->ip);
+ printk(KERN_DEFAULT "EIP is at %pSR\n", (void *)regs->ip);
printk(KERN_DEFAULT "EAX: %08lx EBX: %08lx ECX: %08lx EDX: %08lx\n",
regs->ax, regs->bx, regs->cx, regs->dx);
diff --git a/arch/x86/mm/mmio-mod.c b/arch/x86/mm/mmio-mod.c
index dc0b727..c0ca484 100644
--- a/arch/x86/mm/mmio-mod.c
+++ b/arch/x86/mm/mmio-mod.c
@@ -123,8 +123,8 @@ static void die_kmmio_nesting_error(struct pt_regs *regs, unsigned long addr)
pr_emerg("unexpected fault for address: 0x%08lx, last fault for address: 0x%08lx\n",
addr, my_reason->addr);
print_pte(addr);
- print_symbol(KERN_EMERG "faulting IP is at %s\n", regs->ip);
- print_symbol(KERN_EMERG "last faulting IP was at %s\n", my_reason->ip);
+ pr_emerg("faulting IP is at %pSR\n", (void *)regs->ip);
+ pr_emerg("last faulting IP was at %pSR\n", (void *)my_reason->ip);
#ifdef __i386__
pr_emerg("eax: %08lx ebx: %08lx ecx: %08lx edx: %08lx\n",
regs->ax, regs->bx, regs->cx, regs->dx);
diff --git a/arch/x86/um/sysrq_32.c b/arch/x86/um/sysrq_32.c
index c9bee5b..30b4200 100644
--- a/arch/x86/um/sysrq_32.c
+++ b/arch/x86/um/sysrq_32.c
@@ -50,18 +50,15 @@ static inline unsigned long print_context_stack(struct thread_info *tinfo,
#ifdef CONFIG_FRAME_POINTER
while (valid_stack_ptr(tinfo, (void *)ebp)) {
addr = *(unsigned long *)(ebp + 4);
- printk("%08lx: [<%08lx>]", ebp + 4, addr);
- print_symbol(" %s", addr);
- printk("\n");
+ printk("%08lx: [<%08lx>] %pSR\n", ebp + 4, addr, (void *)addr);
ebp = *(unsigned long *)ebp;
}
#else
while (valid_stack_ptr(tinfo, stack)) {
addr = *stack;
if (__kernel_text_address(addr)) {
- printk("%08lx: [<%08lx>]", (unsigned long) stack, addr);
- print_symbol(" %s", addr);
- printk("\n");
+ printk("%08lx: [<%08lx>] %pSR\n",
+ (unsigned long)stack, addr, (void *)addr);
}
stack++;
}
--
1.7.8.112.g3fd21
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj...@vg...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
|
From: Borislav P. <bp...@al...> - 2012-12-13 19:05:56
|
On Thu, Dec 13, 2012 at 10:42:28AM -0800, H. Peter Anvin wrote:
> On 12/13/2012 10:37 AM, Borislav Petkov wrote:
> >>
> >> If appropriate, the code could be changed to
> >>
> >> (void *)(unsigned long)m->ip
> >
> > Can we explicitly cast it to what it is so that we can be explicit as to
> > what we're casting it? IOW:
> >
> > (void *)(__u64)m->ip;
> >
> > Does that even work on 32bit?
> >
> > Also, does the compiler bitch about this useless cast when building with
> > W=123?
> >
>
> Uh... no.
>
> The point is that (void *)(unsigned long) casts it to an integer of
> pointer size -- in userspace you would to (void *)(size_t) or (void
> *)(uintptr_t) -- so that the compiler knows "I meant to do that."
Ok, I grok it now. So, in most cases, mce.ip comes from pt_regs.ip which
is unsigned long so we're fine for both 32- and 64-bit. There's only the
case with precise RIP reporting where we get the rip from an MSR but
even then, it should be 4 bytes on 32-bit since our addresses there are
4 bytes.
So, actually struct mce should've had ->ip defined as an unsigned long
from the very beginning. But we can't change that now because this
struct is shared with userspace :(
So yes Joe, make it (void *)(unsigned long).
Thanks guys.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
|
|
From: Joe P. <jo...@pe...> - 2012-12-13 18:57:31
|
On Thu, 2012-12-13 at 19:37 +0100, Borislav Petkov wrote:
> On Thu, Dec 13, 2012 at 10:23:10AM -0800, Joe Perches wrote:
> > m->ip is a u64 so, when compiling x86-32, there's a new warning
> > "cast to pointer from integer of different size". This isn't new
> > different behavior, just a new warning. The previous print_symbol
> > took a ulong and the u64 was silently truncated.
> >
> > CC arch/x86/kernel/cpu/mcheck/mce.o
> > arch/x86/kernel/cpu/mcheck/mce.c: In function ‘print_mce’:
> > arch/x86/kernel/cpu/mcheck/mce.c:246:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> >
> > If appropriate, the code could be changed to
> >
> > (void *)(unsigned long)m->ip
>
> Can we explicitly cast it to what it is so that we can be explicit as to
> what we're casting it? IOW:
>
> (void *)(__u64)m->ip;
>
> Does that even work on 32bit?
No, it already is __u64. You need (unsigned long)
or something else the same size as (void *)
from: arch/x86/include/asm/mce.h
/* Fields are zero when not available */
struct mce {
...
__u64 ip;
> Also, does the compiler bitch about this useless cast when building with
> W=123?
For x86-32:
With the cast the line is silent.
Without the cast, just the warning about cast.
|
|
From: H. P. A. <hp...@zy...> - 2012-12-13 18:43:35
|
On 12/13/2012 10:37 AM, Borislav Petkov wrote: >> >> If appropriate, the code could be changed to >> >> (void *)(unsigned long)m->ip > > Can we explicitly cast it to what it is so that we can be explicit as to > what we're casting it? IOW: > > (void *)(__u64)m->ip; > > Does that even work on 32bit? > > Also, does the compiler bitch about this useless cast when building with > W=123? > Uh... no. The point is that (void *)(unsigned long) casts it to an integer of pointer size -- in userspace you would to (void *)(size_t) or (void *)(uintptr_t) -- so that the compiler knows "I meant to do that." -hpa |
|
From: Borislav P. <bp...@al...> - 2012-12-13 18:37:14
|
On Thu, Dec 13, 2012 at 10:23:10AM -0800, Joe Perches wrote:
> m->ip is a u64 so, when compiling x86-32, there's a new warning
> "cast to pointer from integer of different size". This isn't new
> different behavior, just a new warning. The previous print_symbol
> took a ulong and the u64 was silently truncated.
>
> CC arch/x86/kernel/cpu/mcheck/mce.o
> arch/x86/kernel/cpu/mcheck/mce.c: In function ‘print_mce’:
> arch/x86/kernel/cpu/mcheck/mce.c:246:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>
> If appropriate, the code could be changed to
>
> (void *)(unsigned long)m->ip
Can we explicitly cast it to what it is so that we can be explicit as to
what we're casting it? IOW:
(void *)(__u64)m->ip;
Does that even work on 32bit?
Also, does the compiler bitch about this useless cast when building with
W=123?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
|
|
From: Joe P. <jo...@pe...> - 2012-12-13 18:23:19
|
On Wed, 2012-12-12 at 23:45 +0100, Borislav Petkov wrote: > On Wed, Dec 12, 2012 at 02:23:59PM -0800, Joe Perches wrote: > > On Wed, 2012-12-12 at 21:49 +0000, Luck, Tony wrote: > > > > I think I'd go ahead and ACK this unless Tony has some comments. I'm not > > > > happy about the two pr_emerg calls based on the conditional. > > > > > > As written the patch has the nice property of not making any changes to the > > > console output (except to eliminate the possibility of interleaved output that > > > the original code had). > > > > Well, it does eliminate a trailing space when m->cs != KERNEL_CS. > > That probably won't hurt anything, but... > > Yeah, that won't be an issue. So let's take it as is, as Tony suggests. Hi again Boris. I should mention one more thing. m->ip is a u64 so, when compiling x86-32, there's a new warning "cast to pointer from integer of different size". This isn't new different behavior, just a new warning. The previous print_symbol took a ulong and the u64 was silently truncated. CC arch/x86/kernel/cpu/mcheck/mce.o arch/x86/kernel/cpu/mcheck/mce.c: In function ‘print_mce’: arch/x86/kernel/cpu/mcheck/mce.c:246:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] If appropriate, the code could be changed to (void *)(unsigned long)m->ip to shut the compiler up. |
|
From: Borislav P. <bp...@al...> - 2012-12-12 22:45:59
|
On Wed, Dec 12, 2012 at 02:23:59PM -0800, Joe Perches wrote:
> On Wed, 2012-12-12 at 21:49 +0000, Luck, Tony wrote:
> > > I think I'd go ahead and ACK this unless Tony has some comments. I'm not
> > > happy about the two pr_emerg calls based on the conditional.
> >
> > As written the patch has the nice property of not making any changes to the
> > console output (except to eliminate the possibility of interleaved output that
> > the original code had).
>
> Well, it does eliminate a trailing space when m->cs != KERNEL_CS.
> That probably won't hurt anything, but...
Yeah, that won't be an issue. So let's take it as is, as Tony suggests.
Acked-by: Borislav Petkov <bp...@al...>
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
|
|
From: Joe P. <jo...@pe...> - 2012-12-12 22:24:08
|
On Wed, 2012-12-12 at 21:49 +0000, Luck, Tony wrote: > > I think I'd go ahead and ACK this unless Tony has some comments. I'm not > > happy about the two pr_emerg calls based on the conditional. > > As written the patch has the nice property of not making any changes to the > console output (except to eliminate the possibility of interleaved output that > the original code had). Well, it does eliminate a trailing space when m->cs != KERNEL_CS. That probably won't hurt anything, but... |
|
From: Luck, T. <ton...@in...> - 2012-12-12 21:49:46
|
> I think I'd go ahead and ACK this unless Tony has some comments. I'm not
> happy about the two pr_emerg calls based on the conditional.
As written the patch has the nice property of not making any changes to the
console output (except to eliminate the possibility of interleaved output that
the original code had). Whereas making the change you suggest would end
up with a useless "{}" in the usermode case (or worse if %pSR did something
with m->ip .. which is most probably not NULL ... it should be a valid user mode
instruction pointer when m->cs != KERNEL_CS).
So Acked-by: Tony Luck <ton...@in...>
|
|
From: Borislav P. <bp...@al...> - 2012-12-12 21:49:08
|
On Wed, Dec 12, 2012 at 01:30:03PM -0800, Joe Perches wrote:
> > I think I'd go ahead and ACK this unless Tony has some comments. I'm
> > not happy about the two pr_emerg calls based on the conditional.
>
> It was done to avoid interleaving.
Right.
> > Or, Tony, what do you think, could we get away if we printed empty
> > string for when m->cs != __KERNEL_CS? I'm thinking of not breaking any
> > userspace which is parsing that output and seeing "... {}" in that case.
> >
> > This assumes that vsprintf can print (void *)0 when passed as an
> > argument through %pSR. Joe?
>
> Definitely yes when not #defined CONFIG_KALLSYMS
>
> I believe no object exists at address 0 for all
> arches so I believe yes for CONFIG_KALLSYMS too,
Ok, here's what I'm thinking more specifically. Have single call like this:
pr_emerg(HW_ERR "RIP%s %02x:<%016Lx> {%pSR}\n",
!(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
m->cs, m->ip,
(m->cs == __KERNEL_CS) ? (void *)m->ip : (void *)0);
and when vsprintf gets to it, it recognizes the special case of
(void *)0 and dumps the empty string "" for that argument.
Hmm.
> My preference is to eventually do away with all the
> "[%0(size)lx] %pSR", addr, (void *)addr
> uses and create another %pSx that emits the pointer
> address and the function/offset in one go in a
> standardized style without caring about the pointer
> size.
>
> Something like:
>
> "%pSp", (void *)addr
>
> would emit
>
> [<7def0123>] function_name+offset/size
Right, this is another way of looking it. And in order to make it more
robust, it should be able to handle the (void *)0 case so that callers
don't have to check the arg.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
|
|
From: Joe P. <jo...@pe...> - 2012-12-12 21:30:12
|
On Wed, 2012-12-12 at 22:09 +0100, Borislav Petkov wrote:
> On Wed, Dec 12, 2012 at 10:19:05AM -0800, Joe Perches wrote:
> > Use the new vsprintf extension to avoid any possible
> > message interleaving.
[]
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
[]
> > @@ -242,13 +242,14 @@ static void print_mce(struct mce *m)
> > m->extcpu, m->mcgstatus, m->bank, m->status);
> >
> > if (m->ip) {
> > - pr_emerg(HW_ERR "RIP%s %02x:<%016Lx> ",
> > - !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
> > - m->cs, m->ip);
> > -
> > if (m->cs == __KERNEL_CS)
> > - print_symbol("{%s}", m->ip);
> > - pr_cont("\n");
> > + pr_emerg(HW_ERR "RIP%s %02x:<%016Lx> {%pSR}\n",
> > + !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
> > + m->cs, m->ip, (void *)m->ip);
> > + else
> > + pr_emerg(HW_ERR "RIP%s %02x:<%016Lx>\n",
> > + !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
> > + m->cs, m->ip);
> > }
>
> I think I'd go ahead and ACK this unless Tony has some comments. I'm not
> happy about the two pr_emerg calls based on the conditional.
It was done to avoid interleaving.
> Or, Tony, what do you think, could we get away if we printed empty
> string for when m->cs != __KERNEL_CS? I'm thinking of not breaking any
> userspace which is parsing that output and seeing "... {}" in that case.
>
> This assumes that vsprintf can print (void *)0 when passed as an
> argument through %pSR. Joe?
Definitely yes when not #defined CONFIG_KALLSYMS
I believe no object exists at address 0 for all
arches so I believe yes for CONFIG_KALLSYMS too,
My preference is to eventually do away with all the
"[%0(size)lx] %pSR", addr, (void *)addr
uses and create another %pSx that emits the pointer
address and the function/offset in one go in a
standardized style without caring about the pointer
size.
Something like:
"%pSp", (void *)addr
would emit
[<7def0123>] function_name+offset/size
|
|
From: Borislav P. <bp...@al...> - 2012-12-12 21:28:17
|
On Wed, Dec 12, 2012 at 10:19:05AM -0800, Joe Perches wrote:
> Use the new vsprintf extension to avoid any possible
> message interleaving.
>
> Signed-off-by: Joe Perches <jo...@pe...>
> ---
> arch/x86/kernel/cpu/mcheck/mce.c | 13 +++++++------
> arch/x86/kernel/dumpstack.c | 5 ++---
> arch/x86/kernel/process_32.c | 2 +-
> arch/x86/mm/mmio-mod.c | 4 ++--
> arch/x86/um/sysrq_32.c | 9 +++------
> 5 files changed, 15 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
> index 80dbda8..996f98a 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -242,13 +242,14 @@ static void print_mce(struct mce *m)
> m->extcpu, m->mcgstatus, m->bank, m->status);
>
> if (m->ip) {
> - pr_emerg(HW_ERR "RIP%s %02x:<%016Lx> ",
> - !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
> - m->cs, m->ip);
> -
> if (m->cs == __KERNEL_CS)
> - print_symbol("{%s}", m->ip);
> - pr_cont("\n");
> + pr_emerg(HW_ERR "RIP%s %02x:<%016Lx> {%pSR}\n",
> + !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
> + m->cs, m->ip, (void *)m->ip);
> + else
> + pr_emerg(HW_ERR "RIP%s %02x:<%016Lx>\n",
> + !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
> + m->cs, m->ip);
> }
I think I'd go ahead and ACK this unless Tony has some comments. I'm not
happy about the two pr_emerg calls based on the conditional.
Or, Tony, what do you think, could we get away if we printed empty
string for when m->cs != __KERNEL_CS? I'm thinking of not breaking any
userspace which is parsing that output and seeing "... {}" in that case.
This assumes that vsprintf can print (void *)0 when passed as an
argument through %pSR. Joe?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
|
|
From: Joe P. <jo...@pe...> - 2012-12-12 18:22:16
|
Use the new vsprintf extension to avoid any possible
message interleaving.
Signed-off-by: Joe Perches <jo...@pe...>
---
arch/x86/kernel/cpu/mcheck/mce.c | 13 +++++++------
arch/x86/kernel/dumpstack.c | 5 ++---
arch/x86/kernel/process_32.c | 2 +-
arch/x86/mm/mmio-mod.c | 4 ++--
arch/x86/um/sysrq_32.c | 9 +++------
5 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 80dbda8..996f98a 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -242,13 +242,14 @@ static void print_mce(struct mce *m)
m->extcpu, m->mcgstatus, m->bank, m->status);
if (m->ip) {
- pr_emerg(HW_ERR "RIP%s %02x:<%016Lx> ",
- !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
- m->cs, m->ip);
-
if (m->cs == __KERNEL_CS)
- print_symbol("{%s}", m->ip);
- pr_cont("\n");
+ pr_emerg(HW_ERR "RIP%s %02x:<%016Lx> {%pSR}\n",
+ !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
+ m->cs, m->ip, (void *)m->ip);
+ else
+ pr_emerg(HW_ERR "RIP%s %02x:<%016Lx>\n",
+ !(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
+ m->cs, m->ip);
}
pr_emerg(HW_ERR "TSC %llx ", m->tsc);
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index ae42418b..b6e5bdb 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -281,9 +281,8 @@ int __kprobes __die(const char *str, struct pt_regs *regs, long err)
sp = kernel_stack_pointer(regs);
savesegment(ss, ss);
}
- printk(KERN_EMERG "EIP: [<%08lx>] ", regs->ip);
- print_symbol("%s", regs->ip);
- printk(" SS:ESP %04x:%08lx\n", ss, sp);
+ printk(KERN_EMERG "EIP: [<%08lx>] %pSR SS:ESP %04x:%08lx\n",
+ regs->ip, (void *)regs->ip, ss, sp);
#else
/* Executive summary in case the oops scrolled away */
printk(KERN_ALERT "RIP ");
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index b5a8905..0db77e0 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -89,7 +89,7 @@ void __show_regs(struct pt_regs *regs, int all)
printk(KERN_DEFAULT "EIP: %04x:[<%08lx>] EFLAGS: %08lx CPU: %d\n",
(u16)regs->cs, regs->ip, regs->flags,
smp_processor_id());
- print_symbol("EIP is at %s\n", regs->ip);
+ printk(KERN_DEFAULT "EIP is at %pSR\n", (void *)regs->ip);
printk(KERN_DEFAULT "EAX: %08lx EBX: %08lx ECX: %08lx EDX: %08lx\n",
regs->ax, regs->bx, regs->cx, regs->dx);
diff --git a/arch/x86/mm/mmio-mod.c b/arch/x86/mm/mmio-mod.c
index dc0b727..c0ca484 100644
--- a/arch/x86/mm/mmio-mod.c
+++ b/arch/x86/mm/mmio-mod.c
@@ -123,8 +123,8 @@ static void die_kmmio_nesting_error(struct pt_regs *regs, unsigned long addr)
pr_emerg("unexpected fault for address: 0x%08lx, last fault for address: 0x%08lx\n",
addr, my_reason->addr);
print_pte(addr);
- print_symbol(KERN_EMERG "faulting IP is at %s\n", regs->ip);
- print_symbol(KERN_EMERG "last faulting IP was at %s\n", my_reason->ip);
+ pr_emerg("faulting IP is at %pSR\n", (void *)regs->ip);
+ pr_emerg("last faulting IP was at %pSR\n", (void *)my_reason->ip);
#ifdef __i386__
pr_emerg("eax: %08lx ebx: %08lx ecx: %08lx edx: %08lx\n",
regs->ax, regs->bx, regs->cx, regs->dx);
diff --git a/arch/x86/um/sysrq_32.c b/arch/x86/um/sysrq_32.c
index c9bee5b..30b4200 100644
--- a/arch/x86/um/sysrq_32.c
+++ b/arch/x86/um/sysrq_32.c
@@ -50,18 +50,15 @@ static inline unsigned long print_context_stack(struct thread_info *tinfo,
#ifdef CONFIG_FRAME_POINTER
while (valid_stack_ptr(tinfo, (void *)ebp)) {
addr = *(unsigned long *)(ebp + 4);
- printk("%08lx: [<%08lx>]", ebp + 4, addr);
- print_symbol(" %s", addr);
- printk("\n");
+ printk("%08lx: [<%08lx>] %pSR\n", ebp + 4, addr, (void *)addr);
ebp = *(unsigned long *)ebp;
}
#else
while (valid_stack_ptr(tinfo, stack)) {
addr = *stack;
if (__kernel_text_address(addr)) {
- printk("%08lx: [<%08lx>]", (unsigned long) stack, addr);
- print_symbol(" %s", addr);
- printk("\n");
+ printk("%08lx: [<%08lx>] %pSR\n",
+ (unsigned long)stack, addr, (void *)addr);
}
stack++;
}
--
1.7.8.112.g3fd21
|
|
From: Joe P. <jo...@pe...> - 2012-12-12 18:21:55
|
Use the new vsprintf extension to avoid any possible
message interleaving.
Signed-off-by: Joe Perches <jo...@pe...>
---
arch/um/kernel/sysrq.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
index e562ff8..6fa632c 100644
--- a/arch/um/kernel/sysrq.c
+++ b/arch/um/kernel/sysrq.c
@@ -24,10 +24,8 @@ void show_trace(struct task_struct *task, unsigned long * stack)
while (((long) stack & (THREAD_SIZE-1)) != 0) {
addr = *stack;
if (__kernel_text_address(addr)) {
- printk(KERN_INFO "%08lx: [<%08lx>]",
- (unsigned long) stack, addr);
- print_symbol(KERN_CONT " %s", addr);
- printk(KERN_CONT "\n");
+ printk(KERN_INFO "%08lx: [<%08lx>] %pSR\n",
+ (unsigned long)stack, addr, (void *)addr);
}
stack++;
}
--
1.7.8.112.g3fd21
|
|
From: Joe P. <jo...@pe...> - 2012-12-12 18:19:42
|
Remove the somewhat awkward uses of print_symbol and convert all the
existing uses to a new vsprintf pointer type of %pSR.
print_symbol can be interleaved when it is used in a sequence like:
printk("something: ...");
print_symbol("%s", addr);
printk("\n");
Instead use:
printk("something: %pSR\n", (void *)addr);
Add a new %p[SsFf]R vsprintf extension that can perform the same
symbol function/address/offset formatting as print_symbol to
reduce the number and styles of message logging functions.
print_symbol used __builtin_extract_return_addr for those architectures
like S/390 and SPARC that have offset or masked addressing.
%p[FfSs]R uses the same gcc __builtin
Joe Perches (26):
vsprintf: Add extension %pSR - print_symbol replacement
alpha: Convert print_symbol to %pSR
arm: Convert print_symbol to %pSR
arm64: Convert print_symbol to %pSR
avr32: Convert print_symbol to %pSR
c6x: Convert print_symbol to %pSR
ia64: Convert print_symbol to %pSR
m32r: Convert print_symbol to %pSR
mn10300: Convert print_symbol to %pSR
openrisc: Convert print_symbol to %pSR
powerpc: Convert print_symbol to %pSR
s390: Convert print_symbol to %pSR
sh: Convert print_symbol to %pSR
um: Convert print_symbol to %pSR
unicore32: Convert print_symbol to %pSR
x86: Convert print_symbol to %pSR
xtensa: Convert print_symbol to %pSR
drivers: base: Convert print_symbol to %pSR
gfs2: Convert print_symbol to %pSR
sysfs: Convert print_symbol to %pSR
irq: Convert print_symbol to %pSR
smp_processor_id: Convert print_symbol to %pSR
mm: Convert print_symbol to %pSR
xtensa: Convert print_symbol to %pSR
x86: head_64.S: Use vsprintf extension %pSR not print_symbol
kallsyms: Remove print_symbol
Documentation/filesystems/sysfs.txt | 4 +-
Documentation/printk-formats.txt | 2 +
Documentation/zh_CN/filesystems/sysfs.txt | 4 +-
arch/alpha/kernel/traps.c | 8 ++----
arch/arm/kernel/process.c | 4 +-
arch/arm64/kernel/process.c | 4 +-
arch/avr32/kernel/process.c | 25 ++++++-----------------
arch/c6x/kernel/traps.c | 3 +-
arch/ia64/kernel/process.c | 13 ++++-------
arch/m32r/kernel/traps.c | 6 +---
arch/mn10300/kernel/traps.c | 8 +++---
arch/openrisc/kernel/traps.c | 7 +----
arch/powerpc/platforms/cell/spu_callbacks.c | 12 ++++------
arch/s390/kernel/traps.c | 28 +++++++++++++++-----------
arch/sh/kernel/process_32.c | 4 +-
arch/um/kernel/sysrq.c | 6 +---
arch/unicore32/kernel/process.c | 5 ++-
arch/x86/kernel/cpu/mcheck/mce.c | 13 ++++++-----
arch/x86/kernel/dumpstack.c | 5 +--
arch/x86/kernel/head_64.S | 4 +-
arch/x86/kernel/process_32.c | 2 +-
arch/x86/mm/mmio-mod.c | 4 +-
arch/x86/um/sysrq_32.c | 9 ++-----
arch/xtensa/kernel/traps.c | 6 +---
drivers/base/core.c | 4 +-
fs/gfs2/glock.c | 4 +-
fs/gfs2/trans.c | 3 +-
fs/sysfs/file.c | 4 +-
include/linux/kallsyms.h | 18 -----------------
kernel/irq/debug.h | 15 ++++++-------
kernel/kallsyms.c | 11 ----------
lib/smp_processor_id.c | 2 +-
lib/vsprintf.c | 18 ++++++++++++----
mm/memory.c | 8 +++---
mm/slab.c | 8 ++----
35 files changed, 117 insertions(+), 164 deletions(-)
--
1.7.8.112.g3fd21
|
|
From: Toralf F. <tor...@gm...> - 2012-12-10 19:56:25
|
/me wondering, why just 2 commits bloat up a user mode linux executable by 180 KB : -rwxr-xr-x 1 root root 19434102 Dec 10 20:46 /usr/local/bin/linux-v3.7-rc8-41-gcaf4919 -rwxr-xr-x 1 root root 19250814 Dec 8 18:31 /usr/local/bin/linux-v3.7-rc8-39-ged23ec4 helper : $>gitk ed23ec4..caf4919 -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 |
525 messages has been excluded from this view by a project administrator.
