- 21 Nov, 2005 8 commits
-
-
Linus Torvalds authored
-
Randy Dunlap authored
Fix kernel-doc warnings in network files. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nicolas Kaiser authored
Signed-off-by: Nicolas Kaiser <nikai@nikai.net> Signed-off-by: Harald Welte <laforge@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yasuyuki Kozakai authored
- IP_NF_CONNTRACK_MARK is bool and depends on only IP_NF_CONNTRACK which is tristate. If a variable depends on IP_NF_CONNTRACK_MARK and doesn't care about IP_NF_CONNTRACK, it can be y. This must be avoided. - IP_NF_CT_ACCT has same problem. - IP_NF_TARGET_CLUSTERIP also depends on IP_NF_MANGLE. Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Signed-off-by: Harald Welte <laforge@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
Don't show local table to behave similar to fib_hash. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 20 Nov, 2005 31 commits
-
-
Dmitry Torokhov authored
Fix an OOPS is CinergyT2 driver when registering IR remote Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Yan Zheng authored
addrconf_verify(...) only traverse address hash table when addrconf_hash_lock is held for writing, and it may hold addrconf_hash_lock for a long time. So I think it's better to acquire addrconf_hash_lock for reading instead of writing Signed-off-by: Yan Zheng <yanzheng@21cn.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexandra Kossovsky authored
From: Alexandra Kossovsky <Alexandra.Kossovsky@oktetlabs.ru> From http://bugzilla.kernel.org/show_bug.cgi?id=4746 There is user data corruption when using ioctl(SIOCGIFCONF) in 32-bit application running amd64 kernel. I do not think that this problem is exploitable, but any data corruption may lead to security problems. Following code demonstrates the problem #include <stdint.h> #include <stdio.h> #include <sys/time.h> #include <sys/socket.h> #include <net/if.h> #include <sys/ioctl.h> char buf[256]; main() { int s = socket(AF_INET, SOCK_DGRAM, 0); struct ifconf req; int i; req.ifc_buf = buf; req.ifc_len = 41; printf("Result %d\n", ioctl(s, SIOCGIFCONF, &req)); printf("Len %d\n", req.ifc_len); for (i = 41; i < 256; i++) if (buf[i] != 0) printf("Byte %d is corrupted\n", i); } Steps to reproduce: Compile the code above into 32-bit elf and run it. You'll get Result 0 Len 32 Byte 48 is corrupted Byte 52 is corrupted Byte 53 is corrupted Byte 54 is corrupted Byte 55 is corrupted Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kris Katterjohn authored
This way we don't have to check it in sk_run_filter(). Signed-off-by: Kris Katterjohn <kjak@users.sourceforge.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrea Bittau authored
If two packets were queued to be sent at the same time in the future, their order would be reversed. This would occur because the queue is traversed back to front, and a position is found by checking whether the new packet needs to be sent before the packet being examined. If the new packet is to be sent at the same time of a previous packet, it would end up before the old packet in the queue. This patch places packets in the correct order when they are queued to be sent at a same time in the future. Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andi Kleen authored
Originally for 2.6.16, but the semaphore causes problems for some people so get rid of it now. It's not needed anymore because the ioctl hash table is never changed at run time now. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jacob.Shin@amd.com authored
Ever since we remove msr.c from x86_64 branch and started grabbing it from i386, msr device (read functionality) has been broken for us. This is due to the differences between asm-i386/msr.h and asm-x86_64/msr.h interfaces. Here is a patch to our side to fix this. Thankfully, as of current (2.6.15-rc1-git6) tree, arch/i386/kernel/msr.c is the only file that uses rdmsr_safe macro. Signed-off-by: Jacob Shin <jacob.shin@amd.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Ashok Raj authored
Needed to make the earlier use disabled CPUs for CPU hotplug patch actually work. Need to register disabled processors as well, so we can count them towards cpu_possible_map as hot pluggable cpus. Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
bigsmp is reported to work on large Opteron systems on 32bit too. Enable it by default there. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
-
Dmitry Torokhov authored
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
kseriod and kgameportd used to process all pending events before checking for freeze condition. This may cause swsusp to time out while stopping tasks when resuming. Switch to process events one by one to check freeze status more often. Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
If thread that submitted FF request gets interrupted somehow it will release request structure and ioctl handler will work with freed memory. TO prevent that from happening switch to using wait_for_completion instead of wait_for_completion_interruptible. Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
Also introduce proper locking when creating/deleting device. Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Miloslav Trmac authored
Try to save battery power by disabling wifi and bluetooth on suspend. Signed-off-by: Miloslav Trmac <mitr@volny.cz> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
Register wistron-bios as a platform device, restore WIFI and Bluetooth state upon resume. Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Bernhard Rosenkraenzer authored
Also fix a potential issue with some notebooks: The current code assumes the response to bios_wifi_get_default_setting is either 1 (disabled) or 3 (enabled), or wifi isn't supported. The BIOS response appears to be a bit field w/ 0x1 indicating hardware presence, 0x2 indicating actiation status, and the other 6 bits being unknown/reserved -- with the patch, these 6 bits are ignored. Signed-off-by: Bernhard Rosenkraenzer <bero@arklinux.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Andrew Morton authored
On x86_64: {standard input}:233: Error: suffix or operands invalid for `push' {standard input}:233: Error: suffix or operands invalid for `pop' Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
A driver for laptop buttons using an x86 BIOS interface that is apparently used on quite a few laptops and seems to be originating from Wistron. This driver currently "knows" only about Fujitsu-Siemens Amilo Pro V2000 (i.e. it can detect the laptop using DMI and it contains the keycode->key meaning mapping for this laptop) and Xeron SonicPro X 155G (probably can't be reliably autodetected, requires a module parameter), adding other laptops should be easy. In addition to reporting button presses to the input layer the driver also allows enabling/disabling the embedded wireless NIC (using the "Wifi" button); this is done using the same BIOS interface, so it seems only logical to keep the implementation together. Any flexibility possibly gained by allowing users to remap the function of the "Wifi" button is IMHO not worth it when weighted against the necessity to run an user-space daemon to convert button presses to wifi state changes. Signed-off-by: Miloslav Trmac <mitr@volny.cz> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
Changing led state is pretty slow operation; when there are multiple requests coming at a high rate they may interfere with normal typing. Try optimize (skip) changing hardware state when multiple requests are coming back-to-back. Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
-
Steve French authored
-
Steve French authored
so it does not return EACCESS (unless server really returns that). Signed-off-by: Steve French <sfrench@us.ibm.com>
-
Linus Torvalds authored
-
YOSHIFUJI Hideaki authored
Based on suggestion from Masahide Nakamura <nakam@linux-ipv6.org>. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-
Ville Nuorvala authored
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-
YOSHIFUJI Hideaki authored
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-
Linus Torvalds authored
-
- 19 Nov, 2005 1 commit
-
-
Linus Torvalds authored
-