LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Cedric Le Goater <clg@fr.ibm.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	containers@lists.osdl.org
Subject: Re: [patch -mm] update mq_notify to use a struct pid
Date: Mon, 11 Sep 2006 19:22:20 -0600	[thread overview]
Message-ID: <m1ejuh98vn.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <4505DADD.4080007@fr.ibm.com> (Cedric Le Goater's message of "Mon, 11 Sep 2006 23:53:33 +0200")

Cedric Le Goater <clg@fr.ibm.com> writes:

> Eric W. Biederman wrote:
>
>> Cedric you mentioned a couple of other patches that are in flight.
>> In the future could you please Cc: the containers list so independent
>> efforts are less likely to duplicate work, and we are more likely
>> to review each others patches instead?
>
> yes sure, i was relying on the openvz wiki to avoid duplicated efforts on
> this topic but i guess email is just the one and only tool for this kind of
> development :)

Sure.  Especially when it comes to helping review each others code :)
Not duplicating work is not really my goal, not submitting a patch
after a patch has been reviewed and accepted is.

Plus we need patch review.

Several people working on a patch in parallel if it is difficult
can frequently find a solution that a single person would miss.

>>>> Filling in a struct pid through sysctl is extremely ugly at the
>>>> moment, plus cad_pid needs some locking.
>>> Which distros use /proc/sys/kernel/cad_pid and why ? I can image the need
>>> but i didn't find much on the topic.
>> 
>> I'm not at all certain, and I'm not even certain I care.  The concept
>> is there in the code so it needs to be dealt with.  
>
> OK. It would be nice to make sure this is still in use before trying to
> deal with /proc/sys/kernel/cad_pid.
>
>> Although if I we extend the cad_pid concept it may make a difference.
>
> what do you mean by extending cad_pid ? kill_init() ?

My meaning was every time we are sending a signal to init.  It is quite
possible we should be using cad_pid instead.

>>> is that about updating the siginfos in collect_signal() to hold the right
>>> pid value depending on the pid namespace they are being received ?
>> 
>> Yes in send_signal, and in collect signal.  To make it work easily I needed
>> to add a struct pid to struct sigqueue.  So in send_signal I generate
>> the struct pid from the pid_t value and in collect signal I regenerate
>> the numeric value.
>
> OK. That's what i imagined also but we need a bit more of the pid namespace
> to regenerate the numerical value. So, how will you convert this 'struct
> pid*' in a pid value using the current pid namespace ?

By calling pid_nr :)  The question I guess is how will pid_nr be implemented.

> thinking aloud :
>
> * if the pid namespace of the sending struct pid and current match,
> 	use nr.
> * if they don't,
> 	if the sending pid namespace is the ancestor of the current pid
> 	namespace
> 		use 0
> 	else
> 		it's a bug.
>
> struct pid* needs a pid namespace attribute and pid namespace needs to know
> its parent.

Yes, that sounds correct.

There is also the case that should not come up with signals where
we have a pid from a child namespace, that we should also be able to
compute the pid for.

In essence I intend to have a list of pid_namespace, pid_t pairs connected
to a struct pid that we can look through to find the appropriate pid.

Eric



  reply	other threads:[~2006-09-12  1:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-08 16:39 Cedric Le Goater
2006-09-09  2:39 ` Eric W. Biederman
2006-09-11 10:17   ` Cedric Le Goater
2006-09-11 11:09     ` Eric W. Biederman
2006-09-11 14:05       ` Cedric Le Goater
2006-09-11 19:01         ` Eric W. Biederman
2006-09-11 21:53           ` Cedric Le Goater
2006-09-12  1:22             ` Eric W. Biederman [this message]
2006-09-12 15:37               ` Cedric Le Goater
2006-09-12 16:03                 ` Eric W. Biederman
2006-09-12 11:05           ` Herbert Poetzl
2006-09-12 15:14             ` Eric W. Biederman
2006-09-14 20:01             ` [PATCH/RFC] kthread API conversion for dvb_frontend and av7110 Herbert Poetzl
2006-09-14 21:07               ` Cedric Le Goater
2006-09-14 22:10                 ` Herbert Poetzl
2006-11-17  1:50                   ` Andrew de Quincey
2006-11-22 14:56                     ` [Devel] " Cedric Le Goater
2006-11-22 21:32                       ` [v4l-dvb-maintainer] " Andrew de Quincey
2007-01-24 15:47                       ` Cedric Le Goater
2006-12-12 22:58                     ` Eric W. Biederman
2006-12-12 23:13                       ` Herbert Poetzl
2006-12-13 15:55                         ` [Devel] " Cedric Le Goater
2006-09-11 15:48     ` [patch -mm] update mq_notify to use a struct pid Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1ejuh98vn.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=clg@fr.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [patch -mm] update mq_notify to use a struct pid' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).