Re: [PATCH] Re: bad pmd ffff810000207238(9090909090909090).

[Jan Engelhardt]

On Wednesday 2008-05-28 21:56, Willy Tarreau wrote:
>On Wed, May 28, 2008 at 07:36:07PM +0100, Hugh Dickins wrote:
>> On Tue, 27 May 2008, Fede wrote:
>> > 
>> > Today I tried to start a firewalling script and failed due to an unrelated
>> > issue, but when I checked the log I saw this:
>> > 
>> > May 27 20:38:15 kaoz ip_tables: (C) 2000-2006 Netfilter Core Team
>> > May 27 20:38:28 kaoz Netfilter messages via NETLINK v0.30.
>> > May 27 20:38:28 kaoz nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
>> > May 27 20:38:28 kaoz ctnetlink v0.93: registering with nfnetlink.
>> > May 27 20:38:28 kaoz ClusterIP Version 0.8 loaded successfully
>> > May 27 20:38:28 kaoz mm/memory.c:127: bad pmd
>> > ffff810000207238(9090909090909090).
>> > 
>> > I also found another post with a very similar issue. The other post had almost
>> > the same message (*mm*/*memory*.*c*:*127*: *bad* *pmd*
>> > ffff810000207808(9090909090909090).)
>> > 
>> > Does anyone know what is it?
>> 
>> Thanks a lot for re-reporting this: it was fun to work it out.
>> It's not a rootkit, it's harmless, but we ought to fix the noise.
>> Simple patch below, but let me explain more verbosely first.
>> 
>> What was really interesting in your report was that the address
>> is so close to that in OGAWA-San's report.  I had a look at that
>> page on my x86_64 boxes, and they have lots of 0x90s there too.
>> It's just some page alignment filler that x86_64 kernel startup
>> has missed cleaning up - patch below fixes that.  There's no
>> security aspect to it: the entries were already not-present,
>> they just generate this noise by triggering the pmd_bad test.
>
>Is there a particular reason we use 0x90 as an alignment filler ?

Alignment within functions. You could use a JMP to jump over
the alignment, but that would be costly. So in order to
"run through the wall", you need an opcode that does not
do anything, something like 0x90.
0xAF would map to scasd on x86, and I'd hardly call that a
no-op.
--
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/