documented Oops running big-endian reiserfs on parisc architecture

documented Oops running big-endian reiserfs on parisc architecture

[thunder7]

Well, I watched the number of files in /lost+found grow every time I
had to pull the plug from my HP C200, so I added a 'sync' option in
/etc/fstab and tried to get reiserfs working.

I patched my 2.4.9-pa13 kernel with

endian-safe-reiserfs-for-2.4.8.patch

which went without warnings or errors. A patched
reiserfs-progs-3.x.0k-pre9 also built well (despite what the configure
scripts says, you _need_ automake).

Creating a reiserfs-partition went without a hitch.

running bonnie -s 128 on it did this:

Adding Swap: 1041400k swap-space (priority -1)
eth0: Setting half-duplex based on MII#1 link partner capability of 0021.
reiserfs: checking transaction log (device 08:03) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
bonnie[163]: Unaligned data reference 28

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001110
r0-3     00000000 102ec550 10197d0c 26f24838
r4-7     26f24848 27054e40 00000011 00000020
r8-11    0000000a 26f06580 00000020 26f247a0
r12-15   27088d1c ffffffff 26f24838 00000001
r16-19   26f24708 faf02c68 0006a248 26f24852
r20-23   0000000f 00000003 03000000 00000002
r24-27   0000000a 0000000a 26f24848 102d4010
r28-31   26f24848 01000000 26f24b40 10196fc8
sr0-3    00000000 00000004 00000000 00000004
sr4-7    00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 10197d10 10197d14
 IIR: 0c7c1093    ISR: 00000000  IOR: 26f24846
 ORIG_R28: 00000000
pa8200:/var/log#

After reading in the archives about ksymoops, I looked up this part of
my System.map:

101979e0 T reiserfs_lookup
101979e0 t .L1432
10197ad4 t reiserfs_add_entry
10197e50 t .L1512
10197f28 t .L1510
10198068 T reiserfs_create

objdump -d /boot/linux-2.4.9-pa13 revealed:

10197cbc:       d6 d6 0b 18     depw,z r22,7,8,r22
10197cc0:       d6 b5 0a 10     depw,z r21,15,16,r21
10197cc4:       41 33 01 fe     ldb ff(sr0,r9),r19
10197cc8:       0a d5 02 75     or r21,r22,r21
10197ccc:       d6 94 09 08     depw,z r20,23,24,r20
10197cd0:       0a b4 02 74     or r20,r21,r20
10197cd4:       0a 93 02 73     or r19,r20,r19
10197cd8:       d2 75 18 f8     extrw,u r19,7,8,r21
10197cdc:       d2 74 19 f8     extrw,u r19,15,8,r20
10197ce0:       0c 73 12 16     stb  r19,b(sr0,r3)
10197ce4:       d2 73 1a f8     extrw,u r19,23,8,r19
10197ce8:       0c 75 12 10     stb  r21,8(sr0,r3)
10197cec:       0c 74 12 12     stb  r20,9(sr0,r3)
10197cf0:       e8 86 a9 e4     b,l 102a51e8 <memcpy>,%r2
10197cf4:       0c 73 12 14     stb  r19,a(sr0,r3)
10197cf8:       08 06 02 59     copy r6,r25
10197cfc:       08 04 02 5a     copy r4,r26
10197d00:       d7 20 1c 1d     depwi 0,31,3,r25
10197d04:       e8 0d a5 d8     call 101b1ff8 <padd_item>
10197d08:       08 08 02 58     copy r8,r24
10197d0c:       00 01 0e 74     rsm 1,r20
10197d10:       0c 7c 10 93     ldw  e(sr0,r3),r19
10197d14:       d6 60 1f 1f     depwi 0,7,1,r19
10197d18:       0c 73 12 9c     stw  r19,e(sr0,r3)
10197d1c:       00 14 18 60     mtsm r20
10197d20:       85 e0 26 32     cmpib,=,n 0,r15,10198040 <.L1510+0x118>
10197d24:       00 01 0e 74     rsm 1,r20
10197d28:       0c 7c 10 93     ldw  e(sr0,r3),r19
10197d2c:       d6 7f 1f 5f     depwi -1,5,1,r19
10197d30:       0c 73 12 9c     stw  r19,e(sr0,r3)
10197d34:       00 14 18 60     mtsm r20
10197d38:       08 00 02 54     copy r0,r20
10197d3c:       08 00 02 55     copy r0,r21
10197d40:       37 c6 3e 51     ldo -d8(sp),r6
10197d44:       37 cd 3d c1     ldo -120(sp),r13
10197d48:       6b d4 3e 51     stw r20,-d8(sr0,sp)
10197d4c:       6b d5 3e 59     stw r21,-d4(sr0,sp)
10197d50:       6b d4 3e 61     stw r20,-d0(sr0,sp)
10197d54:       6b d5 3e 69     stw r21,-cc(sr0,sp)
10197d58:       08 0c 02 59     copy r12,r25
10197d5c:       6b c6 3e 01     stw r6,-100(sr0,sp)
10197d60:       6b cd 3f 99     stw r13,-34(sr0,sp)
10197d64:       08 08 02 58     copy r8,r24
10197d68:       08 05 02 5a     copy r5,r26
10197d6c:       eb ff b4 4d     b,l 10197798 <reiserfs_find_entry>,%r2

which makes the error somewhere around here in 
fs/reiserfs/namei.c, function reiserfs_add_entry, after call to
padd_item, before call to reiserfs_find_entry:

    /* copy name */
    memcpy ((char *)(deh + 1), name, namelen);
    /* padd by 0s to the 4 byte boundary */
    padd_item ((char *)(deh + 1), ROUND_UP (namelen), namelen);

    /* entry is ready to be pasted into tree, set 'visibility' and 'stat data in entry' attributes */
    mark_de_without_sd (deh);
    visible ? mark_de_visible (deh) : mark_de_hidden (deh);

    /* find the proper place for the new entry */
    memset (bit_string, 0, sizeof (bit_string));
    de.de_gen_number_bit_string = (char *)bit_string;
    retval = reiserfs_find_entry (dir, name, namelen, &path, &de);


And there I'm stuck. I'm sending this to the parisc-list to document the
failure, and to linux-kernel to reach some reiserfs-experts, perhaps.

I'm willing to test anything!

Good luck,
Jurriaan
-- 
"I have seen her. That is enough, perhaps."
Pug smiled. "You are a rare man."
	Raymond E Feist - The King's Buccaneer
GNU/Linux 2.4.9-ac5 SMP/ReiserFS 2x1402 bogomips load av: 0.04 0.01 0.06

Re: [parisc-linux] documented Oops running big-endian reiserfs on parisc architecture

[Matthew Wilcox]

On Sun, Sep 02, 2001 at 10:55:38AM +0200, thunder7@xs4all.nl wrote:
> ReiserFS version 3.6.25
> bonnie[163]: Unaligned data reference 28

As it says, an unaligned data reference.

> r0-3     00000000 102ec550 10197d0c 26f24838

> IASQ: 00000000 00000000 IAOQ: 10197d10 10197d14

In kernel mode.

> 10197d10:       0c 7c 10 93     ldw  e(sr0,r3),r19

r3 is 26f24838, and offset `e' from that is unaligned.

> which makes the error somewhere around here in 
> fs/reiserfs/namei.c, function reiserfs_add_entry, after call to
> padd_item, before call to reiserfs_find_entry:
> 
>     /* copy name */
>     memcpy ((char *)(deh + 1), name, namelen);
>     /* padd by 0s to the 4 byte boundary */
>     padd_item ((char *)(deh + 1), ROUND_UP (namelen), namelen);
> 
>     /* entry is ready to be pasted into tree, set 'visibility' and 'stat data in entry' attributes */
>     mark_de_without_sd (deh);
>     visible ? mark_de_visible (deh) : mark_de_hidden (deh);
> 
>     /* find the proper place for the new entry */
>     memset (bit_string, 0, sizeof (bit_string));
>     de.de_gen_number_bit_string = (char *)bit_string;
>     retval = reiserfs_find_entry (dir, name, namelen, &path, &de);

I suspect mark_de_without_sd is an inlined function/macro and this will
be where the unaligned data reference is happening.

-- 
Revolutions do not require corporate support.

[SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[thunder7]

On Sun, Sep 02, 2001 at 03:00:23PM +0100, Matthew Wilcox wrote:
> On Sun, Sep 02, 2001 at 10:55:38AM +0200, thunder7@xs4all.nl wrote:
> > ReiserFS version 3.6.25
> > bonnie[163]: Unaligned data reference 28
> 
> > which makes the error somewhere around here in 
> > fs/reiserfs/namei.c, function reiserfs_add_entry, after call to
> > padd_item, before call to reiserfs_find_entry:
> > 
> >     padd_item ((char *)(deh + 1), ROUND_UP (namelen), namelen);
> > 
> >     /* entry is ready to be pasted into tree, set 'visibility' and 'stat data in entry' attributes */
> >     mark_de_without_sd (deh);
> >     visible ? mark_de_visible (deh) : mark_de_hidden (deh);
> > 
> >     /* find the proper place for the new entry */
> >     memset (bit_string, 0, sizeof (bit_string));
> >     de.de_gen_number_bit_string = (char *)bit_string;
> >     retval = reiserfs_find_entry (dir, name, namelen, &path, &de);
> 
> I suspect mark_de_without_sd is an inlined function/macro and this will
> be where the unaligned data reference is happening.
> 
Correct. And the comments just above there about alignment are very
enlightening; it seems that the IBM/S390 architecture has some special
needs, and I just tested that my PA-RISC kernel has the same needs.
Thus I am able to present a real bugfix.

This patch allows me to run bonnie on a reiserfs partition with pa-risc
linux.

--- linux/include/linux/reiserfs_fs.h   Sun Sep  2 21:54:25 2001
+++ linux-new/include/linux/reiserfs_fs.h       Sun Sep  2 20:47:27 2001
@@ -924,7 +924,7 @@
 #define DEH_Visible 2

 /* 64 bit systems (and the S/390) need to be aligned explicitly -jdm */
-#if BITS_PER_LONG == 64 || defined(__s390__)
+#if BITS_PER_LONG == 64 || defined(__s390__) || defined(__hppa__)
 #   define ADDR_UNALIGNED_BITS  (3)
 #endif

This applies to linux-2.4.9-pa13 with
endian-safe-reiserfs-for-2.4.8.patch and to 2.4.9-ac5.

Please apply,
Jurriaan
-- 
It is well to remember, my son, that the entire population of the
universe, with one trifling exception, is composed of others.
        John Andrew Holmes
GNU/Linux 2.4.9-ac5 SMP/ReiserFS 2x1402 bogomips load av: 0.98 0.83 0.37

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Richard Zidlicky]

On Sun, Sep 02, 2001 at 07:57:17PM +0200, thunder7@xs4all.nl wrote:
> 
> --- linux/include/linux/reiserfs_fs.h   Sun Sep  2 21:54:25 2001
> +++ linux-new/include/linux/reiserfs_fs.h       Sun Sep  2 20:47:27 2001
> @@ -924,7 +924,7 @@
>  #define DEH_Visible 2
> 
>  /* 64 bit systems (and the S/390) need to be aligned explicitly -jdm */
> -#if BITS_PER_LONG == 64 || defined(__s390__)
> +#if BITS_PER_LONG == 64 || defined(__s390__) || defined(__hppa__)
>  #   define ADDR_UNALIGNED_BITS  (3)
>  #endif

couldn't reiserfs use asm/unaligned.h like anyone else?
Seems at least sparc and mips may need the same treatment.

Bye
Richard

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[David S. Miller]

   From: Richard Zidlicky <Richard.Zidlicky@stud.informatik.uni-erlangen.de>
   Date: Mon, 3 Sep 2001 00:34:37 +0200

   On Sun, Sep 02, 2001 at 07:57:17PM +0200, thunder7@xs4all.nl wrote:
   >  /* 64 bit systems (and the S/390) need to be aligned explicitly -jdm */
   > -#if BITS_PER_LONG == 64 || defined(__s390__)
   > +#if BITS_PER_LONG == 64 || defined(__s390__) || defined(__hppa__)
   >  #   define ADDR_UNALIGNED_BITS  (3)
   >  #endif
   
   couldn't reiserfs use asm/unaligned.h like anyone else?
   Seems at least sparc and mips may need the same treatment.

Sparc will act correctly for unaliagned accesses.

It will trap and run very slowly, but it wont' OOPS and
it will give correct results.

This is actually required behavior, I don't know why parisc
is acting differently.

Later,
David S. Miller
davem@redhat.com

Re: [parisc-linux] Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs

[Alan Cox]

> It will trap and run very slowly, but it wont' OOPS and
> it will give correct results.
> 
> This is actually required behavior, I don't know why parisc
> is acting differently.

Several of the platforms only have trap fixups for a small subset of operations
that can legitimately occur on things like networking headers. It makes the
recovery code a lot smaller and cleaner.

Alan

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Jeff Mahoney]

On Mon, Sep 03, 2001 at 12:34:37AM +0200, Richard Zidlicky wrote:
> On Sun, Sep 02, 2001 at 07:57:17PM +0200, thunder7@xs4all.nl wrote:
> > 
> > --- linux/include/linux/reiserfs_fs.h   Sun Sep  2 21:54:25 2001
> > +++ linux-new/include/linux/reiserfs_fs.h       Sun Sep  2 20:47:27 2001
> > @@ -924,7 +924,7 @@
> >  #define DEH_Visible 2
> > 
> >  /* 64 bit systems (and the S/390) need to be aligned explicitly -jdm */
> > -#if BITS_PER_LONG == 64 || defined(__s390__)
> > +#if BITS_PER_LONG == 64 || defined(__s390__) || defined(__hppa__)
> >  #   define ADDR_UNALIGNED_BITS  (3)
> >  #endif
> 
> couldn't reiserfs use asm/unaligned.h like anyone else?
> Seems at least sparc and mips may need the same treatment.

    I'll be the first to admit that having the #if followed by arch defines
    really sucks, and that asm/unaligned.h would be much cleaner if for no
    other reason than avoiding an unnecessary gotcha for someone porting a new
    arch.

    Unfortunately, this doesn't appear to work in all cases. I know from
    testing that the S/390 case will fail using the {get,put)_unaligned macros,
    since they are identical to a normal, unassisted assignment.

    I did kick around the idea of making those macros the default accessors for
    the deh_state member (which is the only place they're used), but it unfairly
    penalizes arches that don't need them.

    I'm open to suggestions.

    -Jeff

-- 
Jeff Mahoney           |   "Bill Gates is a monocle and a Persian cat away
jeffm@suse.com         |    from being the villain in a James Bond movie."
jeffm@csh.rit.edu      |                   -- Dennis Miller

Re: [parisc-linux] documented Oops running big-endian reiserfs on parisc architecture

[David S. Miller]

   From: Matthew Wilcox <willy@debian.org>
   Date: Sun, 2 Sep 2001 15:00:23 +0100

   On Sun, Sep 02, 2001 at 10:55:38AM +0200, thunder7@xs4all.nl wrote:
   > ReiserFS version 3.6.25
   > bonnie[163]: Unaligned data reference 28
   
   As it says, an unaligned data reference.
   
BTW, you should not be OOPSing on this as unaligned references are
defined as completely normal, especially in the networking.

Is it impossible to handle unaligned access traps properly on
parisc?  If so, well you have some problems...

Later,
David S. Miller
davem@redhat.com

Re: [parisc-linux] documented Oops running big-endian reiserfs on parisc architecture

[Matthew Wilcox]

On Sun, Sep 02, 2001 at 04:04:41PM -0700, David S. Miller wrote:
>    From: Matthew Wilcox <willy@debian.org>
>    Date: Sun, 2 Sep 2001 15:00:23 +0100
> 
>    On Sun, Sep 02, 2001 at 10:55:38AM +0200, thunder7@xs4all.nl wrote:
>    > ReiserFS version 3.6.25
>    > bonnie[163]: Unaligned data reference 28
>    
>    As it says, an unaligned data reference.
>    
> BTW, you should not be OOPSing on this as unaligned references are
> defined as completely normal, especially in the networking.
> 
> Is it impossible to handle unaligned access traps properly on
> parisc?  If so, well you have some problems...

No, we just haven't bothered to implement it yet.  Not many people
use IPX these days.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] documented Oops running big-endian reiserfs on parisc architecture

[David S. Miller]

   From: Matthew Wilcox <willy@debian.org>
   Date: Mon, 3 Sep 2001 00:25:14 +0100
   
   No, we just haven't bothered to implement it yet.  Not many people
   use IPX these days.
   
IPX is not the only way this can happen.  Normal IPv4 can get
it with some ethernet cards on receive.

Later,
David S. Miller
davem@redhat.com

Re: [parisc-linux] documented Oops running big-endian reiserfs on parisc architecture

[Alan Cox]

> > Is it impossible to handle unaligned access traps properly on
> > parisc?  If so, well you have some problems...
> 
> No, we just haven't bothered to implement it yet.  Not many people
> use IPX these days.

You also need unaligned trap fixups for

AX.25, NetROM, LAPB, X.25, Appletalk, PPP, Anything over 802.2LLC, Linus
NFS code for some NFS mount options (although not the -ac NFS code)

Alan

Re: documented Oops running big-endian reiserfs on parisc architecture

[thunder7]

On Mon, Sep 03, 2001 at 12:25:14AM +0100, Matthew Wilcox wrote:
> On Sun, Sep 02, 2001 at 04:04:41PM -0700, David S. Miller wrote:
> >    From: Matthew Wilcox <willy@debian.org>
> >    Date: Sun, 2 Sep 2001 15:00:23 +0100
> > 
> >    On Sun, Sep 02, 2001 at 10:55:38AM +0200, thunder7@xs4all.nl wrote:
> >    > ReiserFS version 3.6.25
> >    > bonnie[163]: Unaligned data reference 28
> >    
> >    As it says, an unaligned data reference.
> >    
> > BTW, you should not be OOPSing on this as unaligned references are
> > defined as completely normal, especially in the networking.
> > 
> > Is it impossible to handle unaligned access traps properly on
> > parisc?  If so, well you have some problems...
> 
> No, we just haven't bothered to implement it yet.  Not many people
> use IPX these days.
> 
OK, well this seems to have opened quite a can of worms. Programming the
handling of unaligned access traps on parisc is quite above my
possibilities.

I did notice that mark_de_without_sd() in reiserfs_fs.h just calls the
ext2_{set|clear|test}_bit routines. If the host architecture should
handle that with unaligned addresses, obviously the exception for s390
should also go. The current source would make reiserfs slow on sparc as
well, if I understand correctly.

To solve this for parisc, I see two possibilities:

- rewrite asm/parisc/bitops.h to have the ext2_* routines handle
  unaligned addresses. This would possibly be slowing down all aligned
  access. Not so nice.

- rewrite reiserfs_fs.h to use it's own test/set/clear bit routines.
  This would lose all the optimizations all specific architectures have
  in their asm/*/bitops.h. Also not nice.

Keeping in mind that I don't know any parisc assembly, is there any way
I can help resolve this in an elegant manner?

Greetings,
Jurriaan
-- 
If all else fails, immortality can always be assured by spectacular error.
        John Kenneth Galbraith
GNU/Linux 2.4.9-ac5 SMP/ReiserFS 2x1402 bogomips load av: 0.45 0.12 0.04

Re: documented Oops running big-endian reiserfs on parisc architecture

[Hans Reiser]

Well, I should have read the next email before saying these patches seemed to be
stable.

Jeff?

Hans

thunder7@xs4all.nl wrote:
> 
> Well, I watched the number of files in /lost+found grow every time I
> had to pull the plug from my HP C200, so I added a 'sync' option in
> /etc/fstab and tried to get reiserfs working.
> 
> I patched my 2.4.9-pa13 kernel with
> 
> endian-safe-reiserfs-for-2.4.8.patch
> 
> which went without warnings or errors. A patched
> reiserfs-progs-3.x.0k-pre9 also built well (despite what the configure
> scripts says, you _need_ automake).
> 
> Creating a reiserfs-partition went without a hitch.
> 
> running bonnie -s 128 on it did this:
> 
> Adding Swap: 1041400k swap-space (priority -1)
> eth0: Setting half-duplex based on MII#1 link partner capability of 0021.
> reiserfs: checking transaction log (device 08:03) ...
> Using r5 hash to sort names
> ReiserFS version 3.6.25
> bonnie[163]: Unaligned data reference 28
> 
>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001001111111100001110
> r0-3     00000000 102ec550 10197d0c 26f24838
> r4-7     26f24848 27054e40 00000011 00000020
> r8-11    0000000a 26f06580 00000020 26f247a0
> r12-15   27088d1c ffffffff 26f24838 00000001
> r16-19   26f24708 faf02c68 0006a248 26f24852
> r20-23   0000000f 00000003 03000000 00000002
> r24-27   0000000a 0000000a 26f24848 102d4010
> r28-31   26f24848 01000000 26f24b40 10196fc8
> sr0-3    00000000 00000004 00000000 00000004
> sr4-7    00000000 00000000 00000000 00000000
> 
> IASQ: 00000000 00000000 IAOQ: 10197d10 10197d14
>  IIR: 0c7c1093    ISR: 00000000  IOR: 26f24846
>  ORIG_R28: 00000000
> pa8200:/var/log#
> 
> After reading in the archives about ksymoops, I looked up this part of
> my System.map:
> 
> 101979e0 T reiserfs_lookup
> 101979e0 t .L1432
> 10197ad4 t reiserfs_add_entry
> 10197e50 t .L1512
> 10197f28 t .L1510
> 10198068 T reiserfs_create
> 
> objdump -d /boot/linux-2.4.9-pa13 revealed:
> 
> 10197cbc:       d6 d6 0b 18     depw,z r22,7,8,r22
> 10197cc0:       d6 b5 0a 10     depw,z r21,15,16,r21
> 10197cc4:       41 33 01 fe     ldb ff(sr0,r9),r19
> 10197cc8:       0a d5 02 75     or r21,r22,r21
> 10197ccc:       d6 94 09 08     depw,z r20,23,24,r20
> 10197cd0:       0a b4 02 74     or r20,r21,r20
> 10197cd4:       0a 93 02 73     or r19,r20,r19
> 10197cd8:       d2 75 18 f8     extrw,u r19,7,8,r21
> 10197cdc:       d2 74 19 f8     extrw,u r19,15,8,r20
> 10197ce0:       0c 73 12 16     stb  r19,b(sr0,r3)
> 10197ce4:       d2 73 1a f8     extrw,u r19,23,8,r19
> 10197ce8:       0c 75 12 10     stb  r21,8(sr0,r3)
> 10197cec:       0c 74 12 12     stb  r20,9(sr0,r3)
> 10197cf0:       e8 86 a9 e4     b,l 102a51e8 <memcpy>,%r2
> 10197cf4:       0c 73 12 14     stb  r19,a(sr0,r3)
> 10197cf8:       08 06 02 59     copy r6,r25
> 10197cfc:       08 04 02 5a     copy r4,r26
> 10197d00:       d7 20 1c 1d     depwi 0,31,3,r25
> 10197d04:       e8 0d a5 d8     call 101b1ff8 <padd_item>
> 10197d08:       08 08 02 58     copy r8,r24
> 10197d0c:       00 01 0e 74     rsm 1,r20
> 10197d10:       0c 7c 10 93     ldw  e(sr0,r3),r19
> 10197d14:       d6 60 1f 1f     depwi 0,7,1,r19
> 10197d18:       0c 73 12 9c     stw  r19,e(sr0,r3)
> 10197d1c:       00 14 18 60     mtsm r20
> 10197d20:       85 e0 26 32     cmpib,=,n 0,r15,10198040 <.L1510+0x118>
> 10197d24:       00 01 0e 74     rsm 1,r20
> 10197d28:       0c 7c 10 93     ldw  e(sr0,r3),r19
> 10197d2c:       d6 7f 1f 5f     depwi -1,5,1,r19
> 10197d30:       0c 73 12 9c     stw  r19,e(sr0,r3)
> 10197d34:       00 14 18 60     mtsm r20
> 10197d38:       08 00 02 54     copy r0,r20
> 10197d3c:       08 00 02 55     copy r0,r21
> 10197d40:       37 c6 3e 51     ldo -d8(sp),r6
> 10197d44:       37 cd 3d c1     ldo -120(sp),r13
> 10197d48:       6b d4 3e 51     stw r20,-d8(sr0,sp)
> 10197d4c:       6b d5 3e 59     stw r21,-d4(sr0,sp)
> 10197d50:       6b d4 3e 61     stw r20,-d0(sr0,sp)
> 10197d54:       6b d5 3e 69     stw r21,-cc(sr0,sp)
> 10197d58:       08 0c 02 59     copy r12,r25
> 10197d5c:       6b c6 3e 01     stw r6,-100(sr0,sp)
> 10197d60:       6b cd 3f 99     stw r13,-34(sr0,sp)
> 10197d64:       08 08 02 58     copy r8,r24
> 10197d68:       08 05 02 5a     copy r5,r26
> 10197d6c:       eb ff b4 4d     b,l 10197798 <reiserfs_find_entry>,%r2
> 
> which makes the error somewhere around here in
> fs/reiserfs/namei.c, function reiserfs_add_entry, after call to
> padd_item, before call to reiserfs_find_entry:
> 
>     /* copy name */
>     memcpy ((char *)(deh + 1), name, namelen);
>     /* padd by 0s to the 4 byte boundary */
>     padd_item ((char *)(deh + 1), ROUND_UP (namelen), namelen);
> 
>     /* entry is ready to be pasted into tree, set 'visibility' and 'stat data in entry' attributes */
>     mark_de_without_sd (deh);
>     visible ? mark_de_visible (deh) : mark_de_hidden (deh);
> 
>     /* find the proper place for the new entry */
>     memset (bit_string, 0, sizeof (bit_string));
>     de.de_gen_number_bit_string = (char *)bit_string;
>     retval = reiserfs_find_entry (dir, name, namelen, &path, &de);
> 
> And there I'm stuck. I'm sending this to the parisc-list to document the
> failure, and to linux-kernel to reach some reiserfs-experts, perhaps.
> 
> I'm willing to test anything!
> 
> Good luck,
> Jurriaan
> --
> "I have seen her. That is enough, perhaps."
> Pug smiled. "You are a rare man."
>         Raymond E Feist - The King's Buccaneer
> GNU/Linux 2.4.9-ac5 SMP/ReiserFS 2x1402 bogomips load av: 0.04 0.01 0.06
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [parisc-linux] Re: documented Oops running big-endian reiserfs on parisc architecture

[Matthew Wilcox]

On Mon, Sep 03, 2001 at 02:25:39PM +0400, Hans Reiser wrote:
> 
> 
> 
> Well, I should have read the next email before saying these patches seemed to be
> stable.
> 
> Jeff?

you misread the archive, Hans.  This is the original bugreport; once the
alignment was fixed it worked fine.

-- 
Revolutions do not require corporate support.

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Ulrich Weigand]

David Miller wrote:

>   From: Richard Zidlicky
<Richard.Zidlicky@stud.informatik.uni-erlangen.de>
>   Date: Mon, 3 Sep 2001 00:34:37 +0200
>
>   On Sun, Sep 02, 2001 at 07:57:17PM +0200, thunder7@xs4all.nl wrote:
>   >  /* 64 bit systems (and the S/390) need to be aligned explicitly -jdm
*/
>   > -#if BITS_PER_LONG == 64 || defined(__s390__)
>   > +#if BITS_PER_LONG == 64 || defined(__s390__) || defined(__hppa__)
>   >  #   define ADDR_UNALIGNED_BITS  (3)
>   >  #endif
>
>   couldn't reiserfs use asm/unaligned.h like anyone else?
>   Seems at least sparc and mips may need the same treatment.
>
>Sparc will act correctly for unaliagned accesses.
>
>It will trap and run very slowly, but it wont' OOPS and
>it will give correct results.
>
>This is actually required behavior, I don't know why parisc
>is acting differently.

>From what I recall when we were looking into reiserfs on S/390,
the core problem was that reiserfs tried to do *atomic* operations
on non-aligned words.  This isn't supported by the hardware on
S/390 (normal non-aligned accesses just work).

I don't really see how this can be fixed in a trap handler; how
would the handler guarantee atomicity?



Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Ralf Baechle]

On Mon, Sep 03, 2001 at 02:08:43PM +0200, Ulrich Weigand wrote:

> >From what I recall when we were looking into reiserfs on S/390,
> the core problem was that reiserfs tried to do *atomic* operations
> on non-aligned words.  This isn't supported by the hardware on
> S/390 (normal non-aligned accesses just work).
> 
> I don't really see how this can be fixed in a trap handler; how
> would the handler guarantee atomicity?

Spinlocks.  Now that'd so infinitly ugly that I'd rather fix Reiserfs.
It's another proof that reiserfs design was done without too much
consideration of portability so I speculate we'll continue to see such
bugs.

  Ralf

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[David S. Miller]

   From: "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com>
   Date: Mon, 3 Sep 2001 14:08:43 +0200
   
   >From what I recall when we were looking into reiserfs on S/390,
   the core problem was that reiserfs tried to do *atomic* operations
   on non-aligned words.  This isn't supported by the hardware on
   S/390 (normal non-aligned accesses just work).
   
   I don't really see how this can be fixed in a trap handler; how
   would the handler guarantee atomicity?

Oh thats different!  That won't even work %100 correctly on x86.  On
x86 it will "execute", but it won't be atomic.

Why the F*CK does it need to do this?  It sounds like sloppy
programming to me.

Later,
David S. Miller
davem@redhat.com

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Linus Torvalds]

In article <20010903.152443.59467554.davem@redhat.com>,
David S. Miller <davem@redhat.com> wrote:
>
>Oh thats different!  That won't even work %100 correctly on x86.  On
>x86 it will "execute", but it won't be atomic.

Actually, it will.  Intel definitely discourages it, but they'll lock
both cache-lines if the access is unaligned and crosses.  So while they
encourage natural alignment for atomic accesses, I think they also
guarantee that they always work - it ends up being only a performance
issue. 

I agree that it is bad practice, though, and I bet that the x86 is one
of the very few architectures that _will_ do this naturally.

		Linus

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Andi Kleen]

Jeff Mahoney <jeffm@suse.com> writes:


>     I did kick around the idea of making those macros the default accessors for
>     the deh_state member (which is the only place they're used), but it unfairly
>     penalizes arches that don't need them.

On archs that don't need them {get,put}_unaligned should be just normal
assignments. They are certainly on i386.


-Andi

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[David S. Miller]

   From: Andi Kleen <ak@suse.de>
   Date: 04 Sep 2001 11:44:30 +0200

   Jeff Mahoney <jeffm@suse.com> writes:
   
   >     I did kick around the idea of making those macros the default accessors for
   >     the deh_state member (which is the only place they're used), but it unfairly
   >     penalizes arches that don't need them.
   
   On archs that don't need them {get,put}_unaligned should be just normal
   assignments. They are certainly on i386.

I can also almost guarentee you that the x86 will sometimes not
execute these bitops atomically on SMP.

We had some obscure bug on SMP/x86 years ago, and Linus discovered
that removing an unaligned spinlock or bitop made the problem go away.

Reiserfs is broken and needs to be fixed.

If you make the unaligned accessors there the default for everyone,
you solve the problem _AND_ there is no penalization.  Look at what
the compiler makes of the code generated, it is going to be almost
entirely identical.  The compiler should be able to compute it all
via constants.  If not, oh you get 1 or 2 instructions here or
there, and that is MINISCULE compared to the cost of the atomic
operation itself.

What's more, you will have less QA'ing to do, since this code will
always be in use and thus tested.

FACT: Doing bitops on something not "long" aligned is a bug and
      will always be a bug.  You must fix it.

Later,
David S. Miller
davem@redhat.com

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Andi Kleen]

On Tue, Sep 04, 2001 at 03:04:54AM -0700, David S. Miller wrote:
>    From: Andi Kleen <ak@suse.de>
>    Date: 04 Sep 2001 11:44:30 +0200
> 
>    Jeff Mahoney <jeffm@suse.com> writes:
>    
>    >     I did kick around the idea of making those macros the default accessors for
>    >     the deh_state member (which is the only place they're used), but it unfairly
>    >     penalizes arches that don't need them.
>    
>    On archs that don't need them {get,put}_unaligned should be just normal
>    assignments. They are certainly on i386.
> 
> I can also almost guarentee you that the x86 will sometimes not
> execute these bitops atomically on SMP.

It's not needed when you have another lock to protect and don't have
interrupt threads.

iirc near all of reiserfs still runs under the BKL. BKL/schedule are full
memory barriers.

> What's more, you will have less QA'ing to do, since this code will
> always be in use and thus tested.

I think for a fs it is best to go with bigger locks and avoid the issue
of atomic operations completely.

-Andi

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[David S. Miller]

   From: Andi Kleen <ak@suse.de>
   Date: Tue, 4 Sep 2001 12:25:24 +0200

   On Tue, Sep 04, 2001 at 03:04:54AM -0700, David S. Miller wrote:
   > I can also almost guarentee you that the x86 will sometimes not
   > execute these bitops atomically on SMP.
   
   It's not needed when you have another lock to protect and don't have
   interrupt threads.

I agree completely, so therefore if moving to non-atomic bitops
is an option that would be a great way to fix this reiserfs bug.

Later,
David S. Miller
davem@redhat.com

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Jeff Mahoney]

On Tue, Sep 04, 2001 at 11:44:30AM +0200, Andi Kleen wrote:
> Jeff Mahoney <jeffm@suse.com> writes:
> 
> 
> >     I did kick around the idea of making those macros the default accessors for
> >     the deh_state member (which is the only place they're used), but it unfairly
> >     penalizes arches that don't need them.
> 
> On archs that don't need them {get,put}_unaligned should be just normal
> assignments. They are certainly on i386.

    Sorry, I guess I wasn't clear.

    When I mentioned "make those macros the default ..", I was referring to the
    reiserfs-defined macros, not the asm/unaligned.h macros.

    In my previous message, I had mentioned that the get/put _unaligned macros
    from asm/unaligned.h don't work in all cases. Specifically, the S/390 (and
    S/390x) versions won't work with ReiserFS, since they're nothing more than
    a normal access/mutate put into a compatible macro. Through testing on the
    S/390{,x}, I found that using the reiserfs-defined unaligned macros did the
    trick. The only place these reiserfs-defined macros are used is to
    access/mutate the reiserfs_de_head->deh_state member, which contains flags
    for the on-disk directory entry representation.
 
    Are the S/390 asm/unaligned.h versions broken, or is the ReiserFS code doing
    something not planned for? It's a 16-bit member, at a 16-bit alignment
    in the structure.  The structure itself need not be aligned in any
    particular manner as it is read directly from disk, and is a packed structure.

    -Jeff

-- 
Jeff Mahoney           |   "Bill Gates is a monocle and a Persian cat away
jeffm@suse.com         |    from being the villain in a James Bond movie."
jeffm@csh.rit.edu      |                   -- Dennis Miller

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Ulrich Weigand]

Jeff Mahoney wrote:

>    Are the S/390 asm/unaligned.h versions broken, or is the ReiserFS code
doing
>    something not planned for? It's a 16-bit member, at a 16-bit alignment
>    in the structure.  The structure itself need not be aligned in any
>    particular manner as it is read directly from disk, and is a packed
structure.

The S/390 unaligned.h macros are just direct assignments because the
S/390 hardware normally *allows* unaligned accesses just fine.

It is only *atomic* accesses (those implemented using the S/390
compare-and-swap instruction) that need to be word aligned; this includes
the atomic bit operations that reiserfs appears to be using.

If these instructions really *need* to be atomic, then reiserfs should
ensure they are performed on properly aligned data, or else there might
be subtle bugs even on Intel, because the operations will not actually
be atomic (even though they don't trap).

If you say that reiserfs doesn't really need these operations to be
atomic because they run under other locks anyway, then they should not
be using atomic operations in the first place; this will only cause
unnecessary slowdown even on Intel.


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Richard B. Johnson]

On Tue, 4 Sep 2001, Ulrich Weigand wrote:
[SNIPPED...]

> 
> If these instructions really *need* to be atomic, then reiserfs should
> ensure they are performed on properly aligned data, or else there might
> be subtle bugs even on Intel, because the operations will not actually
> be atomic (even though they don't trap).
>

Regardless of alignment, locked instructions in Intel machines are
atomic. Any "hidden" read/modify/write operations are performed
by the hardware, under the lock, preventing access by any other
CPUs or DMA.
 
> If you say that reiserfs doesn't really need these operations to be
> atomic because they run under other locks anyway, then they should not
> be using atomic operations in the first place; this will only cause
> unnecessary slowdown even on Intel.
> 

Agreed that there are many "atomic_t" types on some drivers, and
"atomic" operations that don't need to be there. Unless a DMA operation
is in progress, anything executing under a spin-lock doesn't need
to be an "atomic" operation to make it, truly, atomic.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[John Alvord]

On Tue, 4 Sep 2001, Ulrich Weigand wrote:

> 
> Jeff Mahoney wrote:
> 
> >    Are the S/390 asm/unaligned.h versions broken, or is the ReiserFS code
> doing
> >    something not planned for? It's a 16-bit member, at a 16-bit alignment
> >    in the structure.  The structure itself need not be aligned in any
> >    particular manner as it is read directly from disk, and is a packed
> structure.
> 
> The S/390 unaligned.h macros are just direct assignments because the
> S/390 hardware normally *allows* unaligned accesses just fine.
> 
> It is only *atomic* accesses (those implemented using the S/390
> compare-and-swap instruction) that need to be word aligned; this includes
> the atomic bit operations that reiserfs appears to be using.

Aren't their some other "must align" instructions like CVB? Or have they
all been relaxed...

john

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Ulrich Weigand]

John Alvord wrote:

>> It is only *atomic* accesses (those implemented using the S/390
>> compare-and-swap instruction) that need to be word aligned; this
includes
>> the atomic bit operations that reiserfs appears to be using.
>
>Aren't their some other "must align" instructions like CVB? Or have they
>all been relaxed...

CVB doesn't have any alignment requirement (I'm not sure it ever had one).
Execpt for the 'atomic' operations (CS, CSG, CDS, CDSG, LPQ, STPQ, PLO)
I know only of two general-purpose instructions with operand alignment
requirement, and that's LAM and STAM.  As access registers are not
normally used in Linux this shouldn't be a problem.

There *is* a whole bunch of privileged system instructions that have
various aligment requirements; but here I'd say it's fair to require the
user to provide correct aligment in these special cases.


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture

[Ulrich Weigand]

Jeff Mahoney wrote:

> Are the S/390 asm/unaligned.h versions broken, or is the ReiserFS code doing 
> something not planned for? It's a 16-bit member, at a 16-bit alignment 
> in the structure. The structure itself need not be aligned in any 
> particular manner as it is read directly from disk, and is a packed structure.

One other point I overlooked before: using set_bit etc on a *16-bit* 
member is fundamentally broken on S/390 anyway (and I far as I know all 
other bigendian architectures as well).  set_bit assumes to operate on
a long (or an array of longs); if you use set_bit to set bit number 0
in the bitfield starting at address X, it will actually modify the byte 
located at address X+3 (or X+7 on 64-bit bigendian machines), because
this is where the bit with value 2^0 is located in a long.

If your bitfield is only 2 bytes long, this will obviously clobber
random memory after the field ...  (Note that the _unaligned variants
do not fix this problem, they will just cause it to clobber memory
*before* the field instead, if I interpret them correctly.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de