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

drm/i915: add i915_lp_ring_sync helper

2010-02-23T15:37:53+00:00

commit 48764bf43f746113fc77877d7e80f2df23ca4cbb upstream.

This just waits until the hw passed the current ring position with
cmd execution. This slightly changes the existing i915_wait_request
function to make uninterruptible waiting possible - no point in
returning to userspace while mucking around with the overlay, that
piece of hw is just too fragile.

Also replace a magic 0 with the symbolic constant (and kill the then
superflous comment) while I was looking at the code.

Signed-off-by: Daniel Vetter 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_conntrack: fix hash resizing with namespaces

2010-02-23T15:37:53+00:00

commit d696c7bdaa55e2208e56c6f98e6bc1599f34286d upstream.

As noticed by Jon Masters , the conntrack hash
size is global and not per namespace, but modifiable at runtime through
/sys/module/nf_conntrack/hashsize. Changing the hash size will only
resize the hash in the current namespace however, so other namespaces
will use an invalid hash size. This can cause crashes when enlarging
the hashsize, or false negative lookups when shrinking it.

Move the hash size into the per-namespace data and only use the global
hash size to initialize the per-namespace value when instanciating a
new namespace. Additionally restrict hash resizing to init_net for
now as other namespaces are not handled currently.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_conntrack: per netns nf_conntrack_cachep

2010-02-23T15:37:53+00:00

commit 5b3501faa8741d50617ce4191c20061c6ef36cb3 upstream.

nf_conntrack_cachep is currently shared by all netns instances, but
because of SLAB_DESTROY_BY_RCU special semantics, this is wrong.

If we use a shared slab cache, one object can instantly flight between
one hash table (netns ONE) to another one (netns TWO), and concurrent
reader (doing a lookup in netns ONE, 'finding' an object of netns TWO)
can be fooled without notice, because no RCU grace period has to be
observed between object freeing and its reuse.

We dont have this problem with UDP/TCP slab caches because TCP/UDP
hashtables are global to the machine (and each object has a pointer to
its netns).

If we use per netns conntrack hash tables, we also *must* use per netns
conntrack slab caches, to guarantee an object can not escape from one
namespace to another one.

Signed-off-by: Eric Dumazet 
[Patrick: added unique slab name allocation]
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

resource: add helpers for fetching rlimits

2010-02-23T15:37:50+00:00

commit 3e10e716abf3c71bdb5d86b8f507f9e72236c9cd upstream.

We want to be sure that compiler fetches the limit variable only
once, so add helpers for fetching current and maximal resource
limits which do that.

Add them to sched.h (instead of resource.h) due to circular dependency
 sched.h->resource.h->task_struct
Alternative would be to create a separate res_access.h or similar.

Signed-off-by: Jiri Slaby 
Cc: James Morris 
Cc: Heiko Carstens 
Cc: Andrew Morton 
Cc: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

connector: Delete buggy notification code.

2010-02-09T12:50:59+00:00

commit f98bfbd78c37c5946cc53089da32a5f741efdeb7 upstream.

On Tue, Feb 02, 2010 at 02:57:14PM -0800, Greg KH (gregkh@suse.de) wrote:
> > There are at least two ways to fix it: using a big cannon and a small
> > one. The former way is to disable notification registration, since it is
> > not used by anyone at all. Second way is to check whether calling
> > process is root and its destination group is -1 (kind of priveledged
> > one) before command is dispatched to workqueue.
>
> Well if no one is using it, removing it makes the most sense, right?
>
> No objection from me, care to make up a patch either way for this?

Getting it is not used, let's drop support for notifications about
(un)registered events from connector.
Another option was to check credentials on receiving, but we can always
restore it without bugs if needed, but genetlink has a wider code base
and none complained, that userspace can not get notification when some
other clients were (un)registered.

Kudos for Sebastian Krahmer , who found a bug in the
code.

Signed-off-by: Evgeniy Polyakov 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

libata: retry link resume if necessary

2010-02-09T12:50:57+00:00

commit 5040ab67a2c6d5710ba497dc52a8f7035729d7b0 upstream.

Interestingly, when SIDPR is used in ata_piix, writes to DET in
SControl sometimes get ignored leading to detection failure.  Update
sata_link_resume() such that it reads back SControl after clearing DET
and retry if it's not clear.

Signed-off-by: Tejun Heo 
Reported-by: fengxiangjun 
Reported-by: Jim Faulkner 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

KVM: allow userspace to adjust kvmclock offset

2010-02-09T12:50:56+00:00

(cherry picked from afbcf7ab8d1bc8c2d04792f6d9e786e0adeb328d)

When we migrate a kvm guest that uses pvclock between two hosts, we may
suffer a large skew. This is because there can be significant differences
between the monotonic clock of the hosts involved. When a new host with
a much larger monotonic time starts running the guest, the view of time
will be significantly impacted.

Situation is much worse when we do the opposite, and migrate to a host with
a smaller monotonic clock.

This proposed ioctl will allow userspace to inform us what is the monotonic
clock value in the source host, so we can keep the time skew short, and
more importantly, never goes backwards. Userspace may also need to trigger
the current data, since from the first migration onwards, it won't be
reflected by a simple call to clock_gettime() anymore.

[marcelo: future-proof abi with a flags field]
[jan: fix KVM_GET_CLOCK by clearing flags field instead of checking it]

Signed-off-by: Glauber Costa 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Avi Kivity 
Signed-off-by: Greg Kroah-Hartman

ax25: netrom: rose: Fix timer oopses

2010-02-09T12:50:56+00:00

[ Upstream commit d00c362f1b0ff54161e0a42b4554ac621a9ef92d ]

Wrong ax25_cb refcounting in ax25_send_frame() and by its callers can
cause timer oopses (first reported with 2.6.29.6 kernel).

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

Reported-by: Bernard Pidoux 
Tested-by: Bernard Pidoux 
Signed-off-by: Jarek Poplawski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: restore ip source validation

2010-02-09T12:50:55+00:00

[ Upstream commit 28f6aeea3f12d37bd258b2c0d5ba891bff4ec479 ]

when using policy routing and the skb mark:
there are cases where a back path validation requires us
to use a different routing table for src ip validation than
the one used for mapping ingress dst ip.
One such a case is transparent proxying where we pretend to be
the destination system and therefore the local table
is used for incoming packets but possibly a main table would
be used on outbound.
Make the default behavior to allow the above and if users
need to turn on the symmetry via sysctl src_valid_mark

Signed-off-by: Jamal Hadi Salim 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Split 'flush_old_exec' into two functions

2010-02-09T12:50:49+00:00

commit 221af7f87b97431e3ee21ce4b0e77d5411cf1549 upstream.

'flush_old_exec()' is the point of no return when doing an execve(), and
it is pretty badly misnamed.  It doesn't just flush the old executable
environment, it also starts up the new one.

Which is very inconvenient for things like setting up the new
personality, because we want the new personality to affect the starting
of the new environment, but at the same time we do _not_ want the new
personality to take effect if flushing the old one fails.

As a result, the x86-64 '32-bit' personality is actually done using this
insane "I'm going to change the ABI, but I haven't done it yet" bit
(TIF_ABI_PENDING), with SET_PERSONALITY() not actually setting the
personality, but just the "pending" bit, so that "flush_thread()" can do
the actual personality magic.

This patch in no way changes any of that insanity, but it does split the
'flush_old_exec()' function up into a preparatory part that can fail
(still called flush_old_exec()), and a new part that will actually set
up the new exec environment (setup_new_exec()).  All callers are changed
to trivially comply with the new world order.

Signed-off-by: H. Peter Anvin 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman