[CCing Linus and the regressions list; fwiw, initial report is here: https://lore.kernel.org/all/b2d40565-7868-ba15-4bb1-fca6f0df076b@xxxxxxxxxxxxx/ ] On 04.08.23 05:25, Sergey Senozhatsky wrote: > On (23/08/03 17:32), Dusty Mabe wrote: >>>>>> zram: simplify bvec iteration in __zram_make_request >>>>>> >>>>>> bio_for_each_segment synthetize bvecs that never cross page boundaries, so >>>>>> don't duplicate that work in an inner loop. >>>>> >>>>>> Any ideas on how to fix the problem? >>>>> >>>>> So the interesting cases are: >>>>> >>>>> - ppc64 usually uses 64k page sizes >>>>> - ppc64 is somewhat cache incoherent (compared to say x86) >>>>> >>>>> Let me think of this a bit more. >>>> >>>> Would need to be confirmed first that 64k pages really are in use >>>> (eg we compile ppc64le with 4k page sizes ...). >>>> Dusty? >>>> For which page size did you compile your kernel? >>> >>> For Fedora the configuration is to enable 64k pages with CONFIG_PPC_64K_PAGES=y >>> https://src.fedoraproject.org/rpms/kernel/blob/064c1675a16b4d379b42ab6c3397632ca54ad897/f/kernel-ppc64le-fedora.config#_4791 >>> >>> I used the same configuration when running the git bisect. >> >> Naive question from my side: would this be a candidate for reverting while we investigate the root cause? > > That's certainly a possible solution. > > But I don't quite understand why af8b04c63708 doesn't work. Seems Christoph and Hannes (thx to both of you) got a bit closer to that, but as this apparently is causing data corruption and we are close to -rc5 I'd like to bring the following up now, as it gets harder to discuss these things on weekends: Should Linus revert the culprit for -rc5 if no fix is found within the next 48 hours? Ciao, Thorsten
