Re: [PATCH 3/2] fcntl: F_[SG]ETOWN_TID

[Oleg Nesterov <oleg@redhat.com>]

On 08/03, Peter Zijlstra wrote:
>
> On Mon, 2009-08-03 at 19:16 +0200, Oleg Nesterov wrote:
>
> > Hmm, OK. so fcntl(F_SETOWN_TID, -666) <=> fcntl(F_SETOWN, +666).
> >
> > Not that I disagree, but I think this should be discussed. Perhaps
> > F_SETOWN_TID can just reject who < 0.
>
> Yeah, I considered that. Opinions?

Yes, please ;)

> > but the caller of F_GETOWN can't know what the returned value actually
> > means if F_GETOWN_TID was used.
>
> Ah, I made GETOWN_TID deal with !PID but forgot the TID case in GETOWN.
> Yeah, icky, esp since there is no room for errors in the return value :/
> I guess I could make it return 0.

Yes, this is confusing too, but probably better.

> > Perhaps we can just add
> >
> > 	#define F_PIDTYPE_THREAD	PIDTYPE_MAX
> >
> > into fcntl.c ? Then,
> >
> Right, I considered adding PIDTYPE_TID, but then I'd have to go through
> the kernel and make everything consistent, which is where I gave up ;-)

Note! we don't add the new PIDTYPE_TID actually. This F_PIDTYPE_THREAD
is not visible outsie of fcntl.c, we just re-use ->pid_type. Instead
we could add a bit, but using the impossible PIDTYPE_MAX is simpler.

> dunno if people will go for it though..

Yes, I am not sure people will like it.


As for F_XXXOWN/F_XXXWOWN_TID interaction. Another option, perhaps, is add
F_{SET,GET}OWN_EX which accepts a use-visible

	struct f_setown_struct {
		int pid;		// > 0
		int type;		// enumerates PIDTYPE_PID, PIDTYPE_PGID, F_PIDTYPE_THREAD
	}

pointer via arg. Instead of F_XXXOWN_TID + int who.

This way at least the users of new api can't be confused.

I dunno.

Oleg.