Hi all,
This is another resend of several task-mm fixes, the bugs I found
during LMK code audit. Architectures were traverse the tasklist
in an unsafe manner, plus there are a few cases of unsafe access to
task-mm in general.
There were no objections on the previous resend, and the final words
Many architectures clear tasks' mm_cpumask like this:
read_lock(tasklist_lock);
for_each_process(p) {
if (p-mm)
cpumask_clear_cpu(cpu, mm_cpumask(p-mm));
}
read_unlock(tasklist_lock);
Depending on the context, the code above
Checking for process-mm is not enough because process' main
thread may exit or detach its mm via use_mm(), but other threads
may still have a valid mm.
To fix this we would need to use find_lock_task_mm(), which would
walk up all threads and returns an appropriate task (with task
lock held).
Current CPU hotplug code has some task-mm handling issues:
1. Working with task-mm w/o getting mm or grabing the task lock is
dangerous as -mm might disappear (exit_mm() assigns NULL under
task_lock(), so tasklist lock is not enough).
We can't use get_task_mm()/mmput() pair as mmput()
Checking for process-mm is not enough because process' main
thread may exit or detach its mm via use_mm(), but other threads
may still have a valid mm.
To fix this we would need to use find_lock_task_mm(), which would
walk up all threads and returns an appropriate task (with task
lock held).
The patch fixes two problems:
1. Working with task-mm w/o getting mm or grabing the task lock is
dangerous as -mm might disappear (exit_mm() assigns NULL under
task_lock(), so tasklist lock is not enough).
We can't use get_task_mm()/mmput() pair as mmput() might sleep,
so we have to
Oleg Nesterov found an interesting deadlock possibility:
sysrq_showregs_othercpus() does smp_call_function(showacpu)
and showacpu() show_stack()-decode_address(). Now suppose that IPI
interrupts the task holding read_lock(tasklist).
To fix this, blackfin should not grab the write_ variant of
Traversing the tasks requires holding tasklist_lock, otherwise it
is unsafe.
p.s. However, I'm not sure that calling os_kill_ptraced_process()
in the atomic context is correct. It seem to work, but please
take a closer look.
Signed-off-by: Anton Vorontsov anton.voront...@linaro.org
---
Checking for task-mm is dangerous as -mm might disappear (exit_mm()
assigns NULL under task_lock(), so tasklist lock is not enough).
We can't use get_task_mm()/mmput() pair as mmput() might sleep,
so let's take the task lock while we care about its mm.
Note that we should also use
kill_off_processes() might miss a valid process, this is because
checking for process-mm is not enough. Process' main thread may
exit or detach its mm via use_mm(), but other threads may still
have a valid mm.
To catch this we use find_lock_task_mm(), which walks up all
threads and returns an
-Original Message-
From: Aggrwal Poonam-B10812
Sent: Saturday, March 10, 2012 6:27 PM
To: linuxppc-dev@lists.ozlabs.org
Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812
Subject: [PATCH][2/3][RFC] TDM Framework
Any feedback on this patchset?
From: Sandeep Singh
On Mon, Apr 23, 2012 at 06:40:06PM +0900, Boojin Kim wrote:
I met a problem on DMA cyclic mode (DMA_CYCLIC) for sound playback.
Kernel BUG occurs during DMA transfer with DMA cyclic mode.
This patch makes the cookies into zero. But, cookies should be kept
during cyclic mode because cyclic mode
On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote:
Von: Michel Dänzer mic...@daenzer.net
On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote:
Von: Michel Dänzer mic...@daenzer.net
On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote:
The former case is an
On Mon, 2012-04-23 at 10:50 +0100, Russell King - ARM Linux wrote:
On Mon, Apr 23, 2012 at 06:40:06PM +0900, Boojin Kim wrote:
I met a problem on DMA cyclic mode (DMA_CYCLIC) for sound playback.
Kernel BUG occurs during DMA transfer with DMA cyclic mode.
This patch makes the cookies into
Russell King - ARM Linux wrote:
Sent: Wednesday, March 07, 2012 7:35 AM
To: Dan Williams; Vinod Koul
Cc: Stephen Warren; Linus Walleij; Srinidhi Kasagar; Li Yang;
linuxppc-dev@lists.ozlabs.org;
linux-arm-ker...@lists.infradead.org
Subject: [PATCH 5/9] dmaengine: provide a common function
Vinod Koul wrote:
Sent: Monday, April 23, 2012 7:01 PM
To: Russell King - ARM Linux
Cc: 'Stephen Warren'; 'Linus Walleij'; 'Srinidhi Kasagar'; Boojin Kim; 'Dan
Williams'; 'Li Yang';
linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 5/9] dmaengine:
On Mon, Apr 23, 2012 at 08:06:36PM +0900, Boojin Kim wrote:
I met the DMA probing fail problem on Linux 3.4.
It's because the return value on regulator_get() is changed
from ENODEV to EPROBE_DEFER in case not to supply a vcore regulator.
So, I try to change the check value about the return
On 23.04.2012 09:09, Anton Vorontsov wrote:
Traversing the tasks requires holding tasklist_lock, otherwise it
is unsafe.
p.s. However, I'm not sure that calling os_kill_ptraced_process()
in the atomic context is correct. It seem to work, but please
take a closer look.
Signed-off-by: Anton
On Mon, Apr 23, 2012 at 04:57:54PM +0200, Richard Weinberger wrote:
On 23.04.2012 09:09, Anton Vorontsov wrote:
Traversing the tasks requires holding tasklist_lock, otherwise it
is unsafe.
p.s. However, I'm not sure that calling os_kill_ptraced_process()
in the atomic context is correct. It
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Friday, April 20, 2012 4:11 PM
To: Kumar Gala
Cc: Yoder Stuart-B08248; linuxppc-dev@lists.ozlabs.org
Subject: Re: pci node question
On Fri, 2012-04-20 at 13:53 -0500, Kumar Gala wrote:
On
Original-Nachricht
Datum: Mon, 23 Apr 2012 11:56:06 +0200
Von: Michel Dänzer mic...@daenzer.net
An: Gerhard Pircher gerhard_pirc...@gmx.net
CC: linuxppc-dev@lists.ozlabs.org
Betreff: Re: PowerPC radeon KMS - is it possible?
On Fre, 2012-04-20 at 18:14 +0200, Gerhard
On Fri, 20 Apr 2012 13:29:34 +1000, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
mpic_is_ipi() takes a virq and immediately converts it to a hw_irq.
However, one of the two call sites calls it with a ... hw_irq. The
other call site also happens to have the hw_irq at hand, so let's
On Mon, 2012-04-23 at 15:48 +, Yoder Stuart-B08248 wrote:
Hmmm... I vaguely understand what you are saying. But why is the
length zero, that is what doesn't make sense on the surface?
Ah indeed, on would think that we could represent the real size of the
config space there... but I've
On Mon, 2012-04-23 at 11:32 -0600, Grant Likely wrote:
On Fri, 20 Apr 2012 13:29:34 +1000, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
mpic_is_ipi() takes a virq and immediately converts it to a hw_irq.
However, one of the two call sites calls it with a ... hw_irq. The
other
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Monday, April 23, 2012 3:22 PM
To: Yoder Stuart-B08248
Cc: Kumar Gala; linuxppc-dev@lists.ozlabs.org
Subject: RE: pci node question
On Mon, 2012-04-23 at 15:48 +, Yoder Stuart-B08248
On Mon, 2012-04-23 at 20:32 +, Yoder Stuart-B08248 wrote:
/* config space address of the device 0,0,0. OF convention is that
the size of config space is 0. */
...is that accurate?
Dunno about OF convention here, but it's what I've seen done. In any
case, anything with a PCI
Hi Ben,
Here's the 2nd version of the NR_IRQS cleanup patches for PowerPC. I've
addressed your comments and compile tested them, but I've not tried to
boot. If they check out for you then they should probably go into v3.4.
g.
___
Linuxppc-dev
The mpc8xx driver uses a reference to NR_IRQS that is buggy. It uses
NR_IRQs for the array size of the ppc_cached_irq_mask bitmap, but
NR_IRQs could be smaller than the number of hardware irqs that
ppc_cached_irq_mask tracks.
Also, while fixing that problem, it became apparent that the interrupt
The switch from using irq_map to irq_alloc_desc*() for managing irq
number allocations introduced new bugs in some of the powerpc
interrupt code. Several functions rely on the value of NR_IRQS to
determine the maximum irq number that could get allocated. However,
with sparse_irq and using
Oops. Flubbed the subject on the below email. This is the cover
letter for the NR_IRQS patches, so the subject should have included
[PATCH v2 0/2]
On Mon, Apr 23, 2012 at 4:30 PM, Grant Likely grant.lik...@secretlab.ca wrote:
Hi Ben,
Here's the 2nd version of the NR_IRQS cleanup patches for
On 03/10/2012 06:57 AM, Poonam Aggrwal wrote:
diff --git a/drivers/Kconfig b/drivers/Kconfig
index ad6c1eb..25f7f5b 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -130,4 +130,5 @@ source drivers/virt/Kconfig
source drivers/net/dpa/NetCommSw/Kconfig
+source drivers/tdm/Kconfig
On Mon, 2012-04-23 at 16:30 -0600, Grant Likely wrote:
The mpc8xx driver uses a reference to NR_IRQS that is buggy. It uses
NR_IRQs for the array size of the ppc_cached_irq_mask bitmap, but
NR_IRQs could be smaller than the number of hardware irqs that
ppc_cached_irq_mask tracks.
Joakim, any
32 matches
Mail list logo
