On 14/03/27, Stephen Smalley wrote:
> On 03/27/2014 01:20 PM, Richard Guy Briggs wrote:
> > On 14/03/12, James Morris wrote:
> >> On Tue, 11 Mar 2014, Tetsuo Handa wrote:
> >>
> >>> And the same phrase goes to James Morris...
> >>>
> >>> If you are sure that it is safe to use get_task_comm() from
>
On 03/27/2014 01:20 PM, Richard Guy Briggs wrote:
> On 14/03/12, James Morris wrote:
>> On Tue, 11 Mar 2014, Tetsuo Handa wrote:
>>
>>> And the same phrase goes to James Morris...
>>>
>>> If you are sure that it is safe to use get_task_comm() from
>>> dump_common_audit_data() and you prefer locked
On 14/03/12, James Morris wrote:
> On Tue, 11 Mar 2014, Tetsuo Handa wrote:
>
> > And the same phrase goes to James Morris...
> >
> > If you are sure that it is safe to use get_task_comm() from
> > dump_common_audit_data() and you prefer locked version, please pick up below
> > patch via your git
On 14/03/12, James Morris wrote:
> On Tue, 11 Mar 2014, Tetsuo Handa wrote:
> > And the same phrase goes to James Morris...
> >
> > If you are sure that it is safe to use get_task_comm() from
> > dump_common_audit_data() and you prefer locked version, please pick up below
> > patch via your git tr
On Tue, 11 Mar 2014, Tetsuo Handa wrote:
> And the same phrase goes to James Morris...
>
> If you are sure that it is safe to use get_task_comm() from
> dump_common_audit_data() and you prefer locked version, please pick up below
> patch via your git tree.
>
> If you are unsure or prefer lockles
And the same phrase goes to James Morris...
If you are sure that it is safe to use get_task_comm() from
dump_common_audit_data() and you prefer locked version, please pick up below
patch via your git tree.
If you are unsure or prefer lockless version, I'll make a lockless version
using do_get_tas
Richard Guy Briggs wrote:
> > Even if you don't trust the comm= field, it is annoying for me that fields
> > after comm= are missing in the audit log.
>
> More than annoying, that isn't acceptable.
>
OK. If you are sure that it is safe to use get_task_comm() from
audit_log_task() and you prefer l
On 14/03/08, Tetsuo Handa wrote:
> Richard Guy Briggs wrote:
> > > > > Likewise, audit_log_untrustedstring(ab, current->comm) is racy.
> > > > > If task->comm was "Hello Linux" until
> > > > > audit_string_contains_control() in
> > > > > audit_log_n_untrustedstring() returns false, and becom
Richard Guy Briggs wrote:
> > > > Likewise, audit_log_untrustedstring(ab, current->comm) is racy.
> > > > If task->comm was "Hello Linux" until audit_string_contains_control()
> > > > in
> > > > audit_log_n_untrustedstring() returns false, and becomes "Penguin"
> > > > before
> > > > memc
On 14/03/07, Tetsuo Handa wrote:
> Peter Zijlstra wrote:
> > https://lkml.org/lkml/2011/5/17/516
> Thank you for pointing that thread out. I found the following comment in that
> thread.
>
> Linus Torvalds wrote:
> | What folks?
> |
> | I don't think a new lock (or any lock) is at all appropri
Peter Zijlstra wrote:
> I would have actually expected it to stop emitting chars at \0. But
> sure. Couldn't care less though; that's what you get, we all know this,
> we've all been through this discussion several times. Get over it
> already.
>
> One of the last threads on this is:
>
> https:
On Wed, Feb 26, 2014 at 10:44:32PM +0900, Tetsuo Handa wrote:
> Thank you for reviewing, Paul.
No problem, but you do also need to address Lai Jiangshan's and
Peter Zijlstra's questions about the purpose of this patch. I was
looking at it only from a "does it work?" viewpoint.
> Paul E. McKenney
Thank you for reviewing, Paul.
Paul E. McKenney wrote:
> > +/**
> > + * set_task_comm - Change task_struct->comm with tracer and perf hooks
> > called.
> > + *
> > + * @tsk: Pointer to "struct task_struct".
> > + * @buf: New comm name.
> > + *
> > + * Returns nothing.
> > + */
> > +void set_task_
On Tue, Feb 25, 2014 at 09:54:01PM +0900, Tetsuo Handa wrote:
> Lai Jiangshan wrote:
> > CC scheduler people.
> >
> > I can't figure out what we get with this patch.
> >
> OK. Welcome to this thread. I'll explain you what is going on.
>
> Current problem:
>
> printk("%s\n", task->comm) is rac
Lai Jiangshan wrote:
> CC scheduler people.
>
> I can't figure out what we get with this patch.
>
OK. Welcome to this thread. I'll explain you what is going on.
Current problem:
printk("%s\n", task->comm) is racy because "%s" format specifier assumes that
the corresponding argument does not
On Tue, Feb 25, 2014 at 09:49:40AM +0800, Lai Jiangshan wrote:
> >>From ada6c4d94f5afda36c7c21869d38b7111a6fe9bc Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa
> > Date: Mon, 17 Feb 2014 14:32:11 +0900
> > Subject: [PATCH] Change task_struct->comm to use RC
sistency when memory allocation failed.
>
> Fixed race condition in copy_process().
>
> Regards.
> --
>>From ada6c4d94f5afda36c7c21869d38b7111a6fe9bc Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Mon, 17 Feb 2014 14:32:11 +0900
> Subject: [PATCH] C
d.
>
> Fixed race condition in copy_process().
>
> Regards.
> --
> >From ada6c4d94f5afda36c7c21869d38b7111a6fe9bc Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Mon, 17 Feb 2014 14:32:11 +0900
> Subject: [PATCH] Change task_struct->comm to use RCU.
>
> This pa
From: Tetsuo Handa
Date: Mon, 17 Feb 2014 14:32:11 +0900
Subject: [PATCH] Change task_struct->comm to use RCU.
This patch changes task_struct->comm to be updated using RCU
(unless memory allocation fails).
Signed-off-by: Tetsuo Handa
--
19 matches
Mail list logo
