On 11/11/21 10:59 AM, Jens Axboe wrote: > On 11/11/21 10:45 AM, Ajay Garg wrote: >> Another report of the issue (different call-flow, but the same error >> at "shmem_read_mapping_page_gfp") at : >> https://lore.kernel.org/lkml/6bb8c25c-cdcf-8bca-3db2-9871a90d518f@xxxxxxxxx/T/#m52d98b6bdb05764524a118b15cec048b34e5ca76 >> >> with a tentative approval for the patch : >> https://lore.kernel.org/lkml/6bb8c25c-cdcf-8bca-3db2-9871a90d518f@xxxxxxxxx/T/#m24c2888a879d428cde5b34c43838301de544eb7e > > Andrew, I've hit this multiple times on resume on my laptop, and it's > a very apparent bug in that b9d02f1bdd98 commit that it doesn't factor > in error pointers. My oops clearly shows it being one too, with ...fff4 > being the dereference address. > > Can we get this pushed upstream asap if you're fine with this patch? Maybe Andrew is out - Linus, if you follow this thread, there are two proposed fixes for this. It'd be nice to have one of them in -rc1. Backstory is that commit: commit b9d02f1bdd98f38e6e5ecacc9786a8f58f3f8b2c Author: Yang Shi <shy828301@xxxxxxxxx> Date: Fri Nov 5 13:41:10 2021 -0700 mm: shmem: don't truncate page if memory failure happens adds a pretty obvious error, where PageHWPoison() is called on an error pointer in shmem_read_mapping_page_gfp(). I can trivially hit this oops on resuming the laptop. -- Jens Axboe
