linux-kernel - Re: [PATCH v2] mm/memory-failure: fix crash in split_huge_page_to_list from soft_offline

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri, 26 Jan 2024 09:13:51 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Matthew Wilcox <willy@...radead.org>
CC: <naoya.horiguchi@....com>, <akpm@...ux-foundation.org>,
	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] mm/memory-failure: fix crash in
 split_huge_page_to_list from soft_offline_page

On 2024/1/25 22:22, Matthew Wilcox wrote:
> On Thu, Jan 25, 2024 at 07:53:25PM +0800, Miaohe Lin wrote:
>> On 2024/1/24 21:15, Matthew Wilcox wrote:
>>>>   Call Trace:
>>>>    <TASK>
>>>>    ? die+0x32/0x90
>>>>    ? do_trap+0xde/0x110
>>>>    ? folio_memcg+0xaf/0xd0
>>>>    ? do_error_trap+0x60/0x80
>>>>    ? folio_memcg+0xaf/0xd0
>>>>    ? exc_invalid_op+0x53/0x70
>>>>    ? folio_memcg+0xaf/0xd0
>>>>    ? asm_exc_invalid_op+0x1a/0x20
>>>>    ? folio_memcg+0xaf/0xd0
>>>>    ? folio_memcg+0xae/0xd0
>>>
>>> I might trim these ? lines out of the backtrace ...
>>
>> Do you mean make backtrace looks like something below?
>>
>> Call Trace:
>>  <TASK>
>>  split_huge_page_to_list+0x4d/0x1380
>>  ? sysvec_apic_timer_interrupt+0xf/0x80
>>  try_to_split_thp_page+0x3a/0xf0
>>  soft_offline_page+0x1ea/0x8a0
>>  soft_offline_page_store+0x52/0x90
>>  kernfs_fop_write_iter+0x118/0x1b0
>>  vfs_write+0x30b/0x430
>>  ksys_write+0x5e/0xe0
>>  do_syscall_64+0xb0/0x1b0
>>  entry_SYSCALL_64_after_hwframe+0x6d/0x75
>> RIP: 0033:0x7f6c60d14697
> 
> Yes.  I'd trim the sysvec_apic_timer_interrupt+0xf/0x80 line too.
> These lines aren't actually part of the call trace.  They're addresses
> that the unwinder found on the stack but don't actually fit the call
> trace.  It puts them in in case they're helpful, but marks them with a ?
> to indicate that they're probably not part of the call trace.

I see. Many thanks for your explanation. Will update backtrace in next version.

Thanks.