[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.98.0706201550480.3593@woody.linux-foundation.org>
Date: Wed, 20 Jun 2007 15:54:37 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ian McDonald <ian.mcdonald@...di.co.nz>
cc: Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Miklos Szeredi <miklos@...redi.hu>,
Ingo Molnar <mingo@...e.hu>,
"Darrick J. Wong" <djwong@...ibm.com>, Andi Kleen <ak@...e.de>,
Bj?rn Steinbrink <B.Steinbrink@....de>,
William Cohen <wcohen@...hat.com>,
"S. P. Prasanna" <prasanna@...ibm.com>,
Antonino Daplas <adaplas@...il.com>,
Olaf Hering <olaf@...fle.de>, Ville Syrj?l? <syrjala@....fi>,
Jean Delvare <khali@...ux-fr.org>,
Rudolf Marek <r.marek@...embler.cz>,
Soeren Sonnenburg <kernel@....de>,
Michal Piotrowski <michal.k.k.piotrowski@...il.com>
Subject: 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists