On Thu, Oct 06, 2022 at 01:33:31PM -0700, Andrew Morton wrote: > On Wed, 5 Oct 2022 21:05:55 -0700 ira.weiny@xxxxxxxxx wrote: > > > kmap_to_page() is used to get the page for a virtual address which may > > be kmap'ed. Unfortunately, kmap_local_page() stores mappings in a > > thread local array separate from kmap(). These mappings were not > > checked by the call. > > > > Check the kmap_local_page() mappings and return the page if found. > > > > Because it is intended to remove kmap_to_page() add a warn on once to > > the kmap checks to flag potential issues early. > > What were the user-visible runtime effects of this? No one actually hit a bug with this because AFAIK only one kmap() call has been converted to kmap_local_page() which then eventually calls kmap_to_page(). https://lore.kernel.org/lkml/YzN+ZYLjK6HI1P1C@ZenIV/ However that has already been fixed by Al in that thread. > > Are we able to identify a Fixes:? I suppose this could be added as a Fixes: to the original patch introducing kmap_local_page()? But one could argue that kmap_to_page() was only intended to support kmap() addresses because it does not work with kmap_atomic() addresses either. I'm proposing this as a stop gap to ensure that work can continue on converting kmap() uses to kmap_local_page() without fear of causing breakage while simultaneously we evaluate and hopefully remove kmap_to_page() as well. Ira
