memory protection in linux kernels

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

Reply to
Mark
Loading thread data ...

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

Reply to
Scott Lurndal

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

Reply to
Mark

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).

The Kconfig files should handle any required dependencies for you.

scott

Reply to
Scott Lurndal
[...]

'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.

Reply to
Rainer Weikusat

[skip]

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

Reply to
Mark

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
Reply to
Ian Collins

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

Reply to
Scott Lurndal

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.