DPDK patches and discussions
 help / color / mirror / Atom feed
* [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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git