Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753504AbbGXCm1 (ORCPT ); Thu, 23 Jul 2015 22:42:27 -0400 Received: from mga14.intel.com ([192.55.52.115]:40931 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752345AbbGXCmZ (ORCPT ); Thu, 23 Jul 2015 22:42:25 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,535,1432623600"; d="scan'208";a="768666341" Message-ID: <55B1A580.7030801@intel.com> Date: Fri, 24 Jul 2015 10:40:00 +0800 From: Pan Xinhui User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Elliott, Robert (Server Storage)" , "linux-kernel@vger.kernel.org" CC: Thomas Gleixner , Borislav Petkov , "mingo@redhat.com" , "hpa@zytor.com" , "x86@kernel.org" , "bp@suse.de" , "Kani, Toshimitsu" , "jgross@suse.com" , "mcgrof@suse.com" , "mnipxh@163.com" , "yanmin_zhang@linux.intel.com" Subject: Re: [PATCH] x86/mm/pat: Do a small optimization when dump PAT memtype list References: <55B0B9BB.50800@intel.com> <94D0CD8314A33A4D9D801C0FE68B40295AA04A39@G9W0745.americas.hpqcorp.net> In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B40295AA04A39@G9W0745.americas.hpqcorp.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2404 Lines: 72 hi, Elliott thanks for your reply. :) On 2015年07月23日 22:53, Elliott, Robert (Server Storage) wrote: >> -----Original Message----- >> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel- >> owner@vger.kernel.org] On Behalf Of Pan Xinhui >> Sent: Thursday, July 23, 2015 4:54 AM >> To: linux-kernel@vger.kernel.org >> Subject: [PATCH] x86/mm/pat: Do a small optimization when dump PAT memtype >> list > ... >> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c >> index 268b2c8..6302119 100644 >> --- a/arch/x86/mm/pat.c >> +++ b/arch/x86/mm/pat.c >> @@ -1001,45 +1001,42 @@ EXPORT_SYMBOL_GPL(pgprot_writethrough); >> >> #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_X86_PAT) >> >> -static struct memtype *memtype_get_idx(loff_t pos) >> +static struct memtype *memtype_get_idx(struct memtype *entry, loff_t pos) >> { >> - struct memtype *print_entry; >> int ret; >> >> - print_entry = kzalloc(sizeof(struct memtype), GFP_KERNEL); >> - if (!print_entry) >> - return NULL; >> - >> spin_lock(&memtype_lock); >> - ret = rbt_memtype_copy_nth_element(print_entry, pos); >> + ret = rbt_memtype_copy_nth_element(entry, pos); >> spin_unlock(&memtype_lock); >> >> - if (!ret) { >> - return print_entry; >> - } else { >> - kfree(print_entry); >> - return NULL; >> - } >> + return ret ? NULL : entry; >> } >> > ... >> static void memtype_seq_stop(struct seq_file *seq, void *v) >> { >> + kfree(seq->private); >> } >> > > Consider adding > seq->private = NULL; > so the stale pointer isn't left around. There's probably not > much risk of accessing it, but NULL is safer in case it is. > I know exactly what are you worrying about. start and stop callback is still not the best place to alloc/free the *entry*. you are worrying about that some codes might touch it. seq_file.c has offered seq_open_private and seq_release_private. we can make use of them. :) I will work out patch v2, this time I will Cc you. I am very happy if you could review it at any free time. :) thanks xinhui > --- > Robert Elliott, HP Server Storage > -- 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/