bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: parted fat bug on ARM platform


From: Lennert Buytenhek
Subject: Re: parted fat bug on ARM platform
Date: Tue, 8 Mar 2005 07:24:38 +0100
User-agent: Mutt/1.4.1i

On Tue, Mar 08, 2005 at 04:38:37AM +1100, Andrew Clausen wrote:

> > > Does gcc work around the problem?  (i.e. does it do the necessary
> > > bit-bashing based on aligned reads only?)
> > 
> > No.  gcc doesn't know in advance that a pointer will be unaligned,
> > so it will just emit a regular load/store in any case.
> 
> That's annoying.  It should be able to do it for
> __attribute__((packed)) structs, IMHO.

Hmmm, not sure what's wise here.  I'm not sure if gcc has the
necessary infrastructure at this point -- it would have to keep
track of which pointers are possibly unaligned.

        FatBootSector foo;
        uint16_t *blah;
        uint16_t value;

        blah = &(foo->unaligned_field);
        [ do other stuff ]
        value = *blah;                  // remember that blah was unaligned

Then again, if it supports 'bounded pointers' (which I think newer
gcc versions do), this shouldn't be hard to add.


> > Whenever the linux kernel does a load that it suspects might be not
> > properly aligned, it uses a function called get_unaligned(), which
> > then uses aligned accesses, instead of dereferencing the pointer
> > directly.  There is no such function for stores, though.
> > 
> > There's also a kernel option to have unaligned userspace accesses
> > send a fatal signal to the offending process, so it would be easy
> > for me to test patches.  (Just shout if you need (temporary) shell
> > access to an ARM box.)
> 
> It sounds to me like the best solution is to:
>  * complain if ARM && kernel<2.6.11
>  * set /proc/cpu/alignment on ARM

You mean, have parted set it?  That'll bluntly override whatever
the administrator configured, which IMHO is not such a good idea.

How about just detecting if unaligned accesses are working properly
or not, and bailing out if it doesn't?  Do something like this:

static int check_if_unaligned_accesses_work(void)
{
        unsigned char test[] = { 0, 1, 2, 3, 4, 5, 6 };

        if (*((volatile u_int16_t *)(test)) == 0x0001 &&
            *((volatile u_int16_t *)(test + 1)) == 0x0102 &&
            *((volatile u_int32_t *)(test)) == 0x00010203 &&
            *((volatile u_int32_t *)(test + 1)) == 0x01020304 &&
            *((volatile u_int32_t *)(test + 2)) == 0x02030405 &&
            *((volatile u_int32_t *)(test + 3)) == 0x03040506) {
                /* Big-endian machine, unaligned accesses are fine.  */
                return 1;
        }

        if (*((volatile u_int16_t *)(test)) == 0x0100 &&
            *((volatile u_int16_t *)(test + 1)) == 0x0201 &&
            *((volatile u_int32_t *)(test)) == 0x03020100 &&
            *((volatile u_int32_t *)(test + 1)) == 0x04030201 &&
            *((volatile u_int32_t *)(test + 2)) == 0x05040302 &&
            *((volatile u_int32_t *)(test + 3)) == 0x06050403) {
                /* Little-endian machine, unaligned accesses are fine.  */
                return 1;
        }

        /* Something wrong!  */
        return 0;
}


> Doing the necessary bit-bashing decreases the maintainability of Parted
> for other platforms.  (And besides, it's rather tedious/difficult work.)

True.  And you're never really sure if you caught all the accesses.


> Do any ARM uses care about FAT support?

There's a lot of "embedded" ARM hardware out there with CompactFlash
slots, and lots of CompactFlash cards (and things like microdrives)
often come preformatted with FAT filesystems, so yeah, there are
surely people out there that use FAT on ARM.

(There's also a lot of ARM hardware that has little more than
some serial ports and ethernet -- there's a lot of variety in
this platform.)


--L




reply via email to

[Prev in Thread] Current Thread [Next in Thread]