On 03/26, Peter Zijlstra wrote:
>
> On Sun, 2012-03-25 at 19:42 +0200, Oleg Nesterov wrote:
> > __cpu_disable() is called by __stop_machine(), we know that nobody
> > can preempt us and other CPUs can do nothing.
>
> It would be very good to not rely on that though,
Ye
On 03/24, Anton Vorontsov wrote:
>
> 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);
On 06/08, Oleg Nesterov wrote:
>
> OK. Thanks a lot Eric for your explanations.
Yes. but may I ask another one?
Shouldn't copy_process()->audit_alloc(tsk) path do
clear_tsk_thread_flag(tsk, TIF_SYSCALL_AUDIT) if it doesn't
set tsk->audit_context?
I can be easily wrong, bu
On 06/08, Eric Paris wrote:
>
> On Wed, 2011-06-08 at 18:36 +0200, Oleg Nesterov wrote:
> > And I guess, all CONFIG_AUDITSYSCALL code in entry.S is only needed to
> > microoptimize the case when TIF_SYSCALL_AUDIT is the only reason for the
> > slow path. I wonder if it rea
On 06/07, Eric Paris wrote:
>
> On Tue, 2011-06-07 at 19:19 +0200, Oleg Nesterov wrote:
> >
> > With or without this patch, can't we call audit_syscall_exit() twice
> > if there is something else in _TIF_WORK_SYSCALL_EXIT mask apart from
> > SYSCALL_AUDIT ? Fir
On 06/03, Eric Paris wrote:
>
> The audit system previously expected arches calling to audit_syscall_exit to
> supply as arguments if the syscall was a success and what the return code was.
> Audit also provides a helper AUDITSC_RESULT which was supposed to simplify
> things
> by converting from n
On 04/23, Jeff Dike wrote:
>
> On Thu, Apr 23, 2009 at 12:17:26AM +0200, Oleg Nesterov wrote:
> > (cc Jeff Dike)
> >
> > So, arch/um/ seems to be the only user of PT_DTRACE.
> >
> > I do not understand this code at all. It looks as if we can just
> > s
On 03/23, Ingo Molnar wrote:
>
> There's an alternative patch
> below. Would you mind to give it a test? Chances are that it will
> make UML even faster than your fix.
>
> Ingo
>
> diff --git a/kernel/sched.c b/kernel/sched.c
> index 3e827b8..2d60f23 100644
> --- a/kernel/sched.c
> +++ b/kern
On 03/20, Miklos Szeredi wrote:
>
> I'm no scheduler expert either.
neither me ;)
> --- linux.git.orig/kernel/sched.c 2009-03-18 12:53:47.0 +0100
> +++ linux.git/kernel/sched.c 2009-03-20 08:58:13.0 +0100
> @@ -4629,7 +4629,8 @@ asmlinkage void __sched preempt_schedule
>
On 03/19, Roland McGrath wrote:
>
> I'm no scheduler expert and I don't know whether the exact placement in
> your change is the optimal one.
Agreed, can't we do a bit more simple patch?
--- kernel/signal.c
+++ kernel/signal.c
@@ -1572,8 +1572,10 @@ static void ptrace_stop
Hello Pierre,
On 09/12, Pierre Morel wrote:
>
> You are right, the functionality can be implemented with the system call.
> But it means we have the overhead of a system call just to clear two bits,
> the TIF_SYSCALL_TRACE and the PTS_SELF.
Yes.
So you want to optimize the code for the (imho ver
On 09/10, Pierre Morel wrote:
>
> Oleg Nesterov wrote:
> >
> >I still think this patch shouldn't change handle_signal().
> >
> >Once again. The signal handler for SIGSYS can first do
> >sys_ptrace(PTRACE_SELF_OFF) (which is filtered out), and then use an
On 09/08, Pierre Morel wrote:
>
> --- linux-2.6.26.orig/arch/s390/kernel/signal.c
> +++ linux-2.6.26/arch/s390/kernel/signal.c
> @@ -409,6 +409,11 @@ handle_signal(unsigned long sig, struct
> spin_unlock_irq(¤t->sighand->siglock);
> }
>
> + if (current->instrumentation) {
>
13 matches
Mail list logo
