On Wed 18-03-15 16:40:34, Vlastimil Babka wrote: > On 03/18/2015 04:02 PM, Michal Hocko wrote: > >On Wed 18-03-15 15:34:50, Vlastimil Babka wrote: > >>On 03/16/2015 03:08 PM, Michal Hocko wrote: > >>>@@ -1080,6 +1080,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, > >>> unsigned long haddr; > >>> unsigned long mmun_start; /* For mmu_notifiers */ > >>> unsigned long mmun_end; /* For mmu_notifiers */ > >>>+ gfp_t huge_gfp = GFP_TRANSHUGE; /* for allocation and charge */ > >> > >>This value is actually never used. Is it here because the compiler emits a > >>spurious non-initialized value warning otherwise? It should be easy for it > >>to prove that setting new_page to something non-null implies initializing > >>huge_gfp (in the hunk below), and NULL new_page means it doesn't reach the > >>mem_cgroup_try_charge() call? > > > >No, I haven't tried to workaround the compiler. It just made the code > >more obvious to me. I can remove the initialization if you prefer, of > >course. > > Yeah IMHO it would be better to remove it, if possible. Leaving it has the > (albeit small) chance that future patch will again use the value in the code > before it's determined based on defrag setting. Wouldn't an uninitialized value be used in such a case? -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>