Messages in this thread | | | Date | Fri, 9 Dec 2022 13:10:45 -0800 | Subject | Re: [PATCH mm-unstable] mm: clarify folio_set_compound_order() zero support | From | John Hubbard <> |
| |
On 12/9/22 06:27, Muchun Song wrote: > From you advise, I think we can remove VM_BUG_ON and handle non-zero > order page, something like:
Yes, and thanks for summarizing all the individual feedback into a proposed solution.
If we go this route, then I'd suggest a little note above the function, such as:
/* * For non-large folios, this will have no effect, other than possibly * generating a warning, if the caller attempts to set a non-zero folio order * for a non-large folio. */
> static inline void folio_set_order(struct folio *folio, > unsigned int order) > { > if (!folio_test_large(folio)) { > WARN_ON(order);
Better make that a WARN_ON_ONCE(), to avoid taking the machine down with excessive warnings in the log.
> return; > } > > folio->_folio_order = order; > #ifdef CONFIG_64BIT > folio->_folio_nr_pages = order ? 1U << order : 0; > #endif > } > > In this case, > > 1) we can handle both non-zero and zero (folio_order() works as well > for this case) order page. > 2) it can prevent OOB for non-large folio and warn unexpected users. > 3) Do not BUG. > 4) No need to rename folio_set_order. > > What do you think?
If the new behavior is OK with everyone, it seems good to me.
thanks, -- John Hubbard NVIDIA
| |