[git:v4l-dvb/for_v3.6] edac: avoid mce decoding crash after edac driver unloaded
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: edac: avoid mce decoding crash after edac driver unloaded
Author: Chen Gong
Date:Tue May 8 20:40:12 2012 -0300
Some edac drivers register themselves as mce decoders via
notifier_chain. But in current notifier_chain implementation logic,
it doesn't accept same notifier registered twice. If so, it will be
wrong when adding/removing the element from the list. For example,
on one SandyBridge platform, remove module sb_edac and then trigger
one error, it will hit oops because it has no mce decoder registered
but related notifier_chain still points to an invalid callback
function. Here is an example:
Call Trace:
[] atomic_notifier_call_chain+0x1a/0x20
[] mce_log+0x46/0x180
[] apei_mce_report_mem_error+0x4a/0x60
[] ghes_do_proc+0x192/0x210
[] ghes_proc+0x46/0x70
[] ghes_notify_sci+0x48/0x80
[] notifier_call_chain+0x55/0x80
[] __blocking_notifier_call_chain+0x5a/0x80
[] ? acpi_os_wait_events_complete+0x23/0x23
[] blocking_notifier_call_chain+0x16/0x20
[] acpi_hed_notify+0x19/0x1b
[] acpi_device_notify+0x19/0x1b
[] acpi_ev_notify_dispatch+0x67/0x7f
[] acpi_os_execute_deferred+0x29/0x36
[] process_one_work+0x132/0x450
[] worker_thread+0x17b/0x3c0
[] ? manage_workers+0x120/0x120
[] kthread+0x9e/0xb0
[] kernel_thread_helper+0x4/0x10
[] ? kthread_freezable_should_stop+0x70/0x70
[] ? gs_change+0x13/0x13
Code: f3 49 89 d4 45 85 ed 4d 89 c6 48 8b 0f 74 48 48 85 c9 75 17 eb 41
0f 1f 80 00 00 00 00 41 83 ed 01 4c 89 f9 74 22 4d 85 ff 74 1d <4c> 8b
79 08 4c 89 e2 48 89 de 48 89 cf ff 11 4d 85 f6 74 04 41
RIP [] notifier_call_chain+0x46/0x80
RSP
CR2: a01af838
---[ end trace 0100930068e73e6f ]---
BUG: unable to handle kernel paging request at fff8
IP: [] kthread_data+0x10/0x20
PGD 1a0d067 PUD 1a0e067 PMD 0
Oops: [#2] SMP
Only i7core_edac and sb_edac have such issues because they have more
than one memory controller which means they have to register mce
decoder many times.
Cc: # 3.2 and upper
Signed-off-by: Chen Gong
Signed-off-by: Mauro Carvalho Chehab
drivers/edac/i7core_edac.c | 15 ---
drivers/edac/sb_edac.c |8
2 files changed, 8 insertions(+), 15 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=e35fca4791fcdd43dc1fd769797df40c562ab491
diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index d27778f..a499c7e 100644
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -1814,12 +1814,6 @@ static int i7core_mce_check_error(struct notifier_block
*nb, unsigned long val,
if (mce->bank != 8)
return NOTIFY_DONE;
-#ifdef CONFIG_SMP
- /* Only handle if it is the right mc controller */
- if (mce->socketid != pvt->i7core_dev->socket)
- return NOTIFY_DONE;
-#endif
-
smp_rmb();
if ((pvt->mce_out + 1) % MCE_LOG_LEN == pvt->mce_in) {
smp_wmb();
@@ -2116,8 +2110,6 @@ static void i7core_unregister_mci(struct i7core_dev
*i7core_dev)
if (pvt->enable_scrub)
disable_sdram_scrub_setting(mci);
- mce_unregister_decode_chain(&i7_mce_dec);
-
/* Disable EDAC polling */
i7core_pci_ctl_release(pvt);
@@ -,8 +2214,6 @@ static int i7core_register_mci(struct i7core_dev
*i7core_dev)
/* DCLK for scrub rate setting */
pvt->dclk_freq = get_dclk_freq();
- mce_register_decode_chain(&i7_mce_dec);
-
return 0;
fail0:
@@ -2367,8 +2357,10 @@ static int __init i7core_init(void)
pci_rc = pci_register_driver(&i7core_driver);
- if (pci_rc >= 0)
+ if (pci_rc >= 0) {
+ mce_register_decode_chain(&i7_mce_dec);
return 0;
+ }
i7core_printk(KERN_ERR, "Failed to register device with error %d.\n",
pci_rc);
@@ -2384,6 +2376,7 @@ static void __exit i7core_exit(void)
{
debugf2("MC: " __FILE__ ": %s()\n", __func__);
pci_unregister_driver(&i7core_driver);
+ mce_unregister_decode_chain(&i7_mce_dec);
}
module_init(i7core_init);
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 4adaf4b..a21ace0 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -1604,8 +1604,6 @@ static void sbridge_unregister_mci(struct sbridge_dev
*sbridge_dev)
debugf0("MC: " __FILE__ ": %s(): mci = %p, dev = %p\n",
__func__, mci, &sbridge_dev->pdev[0]->dev);
- mce_unregister_decode_chain(&sbridge_mce_dec);
-
/* Remove MC sysfs nodes */
edac_mc_del_mc(mci->dev);
@@ -1682,7 +1680,6 @@ static int sbridge_register_mci(struct sbridge_dev
*sbridge_dev)
goto fail0;
}
- mce_register_decode_chain(&sbridge_mce_dec);
return 0;
fail0:
@@ -1811,8 +1808,10 @@ static int __init sbridge_init(void)
pci_rc = p
Patch Upstream: ACPI processor: Fix tick_broadcast_mask online/offline regression
commit: b7db60f45d74497c723dc7ae1370cf0b37dfb0d8
From: Feng Tang
Date: Tue, 31 Jul 2012 12:44:43 +0800
Subject: ACPI processor: Fix tick_broadcast_mask online/offline regression
In commit 99b725084 "ACPI processor hotplug: Delay acpi_processor_start()
call for hotplugged cores", acpi_processor_hotplug(pr) was wrongly replaced
by acpi_processor_cst_has_changed() inside the acpi_cpu_soft_notify(). This
patch will restore it back, fixing the tick_broadcast_mask regression:
https://lkml.org/lkml/2012/7/30/169
Signed-off-by: Feng Tang
Cc: Thomas Renninger
Cc: # 3.3+
Reviewed-by: Rafael J. Wysocki
Reviewed-by: Deepthi Dharwar
Signed-off-by: Len Brown
---
drivers/acpi/processor_driver.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 0734086..bbac51e 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -442,7 +442,7 @@ static int acpi_cpu_soft_notify(struct notifier_block *nfb,
/* Normal CPU soft online event */
} else {
acpi_processor_ppc_has_changed(pr, 0);
- acpi_processor_cst_has_changed(pr);
+ acpi_processor_hotplug(pr);
acpi_processor_reevaluate_tstate(pr, action);
acpi_processor_tstate_has_changed(pr);
}
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2
On Fri, Aug 3, 2012 at 4:47 PM, Greg KH wrote: > On Fri, Aug 03, 2012 at 04:31:22PM -0400, Jerome Glisse wrote: >> On Fri, Aug 3, 2012 at 4:16 PM, Greg KH wrote: >> > On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.gli...@gmail.com wrote: >> >> From: Jerome Glisse >> >> >> >> Virtual address need to be fenced to know when we can safely remove it. >> >> This patch also properly clear the pagetable. Previously it was >> >> serouisly broken. >> >> >> >> v2: For to update pagetable when unbinding bo (don't bailout if >> >> bo_va->valid is true). >> >> >> >> This version is for stable 3.5 only. >> > >> > Why? >> >> Because 3.4 needs again a different patch and 3.6 needs a different >> patch. Code around this patch changed btw 3.4-3.5 and changed again >> btw 3.5-3.6 and in non trivial way. > > Then please say that in the original patch, and point to where the > changes happened, and resend it so that I can apply it. > > I also need an ack from the maintainer(s) that this is acceptable. > > greg k-h I resend the original patch with comment that says 3.5 need special patch. Cheers, Jerome -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] m68k: Correct the Atari ALLOWINT definition
From: Mikael Pettersson commit c663600584a596b5e66258cc10716fb781a5c2c9 upstream. Booting a 3.2, 3.3, or 3.4-rc4 kernel on an Atari using the `nfeth' ethernet device triggers a WARN_ONCE() in generic irq handling code on the first irq for that device: WARNING: at kernel/irq/handle.c:146 handle_irq_event_percpu+0x134/0x142() irq 3 handler nfeth_interrupt+0x0/0x194 enabled interrupts Modules linked in: Call Trace: [<000299b2>] warn_slowpath_common+0x48/0x6a [<000299c0>] warn_slowpath_common+0x56/0x6a [<00029a4c>] warn_slowpath_fmt+0x2a/0x32 [<0005b34c>] handle_irq_event_percpu+0x134/0x142 [<0005b34c>] handle_irq_event_percpu+0x134/0x142 [] nfeth_interrupt+0x0/0x194 [<001ba0a8>] schedule_preempt_disabled+0x0/0xc [<0005b37a>] handle_irq_event+0x20/0x2c [<0005add4>] generic_handle_irq+0x2c/0x3a [<2ab6>] do_IRQ+0x20/0x32 [<289e>] auto_irqhandler_fixup+0x4/0x6 [<3144>] cpu_idle+0x22/0x2e [<001b8a78>] printk+0x0/0x18 [<0024d112>] start_kernel+0x37a/0x386 [<0003021d>] __do_proc_dointvec+0xb1/0x366 [<0003021d>] __do_proc_dointvec+0xb1/0x366 [<0024c31e>] _sinittext+0x31e/0x9c0 After invoking the irq's handler the kernel sees !irqs_disabled() and concludes that the handler erroneously enabled interrupts. However, debugging shows that !irqs_disabled() is true even before the handler is invoked, which indicates a problem in the platform code rather than the specific driver. The warning does not occur in 3.1 or older kernels. It turns out that the ALLOWINT definition for Atari is incorrect. The Atari definition of ALLOWINT is ~0x400, the stated purpose of that is to avoid taking HSYNC interrupts. irqs_disabled() returns true if the 3-bit ipl & 4 is non-zero. The nfeth interrupt runs at ipl 3 (it's autovector 3), but 3 & 4 is zero so irqs_disabled() is false, and the warning above is generated. When interrupts are explicitly disabled, ipl is set to 7. When they are enabled, ipl is masked with ALLOWINT. On Atari this will result in ipl = 3, which blocks interrupts at ipl 3 and below. So how come nfeth interrupts at ipl 3 are received at all? That's because ipl is reset to 2 by Atari-specific code in default_idle(), again with the stated purpose of blocking HSYNC interrupts. This discrepancy means that ipl 3 can remain blocked for longer than intended. Both default_idle() and falcon_hblhandler() identify HSYNC with ipl 2, and the "Atari ST/.../F030 Hardware Register Listing" agrees, but ALLOWINT is defined as if HSYNC was ipl 3. [As an experiment I modified default_idle() to reset ipl to 3, and as expected that resulted in all nfeth interrupts being blocked.] The fix is simple: define ALLOWINT as ~0x500 instead. This makes arch_local_irq_enable() consistent with default_idle(), and prevents the !irqs_disabled() problems for ipl 3 interrupts. Tested on Atari running in an Aranym VM. Signed-off-by: Mikael Pettersson Tested-by: Michael Schmitz (on Falcon/CT60) Signed-off-by: Geert Uytterhoeven --- This version applies to v3.2..v3.4. For v2.6.29..v3.1, it should be applied to arch/m68k/include/asm/entry_mm.h instead arch/m68k/include/asm/entry.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/m68k/include/asm/entry.h b/arch/m68k/include/asm/entry.h index c3c5a86..8798ebc 100644 --- a/arch/m68k/include/asm/entry.h +++ b/arch/m68k/include/asm/entry.h @@ -33,8 +33,8 @@ /* the following macro is used when enabling interrupts */ #if defined(MACH_ATARI_ONLY) - /* block out HSYNC on the atari */ -#define ALLOWINT (~0x400) + /* block out HSYNC = ipl 2 on the atari */ +#define ALLOWINT (~0x500) #defineMAX_NOINT_IPL 3 #else /* portable version */ -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2
On Fri, Aug 03, 2012 at 04:31:22PM -0400, Jerome Glisse wrote: > On Fri, Aug 3, 2012 at 4:16 PM, Greg KH wrote: > > On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.gli...@gmail.com wrote: > >> From: Jerome Glisse > >> > >> Virtual address need to be fenced to know when we can safely remove it. > >> This patch also properly clear the pagetable. Previously it was > >> serouisly broken. > >> > >> v2: For to update pagetable when unbinding bo (don't bailout if > >> bo_va->valid is true). > >> > >> This version is for stable 3.5 only. > > > > Why? > > Because 3.4 needs again a different patch and 3.6 needs a different > patch. Code around this patch changed btw 3.4-3.5 and changed again > btw 3.5-3.6 and in non trivial way. Then please say that in the original patch, and point to where the changes happened, and resend it so that I can apply it. I also need an ack from the maintainer(s) that this is acceptable. greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: ore: Fix out-of-bounds access in _ios_obj()
commit: 9e62bb4458ad2cf28bd701aa5fab380b846db326
From: Boaz Harrosh
Date: Wed, 1 Aug 2012 17:48:36 +0300
Subject: ore: Fix out-of-bounds access in _ios_obj()
_ios_obj() is accessed by group_index not device_table index.
The oc->comps array is only a group_full of devices at a time
it is not like ore_comp_dev() which is indexed by a global
device_table index.
This did not BUG until now because exofs only uses a single
COMP for all devices. But with other FSs like PanFS this is
not true.
This bug was only in the write_path, all other users were
using it correctly
[This is a bug since 3.2 Kernel]
CC: Stable Tree
Signed-off-by: Boaz Harrosh
---
fs/exofs/ore.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/exofs/ore.c b/fs/exofs/ore.c
index 24a49d4..1585db1 100644
--- a/fs/exofs/ore.c
+++ b/fs/exofs/ore.c
@@ -837,11 +837,11 @@ static int _write_mirror(struct ore_io_state *ios, int
cur_comp)
bio->bi_rw |= REQ_WRITE;
}
- osd_req_write(or, _ios_obj(ios, dev), per_dev->offset,
- bio, per_dev->length);
+ osd_req_write(or, _ios_obj(ios, cur_comp),
+ per_dev->offset, bio, per_dev->length);
ORE_DBGMSG("write(0x%llx) offset=0x%llx "
"length=0x%llx dev=%d\n",
-_LLU(_ios_obj(ios, dev)->id),
+_LLU(_ios_obj(ios, cur_comp)->id),
_LLU(per_dev->offset),
_LLU(per_dev->length), dev);
} else if (ios->kern_buff) {
@@ -853,20 +853,20 @@ static int _write_mirror(struct ore_io_state *ios, int
cur_comp)
(ios->si.unit_off + ios->length >
ios->layout->stripe_unit));
- ret = osd_req_write_kern(or, _ios_obj(ios,
per_dev->dev),
+ ret = osd_req_write_kern(or, _ios_obj(ios, cur_comp),
per_dev->offset,
ios->kern_buff, ios->length);
if (unlikely(ret))
goto out;
ORE_DBGMSG2("write_kern(0x%llx) offset=0x%llx "
"length=0x%llx dev=%d\n",
-_LLU(_ios_obj(ios, dev)->id),
+_LLU(_ios_obj(ios, cur_comp)->id),
_LLU(per_dev->offset),
_LLU(ios->length), per_dev->dev);
} else {
- osd_req_set_attributes(or, _ios_obj(ios, dev));
+ osd_req_set_attributes(or, _ios_obj(ios, cur_comp));
ORE_DBGMSG2("obj(0x%llx) set_attributes=%d dev=%d\n",
-_LLU(_ios_obj(ios, dev)->id),
+_LLU(_ios_obj(ios, cur_comp)->id),
ios->out_attr_len, dev);
}
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2
On Fri, Aug 3, 2012 at 4:16 PM, Greg KH wrote: > On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.gli...@gmail.com wrote: >> From: Jerome Glisse >> >> Virtual address need to be fenced to know when we can safely remove it. >> This patch also properly clear the pagetable. Previously it was >> serouisly broken. >> >> v2: For to update pagetable when unbinding bo (don't bailout if >> bo_va->valid is true). >> >> This version is for stable 3.5 only. > > Why? Because 3.4 needs again a different patch and 3.6 needs a different patch. Code around this patch changed btw 3.4-3.5 and changed again btw 3.5-3.6 and in non trivial way. Cheers, Jerome -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2
On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.gli...@gmail.com wrote: > From: Jerome Glisse > > Virtual address need to be fenced to know when we can safely remove it. > This patch also properly clear the pagetable. Previously it was > serouisly broken. > > v2: For to update pagetable when unbinding bo (don't bailout if > bo_va->valid is true). > > This version is for stable 3.5 only. Why? -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2
From: Jerome Glisse
Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.
v2: For to update pagetable when unbinding bo (don't bailout if
bo_va->valid is true).
This version is for stable 3.5 only.
cc: stable@vger.kernel.org
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_cs.c | 32 +---
drivers/gpu/drm/radeon/radeon_gart.c | 24 ++--
drivers/gpu/drm/radeon/radeon_gem.c| 13 ++---
drivers/gpu/drm/radeon/radeon_object.c | 6 +-
5 files changed, 55 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index fefcca5..01d2a87 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -323,6 +323,7 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
+ struct radeon_fence *fence;
boolvalid;
};
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 142f894..70f6d08 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -294,6 +294,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return 0;
}
+static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
+ struct radeon_fence *fence)
+{
+ struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+ struct radeon_vm *vm = &fpriv->vm;
+ struct radeon_bo_list *lobj;
+ int r;
+
+ if (parser->chunk_ib_idx == -1)
+ return;
+ if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
+ return;
+
+ list_for_each_entry(lobj, &parser->validated, tv.head) {
+ struct radeon_bo_va *bo_va;
+ struct radeon_bo *rbo = lobj->bo;
+
+ bo_va = radeon_bo_va(rbo, vm);
+ radeon_fence_unref(&bo_va->fence);
+ bo_va->fence = radeon_fence_ref(fence);
+ }
+ return 0;
+}
+
/**
* cs_parser_fini() - clean parser states
* @parser:parser structure holding parsing context.
@@ -306,11 +330,14 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
{
unsigned i;
- if (!error)
+ if (!error) {
+ /* fence all bo va before ttm_eu_fence_buffer_objects so bo are
still reserved */
+ radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(&parser->validated,
parser->ib.fence);
- else
+ } else {
ttm_eu_backoff_reservation(&parser->validated);
+ }
if (parser->relocs != NULL) {
for (i = 0; i < parser->nrelocs; i++) {
@@ -407,7 +434,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
if (parser->chunk_ib_idx == -1)
return 0;
-
if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 84b648a..f651f22 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -564,7 +564,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}
- if (bo_va->valid)
+ if (bo_va->valid && mem)
return 0;
ngpu_pages = radeon_bo_ngpu_pages(bo);
@@ -597,11 +597,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
struct radeon_bo *bo)
{
struct radeon_bo_va *bo_va;
+ int r;
bo_va = radeon_bo_va(bo, vm);
if (bo_va == NULL)
return 0;
+ /* wait for va use to end */
+ while (bo_va->fence) {
+ r = radeon_fence_wait(bo_va->fence, false);
+ if (r) {
+ DRM_ERROR("error while waiting for fence: %d\n", r);
+ }
+ if (r == -EDEADLK) {
+ r = radeon_gpu_reset(rdev);
+ if (!r)
+ continue;
+ }
+ break;
+ }
+ radeon_fence_unref(&bo_va->fence);
+
radeon_mutex_lock(&rdev->cs_mutex);
mutex_lock(&vm->mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
@@ -661,12 +677,15 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
radeon_vm *vm)
radeon_vm_unbind_locked(rdev, vm);
radeon_mutex_unlock(&rdev->cs_mutex);
- /* remove all bo */
+ /* remove all bo at this point non are busy any more because unbind
+* waited for the last vm fence to signal
+
Patch Upstream: ASoC: wm8994: Ensure there are enough BCLKs for four channels
commit: b8edf3e5522735c8ce78b81845f7a1a2d4a08626
From: Mark Brown
Date: Fri, 22 Jun 2012 17:21:17 +0100
Subject: ASoC: wm8994: Ensure there are enough BCLKs for four channels
Otherwise if someone tries to use all four channels on AIF1 with the
device in master mode we won't be able to clock out all the data.
Signed-off-by: Mark Brown
Cc: stable@vger.kernel.org
---
sound/soc/codecs/wm8994.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
index bb62f4b..235577a 100644
--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -2649,7 +2649,7 @@ static int wm8994_hw_params(struct snd_pcm_substream
*substream,
return -EINVAL;
}
- bclk_rate = params_rate(params) * 2;
+ bclk_rate = params_rate(params) * 4;
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S16_LE:
bclk_rate *= 16;
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: futex: Test for pi_mutex on fault in futex_wait_requeue_pi()
commit: b6070a8d9853eda010a549fa9a09eb8d7269b929
From: Darren Hart
Date: Fri, 20 Jul 2012 11:53:29 -0700
Subject: futex: Test for pi_mutex on fault in futex_wait_requeue_pi()
If fixup_pi_state_owner() faults, pi_mutex may be NULL. Test
for pi_mutex != NULL before testing the owner against current
and possibly unlocking it.
Signed-off-by: Darren Hart
Cc: Dave Jones
Cc: Dan Carpenter
Cc: stable@vger.kernel.org
Link:
http://lkml.kernel.org/r/dc59890338fc413606f04e5c5b131530734dae3d.1342809673.git.dvh...@linux.intel.com
Signed-off-by: Thomas Gleixner
---
kernel/futex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index e2b0fb9..05018bf 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2370,7 +2370,7 @@ static int futex_wait_requeue_pi(u32 __user *uaddr,
unsigned int flags,
* fault, unlock the rt_mutex and return the fault to userspace.
*/
if (ret == -EFAULT) {
- if (rt_mutex_owner(pi_mutex) == current)
+ if (pi_mutex && rt_mutex_owner(pi_mutex) == current)
rt_mutex_unlock(pi_mutex);
} else if (ret == -EINTR) {
/*
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi()
commit: 6f7b0a2a5c0fb03be7c25bd1745baa50582348ef From: Darren Hart Date: Fri, 20 Jul 2012 11:53:31 -0700 Subject: futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi() If uaddr == uaddr2, then we have broken the rule of only requeueing from a non-pi futex to a pi futex with this call. If we attempt this, as the trinity test suite manages to do, we miss early wakeups as q.key is equal to key2 (because they are the same uaddr). We will then attempt to dereference the pi_mutex (which would exist had the futex_q been properly requeued to a pi futex) and trigger a NULL pointer dereference. Signed-off-by: Darren Hart Cc: Dave Jones Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/ad82bfe7f7d130247fbe2b5b4275654807774227.1342809673.git.dvh...@linux.intel.com Signed-off-by: Thomas Gleixner --- kernel/futex.c | 13 - 1 files changed, 8 insertions(+), 5 deletions(-) diff --git a/kernel/futex.c b/kernel/futex.c index 5551ada..3717e7b 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -2231,11 +2231,11 @@ int handle_early_requeue_pi_wakeup(struct futex_hash_bucket *hb, * @uaddr2:the pi futex we will take prior to returning to user-space * * The caller will wait on uaddr and will be requeued by futex_requeue() to - * uaddr2 which must be PI aware. Normal wakeup will wake on uaddr2 and - * complete the acquisition of the rt_mutex prior to returning to userspace. - * This ensures the rt_mutex maintains an owner when it has waiters; without - * one, the pi logic wouldn't know which task to boost/deboost, if there was a - * need to. + * uaddr2 which must be PI aware and unique from uaddr. Normal wakeup will wake + * on uaddr2 and complete the acquisition of the rt_mutex prior to returning to + * userspace. This ensures the rt_mutex maintains an owner when it has waiters; + * without one, the pi logic would not know which task to boost/deboost, if + * there was a need to. * * We call schedule in futex_wait_queue_me() when we enqueue and return there * via the following: @@ -2272,6 +2272,9 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, struct futex_q q = futex_q_init; int res, ret; + if (uaddr == uaddr2) + return -EINVAL; + if (!bitset) return -EINVAL; -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: futex: Fix bug in WARN_ON for NULL q.pi_state
commit: f27071cb7fe3e1d37a9dbe6c0dfc5395cd40fa43 From: Darren Hart Date: Fri, 20 Jul 2012 11:53:30 -0700 Subject: futex: Fix bug in WARN_ON for NULL q.pi_state The WARN_ON in futex_wait_requeue_pi() for a NULL q.pi_state was testing the address (&q.pi_state) of the pointer instead of the value (q.pi_state) of the pointer. Correct it accordingly. Signed-off-by: Darren Hart Cc: Dave Jones Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1c85d97f6e5f79ec389a4ead3e367363c74bd09a.1342809673.git.dvh...@linux.intel.com Signed-off-by: Thomas Gleixner --- kernel/futex.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/futex.c b/kernel/futex.c index 05018bf..5551ada 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -2343,7 +2343,7 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, * signal. futex_unlock_pi() will not destroy the lock_ptr nor * the pi_state. */ - WARN_ON(!&q.pi_state); + WARN_ON(!q.pi_state); pi_mutex = &q.pi_state->pi_mutex; ret = rt_mutex_finish_proxy_lock(pi_mutex, to, &rt_waiter, 1); debug_rt_mutex_free_waiter(&rt_waiter); -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: x86, nops: Missing break resulting in incorrect selection on Intel
commit: d6250a3f12edb3a86db9598ffeca3de8b4a219e9 From: Alan Cox Date: Wed, 25 Jul 2012 16:28:19 +0100 Subject: x86, nops: Missing break resulting in incorrect selection on Intel The Intel case falls through into the generic case which then changes the values. For cases like the P6 it doesn't do the right thing so this seems to be a screwup. Signed-off-by: Alan Cox Link: http://lkml.kernel.org/n/tip-lww2uirad4skzjlmrm0vr...@git.kernel.org Signed-off-by: H. Peter Anvin Cc: --- arch/x86/kernel/alternative.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c index 1f84794..73ef56c 100644 --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -219,7 +219,7 @@ void __init arch_init_ideal_nops(void) ideal_nops = intel_nops; #endif } - + break; default: #ifdef CONFIG_X86_64 ideal_nops = k8_nops; -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: m68k: Make sys_atomic_cmpxchg_32 work on classic m68k
commit: 9e2760d18b3cf179534bbc27692c84879c61b97c From: Andreas Schwab Date: Sat, 28 Jul 2012 00:20:34 +0200 Subject: m68k: Make sys_atomic_cmpxchg_32 work on classic m68k User space access must always go through uaccess accessors, since on classic m68k user space and kernel space are completely separate. Signed-off-by: Andreas Schwab Tested-by: Thorsten Glaser Signed-off-by: Geert Uytterhoeven Cc: stable@vger.kernel.org --- arch/m68k/kernel/sys_m68k.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/m68k/kernel/sys_m68k.c b/arch/m68k/kernel/sys_m68k.c index 8623f8d..9a5932e 100644 --- a/arch/m68k/kernel/sys_m68k.c +++ b/arch/m68k/kernel/sys_m68k.c @@ -479,9 +479,13 @@ sys_atomic_cmpxchg_32(unsigned long newval, int oldval, int d3, int d4, int d5, goto bad_access; } - mem_value = *mem; + /* +* No need to check for EFAULT; we know that the page is +* present and writable. +*/ + __get_user(mem_value, mem); if (mem_value == oldval) - *mem = newval; + __put_user(newval, mem); pte_unmap_unlock(pte, ptl); up_read(&mm->mmap_sem); -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: USB: echi-dbgp: increase the controller wait time to come out of halt.
commit: f96a4216e85050c0a9d41a41ecb0ae9d8e39b509
From: Colin Ian King
Date: Mon, 30 Jul 2012 16:06:42 +0100
Subject: USB: echi-dbgp: increase the controller wait time to come out of halt.
The default 10 microsecond delay for the controller to come out of
halt in dbgp_ehci_startup is too short, so increase it to 1 millisecond.
This is based on emperical testing on various USB debug ports on
modern machines such as a Lenovo X220i and an Ivybridge development
platform that needed to wait ~450-950 microseconds.
Cc:
Signed-off-by: Colin Ian King
Signed-off-by: Jason Wessel
---
drivers/usb/early/ehci-dbgp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/early/ehci-dbgp.c b/drivers/usb/early/ehci-dbgp.c
index 1fc8f12..347bb05 100644
--- a/drivers/usb/early/ehci-dbgp.c
+++ b/drivers/usb/early/ehci-dbgp.c
@@ -450,7 +450,7 @@ static int dbgp_ehci_startup(void)
writel(FLAG_CF, &ehci_regs->configured_flag);
/* Wait until the controller is no longer halted */
- loop = 10;
+ loop = 1000;
do {
status = readl(&ehci_regs->status);
if (!(status & STS_HALT))
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: ASoC: wm8962: Allow VMID time to fully ramp
commit: 9d40e5582c9c4cfb6977ba2a0ca9c2ed82c56f21 From: Mark Brown Date: Mon, 30 Jul 2012 18:24:19 +0100 Subject: ASoC: wm8962: Allow VMID time to fully ramp Required for reliable power up from cold. Signed-off-by: Mark Brown Cc: stable@vger.kernel.org --- sound/soc/codecs/wm8962.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index eaf6586..aa9ce9d 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -2501,6 +2501,9 @@ static int wm8962_set_bias_level(struct snd_soc_codec *codec, /* VMID 2*250k */ snd_soc_update_bits(codec, WM8962_PWR_MGMT_1, WM8962_VMID_SEL_MASK, 0x100); + + if (codec->dapm.bias_level == SND_SOC_BIAS_OFF) + msleep(100); break; case SND_SOC_BIAS_OFF: -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: x86-64, kcmp: The kcmp system call can be common
commit: eaf4ce6c5fed6b4c55f7efcd5fc3477435cab5e9 From: H. Peter Anvin Date: Wed, 1 Aug 2012 15:59:58 -0700 Subject: x86-64, kcmp: The kcmp system call can be common We already use the same system call handler for i386 and x86-64, there is absolutely no reason x32 can't use the same system call, too. Signed-off-by: H. Peter Anvin Cc: H.J. Lu Cc: Cyrill Gorcunov Cc: v3.5 Link: http://lkml.kernel.org/n/tip-vwzk3qbcr3yjyxjg2j38v...@git.kernel.org --- arch/x86/syscalls/syscall_64.tbl |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl index 51171ae..29aed7a 100644 --- a/arch/x86/syscalls/syscall_64.tbl +++ b/arch/x86/syscalls/syscall_64.tbl @@ -318,7 +318,7 @@ 309common getcpu sys_getcpu 31064 process_vm_readvsys_process_vm_readv 31164 process_vm_writev sys_process_vm_writev -31264 kcmpsys_kcmp +312common kcmpsys_kcmp # # x32-specific system call numbers start at 512 to avoid cache impact -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: ALSA: hda - Support dock on Lenovo Thinkpad T530 with ALC269VC
commit: 707fba3fa76a4c882f5d4c1a12430c09bce8
From: Takashi Iwai
Date: Thu, 2 Aug 2012 09:04:39 +0200
Subject: ALSA: hda - Support dock on Lenovo Thinkpad T530 with ALC269VC
Lenovo Thinkpad T530 with ALC269VC codec has a dock port but BIOS
doesn't set up the pins properly. Enable the pins as well as on
Thinkpad X230 Tablet.
Reported-and-tested-by: Mario
Cc: [v3.2+]
Signed-off-by: Takashi Iwai
---
sound/pci/hda/patch_realtek.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 344b221..b9a5c45 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6206,6 +6206,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x21b8, "Thinkpad Edge 14",
ALC269_FIXUP_SKU_IGNORE),
SND_PCI_QUIRK(0x17aa, 0x21ca, "Thinkpad L412", ALC269_FIXUP_SKU_IGNORE),
SND_PCI_QUIRK(0x17aa, 0x21e9, "Thinkpad Edge 15",
ALC269_FIXUP_SKU_IGNORE),
+ SND_PCI_QUIRK(0x17aa, 0x21f6, "Thinkpad T530",
ALC269_FIXUP_LENOVO_DOCK),
SND_PCI_QUIRK(0x17aa, 0x2203, "Thinkpad X230 Tablet",
ALC269_FIXUP_LENOVO_DOCK),
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_QUANTA_MUTE),
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Lenovo Ideapd", ALC269_FIXUP_PCM_44K),
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/14] workqueue: add missing smp_wmb() in process_one_work()
WORK_STRUCT_PENDING is used to claim ownership of a work item and process_one_work() releases it before starting execution. When someone else grabs PENDING, all pre-release updates to the work item should be visible and all updates made by the new owner should happen afterwards. Grabbing PENDING uses test_and_set_bit() and thus has a full barrier; however, clearing doesn't have a matching wmb. Given the preceding spin_unlock and use of clear_bit, I don't believe this can be a problem on an actual machine and there hasn't been any related report but it still is theretically possible for clear_pending to permeate upwards and happen before work->entry update. Add an explicit smp_wmb() before work_clear_pending(). Signed-off-by: Tejun Heo Cc: Oleg Nesterov Cc: stable@vger.kernel.org --- kernel/workqueue.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 70f95ab..5c26d36 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -1997,7 +1997,9 @@ __acquires(&gcwq->lock) spin_unlock_irq(&gcwq->lock); + smp_wmb(); /* paired with test_and_set_bit(PENDING) */ work_clear_pending(work); + lock_map_acquire_read(&cwq->wq->lockdep_map); lock_map_acquire(&lockdep_map); trace_workqueue_execute_start(work); -- 1.7.7.3 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "futex: Mark get_robust_list as deprecated"
On Fri, Aug 3, 2012 at 6:29 AM, Richard Weinberger wrote: > get_robust_list has at least two valid use cases. > 1. checkpoint/restore in userspace > 2. post mortem analysis > > Cc: Randy Dunlap > Cc: Darren Hart > Cc: Peter Zijlstra > Cc: Jiri Kosina > Cc: Eric W. Biederman > Cc: David Howells > Cc: Serge E. Hallyn > Cc: kernel-harden...@lists.openwall.com > Cc: spen...@grsecurity.net > Cc: keesc...@chromium.org > Cc: t...@linutronix.de > Cc: Cyrill Gorcunov > Cc: xe...@parallels.com > Cc: # 3.4.x > Cc: # 3.5.x > Link: > http://lkml.kernel.org/r/CAFLxGvzPVPyXPwjay4a01q1vx4K4Ht56bHjzswYrr1wvB_1dYw%20%28%29%20mail%20!%20gmail%20!%20com > Signed-off-by: Richard Weinberger Acked-by: Kees Cook -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: vfp: only advertise VFPv4 in hwcaps if CONFIG_VFPv3 is enabled
VFPv4 support depends on the VFPv3 context save/restore code, so only advertise support in the hwcaps if the kernel can actually handle it. Cc: # 3.1+ Signed-off-by: Will Deacon KernelVersion: 3.6-rc1 --- arch/arm/vfp/vfpmodule.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c index fb849d0..c834b32 100644 --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -719,8 +719,10 @@ static int __init vfp_init(void) if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100) elf_hwcap |= HWCAP_NEON; #endif +#ifdef CONFIG_VFPv3 if ((fmrx(MVFR1) & 0xf000) == 0x1000) elf_hwcap |= HWCAP_VFPv4; +#endif } } return 0; -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.5] iwlwifi: Check BSS ctx active before call mac80211
From: Ilan Peer
Upstream commit e19ebcab01cc130fa832764d453b263460ec3b91.
It is possible that the BSS context is not active (for example
when the current mode is set to GO), or that the vif->type is
different than station. In such a case we cannot
call mac80211 to report the average rssi for the interface
(the function assumes that the vif is valid and that the type
is station).
Reviewed-by: Emmanuel Grumbach
Signed-off-by: Ilan Peer
Signed-off-by: Johannes Berg
---
This patch narrowly missed 3.5 but is needed there to fix a crash, see
e.g. https://bugzilla.kernel.org/show_bug.cgi?id=45481
drivers/net/wireless/iwlwifi/iwl-agn-lib.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index e55ec6c..c31072d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -617,6 +617,11 @@ static bool iwlagn_fill_txpower_mode(struct iwl_priv *priv,
struct iwl_rxon_context *ctx = &priv->contexts[IWL_RXON_CTX_BSS];
int ave_rssi;
+ if (!ctx->vif || (ctx->vif->type != NL80211_IFTYPE_STATION)) {
+ IWL_DEBUG_INFO(priv, "BSS ctx not active or not in sta mode\n");
+ return false;
+ }
+
ave_rssi = ieee80211_ave_rssi(ctx->vif);
if (!ave_rssi) {
/* no rssi data, no changes to reduce tx power */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: imx: enable emi_slow_gate clock for imx5
On Fri, Aug 03, 2012 at 04:11:08PM +0200, Sascha Hauer wrote: > Can we add a comment that emi_slow_gate is needed for the EIM interface? > It's not obvious from the datasheet and this information might help > people who want to clean up the now unconditionally enabled clocks. > Ok, will amend the following change. diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c index 6eee32a..4bdcaa9 100644 --- a/arch/arm/mach-imx/clk-imx51-imx53.c +++ b/arch/arm/mach-imx/clk-imx51-imx53.c @@ -303,7 +303,7 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil, clk_prepare_enable(clk[aips_tz2]); /* fec */ clk_prepare_enable(clk[spba]); clk_prepare_enable(clk[emi_fast_gate]); /* fec */ - clk_prepare_enable(clk[emi_slow_gate]); + clk_prepare_enable(clk[emi_slow_gate]); /* eim */ clk_prepare_enable(clk[tmax1]); clk_prepare_enable(clk[tmax2]); /* esdhc2, fec */ clk_prepare_enable(clk[tmax3]); /* esdhc1, esdhc4 */ > Otherwise: > > Acked-by: Sascha Hauer > Thanks. -- Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: imx: enable emi_slow_gate clock for imx5
On Thu, Aug 02, 2012 at 11:01:51PM +0800, Shawn Guo wrote: > The imx5 common clock migration causes a regression with smsc911x > driver on imx53-ard board, where a smsc lan9220 controller gets > connected on imx53 with EIM interface. EIM needs clock emi_slow_gate > to be functional. In the new imx5 clock driver, there is no use count > incremented for the clock by enabling it, so the framework closes the > clock at late init time and makes EIM stop working then. > > Enable emi_slow_gate in clock driver initialization to fix the > regression. Can we add a comment that emi_slow_gate is needed for the EIM interface? It's not obvious from the datasheet and this information might help people who want to clean up the now unconditionally enabled clocks. Otherwise: Acked-by: Sascha Hauer Sascha > > Cc: stable@vger.kernel.org > Signed-off-by: Shawn Guo > --- > arch/arm/mach-imx/clk-imx51-imx53.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c > b/arch/arm/mach-imx/clk-imx51-imx53.c > index f608669..6eee32a 100644 > --- a/arch/arm/mach-imx/clk-imx51-imx53.c > +++ b/arch/arm/mach-imx/clk-imx51-imx53.c > @@ -303,6 +303,7 @@ static void __init mx5_clocks_common_init(unsigned long > rate_ckil, > clk_prepare_enable(clk[aips_tz2]); /* fec */ > clk_prepare_enable(clk[spba]); > clk_prepare_enable(clk[emi_fast_gate]); /* fec */ > + clk_prepare_enable(clk[emi_slow_gate]); > clk_prepare_enable(clk[tmax1]); > clk_prepare_enable(clk[tmax2]); /* esdhc2, fec */ > clk_prepare_enable(clk[tmax3]); /* esdhc1, esdhc4 */ > -- > 1.7.5.4 > > > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "futex: Mark get_robust_list as deprecated"
On Fri, Aug 3, 2012 at 3:34 PM, Cyrill Gorcunov wrote: > On Fri, Aug 03, 2012 at 03:29:53PM +0200, Richard Weinberger wrote: >> get_robust_list has at least two valid use cases. >> 1. checkpoint/restore in userspace >> 2. post mortem analysis >> >> Cc: Randy Dunlap >> Cc: Darren Hart >> Cc: Peter Zijlstra >> Cc: Jiri Kosina >> Cc: Eric W. Biederman >> Cc: David Howells >> Cc: Serge E. Hallyn >> Cc: kernel-harden...@lists.openwall.com >> Cc: spen...@grsecurity.net >> Cc: keesc...@chromium.org >> Cc: t...@linutronix.de >> Cc: Cyrill Gorcunov >> Cc: xe...@parallels.com >> Cc: # 3.4.x >> Cc: # 3.5.x >> Link: >> http://lkml.kernel.org/r/CAFLxGvzPVPyXPwjay4a01q1vx4K4Ht56bHjzswYrr1wvB_1dYw%20%28%29%20mail%20!%20gmail%20!%20com >> Signed-off-by: Richard Weinberger >> --- > > Acked-by: Cyrill Gorcunov > > Thanks, Richard! Looks like the patch itself did made into through vger. Will resend later. -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "futex: Mark get_robust_list as deprecated"
On Fri, Aug 03, 2012 at 03:29:53PM +0200, Richard Weinberger wrote: > get_robust_list has at least two valid use cases. > 1. checkpoint/restore in userspace > 2. post mortem analysis > > Cc: Randy Dunlap > Cc: Darren Hart > Cc: Peter Zijlstra > Cc: Jiri Kosina > Cc: Eric W. Biederman > Cc: David Howells > Cc: Serge E. Hallyn > Cc: kernel-harden...@lists.openwall.com > Cc: spen...@grsecurity.net > Cc: keesc...@chromium.org > Cc: t...@linutronix.de > Cc: Cyrill Gorcunov > Cc: xe...@parallels.com > Cc: # 3.4.x > Cc: # 3.5.x > Link: > http://lkml.kernel.org/r/CAFLxGvzPVPyXPwjay4a01q1vx4K4Ht56bHjzswYrr1wvB_1dYw%20%28%29%20mail%20!%20gmail%20!%20com > Signed-off-by: Richard Weinberger > --- Acked-by: Cyrill Gorcunov Thanks, Richard! -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 33/73] x86, microcode: Sanitize per-cpu microcode reloading interface
On Fri, Aug 03, 2012 at 11:43:14AM +0200, Borislav Petkov wrote:
> On Fri, Aug 03, 2012 at 11:04:06AM +0200, Sven Joachim wrote:
> > On 2012-07-31 06:43 +0200, Ben Hutchings wrote:
> >
> > > 3.2-stable review patch. If anyone has any objections, please let me
> > > know.
> >
> > Alas, this does not build if CONFIG_SMP is unset:
> >
> > ,
> > | arch/x86/kernel/microcode_core.c: In function 'reload_store':
> > | arch/x86/kernel/microcode_core.c:304:19: error: 'struct cpuinfo_x86' has
> > no member named 'cpu_index'
> > `
>
> Crap. :-(
>
> 3.2 still has this:
>
> :
> ...
> #ifdef CONFIG_SMP
> /* number of cores as seen by the OS: */
> u16 booted_cores;
> /* Physical processor id: */
> u16 phys_proc_id;
> /* Core id: */
> u16 cpu_core_id;
> /* Compute unit id */
> u8 compute_unit_id;
> /* Index into per_cpu list: */
> u16 cpu_index;
> #endif
> u32 microcode;
> } __attribute__((__aligned__(SMP_CACHE_BYTES)));
> ---
>
> which got removed by
>
> commit 141168c36cdee3ff23d9c7700b0edc47cb65479f
> Author: Kevin Winchester
> Date: Tue Dec 20 20:52:22 2011 -0400
>
> x86: Simplify code by removing a !SMP #ifdefs from 'struct cpuinfo_x86'
>
> Ben, you might want to backport this one too... I'll run a couple of 3.2
> builds with it ontop of 3.2 to verify nothing else breaks.
Ok, 141168c36cdee3ff23d9c7700b0edc47cb65479f doesn't apply cleanly to
3.2-stable, as expected. I've attached a partly backported version. Why
partly? Well, it broke an UP build in mainline which got fixed later by
commit 3f806e50981825fa56a7f1938f24c0680816be45
Author: Borislav Petkov
Date: Fri Feb 3 20:18:01 2012 +0100
x86/mce/AMD: Fix UP build error
141168c36cde ("x86: Simplify code by removing a !SMP #ifdefs
from 'struct cpuinfo_x86'") removed a bunch of CONFIG_SMP ifdefs
around code touching struct cpuinfo_x86 members but also caused
the following build error with Randy's randconfigs:
mce_amd.c:(.cpuinit.text+0x4723): undefined reference to
`cpu_llc_shared_map'
---
which reverted what the original patch removed.
So I've taken out the parts that introduce the breakage from the
backport.
And the attached version survives a bunch of smoke tests like
all{yes,no,mod}config builds on 32 and 64-bit.
@Sven: it should fix the issue on your box too.
HTH.
--
>From 5e2fe6b301f5f969f25e4404a6b9d069957b8aeb Mon Sep 17 00:00:00 2001
From: Kevin Winchester
Date: Tue, 20 Dec 2011 20:52:22 -0400
Subject: [PATCH] x86: Simplify code by removing a !SMP #ifdefs from 'struct
cpuinfo_x86'
Upstream commit: 141168c36cdee3ff23d9c7700b0edc47cb65479f
Several fields in struct cpuinfo_x86 were not defined for the
!SMP case, likely to save space. However, those fields still
have some meaning for UP, and keeping them allows some #ifdef
removal from other files. The additional size of the UP kernel
from this change is not significant enough to worry about
keeping up the distinction:
textdata bss dec hex filename
4737168 506459 972040 6215667 5ed7f3 vmlinux.o.before
4737444 506459 972040 6215943 5ed907 vmlinux.o.after
for a difference of 276 bytes for an example UP config.
If someone wants those 276 bytes back badly then it should
be implemented in a cleaner way.
Signed-off-by: Kevin Winchester
Cc: Steffen Persvold
Link:
http://lkml.kernel.org/r/1324428742-12498-1-git-send-email-kjwinches...@gmail.com
Signed-off-by: Ingo Molnar
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/processor.h | 2 --
arch/x86/kernel/amd_nb.c | 8 ++--
arch/x86/kernel/cpu/amd.c| 2 --
arch/x86/kernel/cpu/common.c | 5 -
arch/x86/kernel/cpu/intel.c | 2 --
arch/x86/kernel/cpu/mcheck/mce.c | 2 --
arch/x86/kernel/cpu/mcheck/mce_amd.c | 5 +
arch/x86/kernel/cpu/proc.c | 4 +---
drivers/edac/sb_edac.c | 2 --
drivers/hwmon/coretemp.c | 7 +++
10 files changed, 7 insertions(+), 32 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index bb3ee3629a0f..f7c89e231c6c 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -99,7 +99,6 @@ struct cpuinfo_x86 {
u16 apicid;
u16 initial_apicid;
u16 x86_clflush_size;
-#ifdef CONFIG_SMP
/* number of cores as seen by the OS: */
u16 booted_cores;
/* Physical processor id: */
@@ -110,7 +109,6 @@ struct cpuinfo_x86 {
u8 compute_unit_id;
/* Index into per_cpu list: */
u16 cpu_index;
-#endif
u32 microcode;
} __attribute__((__aligned__(
Re: [ 33/73] x86, microcode: Sanitize per-cpu microcode reloading interface
On Fri, Aug 03, 2012 at 11:04:06AM +0200, Sven Joachim wrote: > On 2012-07-31 06:43 +0200, Ben Hutchings wrote: > > > 3.2-stable review patch. If anyone has any objections, please let me know. > > Alas, this does not build if CONFIG_SMP is unset: > > , > | arch/x86/kernel/microcode_core.c: In function 'reload_store': > | arch/x86/kernel/microcode_core.c:304:19: error: 'struct cpuinfo_x86' has no > member named 'cpu_index' > ` Crap. :-( 3.2 still has this: : ... #ifdef CONFIG_SMP /* number of cores as seen by the OS: */ u16 booted_cores; /* Physical processor id: */ u16 phys_proc_id; /* Core id: */ u16 cpu_core_id; /* Compute unit id */ u8 compute_unit_id; /* Index into per_cpu list: */ u16 cpu_index; #endif u32 microcode; } __attribute__((__aligned__(SMP_CACHE_BYTES))); --- which got removed by commit 141168c36cdee3ff23d9c7700b0edc47cb65479f Author: Kevin Winchester Date: Tue Dec 20 20:52:22 2011 -0400 x86: Simplify code by removing a !SMP #ifdefs from 'struct cpuinfo_x86' Ben, you might want to backport this one too... I'll run a couple of 3.2 builds with it ontop of 3.2 to verify nothing else breaks. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 33/73] x86, microcode: Sanitize per-cpu microcode reloading interface
On 2012-07-31 06:43 +0200, Ben Hutchings wrote:
> 3.2-stable review patch. If anyone has any objections, please let me know.
Alas, this does not build if CONFIG_SMP is unset:
,
| arch/x86/kernel/microcode_core.c: In function 'reload_store':
| arch/x86/kernel/microcode_core.c:304:19: error: 'struct cpuinfo_x86' has no
member named 'cpu_index'
`
Cheers,
Sven
> From: Borislav Petkov
>
> commit c9fc3f778a6a215ace14ee556067c73982b6d40f upstream.
>
> Microcode reloading in a per-core manner is a very bad idea for both
> major x86 vendors. And the thing is, we have such interface with which
> we can end up with different microcode versions applied on different
> cores of an otherwise homogeneous wrt (family,model,stepping) system.
>
> So turn off the possibility of doing that per core and allow it only
> system-wide.
>
> This is a minimal fix which we'd like to see in stable too thus the
> more-or-less arbitrary decision to allow system-wide reloading only on
> the BSP:
>
> $ echo 1 > /sys/devices/system/cpu/cpu0/microcode/reload
> ...
>
> and disable the interface on the other cores:
>
> $ echo 1 > /sys/devices/system/cpu/cpu23/microcode/reload
> -bash: echo: write error: Invalid argument
>
> Also, allowing the reload only from one CPU (the BSP in
> that case) doesn't allow the reload procedure to degenerate
> into an O(n^2) deal when triggering reloads from all
> /sys/devices/system/cpu/cpuX/microcode/reload sysfs nodes
> simultaneously.
>
> A more generic fix will follow.
>
> Cc: Henrique de Moraes Holschuh
> Cc: Peter Zijlstra
> Signed-off-by: Borislav Petkov
> Link: http://lkml.kernel.org/r/1340280437-7718-2-git-send-email...@amd64.org
> Signed-off-by: H. Peter Anvin
> Signed-off-by: Ben Hutchings
> ---
> arch/x86/kernel/microcode_core.c | 26 +++---
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/kernel/microcode_core.c
> b/arch/x86/kernel/microcode_core.c
> index fbdfc69..24b852b 100644
> --- a/arch/x86/kernel/microcode_core.c
> +++ b/arch/x86/kernel/microcode_core.c
> @@ -298,19 +298,31 @@ static ssize_t reload_store(struct device *dev,
> const char *buf, size_t size)
> {
> unsigned long val;
> - int cpu = dev->id;
> - ssize_t ret = 0;
> + int cpu;
> + ssize_t ret = 0, tmp_ret;
> +
> + /* allow reload only from the BSP */
> + if (boot_cpu_data.cpu_index != dev->id)
> + return -EINVAL;
>
> ret = kstrtoul(buf, 0, &val);
> if (ret)
> return ret;
>
> - if (val == 1) {
> - get_online_cpus();
> - if (cpu_online(cpu))
> - ret = reload_for_cpu(cpu);
> - put_online_cpus();
> + if (val != 1)
> + return size;
> +
> + get_online_cpus();
> + for_each_online_cpu(cpu) {
> + tmp_ret = reload_for_cpu(cpu);
> + if (tmp_ret != 0)
> + pr_warn("Error reloading microcode on CPU %d\n", cpu);
> +
> + /* save retval of the first encountered reload error */
> + if (!ret)
> + ret = tmp_ret;
> }
> + put_online_cpus();
>
> if (!ret)
> ret = size;
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 15/16] MIPS: Fix poweroff failure when HOTPLUG_CPU configured.
When poweroff machine, kernel_power_off() call disable_nonboot_cpus(). And if we have HOTPLUG_CPU configured, disable_nonboot_cpus() is not an empty function but attempt to actually disable the nonboot cpus. Since system state is SYSTEM_POWER_OFF, play_dead() won't be called and thus disable_nonboot_cpus() hangs. Therefore, we make this patch to avoid poweroff failure. Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: stable@vger.kernel.org --- arch/mips/kernel/process.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c index e9a5fd7..69b17a9 100644 --- a/arch/mips/kernel/process.c +++ b/arch/mips/kernel/process.c @@ -72,9 +72,7 @@ void __noreturn cpu_idle(void) } } #ifdef CONFIG_HOTPLUG_CPU - if (!cpu_online(cpu) && !cpu_isset(cpu, cpu_callin_map) && - (system_state == SYSTEM_RUNNING || -system_state == SYSTEM_BOOTING)) + if (!cpu_online(cpu) && !cpu_isset(cpu, cpu_callin_map)) play_dead(); #endif rcu_idle_exit(); -- 1.7.7.3 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
