linux-kernel - Re: kernel BUG at fs/buffer.c:3205 (stable 3.5.3)

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]

Message-ID: <507A8189.7020402@ahsoftware.de>
Date:	Sun, 14 Oct 2012 11:10:33 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Jan Kara <jack@...e.cz>
CC:	Dan Carpenter <dan.carpenter@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: kernel BUG at fs/buffer.c:3205 (stable 3.5.3)

Am 02.10.2012 11:30, schrieb Alexander Holler:
> Am 01.10.2012 11:21, schrieb Alexander Holler:
>> Hello,
>>
>> Am 01.10.2012 11:10, schrieb Jan Kara:
>>
>>>> sha1sum Tainted: P           O 3.5.4-00009-gfa43f23-dirty #228
>>>    BTW, fglrx moodule taints the kernel because it is a proprietary
>>> driver.
>>
>> I know.
>>
>>> Can you reproduce the issue without this module loaded?
>>
>> I will try it with a clean 3.6. Most of the 9 additional patches here
>> are for ARM boxes, but anyway. I will need a few days.
>
> Just tried my "tar cp . | mbuffer | bzip2smp >/usb3/ext4/foo.tar.bz2
> using a kernel 3.6 without using fglrx and without any additional
> patches. The first try already ended up in a broken archive (tar djf =>
> bzip2: Data integrity error when decompressing), but (again) without the
> BUG() in fs/buffer.c getting hit. Will do some more tests, trying hit
> that BUG().

I found the problem. Looks like either the RAM, CPU or the stuff 
inbetween is broken because I see some memory failures (1 bit flipped on 
some bytes) when using memtest(86+).

The people which are responsible that the chips for "consumer"-HW and 
laptops got their (already included) ECC functionality disabled should 
get hit with Googles (now 3y old) study on that topic all the day. 
Leaving customers in danger by not offering them at least the 
possibility to use ECC RAM is just stupid.

Sorry to everyone whose time I've wasted.

Regards,

Alexander

--
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/