From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:38411 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932371AbcEXTj4 (ORCPT ); Tue, 24 May 2016 15:39:56 -0400 From: Jeff Moyer To: Andrew Morton Cc: Eryu Guan , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, viro@ZenIV.linux.org.uk Subject: Re: [PATCH v3] direct-io: fix direct write stale data exposure from concurrent buffered read References: <1463156728-13357-1-git-send-email-guaneryu@gmail.com> <20160524122455.4fc3d250b17fcd776dc15968@linux-foundation.org> Date: Tue, 24 May 2016 15:39:54 -0400 In-Reply-To: <20160524122455.4fc3d250b17fcd776dc15968@linux-foundation.org> (Andrew Morton's message of "Tue, 24 May 2016 12:24:55 -0700") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Andrew Morton writes: > On Sat, 14 May 2016 00:25:28 +0800 Eryu Guan wrote: > >> Currently direct writes inside i_size on a DIO_SKIP_HOLES filesystem are >> not allowed to allocate blocks(get_more_blocks() sets 'create' to 0 >> before calling get_block() callback), if it's a sparse file, direct >> writes fall back to buffered writes to avoid stale data exposure from >> concurrent buffered read. But there're two cases that can result in >> stale data exposure are not correctly detected. >> >> 1. The detection for "writing inside i_size" is not sufficient, writes >> can be treated as "extending writes" wrongly. For example, direct write >> 1FSB to a 1FSB sparse file on ext2/3/4, starting from offset 0, in this >> case it's writing inside i_size, but 'create' is non-zero, because >> 'block_in_file' and '(i_size_read(inode) >> blkbits' are both zero. > > um, what is an "FSB"? File System Block, as opposed to a block device block. :) -Jeff