linux-kernel - Re: [RFC][PATCH] ps command race fix take2 [1/4] list token

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

Date:	Wed, 23 Aug 2006 21:46:40 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	ebiederm@...ssion.com (Eric W. Biederman)
Cc:	linux-kernel@...r.kernel.org, akpm@...l.org, pj@....com,
	saito.tadashi@...t.fujitsu.com, ak@...e.de
Subject: Re: [RFC][PATCH] ps command race fix take2 [1/4] list token

On Wed, 23 Aug 2006 05:35:08 -0600
ebiederm@...ssion.com (Eric W. Biederman) wrote:

> What you are proposing is to reduce contention by having several different
> locks for each of the global data structures. 
not for each, just a lock for a list for for_each_process ;)
About cache bounsing, it's problem if heavy.
In my plan, fork/exit/proc_readdir will have write lock of
for_each_process_write_lock. talking this again after take3 will be good.
If I'm very lucky, I'll find some another way..

> >> >> In addition you only solves half the readdir problems.  You don't solve
> >> >> the seek problem which is returning to an offset you had been to
> >> >> before.  A relatively rare case but...
> >> >> 
> >> > Ah, I should add lseek handler for proc root. Okay.
> >> 
> >> Hmm.  Possibly.  Mostly what I was thinking is that a token in the
> >> list simply cannot solve the problem of a guaranteeing lseek to a
> >> previous position works.  I really haven't looked closely on
> >> how you handle that case.
> >> 
> > I'll try some. But lseek on directory, which is modified at any moment, cannot
> > work stable anyway.
> 
> It can work as well as anything else in readdir.  It can ensure that you don't
> miss things that haven't been added or deleted during the while you are in
> the middle of readdir.    I'm just after the usual Single Unix Spec/POSIX guarantees.
> The same thing that are missing in the current readdir implementation.
> 
BTW, what position means at lseek() in directory ? 
bytes ? implementation dependent ? 

I'm thinking of implementing "position" as offset in task list. 
Hmm..about lseek(), it's obvious that searching in a table has an advantage.
we cannot define position with list.
What will you do if user moves f->pos to not-used-position.

I have no complaint about pidmap scanning next_tgid() unless it doesn't scan
all over the world.

-Kame

-
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/