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,
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
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 wrote:
> Hi Ben,
>
> Here's the 2nd version of the NR_IRQS cleanup patches for PowerPC. I've
> addre
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 irq_all
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
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 mailing
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 de
> -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-B082
On Mon, 2012-04-23 at 11:32 -0600, Grant Likely wrote:
> On Fri, 20 Apr 2012 13:29:34 +1000, Benjamin Herrenschmidt
> 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
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 al
On Fri, 20 Apr 2012 13:29:34 +1000, Benjamin Herrenschmidt
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
> change it to just t
Original-Nachricht
> Datum: Mon, 23 Apr 2012 11:56:06 +0200
> Von: "Michel Dänzer"
> An: Gerhard Pircher
> CC: linuxppc-dev@lists.ozlabs.org
> Betreff: Re: PowerPC radeon KMS - is it possible?
> On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote:
> > > Von: "Michel Dänz
> -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 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 c
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 Voron
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
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:
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 functi
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 i
On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote:
> > Von: "Michel Dänzer"
> > On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote:
> > > > Von: "Michel Dänzer"
> > > > On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote:
> > > > >
> > > > > The "former case" is an explanati
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 m
> -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
>
> TDM Fr
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 app
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 find_lock_tas
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
---
arch/um/kernel/reboot.c |3 +++
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
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
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).
cle
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).
cle
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 ab
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
32 matches
Mail list logo
