Jan Harkes <jaharkes@cs.cmu.edu> writes:> On Sun, Jan 18, 2009 at 08:34:53AM +0100, Oleg Nesterov wrote:>> Needs an ack from maintaner, I do not know where coda_in_hdr->pgid is used.>> It is used to uniquely identify a process and any of it children during> conflict resolution.>> When a conflict is detected, all accesses to the inconsistent object are> blocked. A special resolver process is forked off by the cache manager> and this is run in a new process group and only accesses from processes> in this group are allowed. The resolver process (or any of it's children)> compare the conflicting replicas, and ideally resolve the inconsistency> after which normal accesses are unblocked.>> So yes this should not a per namespace thing, but also not a process> specific pid, the resolver forks off different helper processes> depending on the type of files that are involved in the conflict, i.e.> mbox files require different merge strategy compared to opendocument> files.>> I'm not sure what you are trying to do.We currently have two pid data types in the kernel.pid_t and struct pid *.pid_t's are the tokens we pass to user space to talk about a process, a process group or a session.struct pid pointers are used internally to the kernel, arereference counted, are not susceptible to pid wrap around,and are generally faster to use for sending signals or othertasks that require looking up a process.With the introduction of the pid namespaces the difference betweenpid_t's and struct pid has become even more important. Becausebased on the pid namespace you are in a given struct pid will havea different pid_t value. So internally we are moving as muchas possible to using struct pid pointers.Oleg is in the process of cleaning up some of the transition codeand we just need to convert the last couple of pieces of codeso we can do that.In the case of coda I'm assuming it is the user space daemon thatdecides if the access is from the resolver process group or not?That the user space filesystem code does the blocking based on whichprocess group you are in.In that case it looks like what needs to happen is that alloc_upcallneeds to know which pid namespace your user space daemon is in.Probably grab the pid namespace at either mount or connect time (isthere a difference).Then since I believe the values in the upcall go straight to the userspace daemon we should do roughly:inp->in.pid = task_pid_nr_ns(&fs_daemon_pidns, current);inp->in.pgid = task_pgrp_nr_ns(&fs_daemon_pidns, current);Does that make sense?Eric