linux-kernel - Re: Linux 3.1-rc7

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:	Wed, 28 Sep 2011 01:34:53 -0400
From:	Arnaud Lacombe <lacombar@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 3.1-rc7

Hi,

On Tue, Sep 27, 2011 at 7:31 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Sep 27, 2011 at 4:25 PM, Arnaud Lacombe <lacombar@...il.com> wrote:
>>
>> What is strange is that I moved from -rc7 to -rc8 with:
>>
>> % git reset --hard v3.1-rc8
>
> Git optimizes all the filesystem operations heavily. That means that
> files that have not changed between two releases and are clean (and
> match) in the index are not re-written by a git reset.
>
> You can obviously always force a re-write by removing all files and
> then doing the reset, but it should never be necessary under normal
> circumstances.
>
>> which should have reset the corrupted file. FYI, the machine is
>> running 2.6.35.13-91.fc14.x86_64. Something's smelly with that kernel
>> :-/
>
> More likely something is smelly with your filesystem or memory. A few
> bits flipped on disk or in the page cache would do it, and git has
> caught corruption like that before.
>
> Do you still have the bad tree around? Because it migth be interesting
> to see what the corruption pattern is if you do.
>
No, unfortunately I checked the file out and overwrote it several
time. I'll be more careful next time.

<off-topic>
Speaking of corruption, I'm encountering another set on an external
hard-drive, connected through USB. The partition ended up being
corrupted after transferring a few dozen GB, and being unmount'ed, ie.
I unmounted the device and tried to mount it back, no spin-down or
whatever; and the superblock was corrupted. fsck corrected a lots of
issue, wrong group checksum, wrong group block usage count (mainly was
always 32768)... but now, some files have wrong checksums
(expectable). These files only seems to belong to files previously
transferred. Luckily, some of these are text file, so I can easily do
a diff. The same corruption pop up (at least in those text file): a
sequence of 4 bytes is replaced by 0x000000E0 at offset 0x1E4 of the
start of the file for some of them, 0x3E4 for two other (same
corruption though). Locating the corruption will be more tricky in
binary files.

I may not trust the drive, but the fact that only known offset are
corrupted (in text files), the exact same way, sounds too much of a
coincidence. Anyway, I started a long SMART self test to see if it
catches anything, as there was no DMA transfer error[0].
</off-topic>

my 2c,
 - Arnaud

[0]: there used to be, but this was because of a bad SATA cable.
--
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/