linux-kernel - 回复: 回复: [PATCH] mm,oom_reaper: avoid run queue_oom

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]

Message-ID: <1d84bf0d1aed45bbbc5941483d8e1695@hihonor.com>
Date:   Sat, 25 Nov 2023 06:46:04 +0000
From:   gaoxu <gaoxu2@...onor.com>
To:     Michal Hocko <mhocko@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>
CC:     "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        yipengxiang <yipengxiang@...onor.com>
Subject: 回复: 回复: [PATCH] mm,oom_reaper: avoid run queue_oom_reaper if task is not oom

On Fri, 24 Nov 2023 09:31  Michal Hocko wrote:
>On Fri 24-11-23 03:15:46, gaoxu wrote:
>[...]
>> >> [3701:11_see]Unable to handle kernel NULL pointer dereference at 
>> >> virtual address 0000000000000328 [3701:11_see]user pgtable: 4k 
>> >> pages, 39-bit VAs, pgdp=00000000821de000 
>> >> [3701:11_see][0000000000000328] pgd=0000000000000000,
>> >> p4d=0000000000000000,pud=0000000000000000
>> >> [3701:11_see]tracing off
>> >> [3701:11_see]Internal error: Oops: 96000005 [#1] PREEMPT SMP 
>> >> [3701:11_see]Call trace:
>> >> [3701:11_see] queue_oom_reaper+0x30/0x170
>> >
>> > Could you resolve this offset into the code line please?
>> Due to the additional code we added for log purposes, the line numbers may not correspond to the original Linux code.
>> 
>> static void queue_oom_reaper(struct task_struct *tsk) {
>> 	/* mm is already queued? */
>> 	if (test_and_set_bit(MMF_OOM_REAP_QUEUED, &tsk->signal->oom_mm->flags)) //a null pointer exception occurred
>> 		return;
>
>Did you manage to narrow it down to which of the dereference this corresponds to? Is it tsk->signal == NULL or signal->oom_mm == NULL.
>The faulting address doesn't match neither with my configs.

[...]

>> >> --- a/mm/oom_kill.c
>> >> +++ b/mm/oom_kill.c
>> >> @@ -984,7 +984,7 @@ static void __oom_kill_process(struct task_struct *victim, const char *message)
>> >>  	}
>> >>  	rcu_read_unlock();
>> >>  
>> >> -	if (can_oom_reap)
>> >> +	if (can_oom_reap && tsk_is_oom_victim(victim))
>> >>  		queue_oom_reaper(victim);
>> >
>> > I do not understand. We always do send SIGKILL and call mark_oom_victim(victim); on victim task when reaching out here. How can tsk_is_oom_victim can ever be false?
>> This is a low-probability issue, as it only occurred once during the monkey testing.
>> I haven't been able to find the root cause either.
>
>OK, was there any non-standard code running during this test?
>In any case I do not see how this patch could be correct. If, for some reason we managed to release the signal structure or something else then we need to understand whether this is a locking or reference counting issue. I do not really see how this would be possible. But this check right here doesn't really make sense.

there was no any non-standard code running during this test.
The cause of the OOM error is the process surfaceflinger has encountered dma-buf memory leak.
This problem is likely caused by concurrency. I will try to create a concurrent scenario of oom or kill process to reproduce the issue,
and if discover anything, I will send it here.
Thank you, Michal and Andrew, for analyzing and discussing the issue.

>Andrew please drop the patch from your tree.