OpenVZ Forum - RDF feed
type: channel
items: [PATCH 1/3] Signal semantics for /sbin/init
items: Re: [PATCH 1/3] Signal semantics for /sbin/init
items: Re: Re: [PATCH 1/3] Signal semantics for /sbin/init

[PATCH 1/3] Signal semantics for /sbin/init
type: item
description: (This is Oleg's patch with my pid ns additions. Compiled and unit tested on 2.6.23-rc4-mm1 with other patches in this set. Oleg pls update this patch if necessary and sign-off) --- Currently, /sbin/init is protected from unhandled signals by the "current == child_reaper(current)" check in get_signal_to_deliver(). This is not enough, we have multiple problems: - this doesn't work for multi-threaded inits, and we can't fix this by simply making this check group-wide. - /sbin/init and kernel threads are not protected from handle_stop_signal(). Minor problem, but not good and allows to "steal" SIGCONT or change ->signal->flags. - /sbin/init is not protected from __group_complete_signal(), sig_fatal() can set SIGNAL_GROUP_EXIT and block exec(), kill sub-threads, set ->group_stop_count, etc. Also, with support for multiple pid namespaces, we need an ability to actually kill the sub-namespace's init from the parent namespace. In this case it is not possible (without painful and intrusive changes) to make the "should we honor this signal" decision on the receiver's side. Hopefully this patch (adds 43 bytes to kernel/signal.o) can solve these problems. Notes: - Blocked signals are never ignored, so init still can receive a pending blocked signal after sigprocmask(SIG_UNBLOCK). Easy to fix, but probably we can ignore this issue. - this patch allows us to simplify de_thread() playing games with pid_ns->child_reaper. (Side note: the current behaviour of things like force_sig_info_fault() is not very good, init should not ignore these signals and go to the endless loop. Exit + panic is imho better, easy to chamge) Oleg. --- kernel/signal.c | 44 ++++++++++++++++++++++++++++++-------------- 1 file changed, 30 insertions(+), 14 deletions(-) Index: 2.6.23-rc3-mm1/kernel/signal.c =================================================================== --- 2.6.23-rc3-mm1.orig/kernel/signal.c 2007-09-05 12:24:32.000000000 -0700 +++ 2.6.23-rc3-mm1/kernel/signal.c 2007-09-05 12:30:12.00000000…
creator: Sukadev Bhattiprolu
date: 2007-09-11T04:10:30-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: On 09/10, sukadev@us.ibm.com wrote: > > (This is Oleg's patch with my pid ns additions. Compiled and unit tested > on 2.6.23-rc4-mm1 with other patches in this set. Oleg pls update this > patch if necessary and sign-off) Sukadev, my apologies. This patch does need some changes, > Notes: > > - Blocked signals are never ignored, so init still can receive > a pending blocked signal after sigprocmask(SIG_UNBLOCK). > Easy to fix, but probably we can ignore this issue. I was wrong. This should be fixed right now. I _think_ this is easy, and I was going to finish this patch yesterday, but - sorry! - I just can't switch to "kernel mode" these days, I am fighting with some urgent tasks on my paid job. Please feel free to solve this issue yourself if you wish. As for me, I'm forgetting about the kernel until at least the next weekend. Also, Pavel has some ideas how to do this all on receiver's path, perhaps this makes more sense (not that I completely agree, but I didn't see the code yet). Sorry for inconvenience, Oleg. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Oleg Nesterov
date: 2007-09-11T11:19:28-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Oleg Nesterov wrote: > On 09/10, sukadev@us.ibm.com wrote: >> (This is Oleg's patch with my pid ns additions. Compiled and unit tested >> on 2.6.23-rc4-mm1 with other patches in this set. Oleg pls update this >> patch if necessary and sign-off) > > Sukadev, my apologies. This patch does need some changes, > >> Notes: >> >> - Blocked signals are never ignored, so init still can receive >> a pending blocked signal after sigprocmask(SIG_UNBLOCK). >> Easy to fix, but probably we can ignore this issue. > > I was wrong. This should be fixed right now. I _think_ this is easy, > and I was going to finish this patch yesterday, but - sorry! - I just > can't switch to "kernel mode" these days, I am fighting with some urgent > tasks on my paid job. > > Please feel free to solve this issue yourself if you wish. As for me, I'm > forgetting about the kernel until at least the next weekend. > > Also, Pavel has some ideas how to do this all on receiver's path, perhaps > this makes more sense (not that I completely agree, but I didn't see the > code yet). To respect the current init semantic, shouldn't we discard any unblockable signal (STOP and KILL) sent by a process to its pid namespace init process ? Then, all other signals should be handled appropriately by the pid namespace init. We are assuming that the pid namespace init is not doing anything silly and I guess it's OK if the consequences are only on the its pid namespace and not the whole system. Cheers, C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-09-13T15:40:27-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: On 09/13, Cedric Le Goater wrote: > > Oleg Nesterov wrote: > > On 09/10, sukadev@us.ibm.com wrote: > >> (This is Oleg's patch with my pid ns additions. Compiled and unit tested > >> on 2.6.23-rc4-mm1 with other patches in this set. Oleg pls update this > >> patch if necessary and sign-off) > > > > Sukadev, my apologies. This patch does need some changes, > > > >> Notes: > >> > >> - Blocked signals are never ignored, so init still can receive > >> a pending blocked signal after sigprocmask(SIG_UNBLOCK). > >> Easy to fix, but probably we can ignore this issue. > > > > I was wrong. This should be fixed right now. I _think_ this is easy, > > and I was going to finish this patch yesterday, but - sorry! - I just > > can't switch to "kernel mode" these days, I am fighting with some urgent > > tasks on my paid job. > > > To respect the current init semantic, The current init semantic is broken in many ways ;) > shouldn't we discard any unblockable > signal (STOP and KILL) sent by a process to its pid namespace init process ? > Then, all other signals should be handled appropriately by the pid namespace > init. Yes, I think you are probably right, this should be enough in practice. After all, only root can send the signal to /sbin/init. On my machine, /proc/1/status shows that init doesn't have a handler for non-ignored SIGUNUSED == 31, though. But who knows? The kernel promises some guarantees, it is not good to break them. Perhaps some strange non-standard environment may suffer. > We are assuming that the pid namespace init is not doing anything silly and > I guess it's OK if the consequences are only on the its pid namespace and > not the whole system. The sub-namespace case is very easy afaics, we only need the "signal comes from the parent namespace" check, not a problem if we make the decision on the sender's path, like this patch does. Oleg. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.lin…
creator: Oleg Nesterov
date: 2007-09-13T16:58:20-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Oleg Nesterov [oleg@tv-sign.ru] wrote: | On 09/13, Cedric Le Goater wrote: | > | > Oleg Nesterov wrote: | > > On 09/10, sukadev@us.ibm.com wrote: | > >> (This is Oleg's patch with my pid ns additions. Compiled and unit tested | > >> on 2.6.23-rc4-mm1 with other patches in this set. Oleg pls update this | > >> patch if necessary and sign-off) | > > | > > Sukadev, my apologies. This patch does need some changes, | > > | > >> Notes: | > >> | > >> - Blocked signals are never ignored, so init still can receive | > >> a pending blocked signal after sigprocmask(SIG_UNBLOCK). | > >> Easy to fix, but probably we can ignore this issue. | > > | > > I was wrong. This should be fixed right now. I _think_ this is easy, | > > and I was going to finish this patch yesterday, but - sorry! - I just | > > can't switch to "kernel mode" these days, I am fighting with some urgent | > > tasks on my paid job. | > > | > To respect the current init semantic, | | The current init semantic is broken in many ways ;) | | > shouldn't we discard any unblockable | > signal (STOP and KILL) sent by a process to its pid namespace init process ? Yes. And Patch 1/3 (Oleg's patch) in the set I sent, handles this already (since STOP and KILL are never in the task->blocked list) | > Then, all other signals should be handled appropriately by the pid namespace | > init. | | Yes, I think you are probably right, this should be enough in practice. After all, | only root can send the signal to /sbin/init. I agree - the assumption that the container-init will handle these other signals, simplifies the kernel implementation for now. | On my machine, /proc/1/status shows that init doesn't have a handler for | non-ignored SIGUNUSED == 31, though. | | But who knows? The kernel promises some guarantees, it is not good to break them. | Perhaps some strange non-standard environment may suffer. | | > We are assuming that the pid namespace init is not doing anything silly and | > I guess it's OK if the consequences are onl…
creator: Sukadev Bhattiprolu
date: 2007-09-14T03:00:53-00:00

Re: Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Oleg Nesterov <oleg@tv-sign.ru> writes: > On 09/13, Cedric Le Goater wrote: >> Oleg Nesterov wrote: [...] >> To respect the current init semantic, > > The current init semantic is broken in many ways ;) Yup. They sure are, but they are pretty set in stone by now. :) >> shouldn't we discard any unblockable signal (STOP and KILL) sent by a >> process to its pid namespace init process ? Then, all other signals >> should be handled appropriately by the pid namespace init. > > Yes, I think you are probably right, this should be enough in > practice. After all, only root can send the signal to /sbin/init. On > my machine, /proc/1/status shows that init doesn't have a handler for > non-ignored SIGUNUSED == 31, though. > > But who knows? The kernel promises some guarantees, it is not good to > break them. Perhaps some strange non-standard environment may suffer. In this case "strange non-standard environments" would mean anyone running the 'upstart' daemon from recent Ubuntu -- it depends on the current kernel semantics. Regards, Daniel -- Daniel Pittman <daniel@cybersource.com.au> Phone: 03 9621 2377 Level 4, 10 Queen St, Melbourne Web: http://www.cyber.com.au Cybersource: Australia's Leading Linux and Open Source Solutions Company _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Daniel Pittman
date: 2007-09-14T10:16:29-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: On 09/13, sukadev@us.ibm.com wrote: > > Oleg Nesterov [oleg@tv-sign.ru] wrote: > | > > > | > >> Notes: > | > >> > | > >> - Blocked signals are never ignored, so init still can receive > | > >> a pending blocked signal after sigprocmask(SIG_UNBLOCK). > | > >> Easy to fix, but probably we can ignore this issue. > | > > > | > > I was wrong. This should be fixed right now. I _think_ this is easy, > | > > and I was going to finish this patch yesterday, but - sorry! - I just > | > > can't switch to "kernel mode" these days, I am fighting with some urgent > | > > tasks on my paid job. > | > > > | > To respect the current init semantic, > | > | The current init semantic is broken in many ways ;) > | > | > shouldn't we discard any unblockable > | > signal (STOP and KILL) sent by a process to its pid namespace init process ? > > Yes. And Patch 1/3 (Oleg's patch) in the set I sent, handles this already > (since STOP and KILL are never in the task->blocked list) > > > | > Then, all other signals should be handled appropriately by the pid namespace > | > init. > > | > | Yes, I think you are probably right, this should be enough in practice. After all, > | only root can send the signal to /sbin/init. > > I agree - the assumption that the container-init will handle these > other signals, simplifies the kernel implementation for now. > > > | On my machine, /proc/1/status shows that init doesn't have a handler for > | non-ignored SIGUNUSED == 31, though. > | > | But who knows? The kernel promises some guarantees, it is not good to break them. > | Perhaps some strange non-standard environment may suffer. > | > | > We are assuming that the pid namespace init is not doing anything silly and > | > I guess it's OK if the consequences are only on the its pid namespace and > | > not the whole system. > | > | The sub-namespace case is very easy afaics, we only need the "signal comes from > | the parent namespace" check, not a problem if we make the decision on the sender's > | path, like th…
creator: Oleg Nesterov
date: 2007-09-17T15:21:14-00:00

Re: Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: On 09/14, Daniel Pittman wrote: > > Oleg Nesterov <oleg@tv-sign.ru> writes: > > On 09/13, Cedric Le Goater wrote: > >> Oleg Nesterov wrote: > > [...] > > >> To respect the current init semantic, > > > > The current init semantic is broken in many ways ;) > > Yup. They sure are, but they are pretty set in stone by now. :) > > >> shouldn't we discard any unblockable signal (STOP and KILL) sent by a > >> process to its pid namespace init process ? Then, all other signals > >> should be handled appropriately by the pid namespace init. > > > > Yes, I think you are probably right, this should be enough in > > practice. After all, only root can send the signal to /sbin/init. On > > my machine, /proc/1/status shows that init doesn't have a handler for > > non-ignored SIGUNUSED == 31, though. > > > > But who knows? The kernel promises some guarantees, it is not good to > > break them. Perhaps some strange non-standard environment may suffer. > > In this case "strange non-standard environments" would mean anyone > running the 'upstart' daemon from recent Ubuntu -- it depends on the > current kernel semantics. Just curious, could you tell more? What "current kernel semantics" do you mean? Do you mean that the 'upstart' daemon sends the unhandled signal to init? Oleg. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Oleg Nesterov
date: 2007-09-17T15:22:23-00:00

Re: Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Oleg Nesterov <oleg@tv-sign.ru> writes: > On 09/14, Daniel Pittman wrote: >> Oleg Nesterov <oleg@tv-sign.ru> writes: >> > On 09/13, Cedric Le Goater wrote: >> >> Oleg Nesterov wrote: >> >> [...] >> >> >> To respect the current init semantic, >> > >> > The current init semantic is broken in many ways ;) >> >> Yup. They sure are, but they are pretty set in stone by now. :) >> >> >> shouldn't we discard any unblockable signal (STOP and KILL) sent by a >> >> process to its pid namespace init process ? Then, all other signals >> >> should be handled appropriately by the pid namespace init. >> > >> > Yes, I think you are probably right, this should be enough in >> > practice. After all, only root can send the signal to /sbin/init. On >> > my machine, /proc/1/status shows that init doesn't have a handler for >> > non-ignored SIGUNUSED == 31, though. >> > >> > But who knows? The kernel promises some guarantees, it is not good to >> > break them. Perhaps some strange non-standard environment may suffer. >> >> In this case "strange non-standard environments" would mean anyone >> running the 'upstart' daemon from recent Ubuntu -- it depends on the >> current kernel semantics. > > Just curious, could you tell more? What "current kernel semantics" do > you mean? The semantics where (inside the container) init is protected from a wide range of unhandled signals by default. > Do you mean that the 'upstart' daemon sends the unhandled signal to > init? Well, yes and no: upstart does not install a handler for several signals that the traditional sysvinit package uses -- notably, USR1 and USR2 which can trigger reloading of inittab. The Debian/Ubuntu init scripts still send that signal to the init process during boot to ensure compatibility with the traditional init package. The current kernel semantics ensure that upstart can do nothing and the unhandled signal does it no harm -- expect, under OpenVZ while getting Ubuntu working I found that it was not protected and the init script w…
creator: Daniel Pittman
date: 2007-09-17T23:20:34-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Oleg Nesterov [oleg@tv-sign.ru] wrote: | On 09/13, sukadev@us.ibm.com wrote: | > | > Oleg Nesterov [oleg@tv-sign.ru] wrote: | > | > > | > | > >> Notes: | > | > >> | > | > >> - Blocked signals are never ignored, so init still can receive | > | > >> a pending blocked signal after sigprocmask(SIG_UNBLOCK). | > | > >> Easy to fix, but probably we can ignore this issue. | > | > > | > | > > I was wrong. This should be fixed right now. I _think_ this is easy, | > | > > and I was going to finish this patch yesterday, but - sorry! - I just | > | > > can't switch to "kernel mode" these days, I am fighting with some urgent | > | > > tasks on my paid job. | > | > > | > | > To respect the current init semantic, | > | | > | The current init semantic is broken in many ways ;) | > | | > | > shouldn't we discard any unblockable | > | > signal (STOP and KILL) sent by a process to its pid namespace init process ? | > | > Yes. And Patch 1/3 (Oleg's patch) in the set I sent, handles this already | > (since STOP and KILL are never in the task->blocked list) | > | > | > | > Then, all other signals should be handled appropriately by the pid namespace | > | > init. | > | > | | > | Yes, I think you are probably right, this should be enough in practice. After all, | > | only root can send the signal to /sbin/init. | > | > I agree - the assumption that the container-init will handle these | > other signals, simplifies the kernel implementation for now. | > | > | > | On my machine, /proc/1/status shows that init doesn't have a handler for | > | non-ignored SIGUNUSED == 31, though. | > | | > | But who knows? The kernel promises some guarantees, it is not good to break them. | > | Perhaps some strange non-standard environment may suffer. | > | | > | > We are assuming that the pid namespace init is not doing anything silly and | > | > I guess it's OK if the consequences are only on the its pid namespace and | > | > not the whole system. | > | | > | The sub-namespace case is very easy afaics, we on…
creator: Sukadev Bhattiprolu
date: 2007-09-18T19:00:52-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Oleg, Any thoughts on how to proceed with this patchset ? While not complete with respect to blocked signals and container init, would this patchset make semantics slightly better than they are today (container-init can be terminated from within the container) ? Suka sukadev@us.ibm.com [sukadev@us.ibm.com] wrote: | Oleg Nesterov [oleg@tv-sign.ru] wrote: | | On 09/13, sukadev@us.ibm.com wrote: | | > | | > Oleg Nesterov [oleg@tv-sign.ru] wrote: | | > | > > | | > | > >> Notes: | | > | > >> | | > | > >> - Blocked signals are never ignored, so init still can receive | | > | > >> a pending blocked signal after sigprocmask(SIG_UNBLOCK). | | > | > >> Easy to fix, but probably we can ignore this issue. | | > | > > | | > | > > I was wrong. This should be fixed right now. I _think_ this is easy, | | > | > > and I was going to finish this patch yesterday, but - sorry! - I just | | > | > > can't switch to "kernel mode" these days, I am fighting with some urgent | | > | > > tasks on my paid job. | | > | > > | | > | > To respect the current init semantic, | | > | | | > | The current init semantic is broken in many ways ;) | | > | | | > | > shouldn't we discard any unblockable | | > | > signal (STOP and KILL) sent by a process to its pid namespace init process ? | | > | | > Yes. And Patch 1/3 (Oleg's patch) in the set I sent, handles this already | | > (since STOP and KILL are never in the task->blocked list) | | > | | > | | > | > Then, all other signals should be handled appropriately by the pid namespace | | > | > init. | | > | | > | | | > | Yes, I think you are probably right, this should be enough in practice. After all, | | > | only root can send the signal to /sbin/init. | | > | | > I agree - the assumption that the container-init will handle these | | > other signals, simplifies the kernel implementation for now. | | > | | > | | > | On my machine, /proc/1/status shows that init doesn't have a handler for | | > | non-ignored SIGUNUSED == 31, though. | | > | | | > | But who kn…
creator: Sukadev Bhattiprolu
date: 2007-09-27T03:04:53-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Hi Sukadev, On 09/26, sukadev@us.ibm.com wrote: > > Any thoughts on how to proceed with this patchset ? While not complete > with respect to blocked signals and container init, would this patchset > make semantics slightly better than they are today (container-init can > be terminated from within the container) ? Please do what you think right, and please use/drop this patch as you wish. I am really sorry, I am very busy with my paid job, and it is very far from the kernel hacking. I don't have the time/energy to follow :( Besides, I've already lost the track on what's going on in this area... Perhaps I will be able to return in a couple of weeks, but can't promise anything. Good luck ;) Oleg. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Oleg Nesterov
date: 2007-09-28T10:36:15-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > Oleg Nesterov [oleg@tv-sign.ru] wrote: > | On 09/13, sukadev@us.ibm.com wrote: > | > > | > Oleg Nesterov [oleg@tv-sign.ru] wrote: > | > | > > > | > | > >> Notes: > | > | > >> > | > | > >> - Blocked signals are never ignored, so init still can receive > | > | > >> a pending blocked signal after sigprocmask(SIG_UNBLOCK). > | > | > >> Easy to fix, but probably we can ignore this issue. > | > | > > > | > | > > I was wrong. This should be fixed right now. I _think_ this is easy, > | > | > > and I was going to finish this patch yesterday, but - sorry! - I just > | > | > > can't switch to "kernel mode" these days, I am fighting with some urgent > | > | > > tasks on my paid job. > | > | > > > | > | > To respect the current init semantic, > | > | > | > | The current init semantic is broken in many ways ;) > | > | > | > | > shouldn't we discard any unblockable > | > | > signal (STOP and KILL) sent by a process to its pid namespace init process ? > | > > | > Yes. And Patch 1/3 (Oleg's patch) in the set I sent, handles this already > | > (since STOP and KILL are never in the task->blocked list) > | > > | > > | > | > Then, all other signals should be handled appropriately by the pid namespace > | > | > init. > | > > | > | > | > | Yes, I think you are probably right, this should be enough in practice. After all, > | > | only root can send the signal to /sbin/init. > | > > | > I agree - the assumption that the container-init will handle these > | > other signals, simplifies the kernel implementation for now. > | > > | > > | > | On my machine, /proc/1/status shows that init doesn't have a handler for > | > | non-ignored SIGUNUSED == 31, though. > | > | > | > | But who knows? The kernel promises some guarantees, it is not good to break them. > | > | Perhaps some strange non-standard environment may suffer. > | > | > | > | > We are assuming that the pid namespace init is not doing anything silly and > | > | > I guess it's OK if the c…
creator: serue
date: 2007-10-01T17:00:35-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Serge E. Hallyn [serue@us.ibm.com] wrote: | Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): | > Oleg Nesterov [oleg@tv-sign.ru] wrote: | > | On 09/13, sukadev@us.ibm.com wrote: | > | > | > | > Oleg Nesterov [oleg@tv-sign.ru] wrote: | > | > | > > | > | > | > >> Notes: | > | > | > >> | > | > | > >> - Blocked signals are never ignored, so init still can receive | > | > | > >> a pending blocked signal after sigprocmask(SIG_UNBLOCK). | > | > | > >> Easy to fix, but probably we can ignore this issue. | > | > | > > | > | > | > > I was wrong. This should be fixed right now. I _think_ this is easy, | > | > | > > and I was going to finish this patch yesterday, but - sorry! - I just | > | > | > > can't switch to "kernel mode" these days, I am fighting with some urgent | > | > | > > tasks on my paid job. | > | > | > > | > | > | > To respect the current init semantic, | > | > | | > | > | The current init semantic is broken in many ways ;) | > | > | | > | > | > shouldn't we discard any unblockable | > | > | > signal (STOP and KILL) sent by a process to its pid namespace init process ? | > | > | > | > Yes. And Patch 1/3 (Oleg's patch) in the set I sent, handles this already | > | > (since STOP and KILL are never in the task->blocked list) | > | > | > | > | > | > | > Then, all other signals should be handled appropriately by the pid namespace | > | > | > init. | > | > | > | > | | > | > | Yes, I think you are probably right, this should be enough in practice. After all, | > | > | only root can send the signal to /sbin/init. | > | > | > | > I agree - the assumption that the container-init will handle these | > | > other signals, simplifies the kernel implementation for now. | > | > | > | > | > | > | On my machine, /proc/1/status shows that init doesn't have a handler for | > | > | non-ignored SIGUNUSED == 31, though. | > | > | | > | > | But who knows? The kernel promises some guarantees, it is not good to break them. | > | > | Perhaps some strange non-standard environment may suffer…
creator: Sukadev Bhattiprolu
date: 2007-10-01T17:47:20-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > Serge E. Hallyn [serue@us.ibm.com] wrote: > | Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > | > Oleg Nesterov [oleg@tv-sign.ru] wrote: > | > | On 09/13, sukadev@us.ibm.com wrote: > | > | > > | > | > Oleg Nesterov [oleg@tv-sign.ru] wrote: > | > | > | > > > | > | > | > >> Notes: > | > | > | > >> > | > | > | > >> - Blocked signals are never ignored, so init still can receive > | > | > | > >> a pending blocked signal after sigprocmask(SIG_UNBLOCK). > | > | > | > >> Easy to fix, but probably we can ignore this issue. > | > | > | > > > | > | > | > > I was wrong. This should be fixed right now. I _think_ this is easy, > | > | > | > > and I was going to finish this patch yesterday, but - sorry! - I just > | > | > | > > can't switch to "kernel mode" these days, I am fighting with some urgent > | > | > | > > tasks on my paid job. > | > | > | > > > | > | > | > To respect the current init semantic, > | > | > | > | > | > | The current init semantic is broken in many ways ;) > | > | > | > | > | > | > shouldn't we discard any unblockable > | > | > | > signal (STOP and KILL) sent by a process to its pid namespace init process ? > | > | > > | > | > Yes. And Patch 1/3 (Oleg's patch) in the set I sent, handles this already > | > | > (since STOP and KILL are never in the task->blocked list) > | > | > > | > | > > | > | > | > Then, all other signals should be handled appropriately by the pid namespace > | > | > | > init. > | > | > > | > | > | > | > | > | Yes, I think you are probably right, this should be enough in practice. After all, > | > | > | only root can send the signal to /sbin/init. > | > | > > | > | > I agree - the assumption that the container-init will handle these > | > | > other signals, simplifies the kernel implementation for now. > | > | > > | > | > > | > | > | On my machine, /proc/1/status shows that init doesn't have a handler for > | > | > | non-ignored SIGUNUSED == 31, though. > | > | > | > | > | > | But who kno…
creator: serue
date: 2007-10-01T18:08:49-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: | > | > One solution I was thinking of was to possibly queue pending blocked | > | > signals to a container init seperately and then requeue them on the | > | > normal queue when signals are unblocked. Its definitely not an easier | > | > solution, but might be less intrusive than the "signal from parent ns | > | > flag" solution. Hmm. Stumbled upon an issue while coding this up. For real time signals, is the order in which signals are delivered important ? If so, the above solution won't work, because when requeing signals from pid namespace to the task, we may lose the order of signals. i.e: - signal sig1 is blocked. - sig1 is posted and queued on the ns->cinit_blocked_pending queue - just as we enter sigprocmask() to unblock sig1, if sig2 is posted, we queue sig2 on task->pending queue since sig2 is not blocked. - when we actually unblock sig1, if we requeue ns->cinit_blocked_pending signals (i.e sig1) after sig2 we end up reversing the order of the signals sig1 and sig2. if we requeue the ns-> signals before sig2 and another sig1 was received after the sig2 and just before the unblock, we again lose the order. The order of signals is not important to legacy signals (< SIGRTMIN) but is probably an issue for signals SIGRTMIN..SIGRTMAX. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2007-10-05T04:30:30-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > | > | > One solution I was thinking of was to possibly queue pending blocked > | > | > signals to a container init seperately and then requeue them on the > | > | > normal queue when signals are unblocked. Its definitely not an easier > | > | > solution, but might be less intrusive than the "signal from parent ns > | > | > flag" solution. > > Hmm. Stumbled upon an issue while coding this up. > > For real time signals, is the order in which signals are delivered > important ? A very quick, inadequate google search suggests that while order is important, the order in which they should be delivered is in increasing signal number. So that should be easy enough to maintain with this type of patch, right? -serge > If so, the above solution won't work, because when requeing > signals from pid namespace to the task, we may lose the order of signals. > > i.e: > - signal sig1 is blocked. > > - sig1 is posted and queued on the ns->cinit_blocked_pending queue > > - just as we enter sigprocmask() to unblock sig1, if sig2 is > posted, we queue sig2 on task->pending queue since sig2 is not > blocked. > > - when we actually unblock sig1, if we requeue ns->cinit_blocked_pending > signals (i.e sig1) after sig2 we end up reversing the order of the > signals sig1 and sig2. > > if we requeue the ns-> signals before sig2 and another sig1 > was received after the sig2 and just before the unblock, we > again lose the order. > > The order of signals is not important to legacy signals (< SIGRTMIN) but is > probably an issue for signals SIGRTMIN..SIGRTMAX. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2007-10-08T14:36:49-00:00

Re: [PATCH 1/3] Signal semantics for /sbin/init
type: item
description: Serge E. Hallyn [serue@us.ibm.com] wrote: | Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): | > | > | > One solution I was thinking of was to possibly queue pending blocked | > | > | > signals to a container init seperately and then requeue them on the | > | > | > normal queue when signals are unblocked. Its definitely not an easier | > | > | > solution, but might be less intrusive than the "signal from parent ns | > | > | > flag" solution. | > | > Hmm. Stumbled upon an issue while coding this up. | > | > For real time signals, is the order in which signals are delivered | > important ? | | A very quick, inadequate google search suggests that while order is | important, the order in which they should be delivered is in increasing | signal number. So that should be easy enough to maintain with this | type of patch, right? Yes. I could stick all the signals to the end of the queue and the existing code should pick them up in proper order. Thanks, Suka | | -serge | | > If so, the above solution won't work, because when requeing | > signals from pid namespace to the task, we may lose the order of signals. | > | > i.e: | > - signal sig1 is blocked. | > | > - sig1 is posted and queued on the ns->cinit_blocked_pending queue | > | > - just as we enter sigprocmask() to unblock sig1, if sig2 is | > posted, we queue sig2 on task->pending queue since sig2 is not | > blocked. | > | > - when we actually unblock sig1, if we requeue ns->cinit_blocked_pending | > signals (i.e sig1) after sig2 we end up reversing the order of the | > signals sig1 and sig2. | > | > if we requeue the ns-> signals before sig2 and another sig1 | > was received after the sig2 and just before the unblock, we | > again lose the order. | > | > The order of signals is not important to legacy signals (< SIGRTMIN) but is | > probably an issue for signals SIGRTMIN..SIGRTMAX. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundati…
creator: Sukadev Bhattiprolu
date: 2007-10-08T15:42:00-00:00