* [01/23] aio: wake all waiters when destroying ctx
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [02/23] shmem: let shared anonymous be nonlinear again Greg KH
` (22 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: stable-review, torvalds, akpm, alan, Roland Dreier
[-- Attachment #1: aio-wake-all-waiters-when-destroying-ctx.patch --]
[-- Type: text/plain, Size: 1915 bytes --]
From: Roland Dreier <roland@purestorage.com>
commit e91f90bb0bb10be9cc8efd09a3cf4ecffcad0db1 upstream.
The test program below will hang because io_getevents() uses
add_wait_queue_exclusive(), which means the wake_up() in io_destroy() only
wakes up one of the threads. Fix this by using wake_up_all() in the aio
code paths where we want to make sure no one gets stuck.
// t.c -- compile with gcc -lpthread -laio t.c
#include <libaio.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
static const int nthr = 2;
void *getev(void *ctx)
{
struct io_event ev;
io_getevents(ctx, 1, 1, &ev, NULL);
printf("io_getevents returned\n");
return NULL;
}
int main(int argc, char *argv[])
{
io_context_t ctx = 0;
pthread_t thread[nthr];
int i;
io_setup(1024, &ctx);
for (i = 0; i < nthr; ++i)
pthread_create(&thread[i], NULL, getev, ctx);
sleep(1);
io_destroy(ctx);
for (i = 0; i < nthr; ++i)
pthread_join(thread[i], NULL);
return 0;
}
Signed-off-by: Roland Dreier <roland@purestorage.com>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/aio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -497,7 +497,7 @@ static inline void really_put_req(struct
ctx->reqs_active--;
if (unlikely(!ctx->reqs_active && ctx->dead))
- wake_up(&ctx->wait);
+ wake_up_all(&ctx->wait);
}
static void aio_fput_routine(struct work_struct *data)
@@ -1219,7 +1219,7 @@ static void io_destroy(struct kioctx *io
* by other CPUs at this point. Right now, we rely on the
* locking done by the above calls to ensure this consistency.
*/
- wake_up(&ioctx->wait);
+ wake_up_all(&ioctx->wait);
put_ioctx(ioctx); /* once for the lookup */
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [02/23] shmem: let shared anonymous be nonlinear again
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
2011-03-25 23:55 ` [01/23] aio: wake all waiters when destroying ctx Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [03/23] PCI hotplug: acpiphp: set current_state to D0 in register_slot Greg KH
` (21 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: stable-review, torvalds, akpm, alan, Hugh Dickins
[-- Attachment #1: shmem-let-shared-anonymous-be-nonlinear-again.patch --]
[-- Type: text/plain, Size: 1008 bytes --]
From: Hugh Dickins <hughd@google.com>
commit bee4c36a5cf5c9f63ce1d7372aa62045fbd16d47 upstream.
Up to 2.6.22, you could use remap_file_pages(2) on a tmpfs file or a
shared mapping of /dev/zero or a shared anonymous mapping. In 2.6.23 we
disabled it by default, but set VM_CAN_NONLINEAR to enable it on safe
mappings. We made sure to set it in shmem_mmap() for tmpfs files, but
missed it in shmem_zero_setup() for the others. Fix that at last.
Reported-by: Kenny Simpson <theonetruekenny@yahoo.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
mm/shmem.c | 1 +
1 file changed, 1 insertion(+)
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2691,5 +2691,6 @@ int shmem_zero_setup(struct vm_area_stru
fput(vma->vm_file);
vma->vm_file = file;
vma->vm_ops = &shmem_vm_ops;
+ vma->vm_flags |= VM_CAN_NONLINEAR;
return 0;
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [03/23] PCI hotplug: acpiphp: set current_state to D0 in register_slot
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
2011-03-25 23:55 ` [01/23] aio: wake all waiters when destroying ctx Greg KH
2011-03-25 23:55 ` [02/23] shmem: let shared anonymous be nonlinear again Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [04/23] xen: set max_pfn_mapped to the last pfn mapped Greg KH
` (20 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Stefano Stabellini,
Jesse Barnes
[-- Attachment #1: pci-hotplug-acpiphp-set-current_state-to-d0-in-register_slot.patch --]
[-- Type: text/plain, Size: 2026 bytes --]
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
commit 47e9037ac16637cd7f12b8790ea7ce6680e42168 upstream.
If a device doesn't support power management (pm_cap == 0) but it is
acpi_pci_power_manageable() because there is a _PS0 method declared for
it and _EJ0 is also declared for the slot then nobody is going to set
current_state = PCI_D0 for this device. This is what I think it is
happening:
pci_enable_device
|
__pci_enable_device_flags
/* here we do not set current_state because !pm_cap */
|
do_pci_enable_device
|
pci_set_power_state
|
__pci_start_power_transition
|
pci_platform_power_transition
/* platform_pci_power_manageable() calls acpi_pci_power_manageable that
* returns true */
|
platform_pci_set_power_state
/* acpi_pci_set_power_state gets called and does nothing because the
* acpi device has _EJ0, see the comment "If the ACPI device has _EJ0,
* ignore the device" */
at this point if we refer to the commit message that introduced the
comment above (10b3dcae0f275e2546e55303d64ddbb58cec7599), it is up to
the hotplug driver to set the state to D0.
However AFAICT the pci hotplug driver never does, in fact
drivers/pci/hotplug/acpiphp_glue.c:register_slot sets the slot flags to
(SLOT_ENABLED | SLOT_POWEREDON) but it does not set the pci device
current state to PCI_D0.
So my proposed fix is also to set current_state = PCI_D0 in
register_slot.
Comments are very welcome.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/pci/hotplug/acpiphp_glue.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -213,6 +213,7 @@ register_slot(acpi_handle handle, u32 lv
pdev = pci_get_slot(pbus, PCI_DEVFN(device, function));
if (pdev) {
+ pdev->current_state = PCI_D0;
slot->flags |= (SLOT_ENABLED | SLOT_POWEREDON);
pci_dev_put(pdev);
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [04/23] xen: set max_pfn_mapped to the last pfn mapped
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (2 preceding siblings ...)
2011-03-25 23:55 ` [03/23] PCI hotplug: acpiphp: set current_state to D0 in register_slot Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [05/23] x86: Cleanup highmap after brk is concluded Greg KH
` (19 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Stefano Stabellini,
Konrad Rzeszutek Wilk, H. Peter Anvin
[-- Attachment #1: xen-set-max_pfn_mapped-to-the-last-pfn-mapped.patch --]
[-- Type: text/plain, Size: 1949 bytes --]
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
commit 14988a4d350ce3b41ecad4f63c4f44c56f5ae34d upstream.
Do not set max_pfn_mapped to the end of the initial memory mappings,
that also contain pages that don't belong in pfn space (like the mfn
list).
Set max_pfn_mapped to the last real pfn mapped in the initial memory
mappings that is the pfn backing _end.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
LKML-Reference: <alpine.DEB.2.00.1103171739050.3382@kaball-desktop>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/x86/xen/mmu.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1658,9 +1658,6 @@ static __init void xen_map_identity_earl
for (pteidx = 0; pteidx < PTRS_PER_PTE; pteidx++, pfn++) {
pte_t pte;
- if (pfn > max_pfn_mapped)
- max_pfn_mapped = pfn;
-
if (!pte_none(pte_page[pteidx]))
continue;
@@ -1704,6 +1701,12 @@ __init pgd_t *xen_setup_kernel_pagetable
pud_t *l3;
pmd_t *l2;
+ /* max_pfn_mapped is the last pfn mapped in the initial memory
+ * mappings. Considering that on Xen after the kernel mappings we
+ * have the mappings of some pages that don't exist in pfn space, we
+ * set max_pfn_mapped to the last real pfn mapped. */
+ max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->mfn_list));
+
/* Zap identity mapping */
init_level4_pgt[0] = __pgd(0);
@@ -1767,9 +1770,7 @@ __init pgd_t *xen_setup_kernel_pagetable
{
pmd_t *kernel_pmd;
- max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->pt_base) +
- xen_start_info->nr_pt_frames * PAGE_SIZE +
- 512*1024);
+ max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->mfn_list));
kernel_pmd = m2v(pgd[KERNEL_PGD_BOUNDARY].pgd);
memcpy(level2_kernel_pgt, kernel_pmd, sizeof(pmd_t) * PTRS_PER_PMD);
^ permalink raw reply [flat|nested] 26+ messages in thread* [05/23] x86: Cleanup highmap after brk is concluded
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (3 preceding siblings ...)
2011-03-25 23:55 ` [04/23] xen: set max_pfn_mapped to the last pfn mapped Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [06/23] PCI: return correct value when writing to the "reset" attribute Greg KH
` (18 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Yinghai Lu,
Stefano Stabellini, H. Peter Anvin
[-- Attachment #1: x86-cleanup-highmap-after-brk-is-concluded.patch --]
[-- Type: text/plain, Size: 4131 bytes --]
From: Yinghai Lu <yinghai@kernel.org>
commit e5f15b45ddf3afa2bbbb10c7ea34fb32b6de0a0e upstream.
Now cleanup_highmap actually is in two steps: one is early in head64.c
and only clears above _end; a second one is in init_memory_mapping() and
tries to clean from _brk_end to _end.
It should check if those boundaries are PMD_SIZE aligned but currently
does not.
Also init_memory_mapping() is called several times for numa or memory
hotplug, so we really should not handle initial kernel mappings there.
This patch moves cleanup_highmap() down after _brk_end is settled so
we can do everything in one step.
Also we honor max_pfn_mapped in the implementation of cleanup_highmap.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
LKML-Reference: <alpine.DEB.2.00.1103171739050.3382@kaball-desktop>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/x86/kernel/head64.c | 3 ---
arch/x86/kernel/setup.c | 5 +++++
arch/x86/mm/init.c | 19 -------------------
arch/x86/mm/init_64.c | 11 ++++++-----
4 files changed, 11 insertions(+), 27 deletions(-)
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -76,9 +76,6 @@ void __init x86_64_start_kernel(char * r
/* Make NULL pointers segfault */
zap_identity_mappings();
- /* Cleanup the over mapped high alias */
- cleanup_highmap();
-
for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) {
#ifdef CONFIG_EARLY_PRINTK
set_intr_gate(i, &early_idt_handlers[i]);
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -294,6 +294,9 @@ static void __init init_gbpages(void)
static inline void init_gbpages(void)
{
}
+static void __init cleanup_highmap(void)
+{
+}
#endif
static void __init reserve_brk(void)
@@ -921,6 +924,8 @@ void __init setup_arch(char **cmdline_p)
reserve_brk();
+ cleanup_highmap();
+
init_gbpages();
/* max_pfn_mapped is updated here */
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -287,25 +287,6 @@ unsigned long __init_refok init_memory_m
load_cr3(swapper_pg_dir);
#endif
-#ifdef CONFIG_X86_64
- if (!after_bootmem && !start) {
- pud_t *pud;
- pmd_t *pmd;
-
- mmu_cr4_features = read_cr4();
-
- /*
- * _brk_end cannot change anymore, but it and _end may be
- * located on different 2M pages. cleanup_highmap(), however,
- * can only consider _end when it runs, so destroy any
- * mappings beyond _brk_end here.
- */
- pud = pud_offset(pgd_offset_k(_brk_end), _brk_end);
- pmd = pmd_offset(pud, _brk_end - 1);
- while (++pmd <= pmd_offset(pud, (unsigned long)_end - 1))
- pmd_clear(pmd);
- }
-#endif
__flush_tlb_all();
if (!after_bootmem && e820_table_end > e820_table_start)
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -49,6 +49,7 @@
#include <asm/numa.h>
#include <asm/cacheflush.h>
#include <asm/init.h>
+#include <asm/setup.h>
#include <linux/bootmem.h>
static unsigned long dma_reserve __initdata;
@@ -257,18 +258,18 @@ void __init init_extra_mapping_uc(unsign
* to the compile time generated pmds. This results in invalid pmds up
* to the point where we hit the physaddr 0 mapping.
*
- * We limit the mappings to the region from _text to _end. _end is
- * rounded up to the 2MB boundary. This catches the invalid pmds as
+ * We limit the mappings to the region from _text to _brk_end. _brk_end
+ * is rounded up to the 2MB boundary. This catches the invalid pmds as
* well, as they are located before _text:
*/
void __init cleanup_highmap(void)
{
unsigned long vaddr = __START_KERNEL_map;
- unsigned long end = roundup((unsigned long)_end, PMD_SIZE) - 1;
+ unsigned long vaddr_end = __START_KERNEL_map + (max_pfn_mapped << PAGE_SHIFT);
+ unsigned long end = roundup((unsigned long)_brk_end, PMD_SIZE) - 1;
pmd_t *pmd = level2_kernel_pgt;
- pmd_t *last_pmd = pmd + PTRS_PER_PMD;
- for (; pmd < last_pmd; pmd++, vaddr += PMD_SIZE) {
+ for (; vaddr + PMD_SIZE - 1 < vaddr_end; pmd++, vaddr += PMD_SIZE) {
if (pmd_none(*pmd))
continue;
if (vaddr < (unsigned long) _text || vaddr > end)
^ permalink raw reply [flat|nested] 26+ messages in thread* [06/23] PCI: return correct value when writing to the "reset" attribute
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (4 preceding siblings ...)
2011-03-25 23:55 ` [05/23] x86: Cleanup highmap after brk is concluded Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [07/23] Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code Greg KH
` (17 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Michael S. Tsirkin,
Michal Schmidt, Jesse Barnes
[-- Attachment #1: pci-return-correct-value-when-writing-to-the-reset-attribute.patch --]
[-- Type: text/plain, Size: 995 bytes --]
From: Michal Schmidt <mschmidt@redhat.com>
commit 447c5dd7338638f526e9bcf7dcf69b4da5835c7d upstream.
A successful write() to the "reset" sysfs attribute should return the
number of bytes written, not 0. Otherwise userspace (bash) retries the
write over and over again.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/pci/pci-sysfs.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -939,7 +939,12 @@ static ssize_t reset_store(struct device
if (val != 1)
return -EINVAL;
- return pci_reset_function(pdev);
+
+ result = pci_reset_function(pdev);
+ if (result < 0)
+ return result;
+
+ return count;
}
static struct device_attribute reset_attr = __ATTR(reset, 0200, NULL, reset_store);
^ permalink raw reply [flat|nested] 26+ messages in thread* [07/23] Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (5 preceding siblings ...)
2011-03-25 23:55 ` [06/23] PCI: return correct value when writing to the "reset" attribute Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [08/23] ext3: skip orphan cleanup on rocompat fs Greg KH
` (16 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Julien Tinnes, Oleg Nesterov
[-- Attachment #1: prevent-rt_sigqueueinfo-and-rt_tgsigqueueinfo-from-spoofing-the-signal-code.patch --]
[-- Type: text/plain, Size: 2231 bytes --]
From: Julien Tinnes <jln@google.com>
commit da48524eb20662618854bb3df2db01fc65f3070c upstream.
Userland should be able to trust the pid and uid of the sender of a
signal if the si_code is SI_TKILL.
Unfortunately, the kernel has historically allowed sigqueueinfo() to
send any si_code at all (as long as it was negative - to distinguish it
from kernel-generated signals like SIGILL etc), so it could spoof a
SI_TKILL with incorrect siginfo values.
Happily, it looks like glibc has always set si_code to the appropriate
SI_QUEUE, so there are probably no actual user code that ever uses
anything but the appropriate SI_QUEUE flag.
So just tighten the check for si_code (we used to allow any negative
value), and add a (one-time) warning in case there are binaries out
there that might depend on using other si_code values.
Signed-off-by: Julien Tinnes <jln@google.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
kernel/signal.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2351,9 +2351,13 @@ SYSCALL_DEFINE3(rt_sigqueueinfo, pid_t,
return -EFAULT;
/* Not even root can pretend to send signals from the kernel.
- Nor can they impersonate a kill(), which adds source info. */
- if (info.si_code >= 0)
+ * Nor can they impersonate a kill()/tgkill(), which adds source info.
+ */
+ if (info.si_code != SI_QUEUE) {
+ /* We used to allow any < 0 si_code */
+ WARN_ON_ONCE(info.si_code < 0);
return -EPERM;
+ }
info.si_signo = sig;
/* POSIX.1b doesn't mention process groups. */
@@ -2367,9 +2371,13 @@ long do_rt_tgsigqueueinfo(pid_t tgid, pi
return -EINVAL;
/* Not even root can pretend to send signals from the kernel.
- Nor can they impersonate a kill(), which adds source info. */
- if (info->si_code >= 0)
+ * Nor can they impersonate a kill()/tgkill(), which adds source info.
+ */
+ if (info->si_code != SI_QUEUE) {
+ /* We used to allow any < 0 si_code */
+ WARN_ON_ONCE(info->si_code < 0);
return -EPERM;
+ }
info->si_signo = sig;
return do_send_specific(tgid, pid, sig, info);
^ permalink raw reply [flat|nested] 26+ messages in thread* [08/23] ext3: skip orphan cleanup on rocompat fs
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (6 preceding siblings ...)
2011-03-25 23:55 ` [07/23] Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [09/23] procfs: fix /proc/<pid>/maps heap check Greg KH
` (15 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Amir Goldstein, Jan Kara
[-- Attachment #1: ext3-skip-orphan-cleanup-on-rocompat-fs.patch --]
[-- Type: text/plain, Size: 1213 bytes --]
From: Amir Goldstein <amir73il@gmail.com>
commit ce654b37f87980d95f339080e4c3bdb2370bdf22 upstream.
Orphan cleanup is currently executed even if the file system has some
number of unknown ROCOMPAT features, which deletes inodes and frees
blocks, which could be very bad for some RO_COMPAT features.
This patch skips the orphan cleanup if it contains readonly compatible
features not known by this ext3 implementation, which would prevent
the fs from being mounted (or remounted) readwrite.
Signed-off-by: Amir Goldstein <amir73il@users.sf.net>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/ext3/super.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -1404,6 +1404,13 @@ static void ext3_orphan_cleanup (struct
return;
}
+ /* Check if feature set allows readwrite operations */
+ if (EXT3_HAS_RO_COMPAT_FEATURE(sb, ~EXT3_FEATURE_RO_COMPAT_SUPP)) {
+ printk(KERN_INFO "EXT3-fs: %s: Skipping orphan cleanup due to "
+ "unknown ROCOMPAT features\n", sb->s_id);
+ return;
+ }
+
if (EXT3_SB(sb)->s_mount_state & EXT3_ERROR_FS) {
if (es->s_last_orphan)
jbd_debug(1, "Errors on filesystem, "
^ permalink raw reply [flat|nested] 26+ messages in thread* [09/23] procfs: fix /proc/<pid>/maps heap check
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (7 preceding siblings ...)
2011-03-25 23:55 ` [08/23] ext3: skip orphan cleanup on rocompat fs Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [10/23] proc: protect mm start_code/end_code in /proc/pid/stat Greg KH
` (14 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: stable-review, torvalds, akpm, alan, Aaro Koskinen
[-- Attachment #1: procfs-fix-proc-pid-maps-heap-check.patch --]
[-- Type: text/plain, Size: 3375 bytes --]
From: Aaro Koskinen <aaro.koskinen@nokia.com>
commit 0db0c01b53a1a421513f91573241aabafb87802a upstream.
The current code fails to print the "[heap]" marking if the heap is split
into multiple mappings.
Fix the check so that the marking is displayed in all possible cases:
1. vma matches exactly the heap
2. the heap vma is merged e.g. with bss
3. the heap vma is splitted e.g. due to locked pages
Test cases. In all cases, the process should have mapping(s) with
[heap] marking:
(1) vma matches exactly the heap
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main (void)
{
if (sbrk(4096) != (void *)-1) {
printf("check /proc/%d/maps\n", (int)getpid());
while (1)
sleep(1);
}
return 0;
}
# ./test1
check /proc/553/maps
[1] + Stopped ./test1
# cat /proc/553/maps | head -4
00008000-00009000 r-xp 00000000 01:00 3113640 /test1
00010000-00011000 rw-p 00000000 01:00 3113640 /test1
00011000-00012000 rw-p 00000000 00:00 0 [heap]
4006f000-40070000 rw-p 00000000 00:00 0
(2) the heap vma is merged
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
char foo[4096] = "foo";
char bar[4096];
int main (void)
{
if (sbrk(4096) != (void *)-1) {
printf("check /proc/%d/maps\n", (int)getpid());
while (1)
sleep(1);
}
return 0;
}
# ./test2
check /proc/556/maps
[2] + Stopped ./test2
# cat /proc/556/maps | head -4
00008000-00009000 r-xp 00000000 01:00 3116312 /test2
00010000-00012000 rw-p 00000000 01:00 3116312 /test2
00012000-00014000 rw-p 00000000 00:00 0 [heap]
4004a000-4004b000 rw-p 00000000 00:00 0
(3) the heap vma is splitted (this fails without the patch)
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
int main (void)
{
if ((sbrk(4096) != (void *)-1) && !mlockall(MCL_FUTURE) &&
(sbrk(4096) != (void *)-1)) {
printf("check /proc/%d/maps\n", (int)getpid());
while (1)
sleep(1);
}
return 0;
}
# ./test3
check /proc/559/maps
[1] + Stopped ./test3
# cat /proc/559/maps|head -4
00008000-00009000 r-xp 00000000 01:00 3119108 /test3
00010000-00011000 rw-p 00000000 01:00 3119108 /test3
00011000-00012000 rw-p 00000000 00:00 0 [heap]
00012000-00013000 rw-p 00000000 00:00 0 [heap]
It looks like the bug has been there forever, and since it only results in
some information missing from a procfile, it does not fulfil the -stable
"critical issue" criteria.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/proc/task_mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -244,8 +244,8 @@ static void show_map_vma(struct seq_file
const char *name = arch_vma_name(vma);
if (!name) {
if (mm) {
- if (vma->vm_start <= mm->start_brk &&
- vma->vm_end >= mm->brk) {
+ if (vma->vm_start <= mm->brk &&
+ vma->vm_end >= mm->start_brk) {
name = "[heap]";
} else if (vma->vm_start <= mm->start_stack &&
vma->vm_end >= mm->start_stack) {
^ permalink raw reply [flat|nested] 26+ messages in thread* [10/23] proc: protect mm start_code/end_code in /proc/pid/stat
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (8 preceding siblings ...)
2011-03-25 23:55 ` [09/23] procfs: fix /proc/<pid>/maps heap check Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [11/23] fbcon: Bugfix soft cursor detection in Tile Blitting Greg KH
` (13 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Kees Cook, Alexey Dobriyan,
David Howells, Eugene Teo, Martin Schwidefsky, Brad Spengler
[-- Attachment #1: proc-protect-mm-start_code-end_code-in-proc-pid-stat.patch --]
[-- Type: text/plain, Size: 1521 bytes --]
From: Kees Cook <kees.cook@canonical.com>
commit 5883f57ca0008ffc93e09cbb9847a1928e50c6f3 upstream.
While mm->start_stack was protected from cross-uid viewing (commit
f83ce3e6b02d5 ("proc: avoid information leaks to non-privileged
processes")), the start_code and end_code values were not. This would
allow the text location of a PIE binary to leak, defeating ASLR.
Note that the value "1" is used instead of "0" for a protected value since
"ps", "killall", and likely other readers of /proc/pid/stat, take
start_code of "0" to mean a kernel thread and will misbehave. Thanks to
Brad Spengler for pointing this out.
Addresses CVE-2011-0726
Signed-off-by: Kees Cook <kees.cook@canonical.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Eugene Teo <eugeneteo@kernel.sg>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Brad Spengler <spender@grsecurity.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/proc/array.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -473,8 +473,8 @@ static int do_task_stat(struct seq_file
vsize,
mm ? get_mm_rss(mm) : 0,
rsslim,
- mm ? mm->start_code : 0,
- mm ? mm->end_code : 0,
+ mm ? (permitted ? mm->start_code : 1) : 0,
+ mm ? (permitted ? mm->end_code : 1) : 0,
(permitted && mm) ? mm->start_stack : 0,
esp,
eip,
^ permalink raw reply [flat|nested] 26+ messages in thread* [11/23] fbcon: Bugfix soft cursor detection in Tile Blitting
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (9 preceding siblings ...)
2011-03-25 23:55 ` [10/23] proc: protect mm start_code/end_code in /proc/pid/stat Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [12/23] nfsd41: modify the members value of nfsd4_op_flags Greg KH
` (12 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Henry Nestler, Paul Mundt
[-- Attachment #1: fbcon-bugfix-soft-cursor-detection-in-tile-blitting.patch --]
[-- Type: text/plain, Size: 1141 bytes --]
From: Henry Nestler <henry.nestler@gmail.com>
commit d6244bc0ed0c52a795e6f4dcab3886daf3e74fac upstream.
Use mask 0x10 for "soft cursor" detection on in function tile_cursor.
(Tile Blitting Operation in framebuffer console).
The old mask 0x01 for vc_cursor_type detects CUR_NONE, CUR_LOWER_THIRD
and every second mode value as "software cursor". This hides the cursor
for these modes (cursor.mode = 0). But, only CUR_NONE or "software cursor"
should hide the cursor.
See also 0x10 in functions add_softcursor, bit_cursor and cw_cursor.
Signed-off-by: Henry Nestler <henry.nestler@gmail.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/video/console/tileblit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/video/console/tileblit.c
+++ b/drivers/video/console/tileblit.c
@@ -83,7 +83,7 @@ static void tile_cursor(struct vc_data *
int softback_lines, int fg, int bg)
{
struct fb_tilecursor cursor;
- int use_sw = (vc->vc_cursor_type & 0x01);
+ int use_sw = (vc->vc_cursor_type & 0x10);
cursor.sx = vc->vc_x;
cursor.sy = vc->vc_y;
^ permalink raw reply [flat|nested] 26+ messages in thread* [12/23] nfsd41: modify the members value of nfsd4_op_flags
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (10 preceding siblings ...)
2011-03-25 23:55 ` [11/23] fbcon: Bugfix soft cursor detection in Tile Blitting Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [13/23] nfsd: wrong index used in inner loop Greg KH
` (11 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Mi Jinlong, J. Bruce Fields
[-- Attachment #1: nfsd41-modify-the-members-value-of-nfsd4_op_flags.patch --]
[-- Type: text/plain, Size: 1285 bytes --]
From: Mi Jinlong <mijinlong@cn.fujitsu.com>
commit 5ece3cafbd88d4da5c734e1810c4a2e6474b57b2 upstream.
The members of nfsd4_op_flags, (ALLOWED_WITHOUT_FH | ALLOWED_ON_ABSENT_FS)
equals to ALLOWED_AS_FIRST_OP, maybe that's not what we want.
OP_PUTROOTFH with op_flags = ALLOWED_WITHOUT_FH | ALLOWED_ON_ABSENT_FS,
can't appears as the first operation with out SEQUENCE ops.
This patch modify the wrong value of ALLOWED_WITHOUT_FH etc which
was introduced by f9bb94c4.
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/nfsd/nfs4proc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -964,8 +964,8 @@ typedef __be32(*nfsd4op_func)(struct svc
void *);
enum nfsd4_op_flags {
ALLOWED_WITHOUT_FH = 1 << 0, /* No current filehandle required */
- ALLOWED_ON_ABSENT_FS = 2 << 0, /* ops processed on absent fs */
- ALLOWED_AS_FIRST_OP = 3 << 0, /* ops reqired first in compound */
+ ALLOWED_ON_ABSENT_FS = 1 << 1, /* ops processed on absent fs */
+ ALLOWED_AS_FIRST_OP = 1 << 2, /* ops reqired first in compound */
};
struct nfsd4_operation {
^ permalink raw reply [flat|nested] 26+ messages in thread* [13/23] nfsd: wrong index used in inner loop
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (11 preceding siblings ...)
2011-03-25 23:55 ` [12/23] nfsd41: modify the members value of nfsd4_op_flags Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [14/23] [media] uvcvideo: Fix uvc_fixup_video_ctrl() format search Greg KH
` (10 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Mi Jinlong, J. Bruce Fields
[-- Attachment #1: nfsd-wrong-index-used-in-inner-loop.patch --]
[-- Type: text/plain, Size: 1189 bytes --]
From: Mi Jinlong <mijinlong@cn.fujitsu.com>
commit 5a02ab7c3c4580f94d13c683721039855b67cda6 upstream.
We must not use dummy for index.
After the first index, READ32(dummy) will change dummy!!!!
Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
[bfields@redhat.com: Trond points out READ_BUF alone is sufficient.]
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/nfsd/nfs4xdr.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -1114,7 +1114,7 @@ nfsd4_decode_create_session(struct nfsd4
u32 dummy;
char *machine_name;
- int i, j;
+ int i;
int nr_secflavs;
READ_BUF(16);
@@ -1187,8 +1187,6 @@ nfsd4_decode_create_session(struct nfsd4
READ_BUF(4);
READ32(dummy);
READ_BUF(dummy * 4);
- for (j = 0; j < dummy; ++j)
- READ32(dummy);
break;
case RPC_AUTH_GSS:
dprintk("RPC_AUTH_GSS callback secflavor "
@@ -1204,7 +1202,6 @@ nfsd4_decode_create_session(struct nfsd4
READ_BUF(4);
READ32(dummy);
READ_BUF(dummy);
- p += XDR_QUADLEN(dummy);
break;
default:
dprintk("Illegal callback secflavor\n");
^ permalink raw reply [flat|nested] 26+ messages in thread* [14/23] [media] uvcvideo: Fix uvc_fixup_video_ctrl() format search
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (12 preceding siblings ...)
2011-03-25 23:55 ` [13/23] nfsd: wrong index used in inner loop Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [15/23] ehci-hcd: Bug fix: dont set a QHs Halt bit Greg KH
` (9 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Stephan Lachowsky,
Mauro Carvalho Chehab
[-- Attachment #1: uvcvideo-fix-uvc_fixup_video_ctrl-format-search.patch --]
[-- Type: text/plain, Size: 1513 bytes --]
From: Stephan Lachowsky <stephan.lachowsky@maxim-ic.com>
commit 38a66824d96de8aeeb915e6f46f0d3fe55828eb1 upstream.
The scheme used to index format in uvc_fixup_video_ctrl() is not robust:
format index is based on descriptor ordering, which does not necessarily
match bFormatIndex ordering. Searching for first matching format will
prevent uvc_fixup_video_ctrl() from using the wrong format/frame to make
adjustments.
Signed-off-by: Stephan Lachowsky <stephan.lachowsky@maxim-ic.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/media/video/uvc/uvc_video.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -64,15 +64,19 @@ int uvc_query_ctrl(struct uvc_device *de
static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
struct uvc_streaming_control *ctrl)
{
- struct uvc_format *format;
+ struct uvc_format *format = NULL;
struct uvc_frame *frame = NULL;
unsigned int i;
- if (ctrl->bFormatIndex <= 0 ||
- ctrl->bFormatIndex > stream->nformats)
- return;
+ for (i = 0; i < stream->nformats; ++i) {
+ if (stream->format[i].index == ctrl->bFormatIndex) {
+ format = &stream->format[i];
+ break;
+ }
+ }
- format = &stream->format[ctrl->bFormatIndex - 1];
+ if (format == NULL)
+ return;
for (i = 0; i < format->nframes; ++i) {
if (format->frame[i].bFrameIndex == ctrl->bFrameIndex) {
^ permalink raw reply [flat|nested] 26+ messages in thread* [15/23] ehci-hcd: Bug fix: dont set a QHs Halt bit
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (13 preceding siblings ...)
2011-03-25 23:55 ` [14/23] [media] uvcvideo: Fix uvc_fixup_video_ctrl() format search Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [16/23] USB: uss720 fixup refcount position Greg KH
` (8 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Alan Stern, David Brownell
[-- Attachment #1: ehci-hcd-bug-fix-don-t-set-a-qh-s-halt-bit.patch --]
[-- Type: text/plain, Size: 2753 bytes --]
From: Alan Stern <stern@rowland.harvard.edu>
commit b5a3b3d985493c173925907adfebf3edab236fe7 upstream.
This patch (as1453) fixes a long-standing bug in the ehci-hcd driver.
There is no need to set the Halt bit in the overlay region for an
unlinked or blocked QH. Contrary to what the comment says, setting
the Halt bit does not cause the QH to be patched later; that decision
(made in qh_refresh()) depends only on whether the QH is currently
pointing to a valid qTD. Likewise, setting the Halt bit does not
prevent completions from activating the QH while it is "stopped"; they
are prevented by the fact that qh_completions() temporarily changes
qh->qh_state to QH_STATE_COMPLETING.
On the other hand, there are circumstances in which the QH will be
reactivated _without_ being patched; this happens after an URB beyond
the head of the queue is unlinked. Setting the Halt bit will then
cause the hardware to see the QH with both the Active and Halt bits
set, an invalid combination that will prevent the queue from
advancing and may even crash some controllers.
Apparently the only reason this hasn't been reported before is that
unlinking URBs from the middle of a running queue is quite uncommon.
However Test 17, recently added to the usbtest driver, does exactly
this, and it confirms the presence of the bug.
In short, there is no reason to set the Halt bit for an unlinked or
blocked QH, and there is a very good reason not to set it. Therefore
the code that sets it is removed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andiry Xu <andiry.xu@amd.com>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/host/ehci-q.c | 12 ------------
1 file changed, 12 deletions(-)
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -315,7 +315,6 @@ qh_completions (struct ehci_hcd *ehci, s
int stopped;
unsigned count = 0;
u8 state;
- const __le32 halt = HALT_BIT(ehci);
struct ehci_qh_hw *hw = qh->hw;
if (unlikely (list_empty (&qh->qtd_list)))
@@ -422,7 +421,6 @@ qh_completions (struct ehci_hcd *ehci, s
&& !(qtd->hw_alt_next
& EHCI_LIST_END(ehci))) {
stopped = 1;
- goto halt;
}
/* stop scanning when we reach qtds the hc is using */
@@ -456,16 +454,6 @@ qh_completions (struct ehci_hcd *ehci, s
*/
ehci_clear_tt_buffer(ehci, qh, urb, token);
}
-
- /* force halt for unlinked or blocked qh, so we'll
- * patch the qh later and so that completions can't
- * activate it while we "know" it's stopped.
- */
- if ((halt & hw->hw_token) == 0) {
-halt:
- hw->hw_token |= halt;
- wmb ();
- }
}
/* unless we already know the urb's status, collect qtd status
^ permalink raw reply [flat|nested] 26+ messages in thread* [16/23] USB: uss720 fixup refcount position
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (14 preceding siblings ...)
2011-03-25 23:55 ` [15/23] ehci-hcd: Bug fix: dont set a QHs Halt bit Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [17/23] USB: cdc-acm: fix memory corruption / panic Greg KH
` (7 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Peter Holik, Thomas Sailer
[-- Attachment #1: usb-uss720-fixup-refcount-position.patch --]
[-- Type: text/plain, Size: 1262 bytes --]
From: Peter Holik <peter@holik.at>
commit adaa3c6342b249548ea830fe8e02aa5b45be8688 upstream.
My testprog do a lot of bitbang - after hours i got following warning and my machine lockups:
WARNING: at /build/buildd/linux-2.6.38/lib/kref.c:34
After debugging uss720 driver i discovered that the completion callback was called before
usb_submit_urb returns. The callback frees the request structure that is krefed on return by
usb_submit_urb.
Signed-off-by: Peter Holik <peter@holik.at>
Acked-by: Thomas Sailer <t.sailer@alumni.ethz.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/misc/uss720.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/usb/misc/uss720.c
+++ b/drivers/usb/misc/uss720.c
@@ -176,12 +176,11 @@ static struct uss720_async_request *subm
spin_lock_irqsave(&priv->asynclock, flags);
list_add_tail(&rq->asynclist, &priv->asynclist);
spin_unlock_irqrestore(&priv->asynclock, flags);
+ kref_get(&rq->ref_count);
ret = usb_submit_urb(rq->urb, mem_flags);
- if (!ret) {
- kref_get(&rq->ref_count);
+ if (!ret)
return rq;
- }
- kref_put(&rq->ref_count, destroy_async);
+ destroy_async(&rq->ref_count);
err("submit_async_request submit_urb failed with %d", ret);
return NULL;
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [17/23] USB: cdc-acm: fix memory corruption / panic
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (15 preceding siblings ...)
2011-03-25 23:55 ` [16/23] USB: uss720 fixup refcount position Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [18/23] USB: cdc-acm: fix potential null-pointer dereference Greg KH
` (6 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: stable-review, torvalds, akpm, alan, Johan Hovold
[-- Attachment #1: usb-cdc-acm-fix-memory-corruption-panic.patch --]
[-- Type: text/plain, Size: 9449 bytes --]
From: Johan Hovold <jhovold@gmail.com>
commit 23b80550e2aa61d0ba3af98b831b9195be0db9ee upstream.
Prevent read urbs from being resubmitted from tasklet after port close.
The receive tasklet was not disabled on port close, which could lead to
corruption of receive lists on consecutive port open. In particular,
read urbs could be re-submitted before port open, added to free list in
open, and then added a second time to the free list in the completion
handler.
cdc-acm.c: Entering acm_tty_open.
cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0
cdc-acm.c: Entering acm_rx_tasklet
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64
cdc-acm.c: set line: 115200 0 0 8
cdc-acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7
cdc-acm.c: acm_tty_close
cdc-acm.c: acm_port_down
cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0
cdc-acm.c: acm_ctrl_irq - urb shutting down with status: -2
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50
cdc-acm.c: Entering acm_read_bulk with status -2
cdc_acm 4-1:1.1: Aborting, acm not ready
cdc-acm.c: Entering acm_read_bulk with status -2
cdc_acm 4-1:1.1: Aborting, acm not ready
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da400, rcv 0xf57fbbe8, buf 0xf57fbd28
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da480, rcv 0xf57fbbd4, buf 0xf57fbd14
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da900, rcv 0xf57fbbc0, buf 0xf57fbd00
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da980, rcv 0xf57fbbac, buf 0xf57fbcec
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa00, rcv 0xf57fbb98, buf 0xf57fbcd8
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa80, rcv 0xf57fbb84, buf 0xf57fbcc4
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab00, rcv 0xf57fbb70, buf 0xf57fbcb0
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab80, rcv 0xf57fbb5c, buf 0xf57fbc9c
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac00, rcv 0xf57fbb48, buf 0xf57fbc88
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac80, rcv 0xf57fbb34, buf 0xf57fbc74
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad00, rcv 0xf57fbb20, buf 0xf57fbc60
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad80, rcv 0xf57fbb0c, buf 0xf57fbc4c
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da880, rcv 0xf57fbaf8, buf 0xf57fbc38
cdc-acm.c: Entering acm_tty_open.
cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0
cdc-acm.c: Entering acm_rx_tasklet
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64
cdc-acm.c: Entering acm_tty_write to write 3 bytes,
cdc-acm.c: Get 3 bytes...
cdc-acm.c: acm_write_start susp_count: 0
cdc-acm.c: Entering acm_read_bulk with status 0
------------[ cut here ]------------
WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120()
Hardware name: Vostro 1520
list_del corruption. next->prev should be f57fbc10, but was f57fbaf8
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.37+ #39
Call Trace:
[<c103c7e2>] warn_slowpath_common+0x72/0xa0
[<c11dd8ac>] ? list_del+0x10c/0x120
[<c11dd8ac>] ? list_del+0x10c/0x120
[<c103c8b3>] warn_slowpath_fmt+0x33/0x40
[<c11dd8ac>] list_del+0x10c/0x120
[<f8051dbf>] acm_rx_tasklet+0xef/0x3e0 [cdc_acm]
[<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80
[<c1042bb6>] tasklet_action+0xe6/0x140
[<c104342f>] __do_softirq+0xaf/0x210
[<c1043380>] ? __do_softirq+0x0/0x210
<IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
[<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
[<c105ac24>] ? kthread+0x74/0x80
[<c105abb0>] ? kthread+0x0/0x80
[<c100337a>] ? kernel_thread_helper+0x6/0x10
---[ end trace efd9a11434f0082e ]---
------------[ cut here ]------------
WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120()
Hardware name: Vostro 1520
list_del corruption. next->prev should be f57fbd50, but was f57fbdb0
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39
Call Trace:
[<c103c7e2>] warn_slowpath_common+0x72/0xa0
[<c11dd8ac>] ? list_del+0x10c/0x120
[<c11dd8ac>] ? list_del+0x10c/0x120
[<c103c8b3>] warn_slowpath_fmt+0x33/0x40
[<c11dd8ac>] list_del+0x10c/0x120
[<f8051dd6>] acm_rx_tasklet+0x106/0x3e0 [cdc_acm]
[<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80
[<c1042bb6>] tasklet_action+0xe6/0x140
[<c104342f>] __do_softirq+0xaf/0x210
[<c1043380>] ? __do_softirq+0x0/0x210
<IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
[<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
[<c105ac24>] ? kthread+0x74/0x80
[<c105abb0>] ? kthread+0x0/0x80
[<c100337a>] ? kernel_thread_helper+0x6/0x10
---[ end trace efd9a11434f0082f ]---
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50
cdc-acm.c: disconnected from network
cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c
cdc-acm.c: Entering acm_rx_tasklet
------------[ cut here ]------------
WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:48 list_del+0xd5/0x120()
Hardware name: Vostro 1520
list_del corruption, next is LIST_POISON1 (00100100)
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39
Call Trace:
[<c103c7e2>] warn_slowpath_common+0x72/0xa0
[<c11dd875>] ? list_del+0xd5/0x120
[<c11dd875>] ? list_del+0xd5/0x120
[<c103c8b3>] warn_slowpath_fmt+0x33/0x40
[<c11dd875>] list_del+0xd5/0x120
[<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
[<c106dbab>] ? trace_hardirqs_on+0xb/0x10
[<c1042b30>] ? tasklet_action+0x60/0x140
[<c1042bb6>] tasklet_action+0xe6/0x140
[<c104342f>] __do_softirq+0xaf/0x210
[<c1043380>] ? __do_softirq+0x0/0x210
<IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
[<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
[<c105ac24>] ? kthread+0x74/0x80
[<c105abb0>] ? kthread+0x0/0x80
[<c100337a>] ? kernel_thread_helper+0x6/0x10
---[ end trace efd9a11434f00830 ]---
BUG: unable to handle kernel paging request at 00200200
IP: [<c11dd7bd>] list_del+0x1d/0x120
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/tty/ttyACM0/uevent
Modules linked in: cdc_acm
Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39 0T816J/Vostro 1520
EIP: 0060:[<c11dd7bd>] EFLAGS: 00010046 CPU: 0
EIP is at list_del+0x1d/0x120
EAX: f57fbd3c EBX: f57fb800 ECX: ffff8000 EDX: 00200200
ESI: f57fbe90 EDI: f57fbd3c EBP: f600bf54 ESP: f600bf3c
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process ksoftirqd/0 (pid: 3, ti=f600a000 task=f60791c0 task.ti=f6082000)
Stack:
c1527e84 00000030 c1527e54 00100100 f57fb800 f57fbd3c f600bf98 f8051fac
f8053104 f8052b94 f600bf6c c106dbab f600bf80 00000286 f60791c0 c1042b30
f57fbda8 f57f5800 f57fbdb0 f57fbd80 f57fbe7c c1656b04 00000000 f600bfb0
Call Trace:
[<f8051fac>] ? acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
[<c106dbab>] ? trace_hardirqs_on+0xb/0x10
[<c1042b30>] ? tasklet_action+0x60/0x140
[<c1042bb6>] ? tasklet_action+0xe6/0x140
[<c104342f>] ? __do_softirq+0xaf/0x210
[<c1043380>] ? __do_softirq+0x0/0x210
<IRQ>
[<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
[<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
[<c105ac24>] ? kthread+0x74/0x80
[<c105abb0>] ? kthread+0x0/0x80
[<c100337a>] ? kernel_thread_helper+0x6/0x10
Code: ff 48 14 e9 57 ff ff ff 90 90 90 90 90 90 55 89 e5 83 ec 18 81 38 00 01 10 00 0f 84 9c 00 00 00 8b 50 04 81 fa 00 02 20 00 74 33 <8b> 12 39 d0 75 5c 8b 10 8b 4a 04 39 c8 0f 85 b5 00 00 00 8b 48
EIP: [<c11dd7bd>] list_del+0x1d/0x120 SS:ESP 0068:f600bf3c
CR2: 0000000000200200
---[ end trace efd9a11434f00831 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 3, comm: ksoftirqd/0 Tainted: G D W 2.6.37+ #39
Call Trace:
[<c13fede1>] ? printk+0x1d/0x24
[<c13fecce>] panic+0x66/0x15c
[<c10067df>] oops_end+0x8f/0x90
[<c1025476>] no_context+0xc6/0x160
[<c10255a8>] __bad_area_nosemaphore+0x98/0x140
[<c103cf68>] ? release_console_sem+0x1d8/0x210
[<c1025667>] bad_area_nosemaphore+0x17/0x20
[<c1025a49>] do_page_fault+0x279/0x420
[<c1006a8f>] ? show_trace+0x1f/0x30
[<c13fede1>] ? printk+0x1d/0x24
[<c10257d0>] ? do_page_fault+0x0/0x420
[<c140333b>] error_code+0x5f/0x64
[<c103007b>] ? select_task_rq_fair+0x37b/0x6a0
[<c10257d0>] ? do_page_fault+0x0/0x420
[<c11dd7bd>] ? list_del+0x1d/0x120
[<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
[<c106dbab>] ? trace_hardirqs_on+0xb/0x10
[<c1042b30>] ? tasklet_action+0x60/0x140
[<c1042bb6>] tasklet_action+0xe6/0x140
[<c104342f>] __do_softirq+0xaf/0x210
[<c1043380>] ? __do_softirq+0x0/0x210
<IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
[<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
[<c105ac24>] ? kthread+0x74/0x80
[<c105abb0>] ? kthread+0x0/0x80
[<c100337a>] ? kernel_thread_helper+0x6/0x10
panic occurred, switching back to text console
------------[ cut here ]------------
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/class/cdc-acm.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -652,8 +652,10 @@ static void acm_port_down(struct acm *ac
usb_kill_urb(acm->ctrlurb);
for (i = 0; i < ACM_NW; i++)
usb_kill_urb(acm->wb[i].urb);
+ tasklet_disable(&acm->urb_task);
for (i = 0; i < nr; i++)
usb_kill_urb(acm->ru[i].urb);
+ tasklet_enable(&acm->urb_task);
acm->control->needs_remote_wakeup = 0;
usb_autopm_put_interface(acm->control);
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [18/23] USB: cdc-acm: fix potential null-pointer dereference
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (16 preceding siblings ...)
2011-03-25 23:55 ` [17/23] USB: cdc-acm: fix memory corruption / panic Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [19/23] USB: cdc-acm: fix potential null-pointer dereference on disconnect Greg KH
` (5 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: stable-review, torvalds, akpm, alan, Johan Hovold
[-- Attachment #1: usb-cdc-acm-fix-potential-null-pointer-dereference.patch --]
[-- Type: text/plain, Size: 591 bytes --]
From: Johan Hovold <jhovold@gmail.com>
commit 15e5bee33ffc11d0e5c6f819a65e7881c5c407be upstream.
Must check return value of tty_port_tty_get.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/class/cdc-acm.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -534,6 +534,8 @@ static void acm_softint(struct work_stru
if (!ACM_READY(acm))
return;
tty = tty_port_tty_get(&acm->port);
+ if (!tty)
+ return;
tty_wakeup(tty);
tty_kref_put(tty);
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [19/23] USB: cdc-acm: fix potential null-pointer dereference on disconnect
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (17 preceding siblings ...)
2011-03-25 23:55 ` [18/23] USB: cdc-acm: fix potential null-pointer dereference Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [20/23] Input: xen-kbdfront - advertise either absolute or relative coordinates Greg KH
` (4 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: stable-review, torvalds, akpm, alan, Johan Hovold
[-- Attachment #1: usb-cdc-acm-fix-potential-null-pointer-dereference-on-disconnect.patch --]
[-- Type: text/plain, Size: 1127 bytes --]
From: Johan Hovold <jhovold@gmail.com>
commit 7e7797e7f6f7bfab73fca02c65e40eaa5bb9000c upstream.
Fix potential null-pointer exception on disconnect introduced by commit
11ea859d64b69a747d6b060b9ed1520eab1161fe (USB: additional power savings
for cdc-acm devices that support remote wakeup).
Only access acm->dev after making sure it is non-null in control urb
completion handler.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/class/cdc-acm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -297,6 +297,8 @@ static void acm_ctrl_irq(struct urb *urb
if (!ACM_READY(acm))
goto exit;
+ usb_mark_last_busy(acm->dev);
+
data = (unsigned char *)(dr + 1);
switch (dr->bNotificationType) {
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
@@ -336,7 +338,6 @@ static void acm_ctrl_irq(struct urb *urb
break;
}
exit:
- usb_mark_last_busy(acm->dev);
retval = usb_submit_urb(urb, GFP_ATOMIC);
if (retval)
dev_err(&urb->dev->dev, "%s - usb_submit_urb failed with "
^ permalink raw reply [flat|nested] 26+ messages in thread* [20/23] Input: xen-kbdfront - advertise either absolute or relative coordinates
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (18 preceding siblings ...)
2011-03-25 23:55 ` [19/23] USB: cdc-acm: fix potential null-pointer dereference on disconnect Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [21/23] SUNRPC: Never reuse the socket port after an xs_close() Greg KH
` (3 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Olaf Hering,
Stefano Stabellini, Dmitry Torokhov
[-- Attachment #1: input-xen-kbdfront-advertise-either-absolute-or-relative-coordinates.patch --]
[-- Type: text/plain, Size: 4085 bytes --]
From: Olaf Hering <olaf@aepfle.de>
commit 8c3c283e6bf463ab498d6e7823aff6c4762314b6 upstream.
A virtualized display device is usually viewed with the vncviewer
application, either by 'xm vnc domU' or with vncviewer localhost:port.
vncviewer and the RFB protocol provides absolute coordinates to the
virtual display. These coordinates are either passed through to a PV
guest or converted to relative coordinates for a HVM guest.
A PV guest receives these coordinates and passes them to the kernels
evdev driver. There it can be picked up by applications such as the
xorg-input drivers. Using absolute coordinates avoids issues such as
guest mouse pointer not tracking host mouse pointer due to wrong mouse
acceleration settings in the guests X display.
Advertise either absolute or relative coordinates to the input system
and the evdev driver, depending on what dom0 provides. The xorg-input
driver prefers relative coordinates even if a devices provides both.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/input/xen-kbdfront.c | 45 ++++++++++++++++++++++---------------------
1 file changed, 24 insertions(+), 21 deletions(-)
--- a/drivers/input/xen-kbdfront.c
+++ b/drivers/input/xen-kbdfront.c
@@ -105,7 +105,7 @@ static irqreturn_t input_handler(int rq,
static int __devinit xenkbd_probe(struct xenbus_device *dev,
const struct xenbus_device_id *id)
{
- int ret, i;
+ int ret, i, abs;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr;
@@ -123,6 +123,11 @@ static int __devinit xenkbd_probe(struct
if (!info->page)
goto error_nomem;
+ if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-abs-pointer", "%d", &abs) < 0)
+ abs = 0;
+ if (abs)
+ xenbus_printf(XBT_NIL, dev->nodename, "request-abs-pointer", "1");
+
/* keyboard */
kbd = input_allocate_device();
if (!kbd)
@@ -132,11 +137,12 @@ static int __devinit xenkbd_probe(struct
kbd->id.bustype = BUS_PCI;
kbd->id.vendor = 0x5853;
kbd->id.product = 0xffff;
- kbd->evbit[0] = BIT(EV_KEY);
+
+ __set_bit(EV_KEY, kbd->evbit);
for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
- set_bit(i, kbd->keybit);
+ __set_bit(i, kbd->keybit);
for (i = KEY_OK; i < KEY_MAX; i++)
- set_bit(i, kbd->keybit);
+ __set_bit(i, kbd->keybit);
ret = input_register_device(kbd);
if (ret) {
@@ -155,12 +161,20 @@ static int __devinit xenkbd_probe(struct
ptr->id.bustype = BUS_PCI;
ptr->id.vendor = 0x5853;
ptr->id.product = 0xfffe;
- ptr->evbit[0] = BIT(EV_KEY) | BIT(EV_REL) | BIT(EV_ABS);
+
+ if (abs) {
+ __set_bit(EV_ABS, ptr->evbit);
+ input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
+ input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+ } else {
+ input_set_capability(ptr, EV_REL, REL_X);
+ input_set_capability(ptr, EV_REL, REL_Y);
+ }
+ input_set_capability(ptr, EV_REL, REL_WHEEL);
+
+ __set_bit(EV_KEY, ptr->evbit);
for (i = BTN_LEFT; i <= BTN_TASK; i++)
- set_bit(i, ptr->keybit);
- ptr->relbit[0] = BIT(REL_X) | BIT(REL_Y) | BIT(REL_WHEEL);
- input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
- input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+ __set_bit(i, ptr->keybit);
ret = input_register_device(ptr);
if (ret) {
@@ -267,7 +281,7 @@ static void xenkbd_backend_changed(struc
enum xenbus_state backend_state)
{
struct xenkbd_info *info = dev_get_drvdata(&dev->dev);
- int ret, val;
+ int val;
switch (backend_state) {
case XenbusStateInitialising:
@@ -278,17 +292,6 @@ static void xenkbd_backend_changed(struc
case XenbusStateInitWait:
InitWait:
- ret = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
- "feature-abs-pointer", "%d", &val);
- if (ret < 0)
- val = 0;
- if (val) {
- ret = xenbus_printf(XBT_NIL, info->xbdev->nodename,
- "request-abs-pointer", "1");
- if (ret)
- printk(KERN_WARNING
- "xenkbd: can't request abs-pointer");
- }
xenbus_switch_state(dev, XenbusStateConnected);
break;
^ permalink raw reply [flat|nested] 26+ messages in thread* [21/23] SUNRPC: Never reuse the socket port after an xs_close()
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (19 preceding siblings ...)
2011-03-25 23:55 ` [20/23] Input: xen-kbdfront - advertise either absolute or relative coordinates Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:55 ` [22/23] fs: call security_d_instantiate in d_obtain_alias V2 Greg KH
` (2 subsequent siblings)
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: stable-review, torvalds, akpm, alan, Trond Myklebust
[-- Attachment #1: sunrpc-never-reuse-the-socket-port-after-an-xs_close.patch --]
[-- Type: text/plain, Size: 746 bytes --]
From: Trond Myklebust <Trond.Myklebust@netapp.com>
commit 246408dcd5dfeef2df437ccb0ef4d6ee87805f58 upstream.
If we call xs_close(), we're in one of two situations:
- Autoclose, which means we don't expect to resend a request
- bind+connect failed, which probably means the port is in use
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/sunrpc/xprtsock.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -743,6 +743,8 @@ static void xs_reset_transport(struct so
if (sk == NULL)
return;
+ transport->srcport = 0;
+
write_lock_bh(&sk->sk_callback_lock);
transport->inet = NULL;
transport->sock = NULL;
^ permalink raw reply [flat|nested] 26+ messages in thread* [22/23] fs: call security_d_instantiate in d_obtain_alias V2
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (20 preceding siblings ...)
2011-03-25 23:55 ` [21/23] SUNRPC: Never reuse the socket port after an xs_close() Greg KH
@ 2011-03-25 23:55 ` Greg KH
2011-03-25 23:56 ` [23/23] dcdbas: force SMI to happen when expected Greg KH
2011-03-26 0:50 ` [00/23] 2.6.32.36-longterm review Teck Choon Giam
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Josef Bacik, Al Viro,
Chuck Ebbert
[-- Attachment #1: fs-call-security_d_instantiate-in-d_obtain_alias-v2.patch --]
[-- Type: text/plain, Size: 1895 bytes --]
From: Josef Bacik <josef@redhat.com>
commit 24ff6663ccfdaf088dfa7acae489cb11ed4f43c4 upstream.
While trying to track down some NFS problems with BTRFS, I kept noticing I was
getting -EACCESS for no apparent reason. Eric Paris and printk() helped me
figure out that it was SELinux that was giving me grief, with the following
denial
type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772
comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
Turns out this is because in d_obtain_alias if we can't find an alias we create
one and do all the normal instantiation stuff, but we don't do the
security_d_instantiate.
Usually we are protected from getting a hashed dentry that hasn't yet run
security_d_instantiate() by the parent's i_mutex, but obviously this isn't an
option there, so in order to deal with the case that a second thread comes in
and finds our new dentry before we get to run security_d_instantiate(), we go
ahead and call it if we find a dentry already. Eric assures me that this is ok
as the code checks to see if the dentry has been initialized already so calling
security_d_instantiate() against the same dentry multiple times is ok. With
this patch I'm no longer getting errant -EACCESS values.
Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/dcache.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1175,9 +1175,12 @@ struct dentry *d_obtain_alias(struct ino
spin_unlock(&tmp->d_lock);
spin_unlock(&dcache_lock);
+ security_d_instantiate(tmp, inode);
return tmp;
out_iput:
+ if (res && !IS_ERR(res))
+ security_d_instantiate(res, inode);
iput(inode);
return res;
}
^ permalink raw reply [flat|nested] 26+ messages in thread* [23/23] dcdbas: force SMI to happen when expected
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (21 preceding siblings ...)
2011-03-25 23:55 ` [22/23] fs: call security_d_instantiate in d_obtain_alias V2 Greg KH
@ 2011-03-25 23:56 ` Greg KH
2011-03-26 0:50 ` [00/23] 2.6.32.36-longterm review Teck Choon Giam
23 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-25 23:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Stuart Hayes, Doug Warzecha,
Chuck Ebbert, Jiri Kosina
[-- Attachment #1: dcdbas-force-smi-to-happen-when-expected.patch --]
[-- Type: text/plain, Size: 1217 bytes --]
From: Stuart Hayes <stuart_hayes@yahoo.com>
commit dd65c736d1b5312c80c88a64bf521db4959eded5 upstream.
The dcdbas driver can do an I/O write to cause a SMI to occur. The SMI handler
looks at certain registers and memory locations, so the SMI needs to happen
immediately. On some systems I/O writes are posted, though, causing the SMI to
happen well after the "outb" occurred, which causes random failures. Following
the "outb" with an "inb" forces the write to go through even if it is posted.
Signed-off-by: Stuart Hayes <stuart_hayes@yahoo.com>
Acked-by: Doug Warzecha <douglas_warzecha@dell.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/firmware/dcdbas.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -267,8 +267,10 @@ int dcdbas_smi_request(struct smi_cmd *s
}
/* generate SMI */
+ /* inb to force posted write through and make SMI happen now */
asm volatile (
- "outb %b0,%w1"
+ "outb %b0,%w1\n"
+ "inb %w1"
: /* no output args */
: "a" (smi_cmd->command_code),
"d" (smi_cmd->command_address),
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [00/23] 2.6.32.36-longterm review
2011-03-25 23:56 ` [00/23] 2.6.32.36-longterm review Greg KH
` (22 preceding siblings ...)
2011-03-25 23:56 ` [23/23] dcdbas: force SMI to happen when expected Greg KH
@ 2011-03-26 0:50 ` Teck Choon Giam
2011-03-26 4:51 ` Greg KH
23 siblings, 1 reply; 26+ messages in thread
From: Teck Choon Giam @ 2011-03-26 0:50 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, stable, stable-review, torvalds, akpm, alan
On Sat, Mar 26, 2011 at 7:56 AM, Greg KH <gregkh@suse.de> wrote:
> This is the start of the longterm review cycle for the 2.6.32.36 release.
> There are 23 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let us know. If anyone is a maintainer of the proper subsystem, and
> wants to add a Signed-off-by: line to the patch, please respond with it.
>
> Responses should be made by Sunday, March 17, 2011, 23:00:00 UTC.
> Anything received after that time might be too late.
I think you mean March 27 instead of March 17? :p
Thanks.
Kindest regards,
Giam Teck Choon
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [00/23] 2.6.32.36-longterm review
2011-03-26 0:50 ` [00/23] 2.6.32.36-longterm review Teck Choon Giam
@ 2011-03-26 4:51 ` Greg KH
0 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2011-03-26 4:51 UTC (permalink / raw)
To: Teck Choon Giam; +Cc: linux-kernel, stable, stable-review, torvalds, akpm, alan
On Sat, Mar 26, 2011 at 08:50:43AM +0800, Teck Choon Giam wrote:
> On Sat, Mar 26, 2011 at 7:56 AM, Greg KH <gregkh@suse.de> wrote:
> > This is the start of the longterm review cycle for the 2.6.32.36 release.
> > There are 23 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let us know. If anyone is a maintainer of the proper subsystem, and
> > wants to add a Signed-off-by: line to the patch, please respond with it.
> >
> > Responses should be made by Sunday, March 17, 2011, 23:00:00 UTC.
> > Anything received after that time might be too late.
>
> I think you mean March 27 instead of March 17? :p
Ick yes, thanks, good catch.
greg k-h
^ permalink raw reply [flat|nested] 26+ messages in thread