Prev: SLUB: Don't drop __GFP_NOFAIL completely from allocate_slab() (was: Re: [Bug #14265] ifconfig: page allocation failure. order:5,ode:0x8020 w/ e100)
Next: [PATCH 2.4] net: Fix 64 bit DMA addressing for 8139cp and r8169
From: Andi Kleen on 21 Oct 2009 20:30
On Wed, Oct 21, 2009 at 04:21:37PM -0700, john stultz wrote:
>
> Taking a very raw attempt at this, I scratched out the following simple
> implementation. I'd appreciate any review or suggestions for
> improvements. I'm not at all certain the passing of the thread pid_t
> through the unsigned long is valid, for instance, or if
> same_thread_group() is the right check to make sure we only change
> siblings and not tid from other processes. So any advice on better
> approaches would be great.

First though that comes to mind is that this should not be in prctl()

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 21 Oct 2009 20:50
On Wed, Oct 21, 2009 at 05:42:15PM -0700, john stultz wrote:
> On Thu, 2009-10-22 at 02:28 +0200, Andi Kleen wrote:
> > On Wed, Oct 21, 2009 at 04:21:37PM -0700, john stultz wrote:
> > >
> > > Taking a very raw attempt at this, I scratched out the following simple
> > > implementation. I'd appreciate any review or suggestions for
> > > improvements. I'm not at all certain the passing of the thread pid_t
> > > through the unsigned long is valid, for instance, or if
> > > same_thread_group() is the right check to make sure we only change
> > > siblings and not tid from other processes. So any advice on better
> > > approaches would be great.
> >
> > First though that comes to mind is that this should not be in prctl()
>
> So it deserves a new syscall? Any other thoughts?

I would probably just put it into /proc/pid and use the normal ptrace
access checks.
-Andi

--
ak(a)linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 21 Oct 2009 20:50
> you're pretty much the first now who touches ->comm from
> not-the-thread-itself.... are you sure that is safe?

It's not, there is no locking. On the other hand nothing should crash,
just users might see half rewritten data.
-Andi
--
ak(a)linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: john stultz on 21 Oct 2009 20:50
On Thu, 2009-10-22 at 02:28 +0200, Andi Kleen wrote:
> On Wed, Oct 21, 2009 at 04:21:37PM -0700, john stultz wrote:
> >
> > Taking a very raw attempt at this, I scratched out the following simple
> > implementation. I'd appreciate any review or suggestions for
> > improvements. I'm not at all certain the passing of the thread pid_t
> > through the unsigned long is valid, for instance, or if
> > same_thread_group() is the right check to make sure we only change
> > siblings and not tid from other processes. So any advice on better
> > approaches would be great.
>
> First though that comes to mind is that this should not be in prctl()

So it deserves a new syscall? Any other thoughts?

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arjan van de Ven on 21 Oct 2009 20:50
On Wed, 21 Oct 2009 16:21:37 -0700
john stultz <johnstul(a)us.ibm.com> wrote:

>
> Taking a very raw attempt at this, I scratched out the following
> simple implementation. I'd appreciate any review or suggestions for
> improvements. I'm not at all certain the passing of the thread pid_t
> through the unsigned long is valid, for instance, or if
> same_thread_group() is the right check to make sure we only change
> siblings and not tid from other processes. So any advice on better
> approaches would be great.
>
> + return -EINVAL;
> +
> + set_task_comm(tsk, comm);


you're pretty much the first now who touches ->comm from
not-the-thread-itself.... are you sure that is safe?


--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3 4
Prev: SLUB: Don't drop __GFP_NOFAIL completely from allocate_slab() (was: Re: [Bug #14265] ifconfig: page allocation failure. order:5,ode:0x8020 w/ e100)
Next: [PATCH 2.4] net: Fix 64 bit DMA addressing for 8139cp and r8169