Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932866Ab3CIQsp (ORCPT ); Sat, 9 Mar 2013 11:48:45 -0500 Received: from mail-ve0-f182.google.com ([209.85.128.182]:46380 "EHLO mail-ve0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760358Ab3CIQso (ORCPT ); Sat, 9 Mar 2013 11:48:44 -0500 MIME-Version: 1.0 In-Reply-To: <877glhkm6b.fsf@xmission.com> References: <20130307132819.GA31162@localhost> <87sj47t97s.fsf@xmission.com> <87d2v9q3sk.fsf@xmission.com> <877glhkm6b.fsf@xmission.com> Date: Sat, 9 Mar 2013 22:48:43 +0600 Message-ID: Subject: Re: [nsproxy] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024 From: Rakib Mullick To: "Eric W. Biederman" Cc: Fengguang Wu , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1706 Lines: 41 On Sat, Mar 9, 2013 at 2:33 PM, Eric W. Biederman wrote: > Rakib Mullick writes: > >> On Fri, Mar 8, 2013 at 10:01 PM, Eric W. Biederman >> wrote: >>> >>> When a new task is created one of two things needs to happen. >>> A) A reference count needs to be added to the current nsproxy. >>> B) B a new nsproxy needs to be created. >>> >>> The way that code works today is far from a shiny example of totally >>> clear code but it is not incorrect. >>> >>> By moving get_nsproxy down below the first return 0, you removed taking >>> the reference count in the one case it is important. >>> >>> Arguably we should apply the patch below for clarity, and I just might >>> queue it up for 3.10. >>> >> This one is much more cleaner. One thing regarding this patch, can we >> check the namespace related flags at copy_namespace() call time at >> copy_process(), also get_nsproxy()? I think this will reduce some >> extra function call overhead and as you've mentioned get_nsproxy() is >> needed at every process creation. > > If you can write a benchmark that can tell the difference, and the code > continues to be readable. It would be worth making the change. > > My gut says you are proposing an optimization that won't have > a measurable impact. > Yes, it'll be hard to measure these sorts of optimization, though I'll try and will tell you if the impact is measurable :). Thanks, Rakib. -- 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/