linux-kernel - Re: Caching issues with tmpfs?

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4F7DBE00.9070800@freebox.fr>
Date:	Thu, 05 Apr 2012 17:45:04 +0200
From:	Florian Fainelli <ffainelli@...ebox.fr>
To:	Hugh Dickins <hughd@...gle.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: Caching issues with tmpfs?

Hi again Hugh,

Le 04/05/12 17:07, Florian Fainelli a écrit :
> Hi Hugh,
>
> I am encountering a very weird and serious issue with tmpfs, which I
> have seen both in 2.6.39 and 3.2.13. The issue is the following:
>
> 1) I read a file from a NAND device back to /tmp/bar
> 2) /tmp/bar is loopback mounted to /tmp/bar_mount/
> 3) when I list the contents of /tmp/bar_mount I see only half of my
> files, and using hexdump on /tmp/bar shows that the cramfs header is
> correct and contains all, which rules out the cramfs issue
> 4) if I move /tmp/bar to /tmp/bar.move and loopback mount /tmp/bar.move
> to /tmp/bar_mount, I now see all the files present
>
> I have compared the md5sums of the cramfs file before mounting, after
> mounting, before moving, after moving, they are all the same. Also, the
> loopback mount does not yiel when mounting the cramfs file, which rules
> out its bad integrity.
>
> the /tmp directory is mounted with the defaults attributes (rw,relatime).
>
> My system is a x86 Atom-based System-on-a-Chip and should not suffer
> from the CPU data cache aliasing issue mentioned here:
> http://lkml.indiana.edu/hypermail/linux/kernel/1202.0/00090.html
>
> I backported this patch however, and it does not make any difference as
> expected.
>
> This behavior has been observed on several devices.
>
> I will try to provide you with a test case to reproduce the issue,
> meanwhile any hints are appreciated :)

I am terribly sorry for suspecting tmpfs, the issue is actually in 
busybox, which is smart enough not to delete the loop device after an 
umount and keep a stale copy of the file used as source. Consequent 
mounts are then given the same stale copy because the name of the source 
file matches the non-deleted loopback setup.
--
Florian
--
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/