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.8 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,URIBL_BLOCKED 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 D9B3EC43387 for ; Tue, 15 Jan 2019 15:42:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AB35220645 for ; Tue, 15 Jan 2019 15:42:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547566952; bh=GWPqXn0OLucJ5oCs6c9cHznzb97xukiiLJP/CprbLs4=; h=Subject:To:Cc:From:Date:List-ID:From; b=GkrZHhz5DsHzEfNfPvDFqTugI9mMcDJrhUGbcOe3lqMvP0gUVbL3LZlK8YbXjPgV9 p+C4umnsBWgSkT900z/pa1+WlQoV0yCB0hAUKN6Yk0zXFLLEgv2DvwqB6CMnRTlS87 jI5Q5mjOHgeSJwPjt0Tsrdd0Il7G5db6Bs4okG6I= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729723AbfAOPmc (ORCPT ); Tue, 15 Jan 2019 10:42:32 -0500 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:48607 "EHLO new3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729477AbfAOPmc (ORCPT ); Tue, 15 Jan 2019 10:42:32 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 137ED83D8; Tue, 15 Jan 2019 10:42:31 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 15 Jan 2019 10:42:31 -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=fm1; bh=qUAhRP RhLnLNUd3aLBvykH/uN5u0Zrhl1GdlgEeKnPE=; b=RTvECHaxLfyDVy5o9vUqdW aTX/dSn3jk19ZDHnHQbQtLyt8A3B/VbimAxMTmX3L507BXxBZlfRZObW+SzilC1b yYokAeHeHpWX6pfMSnBO758WLu7cmTBw0CvUsnRiNnqYltCG5kie0yulOHlNzlLG Sx/qcP9qzIRb6owAoH02WrS8tr7UGeD9XbwI9o/swHeFgkOQ4Zjiwt4b6dDoK/ww xkOPGx8S91+FsrWS6GMtedTS/4U2c2pzwAbBVJF3q0GtRm0YyTaM8d6cA380p3de 5XVU3yiu3/CxU02OsMUX6bDToxvtjHGc6/vtSh6tsu8wfcR00IyYLgHqJWo7vIWg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeefgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucgoufhprghmkfhpucdlfedttddmnecujfgurhepuffvhfffkfggtgfgsehtkeertd dttdflnecuhfhrohhmpeeoghhrvghgkhhhsehlihhnuhigfhhouhhnuggrthhiohhnrdho rhhgqeenucfkphepkeefrdekiedrkeelrddutdejnecurfgrrhgrmhepmhgrihhlfhhroh hmpehgrhgvgheskhhrohgrhhdrtghomhenucevlhhushhtvghrufhiiigvpedt 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 6ACA6102A0; Tue, 15 Jan 2019 10:42:30 -0500 (EST) Subject: FAILED: patch "[PATCH] Btrfs: use nofs context when initializing security xattrs to" failed to apply to 4.4-stable tree To: fdmanana@suse.com, dsterba@suse.com, nborisov@suse.com Cc: From: Date: Tue, 15 Jan 2019 16:42:29 +0100 Message-ID: <1547566949217214@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.4-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 827aa18e7b903c5ff3b3cd8fec328a99b1dbd411 Mon Sep 17 00:00:00 2001 From: Filipe Manana Date: Mon, 10 Dec 2018 17:53:35 +0000 Subject: [PATCH] Btrfs: use nofs context when initializing security xattrs to avoid deadlock When initializing the security xattrs, we are holding a transaction handle therefore we need to use a GFP_NOFS context in order to avoid a deadlock with reclaim in case it's triggered. Fixes: 39a27ec1004e8 ("btrfs: use GFP_KERNEL for xattr and acl allocations") Reviewed-by: Nikolay Borisov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba diff --git a/fs/btrfs/xattr.c b/fs/btrfs/xattr.c index ea78c3d6dcfc..f141b45ce349 100644 --- a/fs/btrfs/xattr.c +++ b/fs/btrfs/xattr.c @@ -11,6 +11,7 @@ #include #include #include +#include #include "ctree.h" #include "btrfs_inode.h" #include "transaction.h" @@ -422,9 +423,15 @@ static int btrfs_initxattrs(struct inode *inode, { const struct xattr *xattr; struct btrfs_trans_handle *trans = fs_info; + unsigned int nofs_flag; char *name; int err = 0; + /* + * We're holding a transaction handle, so use a NOFS memory allocation + * context to avoid deadlock if reclaim happens. + */ + nofs_flag = memalloc_nofs_save(); for (xattr = xattr_array; xattr->name != NULL; xattr++) { name = kmalloc(XATTR_SECURITY_PREFIX_LEN + strlen(xattr->name) + 1, GFP_KERNEL); @@ -440,6 +447,7 @@ static int btrfs_initxattrs(struct inode *inode, if (err < 0) break; } + memalloc_nofs_restore(nofs_flag); return err; }