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:	Thu, 28 Aug 2014 10:37:04 -0400
From:	Rob Harris <rob.harris@...il.com>
To:	linux-ext4@...r.kernel.org
Subject: Refreshing after OOB file update?

Greetings. My apologies in advance... I need to ask a weird question and 
can't think of a more appropriate place to ask.

And yes, I know this is a broken/stupid/insane/WTF?/n00b request, but 
bear with me for a second.

I'm writing a FUSE layer for a project that sits on top of a ext4 
filesystem. My daemon will be the ONLY reader and writer; Except! ... 
I've been told that upon request, another (hardware--pcie) component of 
my system needs to be able to write data into a existing file in the 
filesystem DIRECTLY (i.e. using the absolute block ID returned from 
fiemap() ) without my FUSE layer or the ext4 file system knowing that 
the writing is occuring (I get a notification later via another means). 
So, basically, files are changing out from under me. (Assume that they 
know how big the extents are so they won't do anything stupid like 
overrun them or anything.)

Thinking this was insane, I ran a simple test:

- I created a file of all 0's using dd.
- I ran mkfs.ext4 on the file and loop mounted the file system.
- I created a dummy text file comprised of all 'y's (output of the yes 
command).
- I wrote a program to call fiemap() and get the physical location of 
the text file contents in the loop mounted fs file.
- I used dd to write a string into the file (i.e. echo "xxxx" | dd 
of=/tmp/dummy.fs bs=1 seek=138416128 conv=notrunc)
- If I dd if=/tmp/dummy.fs | hexdump -C, then I can see the changes written.
- If I cat the text file, I DON'T see the changes.
- If I touch the text file and cat it, still no joy.
- If I copy the text file to another file, I DON'T see the changes in 
either file.
- If I umount and remount the partition and then cat the file, I CAN see 
the changes.

This tells me (probably naively) that the kernel is caching the old file 
contents.

Is there a way for me to tell the file system that something out-of-band 
change a file contents and to force a re-read from the disk?

Also, this was performed using a loop mount--is the expectation that a 
similar test with live hardware/block device file systems would behave 
similarly?

Thanks again for placating my insanity.
-Rob Harris


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ