public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Kiernan <alex.kiernan@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: akpm@osdl.org, viro@ZenII.linux.org.uk
Subject: Re: Submitting patches for unmaintained areas (Solaris x86 UFS bug)
Date: Wed, 13 Oct 2004 13:10:10 +0100	[thread overview]
Message-ID: <c461c0d104101305103792ad7a@mail.gmail.com> (raw)
In-Reply-To: <c461c0d10410130406714fafe3@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Wed, 13 Oct 2004 12:06:29 +0100, Alex Kiernan <alex.kiernan@gmail.com> wrote:
> I've run into a bug in the UFS reading code (on Solaris x86 the
> major/minor numbers are in 2nd indirect offset not the first), so I've
> patched it & bugzilled it
> (http://bugzilla.kernel.org/show_bug.cgi?id=3475).
> 
> But where do I go from here? There doesn't seem to be a maintainer for
> UFS so I can't send it there.
> 

After advice from Alan (thanks), here's the patch which addresses the
problem I'm seeing. Specifically it appears that on x86 Solaris stores
the major/minor device numbers in the 2nd indirect block, not the
first.

-- 
Alex Kiernan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ufs.solx86.diff --]
[-- Type: text/x-patch; name="ufs.solx86.diff", Size: 2152 bytes --]

===== namei.c 1.24 vs edited =====
--- 1.24/fs/ufs/namei.c	2004-03-12 09:30:20 +00:00
+++ edited/namei.c	2004-09-27 16:52:58 +01:00
@@ -30,6 +30,7 @@
 #include <linux/smp_lock.h>
 #include <linux/buffer_head.h>
 #include "swab.h"	/* will go away - see comment in mknod() */
+#include "util.h"
 
 /*
 #undef UFS_NAMEI_DEBUG
@@ -125,8 +126,8 @@
 	if (!IS_ERR(inode)) {
 		init_special_inode(inode, mode, rdev);
 		/* NOTE: that'll go when we get wide dev_t */
-		UFS_I(inode)->i_u1.i_data[0] = cpu_to_fs32(inode->i_sb,
-							old_encode_dev(rdev));
+		ufs_set_inode_dev(inode->i_sb, UFS_I(inode),
+			old_encode_dev(rdev));
 		mark_inode_dirty(inode);
 		lock_kernel();
 		err = ufs_add_nondir(dentry, inode);
===== inode.c 1.24 vs edited =====
--- 1.24/fs/ufs/inode.c	2004-09-17 07:58:42 +01:00
+++ edited/inode.c	2004-09-27 16:50:47 +01:00
@@ -629,7 +629,7 @@
 		}
 	} else
 		init_special_inode(inode, inode->i_mode,
-			old_decode_dev(fs32_to_cpu(sb, ufsi->i_u1.i_data[0])));
+			old_decode_dev(ufs_get_inode_dev(sb, ufsi)));
 
 	brelse (bh);
 
@@ -705,7 +705,7 @@
 		}
 	} else   /* TODO  : here ...*/
 		init_special_inode(inode, inode->i_mode,
-			old_decode_dev(fs32_to_cpu(sb, ufsi->i_u1.i_data[0])));
+			old_decode_dev(ufs_get_inode_dev(sb, ufsi)));
 
 	brelse(bh);
 
===== util.h 1.9 vs edited =====
--- 1.9/fs/ufs/util.h	2004-03-12 09:30:20 +00:00
+++ edited/util.h	2004-09-27 16:49:21 +01:00
@@ -223,6 +223,24 @@
 	inode->ui_u1.oldids.ui_sgid =  cpu_to_fs16(sb, value);
 }
 
+static inline u32
+ufs_get_inode_dev(struct super_block *sb, struct ufs_inode_info *inode)
+{
+	if ((UFS_SB(sb)->s_flags & UFS_ST_MASK) == UFS_ST_SUNx86)
+		return fs32_to_cpu(sb, ufsi->i_u1.i_data[1]);
+	else
+		return fs32_to_cpu(sb, ufsi->i_u1.i_data[0]);
+}
+
+static inline void
+ufs_set_inode_dev(struct super_block *sb, struct ufs_inode_info *inode, u32 value)
+{
+	if ((UFS_SB(sb)->s_flags & UFS_ST_MASK) == UFS_ST_SUNx86)
+		ufsi->i_u1.i_data[1] = cpu_to_fs32(sb, value);
+	else
+		ufsi->i_u1.i_data[0] = cpu_to_fs32(sb, value);
+}
+
 
 /*
  * These functions manipulate ufs buffers

  reply	other threads:[~2004-10-13 12:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-13 11:06 Submitting patches for unmaintained areas (Solaris x86 UFS bug) Alex Kiernan
2004-10-13 12:10 ` Alex Kiernan [this message]
2004-10-13 13:43   ` viro
2004-10-15 16:35     ` Alex Kiernan
2004-10-18 10:20       ` Alex Kiernan
2004-10-19  8:21         ` Alex Kiernan
2004-10-13 12:19 ` Haroldo Gamal
2004-10-13 15:05   ` Randy.Dunlap
2004-10-14 11:16     ` Haroldo Gamal
2004-10-14 15:15       ` Randy.Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c461c0d104101305103792ad7a@mail.gmail.com \
    --to=alex.kiernan@gmail.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ZenII.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox