From patchwork Tue Mar 24 15:35:49 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom Van Braeckel X-Patchwork-Id: 6080731 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 36CA7BF90F for ; Tue, 24 Mar 2015 15:36:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 49E3C201EC for ; Tue, 24 Mar 2015 15:36:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4A56C201E4 for ; Tue, 24 Mar 2015 15:36:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752747AbbCXPgR (ORCPT ); Tue, 24 Mar 2015 11:36:17 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:36353 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752261AbbCXPgP (ORCPT ); Tue, 24 Mar 2015 11:36:15 -0400 Received: by wibg7 with SMTP id g7so78086326wib.1; Tue, 24 Mar 2015 08:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=YiSCfu3MIRxsKJJYMRch9vgdZb73aCllkD8SOxIrQFw=; b=u6WQKi/hBnjSpYEjHVHji49uuri3Ksx0sEadhsqReaiuygRKva9tJeJcgTeyJoupFH 1JlLtsbNMZWDWLsG5ggJbKbl0QtTmKb5+gWSXSyXVuj3hQuzMKc2Nb6CHgXjeuYK89Ly yjPiHtmk5WnbaIvg5kzY8i0/R3vgZM42MQ70WQh0xa6M6CA6pbz1r5OG7tuZ4kRKNWpq scT5y1y/EShIcicieFr6rjxiKZsdxVMDF9B/iaA1SUxup6AhNkj0uvX4czRRQJRk10dj FJPy8bCL2Gw8E7vbT2Li4hxGk6xOdqU8g27Ync3449xGDOD1iptw29WQ6ipjp8Wd1c50 Uc2w== X-Received: by 10.180.189.69 with SMTP id gg5mr29229342wic.93.1427211373709; Tue, 24 Mar 2015 08:36:13 -0700 (PDT) Received: from mars.example.org (ip-83-101-72-4.customer.schedom-europe.net. [83.101.72.4]) by mx.google.com with ESMTPSA id hl15sm16418708wib.3.2015.03.24.08.36.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Mar 2015 08:36:12 -0700 (PDT) From: Tom Van Braeckel To: clm@fb.com, jbacik@fb.com, dsterba@suse.cz, linux-btrfs@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Tom Van Braeckel , Martin Kepplinger Subject: [PATCH v2] btrfs: explicitly set control file's private_data Date: Tue, 24 Mar 2015 16:35:49 +0100 Message-Id: <1427211349-8621-1-git-send-email-tomvanbraeckel@gmail.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <20150324140155.GU20767@twin.jikos.cz> References: <20150324140155.GU20767@twin.jikos.cz> Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The private_data member of the Btrfs control device file (/dev/btrfs-control) is used to hold the current transaction and needs to be initialized to NULL to signify that no transaction is in progress. We explicitly set the control file's private_data to NULL to be independent of whatever value the misc subsystem initializes it to. Backstory: ---------- The misc subsystem (which is used by /dev/btrfs-control) initializes a file's private_data to point to the misc device when a driver has registered a custom open file operation and initializes it to NULL when a custom open file operation has *not* been provided. This subtle quirk is confusing, to the point where kernel code registers *empty* file open operations to have private_data point to the misc device structure. And it leads to bugs, where the addition or removal of a custom open file operation surprisingly changes the initial contents of a file's private_data structure. To simplify things in the misc subsystem, a patch [1] has been proposed to *always* set private_data to point to the misc device instead of only doing this when a custom open file operation has been registered. But before we can fix this in the misc subsystem itself, we need to modify the (few) drivers that rely on this very subtle behavior. [1] https://lkml.org/lkml/2014/12/4/939 Signed-off-by: Martin Kepplinger Signed-off-by: Tom Van Braeckel --- fs/btrfs/super.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 05fef19..3c30195 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -1908,6 +1908,17 @@ static struct file_system_type btrfs_fs_type = { }; MODULE_ALIAS_FS("btrfs"); +static int btrfs_control_open(struct inode *inode, struct file *file) +{ + /* + * The control file's private_data is used to hold the + * transaction when it is started and is used to keep + * track of whether a transaction is already in progress. + */ + file->private_data = NULL; + return 0; +} + /* * used by btrfsctl to scan devices when no FS is mounted */ @@ -2009,6 +2020,7 @@ static const struct super_operations btrfs_super_ops = { }; static const struct file_operations btrfs_ctl_fops = { + .open = btrfs_control_open, .unlocked_ioctl = btrfs_control_ioctl, .compat_ioctl = btrfs_control_ioctl, .owner = THIS_MODULE,