From patchwork Wed Nov 21 02:43:56 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eiichi Tsukata X-Patchwork-Id: 10691555 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 7917F14E2 for ; Wed, 21 Nov 2018 02:44:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 57F8C29186 for ; Wed, 21 Nov 2018 02:44:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 48016290B8; Wed, 21 Nov 2018 02:44:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B3A59290B8 for ; Wed, 21 Nov 2018 02:44:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726101AbeKUNQf (ORCPT ); Wed, 21 Nov 2018 08:16:35 -0500 Received: from mail-pl1-f194.google.com ([209.85.214.194]:43416 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725950AbeKUNQf (ORCPT ); Wed, 21 Nov 2018 08:16:35 -0500 Received: by mail-pl1-f194.google.com with SMTP id gn14so3199845plb.10 for ; Tue, 20 Nov 2018 18:44:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=etsukata-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=H/VYLi6U4iBE4eE2CcKKa7D9aRHjN0CLWuRfVxyf9i8=; b=gzL7tHpQppPG6H2q6XJAekkauuxuemA3cqF44dCo6WHLkk2+LyxJvAhUsTtq3xNsLc /qioC1tOg6QniVxdcLVuJdGX10qWCad8pNj1OdZhZyuITpGGXXdS0Xn8h91Kz4YyofTL kE08oGzcexOSTjoJUDdLuQoy53LtvEIBgUgFh3qMhc0pSEiFAGs5eu78afigpBBWtJD2 OICQkZcUNpnHITn3DbbDIK+AwCUG6GrGItnxn6L08ag25QTS6uE0uPrnxi+o2yRq81ak 6zg+wXpdy6PX6+7caxkQJpN1qWeMOuQC7kKsdIE//tTq57SFE7E4Lv7o0joJJuE6iGuF ZHaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=H/VYLi6U4iBE4eE2CcKKa7D9aRHjN0CLWuRfVxyf9i8=; b=eyAx6kWtzuNRxPMT2I3aOpHEnQ4qXpU9iODwve6JGGoQb+bNm8YvWE68xjTM1EeWJi 3nc6Cgl+Y3r59DTqiC9lRTyfibObRQMbvEP9JwSjzmnekNkDvu4HMR4cck1meMr2awhw EEsCxiFyA3PCrl2/cB9SJc7iaPVyBoFzfYzdibhQtYY8fGYvaWw9dMn3EjVZnVY7fe3F FM7Z9oWWCkuQd8LHP5Q880mkGBOidX7uMoIwCQDezKXbGLsBZzIbItN/3nZPq70mLrb5 91+2gkz2VSO65kjc9qJsWFpsYpqANt/XU9cQo9NknuDQk4+2b7NLxCc0uFAu770pnjKV OtxQ== X-Gm-Message-State: AA+aEWbuS2lxPEBIvp21BreG1+iVFTPHQEJKdoTWjoaN9uyazC1LIAN6 LQz+XtgdKwJrH9yHZQP0GarkXA== X-Google-Smtp-Source: AFSGD/VtX4VsaOh0ScdtJ7EuZP2uGVoUU4W1SYpsS2c6Ge7+MDAz+PmhTQkU02evyhqKpL0SFw784Q== X-Received: by 2002:a17:902:a411:: with SMTP id p17mr4828581plq.292.1542768253159; Tue, 20 Nov 2018 18:44:13 -0800 (PST) Received: from fedora.fout.local (fs76eecbcd.tkyc008.ap.nuro.jp. [118.238.203.205]) by smtp.gmail.com with ESMTPSA id l63-v6sm46356677pfb.75.2018.11.20.18.44.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Nov 2018 18:44:12 -0800 (PST) From: Eiichi Tsukata To: andi@firstfloor.org, Chris Mason , Josef Bacik , David Sterba , "Theodore Ts'o" , Andreas Dilger , Jaegeuk Kim , Chao Yu , Miklos Szeredi , Bob Peterson , Andreas Gruenbacher , Alexander Viro , linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, cluster-devel@redhat.com, linux-unionfs@vger.kernel.org Cc: Eiichi Tsukata Subject: [PATCH v1 0/4] fs: fix race between llseek SEEK_END and write Date: Wed, 21 Nov 2018 11:43:56 +0900 Message-Id: <20181121024400.4346-1-devel@etsukata.com> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Some file systems (including ext4, xfs, ramfs ...) have the following problem as I've described in the commit message of the 1/4 patch. The commit ef3d0fd27e90 ("vfs: do (nearly) lockless generic_file_llseek") removed almost all locks in llseek() including SEEK_END. It based on the idea that write() updates size atomically. But in fact, write() can be divided into two or more parts in generic_perform_write() when pos straddles over the PAGE_SIZE, which results in updating size multiple times in one write(). It means that llseek() can see the size being updated during write(). This race changes behavior of some applications. 'tail' is one of those applications. It reads range [pos, pos_end] where pos_end is obtained via llseek() SEEK_END. Sometimes, a read line could be broken. reproducer: $ while true; do echo 123456 >> out; done $ while true; do tail out | grep -v 123456 ; done example output(take 30 secs): 12345 1 1234 1 12 1234 Note: Some file systems which indivisually implements llseek() and hold inode mutex lock in it are not affected. ex:) btrfs, ocfs2 Patch 1: re-implements inode lock for SEEK_END in generic_file_llseek() Patch 2 to 4: implement inode lock for SEEK_END in each file systems Eiichi Tsukata (4): vfs: fix race between llseek SEEK_END and write ext4: fix race between llseek SEEK_END and write f2fs: fix race between llseek SEEK_END and write overlayfs: fix race between llseek SEEK_END and write fs/btrfs/file.c | 2 +- fs/ext4/file.c | 10 ++++++++++ fs/f2fs/file.c | 6 +----- fs/fuse/file.c | 5 +++-- fs/gfs2/file.c | 3 ++- fs/overlayfs/file.c | 23 ++++++++++++++++++++--- fs/read_write.c | 37 ++++++++++++++++++++++++++++++++++--- include/linux/fs.h | 2 ++ 8 files changed, 73 insertions(+), 15 deletions(-)