linux-kernel - Re: [PATCH] perf top: add concurrent access protection of the SLsmg screen management

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: <b50185ae-63f1-c2cf-2721-5b62a1ea378c@huawei.com>
Date:   Tue, 4 Jan 2022 15:21:42 +0800
From:   yaowenbin <yaowenbin1@...wei.com>
To:     Jiri Olsa <jolsa@...hat.com>
CC:     <peterz@...radead.org>, <mingo@...hat.com>, <acme@...nel.org>,
        <mark.rutland@....com>, <alexander.shishkin@...ux.intel.com>,
        <namhyung@...nel.org>, <linux-kernel@...r.kernel.org>,
        <hewenliang4@...wei.com>, <wuxu.wu@...wei.com>
Subject: Re: [PATCH] perf top: add concurrent access protection of the SLsmg
 screen management

In ui__refresh_dimensions function, ui__lock will also be acquired, so we use trylock
in the signal handler ui__exit to avoid deadlock.
Thanks.

在 2021/12/31 22:10, Jiri Olsa 写道:
> On Wed, Dec 29, 2021 at 04:55:19PM +0800, yaowenbin wrote:
>> When the following command is executed several times, a coredump file is generated.
>> 	$ timeout -k 9 5 perf top -e task-clock
>> 	*******
>> 	*******
>> 	*******
>> 	0.01%  [kernel]                  [k] __do_softirq
>> 	0.01%  libpthread-2.28.so        [.] __pthread_mutex_lock
>> 	0.01%  [kernel]                  [k] __ll_sc_atomic64_sub_return
>> 	double free or corruption (!prev) perf top --sort comm,dso
>> 	timeout: the monitored command dumped core
>>
>> When we terminate "perf top" using sending signal method, SLsmg_reset_smg
>> function is called. SLsmg_reset_smg resets the SLsmg screen management routines
>> by freeing all memory allocated while it was active. However SLsmg_reinit_smg
>> function maybe be called by another thread. SLsmg_reinit_smg function will
>> free the same memory accessed by SLsmg_reset_smg functon, thus it results
>> in double free. SLsmg_reinit_smg function is called already protected by
>> ui__lock, so we fix the problem by adding pthread_mutex_trylock of ui__lock
>> when calling SLsmg_reset_smg function.
>>
>> Signed-off-by: yaowenbin <yaowenbin1@...wei.com>
>> Signed-off-by: hewenliang <hewenliang4@...wei.com>
>> Signed-off-by: Wenyu Liu <liuwenyu7@...wei.com>
>> ---
>>  tools/perf/ui/tui/setup.c | 8 +++++---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/perf/ui/tui/setup.c b/tools/perf/ui/tui/setup.c
>> index d4ac41679..1fdf92062 100644
>> --- a/tools/perf/ui/tui/setup.c
>> +++ b/tools/perf/ui/tui/setup.c
>> @@ -170,9 +170,11 @@ void ui__exit(bool wait_for_ok)
>>  				    "Press any key...", 0);
>>
>>  	SLtt_set_cursor_visibility(1);
>> -	SLsmg_refresh();
>> -	SLsmg_reset_smg();
>> +	if (!pthread_mutex_trylock(&ui__lock)) {
> 
> trylock because it can be called from signal, right?
> could you plase add some comment about that
> 
> thanks,
> jirka
> 
>> +		SLsmg_refresh();
>> +		SLsmg_reset_smg();
>> +		pthread_mutex_unlock(&ui__lock);
>> +	}
>>  	SLang_reset_tty();
>> -
>>  	perf_error__unregister(&perf_tui_eops);
>>  }
>> --
>> 2.27.0
>>
> 
> .