linux-kernel - Re: [PATCH] tracing: Fix issues recording task information

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 6 Jul 2017 21:29:24 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Joel Fernandes <joelaf@...gle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Michael Sartain <mikesart@...il.com>, kernel-team@...roid.com,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] tracing: Fix issues recording task information

On Thu, 6 Jul 2017 16:17:18 -0700
Joel Fernandes <joelaf@...gle.com> wrote:

> Hi Steven,
> 
> On Thu, Jul 6, 2017 at 5:59 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> [..]
> >> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> >> index b66a1c8805f3..27b981a46389 100644
> >> --- a/kernel/trace/trace.c
> >> +++ b/kernel/trace/trace.c
> >> @@ -1918,7 +1918,11 @@ static int trace_save_cmdline(struct task_struct *tsk)
> >>  {
> >>       unsigned pid, idx;
> >>
> >> -     if (!tsk->pid || unlikely(tsk->pid > PID_MAX_DEFAULT))
> >> +     /* treat recording of idle task as a success */
> >> +     if (!tsk->pid)
> >> +             return 1;
> >> +
> >> +     if (unlikely(tsk->pid > PID_MAX_DEFAULT))
> >>               return 0;  
> >
> > Make this a separate patch. This should go to stable.  
> 
> Actually I am not sure if this should be marked for stable since
> before we were doing:
> tracing_record_cmdline(prev);
> tracing_record_cmdline(next);
> in probe_sched_switch, thus even if prev was the idle task, it would
> still goto record the next.

Ah right. I wasn't sure when that change was made. I should have looked
deeper into it.

> 
> IMO it becomes an issue only with the new stuff where we record
> cmdline for prev and next in the same call
> (tracing_record_taskinfo_sched_switch). Anyway I already broke it up
> into a different patch and sent it out. Let me know if anything else
> needs to be done here, thanks.

OK, I'll take a look at it tomorrow.

Thanks,

-- Steve