On 12/8/22 11:33, Matthew Wilcox wrote:
None of the above! Whatever we're calling this function *it does not belong* in mm.h. Anything outside the MM calling it is going to be a disaster -- can you imagine what will happen if a filesystem or device driver is handed a folio and decides "Oh, I'll just change the size of this folio"? It is an attractive nuisance and should be confined to mm/internal.h *at best*. Equally, we *must not have* separate folio_set_order() and folio_set_nr_pages(). These are the same thing! They must be kept in sync! If we are to have a folio_set_order() instead of open-coding it, then it should also update nr_pages. So, given that this is now an internal-to-mm, if not internal-to-hugetlb function, I see no reason that it should not handle the case of 0. I haven't studied what hugetlb_dissolve does, or why it can't use the standard split_folio(), but I'm sure there's a good reason.
Sure, perhaps I overreacted to the "abuse of this function" comment, and the whole thing could be fixed up with a clean name, hiding it from the public mm.h API, and...removing comments about abuse! haha :) thanks, -- John Hubbard NVIDIA
