- 01 6月, 2006 1 次提交
-
-
由 Andrew Morton 提交于
From: Andrew Morton <akpm@osdl.org> Move the forward decl outside the ifdef, since we use it in both legs. Should fix the spacr64 build error reported in http://bugzilla.kernel.org/show_bug.cgi?id=6625Acked-by: N"David S. Miller" <davem@davemloft.net> Cc: Cedric Pellerin <cedric@bidouillesoft.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 26 4月, 2006 1 次提交
-
-
由 David Woodhouse 提交于
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 22 3月, 2006 1 次提交
-
-
由 Shaun Pereira 提交于
Get socket timestamp handler function that does not use the ioctl32_hash_table. Signed-off-by: NShaun Pereira <spereira@tusc.com.au> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 09 9月, 2005 1 次提交
-
-
由 David S. Miller 提交于
Else we get build failures like: CC arch/sparc64/kernel/sparc64_ksyms.o In file included from arch/sparc64/kernel/sparc64_ksyms.c:28: include/net/compat.h:37: warning: "struct sock" declared inside parameter list include/net/compat.h:37: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 08 9月, 2005 1 次提交
-
-
由 Al Viro 提交于
When we copy 32bit ->msg_control contents to kernel, we walk the same userland data twice without sanity checks on the second pass. Second version of this patch: the original broke with 64-bit arches running 32-bit-compat-mode executables doing sendmsg() syscalls with unaligned CMSG data areas Another thing is that we use kmalloc() to allocate and sock_kfree_s() to free afterwards; less serious, but also needs fixing. Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org> Signed-off-by: NChris Wright <chrisw@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-