linux-stable.git/include, branch linux-2.6.30.y

net: Fix thinko in backport of skb destructor fix.

2009-12-04T05:15:01+00:00

As noticed by Oliver Hartkopp, the backport of the
'net: Partially allow skb destructors to be used on receive path'
(2.6.30.y commit: 172570a224fe66d560c097e48fca15b620c76e72,
 upstream commit: d55d87fdff8252d0e2f7c28c2d443aee17e9d70f)
was buggy.

It should have added an skb_orphan() call to both skb_set_owner_w()
and skb_set_owner_r().  Instead it added two calls to skb_set_owner_r().

This fixes it up.

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

PM / PCMCIA: Drop second argument of pcmcia_socket_dev_suspend()

2009-10-05T15:28:06+00:00

commit 827b4649d4626bf97b203b4bcd69476bb9b4e760 upstream.

pcmcia_socket_dev_suspend() doesn't use its second argument, so it
may be dropped safely.

This change is necessary for the subsequent yenta suspend/resume fix.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: Disallow hypercalls for guest callers in rings > 0

2009-10-05T15:27:54+00:00

(cherry picked from commit 07708c4af1346ab1521b26a202f438366b7bcffd)

So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by passing random addresses.

To close the hole, this patch considers hypercalls valid only if issued
from guest ring 0. This may still be relaxed on a per-hypercall base in
the future once required.

Signed-off-by: Jan Kiszka 
Signed-off-by: Avi Kivity 
Signed-off-by: Greg Kroah-Hartman

vfs: add __destroy_inode

2009-09-09T03:33:56+00:00

backport of upstream commit 2e00c97e2c1d2ffc9e26252ca26b237678b0b772

When we want to tear down an inode that lost the add to the cache race
in XFS we must not call into ->destroy_inode because that would delete
the inode that won the race from the inode cache radix tree.

This patch provides the __destroy_inode helper needed to fix this,
the actual fix will be in th next patch.  As XFS was the only reason
destroy_inode was exported we shift the export to the new __destroy_inode.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Eric Sandeen 
Signed-off-by: Greg Kroah-Hartman

vfs: fix inode_init_always calling convention

2009-09-09T03:33:54+00:00

backport of upstream commit 54e346215e4fe2ca8c94c54e546cc61902060510

Currently inode_init_always calls into ->destroy_inode if the additional
initialization fails.  That's not only counter-intuitive because
inode_init_always did not allocate the inode structure, but in case of
XFS it's actively harmful as ->destroy_inode might delete the inode from
a radix-tree that has never been added.  This in turn might end up
deleting the inode for the same inum that has been instanciated by
another process and cause lots of cause subtile problems.

Also in the case of re-initializing a reclaimable inode in XFS it would
free an inode we still want to keep alive.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Eric Sandeen 
Signed-off-by: Greg Kroah-Hartman

ACPI processor: force throttling state when BIOS returns incorrect value

2009-09-09T03:33:54+00:00

commit 2a908002c7b1b666616103e9df2419b38d7c6f1f upstream.

If the BIOS reports an invalid throttling state (which seems to be
fairly common after system boot), a reset is done to state T0.
Because of a check in acpi_processor_get_throttling_ptc(), the reset
never actually gets executed, which results in the error reoccurring
on every access of for example /proc/acpi/processor/CPU0/throttling.

Add a 'force' option to acpi_processor_set_throttling() to ensure
the reset really takes effect.

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

This patch, together with the next one, fixes a regression introduced in
2.6.30, listed on the regression list. They have been available for 2.5
months now in bugzilla, but have not been picked up, despite various
reminders and without any reason given.

Google shows that numerous people are hitting this issue. The issue is in
itself relatively minor, but the bug in the code is clear.

The patches have been in all my kernels and today testing has shown that
throttling works correctly with the patches applied when the system
overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14).

Signed-off-by: Frans Pop 
Acked-by: Zhang Rui 
Cc: Len Brown 
Cc: "Rafael J. Wysocki" 
Cc: Rusty Russell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

KVM: fix ack not being delivered when msi present

2009-09-09T03:33:37+00:00

(cherry picked from commit 5116d8f6b977970ebefc1932c0f313163a6ec91f)

kvm_notify_acked_irq does not check irq type, so that it sometimes
interprets msi vector as irq.  As a result, ack notifiers are not
called, which typially hangs the guest.  The fix is to track and
check irq type.

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Avi Kivity 
Signed-off-by: Greg Kroah-Hartman

kernel_read: redefine offset type

2009-09-09T03:33:22+00:00

commit 6777d773a463ac045d333b989d4e44660f8d92ad upstream.

vfs_read() offset is defined as loff_t, but kernel_read()
offset is only defined as unsigned long. Redefine
kernel_read() offset as loff_t.

Signed-off-by: Mimi Zohar 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

mm: fix hugetlb bug due to user_shm_unlock call

2009-09-09T03:33:20+00:00

commit 353d5c30c666580347515da609dd74a2b8e9b828 upstream.

2.6.30's commit 8a0bdec194c21c8fdef840989d0d7b742bb5d4bc removed
user_shm_lock() calls in hugetlb_file_setup() but left the
user_shm_unlock call in shm_destroy().

In detail:
Assume that can_do_hugetlb_shm() returns true and hence user_shm_lock()
is not called in hugetlb_file_setup(). However, user_shm_unlock() is
called in any case in shm_destroy() and in the following
atomic_dec_and_lock(&up->__count) in free_uid() is executed and if
up->__count gets zero, also cleanup_user_struct() is scheduled.

Note that sched_destroy_user() is empty if CONFIG_USER_SCHED is not set.
However, the ref counter up->__count gets unexpectedly non-positive and
the corresponding structs are freed even though there are live
references to them, resulting in a kernel oops after a lots of
shmget(SHM_HUGETLB)/shmctl(IPC_RMID) cycles and CONFIG_USER_SCHED set.

Hugh changed Stefan's suggested patch: can_do_hugetlb_shm() at the
time of shm_destroy() may give a different answer from at the time
of hugetlb_file_setup().  And fixed newseg()'s no_id error path,
which has missed user_shm_unlock() ever since it came in 2.6.9.

Reported-by: Stefan Huber 
Signed-off-by: Hugh Dickins 
Tested-by: Stefan Huber 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Make bitmask 'and' operators return a result code

2009-09-09T03:33:14+00:00

commit f4b0373b26567cafd421d91101852ed7a34e9e94 upstream.

When 'and'ing two bitmasks (where 'andnot' is a variation on it), some
cases want to know whether the result is the empty set or not.  In
particular, the TLB IPI sending code wants to do cpumask operations and
determine if there are any CPU's left in the final set.

So this just makes the bitmask (and cpumask) functions return a boolean
for whether the result has any bits set.

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman