linux/include, branch v2.6.28.5

serial: set correct baud_base for Oxford Semiconductor Ltd EXSYS EX-41092 Dual 16950 Serial adapter

2009-02-12T17:50:36Z

commit 39aced68d664291db3324d0fcf0985ab5626aac2 upstream. The PCI-card identified as "Oxford Semiconductor Ltd EXSYS EX-41092 Dual 16950 Serial adapter" is only usable with other devices (i.e. not the same card) after doing a "setserial /dev/ttyS baud_base 115200". This baud_base should be default for this card. Signed-off-by: Niels de Vos Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

PCI: return error on failure to read PCI ROMs

2009-02-12T17:50:35Z

commit 97c44836cdec1ea713a15d84098a1a908157e68f upstream. This patch makes the ROM reading code return an error to user space if the size of the ROM read is equal to 0. The patch also emits a warnings if the contents of the ROM are invalid, and documents the effects of the "enable" file on ROM reading. Signed-off-by: Timothy S. Nelson Acked-by: Alex Villacis-Lasso Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

serial: RS485 ioctl structure uses __u32 include linux/types.h

2009-02-12T17:50:27Z

commit 60c20fb8c00a2b23308ae4517f145383bc66d291 upstream. In the commit below a new struct serial_rs485 was introduced for a new ioctl: commit c26c56c0f40e200e61d1390629c806f6adaffbcc Author: Alan Cox Date: Mon Oct 13 10:37:48 2008 +0100 tty: Cris has a nice RS485 ioctl so we should steal it This structure uses the __u32 types for some of its members, which leads to the following compile error: $ cc -I.../include -c X.c In file included from X.c:2: .../include/linux/serial.h:185: error: expected specifier-qualifier-list before ‘__u32’ $ It seems that these types are appropriate for this structure as it is to be exposed to userspace. These types are available via linux/types.h so move the include of that outside the __KERNEL__ section. Signed-off-by: Andy Whitcroft Signed-off-by: Andrew Morton Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Cc: Matthew Burgess Signed-off-by: Greg Kroah-Hartman

module: remove over-zealous check in __module_get()

2009-02-12T17:50:26Z

commit 7f9a50a5b89b87f8e754f59ae9968da28be618a5 upstream. Impact: fix spurious BUG_ON() triggered under load module_refcount() isn't reliable outside stop_machine(), as demonstrated by Karsten Keil , networking can trigger it under load (an inc on one cpu and dec on another while module_refcount() is tallying can give false results, for example). Almost noone should be using __module_get, but that's another issue. Cc: Karsten Keil Signed-off-by: Rusty Russell Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ACPI: Enable bit 11 in _PDC to advertise hw coord

2009-02-12T17:50:25Z

commit d96f94c604453f87fe24154b87e1e9a3a72511f8 upstream. Bit 11 in intel PDC definitions is meant for OS capability to handle hardware coordination of P-states. In Linux we have always supported hwardware coordination of P-states. Just let the BIOSes know that we support it, by setting this bit. Some BIOSes use this bit to choose between hardware or software coordination and without this change below, BIOSes switch to software coordination, which is not very optimal in terms of power consumption and extra wakeups from idle. Signed-off-by: Venkatesh Pallipadi Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

wait: prevent exclusive waiter starvation

2009-02-12T17:50:23Z

commit 777c6c5f1f6e757ae49ecca2ed72d6b1f523c007 upstream. With exclusive waiters, every process woken up through the wait queue must ensure that the next waiter down the line is woken when it has finished. Interruptible waiters don't do that when aborting due to a signal. And if an aborting waiter is concurrently woken up through the waitqueue, noone will ever wake up the next waiter. This has been observed with __wait_on_bit_lock() used by lock_page_killable(): the first contender on the queue was aborting when the actual lock holder woke it up concurrently. The aborted contender didn't acquire the lock and therefor never did an unlock followed by waking up the next waiter. Add abort_exclusive_wait() which removes the process' wait descriptor from the waitqueue, iff still queued, or wakes up the next waiter otherwise. It does so under the waitqueue lock. Racing with a wake up means the aborting process is either already woken (removed from the queue) and will wake up the next waiter, or it will remove itself from the queue and the concurrent wake up will apply to the next waiter after it. Use abort_exclusive_wait() in __wait_event_interruptible_exclusive() and __wait_on_bit_lock() when they were interrupted by other means than a wake up through the queue. [akpm@linux-foundation.org: coding-style fixes] Reported-by: Chris Mason Signed-off-by: Johannes Weiner Mentored-by: Oleg Nesterov Cc: Peter Zijlstra Cc: Matthew Wilcox Cc: Chuck Lever Cc: Nick Piggin Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

PCI: irq and pci_ids patch for Intel Tigerpoint DeviceIDs

2009-02-06T21:47:23Z

commit 57064d213d2e44654d4f13c66df135b5e7389a26 upstream. This patch adds the Intel Tigerpoint LPC Controller DeviceIDs. Signed-off-by: Seth Heasley Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

kmalloc: return NULL instead of link failure

2009-02-06T21:47:19Z

commit 1cf3eb2ff6b0844c678f2f48d0053b9d12b7da67 upstream. The SLAB kmalloc with a constant value isn't consistent with the other implementations because it bails out with __you_cannot_kmalloc_that_much rather than returning NULL and properly allowing the caller to fall back to vmalloc or take other action. This doesn't happen with a non-constant value or with SLOB or SLUB. Starting with 2.6.28, I've been seeing build failures on s390x. This is due to init_section_page_cgroup trying to allocate 2.5MB when the max size for a kmalloc on s390x is 2MB. It's failing because the value is constant. The workarounds at the call size are ugly and the caller shouldn't have to change behavior depending on what the backend of the API is. So, this patch eliminates the link failure and returns NULL like the other implementations. Signed-off-by: Jeff Mahoney Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Christoph Lameter Cc: Pekka Enberg Cc: Matt Mackall Cc: Nick Piggin Signed-off-by: Andrew Morton Signed-off-by: Pekka Enberg Signed-off-by: Greg Kroah-Hartman

include/linux: Add bsg.h to the Kernel exported headers

2009-02-02T17:53:27Z

commit a229fc61ef0ee3c30fd193beee0eeb87410227f1 upstream. bsg.h in current form is perfectly suitable for user-mode consumption. It is needed together with scsi/sg.h for applications that want to interface with the bsg driver. Currently the few projects that use it would copy it over into the projects. But that is not acceptable for projects that need to provide source and devel packages for distros. This should also be submitted to stable 2.6.28 and 2.6.27 since bsg had a stable API since these Kernels and distro users will need the header for these kernels a swell Signed-off-by: Boaz Harrosh Acked-by: FUJITA Tomonori Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

epoll: drop max_user_instances and rely only on max_user_watches

2009-02-02T17:53:26Z

commit 9df04e1f25effde823a600e755b51475d438f56b upstream. Linus suggested to put limits where the money is, and max_user_watches already does that w/out the need of max_user_instances. That has the advantage to mitigate the potential DoS while allowing pretty generous default behavior. Allowing top 4% of low memory (per user) to be allocated in epoll watches, we have: LOMEM MAX_WATCHES (per user) 512MB ~178000 1GB ~356000 2GB ~712000 A box with 512MB of lomem, will meet some challenge in hitting 180K watches, socket buffers math teaches us. No more max_user_instances limits then. Signed-off-by: Davide Libenzi Cc: Willy Tarreau Cc: Michael Kerrisk Cc: Bron Gondwana Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman