[buildd-tools-devel] Bug#580136: Bug#580136: schroot personality build fails on armel

[Roger Leigh]

tags 580136 + patch
thanks

On Fri, May 07, 2010 at 05:04:51PM +0200, Arnaud Patard wrote:
> Roger Leigh <rleigh at codelibre.net> writes:
> 
> > Could the Debian ARM list/porters possibly comment upon this
> > bug?  Please could you keep buildd-tools-devel and the bug
> > in the CC on any reply.  Thanks.
> >
> > It's not clear to me why this bug has suddenly appeared, and
> > only on armel.  There seem to be a few possibilities:
> >
> > 1) schroot is using personality(2) incorrectly, but this is
> >    only causing breakage on armel because only armel sets
> >    some of the high bits outside the range of PER_MASK
> > 2) there's an armel-specific bug in the glibc personality
> >    wrapper and/or headers
> > 3) there's an armel-specific bug in the kernel and/or its
> >    headers
> 
> I would rather say it's a little bit more complicated than that. From
> what I understand :
> 
> by default, the personality is PER_LINUX_32BIT on eabi (and PER_LINUX on
> oabi [1]), but :
> 
> - on arm < v6, there's no xn/nx which means that READ_IMPLIES_EXEC will be
>   set. So personality(0xffffffff) gives 0x00c00000
> - on arm >= v6, there's xn/nx so READ_IMPLIES_EXEC will not be set and then
>   personality(0xffffffff) gives 0x00800000
> 
> It was giving 0x00800000  on all systems before because it was
> broken. It has been fixed in the kernel with commit :
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9da616fb9946c8d65387052e5a538b8f54ddb292

OK, thanks.  It looks like we can't rely on personality(0xffffffff)
ever giving a usable result.  Given that some personality defines
set the high bits and reuse the low bits, we can't mask out the
high bits and get a sensible result... i.e. you can't roundtrip
from personality(PER_OSR5) and get the same result back if you
use PER_MASK, and the same applies to any kernel which sets
PER_LINUX with any additional flags.

It would be nice if some more thought had been given to this
interface by the kernel folks, but it looks like we just can't
reliably retrieve the personality from the kernel.  Preferably
every byte should resolve to a separate system type, but
they aren't unique.

I've attached a patch for schroot which removes the need for
getting the personality from the kernel.  We cache the set
personality and return that instead.  Not as nice as I would
have liked, but it should fix up this issue.

Please could someone test if this builds correctly on armel for
me?  If so, I'll include this fix in the next upload.  This
also needs testing on a 64bit system to ensure that
personality=linux32 etc. still work correctly; if anyone
could do that as well, it would be much appreciated.


Many thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schroot-personality-no-roundtrip.patch
Type: text/x-diff
Size: 7566 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20100515/811573b9/attachment-0003.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20100515/811573b9/attachment-0003.pgp>