Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Date:   Mon, 25 Sep 2023 21:49:30 -0400
From:   "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To:     Erhard Furtner <erhard_f@mailbox.org>
Cc:     linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [Bisected] PowerMac G4 getting "BUG: Unable to handle kernel
 data access on write at 0x00001ff0" at boot with CONFIG_VMAP_STACK=y on
 kernels 6.5.x (regression over 6.4.x)
Message-ID: <20230926014930.yi5v35llxyc5fvwi@revolver>
References: <20230926010159.0f25161c@yea>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230926010159.0f25161c@yea>
User-Agent: NeoMutt/20220429
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?t+qSN4I7Yy2bFISWHEQp3LEzbvoxPRbFyNEnK0aZNPsiF5UO/KFuvimM+PjX?=
 =?us-ascii?Q?AlShR9HeUAdXNiJDSSzCmwuQT690KQArYxjGdou16s47yjUhXuu2vfgLpc3Q?=
 =?us-ascii?Q?pULeKjPYIPgySwOYRYb9yA5W16Rsu01DVthxROr2TnMqWJuPIOUz4rAHGU1l?=
 =?us-ascii?Q?UZbtKHiK23H5idTxHdZIWdEfTbwD29MhWcXGZ4VIAM0ZmiF1wahQthjxhM54?=
 =?us-ascii?Q?sraewd4+RBRoi8aj3lMStLVaHAFG0MahdBt6MsB7PNZbF44IQz8i6zFIcI64?=
 =?us-ascii?Q?YgO0ZgnCPupN7PHkLYBzDHCGvGhdnQKvyJ/BlNWD3mvr0GlX9Q0R5yr0vCau?=
 =?us-ascii?Q?quO9QPOzls31KcNyEQw83ED0X2WgPxLSyrlyYuvdjGclMt7bVUcJl5Sa8Ae3?=
 =?us-ascii?Q?m0wdT3BOr8mWl3dn41fXAVSOqEM9SbP4b8kBeGq2vmiLTnSqImvFxf4jzZ0a?=
 =?us-ascii?Q?V6LmRQi/DrgGsF8nM4do+zK+kmUg+Hi+Q6un0t2/PERvUpV8dgrODvVlCs0B?=
 =?us-ascii?Q?aJDQ1d1IPmDNLP8+D49TKCEfU1vRMJm2VXsdUXLSdLgdxUhd0JUUH+IGYuIB?=
 =?us-ascii?Q?KSg2f9t/tMuXt5Hidefd++fc+eRvmZeRP+Iw04VUF5keeBWEH+DndB5ie7E/?=
 =?us-ascii?Q?QnpLw2a3kpwDag1PCXIWcDJkEAds4JoOq2/8O77BflUNBOu9RBrnfUdFH+0V?=
 =?us-ascii?Q?Az5pKoOk71QaJZMKWo72wCNI24YLU0wwPe7vyt+UUsa0a7QCqt5Z7FNC01ow?=
 =?us-ascii?Q?uWGHdZGNONnjYY398VLnCotgdXGFFyjPiNXW+Y0MfKrJu4T02GGxEnczL7ui?=
 =?us-ascii?Q?yZ9jXR5C3B+4JDPcdOqEv8DNS5BAujpwvx1oB3nBq4DnxxoLHNk6nOz2k5W9?=
 =?us-ascii?Q?JWnMybo/523kTG+/AMENB+vDvLFPU1EhjqjHqZIjw8snXRa29zx2OIKoWf4B?=
 =?us-ascii?Q?af0NQUm7MTIH1gLKzKh+loLbMO0YRatRzazV9er6Fwaq94CG+RQDEcSTM9Vl?=
 =?us-ascii?Q?wPmiKWJ6eTpy/85EKGcu+LMZt5OJA++MebvOrP77AeJ5rkRpaz4LC5+Mn1pv?=
 =?us-ascii?Q?oUumDOiPJy1HTTKSvF+WFb956Qy4b0sJz8gtf7Yb9zU/gPtJM9KrNCzobhfq?=
 =?us-ascii?Q?UT/Fa64jp6Ooo55oOQBOp0znAVGG+bi1akI6t740SmQ2xvJ5a0Y3+Z0rzVrv?=
 =?us-ascii?Q?Y4yK8brsmJK6N/fguNC6mZftQBcjKFMiklmtv0FI1nDVwmblBFXy04ygR2oG?=
 =?us-ascii?Q?GnP97qCku+VX0zFkL8apfvNH7+7TQFhQ296B5cKEp8BPT1d22Qi3C+aEnXJF?=
 =?us-ascii?Q?1FBwD2Ui/FFOsLu2pAp1VmflYnXziy6ARSniTwaR6iVRtyDrmvVU6pvyv5IF?=
 =?us-ascii?Q?YciMMPVLnk4q485iCExVkuT37JDEfPzcvAsQFlOkDTtUK4AuKjtMQfV1744B?=
 =?us-ascii?Q?TRiL9EDkeOKsh6DgDfBGaxy5Z3mPCNAZDz6m6JAJCx6EOeBaW4PdmcirI76C?=
 =?us-ascii?Q?LlRYRF0w/y21AF0dQ4RZ1XpTqttECqlhERY1Y4Bwo4PAAoPJc3kxVwC8Pg3v?=
 =?us-ascii?Q?xNVp9ZPjIt3gt+8gIVmjKwvDocEKDjpxe7pAV5Ak?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 8zZLi0caBR3U12p8m5y3zaPJyyk9zN2shx8PsbQnOSSmYFR5zdnyBKCCyOHNNORW50UHSFmn/sB5LoTIXtL/ZV7Fb6y7DvnXUro/X8da1kpnqLVetj/7fJ+UmXT5Mk0ud3v5n3DDLygxJGu5hleASJZSgtHrEzlo8zk3DaO+CrLXBXy8vJFKG5yhi1lb0z7UKGv5uYrSXo1aJmM6Ser0CXgbHXIlB0hJu7ZV3A5p22eGqxemWGyZ6fb0bTAC7gIp7WHGuRhDeZ0sMd1Kl4JLr7WLlvFHUhDjYxuTkN9dYs6q91AAtkmmW1Z2Vwc1MfkQk2fC+YQTVha9Mh5Fbujg7DHjHaluxc6hNhEh4XpC31qx9sIveIttvhCGW6OosHaLM0Hl2AaqjbU5Am4ysYXYoTuJ/kXpBkczEifgtliuMtGkdqpyazJp00HMwCET6p1q4sFHETxkcmdzIQoXKiaKoy0s56pC3h25nz1AYlI+1MMOX2OMynOjozYTDr+2RcQptcYsmUesf18weAWQhS0N9g7Fa5NLSgLe8b/oHLOoxiFlGtOV3iPqkrTOR0SF24JIHOIlrXACIkAIl7GEDUk4Kv2V6XCT/u2SlrGKE47fsdzunWZq77QyJpWXLVNKhHpWthCcAxXt9HHYwa43PL+B5BdwVejp4k3SJp4XtASs+s2F7A2vrOjHTfne2aoB0XjG1L95J1ZT/BfKQ6baVsop4qerkhQcZbibGgOuS9HOAZCdUiVOBxMpyqRbBCvKblgv8pfembT6g32vo6vy0V0U9JChXW2CYEEJTLu78JsljZ/BErYxhNhuZHfLLTh4AeYstz1PV7oSJTxfyr6wVJhgJg==
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 24070e90-6389-4230-7ce5-08dbbe32d4da
X-MS-Exchange-CrossTenant-AuthSource: SN6PR10MB3022.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2023 01:49:33.3399
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: yBJW5llFI4nB2IvncFfx9cPjOLBk2wYeJc9rNHhAkd3iWueiz1yuoh7DsOX6ei565iIPzGKaquWTYK9vYgfdbQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR10MB6294
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2023-09-26_01,2023-09-25_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 mlxscore=0
 mlxlogscore=906 suspectscore=0 phishscore=0 adultscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000
 definitions=main-2309260014
X-Proofpoint-ORIG-GUID: isaRzw2blWx1G6zcEiRfVZiDZ8QavLpX
X-Proofpoint-GUID: isaRzw2blWx1G6zcEiRfVZiDZ8QavLpX
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Mon, 25 Sep 2023 18:50:13 -0700 (PDT)

* Erhard Furtner <erhard_f@mailbox.org> [230925 19:02]:
> Greetings!
> 
> Had a chat on #gentoo-powerpc with another user whose G4 Mini fails booting kernel 6.5.0 when CONFIG_VMAP_STACK=y is enabled. I was able to replicate the issue on my PowerMac G4. Also I was able to bisect the issue.
> 
> Kernels 6.4.x boot ok with CONFIG_VMAP_STACK=y but on 6.5.5 I get:
> 
> [...]
> Kernel attempted to write user page (1ff0) - exploit attempt? (uid: 0)
> BUG: Unable to handle kernel data access on write at 0x00001ff0
> Faulting instruction address: 0xc0008750
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PAGE_SIZE=4K MMU=Hash PowerMac
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.5-PMacG4 #5
> Hardware name: PowerMac3,6 7455 0x80010303 PowerMac
> NIP:  c0008750 LR: c0041848 CTR: c0070988
> REGS: c0d3dcd0 TRAP: 0300   Not tainted (6.5.5-PMacG4)
> MSR:  00001032 <ME,IR,DR,RI>  CR: 22d3ddc0 XER: 20000000
> DAR: 00001ff0 DSISR: 42000000
> GPR00: c0041848 c0d3dd90 c0d06360 c0d3ddd0 c0d06360 c0d3dea8 c0d3adc0 00000000
> GPR08: 00000000 c0d40000 00000000 c0d3ddc0 00000000 00000000 00000000 00000004
> GPR16: 00000002 00000000 00000002 00402dc2 00402dc2 00002000 f1004000 00000000
> GPR24: c0d45220 c0d06644 c0843c34 00000002 c0d06360 c0d0ce00 c0d06360 00000000
> NIP [c0008750] do_softirq_own_stack+0x18/0x3c
> LR [c0041848] irq_exit+0x98/0xc4
> Call Trace:
> [c0d3dd90] [c0d69564] 0xc0d69564 (unreliable)
> [c0d3ddb0] [c0041848] irq_exit+0x98/0xc4
> [c0d3ddc0] [c0004a98] Decrementer_virt+0x108/0x10c
> --- interrupt: 900 at __schedule+0x43c/0x4e0
> NIP:  c0843940 LR: c084398c CTR: c0070988
> REGS: c0d3ddd0 TRAP: 0900   Not tainted  (6.5.5-PMacG4)
> MSR:  00009032 <EE,ME,IR,DR,RI>  CR: 22024484  XER: 00000000
> 
> GPR00: c0843574 c0d3de90 c0d06360 c0d06360 c0d06360 c0d3dea8 00000001 00000000
> GPR08: 00000000 00009032 c099ce2c 0007ffbf 22024484 00000000 00000000 00000004
> GPR16: 00000002 00000000 00000002 00402dc2 00402dc2 00002000 f1004000 00000000
> GPR24: c0d45220 c0d06644 c0843c34 00000002 c0d06360 c0d0ce00 c0d06360 c0d063ac
> NIP [c0843940] __schedule+0x43c/0x4e0
> LR [c084390c] __schedule+0x408/0x4e0
> --- interrupt: 900
> [c0d3de90] [c0843574] __schedule+0x70/0x4e0 (unreliable)
> [c0d3ded0] [c0843c34] __cond_resched+0x34/0x54
> [c0d3dee0] [c0141068] __vmalloc_node_range+0x27c/0x64c
> [c0d3de60] [c0141794] __vmalloc_node+0x44/0x54
> [c8d3df80] [c0c06510] init_IRQ+0x34/0xd4
> [c8d3dfa0] [c0c03440] start_kernel+0x424/0x558
> [c8d3dff0] [00003540] 0x3540
> Code: 39490999 7d4901a4 39290aaa 7d2a01a4 4c00012c 4bffff20 9421ffe0 7c08002a6 3d20c0d4 93e1001c 90010024 83e95278 <943f1ff0> 7fe1fb78 48840c6d 80210000
> ---[ end trace 0000000000000000 ]---
> 
> Kernel panic - not syncing: Attempted to kill the idle task!
> Rebooting in 48 seconds..

This looks very close to the crash a few weeks ago which bisected to the
same commit [1].

Can you try applying this fix [2] which is on its way upstream?

[1] https://lore.kernel.org/linux-mm/3f86d58e-7f36-c6b4-c43a-2a7bcffd3bd@linux-m68k.org/
[2] https://lore.kernel.org/lkml/20230915174444.2835306-1-Liam.Howlett@oracle.com/

> 
> 
> The bisect revealed this commit:
>  # git bisect good
> cfeb6ae8bcb96ccf674724f223661bbcef7b0d0b is the first bad commit
> commit cfeb6ae8bcb96ccf674724f223661bbcef7b0d0b
> Author: Liam R. Howlett <Liam.Howlett@oracle.com>
> Date:   Fri Aug 18 20:43:55 2023 -0400
> 
>     maple_tree: disable mas_wr_append() when other readers are possible
>     
>     The current implementation of append may cause duplicate data and/or
>     incorrect ranges to be returned to a reader during an update.  Although
>     this has not been reported or seen, disable the append write operation
>     while the tree is in rcu mode out of an abundance of caution.
>     
>     During the analysis of the mas_next_slot() the following was
>     artificially created by separating the writer and reader code:
>     
>     Writer:                                 reader:
>     mas_wr_append
>         set end pivot
>         updates end metata
>         Detects write to last slot
>         last slot write is to start of slot
>         store current contents in slot
>         overwrite old end pivot
>                                             mas_next_slot():
>                                                     read end metadata
>                                                     read old end pivot
>                                                     return with incorrect range
>         store new value
>     
>     Alternatively:
>     
>     Writer:                                 reader:
>     mas_wr_append
>         set end pivot
>         updates end metata
>         Detects write to last slot
>         last lost write to end of slot
>         store value
>                                             mas_next_slot():
>                                                     read end metadata
>                                                     read old end pivot
>                                                     read new end pivot
>                                                     return with incorrect range
>         set old end pivot
>     
>     There may be other accesses that are not safe since we are now updating
>     both metadata and pointers, so disabling append if there could be rcu
>     readers is the safest action.
>     
>     Link: https://lkml.kernel.org/r/20230819004356.1454718-2-Liam.Howlett@oracle.com
>     Fixes: 54a611b60590 ("Maple Tree: add new data structure")
>     Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
>     Cc: <stable@vger.kernel.org>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> 
>  lib/maple_tree.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> 
> And indeed when I revert commit cfeb6ae8bcb96ccf674724f223661bbcef7b0d0b kernel 6.5.5 succeeds booting with CONFIG_VMAP_STACK=y enabled. dmesg of the successful boot with the reverted commit attached, also kernel .config and the bisect.log.
> 
> Regards,
> Erhard F.