[lkml]   [2001]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Ia64 unaligned accesses in ntfs driver
At 07:05 17/12/01, Ville Herva wrote:
>I get unaligned accesses from these addresses:
>kernel unaligned access to 0xe00000006fb49719, ip=0xa000000000265050
>from ksymoops:
>Adhoc a000000000265050 <[ntfs]ntfs_decompress+d0/320>
>Adhoc a000000000262d80 <[ntfs]ntfs_decompress_run+2a0/3c0>
>Adhoc a000000000262ba0 <[ntfs]ntfs_decompress_run+c0/3c0>
>Adhoc a000000000262d60 <[ntfs]ntfs_decompress_run+280/3c0>
>Are these dangerous? I gather IA64 port has some kind of handler for these,
>since they don't oops.

They are at least one of the explanations why the driver would not work on
non-intel arch... I gather most other arch don't cope with unaligned
accesses. I am surprised those are the only ones you see actually...

This particular function is not implemented correctly anyway - it will not
work on BE arch for example (despite all the endian conversion functions,
some of which are wrong AFAIK).

The changes to make the driver clean are too complex and I am not going to
bother considering the replacement ntfs driver (ntfs tng available from
linux-ntfs cvs on sourceforge) is close to being ready for inclusion into
2.5.x (as soon as read support is completed I will submit it, probably
sometime in January). If anyone wants to work on the old driver I am happy
to take patches. (-;

The new driver should be completely endianness clean and any unaligned
accesses will be dealt with as they are identified. I know of a few
possible ones which I will need to verify and wrap in the get unaligned
macros before release. But for tracking down the rest I will need people to
test the driver as I don't have access to any non-ia32 arch to test on
myself... I don't think there will be many though as most structures in
ntfs have nice alignment guarantees. - The mapping pairs array being a
notable difference which is the source of the unaligned accesses you
report. The new driver handles them correctly by working on a byte-by-byte
basis instead of doing multi-byte accesses, which is the correct way to
decompress the mapping pairs array.

Best regards,


"I've not lost my mind. It's backed up on tape somewhere." - Unknown
Anton Altaparmakov <aia21 at> (replace at with @)
Linux NTFS Maintainer / WWW:
ICQ: 8561279 / WWW:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:14    [W:0.068 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site