This is the start of the stable review cycle for the 2.6.32.6 release.
There are 29 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 Monday, January 24, 00:00:00 UTC.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.32.6-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
Makefile | 2 +-
arch/x86/kernel/cpuid.c | 5 +-
arch/x86/kernel/msr.c | 4 +-
arch/x86/pci/i386.c | 9 +++
block/blk-settings.c | 22 ++++++
drivers/acpi/ec.c | 125 +++++++++++++++++++++------------
drivers/char/nozomi.c | 2 +-
drivers/char/tty_io.c | 2 +-
drivers/gpu/drm/i915/intel_sdvo.c | 83 +++++++++++++++++++++-
drivers/md/dm-table.c | 20 ++----
drivers/media/video/gspca/sunplus.c | 26 ++++----
drivers/misc/enclosure.c | 1 +
drivers/serial/8250_pnp.c | 10 +---
drivers/staging/asus_oled/asus_oled.c | 12 ++-
drivers/staging/hv/Hv.c | 50 +++++++-------
drivers/staging/hv/Hv.h | 6 +-
drivers/staging/hv/Vmbus.c | 12 ++--
drivers/usb/core/devices.c | 2 +-
drivers/usb/core/hub.c | 3 +
drivers/usb/core/message.c | 8 +-
drivers/usb/core/sysfs.c | 6 ++
drivers/usb/host/ehci-hcd.c | 5 +-
drivers/usb/host/ehci-hub.c | 20 +++++-
drivers/usb/host/ehci-q.c | 11 ++-
drivers/usb/host/uhci-hcd.c | 15 ++++-
drivers/usb/host/uhci-hub.c | 2 +-
drivers/usb/serial/generic.c | 2 +
drivers/usb/storage/unusual_devs.h | 7 --
drivers/usb/storage/usb.c | 3 +-
fs/ecryptfs/crypto.c | 4 +-
fs/ecryptfs/file.c | 14 ++--
include/linux/blkdev.h | 2 +
include/linux/enclosure.h | 2 +
kernel/perf_event.c | 29 +++++++-
mm/vmalloc.c | 4 +-
tools/perf/builtin-timechart.c | 2 +-
36 files changed, 365 insertions(+), 167 deletions(-)
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: H. Peter Anvin <[email protected]>
commit 0b962d473af32ec334df271b54ff4973cb2b4c73 upstream.
register_chrdev() hardcodes registering 256 minors, presumably to
avoid breaking old drivers. However, we need to register enough
minors so that we have all possible CPUs.
checkpatch warns on this patch, but the patch is correct: NR_CPUS here
is a static *upper bound* on the *maximum CPU index* (not *number of
CPUs!*) and that is what we want.
Reported-and-tested-by: Russ Anderson <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: Takashi Iwai <[email protected]>
Cc: Alexander Viro <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
LKML-Reference: <tip-*@git.kernel.org>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/cpuid.c | 5 +++--
arch/x86/kernel/msr.c | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
--- a/arch/x86/kernel/cpuid.c
+++ b/arch/x86/kernel/cpuid.c
@@ -192,7 +192,8 @@ static int __init cpuid_init(void)
int i, err = 0;
i = 0;
- if (register_chrdev(CPUID_MAJOR, "cpu/cpuid", &cpuid_fops)) {
+ if (__register_chrdev(CPUID_MAJOR, 0, NR_CPUS,
+ "cpu/cpuid", &cpuid_fops)) {
printk(KERN_ERR "cpuid: unable to get major %d for cpuid\n",
CPUID_MAJOR);
err = -EBUSY;
@@ -221,7 +222,7 @@ out_class:
}
class_destroy(cpuid_class);
out_chrdev:
- unregister_chrdev(CPUID_MAJOR, "cpu/cpuid");
+ __unregister_chrdev(CPUID_MAJOR, 0, NR_CPUS, "cpu/cpuid");
out:
return err;
}
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -251,7 +251,7 @@ static int __init msr_init(void)
int i, err = 0;
i = 0;
- if (register_chrdev(MSR_MAJOR, "cpu/msr", &msr_fops)) {
+ if (__register_chrdev(MSR_MAJOR, 0, NR_CPUS, "cpu/msr", &msr_fops)) {
printk(KERN_ERR "msr: unable to get major %d for msr\n",
MSR_MAJOR);
err = -EBUSY;
@@ -279,7 +279,7 @@ out_class:
msr_device_destroy(i);
class_destroy(msr_class);
out_chrdev:
- unregister_chrdev(MSR_MAJOR, "cpu/msr");
+ __unregister_chrdev(MSR_MAJOR, 0, NR_CPUS, "cpu/msr");
out:
return err;
}
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johan Hovold <[email protected]>
commit 2591530204a76fecc843529ade56afe865dd2657 upstream.
Fix a regression introduced by commit
715b1dc01fe44537e8fce9566e4bb48d6821d84b ("USB: usb_debug,
usb_generic_serial: implement multi urb write").
URB transfer buffer was never freed when using multi-urb writes.
Currently the only driver enabling multi-urb writes is usb_debug.
Signed-off-by: Johan Hovold <[email protected]>
Cc: Greg KH <[email protected]>
Acked-by: Jason Wessel <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/generic.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -489,6 +489,8 @@ void usb_serial_generic_write_bulk_callb
dbg("%s - port %d", __func__, port->number);
if (port->serial->type->max_in_flight_urbs) {
+ kfree(urb->transfer_buffer);
+
spin_lock_irqsave(&port->lock, flags);
--port->urbs_in_flight;
port->tx_bytes_flight -= urb->transfer_buffer_length;
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: James Bottomley <[email protected]>
commit cc9b2e9f6603190c009e5d2629ce8e3f99571346 upstream.
Based on patch originally by Jeff Mahoney <[email protected]>
enclosure_status is expected to be a NULL terminated array of strings
but isn't actually NULL terminated. When writing an invalid value to
/sys/class/enclosure/.../.../status, it goes off the end of the array
and Oopses.
Fix by making the assumption true and adding NULL at the end.
Reported-by: Artur Wojcik <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/misc/enclosure.c | 1 +
include/linux/enclosure.h | 2 ++
2 files changed, 3 insertions(+)
--- a/drivers/misc/enclosure.c
+++ b/drivers/misc/enclosure.c
@@ -391,6 +391,7 @@ static const char *const enclosure_statu
[ENCLOSURE_STATUS_NOT_INSTALLED] = "not installed",
[ENCLOSURE_STATUS_UNKNOWN] = "unknown",
[ENCLOSURE_STATUS_UNAVAILABLE] = "unavailable",
+ [ENCLOSURE_STATUS_MAX] = NULL,
};
static const char *const enclosure_type [] = {
--- a/include/linux/enclosure.h
+++ b/include/linux/enclosure.h
@@ -42,6 +42,8 @@ enum enclosure_status {
ENCLOSURE_STATUS_NOT_INSTALLED,
ENCLOSURE_STATUS_UNKNOWN,
ENCLOSURE_STATUS_UNAVAILABLE,
+ /* last element for counting purposes */
+ ENCLOSURE_STATUS_MAX
};
/* SFF-8485 activity light settings */
From: Suresh Siddha <[email protected]>
commit 2992e545ea006992ec9dc91c4fa996ce1e15f921 upstream.
Thomas Schlichter reported:
> X.org uses libpciaccess which tries to mmap with write combining enabled via
> /sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, the
> kernel does fall back to uncached mmap. Then libpciaccess thinks it succeeded
> mapping with write combining enabled and does not set up suited MTRR entries.
> ;-(
Instead of silently mapping pci mmap region as UC minus in the case
of !pat_enabled and wc request, we can return error. Eric Anholt mentioned
that caller (like X) typically follows up with UC minus pci mmap request and
if there is a free mtrr slot, caller will manage adding WC mtrr.
Jesse Barnes says:
> Older versions of libpciaccess will behave better if we do it that way
> (iirc it only allocates an MTRR if the resource_wc file doesn't exist or
> fails to get mapped).
Reported-by: Thomas Schlichter <[email protected]>
Signed-off-by: Thomas Schlichter <[email protected]>
Signed-off-by: Suresh Siddha <[email protected]>
Acked-by: Eric Anholt <[email protected]>
Acked-by: Jesse Barnes <[email protected]>
Signed-off-by: Jesse Barnes <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/pci/i386.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -282,6 +282,15 @@ int pci_mmap_page_range(struct pci_dev *
return -EINVAL;
prot = pgprot_val(vma->vm_page_prot);
+
+ /*
+ * Return error if pat is not enabled and write_combine is requested.
+ * Caller can followup with UC MINUS request and add a WC mtrr if there
+ * is a free mtrr slot.
+ */
+ if (!pat_enabled && write_combine)
+ return -EINVAL;
+
if (pat_enabled && write_combine)
prot |= _PAGE_CACHE_WC;
else if (pat_enabled || boot_cpu_data.x86 > 3)
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alexey Starikovskiy <[email protected]>
commit a62e8f1978f49e52f87a711ff6711b323d4b12ff upstream.
Split EC query handling into acknowledge and execution phase.
This allows much smaller pending query lattency and lowers chances
of EC going "wild" and losing events.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14858
Signed-off-by: Alexey Starikovskiy <[email protected]>
Signed-off-by: Len Brown <[email protected]>
Cc: François Valenduc <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/acpi/ec.c | 122 ++++++++++++++++++++++++++++++++++--------------------
1 file changed, 77 insertions(+), 45 deletions(-)
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -201,14 +201,13 @@ unlock:
spin_unlock_irqrestore(&ec->curr_lock, flags);
}
-static void acpi_ec_gpe_query(void *ec_cxt);
+static int acpi_ec_sync_query(struct acpi_ec *ec);
-static int ec_check_sci(struct acpi_ec *ec, u8 state)
+static int ec_check_sci_sync(struct acpi_ec *ec, u8 state)
{
if (state & ACPI_EC_FLAG_SCI) {
if (!test_and_set_bit(EC_FLAGS_QUERY_PENDING, &ec->flags))
- return acpi_os_execute(OSL_EC_BURST_HANDLER,
- acpi_ec_gpe_query, ec);
+ return acpi_ec_sync_query(ec);
}
return 0;
}
@@ -249,11 +248,6 @@ static int acpi_ec_transaction_unlocked(
{
unsigned long tmp;
int ret = 0;
- pr_debug(PREFIX "transaction start\n");
- /* disable GPE during transaction if storm is detected */
- if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
- acpi_disable_gpe(NULL, ec->gpe);
- }
if (EC_FLAGS_MSI)
udelay(ACPI_EC_MSI_UDELAY);
/* start transaction */
@@ -269,16 +263,6 @@ static int acpi_ec_transaction_unlocked(
spin_lock_irqsave(&ec->curr_lock, tmp);
ec->curr = NULL;
spin_unlock_irqrestore(&ec->curr_lock, tmp);
- if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
- /* check if we received SCI during transaction */
- ec_check_sci(ec, acpi_ec_read_status(ec));
- /* it is safe to enable GPE outside of transaction */
- acpi_enable_gpe(NULL, ec->gpe);
- } else if (t->irq_count > ACPI_EC_STORM_THRESHOLD) {
- pr_info(PREFIX "GPE storm detected, "
- "transactions will use polling mode\n");
- set_bit(EC_FLAGS_GPE_STORM, &ec->flags);
- }
return ret;
}
@@ -321,7 +305,24 @@ static int acpi_ec_transaction(struct ac
status = -ETIME;
goto end;
}
+ pr_debug(PREFIX "transaction start\n");
+ /* disable GPE during transaction if storm is detected */
+ if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
+ acpi_disable_gpe(NULL, ec->gpe);
+ }
+
status = acpi_ec_transaction_unlocked(ec, t);
+
+ /* check if we received SCI during transaction */
+ ec_check_sci_sync(ec, acpi_ec_read_status(ec));
+ if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
+ /* it is safe to enable GPE outside of transaction */
+ acpi_enable_gpe(NULL, ec->gpe);
+ } else if (t->irq_count > ACPI_EC_STORM_THRESHOLD) {
+ pr_info(PREFIX "GPE storm detected, "
+ "transactions will use polling mode\n");
+ set_bit(EC_FLAGS_GPE_STORM, &ec->flags);
+ }
end:
if (ec->global_lock)
acpi_release_global_lock(glk);
@@ -443,7 +444,7 @@ int ec_transaction(u8 command,
EXPORT_SYMBOL(ec_transaction);
-static int acpi_ec_query(struct acpi_ec *ec, u8 * data)
+static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 * data)
{
int result;
u8 d;
@@ -452,20 +453,16 @@ static int acpi_ec_query(struct acpi_ec
.wlen = 0, .rlen = 1};
if (!ec || !data)
return -EINVAL;
-
/*
* Query the EC to find out which _Qxx method we need to evaluate.
* Note that successful completion of the query causes the ACPI_EC_SCI
* bit to be cleared (and thus clearing the interrupt source).
*/
-
- result = acpi_ec_transaction(ec, &t);
+ result = acpi_ec_transaction_unlocked(ec, &t);
if (result)
return result;
-
if (!d)
return -ENODATA;
-
*data = d;
return 0;
}
@@ -509,43 +506,78 @@ void acpi_ec_remove_query_handler(struct
EXPORT_SYMBOL_GPL(acpi_ec_remove_query_handler);
-static void acpi_ec_gpe_query(void *ec_cxt)
+static void acpi_ec_run(void *cxt)
{
- struct acpi_ec *ec = ec_cxt;
- u8 value = 0;
- struct acpi_ec_query_handler *handler, copy;
-
- if (!ec || acpi_ec_query(ec, &value))
+ struct acpi_ec_query_handler *handler = cxt;
+ if (!handler)
return;
- mutex_lock(&ec->lock);
+ pr_debug(PREFIX "start query execution\n");
+ if (handler->func)
+ handler->func(handler->data);
+ else if (handler->handle)
+ acpi_evaluate_object(handler->handle, NULL, NULL, NULL);
+ pr_debug(PREFIX "stop query execution\n");
+ kfree(handler);
+}
+
+static int acpi_ec_sync_query(struct acpi_ec *ec)
+{
+ u8 value = 0;
+ int status;
+ struct acpi_ec_query_handler *handler, *copy;
+ if ((status = acpi_ec_query_unlocked(ec, &value)))
+ return status;
list_for_each_entry(handler, &ec->list, node) {
if (value == handler->query_bit) {
/* have custom handler for this bit */
- memcpy(©, handler, sizeof(copy));
- mutex_unlock(&ec->lock);
- if (copy.func) {
- copy.func(copy.data);
- } else if (copy.handle) {
- acpi_evaluate_object(copy.handle, NULL, NULL, NULL);
- }
- return;
+ copy = kmalloc(sizeof(*handler), GFP_KERNEL);
+ if (!copy)
+ return -ENOMEM;
+ memcpy(copy, handler, sizeof(*copy));
+ pr_debug(PREFIX "push query execution (0x%2x) on queue\n", value);
+ return acpi_os_execute(OSL_GPE_HANDLER,
+ acpi_ec_run, copy);
}
}
+ return 0;
+}
+
+static void acpi_ec_gpe_query(void *ec_cxt)
+{
+ struct acpi_ec *ec = ec_cxt;
+ if (!ec)
+ return;
+ mutex_lock(&ec->lock);
+ acpi_ec_sync_query(ec);
mutex_unlock(&ec->lock);
}
+static void acpi_ec_gpe_query(void *ec_cxt);
+
+static int ec_check_sci(struct acpi_ec *ec, u8 state)
+{
+ if (state & ACPI_EC_FLAG_SCI) {
+ if (!test_and_set_bit(EC_FLAGS_QUERY_PENDING, &ec->flags)) {
+ pr_debug(PREFIX "push gpe query to the queue\n");
+ return acpi_os_execute(OSL_NOTIFY_HANDLER,
+ acpi_ec_gpe_query, ec);
+ }
+ }
+ return 0;
+}
+
static u32 acpi_ec_gpe_handler(void *data)
{
struct acpi_ec *ec = data;
- u8 status;
pr_debug(PREFIX "~~~> interrupt\n");
- status = acpi_ec_read_status(ec);
- advance_transaction(ec, status);
- if (ec_transaction_done(ec) && (status & ACPI_EC_FLAG_IBF) == 0)
+ advance_transaction(ec, acpi_ec_read_status(ec));
+ if (ec_transaction_done(ec) &&
+ (acpi_ec_read_status(ec) & ACPI_EC_FLAG_IBF) == 0) {
wake_up(&ec->wait);
- ec_check_sci(ec, status);
+ ec_check_sci(ec, acpi_ec_read_status(ec));
+ }
return ACPI_INTERRUPT_HANDLED;
}
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Peter Zijlstra <[email protected]>
commit 22e190851f8709c48baf00ed9ce6144cdc54d025 upstream.
Anton reported that perf record kept receiving events even after calling
ioctl(PERF_EVENT_IOC_DISABLE). It turns out that FORK,COMM and MMAP
events didn't respect the disabled state and kept flowing in.
Reported-by: Anton Blanchard <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Tested-by: Anton Blanchard <[email protected]>
LKML-Reference: <1263459187.4244.265.camel@laptop>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/perf_event.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -3229,6 +3229,9 @@ static void perf_event_task_output(struc
static int perf_event_task_match(struct perf_event *event)
{
+ if (event->state != PERF_EVENT_STATE_ACTIVE)
+ return 0;
+
if (event->cpu != -1 && event->cpu != smp_processor_id())
return 0;
@@ -3345,6 +3348,9 @@ static void perf_event_comm_output(struc
static int perf_event_comm_match(struct perf_event *event)
{
+ if (event->state != PERF_EVENT_STATE_ACTIVE)
+ return 0;
+
if (event->cpu != -1 && event->cpu != smp_processor_id())
return 0;
@@ -3472,6 +3478,9 @@ static void perf_event_mmap_output(struc
static int perf_event_mmap_match(struct perf_event *event,
struct perf_mmap_event *mmap_event)
{
+ if (event->state != PERF_EVENT_STATE_ACTIVE)
+ return 0;
+
if (event->cpu != -1 && event->cpu != smp_processor_id())
return 0;
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Peter Zijlstra <[email protected]>
commit 5d27c23df09b702868d9a3bff86ec6abd22963ac upstream.
Acme noticed that his FORK/MMAP numbers were inflated by about
the same factor as his cpu-count.
This led to the discovery of a few more sites that need to
respect the event->cpu filter.
Reported-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Cc: Paul Mackerras <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/perf_event.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(struct
if (event->state != PERF_EVENT_STATE_ACTIVE)
continue;
+ if (event->cpu != -1 && event->cpu != smp_processor_id())
+ continue;
+
hwc = &event->hw;
interrupts = hwc->interrupts;
@@ -3226,6 +3229,9 @@ static void perf_event_task_output(struc
static int perf_event_task_match(struct perf_event *event)
{
+ if (event->cpu != -1 && event->cpu != smp_processor_id())
+ return 0;
+
if (event->attr.comm || event->attr.mmap || event->attr.task)
return 1;
@@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct
ctx = rcu_dereference(task_event->task->perf_event_ctxp);
if (ctx)
perf_event_task_ctx(ctx, task_event);
+ put_cpu_var(perf_cpu_context);
rcu_read_unlock();
}
@@ -3338,6 +3345,9 @@ static void perf_event_comm_output(struc
static int perf_event_comm_match(struct perf_event *event)
{
+ if (event->cpu != -1 && event->cpu != smp_processor_id())
+ return 0;
+
if (event->attr.comm)
return 1;
@@ -3378,7 +3388,6 @@ static void perf_event_comm_event(struct
cpuctx = &get_cpu_var(perf_cpu_context);
perf_event_comm_ctx(&cpuctx->ctx, comm_event);
- put_cpu_var(perf_cpu_context);
rcu_read_lock();
/*
@@ -3388,6 +3397,7 @@ static void perf_event_comm_event(struct
ctx = rcu_dereference(current->perf_event_ctxp);
if (ctx)
perf_event_comm_ctx(ctx, comm_event);
+ put_cpu_var(perf_cpu_context);
rcu_read_unlock();
}
@@ -3462,6 +3472,9 @@ static void perf_event_mmap_output(struc
static int perf_event_mmap_match(struct perf_event *event,
struct perf_mmap_event *mmap_event)
{
+ if (event->cpu != -1 && event->cpu != smp_processor_id())
+ return 0;
+
if (event->attr.mmap)
return 1;
@@ -3539,7 +3552,6 @@ got_name:
cpuctx = &get_cpu_var(perf_cpu_context);
perf_event_mmap_ctx(&cpuctx->ctx, mmap_event);
- put_cpu_var(perf_cpu_context);
rcu_read_lock();
/*
@@ -3549,6 +3561,7 @@ got_name:
ctx = rcu_dereference(current->perf_event_ctxp);
if (ctx)
perf_event_mmap_ctx(ctx, mmap_event);
+ put_cpu_var(perf_cpu_context);
rcu_read_unlock();
kfree(buf);
@@ -3811,6 +3824,9 @@ static int perf_swevent_match(struct per
enum perf_type_id type,
u32 event_id, struct pt_regs *regs)
{
+ if (event->cpu != -1 && event->cpu != smp_processor_id())
+ return 0;
+
if (!perf_swevent_is_counting(event))
return 0;
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Arjan van de Ven <[email protected]>
commit 8f06d7e6e1bbfb32698d6d455583ab7460c090e2 upstream.
A process that changes its comm field, does this on a per kernel
task struct basis. The timechart tool used, incorrectly, the pid
to track this, and should have used the tid instead...
Signed-off-by: Arjan van de Ven <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Paul Mackerras <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/perf/builtin-timechart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -275,7 +275,7 @@ static u64 cpus_pstate_state[MAX_CPUS];
static int
process_comm_event(event_t *event)
{
- pid_set_comm(event->comm.pid, event->comm.comm);
+ pid_set_comm(event->comm.tid, event->comm.comm);
return 0;
}
static int
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Yongseok Koh <[email protected]>
commit 88f5004430babb836cfce886d5d54c82166f8ba4 upstream.
In free_unmap_area_noflush(), va->flags is marked as VM_LAZY_FREE first, and
then vmap_lazy_nr is increased atomically.
But, in __purge_vmap_area_lazy(), while traversing of vmap_are_list, nr
is counted by checking VM_LAZY_FREE is set to va->flags. After counting
the variable nr, kernel reads vmap_lazy_nr atomically and checks a
BUG_ON condition whether nr is greater than vmap_lazy_nr to prevent
vmap_lazy_nr from being negative.
The problem is that, if interrupted right after marking VM_LAZY_FREE,
increment of vmap_lazy_nr can be delayed. Consequently, BUG_ON
condition can be met because nr is counted more than vmap_lazy_nr.
It is highly probable when vmalloc/vfree are called frequently. This
scenario have been verified by adding delay between marking VM_LAZY_FREE
and increasing vmap_lazy_nr in free_unmap_area_noflush().
Even the vmap_lazy_nr is for checking high watermark, it never be the
strict watermark. Although the BUG_ON condition is to prevent
vmap_lazy_nr from being negative, vmap_lazy_nr is signed variable. So,
it could go down to negative value temporarily.
Consequently, removing the BUG_ON condition is proper.
A possible BUG_ON message is like the below.
kernel BUG at mm/vmalloc.c:517!
invalid opcode: 0000 [#1] SMP
EIP: 0060:[<c04824a4>] EFLAGS: 00010297 CPU: 3
EIP is at __purge_vmap_area_lazy+0x144/0x150
EAX: ee8a8818 EBX: c08e77d4 ECX: e7c7ae40 EDX: c08e77ec
ESI: 000081fe EDI: e7c7ae60 EBP: e7c7ae64 ESP: e7c7ae3c
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Call Trace:
[<c0482ad9>] free_unmap_vmap_area_noflush+0x69/0x70
[<c0482b02>] remove_vm_area+0x22/0x70
[<c0482c15>] __vunmap+0x45/0xe0
[<c04831ec>] vmalloc+0x2c/0x30
Code: 8d 59 e0 eb 04 66 90 89 cb 89 d0 e8 87 fe ff ff 8b 43 20 89 da 8d 48 e0 8d 43 20 3b 04 24 75 e7 fe 05 a8 a5 a3 c0 e9 78 ff ff ff <0f> 0b eb fe 90 8d b4 26 00 00 00 00 56 89 c6 b8 ac a5 a3 c0 31
EIP: [<c04824a4>] __purge_vmap_area_lazy+0x144/0x150 SS:ESP 0068:e7c7ae3c
[ See also http://marc.info/?l=linux-kernel&m=126335856228090&w=2 ]
Signed-off-by: Yongseok Koh <[email protected]>
Reviewed-by: Minchan Kim <[email protected]>
Cc: Nick Piggin <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/vmalloc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -555,10 +555,8 @@ static void __purge_vmap_area_lazy(unsig
}
rcu_read_unlock();
- if (nr) {
- BUG_ON(nr > atomic_read(&vmap_lazy_nr));
+ if (nr)
atomic_sub(nr, &vmap_lazy_nr);
- }
if (nr || force_flush)
flush_tlb_kernel_range(*start, *end);
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ryan May <[email protected]>
commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream.
Resolves kernel.org bug 14914.
Remove entry for 2770:915d (usb digital camera with mass storage
support) from unusual_devs.h. The fix triggered by the entry causes
the file system on the camera to be completely inaccessible (no
partition table, the device is not mountable).
The patch works, but let me clarify a few things about it. All the
patch does is remove the entry for this device from the
drivers/usb/storage/unusual_devs.h, which is supposed to help with a
problem with the device's reported size (I think). I'm pretty sure it
was originally added for a reason, so I'm not sure removing it won't
cause other problems to reappear. Also, I should note that this
unusual_devs.h entry was present (and activating workarounds) in
2.6.29, but in that version everything works fine. Starting with
2.6.30, things no longer work.
Signed-off-by: Ryan May <[email protected]>
Cc: Rohan Hart <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/storage/unusual_devs.h | 7 -------
1 file changed, 7 deletions(-)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1807,13 +1807,6 @@ UNUSUAL_DEV( 0x2735, 0x100b, 0x0000, 0x
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_GO_SLOW ),
-/* Reported by Rohan Hart <[email protected]> */
-UNUSUAL_DEV( 0x2770, 0x915d, 0x0010, 0x0010,
- "INTOVA",
- "Pixtreme",
- US_SC_DEVICE, US_PR_DEVICE, NULL,
- US_FL_FIX_CAPACITY ),
-
/* Reported by Frederic Marchal <[email protected]>
* Mio Moov 330
*/
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Zhao Yakui <[email protected]>
commit 6a304caf0bf9c429fc261f260b86cabf5bde2cbb upstream.
For some SDVO cards based on conexant chip, we can't read the EDID if
we don't read the response after issuing SDVO DDC bus switch
command.
>From the SDVO spec once when another I2C transaction is finished after
completing the I2C transaction of issuing the bus switch command, it
will be switched back to the SDVO internal state again. So we can't
initiate a new I2C transaction to read the response after issuing the
DDC bus switch command. Instead we should issue DDC bus switch command
and read the response in the same I2C transaction.
https://bugs.freedesktop.org/show_bug.cgi?id=23842
https://bugs.freedesktop.org/show_bug.cgi?id=24458
https://bugs.freedesktop.org/show_bug.cgi?id=24522
https://bugs.freedesktop.org/show_bug.cgi?id=24282
Signed-off-by: Zhao Yakui <[email protected]>
Tested-by: Sebastien Caty <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/i915/intel_sdvo.c | 57 +++++++++++++++++++++++++++++++++++---
1 file changed, 53 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -472,14 +472,63 @@ static int intel_sdvo_get_pixel_multipli
}
/**
- * Don't check status code from this as it switches the bus back to the
- * SDVO chips which defeats the purpose of doing a bus switch in the first
- * place.
+ * Try to read the response after issuie the DDC switch command. But it
+ * is noted that we must do the action of reading response and issuing DDC
+ * switch command in one I2C transaction. Otherwise when we try to start
+ * another I2C transaction after issuing the DDC bus switch, it will be
+ * switched to the internal SDVO register.
*/
static void intel_sdvo_set_control_bus_switch(struct intel_output *intel_output,
u8 target)
{
- intel_sdvo_write_cmd(intel_output, SDVO_CMD_SET_CONTROL_BUS_SWITCH, &target, 1);
+ struct intel_sdvo_priv *sdvo_priv = intel_output->dev_priv;
+ u8 out_buf[2], cmd_buf[2], ret_value[2], ret;
+ struct i2c_msg msgs[] = {
+ {
+ .addr = sdvo_priv->slave_addr >> 1,
+ .flags = 0,
+ .len = 2,
+ .buf = out_buf,
+ },
+ /* the following two are to read the response */
+ {
+ .addr = sdvo_priv->slave_addr >> 1,
+ .flags = 0,
+ .len = 1,
+ .buf = cmd_buf,
+ },
+ {
+ .addr = sdvo_priv->slave_addr >> 1,
+ .flags = I2C_M_RD,
+ .len = 1,
+ .buf = ret_value,
+ },
+ };
+
+ intel_sdvo_debug_write(intel_output, SDVO_CMD_SET_CONTROL_BUS_SWITCH,
+ &target, 1);
+ /* write the DDC switch command argument */
+ intel_sdvo_write_byte(intel_output, SDVO_I2C_ARG_0, target);
+
+ out_buf[0] = SDVO_I2C_OPCODE;
+ out_buf[1] = SDVO_CMD_SET_CONTROL_BUS_SWITCH;
+ cmd_buf[0] = SDVO_I2C_CMD_STATUS;
+ cmd_buf[1] = 0;
+ ret_value[0] = 0;
+ ret_value[1] = 0;
+
+ ret = i2c_transfer(intel_output->i2c_bus, msgs, 3);
+ if (ret != 3) {
+ /* failure in I2C transfer */
+ DRM_DEBUG_KMS("I2c transfer returned %d\n", ret);
+ return;
+ }
+ if (ret_value[0] != SDVO_CMD_STATUS_SUCCESS) {
+ DRM_DEBUG_KMS("DDC switch command returns response %d\n",
+ ret_value[0]);
+ return;
+ }
+ return;
}
static bool intel_sdvo_set_target_input(struct intel_output *intel_output, bool target_0, bool target_1)
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Zhao Yakui <[email protected]>
commit 7c3f0a2726fed78e0e0afe3b6fc3c1f5b298e447 upstream.
There exist multiple DDC buses for the SDVO cards with multiple outputs.
When we can't get the EDID by using the select DDC bus, we can try the other
possible DDC bus to see whether the EDID can be obtained.
https://bugs.freedesktop.org/show_bug.cgi?id=23842
Signed-off-by: Zhao Yakui <[email protected]>
Tested-by: Sebastien Caty <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/i915/intel_sdvo.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1638,6 +1638,32 @@ intel_sdvo_hdmi_sink_detect(struct drm_c
edid = drm_get_edid(&intel_output->base,
intel_output->ddc_bus);
+ /* This is only applied to SDVO cards with multiple outputs */
+ if (edid == NULL && intel_sdvo_multifunc_encoder(intel_output)) {
+ uint8_t saved_ddc, temp_ddc;
+ saved_ddc = sdvo_priv->ddc_bus;
+ temp_ddc = sdvo_priv->ddc_bus >> 1;
+ /*
+ * Don't use the 1 as the argument of DDC bus switch to get
+ * the EDID. It is used for SDVO SPD ROM.
+ */
+ while(temp_ddc > 1) {
+ sdvo_priv->ddc_bus = temp_ddc;
+ edid = drm_get_edid(&intel_output->base,
+ intel_output->ddc_bus);
+ if (edid) {
+ /*
+ * When we can get the EDID, maybe it is the
+ * correct DDC bus. Update it.
+ */
+ sdvo_priv->ddc_bus = temp_ddc;
+ break;
+ }
+ temp_ddc >>= 1;
+ }
+ if (edid == NULL)
+ sdvo_priv->ddc_bus = saved_ddc;
+ }
/* when there is no edid and no monitor is connected with VGA
* port, try to use the CRT ddc to read the EDID for DVI-connector
*/
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Martin K. Petersen <[email protected]>
commit b27d7f16d3c6c27345d4280a739809c1c2c4c0b5 upstream.
Make DM use bdev_stack_limits() function so that partition offsets get
taken into account when calculating alignment. Clarify stacking
warnings.
Also remove obsolete clearing of final alignment_offset and misalignment
flag.
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Cc: Alasdair G. Kergon <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/dm-table.c | 20 +++++---------------
1 file changed, 5 insertions(+), 15 deletions(-)
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -499,16 +499,15 @@ int dm_set_device_limits(struct dm_targe
return 0;
}
- if (blk_stack_limits(limits, &q->limits, start << 9) < 0)
- DMWARN("%s: target device %s is misaligned: "
+ if (bdev_stack_limits(limits, bdev, start) < 0)
+ DMWARN("%s: adding target device %s caused an alignment inconsistency: "
"physical_block_size=%u, logical_block_size=%u, "
"alignment_offset=%u, start=%llu",
dm_device_name(ti->table->md), bdevname(bdev, b),
q->limits.physical_block_size,
q->limits.logical_block_size,
q->limits.alignment_offset,
- (unsigned long long) start << 9);
-
+ (unsigned long long) start << SECTOR_SHIFT);
/*
* Check if merge fn is supported.
@@ -1025,9 +1024,9 @@ combine_limits:
* for the table.
*/
if (blk_stack_limits(limits, &ti_limits, 0) < 0)
- DMWARN("%s: target device "
+ DMWARN("%s: adding target device "
"(start sect %llu len %llu) "
- "is misaligned",
+ "caused an alignment inconsistency",
dm_device_name(table->md),
(unsigned long long) ti->begin,
(unsigned long long) ti->len);
@@ -1079,15 +1078,6 @@ void dm_table_set_restrictions(struct dm
struct queue_limits *limits)
{
/*
- * Each target device in the table has a data area that should normally
- * be aligned such that the DM device's alignment_offset is 0.
- * FIXME: Propagate alignment_offsets up the stack and warn of
- * sub-optimal or inconsistent settings.
- */
- limits->alignment_offset = 0;
- limits->misaligned = 0;
-
- /*
* Copy table's limits to the DM device's request_queue
*/
q->limits = *limits;
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Martin K. Petersen <[email protected]>
commit 17be8c245054b9c7786545af3ba3ca4e54cd4ad9 upstream.
DM does not want to know about partition offsets. Add a partition-aware
wrapper that DM can use when stacking block devices.
Signed-off-by: Martin K. Petersen <[email protected]>
Acked-by: Mike Snitzer <[email protected]>
Reviewed-by: Alasdair G Kergon <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
block/blk-settings.c | 22 ++++++++++++++++++++++
include/linux/blkdev.h | 2 ++
2 files changed, 24 insertions(+)
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -560,6 +560,28 @@ int blk_stack_limits(struct queue_limits
EXPORT_SYMBOL(blk_stack_limits);
/**
+ * bdev_stack_limits - adjust queue limits for stacked drivers
+ * @t: the stacking driver limits (top device)
+ * @bdev: the component block_device (bottom)
+ * @start: first data sector within component device
+ *
+ * Description:
+ * Merges queue limits for a top device and a block_device. Returns
+ * 0 if alignment didn't change. Returns -1 if adding the bottom
+ * device caused misalignment.
+ */
+int bdev_stack_limits(struct queue_limits *t, struct block_device *bdev,
+ sector_t start)
+{
+ struct request_queue *bq = bdev_get_queue(bdev);
+
+ start += get_start_sect(bdev);
+
+ return blk_stack_limits(t, &bq->limits, start << 9);
+}
+EXPORT_SYMBOL(bdev_stack_limits);
+
+/**
* disk_stack_limits - adjust queue limits for stacked drivers
* @disk: MD/DM gendisk (top)
* @bdev: the underlying block device (bottom)
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -942,6 +942,8 @@ extern void blk_queue_io_opt(struct requ
extern void blk_set_default_limits(struct queue_limits *lim);
extern int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
sector_t offset);
+extern int bdev_stack_limits(struct queue_limits *t, struct block_device *bdev,
+ sector_t offset);
extern void disk_stack_limits(struct gendisk *disk, struct block_device *bdev,
sector_t offset);
extern void blk_queue_stack_limits(struct request_queue *t, struct request_queue *b);
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alexey Starikovskiy <[email protected]>
commit 54070101f86ca9a6e9ba243c999d144721ec3db7 upstream.
Merge of poll and irq modes accelerated EC transaction, so
that keyboard starts to suffer again. Add msleep(1) into
transaction path for the storm to allow keyboard controller
to do its job.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14747
Signed-off-by: Alexey Starikovskiy <[email protected]>
Signed-off-by: Len Brown <[email protected]>
Cc: François Valenduc <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/acpi/ec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -259,7 +259,6 @@ static int acpi_ec_transaction_unlocked(
clear_bit(EC_FLAGS_QUERY_PENDING, &ec->flags);
spin_unlock_irqrestore(&ec->curr_lock, tmp);
ret = ec_poll(ec);
- pr_debug(PREFIX "transaction end\n");
spin_lock_irqsave(&ec->curr_lock, tmp);
ec->curr = NULL;
spin_unlock_irqrestore(&ec->curr_lock, tmp);
@@ -316,6 +315,7 @@ static int acpi_ec_transaction(struct ac
/* check if we received SCI during transaction */
ec_check_sci_sync(ec, acpi_ec_read_status(ec));
if (test_bit(EC_FLAGS_GPE_STORM, &ec->flags)) {
+ msleep(1);
/* it is safe to enable GPE outside of transaction */
acpi_enable_gpe(NULL, ec->gpe);
} else if (t->irq_count > ACPI_EC_STORM_THRESHOLD) {
@@ -323,6 +323,7 @@ static int acpi_ec_transaction(struct ac
"transactions will use polling mode\n");
set_bit(EC_FLAGS_GPE_STORM, &ec->flags);
}
+ pr_debug(PREFIX "transaction end\n");
end:
if (ec->global_lock)
acpi_release_global_lock(glk);
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit 49d0f078f494b9d81e820a13dd8093a9bfb0b6b1 upstream.
This patch (as1330) fixes a bug in khbud's handling of remote
wakeups. When a device sends a remote-wakeup request, the parent hub
(or the host controller driver, for directly attached devices) begins
the resume sequence and notifies khubd when the sequence finishes. At
this point the port's SUSPEND feature is automatically turned off.
However the device needs an additional 10-ms resume-recovery time
(TRSMRCY in the USB spec). Khubd does not wait for this delay if the
SUSPEND feature is off, and as a result some devices fail to behave
properly following a remote wakeup. This patch adds the missing
delay to the remote-wakeup path.
It also extends the resume-signalling delay used by ehci-hcd and
uhci-hcd from 20 ms (the value in the spec) to 25 ms (the value we use
for non-remote-wakeup resumes). The extra time appears to help some
devices.
Signed-off-by: Alan Stern <[email protected]>
Cc: Rickard Bellini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/core/hub.c | 3 +++
drivers/usb/host/ehci-hcd.c | 5 +++--
drivers/usb/host/uhci-hub.c | 2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3286,6 +3286,9 @@ static void hub_events(void)
USB_PORT_FEAT_C_SUSPEND);
udev = hdev->children[i-1];
if (udev) {
+ /* TRSMRCY = 10 msec */
+ msleep(10);
+
usb_lock_device(udev);
ret = remote_wakeup(hdev->
children[i-1]);
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -785,9 +785,10 @@ static irqreturn_t ehci_irq (struct usb_
/* start 20 msec resume signaling from this port,
* and make khubd collect PORT_STAT_C_SUSPEND to
- * stop that signaling.
+ * stop that signaling. Use 5 ms extra for safety,
+ * like usb_port_resume() does.
*/
- ehci->reset_done [i] = jiffies + msecs_to_jiffies (20);
+ ehci->reset_done[i] = jiffies + msecs_to_jiffies(25);
ehci_dbg (ehci, "port %d remote wakeup\n", i + 1);
mod_timer(&hcd->rh_timer, ehci->reset_done[i]);
}
--- a/drivers/usb/host/uhci-hub.c
+++ b/drivers/usb/host/uhci-hub.c
@@ -167,7 +167,7 @@ static void uhci_check_ports(struct uhci
/* Port received a wakeup request */
set_bit(port, &uhci->resuming_ports);
uhci->ports_timeout = jiffies +
- msecs_to_jiffies(20);
+ msecs_to_jiffies(25);
/* Make sure we see the port again
* after the resuming period is over. */
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit cec3a53c7fe794237b582e8e77fc0e48465e65ee upstream.
This patch (as1321) fixes a problem with EHCI and UHCI root-hub
suspends: If the suspend occurs while a port is trying to resume, the
resume doesn't finish and simply gets lost. When remote wakeup is
enabled, this is undesirable behavior.
The patch checks first to see if any port resumes are in progress, and
if they are then it fails the root-hub suspend with -EBUSY.
Signed-off-by: Alan Stern <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/ehci-hub.c | 20 +++++++++++++++++++-
drivers/usb/host/uhci-hcd.c | 15 ++++++++++++++-
2 files changed, 33 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -120,9 +120,26 @@ static int ehci_bus_suspend (struct usb_
del_timer_sync(&ehci->watchdog);
del_timer_sync(&ehci->iaa_watchdog);
- port = HCS_N_PORTS (ehci->hcs_params);
spin_lock_irq (&ehci->lock);
+ /* Once the controller is stopped, port resumes that are already
+ * in progress won't complete. Hence if remote wakeup is enabled
+ * for the root hub and any ports are in the middle of a resume or
+ * remote wakeup, we must fail the suspend.
+ */
+ if (hcd->self.root_hub->do_remote_wakeup) {
+ port = HCS_N_PORTS(ehci->hcs_params);
+ while (port--) {
+ if (ehci->reset_done[port] != 0) {
+ spin_unlock_irq(&ehci->lock);
+ ehci_dbg(ehci, "suspend failed because "
+ "port %d is resuming\n",
+ port + 1);
+ return -EBUSY;
+ }
+ }
+ }
+
/* stop schedules, clean any completed work */
if (HC_IS_RUNNING(hcd->state)) {
ehci_quiesce (ehci);
@@ -138,6 +155,7 @@ static int ehci_bus_suspend (struct usb_
*/
ehci->bus_suspended = 0;
ehci->owned_ports = 0;
+ port = HCS_N_PORTS(ehci->hcs_params);
while (port--) {
u32 __iomem *reg = &ehci->regs->port_status [port];
u32 t1 = ehci_readl(ehci, reg) & ~PORT_RWC_BITS;
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -749,7 +749,20 @@ static int uhci_rh_suspend(struct usb_hc
spin_lock_irq(&uhci->lock);
if (!test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags))
rc = -ESHUTDOWN;
- else if (!uhci->dead)
+ else if (uhci->dead)
+ ; /* Dead controllers tell no tales */
+
+ /* Once the controller is stopped, port resumes that are already
+ * in progress won't complete. Hence if remote wakeup is enabled
+ * for the root hub and any ports are in the middle of a resume or
+ * remote wakeup, we must fail the suspend.
+ */
+ else if (hcd->self.root_hub->do_remote_wakeup &&
+ uhci->resuming_ports) {
+ dev_dbg(uhci_dev(uhci), "suspend failed because a port "
+ "is resuming\n");
+ rc = -EBUSY;
+ } else
suspend_rh(uhci, UHCI_RH_SUSPENDED);
spin_unlock_irq(&uhci->lock);
return rc;
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit b132b04e193908a94d95065d0628f8fb0159cc55 upstream.
These controllers say "unknown" for their speed in sysfs, which
obviously isn't correct.
Reported-by: Kurt Garloff <[email protected]>
Cc: Sarah Sharp <[email protected]>
Cc: David Vrabel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/core/sysfs.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -115,6 +115,12 @@ show_speed(struct device *dev, struct de
case USB_SPEED_HIGH:
speed = "480";
break;
+ case USB_SPEED_VARIABLE:
+ speed = "480";
+ break;
+ case USB_SPEED_SUPER:
+ speed = "5000";
+ break;
default:
speed = "unknown";
}
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Eugeni Dodonov <[email protected]>
commit 20633bf0141c5e93e3396770d5eb7d200ee4068a upstream.
After updating to 2.6.32 kernel, I started experiencing Oopses caused by
the asus_oled module. After quick investigation, I wrapped this simple
patch which fixes an Oops in by asus_oled module on 2.6.32.2 kernel,
caused by incorrect usage of strict_strtoul function call within
set_enabled and set_disabled functions. This can be triggered by simple
running the userspace client for asus_old (e.g., 'asusoled -e' or
'asusoled -d').
Signed-off-by: Eugeni Dodonov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/asus_oled/asus_oled.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/staging/asus_oled/asus_oled.c
+++ b/drivers/staging/asus_oled/asus_oled.c
@@ -194,9 +194,11 @@ static ssize_t set_enabled(struct device
{
struct usb_interface *intf = to_usb_interface(dev);
struct asus_oled_dev *odev = usb_get_intfdata(intf);
- int temp = strict_strtoul(buf, 10, NULL);
+ unsigned long value;
+ if (strict_strtoul(buf, 10, &value))
+ return -EINVAL;
- enable_oled(odev, temp);
+ enable_oled(odev, value);
return count;
}
@@ -207,10 +209,12 @@ static ssize_t class_set_enabled(struct
{
struct asus_oled_dev *odev =
(struct asus_oled_dev *) dev_get_drvdata(device);
+ unsigned long value;
- int temp = strict_strtoul(buf, 10, NULL);
+ if (strict_strtoul(buf, 10, &value))
+ return -EINVAL;
- enable_oled(odev, temp);
+ enable_oled(odev, value);
return count;
}
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Oliver Neukum <[email protected]>
commit acbe2febe71abb2360b008e9ab3ee5c44169f78c upstream.
Memory allocations with GFP_KERNEL can cause IO to a storage
device which can fail resulting in a need to reset the device.
Therefore GFP_KERNEL cannot be safely used between usb_lock_device()
and usb_unlock_device(). Replace by GFP_NOIO.
Signed-off-by: Oliver Neukum <[email protected]>
Cc: Alan Stern <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/core/devices.c | 2 +-
drivers/usb/core/message.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/usb/core/devices.c
+++ b/drivers/usb/core/devices.c
@@ -494,7 +494,7 @@ static ssize_t usb_device_dump(char __us
return 0;
/* allocate 2^1 pages = 8K (on i386);
* should be more than enough for one device */
- pages_start = (char *)__get_free_pages(GFP_KERNEL, 1);
+ pages_start = (char *)__get_free_pages(GFP_NOIO, 1);
if (!pages_start)
return -ENOMEM;
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -911,11 +911,11 @@ char *usb_cache_string(struct usb_device
if (index <= 0)
return NULL;
- buf = kmalloc(MAX_USB_STRING_SIZE, GFP_KERNEL);
+ buf = kmalloc(MAX_USB_STRING_SIZE, GFP_NOIO);
if (buf) {
len = usb_string(udev, index, buf, MAX_USB_STRING_SIZE);
if (len > 0) {
- smallbuf = kmalloc(++len, GFP_KERNEL);
+ smallbuf = kmalloc(++len, GFP_NOIO);
if (!smallbuf)
return buf;
memcpy(smallbuf, buf, len);
@@ -1682,7 +1682,7 @@ int usb_set_configuration(struct usb_dev
if (cp) {
nintf = cp->desc.bNumInterfaces;
new_interfaces = kmalloc(nintf * sizeof(*new_interfaces),
- GFP_KERNEL);
+ GFP_NOIO);
if (!new_interfaces) {
dev_err(&dev->dev, "Out of memory\n");
return -ENOMEM;
@@ -1691,7 +1691,7 @@ int usb_set_configuration(struct usb_dev
for (; n < nintf; ++n) {
new_interfaces[n] = kzalloc(
sizeof(struct usb_interface),
- GFP_KERNEL);
+ GFP_NOIO);
if (!new_interfaces[n]) {
dev_err(&dev->dev, "Out of memory\n");
ret = -ENOMEM;
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit 1b9a38bfa6e664ff02511314f5586d711c83cc91 upstream.
This patch (as1320) fixes two problems related to interrupt-URB
scheduling in ehci-hcd.
URBs with an interval of 2 or 4 microframes aren't handled.
For the time being, the patch reduces to interval to 1 uframe.
URBs are constrained to have an interval no larger than 1024
frames by usb_submit_urb(). But some EHCI controllers allow
use of a schedule as short as 256 frames; for these
controllers we may have to decrease the interval to the
actual schedule length.
The second problem isn't very significant since few devices expose
interrupt endpoints with an interval larger than 256 frames. But the
first problem is critical; it will prevent the kernel from working
with devices having interrupt intervals of 2 or 4 uframes.
Signed-off-by: Alan Stern <[email protected]>
Tested-by: Glynn Farrow <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/ehci-q.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -827,9 +827,10 @@ qh_make (
* But interval 1 scheduling is simpler, and
* includes high bandwidth.
*/
- dbg ("intr period %d uframes, NYET!",
- urb->interval);
- goto done;
+ urb->interval = 1;
+ } else if (qh->period > ehci->periodic_size) {
+ qh->period = ehci->periodic_size;
+ urb->interval = qh->period << 3;
}
} else {
int think_time;
@@ -852,6 +853,10 @@ qh_make (
usb_calc_bus_time (urb->dev->speed,
is_input, 0, max_packet (maxp)));
qh->period = urb->interval;
+ if (qh->period > ehci->periodic_size) {
+ qh->period = ehci->periodic_size;
+ urb->interval = qh->period;
+ }
}
}
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Matthew Garrett <[email protected]>
commit 6d34855d9aa281f72c533ecb827405139d1b0fe9 upstream.
Wacom claims that the WACF namespace will always be devoted to serial
Wacom tablets. Remove the existing entries and add a wildcard to avoid
having to update the kernel every time they add a new device.
Signed-off-by: Ping Cheng <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Tested-by: Ping Cheng <[email protected]>
Cc: Alan Cox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/serial/8250_pnp.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
--- a/drivers/serial/8250_pnp.c
+++ b/drivers/serial/8250_pnp.c
@@ -328,15 +328,7 @@ static const struct pnp_device_id pnp_de
/* U.S. Robotics 56K Voice INT PnP*/
{ "USR9190", 0 },
/* Wacom tablets */
- { "WACF004", 0 },
- { "WACF005", 0 },
- { "WACF006", 0 },
- { "WACF007", 0 },
- { "WACF008", 0 },
- { "WACF009", 0 },
- { "WACF00A", 0 },
- { "WACF00B", 0 },
- { "WACF00C", 0 },
+ { "WACFXXX", 0 },
/* Compaq touchscreen */
{ "FPI2002", 0 },
/* Fujitsu Stylistic touchscreens */
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Stern <[email protected]>
commit a91b593edd4b3e8aa91f671b763b27b8119eb49d upstream.
This patch adds a mask bit which was mistakenly omitted from the
as1311 patch (usb-storage: add BAD_SENSE flag).
Signed-off-by: Alan Stern <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/storage/usb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -430,7 +430,8 @@ static void adjust_quirks(struct us_data
u16 vid = le16_to_cpu(us->pusb_dev->descriptor.idVendor);
u16 pid = le16_to_cpu(us->pusb_dev->descriptor.idProduct);
unsigned f = 0;
- unsigned int mask = (US_FL_SANE_SENSE | US_FL_FIX_CAPACITY |
+ unsigned int mask = (US_FL_SANE_SENSE | US_FL_BAD_SENSE |
+ US_FL_FIX_CAPACITY |
US_FL_CAPACITY_HEURISTICS | US_FL_IGNORE_DEVICE |
US_FL_NOT_LOCKABLE | US_FL_MAX_SECTORS_64 |
US_FL_CAPACITY_OK | US_FL_IGNORE_RESIDUE |
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jean-Francois Moine <[email protected]>
commit 07d1c69b2dcfdd1b21e36af0ff8b9506234908ee upstream.
A previous code optimization inverted bridge registers and values,
doing a regression in kernel 2.6.32.
Signed-off-by: Jean-Francois Moine <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/video/gspca/sunplus.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
--- a/drivers/media/video/gspca/sunplus.c
+++ b/drivers/media/video/gspca/sunplus.c
@@ -705,7 +705,7 @@ static void spca504B_SetSizeType(struct
rc = spca504B_PollingDataReady(gspca_dev);
/* Init the cam width height with some values get on init ? */
- reg_w_riv(dev, 0x31, 0, 0x04);
+ reg_w_riv(dev, 0x31, 0x04, 0);
spca504B_WaitCmdStatus(gspca_dev);
rc = spca504B_PollingDataReady(gspca_dev);
break;
@@ -807,14 +807,14 @@ static void init_ctl_reg(struct gspca_de
default:
/* case BRIDGE_SPCA533: */
/* case BRIDGE_SPCA504B: */
- reg_w_riv(dev, 0, 0x00, 0x21ad); /* hue */
- reg_w_riv(dev, 0, 0x01, 0x21ac); /* sat/hue */
- reg_w_riv(dev, 0, 0x00, 0x21a3); /* gamma */
+ reg_w_riv(dev, 0, 0x21ad, 0x00); /* hue */
+ reg_w_riv(dev, 0, 0x21ac, 0x01); /* sat/hue */
+ reg_w_riv(dev, 0, 0x21a3, 0x00); /* gamma */
break;
case BRIDGE_SPCA536:
- reg_w_riv(dev, 0, 0x40, 0x20f5);
- reg_w_riv(dev, 0, 0x01, 0x20f4);
- reg_w_riv(dev, 0, 0x00, 0x2089);
+ reg_w_riv(dev, 0, 0x20f5, 0x40);
+ reg_w_riv(dev, 0, 0x20f4, 0x01);
+ reg_w_riv(dev, 0, 0x2089, 0x00);
break;
}
if (pollreg)
@@ -888,11 +888,11 @@ static int sd_init(struct gspca_dev *gsp
switch (sd->bridge) {
case BRIDGE_SPCA504B:
reg_w_riv(dev, 0x1d, 0x00, 0);
- reg_w_riv(dev, 0, 0x01, 0x2306);
- reg_w_riv(dev, 0, 0x00, 0x0d04);
- reg_w_riv(dev, 0, 0x00, 0x2000);
- reg_w_riv(dev, 0, 0x13, 0x2301);
- reg_w_riv(dev, 0, 0x00, 0x2306);
+ reg_w_riv(dev, 0, 0x2306, 0x01);
+ reg_w_riv(dev, 0, 0x0d04, 0x00);
+ reg_w_riv(dev, 0, 0x2000, 0x00);
+ reg_w_riv(dev, 0, 0x2301, 0x13);
+ reg_w_riv(dev, 0, 0x2306, 0x00);
/* fall thru */
case BRIDGE_SPCA533:
spca504B_PollingDataReady(gspca_dev);
@@ -1011,7 +1011,7 @@ static int sd_start(struct gspca_dev *gs
spca504B_WaitCmdStatus(gspca_dev);
break;
default:
- reg_w_riv(dev, 0x31, 0, 0x04);
+ reg_w_riv(dev, 0x31, 0x04, 0);
spca504B_WaitCmdStatus(gspca_dev);
spca504B_PollingDataReady(gspca_dev);
break;
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Erez Zadok <[email protected]>
commit e27759d7a333d1f25d628c4f7caf845c51be51c2 upstream.
Ecryptfs_open dereferences a pointer to the private lower file (the one
stored in the ecryptfs inode), without checking if the pointer is NULL.
Right afterward, it initializes that pointer if it is NULL. Swap order of
statements to first initialize. Bug discovered by Duckjin Kang.
Signed-off-by: Duckjin Kang <[email protected]>
Signed-off-by: Erez Zadok <[email protected]>
Cc: Dustin Kirkland <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Tyler Hicks <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ecryptfs/file.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/fs/ecryptfs/file.c
+++ b/fs/ecryptfs/file.c
@@ -191,13 +191,6 @@ static int ecryptfs_open(struct inode *i
| ECRYPTFS_ENCRYPTED);
}
mutex_unlock(&crypt_stat->cs_mutex);
- if ((ecryptfs_inode_to_private(inode)->lower_file->f_flags & O_RDONLY)
- && !(file->f_flags & O_RDONLY)) {
- rc = -EPERM;
- printk(KERN_WARNING "%s: Lower persistent file is RO; eCryptfs "
- "file must hence be opened RO\n", __func__);
- goto out;
- }
if (!ecryptfs_inode_to_private(inode)->lower_file) {
rc = ecryptfs_init_persistent_file(ecryptfs_dentry);
if (rc) {
@@ -208,6 +201,13 @@ static int ecryptfs_open(struct inode *i
goto out;
}
}
+ if ((ecryptfs_inode_to_private(inode)->lower_file->f_flags & O_RDONLY)
+ && !(file->f_flags & O_RDONLY)) {
+ rc = -EPERM;
+ printk(KERN_WARNING "%s: Lower persistent file is RO; eCryptfs "
+ "file must hence be opened RO\n", __func__);
+ goto out;
+ }
ecryptfs_set_file_lower(
file, ecryptfs_inode_to_private(inode)->lower_file);
if (S_ISDIR(ecryptfs_dentry->d_inode->i_mode)) {
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Cox <[email protected]>
commit eeec32a731631a9bad9abb21c626b9f2840bee0d upstream.
Nozomi goes wrong if you get the sequence
open
open
close
[stuff]
close
which turns out to occur on some ppp type setups.
This is a quick patch up for the problem. It's not really fixing Nozomi
which completely fails to implement tty open/close semantics and all the
other needed stuff. Doing it right is a rather more invasive patch set and
not one that will backport.
Signed-off-by: Alan Cox <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/nozomi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/char/nozomi.c
+++ b/drivers/char/nozomi.c
@@ -1629,10 +1629,10 @@ static void ntty_close(struct tty_struct
dc->open_ttys--;
port->count--;
- tty_port_tty_set(port, NULL);
if (port->count == 0) {
DBG1("close: %d", nport->token_dl);
+ tty_port_tty_set(port, NULL);
spin_lock_irqsave(&dc->spin_mutex, flags);
dc->last_ier &= ~(nport->token_dl);
writew(dc->last_ier, dc->reg_ier);
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Dan Carpenter <[email protected]>
commit ece550f51ba175c14ec3ec047815927d7386ea1f upstream.
The "full_alg_name" variable is used on a couple error paths, so we
shouldn't free it until the end.
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Tyler Hicks <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ecryptfs/crypto.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1748,7 +1748,7 @@ ecryptfs_process_key_cipher(struct crypt
char *cipher_name, size_t *key_size)
{
char dummy_key[ECRYPTFS_MAX_KEY_BYTES];
- char *full_alg_name;
+ char *full_alg_name = NULL;
int rc;
*key_tfm = NULL;
@@ -1763,7 +1763,6 @@ ecryptfs_process_key_cipher(struct crypt
if (rc)
goto out;
*key_tfm = crypto_alloc_blkcipher(full_alg_name, 0, CRYPTO_ALG_ASYNC);
- kfree(full_alg_name);
if (IS_ERR(*key_tfm)) {
rc = PTR_ERR(*key_tfm);
printk(KERN_ERR "Unable to allocate crypto cipher with name "
@@ -1786,6 +1785,7 @@ ecryptfs_process_key_cipher(struct crypt
goto out;
}
out:
+ kfree(full_alg_name);
return rc;
}
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit 7692fd4d441afac728cb83fdd33349d5ba07406c upstream.
This fixes a number of SMP problems that were in the hyperv core code.
Patch originally written by K. Y. Srinivasan <[email protected]>
but forward ported to the latest in-kernel code and tweaked slightly by
me.
Novell, Inc. hereby disclaims all copyright in any derivative work
copyright associated with this patch.
Signed-off-by: K. Y. Srinivasan <[email protected]>
Cc: Hank Janssen <[email protected]>
Cc: Haiyang Zhang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/hv/Hv.c | 50 ++++++++++++++++++++++-----------------------
drivers/staging/hv/Hv.h | 6 ++---
drivers/staging/hv/Vmbus.c | 12 ++++++----
3 files changed, 35 insertions(+), 33 deletions(-)
--- a/drivers/staging/hv/Hv.c
+++ b/drivers/staging/hv/Hv.c
@@ -386,7 +386,7 @@ u16 HvSignalEvent(void)
* retrieve the initialized message and event pages. Otherwise, we create and
* initialize the message and event pages.
*/
-int HvSynicInit(u32 irqVector)
+void HvSynicInit(void *irqarg)
{
u64 version;
union hv_synic_simp simp;
@@ -394,13 +394,14 @@ int HvSynicInit(u32 irqVector)
union hv_synic_sint sharedSint;
union hv_synic_scontrol sctrl;
u64 guestID;
- int ret = 0;
+ u32 irqVector = *((u32 *)(irqarg));
+ int cpu = smp_processor_id();
DPRINT_ENTER(VMBUS);
if (!gHvContext.HypercallPage) {
DPRINT_EXIT(VMBUS);
- return ret;
+ return;
}
/* Check the version */
@@ -425,27 +426,27 @@ int HvSynicInit(u32 irqVector)
*/
rdmsrl(HV_X64_MSR_GUEST_OS_ID, guestID);
if (guestID == HV_LINUX_GUEST_ID) {
- gHvContext.synICMessagePage[0] =
+ gHvContext.synICMessagePage[cpu] =
phys_to_virt(simp.BaseSimpGpa << PAGE_SHIFT);
- gHvContext.synICEventPage[0] =
+ gHvContext.synICEventPage[cpu] =
phys_to_virt(siefp.BaseSiefpGpa << PAGE_SHIFT);
} else {
DPRINT_ERR(VMBUS, "unknown guest id!!");
goto Cleanup;
}
DPRINT_DBG(VMBUS, "MAPPED: Simp: %p, Sifep: %p",
- gHvContext.synICMessagePage[0],
- gHvContext.synICEventPage[0]);
+ gHvContext.synICMessagePage[cpu],
+ gHvContext.synICEventPage[cpu]);
} else {
- gHvContext.synICMessagePage[0] = osd_PageAlloc(1);
- if (gHvContext.synICMessagePage[0] == NULL) {
+ gHvContext.synICMessagePage[cpu] = (void *)get_zeroed_page(GFP_ATOMIC);
+ if (gHvContext.synICMessagePage[cpu] == NULL) {
DPRINT_ERR(VMBUS,
"unable to allocate SYNIC message page!!");
goto Cleanup;
}
- gHvContext.synICEventPage[0] = osd_PageAlloc(1);
- if (gHvContext.synICEventPage[0] == NULL) {
+ gHvContext.synICEventPage[cpu] = (void *)get_zeroed_page(GFP_ATOMIC);
+ if (gHvContext.synICEventPage[cpu] == NULL) {
DPRINT_ERR(VMBUS,
"unable to allocate SYNIC event page!!");
goto Cleanup;
@@ -454,7 +455,7 @@ int HvSynicInit(u32 irqVector)
/* Setup the Synic's message page */
rdmsrl(HV_X64_MSR_SIMP, simp.AsUINT64);
simp.SimpEnabled = 1;
- simp.BaseSimpGpa = virt_to_phys(gHvContext.synICMessagePage[0])
+ simp.BaseSimpGpa = virt_to_phys(gHvContext.synICMessagePage[cpu])
>> PAGE_SHIFT;
DPRINT_DBG(VMBUS, "HV_X64_MSR_SIMP msr set to: %llx",
@@ -465,7 +466,7 @@ int HvSynicInit(u32 irqVector)
/* Setup the Synic's event page */
rdmsrl(HV_X64_MSR_SIEFP, siefp.AsUINT64);
siefp.SiefpEnabled = 1;
- siefp.BaseSiefpGpa = virt_to_phys(gHvContext.synICEventPage[0])
+ siefp.BaseSiefpGpa = virt_to_phys(gHvContext.synICEventPage[cpu])
>> PAGE_SHIFT;
DPRINT_DBG(VMBUS, "HV_X64_MSR_SIEFP msr set to: %llx",
@@ -501,32 +502,30 @@ int HvSynicInit(u32 irqVector)
DPRINT_EXIT(VMBUS);
- return ret;
+ return;
Cleanup:
- ret = -1;
-
if (gHvContext.GuestId == HV_LINUX_GUEST_ID) {
- if (gHvContext.synICEventPage[0])
- osd_PageFree(gHvContext.synICEventPage[0], 1);
+ if (gHvContext.synICEventPage[cpu])
+ osd_PageFree(gHvContext.synICEventPage[cpu], 1);
- if (gHvContext.synICMessagePage[0])
- osd_PageFree(gHvContext.synICMessagePage[0], 1);
+ if (gHvContext.synICMessagePage[cpu])
+ osd_PageFree(gHvContext.synICMessagePage[cpu], 1);
}
DPRINT_EXIT(VMBUS);
-
- return ret;
+ return;
}
/**
* HvSynicCleanup - Cleanup routine for HvSynicInit().
*/
-void HvSynicCleanup(void)
+void HvSynicCleanup(void *arg)
{
union hv_synic_sint sharedSint;
union hv_synic_simp simp;
union hv_synic_siefp siefp;
+ int cpu = smp_processor_id();
DPRINT_ENTER(VMBUS);
@@ -539,6 +538,7 @@ void HvSynicCleanup(void)
sharedSint.Masked = 1;
+ /* Need to correctly cleanup in the case of SMP!!! */
/* Disable the interrupt */
wrmsrl(HV_X64_MSR_SINT0 + VMBUS_MESSAGE_SINT, sharedSint.AsUINT64);
@@ -560,8 +560,8 @@ void HvSynicCleanup(void)
wrmsrl(HV_X64_MSR_SIEFP, siefp.AsUINT64);
- osd_PageFree(gHvContext.synICMessagePage[0], 1);
- osd_PageFree(gHvContext.synICEventPage[0], 1);
+ osd_PageFree(gHvContext.synICMessagePage[cpu], 1);
+ osd_PageFree(gHvContext.synICEventPage[cpu], 1);
}
DPRINT_EXIT(VMBUS);
--- a/drivers/staging/hv/Hv.h
+++ b/drivers/staging/hv/Hv.h
@@ -93,7 +93,7 @@ static const struct hv_guid VMBUS_SERVIC
},
};
-#define MAX_NUM_CPUS 1
+#define MAX_NUM_CPUS 32
struct hv_input_signal_event_buffer {
@@ -137,8 +137,8 @@ extern u16 HvPostMessage(union hv_connec
extern u16 HvSignalEvent(void);
-extern int HvSynicInit(u32 irqVector);
+extern void HvSynicInit(void *irqarg);
-extern void HvSynicCleanup(void);
+extern void HvSynicCleanup(void *arg);
#endif /* __HV_H__ */
--- a/drivers/staging/hv/Vmbus.c
+++ b/drivers/staging/hv/Vmbus.c
@@ -129,7 +129,7 @@ static int VmbusOnDeviceAdd(struct hv_de
/* strcpy(dev->name, "vmbus"); */
/* SynIC setup... */
- ret = HvSynicInit(*irqvector);
+ on_each_cpu(HvSynicInit, (void *)irqvector, 1);
/* Connect to VMBus in the root partition */
ret = VmbusConnect();
@@ -150,7 +150,7 @@ static int VmbusOnDeviceRemove(struct hv
DPRINT_ENTER(VMBUS);
VmbusChannelReleaseUnattachedChannels();
VmbusDisconnect();
- HvSynicCleanup();
+ on_each_cpu(HvSynicCleanup, NULL, 1);
DPRINT_EXIT(VMBUS);
return ret;
@@ -173,7 +173,8 @@ static void VmbusOnCleanup(struct hv_dri
*/
static void VmbusOnMsgDPC(struct hv_driver *drv)
{
- void *page_addr = gHvContext.synICMessagePage[0];
+ int cpu = smp_processor_id();
+ void *page_addr = gHvContext.synICMessagePage[cpu];
struct hv_message *msg = (struct hv_message *)page_addr +
VMBUS_MESSAGE_SINT;
struct hv_message *copied;
@@ -230,11 +231,12 @@ static void VmbusOnEventDPC(struct hv_dr
static int VmbusOnISR(struct hv_driver *drv)
{
int ret = 0;
+ int cpu = smp_processor_id();
void *page_addr;
struct hv_message *msg;
union hv_synic_event_flags *event;
- page_addr = gHvContext.synICMessagePage[0];
+ page_addr = gHvContext.synICMessagePage[cpu];
msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
DPRINT_ENTER(VMBUS);
@@ -248,7 +250,7 @@ static int VmbusOnISR(struct hv_driver *
}
/* TODO: Check if there are events to be process */
- page_addr = gHvContext.synICEventPage[0];
+ page_addr = gHvContext.synICEventPage[cpu];
event = (union hv_synic_event_flags *)page_addr + VMBUS_MESSAGE_SINT;
/* Since we are a child, we only need to check bit 0 */
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit 703625118069f9f8960d356676662d3db5a9d116 upstream.
We need to keep the lock held over the call to __f_setown() to
prevent a PID race.
Thanks to Al Viro for pointing out the problem, and to Travis for
making us look here in the first place.
Cc: Eric W. Biederman <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Tavis Ormandy <[email protected]>
Cc: Jeff Dike <[email protected]>
Cc: Julien Tinnes <[email protected]>
Cc: Matt Mackall <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/tty_io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -1930,8 +1930,8 @@ static int tty_fasync(int fd, struct fil
pid = task_pid(current);
type = PIDTYPE_PID;
}
- spin_unlock_irqrestore(&tty->ctrl_lock, flags);
retval = __f_setown(filp, pid, type, 0);
+ spin_unlock_irqrestore(&tty->ctrl_lock, flags);
if (retval)
goto out;
} else {
On Fri, 2010-01-22 at 16:10 -0800, Greg KH wrote:
> 2.6.32-stable review patch. If anyone has any objections, please let us know.
>
> ------------------
>
> From: Ryan May <[email protected]>
>
> commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream.
>
> Resolves kernel.org bug 14914.
>
> Remove entry for 2770:915d (usb digital camera with mass storage
> support) from unusual_devs.h. The fix triggered by the entry causes
> the file system on the camera to be completely inaccessible (no
> partition table, the device is not mountable).
>
> The patch works, but let me clarify a few things about it. All the
> patch does is remove the entry for this device from the
> drivers/usb/storage/unusual_devs.h, which is supposed to help with a
> problem with the device's reported size (I think). I'm pretty sure it
> was originally added for a reason, so I'm not sure removing it won't
> cause other problems to reappear. Also, I should note that this
> unusual_devs.h entry was present (and activating workarounds) in
> 2.6.29, but in that version everything works fine. Starting with
> 2.6.30, things no longer work.
[...]
It doesn't sound like this bug or fix are sufficiently well understood
yet to be suitable for a stable update. The bug report is currently
marked as invalid!
Ben.
--
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.
On Sat, Jan 23, 2010 at 02:43:46AM +0000, Ben Hutchings wrote:
> On Fri, 2010-01-22 at 16:10 -0800, Greg KH wrote:
> > 2.6.32-stable review patch. If anyone has any objections, please let us know.
> >
> > ------------------
> >
> > From: Ryan May <[email protected]>
> >
> > commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream.
> >
> > Resolves kernel.org bug 14914.
> >
> > Remove entry for 2770:915d (usb digital camera with mass storage
> > support) from unusual_devs.h. The fix triggered by the entry causes
> > the file system on the camera to be completely inaccessible (no
> > partition table, the device is not mountable).
> >
> > The patch works, but let me clarify a few things about it. All the
> > patch does is remove the entry for this device from the
> > drivers/usb/storage/unusual_devs.h, which is supposed to help with a
> > problem with the device's reported size (I think). I'm pretty sure it
> > was originally added for a reason, so I'm not sure removing it won't
> > cause other problems to reappear. Also, I should note that this
> > unusual_devs.h entry was present (and activating workarounds) in
> > 2.6.29, but in that version everything works fine. Starting with
> > 2.6.30, things no longer work.
> [...]
>
> It doesn't sound like this bug or fix are sufficiently well understood
> yet to be suitable for a stable update. The bug report is currently
> marked as invalid!
It was marked that way as we couldn't take a patch through a bug report.
The email thread for it said it solved the problem, and I have had a
number of other users report that it solves their problem as well.
So I do think it needs to remain, unless someone has a report to the
contrary? And if so, I'll be glad to take it out of the main tree, and
then take that back to the -stable tree.
thanks,
greg k-h
Greg KH wrote:
> 2.6.32-stable review patch. If anyone has any objections, please let us know.
>
> ------------------
>
> From: Peter Zijlstra <[email protected]>
>
> commit 5d27c23df09b702868d9a3bff86ec6abd22963ac upstream.
>
> Acme noticed that his FORK/MMAP numbers were inflated by about
> the same factor as his cpu-count.
>
> This led to the discovery of a few more sites that need to
> respect the event->cpu filter.
>
> Reported-by: Arnaldo Carvalho de Melo <[email protected]>
> Signed-off-by: Peter Zijlstra <[email protected]>
> Cc: Paul Mackerras <[email protected]>
> LKML-Reference: <[email protected]>
> Signed-off-by: Ingo Molnar <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> kernel/perf_event.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> --- a/kernel/perf_event.c
> +++ b/kernel/perf_event.c
> @@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(struct
> if (event->state != PERF_EVENT_STATE_ACTIVE)
> continue;
>
> + if (event->cpu != -1 && event->cpu != smp_processor_id())
> + continue;
> +
> hwc = &event->hw;
>
> interrupts = hwc->interrupts;
> @@ -3226,6 +3229,9 @@ static void perf_event_task_output(struc
>
> static int perf_event_task_match(struct perf_event *event)
> {
> + if (event->cpu != -1 && event->cpu != smp_processor_id())
> + return 0;
> +
> if (event->attr.comm || event->attr.mmap || event->attr.task)
> return 1;
>
> @@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct
> ctx = rcu_dereference(task_event->task->perf_event_ctxp);
> if (ctx)
> perf_event_task_ctx(ctx, task_event);
> + put_cpu_var(perf_cpu_context);
> rcu_read_unlock();
> }
I believe this hunk drops the move of put_cpu_var. The upstream hunk looks like
this:
@ -3290,12 +3296,11 @@ static void perf_event_task_event(struct perf_task_event
rcu_read_lock();
cpuctx = &get_cpu_var(perf_cpu_context);
perf_event_task_ctx(&cpuctx->ctx, task_event);
- put_cpu_var(perf_cpu_context);
-
if (!ctx)
ctx = rcu_dereference(task_event->task->perf_event_ctxp);
if (ctx)
perf_event_task_ctx(ctx, task_event);
+ put_cpu_var(perf_cpu_context);
rcu_read_unlock();
}
> @@ -3338,6 +3345,9 @@ static void perf_event_comm_output(struc
>
> static int perf_event_comm_match(struct perf_event *event)
> {
> + if (event->cpu != -1 && event->cpu != smp_processor_id())
> + return 0;
> +
> if (event->attr.comm)
> return 1;
>
> @@ -3378,7 +3388,6 @@ static void perf_event_comm_event(struct
>
> cpuctx = &get_cpu_var(perf_cpu_context);
> perf_event_comm_ctx(&cpuctx->ctx, comm_event);
> - put_cpu_var(perf_cpu_context);
>
> rcu_read_lock();
> /*
> @@ -3388,6 +3397,7 @@ static void perf_event_comm_event(struct
> ctx = rcu_dereference(current->perf_event_ctxp);
> if (ctx)
> perf_event_comm_ctx(ctx, comm_event);
> + put_cpu_var(perf_cpu_context);
> rcu_read_unlock();
> }
>
> @@ -3462,6 +3472,9 @@ static void perf_event_mmap_output(struc
> static int perf_event_mmap_match(struct perf_event *event,
> struct perf_mmap_event *mmap_event)
> {
> + if (event->cpu != -1 && event->cpu != smp_processor_id())
> + return 0;
> +
> if (event->attr.mmap)
> return 1;
>
> @@ -3539,7 +3552,6 @@ got_name:
>
> cpuctx = &get_cpu_var(perf_cpu_context);
> perf_event_mmap_ctx(&cpuctx->ctx, mmap_event);
> - put_cpu_var(perf_cpu_context);
>
> rcu_read_lock();
> /*
> @@ -3549,6 +3561,7 @@ got_name:
> ctx = rcu_dereference(current->perf_event_ctxp);
> if (ctx)
> perf_event_mmap_ctx(ctx, mmap_event);
> + put_cpu_var(perf_cpu_context);
> rcu_read_unlock();
>
> kfree(buf);
> @@ -3811,6 +3824,9 @@ static int perf_swevent_match(struct per
> enum perf_type_id type,
> u32 event_id, struct pt_regs *regs)
> {
> + if (event->cpu != -1 && event->cpu != smp_processor_id())
> + return 0;
> +
> if (!perf_swevent_is_counting(event))
> return 0;
>
>
>
> _______________________________________________
> Stable-review mailing list
> [email protected]
> http://linux.kernel.org/mailman/listinfo/stable-review
On Sat, Jan 23, 2010 at 12:38:41PM +0100, Stefan Bader wrote:
> Greg KH wrote:
> > 2.6.32-stable review patch. If anyone has any objections, please let us know.
> >
> > ------------------
> >
> > From: Peter Zijlstra <[email protected]>
> >
> > commit 5d27c23df09b702868d9a3bff86ec6abd22963ac upstream.
> >
> > Acme noticed that his FORK/MMAP numbers were inflated by about
> > the same factor as his cpu-count.
> >
> > This led to the discovery of a few more sites that need to
> > respect the event->cpu filter.
> >
> > Reported-by: Arnaldo Carvalho de Melo <[email protected]>
> > Signed-off-by: Peter Zijlstra <[email protected]>
> > Cc: Paul Mackerras <[email protected]>
> > LKML-Reference: <[email protected]>
> > Signed-off-by: Ingo Molnar <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >
> > ---
> > kernel/perf_event.c | 20 ++++++++++++++++++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > --- a/kernel/perf_event.c
> > +++ b/kernel/perf_event.c
> > @@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(struct
> > if (event->state != PERF_EVENT_STATE_ACTIVE)
> > continue;
> >
> > + if (event->cpu != -1 && event->cpu != smp_processor_id())
> > + continue;
> > +
> > hwc = &event->hw;
> >
> > interrupts = hwc->interrupts;
> > @@ -3226,6 +3229,9 @@ static void perf_event_task_output(struc
> >
> > static int perf_event_task_match(struct perf_event *event)
> > {
> > + if (event->cpu != -1 && event->cpu != smp_processor_id())
> > + return 0;
> > +
> > if (event->attr.comm || event->attr.mmap || event->attr.task)
> > return 1;
> >
>
> > @@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct
> > ctx = rcu_dereference(task_event->task->perf_event_ctxp);
> > if (ctx)
> > perf_event_task_ctx(ctx, task_event);
> > + put_cpu_var(perf_cpu_context);
> > rcu_read_unlock();
> > }
>
> I believe this hunk drops the move of put_cpu_var. The upstream hunk looks like
> this:
>
> @ -3290,12 +3296,11 @@ static void perf_event_task_event(struct perf_task_event
> rcu_read_lock();
> cpuctx = &get_cpu_var(perf_cpu_context);
> perf_event_task_ctx(&cpuctx->ctx, task_event);
> - put_cpu_var(perf_cpu_context);
> -
> if (!ctx)
> ctx = rcu_dereference(task_event->task->perf_event_ctxp);
> if (ctx)
> perf_event_task_ctx(ctx, task_event);
> + put_cpu_var(perf_cpu_context);
> rcu_read_unlock();
> }
Good catch, thanks, I merged this by hand (it was needed by the patch
after this), and I missed this chunk.
thanks,
greg k-h
On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
> This is the start of the stable review cycle for the 2.6.32.6 release.
> There are 29 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 Monday, January 24, 00:00:00 UTC.
> Anything received after that time might be too late.
2.6.32.6 will still contain the regression described in (for example)
http://bugzilla.kernel.org/show_bug.cgi?id=15117
http://bugzilla.kernel.org/show_bug.cgi?id=15005
It's fixed with the below revert which has been in -mm (and only in
-mm) for ten days.
I don't what's going on - perhaps we're waiting for Thomas, and he's
otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH
0/4] clockevents: fix clockevent_devices list corruption after cpu
hotplug" to which Thomas replied
I just applied your patch, but kept the cpuweight check. This
is the least intrusive solution for now. The logic needs an
overhaul, but thats neither rc4 nor stable material"
but no such patch is present in linux-next.
From: Andrew Morton <[email protected]>
Revert
: commit bb6eddf7676e1c1f3e637aa93c5224488d99036f
: Author: Thomas Gleixner <[email protected]>
: AuthorDate: Thu Dec 10 15:35:10 2009 +0100
: Commit: Thomas Gleixner <[email protected]>
: CommitDate: Fri Dec 11 10:28:08 2009 +0100
:
: clockevents: Prevent clockevent_devices list corruption on cpu hotplug
due to the regression reported in
http://bugzilla.kernel.org/show_bug.cgi?id=15005
Cc: Xiaotian Feng <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Reported-by: Martin Bammer <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
kernel/time/clockevents.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff -puN kernel/time/clockevents.c~revert-clockevents-prevent-clockevent_devices-list-corruption-on-cpu-hotplug kernel/time/clockevents.c
--- a/kernel/time/clockevents.c~revert-clockevents-prevent-clockevent_devices-list-corruption-on-cpu-hotplug
+++ a/kernel/time/clockevents.c
@@ -238,9 +238,8 @@ void clockevents_exchange_device(struct
*/
void clockevents_notify(unsigned long reason, void *arg)
{
- struct clock_event_device *dev, *tmp;
+ struct list_head *node, *tmp;
unsigned long flags;
- int cpu;
raw_spin_lock_irqsave(&clockevents_lock, flags);
clockevents_do_notify(reason, arg);
@@ -251,19 +250,8 @@ void clockevents_notify(unsigned long re
* Unregister the clock event devices which were
* released from the users in the notify chain.
*/
- list_for_each_entry_safe(dev, tmp, &clockevents_released, list)
- list_del(&dev->list);
- /*
- * Now check whether the CPU has left unused per cpu devices
- */
- cpu = *((int *)arg);
- list_for_each_entry_safe(dev, tmp, &clockevent_devices, list) {
- if (cpumask_test_cpu(cpu, dev->cpumask) &&
- cpumask_weight(dev->cpumask) == 1) {
- BUG_ON(dev->mode != CLOCK_EVT_MODE_UNUSED);
- list_del(&dev->list);
- }
- }
+ list_for_each_safe(node, tmp, &clockevents_released)
+ list_del(node);
break;
default:
break;
_
On Sat, 23 Jan 2010, Andrew Morton wrote:
> On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
>
> > This is the start of the stable review cycle for the 2.6.32.6 release.
> > There are 29 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 Monday, January 24, 00:00:00 UTC.
> > Anything received after that time might be too late.
>
> 2.6.32.6 will still contain the regression described in (for example)
>
> http://bugzilla.kernel.org/show_bug.cgi?id=15117
> http://bugzilla.kernel.org/show_bug.cgi?id=15005
>
> It's fixed with the below revert which has been in -mm (and only in
> -mm) for ten days.
>
> I don't what's going on - perhaps we're waiting for Thomas, and he's
> otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH
> 0/4] clockevents: fix clockevent_devices list corruption after cpu
> hotplug" to which Thomas replied
>
> I just applied your patch, but kept the cpuweight check. This
> is the least intrusive solution for now. The logic needs an
> overhaul, but thats neither rc4 nor stable material"
Just sent the pull request for it. Sorry for the delay. The patch
needs to go into 32.6 as well.
Thanks,
tglx
Thomas Gleixner wrote On 24-01-2010 18:29:
> On Sat, 23 Jan 2010, Andrew Morton wrote:
>
>> On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
>>
>>> This is the start of the stable review cycle for the 2.6.32.6 release.
>>> There are 29 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 Monday, January 24, 00:00:00 UTC.
>>> Anything received after that time might be too late.
>> 2.6.32.6 will still contain the regression described in (for example)
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=15117
>> http://bugzilla.kernel.org/show_bug.cgi?id=15005
>>
>> It's fixed with the below revert which has been in -mm (and only in
>> -mm) for ten days.
>>
>> I don't what's going on - perhaps we're waiting for Thomas, and he's
>> otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH
>> 0/4] clockevents: fix clockevent_devices list corruption after cpu
>> hotplug" to which Thomas replied
>>
>> I just applied your patch, but kept the cpuweight check. This
>> is the least intrusive solution for now. The logic needs an
>> overhaul, but thats neither rc4 nor stable material"
>
> Just sent the pull request for it. Sorry for the delay. The patch
> needs to go into 32.6 as well.
tick-internal.h should be included for this to fix build failure. Already included
in 2.6.33 with 8e1a928a2ed7e8.
Regards,
On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
> Thomas Gleixner wrote On 24-01-2010 18:29:
> > On Sat, 23 Jan 2010, Andrew Morton wrote:
> >
> >> On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
> >>
> >>> This is the start of the stable review cycle for the 2.6.32.6 release.
> >>> There are 29 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 Monday, January 24, 00:00:00 UTC.
> >>> Anything received after that time might be too late.
> >> 2.6.32.6 will still contain the regression described in (for example)
> >>
> >> http://bugzilla.kernel.org/show_bug.cgi?id=15117
> >> http://bugzilla.kernel.org/show_bug.cgi?id=15005
> >>
> >> It's fixed with the below revert which has been in -mm (and only in
> >> -mm) for ten days.
> >>
> >> I don't what's going on - perhaps we're waiting for Thomas, and he's
> >> otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH
> >> 0/4] clockevents: fix clockevent_devices list corruption after cpu
> >> hotplug" to which Thomas replied
> >>
> >> I just applied your patch, but kept the cpuweight check. This
> >> is the least intrusive solution for now. The logic needs an
> >> overhaul, but thats neither rc4 nor stable material"
> >
> > Just sent the pull request for it. Sorry for the delay. The patch
> > needs to go into 32.6 as well.
>
> tick-internal.h should be included for this to fix build failure. Already included
> in 2.6.33 with 8e1a928a2ed7e8.
Huh? That says:
clockevents: Add missing include to pacify sparse
and does not sound like a problem that needs to be fixed for "real"
users, right?
Or does .32.6 have a build problem somewhere?
confused,
greg k-h
On Sun, Jan 24, 2010 at 05:29:26PM +0100, Thomas Gleixner wrote:
> On Sat, 23 Jan 2010, Andrew Morton wrote:
>
> > On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
> >
> > > This is the start of the stable review cycle for the 2.6.32.6 release.
> > > There are 29 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 Monday, January 24, 00:00:00 UTC.
> > > Anything received after that time might be too late.
> >
> > 2.6.32.6 will still contain the regression described in (for example)
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=15117
> > http://bugzilla.kernel.org/show_bug.cgi?id=15005
> >
> > It's fixed with the below revert which has been in -mm (and only in
> > -mm) for ten days.
> >
> > I don't what's going on - perhaps we're waiting for Thomas, and he's
> > otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH
> > 0/4] clockevents: fix clockevent_devices list corruption after cpu
> > hotplug" to which Thomas replied
> >
> > I just applied your patch, but kept the cpuweight check. This
> > is the least intrusive solution for now. The logic needs an
> > overhaul, but thats neither rc4 nor stable material"
>
> Just sent the pull request for it. Sorry for the delay. The patch
> needs to go into 32.6 as well.
So that would be commit id ea9d8e3f45404d411c00ae67b45cc35c58265bb7 ?
Or something else?
I'll queue that one up for the next .32 stable update, but will refrain
from having it in this specific release in an hour, as there has not
been any time to test it all out. I will start up a round for the next
.32 kernel right afterward, later today, with this patch in it.
thanks,
greg k-h
Greg KH wrote:
> On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
>
> Huh? That says:
> clockevents: Add missing include to pacify sparse
>
> and does not sound like a problem that needs to be fixed for "real"
> users, right?
>
> Or does .32.6 have a build problem somewhere?
Applying the patch on top of 2.6.32.y causes build failure as the fix calls a macro from
"tick-internal.h".
#include "tick-internal.h"
was added to clockevents.c with 8e1a928a2ed7e8 in linux-2.6/master for another reason e.g.
the patch is OK for linux-2.6/master but should be modified to add #include directive
for .32.y when backporting.
Regards,
On Mon, Jan 25, 2010 at 07:39:57PM +0200, Ozan Çağlayan wrote:
> Greg KH wrote:
> > On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
>
> >
> > Huh? That says:
> > clockevents: Add missing include to pacify sparse
> >
> > and does not sound like a problem that needs to be fixed for "real"
> > users, right?
> >
> > Or does .32.6 have a build problem somewhere?
>
> Applying the patch on top of 2.6.32.y causes build failure as the fix calls a macro from
> "tick-internal.h".
>
> #include "tick-internal.h"
>
> was added to clockevents.c with 8e1a928a2ed7e8 in linux-2.6/master for another reason e.g.
> the patch is OK for linux-2.6/master but should be modified to add #include directive
> for .32.y when backporting.
Hm, please, can someone give me _exactly_ which git commit ids they wish
to see in the .32-stable tree to resolve this issue?
thanks,
greg k-h
On Sat, Jan 23, 2010 at 12:38:41PM +0100, Stefan Bader wrote:
> Greg KH wrote:
> > 2.6.32-stable review patch. If anyone has any objections, please let us know.
> >
> > ------------------
> >
> > From: Peter Zijlstra <[email protected]>
> >
> > commit 5d27c23df09b702868d9a3bff86ec6abd22963ac upstream.
> >
> > Acme noticed that his FORK/MMAP numbers were inflated by about
> > the same factor as his cpu-count.
> >
> > This led to the discovery of a few more sites that need to
> > respect the event->cpu filter.
> >
> > Reported-by: Arnaldo Carvalho de Melo <[email protected]>
> > Signed-off-by: Peter Zijlstra <[email protected]>
> > Cc: Paul Mackerras <[email protected]>
> > LKML-Reference: <[email protected]>
> > Signed-off-by: Ingo Molnar <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >
> > ---
> > kernel/perf_event.c | 20 ++++++++++++++++++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > --- a/kernel/perf_event.c
> > +++ b/kernel/perf_event.c
> > @@ -1359,6 +1359,9 @@ static void perf_ctx_adjust_freq(struct
> > if (event->state != PERF_EVENT_STATE_ACTIVE)
> > continue;
> >
> > + if (event->cpu != -1 && event->cpu != smp_processor_id())
> > + continue;
> > +
> > hwc = &event->hw;
> >
> > interrupts = hwc->interrupts;
> > @@ -3226,6 +3229,9 @@ static void perf_event_task_output(struc
> >
> > static int perf_event_task_match(struct perf_event *event)
> > {
> > + if (event->cpu != -1 && event->cpu != smp_processor_id())
> > + return 0;
> > +
> > if (event->attr.comm || event->attr.mmap || event->attr.task)
> > return 1;
> >
>
> > @@ -3262,6 +3268,7 @@ static void perf_event_task_event(struct
> > ctx = rcu_dereference(task_event->task->perf_event_ctxp);
> > if (ctx)
> > perf_event_task_ctx(ctx, task_event);
> > + put_cpu_var(perf_cpu_context);
> > rcu_read_unlock();
> > }
>
> I believe this hunk drops the move of put_cpu_var. The upstream hunk looks like
> this:
>
> @ -3290,12 +3296,11 @@ static void perf_event_task_event(struct perf_task_event
> rcu_read_lock();
> cpuctx = &get_cpu_var(perf_cpu_context);
> perf_event_task_ctx(&cpuctx->ctx, task_event);
> - put_cpu_var(perf_cpu_context);
> -
> if (!ctx)
> ctx = rcu_dereference(task_event->task->perf_event_ctxp);
> if (ctx)
> perf_event_task_ctx(ctx, task_event);
> + put_cpu_var(perf_cpu_context);
> rcu_read_unlock();
> }
All fixed up now, thanks again for the review.
greg k-h
On Mon, 25 Jan 2010, Greg KH wrote:
> On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
> > Thomas Gleixner wrote On 24-01-2010 18:29:
> > > On Sat, 23 Jan 2010, Andrew Morton wrote:
> > >
> > >> On Fri, 22 Jan 2010 16:11:45 -0800 Greg KH <[email protected]> wrote:
> > >>
> > >>> This is the start of the stable review cycle for the 2.6.32.6 release.
> > >>> There are 29 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 Monday, January 24, 00:00:00 UTC.
> > >>> Anything received after that time might be too late.
> > >> 2.6.32.6 will still contain the regression described in (for example)
> > >>
> > >> http://bugzilla.kernel.org/show_bug.cgi?id=15117
> > >> http://bugzilla.kernel.org/show_bug.cgi?id=15005
> > >>
> > >> It's fixed with the below revert which has been in -mm (and only in
> > >> -mm) for ten days.
> > >>
> > >> I don't what's going on - perhaps we're waiting for Thomas, and he's
> > >> otherwise engaged. There's a fix in the lkml thread "Re: [RFC PATCH
> > >> 0/4] clockevents: fix clockevent_devices list corruption after cpu
> > >> hotplug" to which Thomas replied
> > >>
> > >> I just applied your patch, but kept the cpuweight check. This
> > >> is the least intrusive solution for now. The logic needs an
> > >> overhaul, but thats neither rc4 nor stable material"
> > >
> > > Just sent the pull request for it. Sorry for the delay. The patch
> > > needs to go into 32.6 as well.
> >
> > tick-internal.h should be included for this to fix build failure. Already included
> > in 2.6.33 with 8e1a928a2ed7e8.
>
> Huh? That says:
> clockevents: Add missing include to pacify sparse
>
> and does not sound like a problem that needs to be fixed for "real"
> users, right?
>
> Or does .32.6 have a build problem somewhere?
If you pick ea9d8e3f45404d411c00ae67b45cc35c58265bb7 then you need
that include.
Thanks,
tglx
On Mon, Jan 25, 2010 at 09:46:25AM -0800, Greg KH wrote:
> On Mon, Jan 25, 2010 at 07:39:57PM +0200, Ozan Çağlayan wrote:
> > Greg KH wrote:
> > > On Mon, Jan 25, 2010 at 10:40:35AM +0200, Ozan Çağlayan wrote:
> >
> > >
> > > Huh? That says:
> > > clockevents: Add missing include to pacify sparse
> > >
> > > and does not sound like a problem that needs to be fixed for "real"
> > > users, right?
> > >
> > > Or does .32.6 have a build problem somewhere?
> >
> > Applying the patch on top of 2.6.32.y causes build failure as the fix calls a macro from
> > "tick-internal.h".
> >
> > #include "tick-internal.h"
> >
> > was added to clockevents.c with 8e1a928a2ed7e8 in linux-2.6/master for another reason e.g.
> > the patch is OK for linux-2.6/master but should be modified to add #include directive
> > for .32.y when backporting.
>
> Hm, please, can someone give me _exactly_ which git commit ids they wish
> to see in the .32-stable tree to resolve this issue?
Ok, I think I got it now, nevermind...
thanks,
greg k-h