From patchwork Fri Nov 30 03:40:08 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Brandenburger X-Patchwork-Id: 1823491 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 7E7C83FC23 for ; Fri, 30 Nov 2012 03:41:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754709Ab2K3Dky (ORCPT ); Thu, 29 Nov 2012 22:40:54 -0500 Received: from mail-oa0-f74.google.com ([209.85.219.74]:40945 "EHLO mail-oa0-f74.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754337Ab2K3Dkc (ORCPT ); Thu, 29 Nov 2012 22:40:32 -0500 Received: by mail-oa0-f74.google.com with SMTP id k14so10657oag.1 for ; Thu, 29 Nov 2012 19:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=/Uuo55bGhZJbp1fzmGAKoZIU9vzbUFxBE5ijDbcSyBc=; b=jnLnRYHZdu82yH7iqDT73N+PmSpC1zfG0Achw+UspXKyz+o9XW2kzYGObG2wf+kLhI /p6EiHKTQOKFsuLdjEisRXi4WVUP55KXG458C1aEkDARYx74yhmNs8fEZm4wrmLgr+tG sShSUS22A1IiSjFQJKFWSE90UbpDvuRWCXiJTWuUXTjliu6bSH306eERNRt3+MHpYNbW HcomTM74jh/DanrW1ZQ6yGq+wyYdHsj4ciC6IGO8a7CsQk0VoCqSeWafgSUPauO4kHlV 4ZvKbGig8Oa7M476YWfxOPMBWiK3RyF1ZM5mVK55FyCer2D4meTDbdIRbKhyRr/G0MSK vnUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references :x-gm-message-state; bh=/Uuo55bGhZJbp1fzmGAKoZIU9vzbUFxBE5ijDbcSyBc=; b=MIqjoC7szzKTNDKn44sdW9ISnFf88pd4nPnZ9/QRA93Y2JUK7XO7ssyD9mHqvUNFHH VwcXMolVSyPiYade1OZjD+FLlCRw3fBWpW269/LnssVgx2LWHuPYN+fG33coacRB6s93 dN19KG4vghRh0gCH9iQq/0rn5d1+vEQ71qA7G+ZjaLSzyjlSavYqR7LKV0f/bHWLzO4Y rF0V8sY6uhboHI3rJ4bp0UuPfmL1kGkA0WkRM1o+hvDXp0nWOZNbEt+dZxk667Ad8Vc3 oeC5m2Q32oDJV0lxtY722PaPu6ymAyQtreIobejOG2tvN6zw+o25au3g/a7TL7NswZar EtfA== Received: by 10.42.215.203 with SMTP id hf11mr10683569icb.17.1354246831142; Thu, 29 Nov 2012 19:40:31 -0800 (PST) Received: from wpzn4.hot.corp.google.com (216-239-44-65.google.com [216.239.44.65]) by gmr-mx.google.com with ESMTPS id o7si1089572igl.0.2012.11.29.19.40.31 (version=TLSv1/SSLv3 cipher=AES128-SHA); Thu, 29 Nov 2012 19:40:31 -0800 (PST) Received: from obelix.sbo.corp.google.com (obelix.sbo.corp.google.com [172.31.172.210]) by wpzn4.hot.corp.google.com (Postfix) with ESMTP id BBD8E82004A; Thu, 29 Nov 2012 19:40:30 -0800 (PST) Received: by obelix.sbo.corp.google.com (Postfix, from userid 180819) id 43A15200D59; Thu, 29 Nov 2012 19:40:30 -0800 (PST) From: Filipe Brandenburger To: Chris Mason , linux-btrfs@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Filipe Brandenburger Subject: [PATCH 1/2] Btrfs: fix permissions of empty files not affected by umask Date: Thu, 29 Nov 2012 19:40:08 -0800 Message-Id: <1354246809-32339-2-git-send-email-filbranden@google.com> X-Mailer: git-send-email 1.7.7.3 In-Reply-To: <1354246809-32339-1-git-send-email-filbranden@google.com> References: <1354246809-32339-1-git-send-email-filbranden@google.com> X-Gm-Message-State: ALoCoQmqIzFtF26pck3Cq4feO0kheOmIZ6B9yz/0Mw+taCweLJ7ya7X32YkUDBPYTWStcnNrGvvLf6MMUEiQR7/rtQEwJJgUvL3yl9yquOb7P/iVQcdrbuqWy8MYj3nNzr+hMcxQ8jesyxBiJknUNLl2DVURjcbhO2vd9sfje2yWShMSX8CAX8p+rZGu/QgecH4V2CBoLGnrxMhFRIlcQmSjsKg3uxZ5KA== Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org When a new file is created with btrfs_create(), the inode will initially be created with permissions 0666 and later on in btrfs_init_acl() it will be adapted to mask out the umask bits. The problem is that this change won't make it into the btrfs_inode unless there's another change to the inode (e.g. writing content changing the size or touching the file changing the mtime.) This fix adds a call to btrfs_update_inode() to btrfs_create() to make sure that the change will not get lost if the in-memory inode is flushed before other changes are made to the file. Signed-off-by: Filipe Brandenburger Reviewed-by: Liu Bo --- fs/btrfs/inode.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 95542a1..caf9d76 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -4996,6 +4996,12 @@ static int btrfs_create(struct inode *dir, struct dentry *dentry, goto out_unlock; } + err = btrfs_update_inode(trans, root, inode); + if (err) { + drop_inode = 1; + goto out_unlock; + } + /* * If the active LSM wants to access the inode during * d_instantiate it needs these. Smack checks to see