memory protection in linux kernels

[Mark]

Hello

I'm debugging my kernel module, which appears to have a memory corruption,
basically a piece of memory allocated by alloc_netdev() for 'net_device'
instance has benn corrupted. I'm wondering if I could apply some "read-only"
attribute on this memory, this way I expect to have Oops generated when
someone tries to modify the memory.

Does it sound reasonable or my ideas are undoable ?
Thanks.

Mark

[Scott Lurndal]

Turn on CONFIG_KDB and use kdb to set a watchpoint on the location being
corrupted. The processor will automatically stop and drop into kdb
when the location is modified.

See the documentation for the bp command in kdb under the Documentation
directory in the kernel source tree.

scott

[Mark]

"Scott Lurndal" <sc...@slp53.sl.home> wrote in message
news:JRTfs.4$Ci...@fe03.iad...

Thank you. The target is ARM-based and runs the kernel 2.6.31.8, which has
only KGDB support, i.e. as I understand it allows to debug via rs232. What
is the difference with KDB?

Also, do I have to enable CONFIG_MAGIC_SYSRQ except CONFIG_KGDB and
CONFIG_DEBUG_INFO (CONFIG_FRAME_POINTER is also recommended) ?

Mark

[Scott Lurndal]

"Mark" <mark_cruz...@hotmail.com> writes:
>
>"Scott Lurndal" <sc...@slp53.sl.home> wrote in message
>news:JRTfs.4$Ci...@fe03.iad...
>>>I'm debugging my kernel module, which appears to have a memory corruption,
>>>basically a piece of memory allocated by alloc_netdev() for 'net_device'
>>>instance has benn corrupted. I'm wondering if I could apply some
>>>"read-only"
>>>attribute on this memory, this way I expect to have Oops generated when
>>>someone tries to modify the memory.
>>>
>>>Does it sound reasonable or my ideas are undoable ?
>>>Thanks.
>>>
>>>Mark
>>>
>>
>> Turn on CONFIG_KDB and use kdb to set a watchpoint on the location being
>> corrupted. The processor will automatically stop and drop into kdb
>> when the location is modified.
>>
>> See the documentation for the bp command in kdb under the Documentation
>> directory in the kernel source tree.
>
>Thank you. The target is ARM-based and runs the kernel 2.6.31.8, which has
>only KGDB support, i.e. as I understand it allows to debug via rs232. What
>is the difference with KDB?

KDB is built in; it doesn't require a client on another machine like KGDB;
but kgdb should work for your case since you've an earlier kernel.

KGDB and KDB both part of the kernel 3.x series, even for ARM as I understand it,
although I've seen recent changes fly by on LKML.

ARM processors also have external debug capabilities in some implementations
(e.g. ETM via jtag).

>
>Also, do I have to enable CONFIG_MAGIC_SYSRQ except CONFIG_KGDB and
>CONFIG_DEBUG_INFO (CONFIG_FRAME_POINTER is also recommended) ?

The Kconfig files should handle any required dependencies for you.

scott

[Rainer Weikusat]

"Mark" <mark_cruz...@hotmail.com> writes:

[...]

> Also, do I have to enable CONFIG_MAGIC_SYSRQ except CONFIG_KGDB and
> CONFIG_DEBUG_INFO (CONFIG_FRAME_POINTER is also recommended) ?

'magic sysreq' is mainly useful when you have some kind of
'interactive console connection' to a computer/ device and it is
necessary to send some kind of 'emergency command' to it after other
ways to interact with the system have ceased to function, eg, try
to write all dirty pages to disk, mount filesystems read-only and do a
'hard' reboot (without a proper shutdown procedure). For embedded,
that's likely not very useful. CONFIG_FRAME_POINTER is very likely a
good idea since this means that the subroutine activation records on
the call stack can be inspected without interpreting the actually
executed machine code.

[Mark]

"Scott Lurndal" <sc...@slp53.sl.home> wrote in message

news:R2Wfs.9$72...@fed11.iad...

>>> Turn on CONFIG_KDB and use kdb to set a watchpoint on the location being
>>> corrupted. The processor will automatically stop and drop into kdb
>>> when the location is modified.
>>>

[skip]

>>Thank you. The target is ARM-based and runs the kernel 2.6.31.8, which has
>>only KGDB support, i.e. as I understand it allows to debug via rs232. What
>>is the difference with KDB?
>
> KDB is built in; it doesn't require a client on another machine like KGDB;
> but kgdb should work for your case since you've an earlier kernel.
>

After googling and reading I've set up kgdb over serial line, I can break
into the debugger (by stopping the kernel via /proc/sysrq-trigger) and
connect from host gdb, which is part of ARM toolchain.

Basically I have development board running embedded linux abd the driver I'm
debugging, and my PC with two connections to the board - serial and ethernet
(telnet session).

After I connect with host gdb to the target, I'm no longer able to do telnet
to the board, because the only way to reproduce the memory corruption is to
apply some configuration with user application on the board.

Is it expected or I'm doing something wrong, and there's a way to have alive
IP connection to the target *and* GDB session?

Mark

[Ian Collins]

On 10/20/12 11:08, Mark wrote:
>
> Basically I have development board running embedded linux abd the driver I'm
> debugging, and my PC with two connections to the board - serial and ethernet
> (telnet session).

Can't you test the driver in a more developer friendly environment (a
simulation on your desktop) before deploying it on your target?

--
Ian Collins

[Scott Lurndal]

That's where you need kdb, instead of kgdb. With kdb, the serial port is
shared between the debugger and the host OS. The 3.5+ kernels have it built-in,
if I recall correctly.

I've never used kdgb, so I don't know if there is a way to multiplex the console
over the serial port along with the GDB protocol.

scott