linux-kernel - Re: [RFC] on general object IDs again

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:	Wed, 11 Jan 2012 23:57:15 +0400
From:	Pavel Emelyanov <xemul@...allels.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...il.com>
CC:	Cyrill Gorcunov <gorcunov@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kyle Moffett <kyle@...fetthome.net>, Tejun Heo <tj@...nel.org>,
	Glauber Costa <glommer@...allels.com>,
	Andi Kleen <andi@...stfloor.org>,
	Matt Helsley <matthltc@...ibm.com>,
	Pekka Enberg <penberg@...nel.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	"David S. Miller" <davem@...emloft.net>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrey Vagin <avagin@...nvz.org>
Subject: Re: [RFC] on general object IDs again

On 01/11/2012 11:50 PM, KOSAKI Motohiro wrote:
>> This might work for mm_structs, although quite a lot apps now do have threads and
>> this mm->users check will be negative. But how about open files? Once we entered the
>> get-the-youngest-file-owner routine we need to take locks and with 1000 tasks the
>> overhead is not 1000 syscalls, but 1000 (syscalls + locks).
> 
> Unfortunately, I have no knowledge your program have what assumption
> of file modify. When I reviewed mincore patch from you, you said you
> assume any file are preserved. And If nobody change the files, why do
> we need to care file locks? I have no knowledge a grand picture of
> your design at all.

By locking I mean the internal kernel locks that preserve kernel objects
integrity. E.g. to check for a task's file (the struct file) being the one
you're interested in you need to lock the task lock (call the task_lock(p))
in order to get the fdtable pointer.

By the way, if you have a file and want to have its ID the complexity is not
just O(N^2) for N tasks. For each task you should walk the whole fdtable which
just makes things worse.

That said, I'd stick to the IDs that are calculated out of the object pointer.

Thanks,
Pavel
--
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/