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=-8.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,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 DA89BC433DF for ; Fri, 19 Jun 2020 08:31:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B61A7214F1 for ; Fri, 19 Jun 2020 08:31:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592555477; bh=QQXFZXnpJpngYW/pGhmCl4XvPE64YPbRdfTvgqFegpE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=T1N9rSpv/IvxlscM8FF9H/ClQ2+TPh7qVhNRGWtPVye334jw9Sdj+Gtgm1oHhqFmd QvOcrOln9n1rD8HjMC0QX3fun/e9AmbfFudBcg7wZ/7Z06+SXibyqN39Ys/i9fnOWk GckBK0tR4lHvjbWgySK/xvtUxMY7OihRb5iiUJa8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731507AbgFSIbQ (ORCPT ); Fri, 19 Jun 2020 04:31:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:52620 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731495AbgFSIbM (ORCPT ); Fri, 19 Jun 2020 04:31:12 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BEDE320890; Fri, 19 Jun 2020 08:31:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592555471; bh=QQXFZXnpJpngYW/pGhmCl4XvPE64YPbRdfTvgqFegpE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qffqWBqze3+tVQ1lpAhJbh46jVGC/jbS262duJGU1DBaI71oret6XYIdkkt4nhGEC 6rousjyX19uJy2TDUSp1ndsDbxXbvEDssrLpbLHoXeVX2j8csCYlXJXpJRkGqVEJiS bo9ulU1o+3IbJEZWoeG+jxmsNzDYJuCWPAz24qGQ= Date: Fri, 19 Jun 2020 10:11:13 +0200 From: Greg KH To: Sasha Levin Cc: mpdesouza@suse.com, dsterba@suse.com, fdmanana@suse.com, stable@vger.kernel.org Subject: Re: FAILED: patch "[PATCH] btrfs: send: emit file capabilities after chown" failed to apply to 4.4-stable tree Message-ID: <20200619081113.GA73176@kroah.com> References: <1592491523186218@kroah.com> <20200619011951.GU1931@sasha-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200619011951.GU1931@sasha-vm> Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, Jun 18, 2020 at 09:19:51PM -0400, Sasha Levin wrote: > On Thu, Jun 18, 2020 at 04:45:23PM +0200, gregkh@linuxfoundation.org wrote: > > > > 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 89efda52e6b6930f80f5adda9c3c9edfb1397191 Mon Sep 17 00:00:00 2001 > > From: Marcos Paulo de Souza > > Date: Sun, 10 May 2020 23:15:07 -0300 > > Subject: [PATCH] btrfs: send: emit file capabilities after chown > > > > Whenever a chown is executed, all capabilities of the file being touched > > are lost. When doing incremental send with a file with capabilities, > > there is a situation where the capability can be lost on the receiving > > side. The sequence of actions bellow shows the problem: > > > > $ mount /dev/sda fs1 > > $ mount /dev/sdb fs2 > > > > $ touch fs1/foo.bar > > $ setcap cap_sys_nice+ep fs1/foo.bar > > $ btrfs subvolume snapshot -r fs1 fs1/snap_init > > $ btrfs send fs1/snap_init | btrfs receive fs2 > > > > $ chgrp adm fs1/foo.bar > > $ setcap cap_sys_nice+ep fs1/foo.bar > > > > $ btrfs subvolume snapshot -r fs1 fs1/snap_complete > > $ btrfs subvolume snapshot -r fs1 fs1/snap_incremental > > > > $ btrfs send fs1/snap_complete | btrfs receive fs2 > > $ btrfs send -p fs1/snap_init fs1/snap_incremental | btrfs receive fs2 > > > > At this point, only a chown was emitted by "btrfs send" since only the > > group was changed. This makes the cap_sys_nice capability to be dropped > > from fs2/snap_incremental/foo.bar > > > > To fix that, only emit capabilities after chown is emitted. The current > > code first checks for xattrs that are new/changed, emits them, and later > > emit the chown. Now, __process_new_xattr skips capabilities, letting > > only finish_inode_if_needed to emit them, if they exist, for the inode > > being processed. > > > > This behavior was being worked around in "btrfs receive" side by caching > > the capability and only applying it after chown. Now, xattrs are only > > emmited _after_ chown, making that workaround not needed anymore. > > > > Link: https://github.com/kdave/btrfs-progs/issues/202 > > CC: stable@vger.kernel.org # 4.4+ > > Suggested-by: Filipe Manana > > Reviewed-by: Filipe Manana > > Signed-off-by: Marcos Paulo de Souza > > Signed-off-by: David Sterba > > I took 1ec9a1ae1e30 ("Btrfs: fix unreplayable log after snapshot delete > + parent dir fsync") to work around the conflict. Great, thanks for this fixup and the others you merged. greg k-h