* [dpdk-dev] Printfs in Signal Handler
@ 2020-12-01 3:39 prateekag
2020-12-01 9:24 ` Thomas Monjalon
0 siblings, 1 reply; 6+ messages in thread
From: prateekag @ 2020-12-01 3:39 UTC (permalink / raw)
To: dev; +Cc: thomas
printf is not signal safe and may lead to deadlock if kept in signal handler
and
signal comes in two quick succession. It will not lead to incorrect behavior
and it is a highly unlikely event. And an expert may understand why this
issue happened. Is it worthwhile to change these printfs to unix I/O write
call?
Prateek Agarwal
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Printfs in Signal Handler
2020-12-01 3:39 [dpdk-dev] Printfs in Signal Handler prateekag
@ 2020-12-01 9:24 ` Thomas Monjalon
2020-12-02 20:41 ` Thomas Monjalon
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Monjalon @ 2020-12-01 9:24 UTC (permalink / raw)
To: prateekag; +Cc: dev, Stephen Hemminger
01/12/2020 04:39, prateekag:
> printf is not signal safe and may lead to deadlock if kept in signal handler
> and
> signal comes in two quick succession. It will not lead to incorrect behavior
> and it is a highly unlikely event. And an expert may understand why this
> issue happened. Is it worthwhile to change these printfs to unix I/O write
> call?
Thank you for reporting.
Please could you describe which files and functions you are talking about?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Printfs in Signal Handler
2020-12-01 9:24 ` Thomas Monjalon
@ 2020-12-02 20:41 ` Thomas Monjalon
2020-12-03 0:02 ` prateekag
2020-12-04 9:20 ` prateekag
0 siblings, 2 replies; 6+ messages in thread
From: Thomas Monjalon @ 2020-12-02 20:41 UTC (permalink / raw)
To: prateekag; +Cc: dev, Stephen Hemminger
01/12/2020 10:24, Thomas Monjalon:
> 01/12/2020 04:39, prateekag:
> > printf is not signal safe and may lead to deadlock if kept in signal handler
> > and
> > signal comes in two quick succession. It will not lead to incorrect behavior
> > and it is a highly unlikely event. And an expert may understand why this
> > issue happened. Is it worthwhile to change these printfs to unix I/O write
> > call?
>
> Thank you for reporting.
> Please could you describe which files and functions you are talking about?
I've received a private reply:
Filenames:
testpmd.c
test_pmd_perf.c
evt_main.c
pdump/main.c
Function name:
signal_handler
I am OK with removing these printfs.
Do you want to do the patch with the explanation?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Printfs in Signal Handler
2020-12-02 20:41 ` Thomas Monjalon
@ 2020-12-03 0:02 ` prateekag
2020-12-04 9:20 ` prateekag
1 sibling, 0 replies; 6+ messages in thread
From: prateekag @ 2020-12-03 0:02 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Stephen Hemminger
Ok.
On 2020-12-03 02:11, Thomas Monjalon wrote:
> 01/12/2020 10:24, Thomas Monjalon:
>> 01/12/2020 04:39, prateekag:
>> > printf is not signal safe and may lead to deadlock if kept in signal handler
>> > and
>> > signal comes in two quick succession. It will not lead to incorrect behavior
>> > and it is a highly unlikely event. And an expert may understand why this
>> > issue happened. Is it worthwhile to change these printfs to unix I/O write
>> > call?
>>
>> Thank you for reporting.
>> Please could you describe which files and functions you are talking about?
>
> I've received a private reply:
> Filenames:
> testpmd.c
> test_pmd_perf.c
> evt_main.c
> pdump/main.c
> Function name:
> signal_handler
>
>
> I am OK with removing these printfs.
>
> Do you want to do the patch with the explanation?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Printfs in Signal Handler
2020-12-02 20:41 ` Thomas Monjalon
2020-12-03 0:02 ` prateekag
@ 2020-12-04 9:20 ` prateekag
2020-12-04 9:50 ` Thomas Monjalon
1 sibling, 1 reply; 6+ messages in thread
From: prateekag @ 2020-12-04 9:20 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Stephen Hemminger
Hi,
I can only look at this problem a week later, If someone wants to correct
this, they may go ahead. The problem is how to convert an integer to string
and what functions to use to create the final string. "itoa" is not a part of
C standard, writing custom itoa may pollute the code. strcpy is asyc-safe
afaik.
The strings in which signal number is not required to printed can be directly
converted to write call.
Prateek Agarwal
On 2020-12-03 02:11, Thomas Monjalon wrote:
> 01/12/2020 10:24, Thomas Monjalon:
>> 01/12/2020 04:39, prateekag:
>> > printf is not signal safe and may lead to deadlock if kept in signal handler
>> > and
>> > signal comes in two quick succession. It will not lead to incorrect behavior
>> > and it is a highly unlikely event. And an expert may understand why this
>> > issue happened. Is it worthwhile to change these printfs to unix I/O write
>> > call?
>>
>> Thank you for reporting.
>> Please could you describe which files and functions you are talking about?
>
> I've received a private reply:
> Filenames:
> testpmd.c
> test_pmd_perf.c
> evt_main.c
> pdump/main.c
> Function name:
> signal_handler
>
>
> I am OK with removing these printfs.
>
> Do you want to do the patch with the explanation?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Printfs in Signal Handler
2020-12-04 9:20 ` prateekag
@ 2020-12-04 9:50 ` Thomas Monjalon
0 siblings, 0 replies; 6+ messages in thread
From: Thomas Monjalon @ 2020-12-04 9:50 UTC (permalink / raw)
To: prateekag; +Cc: dev, Stephen Hemminger
04/12/2020 10:20, prateekag:
> Hi,
>
> I can only look at this problem a week later, If someone wants to correct
> this, they may go ahead. The problem is how to convert an integer to string
> and what functions to use to create the final string. "itoa" is not a part of
> C standard, writing custom itoa may pollute the code. strcpy is asyc-safe
> afaik.
> The strings in which signal number is not required to printed can be directly
> converted to write call.
First question is to decide whether the prints are useful enough
to be kept?
> On 2020-12-03 02:11, Thomas Monjalon wrote:
> > 01/12/2020 10:24, Thomas Monjalon:
> >> 01/12/2020 04:39, prateekag:
> >> > printf is not signal safe and may lead to deadlock if kept in signal handler
> >> > and
> >> > signal comes in two quick succession. It will not lead to incorrect behavior
> >> > and it is a highly unlikely event. And an expert may understand why this
> >> > issue happened. Is it worthwhile to change these printfs to unix I/O write
> >> > call?
> >>
> >> Thank you for reporting.
> >> Please could you describe which files and functions you are talking about?
> >
> > I've received a private reply:
> > Filenames:
> > testpmd.c
> > test_pmd_perf.c
> > evt_main.c
> > pdump/main.c
> > Function name:
> > signal_handler
> >
> >
> > I am OK with removing these printfs.
> >
> > Do you want to do the patch with the explanation?
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-12-04 9:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-01 3:39 [dpdk-dev] Printfs in Signal Handler prateekag
2020-12-01 9:24 ` Thomas Monjalon
2020-12-02 20:41 ` Thomas Monjalon
2020-12-03 0:02 ` prateekag
2020-12-04 9:20 ` prateekag
2020-12-04 9:50 ` Thomas Monjalon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).