Re: [PATCH] coda: alloc_upcall: s/task_pgrp_nr/task_pgrp_vnr/

[Eric W. Biederman]

Jan Harkes <jaharkes@xxxxxxxxxx> 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, are
reference counted, are not susceptible to pid wrap around,
and are generally faster to use for sending signals or other
tasks that require looking up a process.

With the introduction of the pid namespaces the difference between
pid_t's and struct pid has become even more important.  Because
based on the pid namespace you are in a given struct pid will have
a different pid_t value.  So internally we are moving as much
as possible to using struct pid pointers.


Oleg is in the process of cleaning up some of the transition code
and we just need to convert the last couple of pieces of code
so we can do that.


In the case of coda I'm assuming it is the user space daemon that
decides if the access is from the resolver process group or not?

That the user space filesystem code does the blocking based on which
process group you are in.

In that case it looks like what needs to happen is that alloc_upcall
needs to know which pid namespace your user space daemon is in.
Probably grab the pid namespace at either mount or connect time (is
there a difference).

Then since I believe the values in the upcall go straight to the user
space 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/