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

[parisc-linux] 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

[parisc-linux] 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

[parisc-linux] 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.

[parisc-linux] 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

[parisc-linux] 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

[parisc-linux] 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