Re: kgdb test suite failure
From: Alexander Beregalov
Date: Tue May 20 2008 - 14:31:05 EST
2008/5/20 Jason Wessel <jason.wessel@xxxxxxxxxxxxx>:
> Alexander Beregalov wrote:
>> I tried to run the latest git kernel and got the following error.
>> See an attachment for full dmesg.
>> kgdbts: ERROR PUT: end of test buffer on 'do_fork_test' line 5
>> expected OK got $E02#a7
>> ------------[ cut here ]------------
>> WARNING: at drivers/misc/kgdbts.c:721 run_simple_test+0x1de/0x20e()
>> Modules linked in:
>> Pid: 6, comm: khelper Not tainted 2.6.26-rc1-00279-g28a4acb #12
>> [<c011a00a>] warn_on_slowpath+0x41/0x6c
>> [<c011aa77>] ? vprintk+0x3e7/0x407
>> [<c0254cf4>] ? number+0x10d/0x1cf
>> [<c012d3da>] ? sched_clock_cpu+0x70/0x88
>> [<c011aaac>] ? printk+0x15/0x17
> Is this a problem you can reproduce every time? Basically what line 5
Yes, it happened every time when kernel booted, even before init.
> of the test does is to write a value into the register struct to rewind
> the PC after hitting a breakpoint such that the instruction will be
> executed again. This is stored in memory which will be used for a
> context switch back to the process. The test also replaces the
> original instruction in memory. In this case the memory write failed.
> This will certainly be fatal to the operation of the kernel and
> stability would be called into question if the kernel doesn't just crash
> and oops in strange ways immediately.
> I looked in your dmesg log and noticed:
> [ 21.027632] Testing CPA: undo c035d000-c044e000
> [ 21.083029] Testing CPA: write protecting again
> [ 21.297278] kgdbts: ERROR PUT: end of test buffer on 'do_fork_test'
> line 5 expected OK got $E02#a7
> I looked through the kernel source in the tip of the tree for the
> "Testing CPA: write protecting again". It seems this code is only used
> when CONFIG_DEBUG_RODATA is set. Perhaps this option is mutually
> exclusive of the use of kgdb? Today kgdb assumes it can write anywhere
> without any kind of special concession for page protection bits.
It seems like this.
The kernel with the following config can boot.
# CONFIG_DEBUG_RODATA is not set
And kgdbts runs successfully:
[ 7.579110] kgdb: Registered I/O driver kgdbts.
[ 7.633491] kgdbts:RUN plant and detach test
[ 7.686505] kgdbts:RUN sw breakpoint test
[ 7.734031] kgdbts:RUN bad memory access test
[ 7.786258] kgdbts:RUN singlestep test 1000 iterations
[ 7.847832] kgdbts:RUN singlestep [0/1000]
[ 7.905206] kgdbts:RUN singlestep [100/1000]
[ 7.965778] kgdbts:RUN singlestep [200/1000]
[ 8.026037] kgdbts:RUN singlestep [300/1000]
[ 8.086507] kgdbts:RUN singlestep [400/1000]
[ 8.146839] kgdbts:RUN singlestep [500/1000]
[ 8.207588] kgdbts:RUN singlestep [600/1000]
[ 8.267889] kgdbts:RUN singlestep [700/1000]
[ 8.328643] kgdbts:RUN singlestep [800/1000]
[ 8.388939] kgdbts:RUN singlestep [900/1000]
[ 8.449322] kgdbts:RUN hw breakpoint test
[ 8.497369] kgdbts:RUN hw write breakpoint test
[ 8.551663] kgdbts:RUN access write breakpoint test
[ 8.610117] kgdbts:RUN do_fork for 100 breakpoints
> Certainly kgdb's memory write function could be changed based on the
> conditional CONFIG_DEBUG_RODATA if there is an api to
> check/change/revert the protection bits on the memory pages. This of
> course is assuming that this is the root cause of the problem.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/