lkml.org 
[lkml]   [2002]   [Dec]   [26]   [last100]   RSS-feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Complete thread (EXPERIMENTAL)
/
DateThu, 26 Dec 2002 13:57:05 +0100 (MET)
FromMikael Pettersson <>
SubjectRe: [PATCH] 2.5 fast poll on ppc64
Digg This
Anton Blanchard writes:
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
\
ISP Services
Valid XHTML 1.0!\ /
Valid CSS! Last update: 2005-03-22 12:31    [W:0.069 / U:0.130 seconds]
©2003-2005 Jasper Spaans