eventfd_write returns EGAIN / EWOULDBLOCK when called from ISR context

[chmorgan]

Describe the bug
Calling eventfd_write() from isr context on an eventfd created with flags of 0 results in an error being returned. Calling eventfd_write() on the same FD from thread context works as expected.

There is no mention of ISR related restrictions in the documentation, https://docs.zephyrproject.org/apidoc/latest/posix_2sys_2eventfd_8h.html, and there are other primitives such as events (I know these aren't the same as eventfd) that can signal from ISR to thread.

Without eventfd_write() support from ISR context I can't make use of poll() in my thread.

To Reproduce
Attempt to send a eventfd_write() to a valid FD from isr context.

Expected behavior
Should send correctly as it shouldn't be a blocking operation.

Impact
Not sure. Have to look at how to work around this limitation. Any thoughts on how I should address this? I'd like to maintain cross platform portable code for testing purposes but moving to k_poll() came to mind (without knowing if its possible to wake up a k_poll from ISR context).

Environment (please complete the following information):

• OS: osx
• Toolchain zephyr-sdk-0.16.8
• Tested with v3.7.0 and v4.0.0-rc1

[cfriedt]

The likely more appropriate way to write with eventfd from kernel code (e.g. in an ISR) would be via zvfs_eventfd_write(). It would probably also make sense to convert those to syscalls.

Only non-blocking eventfd's can (currently) be written in ISR context.

https://github.com/zephyrproject-rtos/zephyr/blob/193eeaef0c04570b80a954b58ccd98075150fb11/tests/posix/eventfd/src/nonblocking.c

@chmorgan - do you think a documentation enhancement would help to clarify in here?

[chmorgan]

@cfriedt for sure a documentation change could help.

Are you suggesting that one can call zvfs_eventfd_write() from isr context, or that zephyr should call zvfs_eventfd_write() if eventfd_write() is called from isr context?

It seemed like there could be a mechanism to enable eventfd_write() work from isr context, but even if its possible that doesn't mean it isn't a ton of work.

[cfriedt]

Are you suggesting that one can call zvfs_eventfd_write() from isr context

I think it should be possible today, as long as it's a non-blocking eventfd.

It seemed like there could be a mechanism to enable eventfd_write() work from isr context, but even if its possible that doesn't mean it isn't a ton of work.

It's more like good API hygiene. An ISR should probably depend mostly on the ZVFS API and applications should rely on the eventfd API. That way there are no dependency cycles.

[chmorgan]

@cfriedt eventfd_write() is mapped to zvfs_eventfd_write() which calls zvfs_eventfd_wr_op() against zvfs_eventfd_write_locked().

I tried it here on an eventfd created with flags of 0 and it reports EAGAIN (on v4.0.0-rc1).

int zvfs_eventfd_write(int fd, zvfs_eventfd_t value)
{
	int ret;
	void *obj;

	obj = zvfs_get_fd_obj(fd, &zvfs_eventfd_fd_vtable, EBADF);
	if (obj == NULL) {
		return -1;
	}

	ret = zvfs_eventfd_rw_op(obj, &value, sizeof(zvfs_eventfd_t), zvfs_eventfd_write_locked);
	__ASSERT_NO_MSG(ret == -1 || ret == sizeof(zvfs_eventfd_t));
	if (ret < 0) {
		return -1;
	}

	return 0;
}

and zvfs_eventfd_rw_op() is where the isr check is:

	if (k_is_in_isr()) {
		/* not covered by the man page, but necessary in Zephyr */
		errno = EWOULDBLOCK;
		ret = -1;
		goto unlock_spin;
	}

[cfriedt]

@chmorgan

If the write eventfd was non-blocking, then execution would not make it to the k_is_in_isr() check.

zephyr/lib/os/zvfs/zvfs_eventfd.c

Line 322 in 193eeae

if (!zvfs_eventfd_is_blocking(efd)) {

So again, as in the testsuite linked above, can you please try to create a non-blocking eventfd?

I.e. please use the flag EFD_NONBLOCK (from the application) or ZVFS_EFD_NONBLOCK (from driver code) to open the eventfd in non-blocking mode.

Generally, we can't service anything in ISR context that will block.

[chmorgan]

@cfriedt ahh yes, this makes sense.

It didn't occur to me, although it should have, that eventfd_write() could block and of course we can't block in isr context.

In terms of documentation, something like "Use in ISR: eventfd_write() will fail with EWOULDBLOCK if EFD_NONBLOCK is not set. Set EFD_NONBLOCK for use in ISR." would have helped.

It's working here now that EFD_NONBLOCK is set. If the failure mode matches the documentation for other implementations of eventfd_write, in that an overflow might result in the write not occurring, then I'm ok with that (its a 64bit number and I'm writing 1 each time so nothing will be missed).

[cfriedt]

In terms of documentation, something like "Use in ISR: eventfd_write() will fail with EWOULDBLOCK if EFD_NONBLOCK is not set. Set EFD_NONBLOCK for use in ISR." would have helped.

Probably better to use zvfs_eventfd_write() from inside of an ISR. Hopefully soon we can make ZVFS a proper public API, and at that point, I'll definitely include a bit about using it in ISR context.

It's working here now that EFD_NONBLOCK is set.

🙌 Awesome!

Thanks for your help to sort this out!

[chmorgan]

Thank you for the help. I should have realized sooner what was going on :-p Hopefully this shows up in search if anyone else is using eventfd and poll with zephyr.

…

On Fri, Nov 1, 2024 at 4:08 PM Chris Friedt ***@***.***> wrote: In terms of documentation, something like "Use in ISR: eventfd_write() will fail with EWOULDBLOCK if EFD_NONBLOCK is not set. Set EFD_NONBLOCK for use in ISR." would have helped. Probably better to use zvfs_eventfd_write() from inside of an ISR. Hopefully soon we can make ZVFS a proper public API, and at that point, I'll definitely include a bit about using it in ISR context. It's working here now that EFD_NONBLOCK is set. 🙌 Awesome! Thanks for your help to sort this out! — Reply to this email directly, view it on GitHub <#80690 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJH4AAWIHZ7ZZ2L4LKKHMTZ6PNULAVCNFSM6AAAAABQ6IVCVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJSGUYTQMRSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>