lkml.org 
[lkml]   [2001]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Compatibility issue with 2.2.19pre7
Date
Zitiere Russell King <rmk@arm.linux.org.uk>:
> The API changed:
> struct nfs_mount_data {
> int version; /* 1 */
> int fd; /* 1 */
> - struct nfs_fh root; /* 1 */
> + struct nfs2_fh old_root; /* 1 */

I don't see an API change:
the 2.2.17 "struct nfs_fs" and the 2.2.18 "struct nfs2_fh" are identical.

Ok, I see the problem:

struct nfs_fh {
unsigned short size;
unsigned char data[NFS_MAXFHSIZE];
}

The compiler thinks that data is a character array, thus no padding is inserted.
nlm_lookup_file casts f->data to "struct knfs_fs", a structure with pointers and
u32. --> unaligned u32 read --> boom.

Is that correct?
Is &(((struct nfs_fh*)0)->data) 2 or 4?

ARM isn't the only cpu that can't handle unaligned memory reads, why doesn't the
code fail on Alpha/Sparc? Does gcc insert padding on these cpus?


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

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