[PATCH] Real-Time Preemption, fixed kexec kernel relocation oops
This patch, built against kernel version 2.6.13-rc7 (and not against -RT tree
patch, sorry), fixes a few local_irq_disable() calls which leads to an oops
during kernel relocation in kexec subsystem. Currently, only i386 implementation
of kexec is fixed.
Anyway, this patch does not fix a strange behaviour when using kexec with a -RT
kernel. Here is dmesg output:
Uncompressing Linux... OK, booting the kernel.
Unknown interrupt or fault at EIP 0203 0060 c011dfe3
Linux version 2.6.13-rc7-rt1 ([EMAIL PROTECTED]) (gcc version 3.3.4 (Debian
1:3.3.4-13)) #2 Fri Aug 26 16:55:12 UTC 2005
[...]
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
[...]
System is very slow and there are tons of "lost interrupt" messages.
Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]>
--- ./arch/i386/kernel/machine_kexec.c.orig 2005-08-28 22:03:52.0
+
+++ ./arch/i386/kernel/machine_kexec.c 2005-08-28 22:05:28.0 +
@@ -187,7 +187,7 @@ NORET_TYPE void machine_kexec(struct kim
relocate_new_kernel_t rnk;
/* Interrupts aren't acceptable while we reboot */
- local_irq_disable();
+ raw_local_irq_disable();
/* Compute some offsets */
reboot_code_buffer = page_to_pfn(image->control_code_page)
--- ./arch/i386/kernel/crash.c.orig 2005-08-28 22:04:08.0 +
+++ ./arch/i386/kernel/crash.c 2005-08-28 22:04:55.0 +
@@ -143,7 +143,7 @@ static int crash_nmi_callback(struct pt_
*/
if (cpu == crashing_cpu)
return 1;
- local_irq_disable();
+ raw_local_irq_disable();
if (!user_mode(regs)) {
crash_setup_regs(_regs, regs);
@@ -210,7 +210,7 @@ void machine_crash_shutdown(struct pt_re
* an SMP system.
*/
/* The kernel is broken so disable interrupts */
- local_irq_disable();
+ raw_local_irq_disable();
/* Make a note of crashing cpu. Will be used in NMI callback.*/
crashing_cpu = smp_processor_id();
Regards,
--
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Real-Time Preemption, fixed kexec kernel relocation oops
This patch, built against kernel version 2.6.13-rc7 (and not against -RT tree
patch, sorry), fixes a few local_irq_disable() calls which leads to an oops
during kernel relocation in kexec subsystem. Currently, only i386 implementation
of kexec is fixed.
Anyway, this patch does not fix a strange behaviour when using kexec with a -RT
kernel. Here is dmesg output:
Uncompressing Linux... OK, booting the kernel.
Unknown interrupt or fault at EIP 0203 0060 c011dfe3
Linux version 2.6.13-rc7-rt1 ([EMAIL PROTECTED]) (gcc version 3.3.4 (Debian
1:3.3.4-13)) #2 Fri Aug 26 16:55:12 UTC 2005
[...]
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
[...]
System is very slow and there are tons of lost interrupt messages.
Signed-off-by: Luca Falavigna [EMAIL PROTECTED]
--- ./arch/i386/kernel/machine_kexec.c.orig 2005-08-28 22:03:52.0
+
+++ ./arch/i386/kernel/machine_kexec.c 2005-08-28 22:05:28.0 +
@@ -187,7 +187,7 @@ NORET_TYPE void machine_kexec(struct kim
relocate_new_kernel_t rnk;
/* Interrupts aren't acceptable while we reboot */
- local_irq_disable();
+ raw_local_irq_disable();
/* Compute some offsets */
reboot_code_buffer = page_to_pfn(image-control_code_page)
--- ./arch/i386/kernel/crash.c.orig 2005-08-28 22:04:08.0 +
+++ ./arch/i386/kernel/crash.c 2005-08-28 22:04:55.0 +
@@ -143,7 +143,7 @@ static int crash_nmi_callback(struct pt_
*/
if (cpu == crashing_cpu)
return 1;
- local_irq_disable();
+ raw_local_irq_disable();
if (!user_mode(regs)) {
crash_setup_regs(fixed_regs, regs);
@@ -210,7 +210,7 @@ void machine_crash_shutdown(struct pt_re
* an SMP system.
*/
/* The kernel is broken so disable interrupts */
- local_irq_disable();
+ raw_local_irq_disable();
/* Make a note of crashing cpu. Will be used in NMI callback.*/
crashing_cpu = smp_processor_id();
Regards,
--
Luca
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kexec and frame buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca Falavigna ha scritto: > Eric W. Biederman ha scritto: > >>>Anyway I believe you also want to look at include/linux/tty.h >>>at the screen_info structure. I believe that is where >>>all of that information is passed. > > I noticed. Maybe if we fill struct x86_linux_param_header with some values > obtained from struct screen_info, we should be able to "score that mid-court > prayer" ;) > I tried to implement a new ioctl command in fb_ioctl() in order to retrieve and store screen_info variables into struct x86_linux_param_header, but I got the same result: no messages shown in console, as I supposed. After that I looked at video.S, especially an interesting label called "video": # This is the main entry point called by setup.S # %ds *must* be pointing to the bootsector video: pushw %ds # We use different segments pushw %ds # FS contains original DS popw%fs [...] #ifdef CONFIG_VIDEO_SELECT movw%fs:(0x01fa), %ax # User selected video mode cmpw$ASK_VGA, %ax # Bring up the menu jz vid2 [...] Video mode is stored (by bootloader, actually) at offset 0x01fa from a given boot sector, which should be located at physical address DEF_SETUPSEG (0x9020). Feel free to correct me if I'm wrong. If we could store current video mode before executing reboot_code_buffer, probably setup() function would take care of anything else. So we could implement a function (or an assembly stub) in machine_kexec which does this job. I think this is the best (and safest) solution. Regards, - -- Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvzwDczkDT3RfMB6AQJlQAf+INkCMjhmm18RPCMHXij7WmOL/4TCKTc8 fZCf+IzhsSUxwkfYmUbTfXtJ/xCxIyRh5gBGirB9n/s9NzOiYwmcQWMrn7DbWpWu YBVkTdz3W3Y0dA08baIYQ8u51gJvnVMuGJEFqsLxPx+gzHJOETEGkzhuyUuPk+J+ N4OkSyTGYt5zXZmyVzV7KZ8XLrfX3XvRLV3m2aey0Hz4jcf8sIozANokDRdG3MpN 7F0Z4yL1EnMI4oijHSDLeqbycAg8iYa49P45EO6+jzuRH2i2bnq8hOvBHa0+B01Q Gr0Ljd+DJ2jNVO4ecqbWC9oFxBFXsRN+ThAxsYEbWDGIrJdAa32mfA== =BztK -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec and frame buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca Falavigna ha scritto: Eric W. Biederman ha scritto: Anyway I believe you also want to look at include/linux/tty.h at the screen_info structure. I believe that is where all of that information is passed. I noticed. Maybe if we fill struct x86_linux_param_header with some values obtained from struct screen_info, we should be able to score that mid-court prayer ;) I tried to implement a new ioctl command in fb_ioctl() in order to retrieve and store screen_info variables into struct x86_linux_param_header, but I got the same result: no messages shown in console, as I supposed. After that I looked at video.S, especially an interesting label called video: # This is the main entry point called by setup.S # %ds *must* be pointing to the bootsector video: pushw %ds # We use different segments pushw %ds # FS contains original DS popw%fs [...] #ifdef CONFIG_VIDEO_SELECT movw%fs:(0x01fa), %ax # User selected video mode cmpw$ASK_VGA, %ax # Bring up the menu jz vid2 [...] Video mode is stored (by bootloader, actually) at offset 0x01fa from a given boot sector, which should be located at physical address DEF_SETUPSEG (0x9020). Feel free to correct me if I'm wrong. If we could store current video mode before executing reboot_code_buffer, probably setup() function would take care of anything else. So we could implement a function (or an assembly stub) in machine_kexec which does this job. I think this is the best (and safest) solution. Regards, - -- Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvzwDczkDT3RfMB6AQJlQAf+INkCMjhmm18RPCMHXij7WmOL/4TCKTc8 fZCf+IzhsSUxwkfYmUbTfXtJ/xCxIyRh5gBGirB9n/s9NzOiYwmcQWMrn7DbWpWu YBVkTdz3W3Y0dA08baIYQ8u51gJvnVMuGJEFqsLxPx+gzHJOETEGkzhuyUuPk+J+ N4OkSyTGYt5zXZmyVzV7KZ8XLrfX3XvRLV3m2aey0Hz4jcf8sIozANokDRdG3MpN 7F0Z4yL1EnMI4oijHSDLeqbycAg8iYa49P45EO6+jzuRH2i2bnq8hOvBHa0+B01Q Gr0Ljd+DJ2jNVO4ecqbWC9oFxBFXsRN+ThAxsYEbWDGIrJdAa32mfA== =BztK -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Real-Time Preemption V0.7.53-02, fix redundant PREEMPT_RCU config option
This patch removes a redundant PREEMPT_RCU option from kernel/Kconfig.preempt. Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]> --- realtime-preempt-2.6.13-rc4-RT-V0.7.53-02.orig 2005-08-11 18:56:51.0 + +++ realtime-preempt-2.6.13-rc4-RT-V0.7.53-02 2005-08-11 21:13:43.0 + @@ -21571,18 +21571,6 @@ Index: linux/kernel/Kconfig.preempt + +Say N if you are unsure. + -+config PREEMPT_RCU -+ bool "Preemptible RCU" -+ default n -+ depends on PREEMPT -+ help -+This option reduces the latency of the kernel by making certain -+RCU sections preemptible. Normally RCU code is non-preemptible, if -+this option is selected then read-only RCU sections become -+preemptible. This helps latency, but may increase memory utilization. -+ -+Say N if you are unsure. -+ +config SPINLOCK_BKL + bool "Old-Style Big Kernel Lock" + depends on (PREEMPT || SMP) && !PREEMPT_RT Regards, -- Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Real-Time Preemption V0.7.53-02, fix redundant PREEMPT_RCU config option
This patch removes a redundant PREEMPT_RCU option from kernel/Kconfig.preempt. Signed-off-by: Luca Falavigna [EMAIL PROTECTED] --- realtime-preempt-2.6.13-rc4-RT-V0.7.53-02.orig 2005-08-11 18:56:51.0 + +++ realtime-preempt-2.6.13-rc4-RT-V0.7.53-02 2005-08-11 21:13:43.0 + @@ -21571,18 +21571,6 @@ Index: linux/kernel/Kconfig.preempt + +Say N if you are unsure. + -+config PREEMPT_RCU -+ bool Preemptible RCU -+ default n -+ depends on PREEMPT -+ help -+This option reduces the latency of the kernel by making certain -+RCU sections preemptible. Normally RCU code is non-preemptible, if -+this option is selected then read-only RCU sections become -+preemptible. This helps latency, but may increase memory utilization. -+ -+Say N if you are unsure. -+ +config SPINLOCK_BKL + bool Old-Style Big Kernel Lock + depends on (PREEMPT || SMP) !PREEMPT_RT Regards, -- Luca - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec and frame buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric W. Biederman ha scritto: > Anyway I believe you also want to look at include/linux/tty.h > at the screen_info structure. I believe that is where > all of that information is passed. I noticed. Maybe if we fill struct x86_linux_param_header with some values obtained from struct screen_info, we should be able to "score that mid-court prayer" ;) >>I tried to pass --real-mode flag to kexec but my virtual machine doesn't like >>it. When I launch kexec -e, it tells me: "A strange behaviour occourred which >>crashed virtual machine". > > > Cool. I haven't used that code in a long time but it is pretty > trivial code to switches to real mode so I don't really doubt it :) Added to my list-of-things-to-do-after-holydays :) Regards, - -- Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvYmaszkDT3RfMB6AQLPMQf/W3HZbJj50rxI1LOHyw0hhcQZji+gU68R E88xmgbL1fuiQqdqD1vp3gG7uDf9jjE+TjNMQ1qgZr01xHUjV13Jq8e9Lu75S+RZ JgiYJxFKGY/ctl9oFgEraU9Qje1b18dTmYh5G4xfZLNjUFUM1uQowV6CSPLVRadv ucmzduDrqwRBQgN9vSrWPoLio8nbT5ZjxLjaY1z3P3EYXoBs9LLx1bjzLmR7/cVe MP3/BM61CLqflOG9G+ck9yD2RIYnLhvNHDBKt1X+oP+U/iSkzse3XEM/YVny6/3d zAYy8m66o2bPnj/vNcBbroxANTdiXJce8QWayk9a69c26DmjOLnYrQ== =iPn6 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec and frame buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric W. Biederman ha scritto: Anyway I believe you also want to look at include/linux/tty.h at the screen_info structure. I believe that is where all of that information is passed. I noticed. Maybe if we fill struct x86_linux_param_header with some values obtained from struct screen_info, we should be able to score that mid-court prayer ;) I tried to pass --real-mode flag to kexec but my virtual machine doesn't like it. When I launch kexec -e, it tells me: A strange behaviour occourred which crashed virtual machine. Cool. I haven't used that code in a long time but it is pretty trivial code to switches to real mode so I don't really doubt it :) Added to my list-of-things-to-do-after-holydays :) Regards, - -- Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvYmaszkDT3RfMB6AQLPMQf/W3HZbJj50rxI1LOHyw0hhcQZji+gU68R E88xmgbL1fuiQqdqD1vp3gG7uDf9jjE+TjNMQ1qgZr01xHUjV13Jq8e9Lu75S+RZ JgiYJxFKGY/ctl9oFgEraU9Qje1b18dTmYh5G4xfZLNjUFUM1uQowV6CSPLVRadv ucmzduDrqwRBQgN9vSrWPoLio8nbT5ZjxLjaY1z3P3EYXoBs9LLx1bjzLmR7/cVe MP3/BM61CLqflOG9G+ck9yD2RIYnLhvNHDBKt1X+oP+U/iSkzse3XEM/YVny6/3d zAYy8m66o2bPnj/vNcBbroxANTdiXJce8QWayk9a69c26DmjOLnYrQ== =iPn6 -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec and frame buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric W. Biederman ha scritto: > So without doing passing --real-mode the vga= parameter currently > cannot work. The vga= parameter is processed by vga.S which > make BIOS calls and we bypass all of the BIOS calls. Actually that file is video.S > So you can try with the --real-mode option and you have > a chance of the code working. Or you can figure out which > information video.S passes to the kernel figure out how > to get that same information out of a running kernel > and then /sbin/kexec can be tweaked to pass the current > video mode. Changing frame buffer modes shouldn't work > but you should at least be able to preserve the existing > ones. I tried to pass --real-mode flag to kexec but my virtual machine doesn't like it. When I launch kexec -e, it tells me: "A strange behaviour occourred which crashed virtual machine". I'll dig source code ASAP to figure out this matter. Meanwhile I'm going to follow your advice to inspect video.S in order to track down something useful. Regards, - -- Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvTG5czkDT3RfMB6AQJY8Qf9HucRMCCAvta/pAs1CakqwJs5bZo4uJUu 3tat7+24I57mDmj+2IGe7qLO9W9ctCyVJStHTMCpjYq0qF7TA9VZSsU3ip1h9/IG HnCzozUGpd3yrNsrs3v0fvinQ1z2UtrOY8lxCUISchI3Ho43KnPDoAV2mfT+eEcP pN/lUz6Z/Jb0YbNS9Z352bqs+JtuxHzX1pVD4uH4X+Dkua3kAde5C0bwP9K+O15A //qlXb4AJErv6I5+Q/RxCDAn4TtVJCcdoA9Sp84ZH8jnxiYkg2coijvwFHLLvPD/ bK49QyD5QHmsVC3x/pIefd3qPEOphbNPE7AlN86X8B4i8lI6jr2x3g== =YhUC -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec and frame buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric W. Biederman ha scritto: So without doing passing --real-mode the vga= parameter currently cannot work. The vga= parameter is processed by vga.S which make BIOS calls and we bypass all of the BIOS calls. Actually that file is video.S So you can try with the --real-mode option and you have a chance of the code working. Or you can figure out which information video.S passes to the kernel figure out how to get that same information out of a running kernel and then /sbin/kexec can be tweaked to pass the current video mode. Changing frame buffer modes shouldn't work but you should at least be able to preserve the existing ones. I tried to pass --real-mode flag to kexec but my virtual machine doesn't like it. When I launch kexec -e, it tells me: A strange behaviour occourred which crashed virtual machine. I'll dig source code ASAP to figure out this matter. Meanwhile I'm going to follow your advice to inspect video.S in order to track down something useful. Regards, - -- Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvTG5czkDT3RfMB6AQJY8Qf9HucRMCCAvta/pAs1CakqwJs5bZo4uJUu 3tat7+24I57mDmj+2IGe7qLO9W9ctCyVJStHTMCpjYq0qF7TA9VZSsU3ip1h9/IG HnCzozUGpd3yrNsrs3v0fvinQ1z2UtrOY8lxCUISchI3Ho43KnPDoAV2mfT+eEcP pN/lUz6Z/Jb0YbNS9Z352bqs+JtuxHzX1pVD4uH4X+Dkua3kAde5C0bwP9K+O15A //qlXb4AJErv6I5+Q/RxCDAn4TtVJCcdoA9Sp84ZH8jnxiYkg2coijvwFHLLvPD/ bK49QyD5QHmsVC3x/pIefd3qPEOphbNPE7AlN86X8B4i8lI6jr2x3g== =YhUC -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kexec and frame buffer
I made three experiments regarding kexec with frame buffer support (vesafb). For
each of them I gathered dmesg messages from original and relocated kernel, in
order to easily compare them later on. These tests were run on a virtual machine
in order to provide the same environment for each experiment.
Here are my tests and related results:
1) Frame buffer not enabled
Original kernel command line: root=/dev/hda1 ro
Relocated kernel command line: root=/dev/hda1 ro
Everything went well, as supposed to be. I was able to read boot messages and to
see login prompts.
2) Frame buffer enabled in the relocated kernel
Original kernel command line: root=/dev/hda1 ro
Relocated kernel command line: root=/dev/hda1 ro vga=791
This time I was able to read boot messages and so on, but I couldn't be able to
load vesafb in the relocated kernel. dmesg showed nothing about vesafb.
3) Frame buffer enabled in the original kernel
Original kernel command line: root=/dev/hda1 ro vga=791
Relocated kernel command line: root=/dev/hda1 ro {vga=791,}
This time I wasn't able to read boot messages in the relocated kernel, whether
vga parameter was set or not. I looked at dmesg in order to get some useful
informations:
Linux version 2.6.13-rc5 ([EMAIL PROTECTED]) (gcc version 3.3.4 (Debian
1:3.3.4-13)) #3 Wed Aug 3 13:39:11 UTC 2005
[...]
-Console: colour dummy device 80x25
+Console: colour VGA+ 80x25
[...]
-vesafb: framebuffer at 0xf000, mapped to 0xc288, using 3072k, total
16384k
-vesafb: mode is 1024x768x16, linelength=2048, pages=0
-vesafb: protected mode interface info at 00ff:44f0
-vesafb: scrolling: redraw
-vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
-mtrr: your processor doesn't support write-combining
-Console: switching to colour frame buffer device 128x48
-fb0: VESA VGA frame buffer device
[...]
It seems relocated kernel doesn't (or can't) load vesafb. Is frame buffer
supported in kexec or there is some work-in-progress?
Regards,
--
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
kexec and frame buffer
I made three experiments regarding kexec with frame buffer support (vesafb). For
each of them I gathered dmesg messages from original and relocated kernel, in
order to easily compare them later on. These tests were run on a virtual machine
in order to provide the same environment for each experiment.
Here are my tests and related results:
1) Frame buffer not enabled
Original kernel command line: root=/dev/hda1 ro
Relocated kernel command line: root=/dev/hda1 ro
Everything went well, as supposed to be. I was able to read boot messages and to
see login prompts.
2) Frame buffer enabled in the relocated kernel
Original kernel command line: root=/dev/hda1 ro
Relocated kernel command line: root=/dev/hda1 ro vga=791
This time I was able to read boot messages and so on, but I couldn't be able to
load vesafb in the relocated kernel. dmesg showed nothing about vesafb.
3) Frame buffer enabled in the original kernel
Original kernel command line: root=/dev/hda1 ro vga=791
Relocated kernel command line: root=/dev/hda1 ro {vga=791,}
This time I wasn't able to read boot messages in the relocated kernel, whether
vga parameter was set or not. I looked at dmesg in order to get some useful
informations:
Linux version 2.6.13-rc5 ([EMAIL PROTECTED]) (gcc version 3.3.4 (Debian
1:3.3.4-13)) #3 Wed Aug 3 13:39:11 UTC 2005
[...]
-Console: colour dummy device 80x25
+Console: colour VGA+ 80x25
[...]
-vesafb: framebuffer at 0xf000, mapped to 0xc288, using 3072k, total
16384k
-vesafb: mode is 1024x768x16, linelength=2048, pages=0
-vesafb: protected mode interface info at 00ff:44f0
-vesafb: scrolling: redraw
-vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
-mtrr: your processor doesn't support write-combining
-Console: switching to colour frame buffer device 128x48
-fb0: VESA VGA frame buffer device
[...]
It seems relocated kernel doesn't (or can't) load vesafb. Is frame buffer
supported in kexec or there is some work-in-progress?
Regards,
--
Luca
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Real-Time Preemption V0.7.52-07: rt_init_MUTEX_LOCKED declaration
> Ingo purposely put this in to crash
> the compile so that we know where this can be a problem right away.
And it works nice ;)
> The patch you wanted to send was:
>
> Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
>
> Index: linux_realtime_ernie/drivers/char/watchdog/cpu5wdt.c
> ===
> --- linux_realtime_ernie/drivers/char/watchdog/cpu5wdt.c(revision 265)
> +++ linux_realtime_ernie/drivers/char/watchdog/cpu5wdt.c(working copy)
> @@ -56,7 +56,7 @@
> /* some device data */
>
> static struct {
> - struct semaphore stop;
> + struct compat_semaphore stop;
> volatile int running;
> struct timer_list timer;
> volatile int queue;
Another solution could be this (as shown in drivers/cpufreq/cpufreq.c):
- init_MUTEX_LOCKED(>lock);
+ init_MUTEX(>lock);
+ down(>lock);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Real-Time Preemption V0.7.52-07: rt_init_MUTEX_LOCKED declaration
This patch fixes broken rt_init_MUTEX_LOCKED declaration using rt_sema_init() macro. This way we fix a potential compile bug: rt_init_MUTEX_LOCKED calls there_is_no_init_MUTEX_LOCKED_for_RT_semaphores, which is not referenced. (e.g. drivers/char/watchdog/cpu5wdt.c: "cpu5wdt: Unknown symbol there_is_no_init_MUTEX_LOCKED_for_RT_semaphores") Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]> --- realtime-preempt-2.6.13-rc4-RT-V0.7.52-07.orig 2005-07-31 23:35:18.0 + +++ realtime-preempt-2.6.13-rc4-RT-V0.7.52-07 2005-08-01 15:59:31.0 + @@ -8342,16 +8342,6 @@ Index: linux/drivers/cpufreq/cpufreq.c === --- linux.orig/drivers/cpufreq/cpufreq.c +++ linux/drivers/cpufreq/cpufreq.c -@@ -605,7 +605,8 @@ static int cpufreq_add_dev (struct sys_d - policy->cpu = cpu; - policy->cpus = cpumask_of_cpu(cpu); - -- init_MUTEX_LOCKED(>lock); -+ init_MUTEX(>lock); -+ down(>lock); - init_completion(>kobj_unregister); - INIT_WORK(>update, handle_update, (void *)(long)cpu); - @@ -614,6 +615,7 @@ static int cpufreq_add_dev (struct sys_d */ ret = cpufreq_driver->init(policy); @@ -14350,7 +14340,7 @@ Index: linux/include/linux/rt_lock.h === --- /dev/null +++ linux/include/linux/rt_lock.h -@@ -0,0 +1,391 @@ +@@ -0,0 +1,385 @@ +#ifndef __LINUX_RT_LOCK_H +#define __LINUX_RT_LOCK_H + @@ -14589,14 +14579,8 @@ Index: linux/include/linux/rt_lock.h +extern void FASTCALL(__init_MUTEX(struct semaphore *sem, char *name, char *file, int line)); +#define rt_init_MUTEX(sem) \ + __init_MUTEX(sem, #sem, __FILE__, __LINE__) -+ -+extern void there_is_no_init_MUTEX_LOCKED_for_RT_semaphores(void); -+ -+/* -+ * No locked initialization for RT semaphores -+ */ +#define rt_init_MUTEX_LOCKED(sem) \ -+ there_is_no_init_MUTEX_LOCKED_for_RT_semaphores() ++ rt_sema_init(sem, 0) +extern void FASTCALL(rt_down(struct semaphore *sem)); +extern int FASTCALL(rt_down_interruptible(struct semaphore *sem)); +extern int FASTCALL(rt_down_trylock(struct semaphore *sem)); Regards, -- Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Real-Time Preemption V0.7.52-07: rt_init_MUTEX_LOCKED declaration
This patch fixes broken rt_init_MUTEX_LOCKED declaration using rt_sema_init() macro. This way we fix a potential compile bug: rt_init_MUTEX_LOCKED calls there_is_no_init_MUTEX_LOCKED_for_RT_semaphores, which is not referenced. (e.g. drivers/char/watchdog/cpu5wdt.c: cpu5wdt: Unknown symbol there_is_no_init_MUTEX_LOCKED_for_RT_semaphores) Signed-off-by: Luca Falavigna [EMAIL PROTECTED] --- realtime-preempt-2.6.13-rc4-RT-V0.7.52-07.orig 2005-07-31 23:35:18.0 + +++ realtime-preempt-2.6.13-rc4-RT-V0.7.52-07 2005-08-01 15:59:31.0 + @@ -8342,16 +8342,6 @@ Index: linux/drivers/cpufreq/cpufreq.c === --- linux.orig/drivers/cpufreq/cpufreq.c +++ linux/drivers/cpufreq/cpufreq.c -@@ -605,7 +605,8 @@ static int cpufreq_add_dev (struct sys_d - policy-cpu = cpu; - policy-cpus = cpumask_of_cpu(cpu); - -- init_MUTEX_LOCKED(policy-lock); -+ init_MUTEX(policy-lock); -+ down(policy-lock); - init_completion(policy-kobj_unregister); - INIT_WORK(policy-update, handle_update, (void *)(long)cpu); - @@ -614,6 +615,7 @@ static int cpufreq_add_dev (struct sys_d */ ret = cpufreq_driver-init(policy); @@ -14350,7 +14340,7 @@ Index: linux/include/linux/rt_lock.h === --- /dev/null +++ linux/include/linux/rt_lock.h -@@ -0,0 +1,391 @@ +@@ -0,0 +1,385 @@ +#ifndef __LINUX_RT_LOCK_H +#define __LINUX_RT_LOCK_H + @@ -14589,14 +14579,8 @@ Index: linux/include/linux/rt_lock.h +extern void FASTCALL(__init_MUTEX(struct semaphore *sem, char *name, char *file, int line)); +#define rt_init_MUTEX(sem) \ + __init_MUTEX(sem, #sem, __FILE__, __LINE__) -+ -+extern void there_is_no_init_MUTEX_LOCKED_for_RT_semaphores(void); -+ -+/* -+ * No locked initialization for RT semaphores -+ */ +#define rt_init_MUTEX_LOCKED(sem) \ -+ there_is_no_init_MUTEX_LOCKED_for_RT_semaphores() ++ rt_sema_init(sem, 0) +extern void FASTCALL(rt_down(struct semaphore *sem)); +extern int FASTCALL(rt_down_interruptible(struct semaphore *sem)); +extern int FASTCALL(rt_down_trylock(struct semaphore *sem)); Regards, -- Luca - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Real-Time Preemption V0.7.52-07: rt_init_MUTEX_LOCKED declaration
Ingo purposely put this in to crash
the compile so that we know where this can be a problem right away.
And it works nice ;)
The patch you wanted to send was:
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
Index: linux_realtime_ernie/drivers/char/watchdog/cpu5wdt.c
===
--- linux_realtime_ernie/drivers/char/watchdog/cpu5wdt.c(revision 265)
+++ linux_realtime_ernie/drivers/char/watchdog/cpu5wdt.c(working copy)
@@ -56,7 +56,7 @@
/* some device data */
static struct {
- struct semaphore stop;
+ struct compat_semaphore stop;
volatile int running;
struct timer_list timer;
volatile int queue;
Another solution could be this (as shown in drivers/cpufreq/cpufreq.c):
- init_MUTEX_LOCKED(policy-lock);
+ init_MUTEX(policy-lock);
+ down(policy-lock);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][TRIVIAL] Real-Time Preemption V0.7.51-38: fix compile bug in drivers/block/paride/pseudo.h
This patch, built against kernel version 2.6.13-rc3, fixes a small bug in drivers/block/paride/pseudo.h which prevents its related drivers from being compiled successfully when RT patch (version 0.7.51-38) is compiled in. This is due to the new definition of DEFINE_SPINLOCK macro, which does not longer accept additional attributes. Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]> --- ./drivers/block/paride/pseudo.h.orig 2005-03-02 21:39:37.0 + +++ ./drivers/block/paride/pseudo.h 2005-07-27 15:37:50.0 + @@ -43,7 +43,7 @@ static int ps_tq_active = 0; static int ps_nice = 0; -static DEFINE_SPINLOCK(ps_spinlock __attribute__((unused))); +static __attribute__((unused)) DEFINE_SPINLOCK(ps_spinlock); static DECLARE_WORK(ps_tq, ps_tq_int, NULL); Regards, -- Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][TRIVIAL] Real-Time Preemption V0.7.51-38: fix compile bug in drivers/block/paride/pseudo.h
This patch, built against kernel version 2.6.13-rc3, fixes a small bug in drivers/block/paride/pseudo.h which prevents its related drivers from being compiled successfully when RT patch (version 0.7.51-38) is compiled in. This is due to the new definition of DEFINE_SPINLOCK macro, which does not longer accept additional attributes. Signed-off-by: Luca Falavigna [EMAIL PROTECTED] --- ./drivers/block/paride/pseudo.h.orig 2005-03-02 21:39:37.0 + +++ ./drivers/block/paride/pseudo.h 2005-07-27 15:37:50.0 + @@ -43,7 +43,7 @@ static int ps_tq_active = 0; static int ps_nice = 0; -static DEFINE_SPINLOCK(ps_spinlock __attribute__((unused))); +static __attribute__((unused)) DEFINE_SPINLOCK(ps_spinlock); static DECLARE_WORK(ps_tq, ps_tq_int, NULL); Regards, -- Luca - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RCU in kernel/intermodule.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch, compiled against version 2.6.12-rc1, implements RCU mechanism in
intermodule functions.
Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]>
- --- ./kernel/intermodule.c.orig 2005-04-01 19:25:26.0 +
+++ ./kernel/intermodule.c 2005-04-02 02:46:22.0 +
@@ -3,7 +3,7 @@
/* Written by Keith Owens Oct 2000 */
#include
#include
- -#include
+#include
#include
#include
@@ -14,7 +14,6 @@
*/
static struct list_head ime_list = LIST_HEAD_INIT(ime_list);
- -static DEFINE_SPINLOCK(ime_lock);
static int kmalloc_failed;
struct inter_module_entry {
@@ -22,8 +21,17 @@ struct inter_module_entry {
const char *im_name;
struct module *owner;
const void *userdata;
+ struct rcu_head rcu;
};
+static void inter_module_free(struct rcu_head *rcu)
+{
+ struct inter_module_entry *ime;
+
+ ime = container_of(rcu, struct inter_module_entry, rcu);
+ kfree(ime);
+}
+
/**
* inter_module_register - register a new set of inter module data.
* @im_name: an arbitrary string to identify the data, must be unique
@@ -36,7 +44,6 @@ struct inter_module_entry {
*/
void inter_module_register(const char *im_name, struct module *owner, const
void *userdata)
{
- - struct list_head *tmp;
struct inter_module_entry *ime, *ime_new;
if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) {
@@ -52,19 +59,15 @@ void inter_module_register(const char *i
ime_new->owner = owner;
ime_new->userdata = userdata;
- - spin_lock(_lock);
- - list_for_each(tmp, _list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ list_for_each_entry(ime, _list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
- - spin_unlock(_lock);
kfree(ime_new);
/* Program logic error, fatal */
printk(KERN_ERR "inter_module_register: duplicate
im_name '%s'", im_name);
BUG();
}
}
- - list_add(&(ime_new->list), _list);
- - spin_unlock(_lock);
+ list_add_rcu(_new->list, _list);
}
/**
@@ -77,20 +80,15 @@ void inter_module_register(const char *i
*/
void inter_module_unregister(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
- - spin_lock(_lock);
- - list_for_each(tmp, _list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ list_for_each_entry(ime, _list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
- - list_del(&(ime->list));
- - spin_unlock(_lock);
- - kfree(ime);
+ list_del_rcu(&(ime->list));
+ call_rcu(>rcu, inter_module_free);
return;
}
}
- - spin_unlock(_lock);
if (kmalloc_failed) {
printk(KERN_ERR
"inter_module_unregister: no entry for '%s', "
@@ -115,20 +113,18 @@ void inter_module_unregister(const char
*/
static const void *inter_module_get(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
const void *result = NULL;
- - spin_lock(_lock);
- - list_for_each(tmp, _list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ rcu_read_lock();
+ list_for_each_entry_rcu(ime, _list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
if (try_module_get(ime->owner))
result = ime->userdata;
break;
}
}
- - spin_unlock(_lock);
+ rcu_read_unlock();
return(result);
}
@@ -158,20 +154,18 @@ const void *inter_module_get_request(con
*/
void inter_module_put(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
- - spin_lock(_lock);
- - list_for_each(tmp, _list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ rcu_read_lock();
+ list_for_each_entry(ime, _list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
if (ime->owner)
module_put(ime->owner);
- - spin_unlock(_lock);
+ rcu_read_unlock();
return;
}
}
- - spin_unlock(_lock);
+ rcu_read_unlock();
printk(KERN_ERR "inter_module_put: no entry for '%s'", im_name);
BUG();
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQEVAwUBQk6BzMzkDT3RfMB6AQI+BggAu476
[PATCH] RCU in kernel/intermodule.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch, compiled against version 2.6.12-rc1, implements RCU mechanism in
intermodule functions.
Signed-off-by: Luca Falavigna [EMAIL PROTECTED]
- --- ./kernel/intermodule.c.orig 2005-04-01 19:25:26.0 +
+++ ./kernel/intermodule.c 2005-04-02 02:46:22.0 +
@@ -3,7 +3,7 @@
/* Written by Keith Owens kaos@ocs.com.au Oct 2000 */
#include linux/module.h
#include linux/kmod.h
- -#include linux/spinlock.h
+#include linux/rcupdate.h
#include linux/list.h
#include linux/slab.h
@@ -14,7 +14,6 @@
*/
static struct list_head ime_list = LIST_HEAD_INIT(ime_list);
- -static DEFINE_SPINLOCK(ime_lock);
static int kmalloc_failed;
struct inter_module_entry {
@@ -22,8 +21,17 @@ struct inter_module_entry {
const char *im_name;
struct module *owner;
const void *userdata;
+ struct rcu_head rcu;
};
+static void inter_module_free(struct rcu_head *rcu)
+{
+ struct inter_module_entry *ime;
+
+ ime = container_of(rcu, struct inter_module_entry, rcu);
+ kfree(ime);
+}
+
/**
* inter_module_register - register a new set of inter module data.
* @im_name: an arbitrary string to identify the data, must be unique
@@ -36,7 +44,6 @@ struct inter_module_entry {
*/
void inter_module_register(const char *im_name, struct module *owner, const
void *userdata)
{
- - struct list_head *tmp;
struct inter_module_entry *ime, *ime_new;
if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) {
@@ -52,19 +59,15 @@ void inter_module_register(const char *i
ime_new-owner = owner;
ime_new-userdata = userdata;
- - spin_lock(ime_lock);
- - list_for_each(tmp, ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ list_for_each_entry(ime, ime_list, list) {
if (strcmp(ime-im_name, im_name) == 0) {
- - spin_unlock(ime_lock);
kfree(ime_new);
/* Program logic error, fatal */
printk(KERN_ERR inter_module_register: duplicate
im_name '%s', im_name);
BUG();
}
}
- - list_add((ime_new-list), ime_list);
- - spin_unlock(ime_lock);
+ list_add_rcu(ime_new-list, ime_list);
}
/**
@@ -77,20 +80,15 @@ void inter_module_register(const char *i
*/
void inter_module_unregister(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
- - spin_lock(ime_lock);
- - list_for_each(tmp, ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ list_for_each_entry(ime, ime_list, list) {
if (strcmp(ime-im_name, im_name) == 0) {
- - list_del((ime-list));
- - spin_unlock(ime_lock);
- - kfree(ime);
+ list_del_rcu((ime-list));
+ call_rcu(ime-rcu, inter_module_free);
return;
}
}
- - spin_unlock(ime_lock);
if (kmalloc_failed) {
printk(KERN_ERR
inter_module_unregister: no entry for '%s',
@@ -115,20 +113,18 @@ void inter_module_unregister(const char
*/
static const void *inter_module_get(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
const void *result = NULL;
- - spin_lock(ime_lock);
- - list_for_each(tmp, ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ rcu_read_lock();
+ list_for_each_entry_rcu(ime, ime_list, list) {
if (strcmp(ime-im_name, im_name) == 0) {
if (try_module_get(ime-owner))
result = ime-userdata;
break;
}
}
- - spin_unlock(ime_lock);
+ rcu_read_unlock();
return(result);
}
@@ -158,20 +154,18 @@ const void *inter_module_get_request(con
*/
void inter_module_put(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
- - spin_lock(ime_lock);
- - list_for_each(tmp, ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ rcu_read_lock();
+ list_for_each_entry(ime, ime_list, list) {
if (strcmp(ime-im_name, im_name) == 0) {
if (ime-owner)
module_put(ime-owner);
- - spin_unlock(ime_lock);
+ rcu_read_unlock();
return;
}
}
- - spin_unlock(ime_lock);
+ rcu_read_unlock();
printk(KERN_ERR inter_module_put: no entry for '%s', im_name);
BUG();
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http
Some questions about VM flags
I was playing with mprotect and VM flags when I noticed two curious behaviours.
1)
This C program modifies data segments's flags:
#include
#include
/* Values shown by /proc//maps */
#define START 0x08049000
#define END 0x0804a000
int target;
int main(void)
{
printf("ADDRESS: %p\n", );
target = 1;
mprotect((void *)START, END - START, PROT_WRITE);
printf("%d\n", target);
return 0;
}
After the mprotect call, data segment's flags are
08049000-0804a000 -w-p 03:06 297330 /home/dktrkranz/vmflags_read
Shouldn't printf generate a segfault trying to read a variabile located in a
write-only area?
2)
This C program tries to execute a shellcode:
/* This shellcode calls write and exit. It's harmless ;) */
char shellcode[] =
"\x31\xc0\x31\xdb\x31\xd2\x53\x68\x7a\x0a\x00\x00\x68\x4b\x72"
"\x61\x6e\x68\x44\x6b\x74\x72\x89\xe1\xb2\x0a\xb0\x04\xcd\x80"
"\x31\xc0\x31\xdb\xb0\x01\xcd\x80";
int main(void)
{
void(*sc)(void);
sc = (void *)
sc();
return 0;
}
These are data segment's flags:
08049000-0804a000 rw-p 03:06 297330 /home/dktrkranz/vmflags_sc
Shellcode lies in this segment. It is executed even if VM_EXEC isn't set. I
think execution shouldn't be permitted if only VM_READ or VM_WRITE flags are
set. Buffer overflows/format string based exploits wouldn't be so popular if we
implemented this feaure. Please let me know your opinion.
Thank you,
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Some questions about VM flags
I was playing with mprotect and VM flags when I noticed two curious behaviours.
1)
This C program modifies data segments's flags:
#include stdio.h
#include sys/mman.h
/* Values shown by /proc/pid/maps */
#define START 0x08049000
#define END 0x0804a000
int target;
int main(void)
{
printf(ADDRESS: %p\n, target);
target = 1;
mprotect((void *)START, END - START, PROT_WRITE);
printf(%d\n, target);
return 0;
}
After the mprotect call, data segment's flags are
08049000-0804a000 -w-p 03:06 297330 /home/dktrkranz/vmflags_read
Shouldn't printf generate a segfault trying to read a variabile located in a
write-only area?
2)
This C program tries to execute a shellcode:
/* This shellcode calls write and exit. It's harmless ;) */
char shellcode[] =
\x31\xc0\x31\xdb\x31\xd2\x53\x68\x7a\x0a\x00\x00\x68\x4b\x72
\x61\x6e\x68\x44\x6b\x74\x72\x89\xe1\xb2\x0a\xb0\x04\xcd\x80
\x31\xc0\x31\xdb\xb0\x01\xcd\x80;
int main(void)
{
void(*sc)(void);
sc = (void *)shellcode;
sc();
return 0;
}
These are data segment's flags:
08049000-0804a000 rw-p 03:06 297330 /home/dktrkranz/vmflags_sc
Shellcode lies in this segment. It is executed even if VM_EXEC isn't set. I
think execution shouldn't be permitted if only VM_READ or VM_WRITE flags are
set. Buffer overflows/format string based exploits wouldn't be so popular if we
implemented this feaure. Please let me know your opinion.
Thank you,
Luca
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
EIP and VMA
Hi,
I am working on this piece of code (simplified):
void ip_vma(struct task_struct *task, struct pt_regs *regs)
{
struct mm_struct *mm;
struct vm_area_struct *vma;
if(task) {
mm = get_task_mm(task);
if(mm) {
vma = find_vma(mm, regs->eip);
if(vma) {
/* Some code */
}
else
printk("WARNING: No VMA\n");
mmput(mm);
}
}
}
I would like to get instruction pointer's VMA of a task. In order to do so, I
use find_vma function, using regs->eip as instruction pointer value.
Unfortunately I always get "WARNING: No VMA" message because find_vma isn't able
to find the right VMA regs->eip address belongs to.
Is regs->eip the right place where istruction pointer is located or I should
find that value elsewhere?
Thank you,
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
EIP and VMA
Hi,
I am working on this piece of code (simplified):
void ip_vma(struct task_struct *task, struct pt_regs *regs)
{
struct mm_struct *mm;
struct vm_area_struct *vma;
if(task) {
mm = get_task_mm(task);
if(mm) {
vma = find_vma(mm, regs->eip);
if(vma) {
/* Some code */
}
else
printk("WARNING: No VMA\n");
mmput(mm);
}
}
}
I would like to get instruction pointer's VMA of a task. In order to do so, I
use find_vma function, using regs->eip as instruction pointer value.
Unfortunately I always get "WARNING: No VMA" message because find_vma isn't able
to find the right VMA regs->eip address belongs to.
Is regs->eip the right place where istruction pointer is located or I should
find that value elsewhere?
Thank you,
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
EIP and VMA
Hi,
I am working on this piece of code (simplified):
void ip_vma(struct task_struct *task, struct pt_regs *regs)
{
struct mm_struct *mm;
struct vm_area_struct *vma;
if(task) {
mm = get_task_mm(task);
if(mm) {
vma = find_vma(mm, regs-eip);
if(vma) {
/* Some code */
}
else
printk(WARNING: No VMA\n);
mmput(mm);
}
}
}
I would like to get instruction pointer's VMA of a task. In order to do so, I
use find_vma function, using regs-eip as instruction pointer value.
Unfortunately I always get WARNING: No VMA message because find_vma isn't able
to find the right VMA regs-eip address belongs to.
Is regs-eip the right place where istruction pointer is located or I should
find that value elsewhere?
Thank you,
Luca
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
EIP and VMA
Hi,
I am working on this piece of code (simplified):
void ip_vma(struct task_struct *task, struct pt_regs *regs)
{
struct mm_struct *mm;
struct vm_area_struct *vma;
if(task) {
mm = get_task_mm(task);
if(mm) {
vma = find_vma(mm, regs-eip);
if(vma) {
/* Some code */
}
else
printk(WARNING: No VMA\n);
mmput(mm);
}
}
}
I would like to get instruction pointer's VMA of a task. In order to do so, I
use find_vma function, using regs-eip as instruction pointer value.
Unfortunately I always get WARNING: No VMA message because find_vma isn't able
to find the right VMA regs-eip address belongs to.
Is regs-eip the right place where istruction pointer is located or I should
find that value elsewhere?
Thank you,
Luca
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kprobes /proc entry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greg KH ha scritto:
> Also, why not use the seqfile interface for this, to prevent overflowing
> the read buffer?
Great idea!
> Am I missing where you allocate the space for the data to be put into?
seq_read does the job now. It manages to allocate PAGE_SIZE bytes.
Assuming function, hook and module names occupy KSYM_NAME_LEN bytes each,
maximum length will be 424 bytes for each kprobe. I don't think it would be
useful to allocate more memory than PAGE_SIZE. Please, let me know your opinion.
- --- ./kernel/kprobes.c2005-01-19 11:03:03.0 +0100
+++ ./kernel/kprobes.c 2005-01-20 15:02:47.0 +0100
@@ -33,6 +33,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
#include
@@ -45,6 +49,13 @@
unsigned int kprobe_cpu = NR_CPUS;
static DEFINE_SPINLOCK(kprobe_lock);
+static char *ktype[] = {
+ "PRE",
+ "POST",
+ "FAULT",
+ "BREAK",
+};
+
/* Locks kprobe: irqs must be disabled */
void lock_kprobes(void)
{
@@ -131,15 +142,92 @@
unregister_kprobe(>kp);
}
+static void kprobes_print(struct seq_file *seq, unsigned long addr,
+ unsigned long handler, int type)
+{
+ char *module, namebuf[KSYM_NAME_LEN+1];
+ const char *hook, *func;
+ unsigned long off, size;
+
+ func = kallsyms_lookup(addr, , , , namebuf);
+ seq_printf(seq, "%s\t0x%lx(%s+%#lx)\t", ktype[type], addr, func, off);
+ hook = kallsyms_lookup(handler, , , , namebuf);
+ seq_printf(seq, "0x%lx(%s)\t%s\n", handler, hook,
+ strlen(module) ? module : "[built-in]");
+}
+
+static int kprobes_show(struct seq_file *seq, void *unused)
+{
+ int i;
+ struct kprobe *k;
+ struct hlist_node *node;
+ unsigned long addr, handler;
+
+ spin_lock(_lock);
+ for(i = 0; i < KPROBE_TABLE_SIZE; i++) {
+ hlist_for_each_entry(k, node, _table[i], hlist) {
+ if(!k)
+ continue;
+ addr = (unsigned long)k->addr;
+ if(k->pre_handler) {
+ handler = (unsigned long)k->pre_handler;
+ kprobes_print(seq, addr, handler, PRE);
+ }
+ if(k->post_handler) {
+ handler = (unsigned long)k->post_handler;
+ kprobes_print(seq, addr, handler, POST);
+ }
+ if(k->fault_handler) {
+ handler = (unsigned long)k->fault_handler;
+ kprobes_print(seq, addr, handler, FAULT);
+ }
+ if(k->break_handler) {
+ handler = (unsigned long)k->break_handler;
+ kprobes_print(seq, addr, handler, BREAK);
+ }
+ }
+ }
+ spin_unlock(_lock);
+ return 0;
+}
+
+static int kprobes_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, kprobes_show, NULL);
+}
+
+static struct file_operations kprobes_fops = {
+ .open = kprobes_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .owner = THIS_MODULE
+};
+
static int __init init_kprobes(void)
{
int i, err = 0;
+ struct dentry *kprobes_dir, *kprobes_list;
/* FIXME allocate the probe table, currently defined statically */
/* initialize all list heads */
for (i = 0; i < KPROBE_TABLE_SIZE; i++)
INIT_HLIST_HEAD(_table[i]);
+ kprobes_dir = debugfs_create_dir("kprobes", NULL);
+ if(!kprobes_dir) {
+ printk("kprobes: could not create debugfs entry\n");
+ goto finish;
+ }
+ kprobes_list = debugfs_create_file("list", S_IRUGO, kprobes_dir,
+ NULL, _fops);
+ if(!kprobes_list) {
+ printk("kprobes: could not create debugfs entry\n");
+ debugfs_remove(kprobes_dir);
+ goto finish;
+ }
+
+finish:
err = register_die_notifier(_exceptions_nb);
return err;
}
- --- ./include/linux/kprobes.h 2005-01-03 20:40:51.0 +0100
+++ ./include/linux/kprobes.h 2005-01-20 13:59:27.0 +0100
@@ -82,6 +82,13 @@
kprobe_opcode_t *entry; /* probe handling code to jump to */
};
+enum kprobe_type {
+ PRE=0,
+ POST,
+ FAULT,
+ BREAK,
+};
+
#ifdef CONFIG_KPROBES
/* Locks kprobe: irq must be disabled */
void lock_kprobes(void);
Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]>
Re
Re: [PATCH] Kprobes /proc entry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greg KH ha scritto:
Also, why not use the seqfile interface for this, to prevent overflowing
the read buffer?
Great idea!
Am I missing where you allocate the space for the data to be put into?
seq_read does the job now. It manages to allocate PAGE_SIZE bytes.
Assuming function, hook and module names occupy KSYM_NAME_LEN bytes each,
maximum length will be 424 bytes for each kprobe. I don't think it would be
useful to allocate more memory than PAGE_SIZE. Please, let me know your opinion.
- --- ./kernel/kprobes.c2005-01-19 11:03:03.0 +0100
+++ ./kernel/kprobes.c 2005-01-20 15:02:47.0 +0100
@@ -33,6 +33,10 @@
#include linux/hash.h
#include linux/init.h
#include linux/module.h
+#include linux/fs.h
+#include linux/debugfs.h
+#include linux/kallsyms.h
+#include linux/seq_file.h
#include asm/cacheflush.h
#include asm/errno.h
#include asm/kdebug.h
@@ -45,6 +49,13 @@
unsigned int kprobe_cpu = NR_CPUS;
static DEFINE_SPINLOCK(kprobe_lock);
+static char *ktype[] = {
+ PRE,
+ POST,
+ FAULT,
+ BREAK,
+};
+
/* Locks kprobe: irqs must be disabled */
void lock_kprobes(void)
{
@@ -131,15 +142,92 @@
unregister_kprobe(jp-kp);
}
+static void kprobes_print(struct seq_file *seq, unsigned long addr,
+ unsigned long handler, int type)
+{
+ char *module, namebuf[KSYM_NAME_LEN+1];
+ const char *hook, *func;
+ unsigned long off, size;
+
+ func = kallsyms_lookup(addr, size, off, module, namebuf);
+ seq_printf(seq, %s\t0x%lx(%s+%#lx)\t, ktype[type], addr, func, off);
+ hook = kallsyms_lookup(handler, size, off, module, namebuf);
+ seq_printf(seq, 0x%lx(%s)\t%s\n, handler, hook,
+ strlen(module) ? module : [built-in]);
+}
+
+static int kprobes_show(struct seq_file *seq, void *unused)
+{
+ int i;
+ struct kprobe *k;
+ struct hlist_node *node;
+ unsigned long addr, handler;
+
+ spin_lock(kprobe_lock);
+ for(i = 0; i KPROBE_TABLE_SIZE; i++) {
+ hlist_for_each_entry(k, node, kprobe_table[i], hlist) {
+ if(!k)
+ continue;
+ addr = (unsigned long)k-addr;
+ if(k-pre_handler) {
+ handler = (unsigned long)k-pre_handler;
+ kprobes_print(seq, addr, handler, PRE);
+ }
+ if(k-post_handler) {
+ handler = (unsigned long)k-post_handler;
+ kprobes_print(seq, addr, handler, POST);
+ }
+ if(k-fault_handler) {
+ handler = (unsigned long)k-fault_handler;
+ kprobes_print(seq, addr, handler, FAULT);
+ }
+ if(k-break_handler) {
+ handler = (unsigned long)k-break_handler;
+ kprobes_print(seq, addr, handler, BREAK);
+ }
+ }
+ }
+ spin_unlock(kprobe_lock);
+ return 0;
+}
+
+static int kprobes_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, kprobes_show, NULL);
+}
+
+static struct file_operations kprobes_fops = {
+ .open = kprobes_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .owner = THIS_MODULE
+};
+
static int __init init_kprobes(void)
{
int i, err = 0;
+ struct dentry *kprobes_dir, *kprobes_list;
/* FIXME allocate the probe table, currently defined statically */
/* initialize all list heads */
for (i = 0; i KPROBE_TABLE_SIZE; i++)
INIT_HLIST_HEAD(kprobe_table[i]);
+ kprobes_dir = debugfs_create_dir(kprobes, NULL);
+ if(!kprobes_dir) {
+ printk(kprobes: could not create debugfs entry\n);
+ goto finish;
+ }
+ kprobes_list = debugfs_create_file(list, S_IRUGO, kprobes_dir,
+ NULL, kprobes_fops);
+ if(!kprobes_list) {
+ printk(kprobes: could not create debugfs entry\n);
+ debugfs_remove(kprobes_dir);
+ goto finish;
+ }
+
+finish:
err = register_die_notifier(kprobe_exceptions_nb);
return err;
}
- --- ./include/linux/kprobes.h 2005-01-03 20:40:51.0 +0100
+++ ./include/linux/kprobes.h 2005-01-20 13:59:27.0 +0100
@@ -82,6 +82,13 @@
kprobe_opcode_t *entry; /* probe handling code to jump to */
};
+enum kprobe_type {
+ PRE=0,
+ POST,
+ FAULT,
+ BREAK,
+};
+
#ifdef CONFIG_KPROBES
/* Locks kprobe: irq must be disabled */
void lock_kprobes(void);
Signed-off-by: Luca Falavigna [EMAIL PROTECTED]
Regards
Re: [PATCH] Kprobes /proc entry
entry\n");
+ goto finish;
+ }
+ kprobes_list = debugfs_create_file("list", S_IRUGO, kprobes_dir,
+ NULL, _fops);
+ if(!kprobes_list) {
+ printk("kprobes: could not create debugfs entry\n");
+ debugfs_remove(kprobes_dir);
+ goto finish;
+ }
+
+finish:
err = register_die_notifier(_exceptions_nb);
return err;
}
Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]>
Regards,
Luca
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQEVAwUBQevumBZrwl7j21nOAQL46Af/apeTfTYuXvDdhWFsqWI7QBqpmYkj9+iu
S4A2EKsBUUlnlcZrpL08lqwMup2H8jt3zjmmCcPn2Oplr054aHIDIQveu5XMA+jJ
9w5EdDf3SZcPF+HEPmN9EV5n0BakVwGERM/8615jH804Y5IJtB8b79XMmU8wLI8x
M4JGa+kwboD260IbWRuxfRUVqJMMVL5Mibin0RFN4WCbJYfxPhDiCsH2HGNgrw1Y
m0uyuaUt4pynAVPpHJPAKPylwY/A9MC7/Zdfa2IIO118bNxKaFTMg0z+AN66jUwz
kRUzxoUfDv3kIhzkHwvyPX9hjsoSPof/xQZwxclz8p6Yz00KICdZRw==
=Ka0n
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kprobes /proc entry
, S_IRUGO, kprobes_dir,
+ NULL, kprobes_fops);
+ if(!kprobes_list) {
+ printk(kprobes: could not create debugfs entry\n);
+ debugfs_remove(kprobes_dir);
+ goto finish;
+ }
+
+finish:
err = register_die_notifier(kprobe_exceptions_nb);
return err;
}
Signed-off-by: Luca Falavigna [EMAIL PROTECTED]
Regards,
Luca
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQEVAwUBQevumBZrwl7j21nOAQL46Af/apeTfTYuXvDdhWFsqWI7QBqpmYkj9+iu
S4A2EKsBUUlnlcZrpL08lqwMup2H8jt3zjmmCcPn2Oplr054aHIDIQveu5XMA+jJ
9w5EdDf3SZcPF+HEPmN9EV5n0BakVwGERM/8615jH804Y5IJtB8b79XMmU8wLI8x
M4JGa+kwboD260IbWRuxfRUVqJMMVL5Mibin0RFN4WCbJYfxPhDiCsH2HGNgrw1Y
m0uyuaUt4pynAVPpHJPAKPylwY/A9MC7/Zdfa2IIO118bNxKaFTMg0z+AN66jUwz
kRUzxoUfDv3kIhzkHwvyPX9hjsoSPof/xQZwxclz8p6Yz00KICdZRw==
=Ka0n
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
