Re: [1/2] 2.6.22-rc5: known regressions with patches v2
On 22/06/07, Alan Cox <[EMAIL PROTECTED]> wrote: On Fri, 22 Jun 2007 14:39:50 +0300 "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > We have patches for "very high non-preempt latency in > > context_struct_compute_av()" and "list_add corruption. prev->next > > should be next (f7d28794), but was f0df8ed4 (prev=f0df8ed4) Kernel Bug > > at lib/list_debug.c:33", but both are too intrusive. > > > > Anyway, those bugs are not regressions. > The question was "why linux kernel release should have some bugs that > would be fixed fixed in future?" Because those bug fixes are intrusive so will potentially cause more other bugs that will need fixing - so make the kernel a worse not a better one in the short term. > Let's wait and publish kernel w/o known bugs. That would be a bit like waiting for a Debian release and never happen. I'm trying to imagine this - Linux 2.6 "Debian style" roadmap: 15-VII-2007 - release of Linux 2.6.22 1-VIII-2007 - freeze 15-II-2009 - release of Linux 2.6.23 1-III-2009 - freeze 1-IX-2010 - release of Linux 2.6.24 :) Alan Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
That would be a bit like waiting for a Debian release and never happen. Ok, but Debian seems to be stable and sometimes their teem make releases =). - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
On Fri, 22 Jun 2007 14:39:50 +0300 "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > We have patches for "very high non-preempt latency in > > context_struct_compute_av()" and "list_add corruption. prev->next > > should be next (f7d28794), but was f0df8ed4 (prev=f0df8ed4) Kernel Bug > > at lib/list_debug.c:33", but both are too intrusive. > > > > Anyway, those bugs are not regressions. > The question was "why linux kernel release should have some bugs that > would be fixed fixed in future?" Because those bug fixes are intrusive so will potentially cause more other bugs that will need fixing - so make the kernel a worse not a better one in the short term. > Let's wait and publish kernel w/o known bugs. That would be a bit like waiting for a Debian release and never happen. Alan - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
We have patches for "very high non-preempt latency in context_struct_compute_av()" and "list_add corruption. prev->next should be next (f7d28794), but was f0df8ed4 (prev=f0df8ed4) Kernel Bug at lib/list_debug.c:33", but both are too intrusive. Anyway, those bugs are not regressions. Are you going to release 2.6.22 with this bugs?? But question wasn't on this subject ... The question was "why linux kernel release should have some bugs that would be fixed fixed in future?" Let's wait and publish kernel w/o known bugs. Let's wait for some time, let's publish 2.6.22-rc_last, test it for some time(2 weeks for example), fix bugs if any and after _test_period_of_whole_kernel_ but not _separate_patches/parts_ of kernel release stable one! - 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/
[1/2] 2.6.22-rc5: known regressions with patches v2
Hello! I'm a newbuy in kernel development. Now I'm just trying to find out what is going in it =). I noticed this: (BTW. There is a new category called "Will be fixed in 2.6.23") Is it really important to release 2.6.22 as soon as possible? I think kernel should be 99% stable. Why not to wait for patches on known regressions and release more or less stable 2.6.22? Thanks! Best wishes, Niam. - 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/
[1/2] 2.6.22-rc5: known regressions with patches v2
Hello! I'm a newbuy in kernel development. Now I'm just trying to find out what is going in it =). I noticed this: (BTW. There is a new category called Will be fixed in 2.6.23) Is it really important to release 2.6.22 as soon as possible? I think kernel should be 99% stable. Why not to wait for patches on known regressions and release more or less stable 2.6.22? Thanks! Best wishes, Niam. - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
On Fri, 22 Jun 2007 14:39:50 +0300 [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: We have patches for very high non-preempt latency in context_struct_compute_av() and list_add corruption. prev-next should be next (f7d28794), but was f0df8ed4 (prev=f0df8ed4) Kernel Bug at lib/list_debug.c:33, but both are too intrusive. Anyway, those bugs are not regressions. The question was why linux kernel release should have some bugs that would be fixed fixed in future? Because those bug fixes are intrusive so will potentially cause more other bugs that will need fixing - so make the kernel a worse not a better one in the short term. Let's wait and publish kernel w/o known bugs. That would be a bit like waiting for a Debian release and never happen. Alan - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
We have patches for very high non-preempt latency in context_struct_compute_av() and list_add corruption. prev-next should be next (f7d28794), but was f0df8ed4 (prev=f0df8ed4) Kernel Bug at lib/list_debug.c:33, but both are too intrusive. Anyway, those bugs are not regressions. Are you going to release 2.6.22 with this bugs?? But question wasn't on this subject ... The question was why linux kernel release should have some bugs that would be fixed fixed in future? Let's wait and publish kernel w/o known bugs. Let's wait for some time, let's publish 2.6.22-rc_last, test it for some time(2 weeks for example), fix bugs if any and after _test_period_of_whole_kernel_ but not _separate_patches/parts_ of kernel release stable one! - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
That would be a bit like waiting for a Debian release and never happen. Ok, offtopbut Debian seems to be stable and sometimes their teem make releases =)./offtop - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
On 22/06/07, Alan Cox [EMAIL PROTECTED] wrote: On Fri, 22 Jun 2007 14:39:50 +0300 [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: We have patches for very high non-preempt latency in context_struct_compute_av() and list_add corruption. prev-next should be next (f7d28794), but was f0df8ed4 (prev=f0df8ed4) Kernel Bug at lib/list_debug.c:33, but both are too intrusive. Anyway, those bugs are not regressions. The question was why linux kernel release should have some bugs that would be fixed fixed in future? Because those bug fixes are intrusive so will potentially cause more other bugs that will need fixing - so make the kernel a worse not a better one in the short term. Let's wait and publish kernel w/o known bugs. That would be a bit like waiting for a Debian release and never happen. I'm trying to imagine this - Linux 2.6 Debian style roadmap: 15-VII-2007 - release of Linux 2.6.22 1-VIII-2007 - freeze 15-II-2009 - release of Linux 2.6.23 1-III-2009 - freeze 1-IX-2010 - release of Linux 2.6.24 :) Alan Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
Linus Torvalds pisze: On Thu, 21 Jun 2007, Michal Piotrowski wrote: Subject: long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi <[EMAIL PROTECTED]> Handled-By : Ingo Molnar <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/16/81 Status : patch was suggested This one is fixed, and tested by Miklos. It's commit fa490cfd15: "Fix possible runqueue lock starvation in wait_task_inactive()". Thanks for the information. BTW. Björn noticed that I accidentally removed this regression. Subject: OProfile issues References : http://lkml.org/lkml/2007/6/12/207 Submitter : Stephane Eranian <[EMAIL PROTECTED]> Handled-By : Björn Steinbrink <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/12/392 Status : patch was suggested Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
On Thu, 21 Jun 2007, Michal Piotrowski wrote: > > Subject: long freezes on thinkpad t60 > References : http://lkml.org/lkml/2007/5/24/100 > Submitter : Miklos Szeredi <[EMAIL PROTECTED]> > Handled-By : Ingo Molnar <[EMAIL PROTECTED]> > Patch : http://lkml.org/lkml/2007/6/16/81 > Status : patch was suggested This one is fixed, and tested by Miklos. It's commit fa490cfd15: "Fix possible runqueue lock starvation in wait_task_inactive()". Linus - 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/
[1/2] 2.6.22-rc5: known regressions with patches v2
Hi all, Here is a list of some known regressions in 2.6.22-rc5 with patches available. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions (BTW. There is a new category called "Will be fixed in 2.6.23") Unclassified Subject: Device hang when offlining a CPU due to IRQ misrouting References : http://lkml.org/lkml/2007/5/31/419 Submitter : Darrick J. Wong <[EMAIL PROTECTED]> Handled-By : Siddha, Suresh B <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/19/422 Status : patch available Subject: long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi <[EMAIL PROTECTED]> Handled-By : Ingo Molnar <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/16/81 Status : patch was suggested FBDEV Subject: mach64 breakage in 2.6.22 References : http://lkml.org/lkml/2007/6/14/73 Submitter : Olaf Hering <[EMAIL PROTECTED]> Handled-By : Ville Syrjälä <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/14/273 Status : patch was suggested HWMON Subject: latest coretemp changes break s2ram References : http://lkml.org/lkml/2007/6/16/173 Submitter : Soeren Sonnenburg <[EMAIL PROTECTED]> Caused-By : Rudolf Marek <[EMAIL PROTECTED]> commit 67f363b1f6a31cf5027a97372f64bcced4f05ba6 Handled-By : Jean Delvare <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/16/177 Status : patch available Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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] Alternative fix for kprobes_RODATA was Re: [1/2] 2.6.22-rc5: known regressions with patches
On Thu, 21 Jun 2007, Andi Kleen wrote: > Ok, here's a patch to do this. With that > 55181000cd60334fe920c65ffbcdfe0e3f1de406 > should be reverted because it isn't needed anymore. This seems buggy: > + int notext = 0; > > +#ifdef CONFIG_KPROBES > + notext = 1; > +#endif > #ifdef CONFIG_HOTPLUG_CPU > /* It must still be possible to apply SMP alternatives. */ > - if (num_possible_cpus() <= 1) > + notext = (num_possible_cpus() > 1); > #endif The CONFIG_HOTPLUG_CPU case will overwrite the CONFIG_KPROBES, and turn it back to zero for a single CPU. Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 06/20/2007 07:04 PM, Linus Torvalds wrote: > As far as I know, the biggest reason to use DEBUG_RODATA is > > (a) Hey, it's a cheap way to check one thing > > (b) An added layer of security (which it's not that great for, but it > might make sense to make it more of a real security feature). > And as a security feature it's pretty useless if kprobes are allowed. - 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: [1/2] 2.6.22-rc5: known regressions with patches
> Shouldn't we add something to the help texts? > > + This option also marks kernel text pages as write-protected, > + except if you enable KPROBES. > > CMIIW. > > As mentioned elsewhere in this thread, replacing CONFIG_DEBUG_RODATA by > CONFIG_WRITEPROTECT_RODATA and CONFIG_WRITEPROTECT_TEXT might be a > better idea. The latter should be mutual exclusive with CONFIG_KPROBES. lets do the minimal now for 2.6.22, and do it right for .23 please -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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: [1/2] 2.6.22-rc5: known regressions with patches
Arjan van de Ven wrote: > --- linux-2.6.22-rc5/arch/i386/Kconfig.debug.org 2007-06-20 > 22:20:30.0 -0700 > +++ linux-2.6.22-rc5/arch/i386/Kconfig.debug 2007-06-20 22:20:55.0 > -0700 > @@ -49,7 +49,6 @@ config DEBUG_PAGEALLOC > config DEBUG_RODATA > bool "Write protect kernel read-only data structures" > depends on DEBUG_KERNEL > - depends on !KPROBES # temporary for 2.6.22 > help > Mark the kernel read-only data as write-protected in the pagetables, > in order to catch accidental (and incorrect) writes to such const > --- linux-2.6.22-rc5/arch/x86_64/Kconfig.debug.org2007-06-20 > 22:20:28.0 -0700 > +++ linux-2.6.22-rc5/arch/x86_64/Kconfig.debug2007-06-20 > 22:20:44.0 -0700 > @@ -9,7 +9,6 @@ source "lib/Kconfig.debug" > config DEBUG_RODATA > bool "Write protect kernel read-only data structures" > depends on DEBUG_KERNEL > - depends on !KPROBES # temporary for 2.6.22 > help >Mark the kernel read-only data as write-protected in the pagetables, >in order to catch accidental (and incorrect) writes to such const data. Shouldn't we add something to the help texts? + This option also marks kernel text pages as write-protected, + except if you enable KPROBES. CMIIW. As mentioned elsewhere in this thread, replacing CONFIG_DEBUG_RODATA by CONFIG_WRITEPROTECT_RODATA and CONFIG_WRITEPROTECT_TEXT might be a better idea. The latter should be mutual exclusive with CONFIG_KPROBES. -- Stefan Richter -=-=-=== -==- =-=-= http://arcgraph.de/sr/ - 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] Alternative fix for kprobes_RODATA was Re: [1/2] 2.6.22-rc5: known regressions with patches
On Thursday 21 June 2007 01:48:43 Linus Torvalds wrote:
>
> On Wed, 20 Jun 2007, Dave Jones wrote:
> >
> > Surely the fundamental disagreement is only due to DEBUG_RODATA
> > covering write-protection of both .text, and .rodata ?
>
> I agree that we could well split DEBUG_RODATA into something more
> fine-grained, and for example have it _only_ protect that .rodata thing
> when Kprobes are enabled, and both .text _and_ .rodata when Kprobes are
> not.
>
> That would make lots of sense.
Ok, here's a patch to do this. With that
55181000cd60334fe920c65ffbcdfe0e3f1de406
should be reverted because it isn't needed anymore.
I still think in .23 it should be fixed properly, by either using c_p_a()
as needed in the kprobes/alternatives code (Prasanna already had a patch)
or perhaps better just doing a temporal ioremap() there.
-Andi
---
Disable kernel text protection when kprobes are enabled
To be done better in .23
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/arch/x86_64/mm/init.c
===
--- linux.orig/arch/x86_64/mm/init.c
+++ linux/arch/x86_64/mm/init.c
@@ -600,6 +600,10 @@ void mark_rodata_ro(void)
{
unsigned long start = (unsigned long)_stext, end;
+#ifdef CONFIG_KPROBES
+ /* Kprobes code doesn't know yet how to unprotect. Temporary fix. */
+ start = (unsigned long)_etext;
+#endif
#ifdef CONFIG_HOTPLUG_CPU
/* It must still be possible to apply SMP alternatives. */
if (num_possible_cpus() > 1)
Index: linux/arch/i386/mm/init.c
===
--- linux.orig/arch/i386/mm/init.c
+++ linux/arch/i386/mm/init.c
@@ -798,12 +798,16 @@ void mark_rodata_ro(void)
{
unsigned long start = PFN_ALIGN(_text);
unsigned long size = PFN_ALIGN(_etext) - start;
+ int notext = 0;
+#ifdef CONFIG_KPROBES
+ notext = 1;
+#endif
#ifdef CONFIG_HOTPLUG_CPU
/* It must still be possible to apply SMP alternatives. */
- if (num_possible_cpus() <= 1)
+ notext = (num_possible_cpus() > 1);
#endif
- {
+ if (!notext) {
change_page_attr(virt_to_page(start),
size >> PAGE_SHIFT, PAGE_KERNEL_RX);
printk("Write protecting the kernel text: %luk\n", size >> 10);
-
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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, Jun 20, 2007 at 10:23:21PM -0700, Arjan van de Ven wrote:
> On Wed, 2007-06-20 at 16:50 -0700, Linus Torvalds wrote:
> >
> > On Wed, 20 Jun 2007, Arjan van de Ven wrote:
> > >
> > > the real fix would be something like this instead:
> >
> > If people can test this, and confirm it works, please send a patch that
> > not only does this ad undoes the Kconfig language. It looks like the
> > right thing to do, but I won't touch it without somebody who actually
> > tested these combinarions sending in a patch.
>
> Hi,
>
> I have tested this on x86_64, and without the config language, the
> original oopses, while with the patch below it works fine (as expected).
> I've not been able to test the i386 one (no 32 bit testboxes since 2
> years) but the change is even simpler there, just an ifdef around the
> entire kernel text marking.
I tested this patch on i386 box, it seems to work fine.
Thanks
Prasanna
>
>
>
> Do not mark the kernel text read only if KPROBES is in the kernel;
> kprobes needs to hot-patch the kernel text to insert it's
> instrumentation. In this case, only mark the .rodata segment as read
> only.
>
> Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
>
> --- linux-2.6.22-rc5/arch/i386/Kconfig.debug.org 2007-06-20
> 22:20:30.0 -0700
> +++ linux-2.6.22-rc5/arch/i386/Kconfig.debug 2007-06-20 22:20:55.0
> -0700
> @@ -49,7 +49,6 @@ config DEBUG_PAGEALLOC
> config DEBUG_RODATA
> bool "Write protect kernel read-only data structures"
> depends on DEBUG_KERNEL
> - depends on !KPROBES # temporary for 2.6.22
> help
> Mark the kernel read-only data as write-protected in the pagetables,
> in order to catch accidental (and incorrect) writes to such const
> --- linux-2.6.22-rc5/arch/x86_64/Kconfig.debug.org2007-06-20
> 22:20:28.0 -0700
> +++ linux-2.6.22-rc5/arch/x86_64/Kconfig.debug2007-06-20
> 22:20:44.0 -0700
> @@ -9,7 +9,6 @@ source "lib/Kconfig.debug"
> config DEBUG_RODATA
> bool "Write protect kernel read-only data structures"
> depends on DEBUG_KERNEL
> - depends on !KPROBES # temporary for 2.6.22
> help
>Mark the kernel read-only data as write-protected in the pagetables,
>in order to catch accidental (and incorrect) writes to such const data.
> --- linux-2.6.22-rc5/arch/i386/mm/init.c.org 2007-06-20 22:18:40.0
> -0700
> +++ linux-2.6.22-rc5/arch/i386/mm/init.c 2007-06-20 22:19:45.0
> -0700
> @@ -799,6 +799,7 @@ void mark_rodata_ro(void)
> unsigned long start = PFN_ALIGN(_text);
> unsigned long size = PFN_ALIGN(_etext) - start;
>
> +#ifndef CONFIG_KPROBES
> #ifdef CONFIG_HOTPLUG_CPU
> /* It must still be possible to apply SMP alternatives. */
> if (num_possible_cpus() <= 1)
> @@ -808,7 +809,7 @@ void mark_rodata_ro(void)
>size >> PAGE_SHIFT, PAGE_KERNEL_RX);
> printk("Write protecting the kernel text: %luk\n", size >> 10);
> }
> -
> +#endif
> start += size;
> size = (unsigned long)__end_rodata - start;
> change_page_attr(virt_to_page(start),
> --- linux-2.6.22-rc5/arch/x86_64/mm/init.c.org2007-06-20
> 21:44:15.0 -0700
> +++ linux-2.6.22-rc5/arch/x86_64/mm/init.c2007-06-20 22:17:45.0
> -0700
> @@ -605,6 +605,11 @@ void mark_rodata_ro(void)
> if (num_possible_cpus() > 1)
> start = (unsigned long)_etext;
> #endif
> +
> +#ifdef CONFIG_KPROBES
> + start = (unsigned long)__start_rodata;
> +#endif
> +
> end = (unsigned long)__end_rodata;
> start = (start + PAGE_SIZE - 1) & PAGE_MASK;
> end &= PAGE_MASK;
>
> --
> if you want to mail me at work (you don't), use arjan (at) linux.intel.com
> Test the interaction between Linux and your BIOS via
> http://www.linuxfirmwarekit.org
--
Thanks & Regards
Prasanna S.P.
Linux Technology Center
India Software Labs, IBM Bangalore
Email: [EMAIL PROTECTED]
Ph: 91-80-41776329
-
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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, Jun 20, 2007 at 10:23:21PM -0700, Arjan van de Ven wrote: On Wed, 2007-06-20 at 16:50 -0700, Linus Torvalds wrote: On Wed, 20 Jun 2007, Arjan van de Ven wrote: the real fix would be something like this instead: If people can test this, and confirm it works, please send a patch that not only does this ad undoes the Kconfig language. It looks like the right thing to do, but I won't touch it without somebody who actually tested these combinarions sending in a patch. Hi, I have tested this on x86_64, and without the config language, the original oopses, while with the patch below it works fine (as expected). I've not been able to test the i386 one (no 32 bit testboxes since 2 years) but the change is even simpler there, just an ifdef around the entire kernel text marking. I tested this patch on i386 box, it seems to work fine. Thanks Prasanna Do not mark the kernel text read only if KPROBES is in the kernel; kprobes needs to hot-patch the kernel text to insert it's instrumentation. In this case, only mark the .rodata segment as read only. Signed-off-by: Arjan van de Ven [EMAIL PROTECTED] --- linux-2.6.22-rc5/arch/i386/Kconfig.debug.org 2007-06-20 22:20:30.0 -0700 +++ linux-2.6.22-rc5/arch/i386/Kconfig.debug 2007-06-20 22:20:55.0 -0700 @@ -49,7 +49,6 @@ config DEBUG_PAGEALLOC config DEBUG_RODATA bool Write protect kernel read-only data structures depends on DEBUG_KERNEL - depends on !KPROBES # temporary for 2.6.22 help Mark the kernel read-only data as write-protected in the pagetables, in order to catch accidental (and incorrect) writes to such const --- linux-2.6.22-rc5/arch/x86_64/Kconfig.debug.org2007-06-20 22:20:28.0 -0700 +++ linux-2.6.22-rc5/arch/x86_64/Kconfig.debug2007-06-20 22:20:44.0 -0700 @@ -9,7 +9,6 @@ source lib/Kconfig.debug config DEBUG_RODATA bool Write protect kernel read-only data structures depends on DEBUG_KERNEL - depends on !KPROBES # temporary for 2.6.22 help Mark the kernel read-only data as write-protected in the pagetables, in order to catch accidental (and incorrect) writes to such const data. --- linux-2.6.22-rc5/arch/i386/mm/init.c.org 2007-06-20 22:18:40.0 -0700 +++ linux-2.6.22-rc5/arch/i386/mm/init.c 2007-06-20 22:19:45.0 -0700 @@ -799,6 +799,7 @@ void mark_rodata_ro(void) unsigned long start = PFN_ALIGN(_text); unsigned long size = PFN_ALIGN(_etext) - start; +#ifndef CONFIG_KPROBES #ifdef CONFIG_HOTPLUG_CPU /* It must still be possible to apply SMP alternatives. */ if (num_possible_cpus() = 1) @@ -808,7 +809,7 @@ void mark_rodata_ro(void) size PAGE_SHIFT, PAGE_KERNEL_RX); printk(Write protecting the kernel text: %luk\n, size 10); } - +#endif start += size; size = (unsigned long)__end_rodata - start; change_page_attr(virt_to_page(start), --- linux-2.6.22-rc5/arch/x86_64/mm/init.c.org2007-06-20 21:44:15.0 -0700 +++ linux-2.6.22-rc5/arch/x86_64/mm/init.c2007-06-20 22:17:45.0 -0700 @@ -605,6 +605,11 @@ void mark_rodata_ro(void) if (num_possible_cpus() 1) start = (unsigned long)_etext; #endif + +#ifdef CONFIG_KPROBES + start = (unsigned long)__start_rodata; +#endif + end = (unsigned long)__end_rodata; start = (start + PAGE_SIZE - 1) PAGE_MASK; end = PAGE_MASK; -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org -- Thanks Regards Prasanna S.P. Linux Technology Center India Software Labs, IBM Bangalore Email: [EMAIL PROTECTED] Ph: 91-80-41776329 - 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] Alternative fix for kprobesDEBUG_RODATA was Re: [1/2] 2.6.22-rc5: known regressions with patches
On Thursday 21 June 2007 01:48:43 Linus Torvalds wrote:
On Wed, 20 Jun 2007, Dave Jones wrote:
Surely the fundamental disagreement is only due to DEBUG_RODATA
covering write-protection of both .text, and .rodata ?
I agree that we could well split DEBUG_RODATA into something more
fine-grained, and for example have it _only_ protect that .rodata thing
when Kprobes are enabled, and both .text _and_ .rodata when Kprobes are
not.
That would make lots of sense.
Ok, here's a patch to do this. With that
55181000cd60334fe920c65ffbcdfe0e3f1de406
should be reverted because it isn't needed anymore.
I still think in .23 it should be fixed properly, by either using c_p_a()
as needed in the kprobes/alternatives code (Prasanna already had a patch)
or perhaps better just doing a temporal ioremap() there.
-Andi
---
Disable kernel text protection when kprobes are enabled
To be done better in .23
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux/arch/x86_64/mm/init.c
===
--- linux.orig/arch/x86_64/mm/init.c
+++ linux/arch/x86_64/mm/init.c
@@ -600,6 +600,10 @@ void mark_rodata_ro(void)
{
unsigned long start = (unsigned long)_stext, end;
+#ifdef CONFIG_KPROBES
+ /* Kprobes code doesn't know yet how to unprotect. Temporary fix. */
+ start = (unsigned long)_etext;
+#endif
#ifdef CONFIG_HOTPLUG_CPU
/* It must still be possible to apply SMP alternatives. */
if (num_possible_cpus() 1)
Index: linux/arch/i386/mm/init.c
===
--- linux.orig/arch/i386/mm/init.c
+++ linux/arch/i386/mm/init.c
@@ -798,12 +798,16 @@ void mark_rodata_ro(void)
{
unsigned long start = PFN_ALIGN(_text);
unsigned long size = PFN_ALIGN(_etext) - start;
+ int notext = 0;
+#ifdef CONFIG_KPROBES
+ notext = 1;
+#endif
#ifdef CONFIG_HOTPLUG_CPU
/* It must still be possible to apply SMP alternatives. */
- if (num_possible_cpus() = 1)
+ notext = (num_possible_cpus() 1);
#endif
- {
+ if (!notext) {
change_page_attr(virt_to_page(start),
size PAGE_SHIFT, PAGE_KERNEL_RX);
printk(Write protecting the kernel text: %luk\n, size 10);
-
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: [1/2] 2.6.22-rc5: known regressions with patches
Arjan van de Ven wrote: --- linux-2.6.22-rc5/arch/i386/Kconfig.debug.org 2007-06-20 22:20:30.0 -0700 +++ linux-2.6.22-rc5/arch/i386/Kconfig.debug 2007-06-20 22:20:55.0 -0700 @@ -49,7 +49,6 @@ config DEBUG_PAGEALLOC config DEBUG_RODATA bool Write protect kernel read-only data structures depends on DEBUG_KERNEL - depends on !KPROBES # temporary for 2.6.22 help Mark the kernel read-only data as write-protected in the pagetables, in order to catch accidental (and incorrect) writes to such const --- linux-2.6.22-rc5/arch/x86_64/Kconfig.debug.org2007-06-20 22:20:28.0 -0700 +++ linux-2.6.22-rc5/arch/x86_64/Kconfig.debug2007-06-20 22:20:44.0 -0700 @@ -9,7 +9,6 @@ source lib/Kconfig.debug config DEBUG_RODATA bool Write protect kernel read-only data structures depends on DEBUG_KERNEL - depends on !KPROBES # temporary for 2.6.22 help Mark the kernel read-only data as write-protected in the pagetables, in order to catch accidental (and incorrect) writes to such const data. Shouldn't we add something to the help texts? + This option also marks kernel text pages as write-protected, + except if you enable KPROBES. CMIIW. As mentioned elsewhere in this thread, replacing CONFIG_DEBUG_RODATA by CONFIG_WRITEPROTECT_RODATA and CONFIG_WRITEPROTECT_TEXT might be a better idea. The latter should be mutual exclusive with CONFIG_KPROBES. -- Stefan Richter -=-=-=== -==- =-=-= http://arcgraph.de/sr/ - 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: [1/2] 2.6.22-rc5: known regressions with patches
Shouldn't we add something to the help texts? + This option also marks kernel text pages as write-protected, + except if you enable KPROBES. CMIIW. As mentioned elsewhere in this thread, replacing CONFIG_DEBUG_RODATA by CONFIG_WRITEPROTECT_RODATA and CONFIG_WRITEPROTECT_TEXT might be a better idea. The latter should be mutual exclusive with CONFIG_KPROBES. lets do the minimal now for 2.6.22, and do it right for .23 please -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 06/20/2007 07:04 PM, Linus Torvalds wrote: As far as I know, the biggest reason to use DEBUG_RODATA is (a) Hey, it's a cheap way to check one thing (b) An added layer of security (which it's not that great for, but it might make sense to make it more of a real security feature). And as a security feature it's pretty useless if kprobes are allowed. - 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] Alternative fix for kprobesDEBUG_RODATA was Re: [1/2] 2.6.22-rc5: known regressions with patches
On Thu, 21 Jun 2007, Andi Kleen wrote: Ok, here's a patch to do this. With that 55181000cd60334fe920c65ffbcdfe0e3f1de406 should be reverted because it isn't needed anymore. This seems buggy: + int notext = 0; +#ifdef CONFIG_KPROBES + notext = 1; +#endif #ifdef CONFIG_HOTPLUG_CPU /* It must still be possible to apply SMP alternatives. */ - if (num_possible_cpus() = 1) + notext = (num_possible_cpus() 1); #endif The CONFIG_HOTPLUG_CPU case will overwrite the CONFIG_KPROBES, and turn it back to zero for a single CPU. Linus - 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/
[1/2] 2.6.22-rc5: known regressions with patches v2
Hi all, Here is a list of some known regressions in 2.6.22-rc5 with patches available. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions (BTW. There is a new category called Will be fixed in 2.6.23) Unclassified Subject: Device hang when offlining a CPU due to IRQ misrouting References : http://lkml.org/lkml/2007/5/31/419 Submitter : Darrick J. Wong [EMAIL PROTECTED] Handled-By : Siddha, Suresh B [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/19/422 Status : patch available Subject: long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/16/81 Status : patch was suggested FBDEV Subject: mach64 breakage in 2.6.22 References : http://lkml.org/lkml/2007/6/14/73 Submitter : Olaf Hering [EMAIL PROTECTED] Handled-By : Ville Syrjälä [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/14/273 Status : patch was suggested HWMON Subject: latest coretemp changes break s2ram References : http://lkml.org/lkml/2007/6/16/173 Submitter : Soeren Sonnenburg [EMAIL PROTECTED] Caused-By : Rudolf Marek [EMAIL PROTECTED] commit 67f363b1f6a31cf5027a97372f64bcced4f05ba6 Handled-By : Jean Delvare [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/16/177 Status : patch available Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
On Thu, 21 Jun 2007, Michal Piotrowski wrote: Subject: long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/16/81 Status : patch was suggested This one is fixed, and tested by Miklos. It's commit fa490cfd15: Fix possible runqueue lock starvation in wait_task_inactive(). Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches v2
Linus Torvalds pisze: On Thu, 21 Jun 2007, Michal Piotrowski wrote: Subject: long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/16/81 Status : patch was suggested This one is fixed, and tested by Miklos. It's commit fa490cfd15: Fix possible runqueue lock starvation in wait_task_inactive(). Thanks for the information. BTW. Björn noticed that I accidentally removed this regression. Subject: OProfile issues References : http://lkml.org/lkml/2007/6/12/207 Submitter : Stephane Eranian [EMAIL PROTECTED] Handled-By : Björn Steinbrink [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/12/392 Status : patch was suggested Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 2007-06-20 at 16:50 -0700, Linus Torvalds wrote:
>
> On Wed, 20 Jun 2007, Arjan van de Ven wrote:
> >
> > the real fix would be something like this instead:
>
> If people can test this, and confirm it works, please send a patch that
> not only does this ad undoes the Kconfig language. It looks like the
> right thing to do, but I won't touch it without somebody who actually
> tested these combinarions sending in a patch.
Hi,
I have tested this on x86_64, and without the config language, the
original oopses, while with the patch below it works fine (as expected).
I've not been able to test the i386 one (no 32 bit testboxes since 2
years) but the change is even simpler there, just an ifdef around the
entire kernel text marking.
Do not mark the kernel text read only if KPROBES is in the kernel;
kprobes needs to hot-patch the kernel text to insert it's
instrumentation. In this case, only mark the .rodata segment as read
only.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
--- linux-2.6.22-rc5/arch/i386/Kconfig.debug.org2007-06-20
22:20:30.0 -0700
+++ linux-2.6.22-rc5/arch/i386/Kconfig.debug2007-06-20 22:20:55.0
-0700
@@ -49,7 +49,6 @@ config DEBUG_PAGEALLOC
config DEBUG_RODATA
bool "Write protect kernel read-only data structures"
depends on DEBUG_KERNEL
- depends on !KPROBES # temporary for 2.6.22
help
Mark the kernel read-only data as write-protected in the pagetables,
in order to catch accidental (and incorrect) writes to such const
--- linux-2.6.22-rc5/arch/x86_64/Kconfig.debug.org 2007-06-20
22:20:28.0 -0700
+++ linux-2.6.22-rc5/arch/x86_64/Kconfig.debug 2007-06-20 22:20:44.0
-0700
@@ -9,7 +9,6 @@ source "lib/Kconfig.debug"
config DEBUG_RODATA
bool "Write protect kernel read-only data structures"
depends on DEBUG_KERNEL
- depends on !KPROBES # temporary for 2.6.22
help
Mark the kernel read-only data as write-protected in the pagetables,
in order to catch accidental (and incorrect) writes to such const data.
--- linux-2.6.22-rc5/arch/i386/mm/init.c.org2007-06-20 22:18:40.0
-0700
+++ linux-2.6.22-rc5/arch/i386/mm/init.c2007-06-20 22:19:45.0
-0700
@@ -799,6 +799,7 @@ void mark_rodata_ro(void)
unsigned long start = PFN_ALIGN(_text);
unsigned long size = PFN_ALIGN(_etext) - start;
+#ifndef CONFIG_KPROBES
#ifdef CONFIG_HOTPLUG_CPU
/* It must still be possible to apply SMP alternatives. */
if (num_possible_cpus() <= 1)
@@ -808,7 +809,7 @@ void mark_rodata_ro(void)
size >> PAGE_SHIFT, PAGE_KERNEL_RX);
printk("Write protecting the kernel text: %luk\n", size >> 10);
}
-
+#endif
start += size;
size = (unsigned long)__end_rodata - start;
change_page_attr(virt_to_page(start),
--- linux-2.6.22-rc5/arch/x86_64/mm/init.c.org 2007-06-20 21:44:15.0
-0700
+++ linux-2.6.22-rc5/arch/x86_64/mm/init.c 2007-06-20 22:17:45.0
-0700
@@ -605,6 +605,11 @@ void mark_rodata_ro(void)
if (num_possible_cpus() > 1)
start = (unsigned long)_etext;
#endif
+
+#ifdef CONFIG_KPROBES
+ start = (unsigned long)__start_rodata;
+#endif
+
end = (unsigned long)__end_rodata;
start = (start + PAGE_SIZE - 1) & PAGE_MASK;
end &= PAGE_MASK;
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via
http://www.linuxfirmwarekit.org
-
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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 20 Jun 2007, Arjan van de Ven wrote: > > the real fix would be something like this instead: If people can test this, and confirm it works, please send a patch that not only does this ad undoes the Kconfig language. It looks like the right thing to do, but I won't touch it without somebody who actually tested these combinarions sending in a patch. Hmm? Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 20 Jun 2007, Dave Jones wrote: > > Surely the fundamental disagreement is only due to DEBUG_RODATA > covering write-protection of both .text, and .rodata ? I agree that we could well split DEBUG_RODATA into something more fine-grained, and for example have it _only_ protect that .rodata thing when Kprobes are enabled, and both .text _and_ .rodata when Kprobes are not. That would make lots of sense. Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, Jun 20, 2007 at 04:15:53PM -0700, Arjan van de Ven wrote: > On Wed, 2007-06-20 at 19:07 -0400, Dave Jones wrote: > > On Wed, Jun 20, 2007 at 03:38:06PM -0700, Linus Torvalds wrote: > > > > > And yes, that patch already got merged. However, the patch to *allow* > > > Kprobes with DEBUG_RODATA is not, and will not be. It's not a > > regression, > > > and quite frankly, I don't think I would even want that patch. > > > > > > Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in > > > "working around it". Better just admit it. > > > > Surely the fundamental disagreement is only due to DEBUG_RODATA > > covering write-protection of both .text, and .rodata ? > > I can see value in having a kernel that supports kprobes, whilst > > at the same point, raising red flags if something writes into > > a const string. With my distro kernel maintainer hat on, I always > > hate these 'pick one' decisions, because I always get convincing > > arguments from proponents of both sides. > > > > Was it always this way? I thought DEBUG_RODATA initially just > > covered, well.. rodata.And kprobes only wants to change .text > > doesn't it ? > > no this got "fixed" recently. It used to only cover data. > Andi merged a patch to make it cover text too.. imo we should reverse > that, or make the check better and not have it cover text if kprobes is > active. I can do the later if people are ok with that, it's > approximately 3 lines of code. Having the text as a separate option makes sense to me. (Or at the least we should rename DEBUG_RODATA, as it's now misleading). Dave -- http://www.codemonkey.org.uk - 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: [1/2] 2.6.22-rc5: known regressions with patches
> Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in > "working around it". Better just admit it. that's wrong. KPROBE fundamentally disagrees with TEXT being read only, which is a 2.6.22 new "feature".. and a buggy one at that. the real fix would be something like this instead: --- linux-2.6.22-rc5/arch/x86_64/mm/init.c.org 2007-06-21 04:20:10.0 -0700 +++ linux-2.6.22-rc5/arch/x86_64/mm/init.c 2007-06-21 04:21:01.0 -0700 @@ -605,6 +605,11 @@ void mark_rodata_ro(void) if (num_possible_cpus() > 1) start = (unsigned long)_etext; #endif + +#ifdef CONFIG_KPROBES + start = (unsigned long)_etext; +#endif + end = (unsigned long)__end_rodata; start = (start + PAGE_SIZE - 1) & PAGE_MASK; end &= PAGE_MASK; - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 2007-06-20 at 19:07 -0400, Dave Jones wrote: > On Wed, Jun 20, 2007 at 03:38:06PM -0700, Linus Torvalds wrote: > > > And yes, that patch already got merged. However, the patch to *allow* > > Kprobes with DEBUG_RODATA is not, and will not be. It's not a regression, > > and quite frankly, I don't think I would even want that patch. > > > > Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in > > "working around it". Better just admit it. > > Surely the fundamental disagreement is only due to DEBUG_RODATA > covering write-protection of both .text, and .rodata ? > I can see value in having a kernel that supports kprobes, whilst > at the same point, raising red flags if something writes into > a const string. With my distro kernel maintainer hat on, I always > hate these 'pick one' decisions, because I always get convincing > arguments from proponents of both sides. > > Was it always this way? I thought DEBUG_RODATA initially just > covered, well.. rodata.And kprobes only wants to change .text > doesn't it ? no this got "fixed" recently. It used to only cover data. Andi merged a patch to make it cover text too.. imo we should reverse that, or make the check better and not have it cover text if kprobes is active. I can do the later if people are ok with that, it's approximately 3 lines of code. - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, Jun 20, 2007 at 03:38:06PM -0700, Linus Torvalds wrote: > And yes, that patch already got merged. However, the patch to *allow* > Kprobes with DEBUG_RODATA is not, and will not be. It's not a regression, > and quite frankly, I don't think I would even want that patch. > > Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in > "working around it". Better just admit it. Surely the fundamental disagreement is only due to DEBUG_RODATA covering write-protection of both .text, and .rodata ? I can see value in having a kernel that supports kprobes, whilst at the same point, raising red flags if something writes into a const string. With my distro kernel maintainer hat on, I always hate these 'pick one' decisions, because I always get convincing arguments from proponents of both sides. Was it always this way? I thought DEBUG_RODATA initially just covered, well.. rodata.And kprobes only wants to change .text doesn't it ? Dave -- http://www.codemonkey.org.uk - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 20 Jun 2007, Linus Torvalds wrote: > > There's just no *point*. Put another way: we lived without DEBUG_RODATA for fifteen years, why should we now start adding complexity to work around code that doesn't accept the (fairly small) debugging it gives? Has anybody actually found a bug using it? As far as I know, the biggest reason to use DEBUG_RODATA is (a) Hey, it's a cheap way to check one thing (b) An added layer of security (which it's not that great for, but it might make sense to make it more of a real security feature). and neither of them really seems to say "let's add more code to other pieces of the kernel to work around it" to me. Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 6/21/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: And yes, sometimes debugging *does* change what it debugs. In timing, if nothing else, but also in the kinds of things you can do. Totally agree. For example, we don't allow slab redzoning on data structures that have alignment restrictions not compatible with the redzoning, and I'd argue that this is more of the same: we just should not do DEBUG_RODATA if you expect to change read-only data. Well the description for DEBUG_RODATA is: Mark the kernel read-only data as write-protected in the pagetables, in order to catch accidental (and incorrect) writes to such const data. What we are doing with kprobes is neither accidental, nor incorrect. There's just no *point*. Linus I understand your philosophical viewpoint here. Anyway it's no biggie as can keep the patch out of tree if I want it... Another option is to be able to enable and disable protecting read only data via a sysctl but that seems even uglier. Anyway I'll stop wasting your time now. Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Thu, 21 Jun 2007, Ian McDonald wrote: > > It depends on the purpose of DEBUG_RODATA. If DEBUG_RODATA was for > security reasons then I agree, but it seems to be more to catch > accidental writes. Well, I'd say that it is *one* tool for debugging. Now, Kprobes is another tool - and I'm just saying that I don't see why you should really expect to break one tool with the other. They take different approaches. And yes, sometimes debugging *does* change what it debugs. In timing, if nothing else, but also in the kinds of things you can do. For example, we don't allow slab redzoning on data structures that have alignment restrictions not compatible with the redzoning, and I'd argue that this is more of the same: we just should not do DEBUG_RODATA if you expect to change read-only data. There's just no *point*. Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 20 Jun 2007, Chuck Ebbert wrote: > > Patch was just merged: Well, that was the patch to make the conflict explicit, and just not allowing DEBUG_RODATA with KPROBES. (And it has a "temporary" marker, which I actually think is wrong). Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 6/21/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: Well, for 2.6.22, Kprobes will just be disabled if you use DEBUG_RODATA. And yes, that patch already got merged. However, the patch to *allow* Kprobes with DEBUG_RODATA is not, and will not be. It's not a regression, and quite frankly, I don't think I would even want that patch. Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in "working around it". Better just admit it. Linus It depends on the purpose of DEBUG_RODATA. If DEBUG_RODATA was for security reasons then I agree, but it seems to be more to catch accidental writes. Kprobes isn't an accidental write and I would suspect many developers would want to catch accidental writes and be able to insert kprobes. Or is there something else I'm missing - i.e. you're saying the patch itself is crap? Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 6/21/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote: >> Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on >> 2.6.22-rc2 >> References : http://lkml.org/lkml/2007/5/23/202 >> Submitter : William Cohen <[EMAIL PROTECTED]> >> Ian McDonald <[EMAIL PROTECTED]> >> Handled-By : S. P. Prasanna <[EMAIL PROTECTED]> >> Patch : http://lkml.org/lkml/2007/6/7/2 >> Status : patch available Patch was just merged: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55181000cd60334fe920c65ffbcdfe0e3f1de406 I see that just makes KPROBES and DEBUG_RODATA mutually exclusive which makes sense for 2.6.22 Michal - don't kill this one so we have the full fix in 2.6.23 Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Thu, 21 Jun 2007, Ian McDonald wrote: > > Can this one be merged so that it makes it into 2.6.22? > > > > > Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on 2.6.22-rc2 > > References : http://lkml.org/lkml/2007/5/23/202 > > Submitter : William Cohen <[EMAIL PROTECTED]> > > Ian McDonald <[EMAIL PROTECTED]> > > Handled-By : S. P. Prasanna <[EMAIL PROTECTED]> > > Patch : http://lkml.org/lkml/2007/6/7/2 > > Status : patch available > > > > Regards, Well, for 2.6.22, Kprobes will just be disabled if you use DEBUG_RODATA. And yes, that patch already got merged. However, the patch to *allow* Kprobes with DEBUG_RODATA is not, and will not be. It's not a regression, and quite frankly, I don't think I would even want that patch. Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in "working around it". Better just admit it. Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 06/20/2007 06:08 PM, Ian McDonald wrote: > Andrew, > > Can this one be merged so that it makes it into 2.6.22? > >> >> Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on >> 2.6.22-rc2 >> References : http://lkml.org/lkml/2007/5/23/202 >> Submitter : William Cohen <[EMAIL PROTECTED]> >> Ian McDonald <[EMAIL PROTECTED]> >> Handled-By : S. P. Prasanna <[EMAIL PROTECTED]> >> Patch : http://lkml.org/lkml/2007/6/7/2 >> Status : patch available Patch was just merged: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55181000cd60334fe920c65ffbcdfe0e3f1de406 - 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: [1/2] 2.6.22-rc5: known regressions with patches
Andrew, Can this one be merged so that it makes it into 2.6.22? Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on 2.6.22-rc2 References : http://lkml.org/lkml/2007/5/23/202 Submitter : William Cohen <[EMAIL PROTECTED]> Ian McDonald <[EMAIL PROTECTED]> Handled-By : S. P. Prasanna <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/7/2 Status : patch available Regards, Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - 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: [1/2] 2.6.22-rc5: known regressions with patches
Andrew, Can this one be merged so that it makes it into 2.6.22? Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on 2.6.22-rc2 References : http://lkml.org/lkml/2007/5/23/202 Submitter : William Cohen [EMAIL PROTECTED] Ian McDonald [EMAIL PROTECTED] Handled-By : S. P. Prasanna [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/7/2 Status : patch available Regards, Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 06/20/2007 06:08 PM, Ian McDonald wrote: Andrew, Can this one be merged so that it makes it into 2.6.22? Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on 2.6.22-rc2 References : http://lkml.org/lkml/2007/5/23/202 Submitter : William Cohen [EMAIL PROTECTED] Ian McDonald [EMAIL PROTECTED] Handled-By : S. P. Prasanna [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/7/2 Status : patch available Patch was just merged: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55181000cd60334fe920c65ffbcdfe0e3f1de406 - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 6/21/07, Chuck Ebbert [EMAIL PROTECTED] wrote: Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on 2.6.22-rc2 References : http://lkml.org/lkml/2007/5/23/202 Submitter : William Cohen [EMAIL PROTECTED] Ian McDonald [EMAIL PROTECTED] Handled-By : S. P. Prasanna [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/7/2 Status : patch available Patch was just merged: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55181000cd60334fe920c65ffbcdfe0e3f1de406 I see that just makes KPROBES and DEBUG_RODATA mutually exclusive which makes sense for 2.6.22 Michal - don't kill this one so we have the full fix in 2.6.23 Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Thu, 21 Jun 2007, Ian McDonald wrote: Can this one be merged so that it makes it into 2.6.22? Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on 2.6.22-rc2 References : http://lkml.org/lkml/2007/5/23/202 Submitter : William Cohen [EMAIL PROTECTED] Ian McDonald [EMAIL PROTECTED] Handled-By : S. P. Prasanna [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/7/2 Status : patch available Regards, Well, for 2.6.22, Kprobes will just be disabled if you use DEBUG_RODATA. And yes, that patch already got merged. However, the patch to *allow* Kprobes with DEBUG_RODATA is not, and will not be. It's not a regression, and quite frankly, I don't think I would even want that patch. Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in working around it. Better just admit it. Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 6/21/07, Linus Torvalds [EMAIL PROTECTED] wrote: Well, for 2.6.22, Kprobes will just be disabled if you use DEBUG_RODATA. And yes, that patch already got merged. However, the patch to *allow* Kprobes with DEBUG_RODATA is not, and will not be. It's not a regression, and quite frankly, I don't think I would even want that patch. Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in working around it. Better just admit it. Linus It depends on the purpose of DEBUG_RODATA. If DEBUG_RODATA was for security reasons then I agree, but it seems to be more to catch accidental writes. Kprobes isn't an accidental write and I would suspect many developers would want to catch accidental writes and be able to insert kprobes. Or is there something else I'm missing - i.e. you're saying the patch itself is crap? Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 20 Jun 2007, Chuck Ebbert wrote: Patch was just merged: Well, that was the patch to make the conflict explicit, and just not allowing DEBUG_RODATA with KPROBES. (And it has a temporary marker, which I actually think is wrong). Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Thu, 21 Jun 2007, Ian McDonald wrote: It depends on the purpose of DEBUG_RODATA. If DEBUG_RODATA was for security reasons then I agree, but it seems to be more to catch accidental writes. Well, I'd say that it is *one* tool for debugging. Now, Kprobes is another tool - and I'm just saying that I don't see why you should really expect to break one tool with the other. They take different approaches. And yes, sometimes debugging *does* change what it debugs. In timing, if nothing else, but also in the kinds of things you can do. For example, we don't allow slab redzoning on data structures that have alignment restrictions not compatible with the redzoning, and I'd argue that this is more of the same: we just should not do DEBUG_RODATA if you expect to change read-only data. There's just no *point*. Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 6/21/07, Linus Torvalds [EMAIL PROTECTED] wrote: And yes, sometimes debugging *does* change what it debugs. In timing, if nothing else, but also in the kinds of things you can do. Totally agree. For example, we don't allow slab redzoning on data structures that have alignment restrictions not compatible with the redzoning, and I'd argue that this is more of the same: we just should not do DEBUG_RODATA if you expect to change read-only data. Well the description for DEBUG_RODATA is: Mark the kernel read-only data as write-protected in the pagetables, in order to catch accidental (and incorrect) writes to such const data. What we are doing with kprobes is neither accidental, nor incorrect. There's just no *point*. Linus I understand your philosophical viewpoint here. Anyway it's no biggie as can keep the patch out of tree if I want it... Another option is to be able to enable and disable protecting read only data via a sysctl but that seems even uglier. Anyway I'll stop wasting your time now. Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 20 Jun 2007, Linus Torvalds wrote: There's just no *point*. Put another way: we lived without DEBUG_RODATA for fifteen years, why should we now start adding complexity to work around code that doesn't accept the (fairly small) debugging it gives? Has anybody actually found a bug using it? As far as I know, the biggest reason to use DEBUG_RODATA is (a) Hey, it's a cheap way to check one thing (b) An added layer of security (which it's not that great for, but it might make sense to make it more of a real security feature). and neither of them really seems to say let's add more code to other pieces of the kernel to work around it to me. Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, Jun 20, 2007 at 03:38:06PM -0700, Linus Torvalds wrote: And yes, that patch already got merged. However, the patch to *allow* Kprobes with DEBUG_RODATA is not, and will not be. It's not a regression, and quite frankly, I don't think I would even want that patch. Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in working around it. Better just admit it. Surely the fundamental disagreement is only due to DEBUG_RODATA covering write-protection of both .text, and .rodata ? I can see value in having a kernel that supports kprobes, whilst at the same point, raising red flags if something writes into a const string. With my distro kernel maintainer hat on, I always hate these 'pick one' decisions, because I always get convincing arguments from proponents of both sides. Was it always this way? I thought DEBUG_RODATA initially just covered, well.. rodata.And kprobes only wants to change .text doesn't it ? Dave -- http://www.codemonkey.org.uk - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 2007-06-20 at 19:07 -0400, Dave Jones wrote: On Wed, Jun 20, 2007 at 03:38:06PM -0700, Linus Torvalds wrote: And yes, that patch already got merged. However, the patch to *allow* Kprobes with DEBUG_RODATA is not, and will not be. It's not a regression, and quite frankly, I don't think I would even want that patch. Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in working around it. Better just admit it. Surely the fundamental disagreement is only due to DEBUG_RODATA covering write-protection of both .text, and .rodata ? I can see value in having a kernel that supports kprobes, whilst at the same point, raising red flags if something writes into a const string. With my distro kernel maintainer hat on, I always hate these 'pick one' decisions, because I always get convincing arguments from proponents of both sides. Was it always this way? I thought DEBUG_RODATA initially just covered, well.. rodata.And kprobes only wants to change .text doesn't it ? no this got fixed recently. It used to only cover data. Andi merged a patch to make it cover text too.. imo we should reverse that, or make the check better and not have it cover text if kprobes is active. I can do the later if people are ok with that, it's approximately 3 lines of code. - 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: [1/2] 2.6.22-rc5: known regressions with patches
Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in working around it. Better just admit it. that's wrong. KPROBE fundamentally disagrees with TEXT being read only, which is a 2.6.22 new feature.. and a buggy one at that. the real fix would be something like this instead: --- linux-2.6.22-rc5/arch/x86_64/mm/init.c.org 2007-06-21 04:20:10.0 -0700 +++ linux-2.6.22-rc5/arch/x86_64/mm/init.c 2007-06-21 04:21:01.0 -0700 @@ -605,6 +605,11 @@ void mark_rodata_ro(void) if (num_possible_cpus() 1) start = (unsigned long)_etext; #endif + +#ifdef CONFIG_KPROBES + start = (unsigned long)_etext; +#endif + end = (unsigned long)__end_rodata; start = (start + PAGE_SIZE - 1) PAGE_MASK; end = PAGE_MASK; - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, Jun 20, 2007 at 04:15:53PM -0700, Arjan van de Ven wrote: On Wed, 2007-06-20 at 19:07 -0400, Dave Jones wrote: On Wed, Jun 20, 2007 at 03:38:06PM -0700, Linus Torvalds wrote: And yes, that patch already got merged. However, the patch to *allow* Kprobes with DEBUG_RODATA is not, and will not be. It's not a regression, and quite frankly, I don't think I would even want that patch. Kprobes fundamntally disagrees with DEBUG_RODATA, there's no point in working around it. Better just admit it. Surely the fundamental disagreement is only due to DEBUG_RODATA covering write-protection of both .text, and .rodata ? I can see value in having a kernel that supports kprobes, whilst at the same point, raising red flags if something writes into a const string. With my distro kernel maintainer hat on, I always hate these 'pick one' decisions, because I always get convincing arguments from proponents of both sides. Was it always this way? I thought DEBUG_RODATA initially just covered, well.. rodata.And kprobes only wants to change .text doesn't it ? no this got fixed recently. It used to only cover data. Andi merged a patch to make it cover text too.. imo we should reverse that, or make the check better and not have it cover text if kprobes is active. I can do the later if people are ok with that, it's approximately 3 lines of code. Having the text as a separate option makes sense to me. (Or at the least we should rename DEBUG_RODATA, as it's now misleading). Dave -- http://www.codemonkey.org.uk - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 20 Jun 2007, Dave Jones wrote: Surely the fundamental disagreement is only due to DEBUG_RODATA covering write-protection of both .text, and .rodata ? I agree that we could well split DEBUG_RODATA into something more fine-grained, and for example have it _only_ protect that .rodata thing when Kprobes are enabled, and both .text _and_ .rodata when Kprobes are not. That would make lots of sense. Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 20 Jun 2007, Arjan van de Ven wrote: the real fix would be something like this instead: If people can test this, and confirm it works, please send a patch that not only does this ad undoes the Kconfig language. It looks like the right thing to do, but I won't touch it without somebody who actually tested these combinarions sending in a patch. Hmm? Linus - 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: [1/2] 2.6.22-rc5: known regressions with patches
On Wed, 2007-06-20 at 16:50 -0700, Linus Torvalds wrote: On Wed, 20 Jun 2007, Arjan van de Ven wrote: the real fix would be something like this instead: If people can test this, and confirm it works, please send a patch that not only does this ad undoes the Kconfig language. It looks like the right thing to do, but I won't touch it without somebody who actually tested these combinarions sending in a patch. Hi, I have tested this on x86_64, and without the config language, the original oopses, while with the patch below it works fine (as expected). I've not been able to test the i386 one (no 32 bit testboxes since 2 years) but the change is even simpler there, just an ifdef around the entire kernel text marking. Do not mark the kernel text read only if KPROBES is in the kernel; kprobes needs to hot-patch the kernel text to insert it's instrumentation. In this case, only mark the .rodata segment as read only. Signed-off-by: Arjan van de Ven [EMAIL PROTECTED] --- linux-2.6.22-rc5/arch/i386/Kconfig.debug.org2007-06-20 22:20:30.0 -0700 +++ linux-2.6.22-rc5/arch/i386/Kconfig.debug2007-06-20 22:20:55.0 -0700 @@ -49,7 +49,6 @@ config DEBUG_PAGEALLOC config DEBUG_RODATA bool Write protect kernel read-only data structures depends on DEBUG_KERNEL - depends on !KPROBES # temporary for 2.6.22 help Mark the kernel read-only data as write-protected in the pagetables, in order to catch accidental (and incorrect) writes to such const --- linux-2.6.22-rc5/arch/x86_64/Kconfig.debug.org 2007-06-20 22:20:28.0 -0700 +++ linux-2.6.22-rc5/arch/x86_64/Kconfig.debug 2007-06-20 22:20:44.0 -0700 @@ -9,7 +9,6 @@ source lib/Kconfig.debug config DEBUG_RODATA bool Write protect kernel read-only data structures depends on DEBUG_KERNEL - depends on !KPROBES # temporary for 2.6.22 help Mark the kernel read-only data as write-protected in the pagetables, in order to catch accidental (and incorrect) writes to such const data. --- linux-2.6.22-rc5/arch/i386/mm/init.c.org2007-06-20 22:18:40.0 -0700 +++ linux-2.6.22-rc5/arch/i386/mm/init.c2007-06-20 22:19:45.0 -0700 @@ -799,6 +799,7 @@ void mark_rodata_ro(void) unsigned long start = PFN_ALIGN(_text); unsigned long size = PFN_ALIGN(_etext) - start; +#ifndef CONFIG_KPROBES #ifdef CONFIG_HOTPLUG_CPU /* It must still be possible to apply SMP alternatives. */ if (num_possible_cpus() = 1) @@ -808,7 +809,7 @@ void mark_rodata_ro(void) size PAGE_SHIFT, PAGE_KERNEL_RX); printk(Write protecting the kernel text: %luk\n, size 10); } - +#endif start += size; size = (unsigned long)__end_rodata - start; change_page_attr(virt_to_page(start), --- linux-2.6.22-rc5/arch/x86_64/mm/init.c.org 2007-06-20 21:44:15.0 -0700 +++ linux-2.6.22-rc5/arch/x86_64/mm/init.c 2007-06-20 22:17:45.0 -0700 @@ -605,6 +605,11 @@ void mark_rodata_ro(void) if (num_possible_cpus() 1) start = (unsigned long)_etext; #endif + +#ifdef CONFIG_KPROBES + start = (unsigned long)__start_rodata; +#endif + end = (unsigned long)__end_rodata; start = (start + PAGE_SIZE - 1) PAGE_MASK; end = PAGE_MASK; -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 17/06/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: * Michal Piotrowski <[EMAIL PROTECTED]> wrote: > Subject: long freezes on thinkpad t60 > References : http://lkml.org/lkml/2007/5/24/100 > Submitter : Miklos Szeredi <[EMAIL PROTECTED]> > Handled-By : Ingo Molnar <[EMAIL PROTECTED]> > Patch : http://lkml.org/lkml/2007/6/16/81 > Status : patch was suggested i think this isnt a new regression in .22, it existed in .21 too - or are you tracking all 2.6 regressions? Unfortunately I don't have enough time, will and tools to track all 2.6 regressions. Anyway, I'll leave it on the list. We've got a fix :) Ingo Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: [1/2] 2.6.22-rc5: known regressions with patches
* Michal Piotrowski <[EMAIL PROTECTED]> wrote: > Subject: long freezes on thinkpad t60 > References : http://lkml.org/lkml/2007/5/24/100 > Submitter : Miklos Szeredi <[EMAIL PROTECTED]> > Handled-By : Ingo Molnar <[EMAIL PROTECTED]> > Patch : http://lkml.org/lkml/2007/6/16/81 > Status : patch was suggested i think this isnt a new regression in .22, it existed in .21 too - or are you tracking all 2.6 regressions? Ingo - 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/
[1/2] 2.6.22-rc5: known regressions with patches
Hi all, Here is a list of some known regressions in 2.6.22-rc5 with patches available. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Unclassified Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on 2.6.22-rc2 References : http://lkml.org/lkml/2007/5/23/202 Submitter : William Cohen <[EMAIL PROTECTED]> Ian McDonald <[EMAIL PROTECTED]> Handled-By : S. P. Prasanna <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/7/2 Status : patch available Subject: long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi <[EMAIL PROTECTED]> Handled-By : Ingo Molnar <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/16/81 Status : patch was suggested Subject: OProfile issues References : http://lkml.org/lkml/2007/6/12/207 Submitter : Stephane Eranian <[EMAIL PROTECTED]> Handled-By : Björn Steinbrink <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/12/392 Status : patch was suggested FBDEV Subject: mach64 breakage in 2.6.22 References : http://lkml.org/lkml/2007/6/14/73 Submitter : Olaf Hering <[EMAIL PROTECTED]> Handled-By : Ville Syrjälä <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/14/273 Status : patch was suggested HWMON Subject: latest coretemp changes break s2ram References : http://lkml.org/lkml/2007/6/16/173 Submitter : Soeren Sonnenburg <[EMAIL PROTECTED]> Caused-By : Rudolf Marek <[EMAIL PROTECTED]> commit 67f363b1f6a31cf5027a97372f64bcced4f05ba6 Handled-By : Jean Delvare <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/6/16/177 Status : patch available Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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/
[1/2] 2.6.22-rc5: known regressions with patches
Hi all, Here is a list of some known regressions in 2.6.22-rc5 with patches available. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Unclassified Subject: CONFIG_DEBUG_RODATA prevents kprobes from working on 2.6.22-rc2 References : http://lkml.org/lkml/2007/5/23/202 Submitter : William Cohen [EMAIL PROTECTED] Ian McDonald [EMAIL PROTECTED] Handled-By : S. P. Prasanna [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/7/2 Status : patch available Subject: long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/16/81 Status : patch was suggested Subject: OProfile issues References : http://lkml.org/lkml/2007/6/12/207 Submitter : Stephane Eranian [EMAIL PROTECTED] Handled-By : Björn Steinbrink [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/12/392 Status : patch was suggested FBDEV Subject: mach64 breakage in 2.6.22 References : http://lkml.org/lkml/2007/6/14/73 Submitter : Olaf Hering [EMAIL PROTECTED] Handled-By : Ville Syrjälä [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/14/273 Status : patch was suggested HWMON Subject: latest coretemp changes break s2ram References : http://lkml.org/lkml/2007/6/16/173 Submitter : Soeren Sonnenburg [EMAIL PROTECTED] Caused-By : Rudolf Marek [EMAIL PROTECTED] commit 67f363b1f6a31cf5027a97372f64bcced4f05ba6 Handled-By : Jean Delvare [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/16/177 Status : patch available Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: [1/2] 2.6.22-rc5: known regressions with patches
* Michal Piotrowski [EMAIL PROTECTED] wrote: Subject: long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/16/81 Status : patch was suggested i think this isnt a new regression in .22, it existed in .21 too - or are you tracking all 2.6 regressions? Ingo - 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: [1/2] 2.6.22-rc5: known regressions with patches
On 17/06/07, Ingo Molnar [EMAIL PROTECTED] wrote: * Michal Piotrowski [EMAIL PROTECTED] wrote: Subject: long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi [EMAIL PROTECTED] Handled-By : Ingo Molnar [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/16/81 Status : patch was suggested i think this isnt a new regression in .22, it existed in .21 too - or are you tracking all 2.6 regressions? Unfortunately I don't have enough time, will and tools to track all 2.6 regressions. Anyway, I'll leave it on the list. We've got a fix :) Ingo Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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/
