![]() | |||||||||||
Messages in this thread Complete thread (EXPERIMENTAL) |
I was unable to boot 2.5-BK on ppc64 and narrowed it down to the fast
poll patch. I found:
offsetof(struct poll_list, entries) == 12 but sizeof(struct poll_list) == 16 This means pp+1 did not match up with pp->entries. Im not sure what the alignment requirements are for a zero length struct (ie is this a compiler bug) but the following patch fixes the problem and also changes ->len to a long to ensure 8 byte alignment of ->entries on 64bit archs. Anton ===== fs/select.c 1.15 vs edited ===== --- 1.15/fs/select.c Sat Dec 21 20:42:41 2002 +++ edited/fs/select.c Thu Dec 26 17:31:16 2002 @@ -362,7 +362,7 @@ struct poll_list { struct poll_list *next; - int len; + long len; struct pollfd entries[0]; }; To me (I'm a compiler writer) it looks like your compiler did NOT mess up. Assuming struct pollfd has 32-bit alignment, the compiler is doing the right thing by starting entries[] at offset 12. The 16-byte size for struct poll_list is because the 'next' field has 64-bit alignment, which forces the compiler to pad struct poll_lists's size to a multiple of 8 bytes, i.e. 16 bytes in this case. So the compiler is not broken. @@ -471,7 +471,7 @@ walk->next = pp; walk = pp; - if (copy_from_user(pp+1, ufds + nfds-i, + if (copy_from_user(pp->entries, ufds + nfds-i, sizeof(struct pollfd)*pp->len)) { But the old code which assumed pp+1 == pp->entries is so horribly broken I can't find words for it. s/pp+1/pp->entries/ is the correct fix. /Mikael | ||||||||||
![]() | |||||||||||
| Last update: 2005-03-22 12:31 [W:0.069 / U:0.130 seconds] ©2003-2005 Jasper Spaans | |||||||||||