On Wed, 21 Mar 2012 09:21:12 +0700, Mai La wrote:
> In this patch:
> - Add CPM node for Maui APM821xxx SoC and Bluestone board in DTS
>
> Signed-off-by: Mai La
> ---
> arch/powerpc/boot/dts/bluestone.dts |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch
On Wed, 2012-03-21 at 17:25 +0100, Wolfgang Denk wrote:
> > > The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes
> with the
> > > ELDK 4.2) this assembly instruction is not known and the build
> breaks.
> >
> > Sigh. GCC 4.2 is pretty old at this point.
>
> But still rock-solid ...
On Sat, Mar 24, 2012 at 01:48:23PM +0100, Peter Zijlstra wrote:
> On Sat, 2012-03-24 at 14:30 +0400, Anton Vorontsov wrote:
> > Traversing the tasks requires holding tasklist_lock, otherwise it
> > is unsafe.
>
> No it doesn't, it either requires tasklist_lock or rcu_read_lock().
Well, currently
Many architctures 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);
The code above has several problems, s
On Sat, 2012-03-24 at 20:21 +0400, Anton Vorontsov wrote:
> Just wonder how do you see the feature implemented?
>
> Something like this?
>
> #define __ret_cond_locked(l, c) __attribute__((ret_cond_locked(l, c)))
> #define __ret_value __attribute__((ret_value))
> #define __ret_loc
On Sat, Mar 24, 2012 at 01:52:54PM +0100, Peter Zijlstra wrote:
[...]
> > p.s. I know Peter Zijlstra detest the __cond_lock() stuff, but untill
> > we have anything better in sparse, let's use it. This particular
> > patch helped me to detect one bug that I myself made during
> > tas
On Sat, 2012-03-24 at 14:31 +0400, Anton Vorontsov wrote:
> This is needed so that callers would not get 'context imbalance'
> warnings from the sparse tool.
>
> As a side effect, this patch fixes the following sparse warnings:
>
> CHECK mm/oom_kill.c
> mm/oom_kill.c:201:28: warning: contex
This is needed so that callers would not get 'context imbalance'
warnings from the sparse tool.
As a side effect, this patch fixes the following sparse warnings:
CHECK mm/oom_kill.c
mm/oom_kill.c:201:28: warning: context imbalance in 'oom_badness' -
unexpected unlock
include/linux/rcupd
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
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()
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()
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()
Many architctures 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);
The code above has several problems, s
Hi all,
This is a reincarnation of the task->mm fixes. Several architectures
were traverse the tasklist in an unsafe manner, plus there are a
few cases of unsafe access to task->mm.
In v2 I decided to introduce a small helper in cpu.c: most arches
duplicate the same [buggy] code snippet, so it's
On Sat, 2012-03-24 at 14:30 +0400, Anton Vorontsov wrote:
> Traversing the tasks requires holding tasklist_lock, otherwise it
> is unsafe.
No it doesn't, it either requires tasklist_lock or rcu_read_lock().
___
Linuxppc-dev mailing list
Linuxppc-dev@lis
On Sat, 2012-03-24 at 14:27 +0400, Anton Vorontsov wrote:
> +void clear_tasks_mm_cpumask(int cpu)
> +{
> + struct task_struct *p;
> +
> + read_lock(&tasklist_lock);
> + for_each_process(p) {
> + struct task_struct *t;
> +
> + t = find_lock_task_mm(p);
>
Am 24.03.2012 11:30, schrieb Anton Vorontsov:
> 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.
os_kill_ptrace
Am 24.03.2012 11:30, schrieb Anton Vorontsov:
> 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 a
Am 24.03.2012 11:31, schrieb Anton Vorontsov:
> 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_loc
Ben, Here it is the updated patch based on your suggestions. Please let
me know if it has any issues.
Thanks
Haren
Some power systems do not have legacy ISA devices. So, /dev/port is not
a valid interface on these systems. User level tools such as kbdrate is
trying to access the device using thi
24 matches
Mail list logo
