linux-kernel - Re: (Last oops is Tainted: P) Re: 2.6.22-rc5: pdflush oops under heavy disk load

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 24 Jun 2007 11:10:09 +0100
From:	"Jay L. T. Cornwall" <jay@...na.co.uk>
To:	Oleg Verych <olecom@...wer.upol.cz>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Chuck Ebbert <cebbert@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: (Last oops is Tainted: P) Re: 2.6.22-rc5: pdflush oops under
 heavy disk load

Oleg Verych wrote:

>> That sounds like a good theory: you're getting easily-hit oopses in one of
>> the kernel's most-used codepaths which hasn't chanbged much in a long
>> time.  So Something Odd Has Happened.

> Maybe this time it's just "Tainted: P"?

That'sthe NVIDIA module, which isn't doing much with X shut down
regardless. It was bad form to forget this, of course, but is unrelated
to the problem.

> And oops have no ext3, like prev. one.

I know. This isn't ext3 related and I'm fairly certain drivers/net/atl1
is trashing... something. Perhaps the page table because:

[  153.785325] Bad page state in process 'scp'
[  153.785327] page:ffff81000308d020 flags:0x0040ad41dc050845
mapping:53dfe57d17cc59cf mapcount:16885953 count:292554304
[  153.785329] Trying to fix it up, but a reboot is needed

This one dismisses a reference counting issue because the page data here
looks like garbage. And a panic in VLC, playing a video across the
network hits a similar problem:

[ 9194.281809]  [<ffffffff802849e3>] page_remove_rmap+0x53/0x110
[ 9194.281819]  [<ffffffff8027c32c>] unmap_vmas+0x4ec/0x7c0
[ 9194.281852]  [<ffffffff802807ac>] unmap_region+0xcc/0x170
[ 9194.281867]  [<ffffffff8028160a>] do_munmap+0x22a/0x2f0
[ 9194.281877]  [<ffffffff80439ee2>] __down_write_nested+0x12/0xb0
[ 9194.281892]  [<ffffffff802ef936>] sys_shmdt+0xb6/0x150
[ 9194.281903]  [<ffffffff80209e8e>] system_call+0x7e/0x83
[ 9194.281921]
[ 9194.281924]
[ 9194.281925] Code: 48 2b ba 98 21 00 00 48 c1 ff 03 48 0f af f8 48 03
ba a8 21
[ 9194.281973] RIP  [<ffffffff80271f99>] page_to_pfn+0x19/0x40

> Jay, check your oops against "Tainted: P" flag, which is not supported
> here, and not drop persons, who assisted you from the CC list.

My apologies, I had thought the etiquette was to only include
maintainers on the CC list.

I'll try and locate a maintainer for the Attansic driver a bit later,
but I've only seen people loosely related to it. In any case we may as
well let this thread die because it's not related to a filesystem bug
(which the CC list is presumably interested in).

-- 
Jay L. T. Cornwall, http://www.esuna.co.uk/~jay/
PhD Student
Imperial College London
-
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/