From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Wednesday, May 5, 2021 8:14 AM

04/05/2021 21:12, Morten Brørup:

quoted

quoted

From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas

Monjalon

quoted

quoted

Sent: Tuesday, May 4, 2021 6:50 PM

29/04/2021 04:10, Min Hu (Connor):

quoted

Currently, the mp uses gettimeofday() API to get the time, and

used

quoted

quoted

as

quoted

timeout parameter.

But the time which gets from gettimeofday() API isn't

monotonically

quoted

quoted

quoted

increasing. The process may fail if the system time is changed.

This fixes it by using clock_gettime() API with monotonic

attribution.

quoted

Fixes: 783b6e54971d ("eal: add synchronous multi-process

communication")

quoted

Fixes: f05e26051c15 ("eal: add IPC asynchronous request")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <redacted>
Signed-off-by: Min Hu (Connor) <redacted>
---

[...]

quoted

--- a/lib/eal/common/eal_common_proc.c
+++ b/lib/eal/common/eal_common_proc.c
-	if (gettimeofday(&now, NULL) < 0) {
-		RTE_LOG(ERR, EAL, "Cannot get current time\n");
-		goto no_trigger;
-	}
-	ts_now.tv_nsec = now.tv_usec * 1000;
-	ts_now.tv_sec = now.tv_sec;
+	clock_gettime(CLOCK_MONOTONIC, &ts_now);

Why not testing the return value?

Because it is guaranteed not to fail. Ref:
https://linux.die.net/man/3/clock_gettime
https://www.freebsd.org/cgi/man.cgi?query=clock_gettime

I see "return 0 for success, or -1 for failure".
Where is it said it cannot fail?

I'm sorry about being unclear. Referring to the "Errors" chapter in the function's man page, this function call is guaranteed not to fail with these parameters. So there is no need to check the return value.

quoted

quoted

I think this change would not be appropriate after -rc1.
If you agree, I will postpone to DPDK 21.08.

It does fix a serious bug, where IPC timeouts can incorrectly happen.

And this is not a theoretical bug; I have seen errors happen due to
using the wrong clock source in other projects.

quoted

However, I have no clue if these IPC library functions are important

or not. So I have no qualified opinion about postponing the change.

I think nobody hit such bug with DPDK IPC.

Then I don't object to postponing.