summaryrefslogtreecommitdiffstats
path: root/hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch
diff options
context:
space:
mode:
authorJosh Boyer <jwboyer@redhat.com>2012-04-18 14:10:02 -0400
committerJosh Boyer <jwboyer@redhat.com>2012-04-18 14:11:56 -0400
commit7f6230e25d2c047e578ed90d0f4060bce085ad8b (patch)
treedd99393f2389efd67af0586fbdddf846a3bd8dfd /hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch
parenta710a7d7ce54cd18fe8c182ff7150b440ece2d0f (diff)
downloadkernel-7f6230e25d2c047e578ed90d0f4060bce085ad8b.tar.gz
kernel-7f6230e25d2c047e578ed90d0f4060bce085ad8b.tar.xz
kernel-7f6230e25d2c047e578ed90d0f4060bce085ad8b.zip
Fix hfsplus bless ioctl with hardlinks (from Matthew Garrett)
Diffstat (limited to 'hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch')
-rw-r--r--hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch100
1 files changed, 100 insertions, 0 deletions
diff --git a/hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch b/hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch
new file mode 100644
index 000000000..3e0b4a5c7
--- /dev/null
+++ b/hfsplus-Fix-bless-ioctl-when-used-with-hardlinks.patch
@@ -0,0 +1,100 @@
+Path: news.gmane.org!not-for-mail
+From: Matthew Garrett <mjg@redhat.com>
+Newsgroups: gmane.linux.kernel,gmane.linux.file-systems
+Subject: [PATCH V2] hfsplus: Fix bless ioctl when used with hardlinks
+Date: Mon, 16 Apr 2012 16:57:18 -0400
+Lines: 45
+Approved: news@gmane.org
+Message-ID: <1334609838-14831-1-git-send-email-mjg@redhat.com>
+NNTP-Posting-Host: plane.gmane.org
+X-Trace: dough.gmane.org 1334609870 7622 80.91.229.3 (16 Apr 2012 20:57:50 GMT)
+X-Complaints-To: usenet@dough.gmane.org
+NNTP-Posting-Date: Mon, 16 Apr 2012 20:57:50 +0000 (UTC)
+Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
+ Matthew Garrett <mjg@redhat.com>
+To: hch@infradead.org
+Original-X-From: linux-kernel-owner@vger.kernel.org Mon Apr 16 22:57:49 2012
+Return-path: <linux-kernel-owner@vger.kernel.org>
+Envelope-to: glk-linux-kernel-3@plane.gmane.org
+Original-Received: from vger.kernel.org ([209.132.180.67])
+ by plane.gmane.org with esmtp (Exim 4.69)
+ (envelope-from <linux-kernel-owner@vger.kernel.org>)
+ id 1SJszc-0006G8-Gd
+ for glk-linux-kernel-3@plane.gmane.org; Mon, 16 Apr 2012 22:57:48 +0200
+Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
+ id S1755330Ab2DPU5g (ORCPT <rfc822;glk-linux-kernel-3@m.gmane.org>);
+ Mon, 16 Apr 2012 16:57:36 -0400
+Original-Received: from mx1.redhat.com ([209.132.183.28]:44295 "EHLO mx1.redhat.com"
+ rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
+ id S1752969Ab2DPU5e (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
+ Mon, 16 Apr 2012 16:57:34 -0400
+Original-Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
+ by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3GKvQoA029518
+ (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
+ Mon, 16 Apr 2012 16:57:26 -0400
+Original-Received: from cavan.codon.org.uk (ovpn-113-122.phx2.redhat.com [10.3.113.122])
+ by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3GKvP1p017146
+ (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
+ Mon, 16 Apr 2012 16:57:26 -0400
+Original-Received: from nat-pool-rdu.redhat.com ([66.187.233.202] helo=x220.boston.devel.redhat.com)
+ by cavan.codon.org.uk with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
+ (Exim 4.72)
+ (envelope-from <mjg@redhat.com>)
+ id 1SJszC-0003jY-P9; Mon, 16 Apr 2012 21:57:23 +0100
+X-SA-Do-Not-Run: Yes
+X-SA-Exim-Connect-IP: 66.187.233.202
+X-SA-Exim-Mail-From: mjg@redhat.com
+X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false
+X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
+Original-Sender: linux-kernel-owner@vger.kernel.org
+Precedence: bulk
+List-ID: <linux-kernel.vger.kernel.org>
+X-Mailing-List: linux-kernel@vger.kernel.org
+Xref: news.gmane.org gmane.linux.kernel:1282933 gmane.linux.file-systems:63394
+Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/1282933>
+
+HFS+ doesn't really implement hard links - instead, hardlinks are indicated
+by a magic file type which refers to an indirect node in a hidden
+directory. The spec indicates that stat() should return the inode number
+of the indirect node, but it turns out that this doesn't satisfy the
+firmware when it's looking for a bootloader - it wants the catalog ID of
+the hardlink file instead. Fix up this case.
+
+Signed-off-by: Matthew Garrett <mjg@redhat.com>
+---
+
+V2 cleans up the casting.
+
+ fs/hfsplus/ioctl.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/fs/hfsplus/ioctl.c b/fs/hfsplus/ioctl.c
+index c640ba5..09addc8 100644
+--- a/fs/hfsplus/ioctl.c
++++ b/fs/hfsplus/ioctl.c
+@@ -31,6 +31,7 @@ static int hfsplus_ioctl_bless(struct file *file, int __user *user_flags)
+ struct hfsplus_sb_info *sbi = HFSPLUS_SB(inode->i_sb);
+ struct hfsplus_vh *vh = sbi->s_vhdr;
+ struct hfsplus_vh *bvh = sbi->s_backup_vhdr;
++ u32 cnid = (unsigned long)dentry->d_fsdata;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+@@ -41,8 +42,12 @@ static int hfsplus_ioctl_bless(struct file *file, int __user *user_flags)
+ vh->finder_info[0] = bvh->finder_info[0] =
+ cpu_to_be32(parent_ino(dentry));
+
+- /* Bootloader */
+- vh->finder_info[1] = bvh->finder_info[1] = cpu_to_be32(inode->i_ino);
++ /*
++ * Bootloader. Just using the inode here breaks in the case of
++ * hard links - the firmware wants the ID of the hard link file,
++ * but the inode points at the indirect inode
++ */
++ vh->finder_info[1] = bvh->finder_info[1] = cpu_to_be32(cnid);
+
+ /* Per spec, the OS X system folder - same as finder_info[0] here */
+ vh->finder_info[5] = bvh->finder_info[5] =
+--
+1.7.10
+