linux-kernel - data corruption: revalidating a (removable) hdd/flash on re-insert

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-next>] [day] [month] [year] [list]

Date:	Fri, 31 Oct 2008 18:38:01 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: data corruption: revalidating a (removable) hdd/flash on re-insert

To make a long story short: is there a way to force kernel
to re-validate a replaced usb-connected hard drive (or a
flash) *automatically*?

Because right now, the kernel does not see that the drive
has been replaced, and uses *some* old cached values, which
results in random data corruption here and there, and other
similar odd things.

For example, I've an USB flash reader (Carry Computer Eng.,
Co., Ltd 6-in-1 Card Reader, but that's not really relevant).
Among other things it has a compact flash slot.  And I've
2 differently-size CF cards.

So I turn the machine on, insert one CF card, mount it, do
something with its vfat filesystem, umount it and remove
it.  Next I insert another card, and when trying to mount
it, the kernel says:

FAT: invalid media value (0x1e)
VFS: Can't find a valid FAT filesystem on dev sdb1.

When trying to run cfdisk for example, it complains that
"partition 0 ends after end of the drive" (or something
similar).

Sometimes the mount succeeds, but there are all sorts of
errors here in there, the filesystem is messed up, whith
parts of the files "from" just-removed card, and parts
from the new card.

And sure enough, when I, forgetting the issue, trying
to WRITE something to the card, it becomes almost 100%
messy...

What helps is to run, for example,

  blockdev --rereadpt /dev/sdb

manually, after replacing the card.

The first thing I was thinking of when saw the whole mess
is: there must be some process like hald/udev/whatever
messy subsystem du jur, which holds the device node open
and prevents the kernel from re-reading the drive by its
own as it correctly did in the past.  Nope, I've shut down
everything, and the same happens when only shell process
running INSTEAD of init (booting with init=/bin/sh option).

So at some point the kernel stopped noticing the drive
change in this configuration some time ago.  I can't say
when exactly, since I didn't use the card reader for over
a year, and certainly didn't try it with more than one
card in a row for even longer time.   It worked in the
past, that's for sure.  And it definitely does not work
(resulting in the above mess) with 2.6.25, 2.6.26 and 2.6.27.

Help?

Thanks!

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