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

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.

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: [parisc-linux] documented Oops running big-endian reiserfs on parisc architecture

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > > 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)

And also everybody connected to the internet needs them, because you can 
create arbitarily unaligned TCP/UDP/ICMP headers using IP option byte sized 
NOPs. 

-Andi

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

[David S. Miller]

   From: Andi Kleen <ak@suse.de>
   Date: 03 Sep 2001 09:29:12 +0200
   
   And also everybody connected to the internet needs them, because you can 
   create arbitarily unaligned TCP/UDP/ICMP headers using IP option byte sized 
   NOPs. 

IP header length is measured in octets, so how is this possible?
:-)

Later,
David S. Miller
davem@redhat.com

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

[Andi Kleen]

On Mon, Sep 03, 2001 at 01:15:30AM -0700, David S. Miller wrote:
>    From: Andi Kleen <ak@suse.de>
>    Date: 03 Sep 2001 09:29:12 +0200
>    
>    And also everybody connected to the internet needs them, because you can 
>    create arbitarily unaligned TCP/UDP/ICMP headers using IP option byte sized 
>    NOPs. 
> 
> IP header length is measured in octets, so how is this possible?
> :-)

Sorry that came out wrong. You can in theory generate unaligned IP options this way, but the 
kernel handles this correctly using memcpy. What it doesn't handle is unaligned TCP options
(e.g. timestamps); which you can create using TCP option byte fillers.

Also the 4 byte alignment of the header doesn't help much when the driver didn't cooperate.

-Andi

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

[Hans Reiser]

Ok, so the sum of this is that Jeff's patches work on the platforms he wrote
them for, and we need one more fix for PA-RISC.

So, we can reasonably send Jeff's patches to Linus, and test and then put the
PA-RISC patch into the AC tree, any disagreement?

Hans

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

[Matthew Wilcox]

On Mon, Sep 03, 2001 at 02:48:24PM +0400, Hans Reiser wrote:
> Ok, so the sum of this is that Jeff's patches work on the platforms he wrote
> them for, and we need one more fix for PA-RISC.
> 
> So, we can reasonably send Jeff's patches to Linus, and test and then put the
> PA-RISC patch into the AC tree, any disagreement?

If you don't align on sparc, alpha, et al, then it will be slower than
it could be; don't you want to fix that first?

-- 
Revolutions do not require corporate support.

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

[Horst von Brand]

"David S. Miller" <davem@redhat.com> said:
> IP header length is measured in octets, so how is this possible?
> :-)

1 octet == 8 bits in RFC-speak. "Byte" is the name given to character
units.  There were machines around with non-8-bit bytes. AFAIR, DEC PDP-10
had the options of 6, 7, or 8 bits/byte in 36 bit words. Purely historical
now, since (AFAIK) everybody has agreed with IBM (S/360?) that 1 byte == 8
bits. As Brian Reid (IIRC) used to say: "It is spelled 'o-c-t-e-t' and
pronounced 'byte'"
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616