* Submitting patches for unmaintained areas (Solaris x86 UFS bug)
@ 2004-10-13 11:06 Alex Kiernan
2004-10-13 12:10 ` Alex Kiernan
2004-10-13 12:19 ` Haroldo Gamal
0 siblings, 2 replies; 10+ messages in thread
From: Alex Kiernan @ 2004-10-13 11:06 UTC (permalink / raw)
To: linux-kernel
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.
--
Alex Kiernan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Submitting patches for unmaintained areas (Solaris x86 UFS bug)
2004-10-13 11:06 Submitting patches for unmaintained areas (Solaris x86 UFS bug) Alex Kiernan
@ 2004-10-13 12:10 ` Alex Kiernan
2004-10-13 13:43 ` viro
2004-10-13 12:19 ` Haroldo Gamal
1 sibling, 1 reply; 10+ messages in thread
From: Alex Kiernan @ 2004-10-13 12:10 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, viro
[-- 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Submitting patches for unmaintained areas (Solaris x86 UFS bug)
2004-10-13 11:06 Submitting patches for unmaintained areas (Solaris x86 UFS bug) Alex Kiernan
2004-10-13 12:10 ` Alex Kiernan
@ 2004-10-13 12:19 ` Haroldo Gamal
2004-10-13 15:05 ` Randy.Dunlap
1 sibling, 1 reply; 10+ messages in thread
From: Haroldo Gamal @ 2004-10-13 12:19 UTC (permalink / raw)
To: linux-kernel
I've done have done the same with
http://bugzilla.kernel.org/show_bug.cgi?id=3330 and I have the same
question!
Where do I go from now?
Haroldo Gamal
Alex Kiernan 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.
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Submitting patches for unmaintained areas (Solaris x86 UFS bug)
2004-10-13 12:10 ` Alex Kiernan
@ 2004-10-13 13:43 ` viro
2004-10-15 16:35 ` Alex Kiernan
0 siblings, 1 reply; 10+ messages in thread
From: viro @ 2004-10-13 13:43 UTC (permalink / raw)
To: Alex Kiernan; +Cc: linux-kernel, akpm, viro
On Wed, Oct 13, 2004 at 01:10:10PM +0100, Alex Kiernan wrote:
> 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.
1) please, move old_encode_dev()/old_decode_dev() into your helper functions.
2) we could do a bit better now that we have large dev_t. What are complete
rules for
a) Solaris userland dev_t => on-disk data
b) major/minor => Solaris userland dev_t
on sparc and x86 Solaris?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Submitting patches for unmaintained areas (Solaris x86 UFS bug)
2004-10-13 12:19 ` Haroldo Gamal
@ 2004-10-13 15:05 ` Randy.Dunlap
2004-10-14 11:16 ` Haroldo Gamal
0 siblings, 1 reply; 10+ messages in thread
From: Randy.Dunlap @ 2004-10-13 15:05 UTC (permalink / raw)
To: haroldo.gamal; +Cc: linux-kernel
Haroldo Gamal wrote:
> I've done have done the same with
> http://bugzilla.kernel.org/show_bug.cgi?id=3330 and I have the same
> question!
>
> Where do I go from now?
Have you tried contacting the SMBfs maintainer?
from the MAINTAINERS file:
SMB FILESYSTEM
P: Urban Widmark
M: urban@teststation.com
W: http://samba.org/
L: samba@samba.org
S: Maintained
--
~Randy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Submitting patches for unmaintained areas (Solaris x86 UFS bug)
2004-10-13 15:05 ` Randy.Dunlap
@ 2004-10-14 11:16 ` Haroldo Gamal
2004-10-14 15:15 ` Randy.Dunlap
0 siblings, 1 reply; 10+ messages in thread
From: Haroldo Gamal @ 2004-10-14 11:16 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: haroldo.gamal, linux-kernel
I have mailed Mr. Urban Widmark ans answered the appropriate bugzilla
bug - https://bugzilla.samba.org/show_bug.cgi?id=999. No response until now.
Maybe my patches do not apply for some reason, but I've got no response.
I would like to get some feedback.
Randy.Dunlap wrote:
> Haroldo Gamal wrote:
>
>> I've done have done the same with
>> http://bugzilla.kernel.org/show_bug.cgi?id=3330 and I have the same
>> question!
>>
>> Where do I go from now?
>
>
> Have you tried contacting the SMBfs maintainer?
> from the MAINTAINERS file:
>
> SMB FILESYSTEM
> P: Urban Widmark
> M: urban@teststation.com
> W: http://samba.org/
> L: samba@samba.org
> S: Maintained
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Submitting patches for unmaintained areas (Solaris x86 UFS bug)
2004-10-14 11:16 ` Haroldo Gamal
@ 2004-10-14 15:15 ` Randy.Dunlap
0 siblings, 0 replies; 10+ messages in thread
From: Randy.Dunlap @ 2004-10-14 15:15 UTC (permalink / raw)
To: Haroldo Gamal; +Cc: linux-kernel
Haroldo Gamal wrote:
> I have mailed Mr. Urban Widmark ans answered the appropriate bugzilla
> bug - https://bugzilla.samba.org/show_bug.cgi?id=999. No response until
> now.
>
> Maybe my patches do not apply for some reason, but I've got no response.
> I would like to get some feedback.
Hm, if he is unresponsive, you can try any of (in no special order):
a. VFS maintainer (Al Viro)
b. 2.6 maintainer (Andrew Morton)
c. linux-fsdevel@vger.kernel.org
d. samba@samba.org
> Randy.Dunlap wrote:
>
>> Haroldo Gamal wrote:
>>
>>> I've done have done the same with
>>> http://bugzilla.kernel.org/show_bug.cgi?id=3330 and I have the same
>>> question!
>>>
>>> Where do I go from now?
>>
>>
>>
>> Have you tried contacting the SMBfs maintainer?
>> from the MAINTAINERS file:
>>
>> SMB FILESYSTEM
>> P: Urban Widmark
>> M: urban@teststation.com
>> W: http://samba.org/
>> L: samba@samba.org
>> S: Maintained
--
~Randy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Submitting patches for unmaintained areas (Solaris x86 UFS bug)
2004-10-13 13:43 ` viro
@ 2004-10-15 16:35 ` Alex Kiernan
2004-10-18 10:20 ` Alex Kiernan
0 siblings, 1 reply; 10+ messages in thread
From: Alex Kiernan @ 2004-10-15 16:35 UTC (permalink / raw)
To: viro@parcelfarce.linux.theplanet.co.uk; +Cc: linux-kernel, akpm, viro
On Wed, 13 Oct 2004 14:43:51 +0100,
viro@parcelfarce.linux.theplanet.co.uk
<viro@parcelfarce.linux.theplanet.co.uk> wrote:
> On Wed, Oct 13, 2004 at 01:10:10PM +0100, Alex Kiernan wrote:
>
>
> > 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.
>
> 1) please, move old_encode_dev()/old_decode_dev() into your helper functions.
Will do.
> 2) we could do a bit better now that we have large dev_t. What are complete
> rules for
> a) Solaris userland dev_t => on-disk data
> b) major/minor => Solaris userland dev_t
> on sparc and x86 Solaris?
>
Assuming I've followed it right...
The kernel dev_t has 14 major device bits, 18 minor device bits (with
the major as the most significant bits).
On disk there are 32 bits stored in host byte order, the device is in
the [0] indirect offset on Sparc, [1] on x86.
Looking at an individual entry, if the top 16 bits are clear or
0xffff, then the bottom 16 bits are the device number, with 7 bits of
major (most significant), 8 bits of minor (and the most significant
bit unused). If the top 16 bits are some other pattern, the on disk
mapping is the same as the kernel mapping.
--
Alex Kiernan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Submitting patches for unmaintained areas (Solaris x86 UFS bug)
2004-10-15 16:35 ` Alex Kiernan
@ 2004-10-18 10:20 ` Alex Kiernan
2004-10-19 8:21 ` Alex Kiernan
0 siblings, 1 reply; 10+ messages in thread
From: Alex Kiernan @ 2004-10-18 10:20 UTC (permalink / raw)
To: viro@parcelfarce.linux.theplanet.co.uk; +Cc: linux-kernel, akpm, viro
[-- Attachment #1: Type: text/plain, Size: 2510 bytes --]
On Fri, 15 Oct 2004 17:35:50 +0100, Alex Kiernan <alex.kiernan@gmail.com> wrote:
> On Wed, 13 Oct 2004 14:43:51 +0100,
> viro@parcelfarce.linux.theplanet.co.uk
> <viro@parcelfarce.linux.theplanet.co.uk> wrote:
> > On Wed, Oct 13, 2004 at 01:10:10PM +0100, Alex Kiernan wrote:
> >
> >
> > > 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.
> >
> > 1) please, move old_encode_dev()/old_decode_dev() into your helper functions.
>
> Will do.
>
> > 2) we could do a bit better now that we have large dev_t. What are complete
> > rules for
> > a) Solaris userland dev_t => on-disk data
> > b) major/minor => Solaris userland dev_t
> > on sparc and x86 Solaris?
> >
>
> Assuming I've followed it right...
>
> The kernel dev_t has 14 major device bits, 18 minor device bits (with
> the major as the most significant bits).
>
> On disk there are 32 bits stored in host byte order, the device is in
> the [0] indirect offset on Sparc, [1] on x86.
>
> Looking at an individual entry, if the top 16 bits are clear or
> 0xffff, then the bottom 16 bits are the device number, with 7 bits of
> major (most significant), 8 bits of minor (and the most significant
> bit unused). If the top 16 bits are some other pattern, the on disk
> mapping is the same as the kernel mapping.
>
Attached is code to implement the code move of old_decode_dev and
support for large dev_t (Solaris' own handling of this seems to be
dodgy in the extreme). I've checked Solaris x86/sparc w/ both types of
dev_t encoding for reading. I haven't checked writing as the code to
detect clean filesystems seems to be bust for Solaris UFS filesystems.
I'll have a look at whats wrong w/ it when I've a bit more time.
Because of the different Solaris/Linux large dev encodings, what
should I be doing in get/set inode_dev when the required things won't
fit?
--
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: 3099 bytes --]
diff -xSCCS -x'*.cmd' -x'*.o' -ur linus-2.5/fs/ufs/inode.c linux-2.5/fs/ufs/inode.c
--- linus-2.5/fs/ufs/inode.c 2004-10-13 15:04:04.000000000 +0100
+++ linux-2.5/fs/ufs/inode.c 2004-10-13 15:44:05.000000000 +0100
@@ -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])));
+ 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])));
+ ufs_get_inode_dev(sb, ufsi));
brelse(bh);
diff -xSCCS -x'*.cmd' -x'*.o' -ur linus-2.5/fs/ufs/namei.c linux-2.5/fs/ufs/namei.c
--- linus-2.5/fs/ufs/namei.c 2004-10-13 15:04:04.000000000 +0100
+++ linux-2.5/fs/ufs/namei.c 2004-10-13 14:58:23.000000000 +0100
@@ -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,7 @@
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), rdev);
mark_inode_dirty(inode);
lock_kernel();
err = ufs_add_nondir(dentry, inode);
Only in linux-2.5/fs/ufs: ufs.ko
Only in linux-2.5/fs/ufs: ufs.mod.c
diff -xSCCS -x'*.cmd' -x'*.o' -ur linus-2.5/fs/ufs/util.h linux-2.5/fs/ufs/util.h
--- linus-2.5/fs/ufs/util.h 2004-10-13 15:04:04.000000000 +0100
+++ linux-2.5/fs/ufs/util.h 2004-10-18 11:12:52.002280119 +0100
@@ -223,6 +223,58 @@
inode->ui_u1.oldids.ui_sgid = cpu_to_fs16(sb, value);
}
+static inline dev_t
+ufs_get_inode_dev(struct super_block *sb, struct ufs_inode_info *ufsi)
+{
+ __fs32 fs32;
+ dev_t dev;
+
+ if ((UFS_SB(sb)->s_flags & UFS_ST_MASK) == UFS_ST_SUNx86)
+ fs32 = ufsi->i_u1.i_data[1];
+ else
+ fs32 = ufsi->i_u1.i_data[0];
+ fs32 = fs32_to_cpu(sb, fs32);
+ switch (UFS_SB(sb)->s_flags & UFS_ST_MASK) {
+ case UFS_ST_SUNx86:
+ case UFS_ST_SUN:
+ if ((fs32 & 0xffff0000) == 0 ||
+ (fs32 & 0xffff0000) == 0xffff0000)
+ dev = old_decode_dev(fs32 & 0x7fff);
+ else
+ dev = MKDEV(sysv_major(fs32), sysv_minor(fs32));
+ break;
+
+ default:
+ dev = old_decode_dev(fs32);
+ break;
+ }
+ return dev;
+}
+
+static inline void
+ufs_set_inode_dev(struct super_block *sb, struct ufs_inode_info *ufsi, dev_t dev)
+{
+ __fs32 fs32;
+
+ switch (UFS_SB(sb)->s_flags & UFS_ST_MASK) {
+ case UFS_ST_SUNx86:
+ case UFS_ST_SUN:
+ fs32 = sysv_encode_dev(dev);
+ if ((fs32 & 0xffff8000) == 0) {
+ fs32 = old_encode_dev(dev);
+ }
+ break;
+
+ default:
+ fs32 = old_encode_dev(dev);
+ break;
+ }
+ fs32 = cpu_to_fs32(sb, fs32);
+ if ((UFS_SB(sb)->s_flags & UFS_ST_MASK) == UFS_ST_SUNx86)
+ ufsi->i_u1.i_data[1] = fs32;
+ else
+ ufsi->i_u1.i_data[0] = fs32;
+}
/*
* These functions manipulate ufs buffers
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Submitting patches for unmaintained areas (Solaris x86 UFS bug)
2004-10-18 10:20 ` Alex Kiernan
@ 2004-10-19 8:21 ` Alex Kiernan
0 siblings, 0 replies; 10+ messages in thread
From: Alex Kiernan @ 2004-10-19 8:21 UTC (permalink / raw)
To: viro@parcelfarce.linux.theplanet.co.uk, linux-kernel, akpm, viro
[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]
On Mon, 18 Oct 2004 11:20:16 +0100, Alex Kiernan <alex.kiernan@gmail.com> wrote:
> On Fri, 15 Oct 2004 17:35:50 +0100, Alex Kiernan <alex.kiernan@gmail.com> wrote:
>
>
> > On Wed, 13 Oct 2004 14:43:51 +0100,
> > viro@parcelfarce.linux.theplanet.co.uk
> > <viro@parcelfarce.linux.theplanet.co.uk> wrote:
> > > On Wed, Oct 13, 2004 at 01:10:10PM +0100, Alex Kiernan wrote:
> > >
> > >
> > > > 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.
> > >
> > > 1) please, move old_encode_dev()/old_decode_dev() into your helper functions.
> >
> > Will do.
> >
> > > 2) we could do a bit better now that we have large dev_t. What are complete
> > > rules for
> > > a) Solaris userland dev_t => on-disk data
> > > b) major/minor => Solaris userland dev_t
> > > on sparc and x86 Solaris?
> > >
> >
> > Assuming I've followed it right...
> >
> > The kernel dev_t has 14 major device bits, 18 minor device bits (with
> > the major as the most significant bits).
> >
> > On disk there are 32 bits stored in host byte order, the device is in
> > the [0] indirect offset on Sparc, [1] on x86.
> >
> > Looking at an individual entry, if the top 16 bits are clear or
> > 0xffff, then the bottom 16 bits are the device number, with 7 bits of
> > major (most significant), 8 bits of minor (and the most significant
> > bit unused). If the top 16 bits are some other pattern, the on disk
> > mapping is the same as the kernel mapping.
> >
>
> Attached is code to implement the code move of old_decode_dev and
> support for large dev_t (Solaris' own handling of this seems to be
> dodgy in the extreme). I've checked Solaris x86/sparc w/ both types of
> dev_t encoding for reading. I haven't checked writing as the code to
> detect clean filesystems seems to be bust for Solaris UFS filesystems.
> I'll have a look at whats wrong w/ it when I've a bit more time.
>
The same functionality again:
Fix handling of device inodes on Solaris x86 filesystems, add support
for large dev_t against Solaris UFS filesystems
but with the helper functions moved out of inline code.
--
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: 3497 bytes --]
diff -xSCCS -x'*.cmd' -x'*.o' -ur linus-2.5/fs/ufs/inode.c linux-2.5/fs/ufs/inode.c
--- linus-2.5/fs/ufs/inode.c 2004-10-13 15:04:04.000000000 +0100
+++ linux-2.5/fs/ufs/inode.c 2004-10-13 15:44:05.000000000 +0100
@@ -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])));
+ 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])));
+ ufs_get_inode_dev(sb, ufsi));
brelse(bh);
diff -xSCCS -x'*.cmd' -x'*.o' -ur linus-2.5/fs/ufs/namei.c linux-2.5/fs/ufs/namei.c
--- linus-2.5/fs/ufs/namei.c 2004-10-13 15:04:04.000000000 +0100
+++ linux-2.5/fs/ufs/namei.c 2004-10-13 14:58:23.000000000 +0100
@@ -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,7 @@
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), rdev);
mark_inode_dirty(inode);
lock_kernel();
err = ufs_add_nondir(dentry, inode);
Only in linux-2.5/fs/ufs: ufs.ko
Only in linux-2.5/fs/ufs: ufs.mod.c
diff -xSCCS -x'*.cmd' -x'*.o' -ur linus-2.5/fs/ufs/util.c linux-2.5/fs/ufs/util.c
--- linus-2.5/fs/ufs/util.c 2004-10-13 15:04:04.000000000 +0100
+++ linux-2.5/fs/ufs/util.c 2004-10-19 04:48:20.000000000 +0100
@@ -202,3 +202,56 @@
bhno++;
}
}
+
+dev_t
+ufs_get_inode_dev(struct super_block *sb, struct ufs_inode_info *ufsi)
+{
+ __fs32 fs32;
+ dev_t dev;
+
+ if ((UFS_SB(sb)->s_flags & UFS_ST_MASK) == UFS_ST_SUNx86)
+ fs32 = ufsi->i_u1.i_data[1];
+ else
+ fs32 = ufsi->i_u1.i_data[0];
+ fs32 = fs32_to_cpu(sb, fs32);
+ switch (UFS_SB(sb)->s_flags & UFS_ST_MASK) {
+ case UFS_ST_SUNx86:
+ case UFS_ST_SUN:
+ if ((fs32 & 0xffff0000) == 0 ||
+ (fs32 & 0xffff0000) == 0xffff0000)
+ dev = old_decode_dev(fs32 & 0x7fff);
+ else
+ dev = MKDEV(sysv_major(fs32), sysv_minor(fs32));
+ break;
+
+ default:
+ dev = old_decode_dev(fs32);
+ break;
+ }
+ return dev;
+}
+
+void
+ufs_set_inode_dev(struct super_block *sb, struct ufs_inode_info *ufsi, dev_t dev)
+{
+ __fs32 fs32;
+
+ switch (UFS_SB(sb)->s_flags & UFS_ST_MASK) {
+ case UFS_ST_SUNx86:
+ case UFS_ST_SUN:
+ fs32 = sysv_encode_dev(dev);
+ if ((fs32 & 0xffff8000) == 0) {
+ fs32 = old_encode_dev(dev);
+ }
+ break;
+
+ default:
+ fs32 = old_encode_dev(dev);
+ break;
+ }
+ fs32 = cpu_to_fs32(sb, fs32);
+ if ((UFS_SB(sb)->s_flags & UFS_ST_MASK) == UFS_ST_SUNx86)
+ ufsi->i_u1.i_data[1] = fs32;
+ else
+ ufsi->i_u1.i_data[0] = fs32;
+}
diff -xSCCS -x'*.cmd' -x'*.o' -ur linus-2.5/fs/ufs/util.h linux-2.5/fs/ufs/util.h
--- linus-2.5/fs/ufs/util.h 2004-10-13 15:04:04.000000000 +0100
+++ linux-2.5/fs/ufs/util.h 2004-10-19 05:02:39.000000000 +0100
@@ -223,6 +223,8 @@
inode->ui_u1.oldids.ui_sgid = cpu_to_fs16(sb, value);
}
+extern dev_t ufs_get_inode_dev(struct super_block *, struct ufs_inode_info *);
+extern void ufs_set_inode_dev(struct super_block *, struct ufs_inode_info *, dev_t);
/*
* These functions manipulate ufs buffers
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2004-10-19 8:27 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-13 11:06 Submitting patches for unmaintained areas (Solaris x86 UFS bug) Alex Kiernan
2004-10-13 12:10 ` Alex Kiernan
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox