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 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 97DC0C43387 for ; Tue, 15 Jan 2019 15:42:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6679420645 for ; Tue, 15 Jan 2019 15:42:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547566949; bh=fIg/ly24rYtBBbqgDOd/7zDhC4kdwKAUGG9A58YHBfo=; h=Subject:To:Cc:From:Date:List-ID:From; b=U3Uz8PKJPBq6VPlDUsp0NhHWB7Wp+TIN1T3xeaUkcf0OrJLtv1R3CSuEvEFyuGUsG 1BDhV71E3XsOXvRqwQZjDjhM+i2uIW+qj84jOlXbzCvze+2GXx7cfTWZoUH4ALoA9C yqgChGr/azXfPgb9WWEj+Aci65fwUWh3sQe1rT1Q= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729721AbfAOPm3 (ORCPT ); Tue, 15 Jan 2019 10:42:29 -0500 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:50205 "EHLO new3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729477AbfAOPm2 (ORCPT ); Tue, 15 Jan 2019 10:42:28 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id CA28A68C6; Tue, 15 Jan 2019 10:42:27 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 15 Jan 2019 10:42:27 -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=aP/fCr 5hhQstjKOZh3mq87OGU4yarXM20PXLqpTQL5w=; b=roqsvAqDMHRKd9CcYe+GDF aQN7IbUOUpt8ZHTrOxbUdV449bcg0QvVPwrz+8WeEmIVoH0o6hLNg/viThe9JBfK x/MmE2gyZb7yiT003UVpoFEXaIHHzPpqhw5vJf5vh1ga+NwAu6B9RmKiE5lj2qeZ WpAu1guO2xEdzNU69vAWzdkn9GLM0b++QKStopKI/mzrnVeUNZ+t483Oz+FQeHQ1 y3UcGbPWSqv6O9oHeQdmpParE9ph6i3BWsCuTMKVBqAlGquf5IB/6nclp73pUjrW I+r1NQDgF0X9q34/uCH+gLfcdrErMJBT5QeQ+oAlJFpz21nQNUPmNMLEKqiBxTpA == 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 39FECE462B; Tue, 15 Jan 2019 10:42:27 -0500 (EST) Subject: FAILED: patch "[PATCH] Btrfs: use nofs context when initializing security xattrs to" failed to apply to 4.9-stable tree To: fdmanana@suse.com, dsterba@suse.com, nborisov@suse.com Cc: From: Date: Tue, 15 Jan 2019 16:42:26 +0100 Message-ID: <1547566946102248@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 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; }