Possible crash consistency bug with write()

[hayley-leblanc]

Hi,

I'm reporting what I believe to be a crash consistency bug in PMFS. Suppose we run the following workload on an empty PMFS file system mounted at /mnt/pmem:

creat /mnt/pmem/foo
write 1 byte to foo
write 8 bytes to foo

When performing the second write with pmfs_xip_file_write(), the if statement at line 380 of xip.c will be entered because the second write is modifying the same block as the first write, and PMFS will use pmfs_file_write_fast() to avoid using a transaction. After writing the data, this function atomically updates foo's size and time fields, and finally flushes the first cacheline of foo's inode using pmfs_flush_buffer(). However, this flush does not include a fence, so these updates to the inode may be reordered with writes from the beginning of the subsequent system call. This can result in losing the data from the second write, even though the write() call is completed.

I'm not 100% sure that this would be considered a bug in PMFS, but it can result in data loss and only requires the addition of a store fence to fix.

[iaoing]

I suspect this is not a bug.
After pmfs_file_write_fast(), PMFS unlocks the inode by inode_unlock(inode);, which implies an implicit fence. Moreover, there will be a context switch after the write, which also implies a fence. Thus, I suspect it is unnecessary to add a fence at the end of pmfs_file_write_fast().

PMFS-new/xip.c

Lines 430 to 434 in 8913fbf

	out:
	inode_unlock(inode);
	sb_end_write(inode->i_sb);
	PMFS_END_TIMING(xip_write_t, xip_write_time);
	return ret;

Memory barriers in kernel: https://www.kernel.org/doc/Documentation/memory-barriers.txt