From patchwork Fri Apr 13 02:27:35 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shaohua Li X-Patchwork-Id: 152246 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 70829B7012 for ; Fri, 13 Apr 2012 12:27:47 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753023Ab2DMC1p (ORCPT ); Thu, 12 Apr 2012 22:27:45 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:64639 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750734Ab2DMC1o (ORCPT ); Thu, 12 Apr 2012 22:27:44 -0400 Received: by pbcun15 with SMTP id un15so3068800pbc.19 for ; Thu, 12 Apr 2012 19:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Nh8xLVmVv7gX6S5T3015OZpaejuBg/7TzVRKtHjnuB4=; b=chpnIQgnRz9McHxWR5yB+VYH4yXB9E3Gxq74LNKbRZ/AU1LH8BWng0twiahaDRAQxy nKM+BJ8Z7hd/cdASMJGnPyuTS1gSolwBjx1xDYLbcTGLyopLp3P9rXOJGdY2mKv6+z6S JEAxvv5puLbn2hLO+yzZNqD+XSYHaXggqbqa0KHsCRZoRzwieSkekc6QW5m2zwZ+KF+5 1Y6YeuMY4GATVaUC9r4cd+jRFWtYng6jSAEcDFEoYO1Mr56DtQwDe5FsD8fiM76YpAeN svcxLmW4lY01P2L5HZGGRyWsVJcD9P7mZZlVTIvkQWMp/OXXuJn/+ONjOSL7gIxjYHtF qQcQ== Received: by 10.68.219.200 with SMTP id pq8mr715296pbc.55.1334284063705; Thu, 12 Apr 2012 19:27:43 -0700 (PDT) Received: from Shaohua-Li.local ([101.224.3.227]) by mx.google.com with ESMTPS id qb10sm2802098pbb.75.2012.04.12.19.27.40 (version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 19:27:42 -0700 (PDT) Message-ID: <4F878F17.2030900@kernel.org> Date: Fri, 13 Apr 2012 10:27:35 +0800 From: Shaohua Li User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, tytso@mit.edu Subject: [RFC]jbd2: use GFP_NOFS for blkdev_issue_flush Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org flush request is issued in transaction commit code path, so looks using GFP_KERNEL to allocate memory for flush request bio falls into the classic deadlock issue. I saw btrfs and dm get it right, but ext4, xfs and md are using GFP_KERNEL, which makes me confused. Hoping filesystem developers clarify. Signed-off-by: Shaohua Li --- fs/jbd2/commit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux/fs/jbd2/commit.c =================================================================== --- linux.orig/fs/jbd2/commit.c 2012-04-13 09:57:51.785506925 +0800 +++ linux/fs/jbd2/commit.c 2012-04-13 09:58:29.585498773 +0800 @@ -723,7 +723,7 @@ start_journal_io: if (commit_transaction->t_need_data_flush && (journal->j_fs_dev != journal->j_dev) && (journal->j_flags & JBD2_BARRIER)) - blkdev_issue_flush(journal->j_fs_dev, GFP_KERNEL, NULL); + blkdev_issue_flush(journal->j_fs_dev, GFP_NOFS, NULL); /* Done it all: now write the commit record asynchronously. */ if (JBD2_HAS_INCOMPAT_FEATURE(journal, @@ -859,7 +859,7 @@ wait_for_iobuf: if (JBD2_HAS_INCOMPAT_FEATURE(journal, JBD2_FEATURE_INCOMPAT_ASYNC_COMMIT) && journal->j_flags & JBD2_BARRIER) { - blkdev_issue_flush(journal->j_dev, GFP_KERNEL, NULL); + blkdev_issue_flush(journal->j_dev, GFP_NOFS, NULL); } if (err)