On Tue, 17 Sep 2013, Chen Gang wrote: > > Rename mpol_to_str() to __mpol_to_str(). Make a static inline function in > > mempolicy.h named mpol_to_str(). That function does BUILD_BUG_ON(maxlen < > > 64) and then calls __mpol_to_str(). > > > > Modify __mpol_to_str() to store "unknown" when mpol->mode does not match > > any known MPOL_* constant. > > > > Can we be sure 'maxlen' should not be less than 64? For show_numa_map() > in fs/proc/task_mmu.c, it use 50 which is less than 64, is it correct? > Whatever the max string length is that can be stored by mpol_to_str() preferably rounded to the nearest power of two. > Can we be sure that our output contents are always less than 64 bytes? > Do we need BUG_ON() instead of all '-ENOSPC' in mpol_to_str()? > You can determine the maximum string length by looking at the implementation of mpol_to_str(). > Hmm... If assume what you said above was always correct: "we are always > sure 64 bytes is enough, and 'maxlen' should be never less than 64". > > It would be better to use a structure (which has a member "char buf[64]") pointer instead of 'buffer' and 'maxlen'. > (and also still need check 64 memory bondary and '\0' within mpol_to_str). > That's ridiculous, kernel developers who call mpol_to_str() aren't idiots. I think at this point it will just be best if I propose a patch and ask for it to be merged into the -mm tree rather than continue this thread. -- 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>