On Sun, Oct 23, 2022 at 10:53 PM Peter Xu <peterx@xxxxxxxxxx> wrote: > On Fri, Oct 21, 2022 at 07:06:03PM +0300, Anatoly Pugachev wrote: > > > > Link: https://lkml.kernel.org/r/20220811161331.37055-5-peterx@xxxxxxxxxx > > > > So, v6.0-rc3-176-g0d206b5d2e0d) does not segfault dpkg, > > v6.0-rc3-177-g0ccf7f168e17 segfaults it on package install. > > > > dpkg test was (apt) install/remove some packages, segfaults only on install > > (not remove). > > > > Reverted 0ccf7f168e17bb7eb5a322397ba5a841f4fbaccb from top of v6.1-rc1 and > > tried to compile kernel, but got error > > > > mm/huge_memory.c: In function ‘__split_huge_pmd_locked’: > > mm/huge_memory.c:2129:17: error: ‘dirty’ undeclared (first use in this function) > > 2129 | dirty = is_migration_entry_dirty(entry); > > | ^~~~~ > > mm/huge_memory.c:2129:17: note: each undeclared identifier is reported only once for each function it appears in > > make[2]: *** [scripts/Makefile.build:250: mm/huge_memory.o] Error 1 > > > > So can't test v6.1-rc1 with patch reverted... > > Sorry to know this, and thanks for the report and debugging. The revert > won't work because dirty variable is used in later patch for the swap path > too. I've attached a partial (and minimum) revert, feel free to try. Peter, tested again with 6.1.0-rc2 already, non patched kernel segfaulting dpkg, using your patch makes dpkg (or kernel) to behave properly. Thanks! > I had a feeling that it's somehow related to the special impl of sparc64 > pte_mkdirty() where a kernel patching mechanism is used to share code > between sun4[uv]. I'd assume your machine is sun4v? As that's the one > that needs the patching, iiuc. kernel boot log reports ARCH: SUN4V
