Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751075AbWIKClg (ORCPT ); Sun, 10 Sep 2006 22:41:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751096AbWIKClg (ORCPT ); Sun, 10 Sep 2006 22:41:36 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:62403 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S1751075AbWIKClf (ORCPT ); Sun, 10 Sep 2006 22:41:35 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Oleg Nesterov Cc: Andrew Morton , linux-kernel@vger.kernel.org, Linux Containers , Alan Cox Subject: Re: [PATCH] vt: Rework the console spawning variables. References: <20060910142942.GA7384@oleg> <20060910203324.GA121@oleg> <20060911010534.GA108@oleg> Date: Sun, 10 Sep 2006 20:40:29 -0600 In-Reply-To: <20060911010534.GA108@oleg> (Oleg Nesterov's message of "Mon, 11 Sep 2006 05:05:34 +0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1495 Lines: 38 Oleg Nesterov writes: > On 09/10, Eric W. Biederman wrote: >> >> Ok. I think I see the where the confusion is. We were looking >> at different parts of the puzzle. But I we need to resolve this >> to make certain I didn't do something clever and racy. > > Yes, I think we misunderstood each other :) > >> As for the rest of your suggestion it would not be hard to be able to >> follow a struct pid pointer in an rcu safe way, and we do in the pid >> hash table. In other contexts so far I always have other variables >> that need to be updated in concert, so there isn't a point in coming >> up with a lockless implementation. I believe vt_pid is the only >> case that I have run across where this is a problem and I have >> at least preliminary patches for every place where signals are >> sent. >> >> Updating this old code is painful. > > No, no, we shouldn't change the old code, it is fine. > So what happens when: cpu0: cpu1: kill_pid(vt_pid,....) fn_SAK()->vc_reset()->put_pid(xchg(&vt_pid, NULL)) Can't kill_pid dereference vt_pid after put_pid is called? It's a microscopic window, and requires the user to attempt a vt switch and a sak simultaneously but I think it is there. Eric - 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/