linux-kernel - Re: Sparc-32 doesn't work in 3.1.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1323884995.2334.71.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date:	Wed, 14 Dec 2011 18:49:55 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Sergei Trofimovich <slyich@...il.com>
Cc:	Rob Landley <rob@...dley.net>,
	Aboriginal Linux <aboriginal@...ts.landley.net>,
	linux-kernel@...r.kernel.org, davem@...emloft.net, tytso@....edu,
	sparclinux@...r.kernel.org, Jakub Jelinek <jakub@...hat.com>
Subject: Re: Sparc-32 doesn't work in 3.1.

Le mercredi 14 décembre 2011 à 20:42 +0300, Sergei Trofimovich a écrit :
> [ CCed Jakub ]
> 
> >>>   Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek (jj@...ra.linux.cz).
> >>>   Patching kernel for srmmu[Fujitsu TurboSparc]/iommu
> >>>   Fixup i f029ddfc doesn't refer to a valid instruction at
> >>>   f00de648[95eea000]
> >>>   halt, power off
> 
> > I put the broken image up at http://landley.net/sparc-image for the
> > moment, but if you build 3.1 with the attached .config and the toolchain
> > mentioned last time, it should reproduce for you.  It's 100% reliable
> > for me...
> 
> Nice! With this config it breaks for me on your and mine toolchains.
> The offending function is ext4_kvmalloc (and similar ext4_kvzalloc).
> 
> The usual relocation in sparc looks like a pair of instructions loading
> two pats of address in 2 instructions:
> 
> Like that:
> >        sethi   %hi(ext4_fill_super), %o4       !, tmp113
> >        or      %o4, %lo(ext4_fill_super), %o4  ! tmp113,, tmp28
> 
> In our case relocatable symbol sits in tail call, so %lo part is in "unusual"
> RESTORE instruction:
> 
> > ext4_kvmalloc:
> ...
> >         sethi  %hi(___i_page_kernel), %i2      !, tmp112
> >        call    __vmalloc, 0    !
> >         restore %i2, %lo(___i_page_kernel), %o2        ! tmp112,,
> ...
> 
> David: is this code correct? Or it's a compiler bug? I am sparc32 newbie.
> (C source and asm sources of function are in [1])
> 
> I think this kind of code is generated only in -Os.
> So to workaround it I tried this hack:
> 
> > --- a/fs/ext4/super.c
> > +++ b/fs/ext4/super.c
> >         ret = kmalloc(size, flags);
> >         if (!ret)
> >                 ret = __vmalloc(size, flags, PAGE_KERNEL);
> > +
> > +       asm __volatile__("nop":::"memory");
> > +
> >         return ret;
> >  }
> (for both ext4_kvmalloc / ext4_kvzalloc. Attached workaround as a patch.)
> 
> It forces compiler to geterate "usual" pattern for relocation.
> 
> I think of 2 solutions:
> 
> 1. trying to fix sparc/boot/btfixupprep.c and arch/sparc/mm/btfixup.c
>    to distinct HI22 and LO10 relocations as different ones.
>    Right now they are merged into one 'i' type and rely on instruction heuristics to fix it.
> 2. Add a hack to arch/sparc/mm/btfixup.c to recognize restore instruction as well
> 
> Any others?

3)  Adding a memset() in ext4_kvmalloc() and ext4_kvzalloc() to prefault
pages ?

4) (Unrelated) : add __GFP_HIGHMEM to __vmalloc() flags, so that high
memory pages can be used for large allocations.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/