[PATCH v3 2/3] eal: fix unckeck pipe

[huangdengdui]

On 2025/4/2 22:45, Morten Brørup wrote:
>> From: Dengdui Huang [mailto:huangdengdui at huawei.com]
>> Sent: Wednesday, 2 April 2025 14.25
>>
>> The communication pipe may be unavailable, for example,
>> when the lcore role is ROLE_OFF or ROLE_NON_EAL.
>> So check whether the pipe is available before using it.
>>
>> Fixes: a95d70547c57 ("eal: factorize lcore main loop")
>> Cc: stable at dpdk.org
>>
>> Signed-off-by: Dengdui Huang <huangdengdui at huawei.com>
>> ---
>>  lib/eal/unix/eal_unix_thread.c | 3 +++
>>  lib/eal/windows/eal_thread.c   | 3 +++
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/lib/eal/unix/eal_unix_thread.c
>> b/lib/eal/unix/eal_unix_thread.c
>> index ef6cbff0ee..103571cabf 100644
>> --- a/lib/eal/unix/eal_unix_thread.c
>> +++ b/lib/eal/unix/eal_unix_thread.c
>> @@ -17,6 +17,9 @@ eal_thread_wake_worker(unsigned int worker_id)
>>  	char c = 0;
>>  	int n;
>>
>> +	if (m2w == 0 || w2m == 0)
>> +		return -EINVAL;
>> +
>>  	do {
>>  		n = write(m2w, &c, 1);
>>  	} while (n == 0 || (n < 0 && errno == EINTR));
>> diff --git a/lib/eal/windows/eal_thread.c
>> b/lib/eal/windows/eal_thread.c
>> index 9e3df200b9..82bb974868 100644
>> --- a/lib/eal/windows/eal_thread.c
>> +++ b/lib/eal/windows/eal_thread.c
>> @@ -24,6 +24,9 @@ eal_thread_wake_worker(unsigned int worker_id)
>>  	char c = 0;
>>  	int n;
>>
>> +	if (m2w == 0 || w2m == 0)
>> +		return -EINVAL;
>> +
>>  	do {
>>  		n = _write(m2w, &c, 1);
>>  	} while (n == 0 || (n < 0 && errno == EINTR));
>> --
>> 2.33.0
> 
> This internal function eal_thread_wake_worker() is only called from rte_eal_remote_launch().
> It would be better to check the lcore role there.
> 

Is it better to check lcore roles in rte_eal_remote_launch() instead?
Only Role_RTE and Role_SERVICE lcore can be woken up through rte_eal_remote_launch().

> References:
> https://elixir.bootlin.com/dpdk/v25.03-rc2/A/ident/eal_thread_wake_worker
> https://elixir.bootlin.com/dpdk/v25.03-rc2/source/lib/eal/common/eal_common_launch.c#L52
> 
> Furthermore, in theory, file descriptor 0 is a valid file descriptor; if "stdin" has been closed, a newly opened file (or pipe) may be assigned file descriptor 0.
> 
>