From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:44060 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752367AbcFNWCw (ORCPT ); Tue, 14 Jun 2016 18:02:52 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2A8492AFE for ; Tue, 14 Jun 2016 22:02:52 +0000 (UTC) From: "Benjamin Marzinski" To: linux-fsdevel Cc: cluster-devel Subject: [PATCH 0/2] fix gfs2 truncate race Date: Tue, 14 Jun 2016 17:02:47 -0500 Message-Id: <1465941769-25596-1-git-send-email-bmarzins@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: If gfs2 tries to write out a page of a file with data journaling enabled, while that file is being truncated, it can cause a kernel panic. The problem is that the page it is writing out may point to past the end of the file. If this happens, gfs2 will try to invalidate the page. However, it can't invalidate a journaled page with buffers in the in-memory log, without revoking those buffers, so that there is no chance of corruption if the machine crashes and later has its journal replayed. If the page is being written out by the log flush code, there is no way that it can add a revoke entry onto the log during the flush. To solve this, gfs2 simply writes out journalled data pages that point past the end of the file, since the truncate is still in progress, and everything will be cleaned up before the file is unlocked, or the blocks are marked free. Doing this involves both a gfs2 change and exporting an additional symbol from the vfs. Benjamin Marzinski (2): fs: export __block_write_full_page gfs2: writeout truncated pages fs/buffer.c | 3 ++- fs/gfs2/aops.c | 37 +++++++++++++++++++++++++++---------- include/linux/buffer_head.h | 3 +++ 3 files changed, 32 insertions(+), 11 deletions(-) -- 1.8.3.1