On 2016/9/30 16:43, Tejun Heo wrote: > Hello, > > On Fri, Sep 30, 2016 at 01:38:35AM +0800, zijun_hu wrote: >> 1) the simpler way don't work because it maybe free many memory block twice > > Right, the punched holes. Forgot about them. Yeah, that's why the > later failure just leaks memory. > >> 2) as we seen, pcpu_setup_first_chunk() doesn't cause a failure, it return 0 >> always or panic by BUG_ON(), even if it fails, we can conclude the allocated >> memory based on information recorded by it, such as pcpu_base_addr and many of >> static variable, we can complete the free operations; but we can't if we >> fail in the case pointed by this patch > > So, being strictly correct doesn't matter that much here. These > things failing indicates that something is very wrong with either the > code or configuration and we might as well trigger BUG. That said, > yeah, it's nicer to recover without leaking anything. > >> 3) my test way is simple, i force "if (max_distance > VMALLOC_TOTAL * 3 / 4)" >> to if (1) and print which memory i allocate before the jumping, then print which memory >> i free after the jumping and before returning, then check whether i free the memory i >> allocate in this function, the result is okay > > Can you please include what has been discussed into the patch > description? > > Thanks. > okay， no problem -- 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>