From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:50683 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750781AbeBTI7w (ORCPT ); Tue, 20 Feb 2018 03:59:52 -0500 To: linux-fsdevel Cc: Jens Axboe , Goldwyn Rodrigues From: Nikolay Borisov Subject: Correctness of inode_dio_end in generic DIO code Message-ID: Date: Tue, 20 Feb 2018 10:59:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hello, Currently the generic DIO code calls inode_dio_begin/inode_dio_end if DIO_SKIP_DIO_COUNT is not set. However, te generic ode doesn't really know if there is a lock synchronizing all the various inode_dio_* operations. As per inode_dio_wait comment : Must be called under a lock that serializes taking new references to i_dio_count, usually by inode->i_mutex. So is it at all correct to increment i_dio_count in generic dio code without imposing strict locking requirement? Currently, most major filesystems (Ext4/xfs/btrfs) do modify i_dio_count under their own locks. Perhaps it's best if i_dio_count modification are removed from the generic code, what do people think about that?