From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [PATCH RFC] powerpc: catch 32/64bit mix Date: Wed, 25 Nov 2009 13:16:17 -0600 Message-ID: <20091125191617.GA11814@us.ibm.com> References: <20091125162250.GA9034@us.ibm.com> <4B0D7F96.6050100@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4B0D7F96.6050100-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Oren Laadan Cc: Linux Containers List-Id: containers.vger.kernel.org Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org): > > I can't recall a convincing reason why restore_{thread,cpu}() should > run so late, or in particular after restore_task_objs(). > > I think the original motivation was to avoid the point-of-no-return > at a very early stage. However this is only useful for self-restart. > > If we ever want self-restart to fail gracefully should something go > wrong, we should be prepared to undo any changes to the process - > on the error path. While not beyond reach, it isn't a top priority. > > Does calling restore_{thread,cpu}() earlier solve the problem ? Yes, it does. > BTW, this is also relevant for x86-64... and also 31-bit s390 -serge