From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6AAD3C282D7 for ; Sun, 10 Feb 2019 12:24:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 37F4B21934 for ; Sun, 10 Feb 2019 12:24:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549801468; bh=ubNVQkmNDpbpJi58uJyoLMnWE1X7+fGT2k5GHTJIowc=; h=Subject:To:Cc:From:Date:List-ID:From; b=sDm6DPD7aJGbzUVStKxUVokqCoSRSueo2XS0k+cCqfo7CnLWsMd6LMF7PgV7CpW3Z aDgSVZ42hE8NMqn1o9jSd2RDFk1OftBfwwJMFJiJZqQ7Q/ougE7L/0QfSVMMYAOXRp 5qAeMZHk30MTY5dqRk11NdrcQr6aqO2TmIQoB548= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726035AbfBJMY1 (ORCPT ); Sun, 10 Feb 2019 07:24:27 -0500 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:42567 "EHLO wout2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726032AbfBJMY1 (ORCPT ); Sun, 10 Feb 2019 07:24:27 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 08EE62038; Sun, 10 Feb 2019 07:24:24 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 10 Feb 2019 07:24:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=DDRIm9 He7INnP/dqg6+vYKHJYKMs0HAGcPrqAVp43/g=; b=7gkV0esCKqj/Jj0Z/VSZjz SLNmtlbMSgR9aD4s6WgJ3mLkKmfdaCshC5YuPiOW1pZJFVpEbw+/ZHzF0lJjSxXJ LPTl+cYfYUIn12htUiwteDnk/ZWvz9X0IVIvBBiBassuNxokQrQuRBbeHiexlV8g GGbIPYRfTpN1obZ8wBf8dRJ3x7WxaYO3yotK2SVWbuOZiCUXTK3s5OKMF4ojI8kX u869reVSJbqrCZ8k6Ue4sECjxLKafp1cXj6f33xsYEi6t/tkkBQG63z4TtWKsLRW 8nd1TTgg1IQlzWOntlC66v6N1gfZyepBd+uj74bL9I17NwPgvMcq+5QUv2o5Cilw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleeigdegtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefuvffhfffkgggtgfesthekredttddtlfenucfhrhhomhepoehgrh gvghhkhheslhhinhhugihfohhunhgurghtihhonhdrohhrgheqnecukfhppeekfedrkeei rdekledruddtjeenucfrrghrrghmpehmrghilhhfrhhomhepghhrvghgsehkrhhorghhrd gtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost (5356596b.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) by mail.messagingengine.com (Postfix) with ESMTPA id 211BBE4068; Sun, 10 Feb 2019 07:24:24 -0500 (EST) Subject: FAILED: patch "[PATCH] xfs: eof trim writeback mapping as soon as it is cached" failed to apply to 4.9-stable tree To: bfoster@redhat.com, allison.henderson@oracle.com, darrick.wong@oracle.com, hch@lst.de, stable@vger.kernel.org Cc: From: Date: Sun, 10 Feb 2019 13:24:22 +0100 Message-ID: <1549801462161212@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From aa6ee4ab69293969867ab09b57546d226ace3d7a Mon Sep 17 00:00:00 2001 From: Brian Foster Date: Fri, 1 Feb 2019 09:36:36 -0800 Subject: [PATCH] xfs: eof trim writeback mapping as soon as it is cached The cached writeback mapping is EOF trimmed to try and avoid races between post-eof block management and writeback that result in sending cached data to a stale location. The cached mapping is currently trimmed on the validation check, which leaves a race window between the time the mapping is cached and when it is trimmed against the current inode size. For example, if a new mapping is cached by delalloc conversion on a blocksize == page size fs, we could cycle various locks, perform memory allocations, etc. in the writeback codepath before the associated mapping is eventually trimmed to i_size. This leaves enough time for a post-eof truncate and file append before the cached mapping is trimmed. The former event essentially invalidates a range of the cached mapping and the latter bumps the inode size such the trim on the next writepage event won't trim all of the invalid blocks. fstest generic/464 reproduces this scenario occasionally and causes a lost writeback and stale delalloc blocks warning on inode inactivation. To work around this problem, trim the cached writeback mapping as soon as it is cached in addition to on subsequent validation checks. This is a minor tweak to tighten the race window as much as possible until a proper invalidation mechanism is available. Fixes: 40214d128e07 ("xfs: trim writepage mapping to within eof") Cc: # v4.14+ Signed-off-by: Brian Foster Reviewed-by: Allison Henderson Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index 338b9d9984e0..d9048bcea49c 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -449,6 +449,7 @@ xfs_map_blocks( } wpc->imap = imap; + xfs_trim_extent_eof(&wpc->imap, ip); trace_xfs_map_blocks_found(ip, offset, count, wpc->io_type, &imap); return 0; allocate_blocks: @@ -459,6 +460,7 @@ xfs_map_blocks( ASSERT(whichfork == XFS_COW_FORK || cow_fsb == NULLFILEOFF || imap.br_startoff + imap.br_blockcount <= cow_fsb); wpc->imap = imap; + xfs_trim_extent_eof(&wpc->imap, ip); trace_xfs_map_blocks_alloc(ip, offset, count, wpc->io_type, &imap); return 0; }