Re: [PATCH] pid: change task_struct::pid to read-only

[Richard Guy Briggs]

On 13/12/20, Oleg Nesterov wrote:
> Richard, Peter,

Oleg,

> sorry I deleted your emails by accident, so I am replying to my email.

That's ok, you could send yourself a new copy from the "forward" link
here:
	https://lkml.org/lkml/2013/12/20/277
	
> Sure, ASSIGN_CONST() looks "dangerous". Still to me it is safer than
> "(pid_t*)&(tsk->pid)" done by hand. And yes, it is visible to grep.
> 
> But the main point, it is much more readable. Just look at the change
> below,

I completely agree it is more readable and safer, if it works.

> On 12/17, Oleg Nesterov wrote:
> > > >  	if (!thread_group_leader(tsk)) {
> > > >  		struct task_struct *leader = tsk->group_leader;
> > > > +		/* tast_struct::pid is const pid_t, hence the ugly cast */
> > > > +		pid_t *pid_p = (pid_t*)&(tsk->pid);
> > > >
> > > >  		sig->notify_count = -1;	/* for exit_notify() */
> > > >  		for (;;) {
> > > > @@ -950,7 +952,7 @@ static int de_thread(struct task_struct *tsk)
> > > >  		 * Note: The old leader also uses this pid until release_task
> > > >  		 *       is called.  Odd but simple and correct.
> > > >  		 */
> > > > -		tsk->pid = leader->pid;
> > > > +		*pid_p = leader->pid;
> 
> Isn't it ugly to add the temporary? And this temporary is the pointer.
> ASSIGN_CONST(task->pid, leader->pid) is self-documenting and clear.
> 
> The only problem is that
> 
> 	#define ASSIGN_CONST(l, r)      (*(typeof(r) *)&(l) = (r))
> 
> obviously can't work in this case ;) We need something more clever.

Go for it.  I'll just stick with what I found works.  I gave it a shot
to do it in one step and failed.  I moved on.

> Oleg.

- RGB

--
Richard Guy Briggs <rbriggs@xxxxxxxxxx>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/