On Sat, 19 Apr 2014, Oleg Nesterov wrote: > On 04/19, Pavel Machek wrote: > > > > > > Hmm. I seem to see a bug in this function, it can be fulled by use_mm, > > > > but I am not sure this can explain the problem. I'll send a patch. > > > > > > Untested, please review. But it really looks "obviously wrong", and note > > > that unuse_mm() doesn't do mm_update_next_owner(). (just in case, do not > > > confuse it with unuse_mm() in mm/swapfile.c). > > > > Having two functions, one exported, one static with same name -- that > > sounds quite evil, right? > > Yes, agreed.
Doubly agreed; though it seems to have escaped causing confusion for several years, so no great hurry to resolve it. > > > mmu_context.c: * unuse_mm > > mmu_context.c:void unuse_mm(struct mm_struct *mm) > > mmu_context.c:EXPORT_SYMBOL_GPL(unuse_mm); > > swapfile.c:static int unuse_mm(struct mm_struct *mm, > > Yes, I was thinking about s/unuse_mm/unswap_mm/ change in swapfile.c, > but then we should probaly rename other "unuse" functions there, and > shmem_unuse/try_to_unuse are not static. My preference is "swapoff" instead of "unuse" throughout there: it saves having to explain that "unuse" implies "swapoff" each time we send in a patch making a change to that code. But I'd prefer you hold off for the moment: Kelley Nielsen is currently preparing a patchset reworking try_to_unuse, and I suggested a few days ago to include such renaming in that patchset. Partly driven by s390's recent 45961722f8e3 "mm: add support for discard of unused ptes" which adds further confusion with pte_unused(). Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/