Messages in this thread | | | Date | Mon, 13 Feb 2006 11:02:07 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC][PATCH 04/20] pspace: Allow multiple instaces of the process id namespace |
| |
Quoting Kirill Korotaev (dev@sw.ru): > >>1. > >>flags are neither atomic nor protected with any lock. > > > > > >flags are atomic as they are a machine word. So they do not > >require a read/modify write so they will either be written > >or not written. Plus this allows write-sharing of the appropriate > >cache line which is very polite (assuming the line is not shared with > >something else) > Eric I'm familiar with SMP, thanks :) > Why do you write all this if you agreed below that have problems with it? > > >>2. due to 1) you code is buggy. in this respect do_exit() is not > >>serialized with > >>copy_process(). > >Yes. I may need a memory barrier in there. I need to think > >about that a little more. > memory barrier doesn't help. you really need to think about. > > >>3. due to the same 1) reason > >>> + kill_pspace_info(SIGKILL, (void *)1, tsk->pspace); > >>can miss a task being forked. Bang!!! > > > >Well the only bad thing that can happen is that I get a process that > >can run and observe pid == 1 has exited. So Bang!! is not too > >painful. > And what about references to pspace->child_reaper which was freed already?
This seems a very valid point. And even if you implement code to detect when a process exits whether it is a child_reaper for some pspace, you can't just make pspace->child_reaper = pspace->child_reaper->child_reaper, as the wid may not be valid in the grandparent's namespace, right?
-serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |