linux-ext4 - [Attachment has been removed]RE: AW: ext4 filesystem bad extent error review

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: <AE39A478622CF340ABEC2418D74074F61FC59ACC76@SGPMBX05.APAC.bosch.com>
Date:	Mon, 6 Jan 2014 13:10:46 +0800
From:	"Huang Weller (CM/ESW12-CN)" <Weller.Huang@...bosch.com>
To:	Eric Sandeen <sandeen@...hat.com>,
	"Juergens Dirk (CM-AI/ECO2)" <Dirk.Juergens@...bosch.com>,
	Theodore Ts'o <tytso@....edu>
CC:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: [Attachment has been removed]RE: AW: ext4 filesystem bad extent error review

The e-mail sent to you contained an attachment with a not allowed filetype.
Please inform the sender to pack this type of attachment into a
password protected ZIP-archive.

Eine an Sie gesendete E-Mail enthielt einen nicht erlaubten Dateianhang.
Bitte informieren Sie den Absender, diese Art von Anhang kann nur
als Passwort geschütztes ZIP-Archiv versendet werden.

Details:

Sender: Weller.Huang@...bosch.com
Recipients: tytso@....edu;sandeen@...hat.com;linux-ext4@...r.kernel.org
Subject: "RE: AW: ext4 filesystem bad extent error review"
Time: Mon Jan  6 06:10:55 2014
File: code_out_pc.tar

The cleaned message body is below this line or in the attached e-mail.
Die bereinigte E-Mail ist unter der folgenden Linie oder in beigefügtem Attachment.
--------------------------------------------------------------------------------

>On 1/3/14, 10:29 AM, Juergens Dirk (CM-AI/ECO2) wrote:
>> So, I think there _might_ be a kernel bug, but it could be also a problem 
>> related to the particular type of eMMC. We did not observe the same issue
>> in previous tests with another type of eMMC from another supplier, but this
>> was with an older kernel patch level and with another HW design.
>> 
>> Regarding a possible kernel bug: Is there any chance that the invalid 
>> ee_len or ee_start are returned by, e.g., the block allocator ?
>> If so, can we try to instrument the code to get suitable traces ?
>> Just to see or to exclude that the corrupted inode is really written
>> to the eMMC ?

>From your description it does sound possible that it's a kernel bug.
>Adding testcases to the code to catch it before it hits the journal
>might be helpful - but then maybe this is something getting overwritten
>after the fact - hard to say.

>Can you share more details of the test you are running?  Or maybe even
>the test itself?

>I've used a test framework in the past to simulate resets w/o needing
>to reset the box, and do many journal replays very quickly.  It'd be
>interesting to run it using your testcase.

Please get code_out.tar.gz from my another mail.
About the PC side, I write a win32 application which can send commands via uart to TOE power supplier(the power supplier has remote control mode which it can accept command from its uart interface).
The Putty src, I only modified the winser.c which include in the attachment of this mail. There is also a readme.txt to introduce the package.
If you want to use my test environment , I think you just need modify the putty_toe.bat with yours.  It is easy to understand the commands in this script. You can replace the command to control the power controller with yours.
Please feel free to let me know if you have any issue about the environment setup.

Thanks
Huang weller