* Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
@ 2023-05-10 17:56 Christoph Biedl
2023-05-10 20:29 ` Helge Deller
0 siblings, 1 reply; 11+ messages in thread
From: Christoph Biedl @ 2023-05-10 17:56 UTC (permalink / raw)
To: linux-parisc
[-- Attachment #1: Type: text/plain, Size: 8307 bytes --]
Greetings,
after upgrading from 6.2 to 6.3, my old HPPA box becomes inresponsive
after 10-30 minutes, possibly with some memory pressure involved
(building some Debian packages), kernel messages below. This is 100%
reproducible, switching back to some 6.2 kernel is a workaround.
Userland is Debian unstable, the affected process (as far as I could
see) is either ntpd or ntpq. A reboot is needed to resolve the
situation.
As this still happens with 6.3.2-rc1 which includes "parisc: Ensure page
alignment in flush functions": Has this been spotted earlier, is there
some tentative fix somewhere?
So far, I haven't tried bisecting between 6.2 and 6.3 yet. While I'm
able to do this, it would take days since I don't have a quick
reproducer, and I don't want to do this work in vain. If you can
provide hints how to speed up this, let me know.
Regards,
Christoph
[ 828.356408] kernel BUG at include/linux/swapops.h:472!
[ 828.361679] CPU: 0 PID: 7119 Comm: ntpq Not tainted 6.3.1 #1
[ 828.367392] Hardware name: 9000/785/C3600
[ 828.371440]
[ 828.372962] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[ 828.377695] PSW: 00000000000001001111011100001111 Not tainted
[ 828.383483] r00-03 0004f70f 11294f90 105c6408 31578540
[ 828.388744] r04-07 00000c73 114157c0 00000000 f66326c7
[ 828.394004] r08-11 4f855a58 31455c60 31455c60 00004000
[ 828.399257] r12-15 00000873 00000006 4f855530 4f855530
[ 828.404528] r16-19 00000002 00000100 31455c60 00000000
[ 828.409789] r20-23 70000000 0000001b 0098b000 4f855a58
[ 828.415060] r24-27 2970de30 315aa8c8 00000000 10e72f90
[ 828.420325] r28-31 00000000 129ecf94 315785c0 129ecf00
[ 828.425578] sr00-03 00000029 00000000 00000000 00000029
[ 828.430925] sr04-07 00000000 00000000 00000000 00000000
[ 828.436265]
[ 828.437780] IASQ: 00000000 00000000 IAOQ: 10559284 10559288
[ 828.443389] IIR: 03ffe01f ISR: 10240085 IOR: 5e178584
[ 828.448900] CPU: 0 CR30: 4f855530 CR31: 11111111
[ 828.454422] ORIG_R28: 00000006
[ 828.457594] IAOQ[0]: migration_entry_wait_on_locked+0x254/0x274
[ 828.463663] IAOQ[1]: migration_entry_wait_on_locked+0x258/0x274
[ 828.469701] RP(r2): __migration_entry_wait+0x64/0x6c
[ 828.474807] Backtrace:
[ 828.477195] [<105c6408>] __migration_entry_wait+0x64/0x6c
[ 828.482732] [<105c6444>] migration_entry_wait+0x34/0x44
[ 828.488085] [<1058c608>] do_swap_page+0x710/0x894
[ 828.492926] [<1058d07c>] handle_mm_fault+0x4e4/0xcb4
[ 828.498009] [<10406490>] do_page_fault+0xd0/0x42c
[ 828.502852] [<10408d60>] handle_interruption+0x4cc/0x6c8
[ 828.508303] [<10403070>] intr_check_sig+0x0/0x38
[ 828.513051]
[ 828.514568] CPU: 0 PID: 7119 Comm: ntpq Not tainted 6.3.1 #1
[ 828.520245] Hardware name: 9000/785/C3600
[ 828.524269] Backtrace:
[ 828.526651] [<104084e0>] show_stack+0x34/0x48
[ 828.531124] [<10cdb894>] dump_stack_lvl+0x38/0x54
[ 828.535953] [<10cdb8cc>] dump_stack+0x1c/0x2c
[ 828.540424] [<104085fc>] die_if_kernel+0xec/0x1b0
[ 828.545241] [<10408eac>] handle_interruption+0x618/0x6c8
[ 828.550668] [<10403070>] intr_check_sig+0x0/0x38
[ 828.555399]
[ 828.556936] ---[ end trace 0000000000000000 ]---
[ 828.562457] ------------[ cut here ]------------
[ 828.567151] kernel BUG at include/linux/swapops.h:472!
[ 828.572394] CPU: 0 PID: 3059 Comm: in:imklog Tainted: G D 6.3.1 #1
[ 828.579997] Hardware name: 9000/785/C3600
[ 828.584045]
[ 828.585567] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[ 828.590306] PSW: 00000000000001001111011100001111 Tainted: G D
[ 828.597546] r00-03 0004f70f 11294f90 105c6408 13030540
[ 828.602837] r04-07 00000c73 114157c0 00000000 f5a32bef
[ 828.608094] r08-11 13035a58 137df5e8 137df5e8 00004000
[ 828.613363] r12-15 00000873 00000006 13035530 13035530
[ 828.618623] r16-19 00000002 00000100 137df5e8 00000000
[ 828.623885] r20-23 70000000 0000001b 0000000e 13035a58
[ 828.629144] r24-27 1472c1f0 4fbdf8c8 00000000 10e72f90
[ 828.634412] r28-31 00000000 1373b094 130305c0 1373b000
[ 828.639667] sr00-03 00000029 00000000 00000000 0000000e
[ 828.645014] sr04-07 00000000 00000000 00000000 00000000
[ 828.650361]
[ 828.651874] IASQ: 00000000 00000000 IAOQ: 10559284 10559288
[ 828.657476] IIR: 03ffe01f ISR: 00000000 IOR: 00000000
[ 828.662997] CPU: 0 CR30: 13035530 CR31: 11111111
[ 828.668510] ORIG_R28: 00000000
[ 828.671688] IAOQ[0]: migration_entry_wait_on_locked+0x254/0x274
[ 828.677739] IAOQ[1]: migration_entry_wait_on_locked+0x258/0x274
[ 828.683788] RP(r2): __migration_entry_wait+0x64/0x6c
[ 828.688888] Backtrace:
[ 828.691289] [<105c6408>] __migration_entry_wait+0x64/0x6c
[ 828.696809] [<105c6444>] migration_entry_wait+0x34/0x44
[ 828.702162] [<1058c608>] do_swap_page+0x710/0x894
[ 828.706993] [<1058d07c>] handle_mm_fault+0x4e4/0xcb4
[ 828.712087] [<10406490>] do_page_fault+0xd0/0x42c
[ 828.716924] [<10408d60>] handle_interruption+0x4cc/0x6c8
[ 828.722375] [<10403070>] intr_check_sig+0x0/0x38
[ 828.727116]
[ 828.728639] CPU: 0 PID: 3059 Comm: in:imklog Tainted: G D 6.3.1 #1
[ 828.736223] Hardware name: 9000/785/C3600
[ 828.740252] Backtrace:
[ 828.742627] [<104084e0>] show_stack+0x34/0x48
[ 828.747099] [<10cdb894>] dump_stack_lvl+0x38/0x54
[ 828.751928] [<10cdb8cc>] dump_stack+0x1c/0x2c
[ 828.756399] [<104085fc>] die_if_kernel+0xec/0x1b0
[ 828.761218] [<10408eac>] handle_interruption+0x618/0x6c8
[ 828.766643] [<10403070>] intr_check_sig+0x0/0x38
[ 828.771376]
[ 828.772915] ---[ end trace 0000000000000000 ]---
[ 828.810379] ------------[ cut here ]------------
[ 828.815050] kernel BUG at include/linux/swapops.h:472!
[ 828.820241] CPU: 0 PID: 261 Comm: systemd-journal Tainted: G D 6.3.1 #1
[ 828.828273] Hardware name: 9000/785/C3600
[ 828.832339]
[ 828.833861] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[ 828.838585] PSW: 00000000000001001111111100001111 Tainted: G D
[ 828.845841] r00-03 0004ff0f 11294f90 105c6408 4f830540
[ 828.851108] r04-07 00000c73 11415fe8 00000002 f69b63af
[ 828.856362] r08-11 4f857698 12951168 12951168 00004000
[ 828.861630] r12-15 00000873 00000006 4f857170 4f857170
[ 828.866884] r16-19 00000002 00000100 12951168 00000000
[ 828.872151] r20-23 70000000 0000001b 0000000e 4f857698
[ 828.877406] r24-27 129621f0 130726d8 00000000 10e72f90
[ 828.882674] r28-31 00000000 4f8c7898 4f8305c0 4f8c7800
[ 828.887925] sr00-03 00000029 00000000 00000000 00000004
[ 828.893274] sr04-07 00000000 00000000 00000000 00000000
[ 828.898612]
[ 828.900137] IASQ: 00000000 00000000 IAOQ: 10559284 10559288
[ 828.905736] IIR: 03ffe01f ISR: 102400fe IOR: 0c030584
[ 828.911258] CPU: 0 CR30: 4f857170 CR31: 11111111
[ 828.916768] ORIG_R28: 00000006
[ 828.919940] IAOQ[0]: migration_entry_wait_on_locked+0x254/0x274
[ 828.925999] IAOQ[1]: migration_entry_wait_on_locked+0x258/0x274
[ 828.932047] RP(r2): __migration_entry_wait+0x64/0x6c
[ 828.937136] Backtrace:
[ 828.939530] [<105c6408>] __migration_entry_wait+0x64/0x6c
[ 828.945059] [<105c6444>] migration_entry_wait+0x34/0x44
[ 828.950414] [<1058c608>] do_swap_page+0x710/0x894
[ 828.955242] [<1058d07c>] handle_mm_fault+0x4e4/0xcb4
[ 828.960336] [<10406490>] do_page_fault+0xd0/0x42c
[ 828.965167] [<10408d60>] handle_interruption+0x4cc/0x6c8
[ 828.970618] [<10403070>] intr_check_sig+0x0/0x38
[ 828.975358]
[ 828.976880] CPU: 0 PID: 261 Comm: systemd-journal Tainted: G D 6.3.1 #1
[ 828.984897] Hardware name: 9000/785/C3600
[ 828.988929] Backtrace:
[ 828.991311] [<104084e0>] show_stack+0x34/0x48
[ 828.995783] [<10cdb894>] dump_stack_lvl+0x38/0x54
[ 829.000613] [<10cdb8cc>] dump_stack+0x1c/0x2c
[ 829.005084] [<104085fc>] die_if_kernel+0xec/0x1b0
[ 829.009901] [<10408eac>] handle_interruption+0x618/0x6c8
[ 829.015328] [<10403070>] intr_check_sig+0x0/0x38
[ 829.020059]
[ 829.021590] ---[ end trace 0000000000000000 ]---
[ 829.304173] ------------[ cut here ]------------
[ 829.308873] kernel BUG at include/linux/swapops.h:472!
[ 829.314076] die_if_kernel() recursion detected.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
2023-05-10 17:56 Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!" Christoph Biedl
@ 2023-05-10 20:29 ` Helge Deller
2023-05-11 17:22 ` Christoph Biedl
0 siblings, 1 reply; 11+ messages in thread
From: Helge Deller @ 2023-05-10 20:29 UTC (permalink / raw)
To: Christoph Biedl, linux-parisc
Hi Christoph,
On 5/10/23 19:56, Christoph Biedl wrote:
> after upgrading from 6.2 to 6.3, my old HPPA box becomes inresponsive
> after 10-30 minutes, possibly with some memory pressure involved
> (building some Debian packages), kernel messages below. This is 100%
> reproducible, switching back to some 6.2 kernel is a workaround.
>
> Userland is Debian unstable, the affected process (as far as I could
> see) is either ntpd or ntpq. A reboot is needed to resolve the
> situation.
>
> As this still happens with 6.3.2-rc1 which includes "parisc: Ensure page
> alignment in flush functions": Has this been spotted earlier, is there
> some tentative fix somewhere?
>
> So far, I haven't tried bisecting between 6.2 and 6.3 yet. While I'm
> able to do this, it would take days since I don't have a quick
> reproducer, and I don't want to do this work in vain. If you can
> provide hints how to speed up this, let me know.
I haven't used kernel 6.3 much yet, but the kernel BUG below seems
to be triggered by CONFIG_MIGRATION.
You could try to disable that config option first to verify if
it fixes your crash.
This might help to narrow down the problem....
Helge
> [ 828.356408] kernel BUG at include/linux/swapops.h:472!
> [ 828.361679] CPU: 0 PID: 7119 Comm: ntpq Not tainted 6.3.1 #1
> [ 828.367392] Hardware name: 9000/785/C3600
> [ 828.371440]
> [ 828.372962] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> [ 828.377695] PSW: 00000000000001001111011100001111 Not tainted
> [ 828.383483] r00-03 0004f70f 11294f90 105c6408 31578540
> [ 828.388744] r04-07 00000c73 114157c0 00000000 f66326c7
> [ 828.394004] r08-11 4f855a58 31455c60 31455c60 00004000
> [ 828.399257] r12-15 00000873 00000006 4f855530 4f855530
> [ 828.404528] r16-19 00000002 00000100 31455c60 00000000
> [ 828.409789] r20-23 70000000 0000001b 0098b000 4f855a58
> [ 828.415060] r24-27 2970de30 315aa8c8 00000000 10e72f90
> [ 828.420325] r28-31 00000000 129ecf94 315785c0 129ecf00
> [ 828.425578] sr00-03 00000029 00000000 00000000 00000029
> [ 828.430925] sr04-07 00000000 00000000 00000000 00000000
> [ 828.436265]
> [ 828.437780] IASQ: 00000000 00000000 IAOQ: 10559284 10559288
> [ 828.443389] IIR: 03ffe01f ISR: 10240085 IOR: 5e178584
> [ 828.448900] CPU: 0 CR30: 4f855530 CR31: 11111111
> [ 828.454422] ORIG_R28: 00000006
> [ 828.457594] IAOQ[0]: migration_entry_wait_on_locked+0x254/0x274
> [ 828.463663] IAOQ[1]: migration_entry_wait_on_locked+0x258/0x274
> [ 828.469701] RP(r2): __migration_entry_wait+0x64/0x6c
> [ 828.474807] Backtrace:
> [ 828.477195] [<105c6408>] __migration_entry_wait+0x64/0x6c
> [ 828.482732] [<105c6444>] migration_entry_wait+0x34/0x44
> [ 828.488085] [<1058c608>] do_swap_page+0x710/0x894
> [ 828.492926] [<1058d07c>] handle_mm_fault+0x4e4/0xcb4
> [ 828.498009] [<10406490>] do_page_fault+0xd0/0x42c
> [ 828.502852] [<10408d60>] handle_interruption+0x4cc/0x6c8
> [ 828.508303] [<10403070>] intr_check_sig+0x0/0x38
> [ 828.513051]
> [ 828.514568] CPU: 0 PID: 7119 Comm: ntpq Not tainted 6.3.1 #1
> [ 828.520245] Hardware name: 9000/785/C3600
> [ 828.524269] Backtrace:
> [ 828.526651] [<104084e0>] show_stack+0x34/0x48
> [ 828.531124] [<10cdb894>] dump_stack_lvl+0x38/0x54
> [ 828.535953] [<10cdb8cc>] dump_stack+0x1c/0x2c
> [ 828.540424] [<104085fc>] die_if_kernel+0xec/0x1b0
> [ 828.545241] [<10408eac>] handle_interruption+0x618/0x6c8
> [ 828.550668] [<10403070>] intr_check_sig+0x0/0x38
> [ 828.555399]
> [ 828.556936] ---[ end trace 0000000000000000 ]---
> [ 828.562457] ------------[ cut here ]------------
> [ 828.567151] kernel BUG at include/linux/swapops.h:472!
> [ 828.572394] CPU: 0 PID: 3059 Comm: in:imklog Tainted: G D 6.3.1 #1
> [ 828.579997] Hardware name: 9000/785/C3600
> [ 828.584045]
> [ 828.585567] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> [ 828.590306] PSW: 00000000000001001111011100001111 Tainted: G D
> [ 828.597546] r00-03 0004f70f 11294f90 105c6408 13030540
> [ 828.602837] r04-07 00000c73 114157c0 00000000 f5a32bef
> [ 828.608094] r08-11 13035a58 137df5e8 137df5e8 00004000
> [ 828.613363] r12-15 00000873 00000006 13035530 13035530
> [ 828.618623] r16-19 00000002 00000100 137df5e8 00000000
> [ 828.623885] r20-23 70000000 0000001b 0000000e 13035a58
> [ 828.629144] r24-27 1472c1f0 4fbdf8c8 00000000 10e72f90
> [ 828.634412] r28-31 00000000 1373b094 130305c0 1373b000
> [ 828.639667] sr00-03 00000029 00000000 00000000 0000000e
> [ 828.645014] sr04-07 00000000 00000000 00000000 00000000
> [ 828.650361]
> [ 828.651874] IASQ: 00000000 00000000 IAOQ: 10559284 10559288
> [ 828.657476] IIR: 03ffe01f ISR: 00000000 IOR: 00000000
> [ 828.662997] CPU: 0 CR30: 13035530 CR31: 11111111
> [ 828.668510] ORIG_R28: 00000000
> [ 828.671688] IAOQ[0]: migration_entry_wait_on_locked+0x254/0x274
> [ 828.677739] IAOQ[1]: migration_entry_wait_on_locked+0x258/0x274
> [ 828.683788] RP(r2): __migration_entry_wait+0x64/0x6c
> [ 828.688888] Backtrace:
> [ 828.691289] [<105c6408>] __migration_entry_wait+0x64/0x6c
> [ 828.696809] [<105c6444>] migration_entry_wait+0x34/0x44
> [ 828.702162] [<1058c608>] do_swap_page+0x710/0x894
> [ 828.706993] [<1058d07c>] handle_mm_fault+0x4e4/0xcb4
> [ 828.712087] [<10406490>] do_page_fault+0xd0/0x42c
> [ 828.716924] [<10408d60>] handle_interruption+0x4cc/0x6c8
> [ 828.722375] [<10403070>] intr_check_sig+0x0/0x38
> [ 828.727116]
> [ 828.728639] CPU: 0 PID: 3059 Comm: in:imklog Tainted: G D 6.3.1 #1
> [ 828.736223] Hardware name: 9000/785/C3600
> [ 828.740252] Backtrace:
> [ 828.742627] [<104084e0>] show_stack+0x34/0x48
> [ 828.747099] [<10cdb894>] dump_stack_lvl+0x38/0x54
> [ 828.751928] [<10cdb8cc>] dump_stack+0x1c/0x2c
> [ 828.756399] [<104085fc>] die_if_kernel+0xec/0x1b0
> [ 828.761218] [<10408eac>] handle_interruption+0x618/0x6c8
> [ 828.766643] [<10403070>] intr_check_sig+0x0/0x38
> [ 828.771376]
> [ 828.772915] ---[ end trace 0000000000000000 ]---
> [ 828.810379] ------------[ cut here ]------------
> [ 828.815050] kernel BUG at include/linux/swapops.h:472!
> [ 828.820241] CPU: 0 PID: 261 Comm: systemd-journal Tainted: G D 6.3.1 #1
> [ 828.828273] Hardware name: 9000/785/C3600
> [ 828.832339]
> [ 828.833861] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> [ 828.838585] PSW: 00000000000001001111111100001111 Tainted: G D
> [ 828.845841] r00-03 0004ff0f 11294f90 105c6408 4f830540
> [ 828.851108] r04-07 00000c73 11415fe8 00000002 f69b63af
> [ 828.856362] r08-11 4f857698 12951168 12951168 00004000
> [ 828.861630] r12-15 00000873 00000006 4f857170 4f857170
> [ 828.866884] r16-19 00000002 00000100 12951168 00000000
> [ 828.872151] r20-23 70000000 0000001b 0000000e 4f857698
> [ 828.877406] r24-27 129621f0 130726d8 00000000 10e72f90
> [ 828.882674] r28-31 00000000 4f8c7898 4f8305c0 4f8c7800
> [ 828.887925] sr00-03 00000029 00000000 00000000 00000004
> [ 828.893274] sr04-07 00000000 00000000 00000000 00000000
> [ 828.898612]
> [ 828.900137] IASQ: 00000000 00000000 IAOQ: 10559284 10559288
> [ 828.905736] IIR: 03ffe01f ISR: 102400fe IOR: 0c030584
> [ 828.911258] CPU: 0 CR30: 4f857170 CR31: 11111111
> [ 828.916768] ORIG_R28: 00000006
> [ 828.919940] IAOQ[0]: migration_entry_wait_on_locked+0x254/0x274
> [ 828.925999] IAOQ[1]: migration_entry_wait_on_locked+0x258/0x274
> [ 828.932047] RP(r2): __migration_entry_wait+0x64/0x6c
> [ 828.937136] Backtrace:
> [ 828.939530] [<105c6408>] __migration_entry_wait+0x64/0x6c
> [ 828.945059] [<105c6444>] migration_entry_wait+0x34/0x44
> [ 828.950414] [<1058c608>] do_swap_page+0x710/0x894
> [ 828.955242] [<1058d07c>] handle_mm_fault+0x4e4/0xcb4
> [ 828.960336] [<10406490>] do_page_fault+0xd0/0x42c
> [ 828.965167] [<10408d60>] handle_interruption+0x4cc/0x6c8
> [ 828.970618] [<10403070>] intr_check_sig+0x0/0x38
> [ 828.975358]
> [ 828.976880] CPU: 0 PID: 261 Comm: systemd-journal Tainted: G D 6.3.1 #1
> [ 828.984897] Hardware name: 9000/785/C3600
> [ 828.988929] Backtrace:
> [ 828.991311] [<104084e0>] show_stack+0x34/0x48
> [ 828.995783] [<10cdb894>] dump_stack_lvl+0x38/0x54
> [ 829.000613] [<10cdb8cc>] dump_stack+0x1c/0x2c
> [ 829.005084] [<104085fc>] die_if_kernel+0xec/0x1b0
> [ 829.009901] [<10408eac>] handle_interruption+0x618/0x6c8
> [ 829.015328] [<10403070>] intr_check_sig+0x0/0x38
> [ 829.020059]
> [ 829.021590] ---[ end trace 0000000000000000 ]---
> [ 829.304173] ------------[ cut here ]------------
> [ 829.308873] kernel BUG at include/linux/swapops.h:472!
> [ 829.314076] die_if_kernel() recursion detected.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
2023-05-10 20:29 ` Helge Deller
@ 2023-05-11 17:22 ` Christoph Biedl
2023-05-11 17:35 ` Helge Deller
0 siblings, 1 reply; 11+ messages in thread
From: Christoph Biedl @ 2023-05-11 17:22 UTC (permalink / raw)
To: linux-parisc
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
Helge Deller wrote...
> I haven't used kernel 6.3 much yet, but the kernel BUG below seems
> to be triggered by CONFIG_MIGRATION.
> You could try to disable that config option first to verify if
> it fixes your crash.
> This might help to narrow down the problem....
Looks good, still have a running system after 45 minutes, never got that
far with the initial kernel configuration.
In the meantime I realized only some 16 commits between v6.2 and v6.3
affect arch/parisc. Do you think it's worth check right around those?
Also, if you can think of a way to trigger the crashes, that would ease
the testing a lot.
Regards,
Christoph
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
2023-05-11 17:22 ` Christoph Biedl
@ 2023-05-11 17:35 ` Helge Deller
2023-05-12 21:56 ` Christoph Biedl
0 siblings, 1 reply; 11+ messages in thread
From: Helge Deller @ 2023-05-11 17:35 UTC (permalink / raw)
To: Christoph Biedl, linux-parisc
On 5/11/23 19:22, Christoph Biedl wrote:
> Helge Deller wrote...
>
>> I haven't used kernel 6.3 much yet, but the kernel BUG below seems
>> to be triggered by CONFIG_MIGRATION.
>> You could try to disable that config option first to verify if
>> it fixes your crash.
>> This might help to narrow down the problem....
>
> Looks good, still have a running system after 45 minutes, never got that
> far with the initial kernel configuration.
Good!
> In the meantime I realized only some 16 commits between v6.2 and v6.3
> affect arch/parisc. Do you think it's worth check right around those?
Don't think so.
Very unlikely is this one:
commit 88d7b12068b95731c280af8ce88e8ee9561f96de
highmem: round down the address passed to kunmap_flush_on_unmap()
> Also, if you can think of a way to trigger the crashes, that would ease
> the testing a lot.
Since you run the 32-bit kernel, huge-pages are not involved as they
aren't available in the 32-bit kernels.
So I think swapping is triggering it.
You could try to find a test program which triggers swapping, e.g. LTS testcases?
Another test could be to enable CONFIG_MIGRATION again and disable
all swap spaces and see if it survives.
Helge
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
2023-05-11 17:35 ` Helge Deller
@ 2023-05-12 21:56 ` Christoph Biedl
2023-05-13 12:10 ` Helge Deller
0 siblings, 1 reply; 11+ messages in thread
From: Christoph Biedl @ 2023-05-12 21:56 UTC (permalink / raw)
To: linux-parisc
[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]
Helge Deller wrote...
> Since you run the 32-bit kernel, huge-pages are not involved as they
> aren't available in the 32-bit kernels.
> So I think swapping is triggering it.
> You could try to find a test program which triggers swapping, e.g. LTS testcases?
> Another test could be to enable CONFIG_MIGRATION again and disable
> all swap spaces and see if it survives.
Well, turns out I'm not using swap at all. But the "memory under
pressure" seemed right, and I could easily trigger the crash by
allowcating almost the entire available memory[1].
Then bisecting led to
commit 6d239fc78c0b0c687e5408573350714e6e789d71
Author: David Hildenbrand <david@redhat.com>
Date: Fri Jan 13 18:10:16 2023 +0100
parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using the yet-unused
_PAGE_ACCESSED location in the swap PTE. Looking at pte_present() and
pte_none() checks, there seems to be no actual reason why we cannot use
it: we only have to make sure we're not using _PAGE_PRESENT.
Reusing this bit avoids having to steal one bit from the swap offset.
Link: https://lkml.kernel.org/r/20230113171026.582290-17-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: Helge Deller <deller@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Does this make sense?
Christoph
[1] Total is 1 Gbyte, and running
| dd if=/dev/zero bs=896M count=1 | pv --rate-limit=1k >/dev/null
might not be the best style but does the trick: Wait for pv to
count up to a minute, then ^C it. If the host is still okay after
that, it's considered "good".
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
2023-05-12 21:56 ` Christoph Biedl
@ 2023-05-13 12:10 ` Helge Deller
2023-05-13 13:21 ` David Hildenbrand
2023-05-13 16:24 ` Christoph Biedl
0 siblings, 2 replies; 11+ messages in thread
From: Helge Deller @ 2023-05-13 12:10 UTC (permalink / raw)
To: Christoph Biedl; +Cc: linux-parisc, David Hildenbrand
* Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>:
> Helge Deller wrote...
>
> > Since you run the 32-bit kernel, huge-pages are not involved as they
> > aren't available in the 32-bit kernels.
> > So I think swapping is triggering it.
> > You could try to find a test program which triggers swapping, e.g. LTS testcases?
> > Another test could be to enable CONFIG_MIGRATION again and disable
> > all swap spaces and see if it survives.
>
> Well, turns out I'm not using swap at all. But the "memory under
> pressure" seemed right, and I could easily trigger the crash by
> allowcating almost the entire available memory[1].
>
> Then bisecting led to
>
> commit 6d239fc78c0b0c687e5408573350714e6e789d71
> Author: David Hildenbrand <david@redhat.com>
> Date: Fri Jan 13 18:10:16 2023 +0100
>
> parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE
>
> Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using the yet-unused
> _PAGE_ACCESSED location in the swap PTE. Looking at pte_present() and
> pte_none() checks, there seems to be no actual reason why we cannot use
> it: we only have to make sure we're not using _PAGE_PRESENT.
>
> Reusing this bit avoids having to steal one bit from the swap offset.
>
> Link: https://lkml.kernel.org/r/20230113171026.582290-17-david@redhat.com
> Signed-off-by: David Hildenbrand <david@redhat.com>
> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
> Cc: Helge Deller <deller@gmx.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> Does this make sense?
Yes, makes sense.
> [1] Total is 1 Gbyte, and running
> | dd if=/dev/zero bs=896M count=1 | pv --rate-limit=1k >/dev/null
> might not be the best style but does the trick: Wait for pv to
> count up to a minute, then ^C it. If the host is still okay after
> that, it's considered "good".
Thanks for bisecting and coming up with a testcase!
The attached patch survives for me on my C3000 with 2GB RAM with this test:
dd if=/dev/zero bs=1896M count=1 | pv
(well, the OOM-killer might jump in, but even that is survived).
Could you try the patch below?
Helge
-
[PATCH] parisc: Fix encoding of swp_entry due to added SWP_EXCLUSIVE flag
Fix the __swp_offset() and __swp_entry() macros due to commit 6d239fc78c0b
("parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE") which introduced the
SWP_EXCLUSIVE flag by reusing the _PAGE_ACCESSED flag.
Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Fixes: 6d239fc78c0b ("parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE")
diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h
index e2950f5db7c9..522846be54b7 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -413,12 +413,12 @@ extern void paging_init (void);
* For the 64bit version, the offset is extended by 32bit.
*/
#define __swp_type(x) ((x).val & 0x1f)
-#define __swp_offset(x) ( (((x).val >> 6) & 0x7) | \
- (((x).val >> 8) & ~0x7) )
+#define __swp_offset(x) ( (((x).val >> 5) & 0x7) | \
+ (((x).val >> 10) << 3) )
#define __swp_entry(type, offset) ((swp_entry_t) { \
((type) & 0x1f) | \
- ((offset & 0x7) << 6) | \
- ((offset & ~0x7) << 8) })
+ ((offset & 0x7) << 5) | \
+ ((offset & ~0x7) << 7) })
#define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) })
#define __swp_entry_to_pte(x) ((pte_t) { (x).val })
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
2023-05-13 12:10 ` Helge Deller
@ 2023-05-13 13:21 ` David Hildenbrand
2023-05-13 13:58 ` Helge Deller
2023-05-13 16:24 ` Christoph Biedl
1 sibling, 1 reply; 11+ messages in thread
From: David Hildenbrand @ 2023-05-13 13:21 UTC (permalink / raw)
To: Helge Deller, Christoph Biedl; +Cc: linux-parisc
> Yes, makes sense.
>
>> [1] Total is 1 Gbyte, and running
>> | dd if=/dev/zero bs=896M count=1 | pv --rate-limit=1k >/dev/null
>> might not be the best style but does the trick: Wait for pv to
>> count up to a minute, then ^C it. If the host is still okay after
>> that, it's considered "good".
>
> Thanks for bisecting and coming up with a testcase!
> The attached patch survives for me on my C3000 with 2GB RAM with this test:
> dd if=/dev/zero bs=1896M count=1 | pv
> (well, the OOM-killer might jump in, but even that is survived).
>
> Could you try the patch below?
Thanks for debugging! :)
>
> Helge
>
> -
>
> [PATCH] parisc: Fix encoding of swp_entry due to added SWP_EXCLUSIVE flag
>
> Fix the __swp_offset() and __swp_entry() macros due to commit 6d239fc78c0b
> ("parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE") which introduced the
> SWP_EXCLUSIVE flag by reusing the _PAGE_ACCESSED flag.
>
> Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
> Fixes: 6d239fc78c0b ("parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE")
>
> diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h
> index e2950f5db7c9..522846be54b7 100644
> --- a/arch/parisc/include/asm/pgtable.h
> +++ b/arch/parisc/include/asm/pgtable.h
> @@ -413,12 +413,12 @@ extern void paging_init (void);
> * For the 64bit version, the offset is extended by 32bit.
> */
> #define __swp_type(x) ((x).val & 0x1f)
> -#define __swp_offset(x) ( (((x).val >> 6) & 0x7) | \
> - (((x).val >> 8) & ~0x7) )
> +#define __swp_offset(x) ( (((x).val >> 5) & 0x7) | \
> + (((x).val >> 10) << 3) )
> #define __swp_entry(type, offset) ((swp_entry_t) { \
> ((type) & 0x1f) | \
> - ((offset & 0x7) << 6) | \
> - ((offset & ~0x7) << 8) })
> + ((offset & 0x7) << 5) | \
> + ((offset & ~0x7) << 7) })
> #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) })
> #define __swp_entry_to_pte(x) ((pte_t) { (x).val })
This fix makes it work like the layout I documented.
What I originally tried doing was reusing one of the spare bits instead of reworking
the layout. Apparently, I got the old layout wrong. :(
So if I understood the layout right this time, maybe we can just use one of the two
spare bits: _PAGE_HUGE (or alternatively, _PAGE_DIRTY_BIT)?
diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h
index e2950f5db7c9..ee9f08cd5938 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -218,8 +218,8 @@ extern void __update_cache(pte_t pte);
#define _PAGE_KERNEL_RWX (_PAGE_KERNEL_EXEC | _PAGE_WRITE)
#define _PAGE_KERNEL (_PAGE_KERNEL_RO | _PAGE_WRITE)
-/* We borrow bit 23 to store the exclusive marker in swap PTEs. */
-#define _PAGE_SWP_EXCLUSIVE _PAGE_ACCESSED
+/* We borrow bit 21 to store the exclusive marker in swap PTEs. */
+#define _PAGE_SWP_EXCLUSIVE _PAGE_HUGE
/* The pgd/pmd contains a ptr (in phys addr space); since all pgds/pmds
* are page-aligned, we don't care about the PAGE_OFFSET bits, except
@@ -405,7 +405,7 @@ extern void paging_init (void);
*
* 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- * <---------------- offset -----------------> P E <ofs> < type ->
+ * <---------------- offset ---------------> E P <ofs> 0 < type ->
*
* E is the exclusive marker that is not stored in swap entries.
* _PAGE_PRESENT (P) must be 0.
diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 110a36479dce..7510db355f48 100644
--
Thanks,
David / dhildenb
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
2023-05-13 13:21 ` David Hildenbrand
@ 2023-05-13 13:58 ` Helge Deller
2023-05-13 23:32 ` David Hildenbrand
0 siblings, 1 reply; 11+ messages in thread
From: Helge Deller @ 2023-05-13 13:58 UTC (permalink / raw)
To: David Hildenbrand, Christoph Biedl; +Cc: linux-parisc
On 5/13/23 15:21, David Hildenbrand wrote:
>> Yes, makes sense.
>>
>>> [1] Total is 1 Gbyte, and running
>>> | dd if=/dev/zero bs=896M count=1 | pv --rate-limit=1k >/dev/null
>>> might not be the best style but does the trick: Wait for pv to
>>> count up to a minute, then ^C it. If the host is still okay after
>>> that, it's considered "good".
>>
>> Thanks for bisecting and coming up with a testcase!
>> The attached patch survives for me on my C3000 with 2GB RAM with this test:
>> dd if=/dev/zero bs=1896M count=1 | pv
>> (well, the OOM-killer might jump in, but even that is survived).
>>
>> Could you try the patch below?
>
> Thanks for debugging! :)
>>
>> [PATCH] parisc: Fix encoding of swp_entry due to added SWP_EXCLUSIVE flag
>>
>> Fix the __swp_offset() and __swp_entry() macros due to commit 6d239fc78c0b
>> ("parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE") which introduced the
>> SWP_EXCLUSIVE flag by reusing the _PAGE_ACCESSED flag.
>>
>> Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
>> Fixes: 6d239fc78c0b ("parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE")
>>
>> diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h
>> index e2950f5db7c9..522846be54b7 100644
>> --- a/arch/parisc/include/asm/pgtable.h
>> +++ b/arch/parisc/include/asm/pgtable.h
>> @@ -413,12 +413,12 @@ extern void paging_init (void);
>> * For the 64bit version, the offset is extended by 32bit.
>> */
>> #define __swp_type(x) ((x).val & 0x1f)
>> -#define __swp_offset(x) ( (((x).val >> 6) & 0x7) | \
>> - (((x).val >> 8) & ~0x7) )
>> +#define __swp_offset(x) ( (((x).val >> 5) & 0x7) | \
>> + (((x).val >> 10) << 3) )
>> #define __swp_entry(type, offset) ((swp_entry_t) { \
>> ((type) & 0x1f) | \
>> - ((offset & 0x7) << 6) | \
>> - ((offset & ~0x7) << 8) })
>> + ((offset & 0x7) << 5) | \
>> + ((offset & ~0x7) << 7) })
>> #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) })
>> #define __swp_entry_to_pte(x) ((pte_t) { (x).val })
>
> This fix makes it work like the layout I documented.
Yes, and your layout looks good for me.
> What I originally tried doing was reusing one of the spare bits instead of reworking
> the layout. Apparently, I got the old layout wrong. :(
Don't worry! Your patch harmonizes parisc to the other platforms, which is good.
> So if I understood the layout right this time, maybe we can just use one of the two
> spare bits: _PAGE_HUGE (or alternatively, _PAGE_DIRTY_BIT)?
Yes, or keep what you suggested.
What I don't understand yet is the original code:
#define __swp_type(x) ((x).val & 0x1f)
#define __swp_offset(x) ( (((x).val >> 6) & 0x7) | \
(((x).val >> 8) & ~0x7) )
#define __swp_entry(type, offset) ((swp_entry_t) { (type) | \
((offset & 0x7) << 6) | \
((offset & ~0x7) << 8) })
Don't we loose one of the offset bits?
Mask 0x7 is 3 bits, but we shift by 6 and 8 (=2 bits difference), so I believe the second shift should be 9.
If it would be 9, then no &0x07 is needed and only one shift would be sufficient.
I don't know much in the swap pte area, but isn't the previous original code wrong?
Which bits of the swp_entry are used where?
Helge
> diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h
> index e2950f5db7c9..ee9f08cd5938 100644
> --- a/arch/parisc/include/asm/pgtable.h
> +++ b/arch/parisc/include/asm/pgtable.h
> @@ -218,8 +218,8 @@ extern void __update_cache(pte_t pte);
> #define _PAGE_KERNEL_RWX (_PAGE_KERNEL_EXEC | _PAGE_WRITE)
> #define _PAGE_KERNEL (_PAGE_KERNEL_RO | _PAGE_WRITE)
>
> -/* We borrow bit 23 to store the exclusive marker in swap PTEs. */
> -#define _PAGE_SWP_EXCLUSIVE _PAGE_ACCESSED
> +/* We borrow bit 21 to store the exclusive marker in swap PTEs. */
> +#define _PAGE_SWP_EXCLUSIVE _PAGE_HUGE
>
> /* The pgd/pmd contains a ptr (in phys addr space); since all pgds/pmds
> * are page-aligned, we don't care about the PAGE_OFFSET bits, except
> @@ -405,7 +405,7 @@ extern void paging_init (void);
> *
> * 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
> * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> - * <---------------- offset -----------------> P E <ofs> < type ->
> + * <---------------- offset ---------------> E P <ofs> 0 < type ->
> *
> * E is the exclusive marker that is not stored in swap entries.
> * _PAGE_PRESENT (P) must be 0.
> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> index 110a36479dce..7510db355f48 100644
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
2023-05-13 12:10 ` Helge Deller
2023-05-13 13:21 ` David Hildenbrand
@ 2023-05-13 16:24 ` Christoph Biedl
1 sibling, 0 replies; 11+ messages in thread
From: Christoph Biedl @ 2023-05-13 16:24 UTC (permalink / raw)
To: Helge Deller; +Cc: linux-parisc, David Hildenbrand
[-- Attachment #1: Type: text/plain, Size: 230 bytes --]
Helge Deller wrote...
> Thanks for bisecting and coming up with a testcase!
Well, thanks for all the advice, and the switft responses as well.
> Could you try the patch below?
Can confirm: Works very well here.
Christoph
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
2023-05-13 13:58 ` Helge Deller
@ 2023-05-13 23:32 ` David Hildenbrand
2023-05-14 0:09 ` Helge Deller
0 siblings, 1 reply; 11+ messages in thread
From: David Hildenbrand @ 2023-05-13 23:32 UTC (permalink / raw)
To: Helge Deller, Christoph Biedl; +Cc: linux-parisc
>>
>> This fix makes it work like the layout I documented.
>
> Yes, and your layout looks good for me.
Good :)
>
>> What I originally tried doing was reusing one of the spare bits instead of reworking
>> the layout. Apparently, I got the old layout wrong. :(
>
> Don't worry! Your patch harmonizes parisc to the other platforms, which is good.
>
>> So if I understood the layout right this time, maybe we can just use one of the two
>> spare bits: _PAGE_HUGE (or alternatively, _PAGE_DIRTY_BIT)?
>
> Yes, or keep what you suggested.
>
> What I don't understand yet is the original code:
> #define __swp_type(x) ((x).val & 0x1f)
> #define __swp_offset(x) ( (((x).val >> 6) & 0x7) | \
> (((x).val >> 8) & ~0x7) )
> #define __swp_entry(type, offset) ((swp_entry_t) { (type) | \
> ((offset & 0x7) << 6) | \
> ((offset & ~0x7) << 8) })
>
> Don't we loose one of the offset bits?
Let's assume we have the offset 0xff. Encoding it with type 0 would be
((0xff & 0x7) << 6) | ((0xff & ~0x7) << 8)
-> (0x7 << 6) | (0xf8 << 8)
-> 0x1c0 | 0xf800
-> 0xf9c0
Extracting the offset:
((0xf9c0 >> 6) & 0x7) | ((0xf9c0 >> 8) & ~0x7)
-> (0x3e7 & 0x7) | (0xf9 & ~0x7)
-> 0x7 | 0xf8
-> 0xff
I think it's correct. The confusing part (that resulted in the BUG here)
is that we end up wasting bit #26, because there is a spare bit between
the type and the offset.
Maybe a relic from the past -- or copy-and-paste, because some archs
supported types with > 5 bits, but core-MM only ever uses 5 bits.
> Mask 0x7 is 3 bits, but we shift by 6 and 8 (=2 bits difference), so I believe the second shift should be 9.
> If it would be 9, then no &0x07 is needed and only one shift would be sufficient.
>
> I don't know much in the swap pte area, but isn't the previous original code wrong?
> Which bits of the swp_entry are used where?
I think the old code was correct. There are apparently two spare bits
that we can use. I just messed up the old layout, thinking there is only
one.
So we can either use the new layout I documented (with the fix you
propose), or use another layout.
In any case, we *gain* one more bit for the offset compared to the old
layout.
I'm more than happy to keep the new layout. Regarding your fix, maybe
avoid the other ~0x7 as well by using similar shifting in __swp_entry()
#define __swp_entry(type, offset) ((swp_entry_t) { \
((type) & 0x1f) | \
((offset & 0x7) << 5) | \
((offset >> 3) << 10) })
So it's easier to match to the logic/values in __swp_offset().
In any case,
Reviewed-by: David Hildenbrand <david@redhat.com>
and thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!"
2023-05-13 23:32 ` David Hildenbrand
@ 2023-05-14 0:09 ` Helge Deller
0 siblings, 0 replies; 11+ messages in thread
From: Helge Deller @ 2023-05-14 0:09 UTC (permalink / raw)
To: David Hildenbrand, Christoph Biedl; +Cc: linux-parisc
On 5/14/23 01:32, David Hildenbrand wrote:
>>>
>>> This fix makes it work like the layout I documented.
>>
>> Yes, and your layout looks good for me.
>
> Good :)
>
>>
>>> What I originally tried doing was reusing one of the spare bits instead of reworking
>>> the layout. Apparently, I got the old layout wrong. :(
>>
>> Don't worry! Your patch harmonizes parisc to the other platforms, which is good.
>>
>>> So if I understood the layout right this time, maybe we can just use one of the two
>>> spare bits: _PAGE_HUGE (or alternatively, _PAGE_DIRTY_BIT)?
>>
>> Yes, or keep what you suggested.
>>
>> What I don't understand yet is the original code:
>> #define __swp_type(x) ((x).val & 0x1f)
>> #define __swp_offset(x) ( (((x).val >> 6) & 0x7) | \
>> (((x).val >> 8) & ~0x7) )
>> #define __swp_entry(type, offset) ((swp_entry_t) { (type) | \
>> ((offset & 0x7) << 6) | \
>> ((offset & ~0x7) << 8) })
>>
>> Don't we loose one of the offset bits?
>
> Let's assume we have the offset 0xff. Encoding it with type 0 would be
>
> ((0xff & 0x7) << 6) | ((0xff & ~0x7) << 8)
> -> (0x7 << 6) | (0xf8 << 8)
> -> 0x1c0 | 0xf800
> -> 0xf9c0
>
> Extracting the offset:
>
> ((0xf9c0 >> 6) & 0x7) | ((0xf9c0 >> 8) & ~0x7)
> -> (0x3e7 & 0x7) | (0xf9 & ~0x7)
> -> 0x7 | 0xf8
> -> 0xff
>
> I think it's correct.
Yes. Seems good.
> The confusing part (that resulted in the BUG here) is that we end up wasting bit #26, because there is a spare bit between the type and the offset.
>
> Maybe a relic from the past -- or copy-and-paste, because some archs supported types with > 5 bits, but core-MM only ever uses 5 bits.
Hard to say. It has been as such since a long time....
>> Mask 0x7 is 3 bits, but we shift by 6 and 8 (=2 bits difference), so I believe the second shift should be 9.
>> If it would be 9, then no &0x07 is needed and only one shift would be sufficient.
>>
>> I don't know much in the swap pte area, but isn't the previous original code wrong?
>> Which bits of the swp_entry are used where?
> I think the old code was correct. There are apparently two spare bits that we can use. I just messed up the old layout, thinking there is only one.
>
> So we can either use the new layout I documented (with the fix you propose), or use another layout.
I think I prefer the layout which you documented.
> In any case, we *gain* one more bit for the offset compared to the old layout.
>
>
> I'm more than happy to keep the new layout. Regarding your fix, maybe avoid the other ~0x7 as well by using similar shifting in __swp_entry()
>
>
> #define __swp_entry(type, offset) ((swp_entry_t) { \
> ((type) & 0x1f) | \
> ((offset & 0x7) << 5) | \
> ((offset >> 3) << 10) })
>
> So it's easier to match to the logic/values in __swp_offset().
Yes, it's much better.
I fixed it up like this in my current git tree.
> In any case,
> Reviewed-by: David Hildenbrand <david@redhat.com>
Great. Thanks for your help & suggestions!
Helge
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2023-05-14 0:09 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-05-10 17:56 Regression with kernel 6.3 "kernel BUG at include/linux/swapops.h:472!" Christoph Biedl
2023-05-10 20:29 ` Helge Deller
2023-05-11 17:22 ` Christoph Biedl
2023-05-11 17:35 ` Helge Deller
2023-05-12 21:56 ` Christoph Biedl
2023-05-13 12:10 ` Helge Deller
2023-05-13 13:21 ` David Hildenbrand
2023-05-13 13:58 ` Helge Deller
2023-05-13 23:32 ` David Hildenbrand
2023-05-14 0:09 ` Helge Deller
2023-05-13 16:24 ` Christoph Biedl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox