linux-kernel - Re: [PATCH 3/2] fcntl: F_[SG]ETOWN

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 3 Aug 2009 20:06:02 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, eranian@...il.com,
	mingo@...e.hu, linux-kernel@...r.kernel.org, tglx@...utronix.de,
	robert.richter@....com, paulus@...ba.org, andi@...stfloor.org,
	mpjohn@...ibm.com, cel@...ibm.com, cjashfor@...ibm.com,
	mucci@...s.utk.edu, terpstra@...s.utk.edu,
	perfmon2-devel@...ts.sourceforge.net, mtk.manpages@...glemail.com,
	roland@...hat.com
Subject: Re: [PATCH 3/2] fcntl: F_[SG]ETOWN_TID

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/