From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [RFC v10][PATCH 09/13] Restore open file descriprtors Date: Mon, 01 Dec 2008 13:07:31 -0800 Message-ID: <1228165651.2971.99.camel@nimitz> References: <1227747884-14150-1-git-send-email-orenl@cs.columbia.edu> <1227747884-14150-10-git-send-email-orenl@cs.columbia.edu> <20081128112745.GR28946@ZenIV.linux.org.uk> <1228159324.2971.74.camel@nimitz> <49344C11.6090204@cs.columbia.edu> <1228164873.2971.95.camel@nimitz> <49345086.4@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49345086.4-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Oren Laadan Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Ingo Molnar , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Linus Torvalds , Al Viro , "H. Peter Anvin" , Andrew Morton , Thomas Gleixner List-Id: linux-api@vger.kernel.org On Mon, 2008-12-01 at 16:00 -0500, Oren Laadan wrote: > > Is that sufficient? It seems like we're depending on the fd's reference > > to the 'struct file' to keep it valid in the hash. If something happens > > to the fd (like the other thread messing with it) the 'struct file' can > > still go away. > > > > Shouldn't we do another get_file() for the hash's reference? > > When a shared object is inserted to the hash we automatically take another > reference to it (according to its type) for as long as it remains in the > hash. See: 'cr_obj_ref_grab()' and 'cr_obj_ref_drop()'. So by moving that > call higher up, we protect the struct file. That's kinda (and by kinda I mean really) disgusting. Hiding that two levels deep in what is effectively the hash table code where no one will ever see it is really bad. It also makes you lazy thinking that the hash code will just know how to take references on whatever you give to it. I think cr_obj_ref_grab() is hideous obfuscation and needs to die. Let's just do the get_file() directly, please. -- Dave -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753654AbYLAVH4 (ORCPT ); Mon, 1 Dec 2008 16:07:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752354AbYLAVHr (ORCPT ); Mon, 1 Dec 2008 16:07:47 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]:36810 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752269AbYLAVHq (ORCPT ); Mon, 1 Dec 2008 16:07:46 -0500 Subject: Re: [RFC v10][PATCH 09/13] Restore open file descriprtors From: Dave Hansen To: Oren Laadan Cc: linux-api@vger.kernel.org, containers@lists.linux-foundation.org, Ingo Molnar , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , Al Viro , "H. Peter Anvin" , Andrew Morton , Thomas Gleixner In-Reply-To: <49345086.4@cs.columbia.edu> References: <1227747884-14150-1-git-send-email-orenl@cs.columbia.edu> <1227747884-14150-10-git-send-email-orenl@cs.columbia.edu> <20081128112745.GR28946@ZenIV.linux.org.uk> <1228159324.2971.74.camel@nimitz> <49344C11.6090204@cs.columbia.edu> <1228164873.2971.95.camel@nimitz> <49345086.4@cs.columbia.edu> Content-Type: text/plain Date: Mon, 01 Dec 2008 13:07:31 -0800 Message-Id: <1228165651.2971.99.camel@nimitz> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2008-12-01 at 16:00 -0500, Oren Laadan wrote: > > Is that sufficient? It seems like we're depending on the fd's reference > > to the 'struct file' to keep it valid in the hash. If something happens > > to the fd (like the other thread messing with it) the 'struct file' can > > still go away. > > > > Shouldn't we do another get_file() for the hash's reference? > > When a shared object is inserted to the hash we automatically take another > reference to it (according to its type) for as long as it remains in the > hash. See: 'cr_obj_ref_grab()' and 'cr_obj_ref_drop()'. So by moving that > call higher up, we protect the struct file. That's kinda (and by kinda I mean really) disgusting. Hiding that two levels deep in what is effectively the hash table code where no one will ever see it is really bad. It also makes you lazy thinking that the hash code will just know how to take references on whatever you give to it. I think cr_obj_ref_grab() is hideous obfuscation and needs to die. Let's just do the get_file() directly, please. -- Dave From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB1L6Nos025285 for ; Mon, 1 Dec 2008 14:06:23 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB1L7i8f215930 for ; Mon, 1 Dec 2008 14:07:44 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB1L7iDX018746 for ; Mon, 1 Dec 2008 14:07:44 -0700 Subject: Re: [RFC v10][PATCH 09/13] Restore open file descriprtors From: Dave Hansen In-Reply-To: <49345086.4@cs.columbia.edu> References: <1227747884-14150-1-git-send-email-orenl@cs.columbia.edu> <1227747884-14150-10-git-send-email-orenl@cs.columbia.edu> <20081128112745.GR28946@ZenIV.linux.org.uk> <1228159324.2971.74.camel@nimitz> <49344C11.6090204@cs.columbia.edu> <1228164873.2971.95.camel@nimitz> <49345086.4@cs.columbia.edu> Content-Type: text/plain Date: Mon, 01 Dec 2008 13:07:31 -0800 Message-Id: <1228165651.2971.99.camel@nimitz> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Oren Laadan Cc: linux-api@vger.kernel.org, containers@lists.linux-foundation.org, Ingo Molnar , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , Al Viro , "H. Peter Anvin" , Andrew Morton , Thomas Gleixner List-ID: On Mon, 2008-12-01 at 16:00 -0500, Oren Laadan wrote: > > Is that sufficient? It seems like we're depending on the fd's reference > > to the 'struct file' to keep it valid in the hash. If something happens > > to the fd (like the other thread messing with it) the 'struct file' can > > still go away. > > > > Shouldn't we do another get_file() for the hash's reference? > > When a shared object is inserted to the hash we automatically take another > reference to it (according to its type) for as long as it remains in the > hash. See: 'cr_obj_ref_grab()' and 'cr_obj_ref_drop()'. So by moving that > call higher up, we protect the struct file. That's kinda (and by kinda I mean really) disgusting. Hiding that two levels deep in what is effectively the hash table code where no one will ever see it is really bad. It also makes you lazy thinking that the hash code will just know how to take references on whatever you give to it. I think cr_obj_ref_grab() is hideous obfuscation and needs to die. Let's just do the get_file() directly, please. -- Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org