Messages in this thread | | | Subject | Re: [PATCH resend] mm/gup: fix try_grab_compound_head() race with split_huge_page() | From | John Hubbard <> | Date | Sat, 12 Jun 2021 00:17:05 -1000 |
| |
On 6/11/21 3:49 PM, Jann Horn wrote: > On Sat, Jun 12, 2021 at 12:36 AM Andrew Morton > <akpm@linux-foundation.org> wrote: >> On Fri, 11 Jun 2021 18:15:45 +0200 Jann Horn <jannh@google.com> wrote: >>> +/* Equivalent to calling put_page() @refs times. */ >>> +static void put_page_refs(struct page *page, int refs) >>> +{ >>> + VM_BUG_ON_PAGE(page_ref_count(page) < refs, page); >> >> I don't think there's a need to nuke the whole kernel in this case. >> Can we warn then simply leak the page? That way we have a much better >> chance of getting a good bug report. > > Ah, yeah, I guess that makes sense. I had just copied this over from > put_compound_head(), and figured it was fine to keep it as-is, but I > guess changing it would be reasonable. I'm not quite sure what the > best way to do that would be though. > > I guess the check should go away in !DEBUG_VM builds? > > Should I just explicitly put the check in an ifdef block? Like so: > > #ifdef CONFIG_DEBUG_VM > if (VM_WARN_ON_ONCE_PAGE(...)) > return; > #endif > > Or, since inline ifdeffery looks ugly, get rid of the explicit ifdef,
Agreed: VM_WARN_ON_ONCE_PAGE(), at least at the API level, seems like the best thing to use here. However, as you point out below, it needs a little something first.
> and change the !DEBUG_VM definition of VM_WARN_ON_ONCE_PAGE() as > follows so that the branch is compiled away? > > #define VM_WARN_ON_ONCE_PAGE(cond, page) (BUILD_BUG_ON_INVALID(cond), false) > > That would look kinda neat, but it would be different from the > behavior of WARN_ON(), which still returns the original condition even > in !BUG builds, so that could be confusing... >
The VM_WARN_ON_ONCE_PAGE() is not implemented exactly right in the !CONFIG_DEBUG_VM case. IMHO it should follow the WARN*() behavior, and return the original condition and keep going in that case.
Then you could use it directly here.
thanks,
-- John Hubbard NVIDIA
| |