On Fri, Oct 08, 2021 at 11:02:14AM +0800, Hao Sun wrote: > Matthew Wilcox <willy@xxxxxxxxxxxxx> 于2021年10月7日周四 下午10:20写道： > > > > On Thu, Oct 07, 2021 at 02:40:29PM +0800, Hao Sun wrote: > > > Hello, > > > > > > This crash can still be triggered repeatedly on the latest kernel. > > > > I asked you three days ago to try a patch and report the results: > > > > https://lore.kernel.org/linux-mm/YVtWhVNFhLbA9+Tl@xxxxxxxxxxxxxxxxxxxx/ > > Sorry, I missed that. > > Here are the results. > Used reproducer: https://paste.ubuntu.com/p/yrYsn4zpcn/ > Kernel log *before* applying the patch: https://paste.ubuntu.com/p/WtkFKB6Vy9/ > Kernel log *after* applying the patch: https://paste.ubuntu.com/p/S2VrtDdggp/ > Symbolized log: https://paste.ubuntu.com/p/RwXjCXDxB8/ OK, so that's ioctl(fd, BLKRRPART). That reproducer is a beast, and I can't help but think it could be minimised. I think I see what's going on here though. We open a block device, mount some stuff on it. khugepaged comes through and decides to create a THP for some of the pages on it. Nobody has it open for write, so why not? But then the filesystem on top of it dirties something -- it doesn't need to go through an open file descriptor because it's a filesystem. So when we call BLKRRPART, it tries to write the dirty things back (which it should) and things go wrong because the writeback path is not equipped to handle compound pages. So, yeah, let's do what Yang Shi suggested and tell khugepaged to never try to work on block devices. I can't think how any of this could happen except to a block device, so there's no more insight to be gained here.
