Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965025Ab2E0Bpj (ORCPT ); Sat, 26 May 2012 21:45:39 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:36607 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964826Ab2E0BJL (ORCPT ); Sat, 26 May 2012 21:09:11 -0400 Message-Id: <20120527010429.673256376@linuxfoundation.org> User-Agent: quilt/0.60-19.1 Date: Sun, 27 May 2012 10:05:05 +0900 From: Greg KH To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, Shaohua Li , NeilBrown Subject: [ 42/94] md: using GFP_NOIO to allocate bio for flush request In-Reply-To: <20120527010332.GA11170@kroah.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1315 Lines: 41 3.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Shaohua Li commit b5e1b8cee7ad58a15d2fa79bcd7946acb592602d upstream. A flush request is usually issued in transaction commit code path, so using GFP_KERNEL to allocate memory for flush request bio falls into the classic deadlock issue. This is suitable for any -stable kernel to which it applies as it avoids a possible deadlock. Signed-off-by: Shaohua Li Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman --- drivers/md/md.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -452,7 +452,7 @@ static void submit_flushes(struct work_s atomic_inc(&rdev->nr_pending); atomic_inc(&rdev->nr_pending); rcu_read_unlock(); - bi = bio_alloc_mddev(GFP_KERNEL, 0, mddev); + bi = bio_alloc_mddev(GFP_NOIO, 0, mddev); bi->bi_end_io = md_end_flush; bi->bi_private = rdev; bi->bi_bdev = rdev->bdev; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/