linux-toradex.git/include, branch v2.6.24.3

hrtimer: check relative timeouts for overflow

2008-02-26T00:18:57+00:00

commit: 5a7780e725d1bb4c3094fcc12f1c5c5faea1e988

Various user space callers ask for relative timeouts. While we fixed
that overflow issue in hrtimer_start(), the sites which convert
relative user space values to absolute timeouts themself were uncovered.

Instead of putting overflow checks into each place add a function
which does the sanity checking and convert all affected callers to use
it.

Thanks to Frans Pop, who reported the problem and tested the fixes.

Signed-off-by: Thomas Gleixner 
Acked-by: Ingo Molnar 
Tested-by: Frans Pop 
Signed-off-by: Greg Kroah-Hartman

hrtimer: fix *rmtp handling in hrtimer_nanosleep()

2008-02-26T00:18:56+00:00

commit 080344b98805553f9b01de0f59a41b1533036d8d

Spotted by Pavel Emelyanov and Alexey Dobriyan.

hrtimer_nanosleep() sets restart_block->arg1 = rmtp, but this rmtp points to
the local variable which lives in the caller's stack frame. This means that
if sys_restart_syscall() actually happens and it is interrupted as well, we
don't update the user-space variable, but write into the already dead stack
frame.

Introduced by commit 04c227140fed77587432667a574b14736a06dd7f
hrtimer: Rework hrtimer_nanosleep to make sys_compat_nanosleep easier

Change the callers to pass "__user *rmtp" to hrtimer_nanosleep(), and change
hrtimer_nanosleep() to use copy_to_user() to actually update *rmtp.

Small problem remains. man 2 nanosleep states that *rtmp should be written if
nanosleep() was interrupted (it says nothing whether it is OK to update *rmtp
if nanosleep returns 0), but (with or without this patch) we can dirty *rem
even if nanosleep() returns 0.

NOTE: this patch doesn't change compat_sys_nanosleep(), because it has other
bugs. Fixed by the next patch.

Signed-off-by: Oleg Nesterov 
Cc: Alexey Dobriyan 
Cc: Michael Kerrisk 
Cc: Pavel Emelyanov 
Cc: Peter Zijlstra 
Cc: Toyo Abe 
Cc: Andrew Morton 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

Disable G5 NAP mode during SMU commands on U3

2008-02-26T00:18:48+00:00

patch 592a607bbc053bc6f614a0e619326009f4b3829e in mainline.

It appears that with the U3 northbridge, if the processor is in NAP
mode the whole time while waiting for an SMU command to complete,
then the SMU will fail.  It could be related to the weird backward
mechanism the SMU uses to get to system memory via i2c to the
northbridge that doesn't operate properly when the said bridge is
in napping along with the CPU.  That is on U3 at least, U4 doesn't
seem to be affected.

This didn't show before NO_HZ as the timer wakeup was enough to make
it work it seems, but that is no longer the case.

This fixes it by disabling NAP mode on those machines while
an SMU command is in flight.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

NET: Add if_addrlabel.h to sanitized headers.

2008-02-26T00:18:35+00:00

Upstream commit: dded91611a728d65721cdab3dd41d801a356fa15

if_addrlabel.h is needed for iproute2 usage.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

hugetlb: add locking for overcommit sysctl

2008-02-26T00:18:32+00:00

patch a3d0c6aa1bb342b9b2c7b123b52ac2f48a4d4d0a in mainline.

When I replaced hugetlb_dynamic_pool with nr_overcommit_hugepages I used
proc_doulongvec_minmax() directly.  However, hugetlb.c's locking rules
require that all counter modifications occur under the hugetlb_lock.  Add a
callback into the hugetlb code similar to the one for nr_hugepages.  Grab
the lock around the manipulation of nr_overcommit_hugepages in
proc_doulongvec_minmax().

Signed-off-by: Nishanth Aravamudan 
Acked-by: Adam Litke 
Cc: David Gibson 
Cc: William Lee Irwin III 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ACPI: update ACPI blacklist

2008-02-08T19:46:25+00:00

These minor changes sync the latest ACPI blacklist into 2.6.24.
The main benefit of this patch is to make any future
changes easier to apply.  The immediate benefit is one less
dmesg line on Acer systems.

Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

lockdep: annotate epoll

2008-02-08T19:46:25+00:00

patch 0ccf831cbee94df9c5006dd46248c0f07847dd7c in mainline.

On Sat, 2008-01-05 at 13:35 -0800, Davide Libenzi wrote:

> I remember I talked with Arjan about this time ago. Basically, since 1)
> you can drop an epoll fd inside another epoll fd 2) callback-based wakeups
> are used, you can see a wake_up() from inside another wake_up(), but they
> will never refer to the same lock instance.
> Think about:
>
> 	dfd = socket(...);
> 	efd1 = epoll_create();
> 	efd2 = epoll_create();
> 	epoll_ctl(efd1, EPOLL_CTL_ADD, dfd, ...);
> 	epoll_ctl(efd2, EPOLL_CTL_ADD, efd1, ...);
>
> When a packet arrives to the device underneath "dfd", the net code will
> issue a wake_up() on its poll wake list. Epoll (efd1) has installed a
> callback wakeup entry on that queue, and the wake_up() performed by the
> "dfd" net code will end up in ep_poll_callback(). At this point epoll
> (efd1) notices that it may have some event ready, so it needs to wake up
> the waiters on its poll wait list (efd2). So it calls ep_poll_safewake()
> that ends up in another wake_up(), after having checked about the
> recursion constraints. That are, no more than EP_MAX_POLLWAKE_NESTS, to
> avoid stack blasting. Never hit the same queue, to avoid loops like:
>
> 	epoll_ctl(efd2, EPOLL_CTL_ADD, efd1, ...);
> 	epoll_ctl(efd3, EPOLL_CTL_ADD, efd2, ...);
> 	epoll_ctl(efd4, EPOLL_CTL_ADD, efd3, ...);
> 	epoll_ctl(efd1, EPOLL_CTL_ADD, efd4, ...);
>
> The code "if (tncur->wq == wq || ..." prevents re-entering the same
> queue/lock.

Since the epoll code is very careful to not nest same instance locks
allow the recursion.

Signed-off-by: Peter Zijlstra 
Tested-by: Stefan Richter 
Acked-by: Davide Libenzi 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

Pull dmi-2.6.24 into release branch

2008-01-24T04:50:01+00:00

Revert "ACPI: Fan: Drop force_power_state acpi_device option"

2008-01-24T03:41:20+00:00

This reverts commit 93ad7c07ad487b036add8760dabcc35666a550ef.

http://bugzilla.kernel.org/show_bug.cgi?id=9798

Signed-off-by: Len Brown

ACPI: make _OSI(Linux) console messages smarter

2008-01-24T02:26:15+00:00

If BIOS invokes _OSI(Linux), the kernel response
depends on what the ACPI DMI list knows about the system,
and that is reflectd in dmesg:

1) System unknown to DMI:

ACPI: BIOS _OSI(Linux) query ignored
ACPI: DMI System Vendor: LENOVO
ACPI: DMI Product Name: 7661W1P
ACPI: DMI Product Version: ThinkPad T61
ACPI: DMI Board Name: 7661W1P
ACPI: DMI BIOS Vendor: LENOVO
ACPI: DMI BIOS Date: 10/18/2007
ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org

2) System known to DMI, but effect of OSI(Linux) unknown:

ACPI: DMI detected: Lenovo ThinkPad T61
...
ACPI: BIOS _OSI(Linux) query ignored via DMI
ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org

3) System known to DMI, which disables _OSI(Linux):

ACPI: DMI detected: Lenovo ThinkPad T61
...
ACPI: BIOS _OSI(Linux) query ignored via DMI

4) System known to DMI, which enable _OSI(Linux):

ACPI: DMI detected: Lenovo ThinkPad T61
ACPI: Added _OSI(Linux)
...
ACPI: BIOS _OSI(Linux) query honored via DMI

cmdline overrides take precidence over the built-in
default and the DMI prescribed default.
cmdline "acpi_osi=Linux" results in:

ACPI: BIOS _OSI(Linux) query honored via cmdline

Signed-off-by: Len Brown