Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp14024517pxu; Mon, 4 Jan 2021 10:45:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJxlpbQxamnBTZGZPf2pL+5MOpdUudt8SuQznsBIYKgy1VbY3wVgGgmBI0n+tlEghCzjcUs9 X-Received: by 2002:a05:6402:8da:: with SMTP id d26mr69585570edz.157.1609785950014; Mon, 04 Jan 2021 10:45:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609785950; cv=none; d=google.com; s=arc-20160816; b=sJsJWRv/FwPkAJRjRc2J08QRw44scRUfigkopC8EEipfEvnyB9hyPzPKcEycE5Mh6m h7xDKibYlIQGEvR7hndW9Z5Aofcw8WtnHTV8P6CEQBMyqsWbRumX0FhvWl04lfYnuZ1I 1krmpSqT+4eUDcFbtKZcYLzI+7xeO1XSc9cMDtyZ+CtvYTLEwuWQ3I5D5LqtdyqaZ4Nb FtrXkTiSPBWH4WaLK4e8TGrcBv4pGv+Dhys+iOpLvIE4cA2xaNQg0KQ/R9dyDtovL/KU dBWraNsIx9yp0fBLLHYWaNCFZXzERT9lF+qH9XDyKTedlKCTQyfXHbYg8TqNcqI9j3Vq BTlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=VNDmuHTQVp470uEBKv9sMyvXtVtMx0UBeqfCleKi6X8=; b=hURn/mlyvWdb/SZekLlFSkImy4yIpopQmGGc8wH3eCYTUXVRPZ+M8aftj/yS9qPYNz a/2y48hyRc5lJI1QNZ+GmA5buiJUVBlnwm3rrEZ59oH7c/7U5Gqm+qJ1km5orP5nKHqG 9OEAW2vP901zi1/RGcLLZH6CWIh7zFyVVlIivdirzcGCRIZxoXlY5D3I5Qvh00V5JFn7 47/QkFZvcMQ46brq/zgG2UcvO17rdI/ED+ZT4A5NZ1Wp5z+7UQqaDn5oTRnleCMqMM/b mVcChopyQsBl3UIfD67Ho/tuVB+2443+7S6qqoTdYqRHgH5bt/sTkfmhKbsRTBK/vj1i FrYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="Jmmz/bZf"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r7si715132eji.306.2021.01.04.10.45.26; Mon, 04 Jan 2021 10:45:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="Jmmz/bZf"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727780AbhADSoa (ORCPT + 99 others); Mon, 4 Jan 2021 13:44:30 -0500 Received: from mail.kernel.org ([198.145.29.99]:47136 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726330AbhADSoa (ORCPT ); Mon, 4 Jan 2021 13:44:30 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2B15D21D1B; Mon, 4 Jan 2021 18:43:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1609785829; bh=GylU2VtkYsBj1SJe+f/YDhcp84RMGLIp50WYd8oU+uk=; h=From:To:Cc:Subject:Date:From; b=Jmmz/bZfEAzWJkm5bA3KblGdEIESV5oR+BF5aSgTeXrwOMRbg5Zn93I/3dSqyKrSd Vy5UXlcI9Hg3vtMSzrR1NUyrhazNegiC49xhfKOgHW0W5BY4fOMMdIw2Z6B/7M/DLg iZxrI8Q3gA6vapS6RWOblEI0guafRHgU8GxF0ii97ra05XO3NH2VYejp9lMlittVPo t+OTCU8CeZCORDC3fMbY89Qb6Ogrb3w41ejqu+HqdJ5VVbDI29IiPe/4BE2Er0OXpv zvK8yOy9JZnkM6UnkgFlOxTuGebZkpoClVbLVbj1/PULKKXG638N/HBCNAjFIHC79A /h5yxAKUzw4dg== From: Jeff Layton To: viro@zeniv.linux.org.uk Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, sargun@sargun.me, amir73il@gmail.com, vgoyal@redhat.com Subject: [PATCH][RESEND] vfs: serialize updates to file->f_sb_err with f_lock Date: Mon, 4 Jan 2021 13:43:47 -0500 Message-Id: <20210104184347.90598-1-jlayton@kernel.org> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When I added the ability for syncfs to report writeback errors, I neglected to adequately protect file->f_sb_err. While changes to sb->s_wb_err don't require locking, we do need to protect the errseq_t cursor in file->f_sb_err. We could have racing updates to that value if two tasks are issuing syncfs() on the same fd at the same time, possibly causing an error to be reported twice or not at all. Fix this by protecting the f_sb_err field with the file->f_lock. Fixes: 735e4ae5ba28 ("vfs: track per-sb writeback errors and report them to syncfs") Signed-off-by: Jeff Layton --- fs/sync.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) Al, could you pick up this patch for v5.11 or v5.12? I sent the original version about a month ago, but it didn't get picked up. In the original posting I marked this for stable, but I'm not sure it really qualifies since it's a pretty unlikely race with an oddball use-case (overlapping syncfs() calls on the same fd). diff --git a/fs/sync.c b/fs/sync.c index 1373a610dc78..3be26ff72431 100644 --- a/fs/sync.c +++ b/fs/sync.c @@ -162,7 +162,7 @@ SYSCALL_DEFINE1(syncfs, int, fd) { struct fd f = fdget(fd); struct super_block *sb; - int ret, ret2; + int ret, ret2 = 0; if (!f.file) return -EBADF; @@ -172,7 +172,12 @@ SYSCALL_DEFINE1(syncfs, int, fd) ret = sync_filesystem(sb); up_read(&sb->s_umount); - ret2 = errseq_check_and_advance(&sb->s_wb_err, &f.file->f_sb_err); + if (errseq_check(&sb->s_wb_err, f.file->f_sb_err)) { + /* Something changed, must use slow path */ + spin_lock(&f.file->f_lock); + ret2 = errseq_check_and_advance(&sb->s_wb_err, &f.file->f_sb_err); + spin_unlock(&f.file->f_lock); + } fdput(f); return ret ? ret : ret2; -- 2.29.2