2019-10-27 11:46:18 +01:00
|
|
|
#include "fdm.h"
|
|
|
|
|
|
|
|
|
|
#include <stdlib.h>
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
#include <stdbool.h>
|
2019-10-27 11:46:18 +01:00
|
|
|
#include <unistd.h>
|
|
|
|
|
#include <errno.h>
|
|
|
|
|
#include <assert.h>
|
2020-01-10 19:22:10 +01:00
|
|
|
#include <fcntl.h>
|
|
|
|
|
|
2019-10-27 11:46:18 +01:00
|
|
|
#include <sys/epoll.h>
|
|
|
|
|
|
2019-11-17 19:19:55 +01:00
|
|
|
#include <tllist.h>
|
|
|
|
|
|
2019-10-27 11:46:18 +01:00
|
|
|
#define LOG_MODULE "fdm"
|
|
|
|
|
#define LOG_ENABLE_DBG 0
|
|
|
|
|
#include "log.h"
|
|
|
|
|
|
2019-11-02 23:37:19 +01:00
|
|
|
struct handler {
|
2019-10-27 11:46:18 +01:00
|
|
|
int fd;
|
2019-11-03 00:22:22 +01:00
|
|
|
int events;
|
2019-11-02 23:37:19 +01:00
|
|
|
fdm_handler_t callback;
|
|
|
|
|
void *callback_data;
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
bool deleted;
|
2019-10-27 11:46:18 +01:00
|
|
|
};
|
|
|
|
|
|
2020-01-04 19:48:15 +01:00
|
|
|
struct hook {
|
|
|
|
|
fdm_hook_t callback;
|
|
|
|
|
void *callback_data;
|
|
|
|
|
};
|
|
|
|
|
|
2020-01-04 23:26:27 +01:00
|
|
|
typedef tll(struct hook) hooks_t;
|
|
|
|
|
|
2019-10-27 11:46:18 +01:00
|
|
|
struct fdm {
|
|
|
|
|
int epoll_fd;
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
bool is_polling;
|
2019-11-02 23:37:19 +01:00
|
|
|
tll(struct handler *) fds;
|
|
|
|
|
tll(struct handler *) deferred_delete;
|
2020-01-04 23:26:27 +01:00
|
|
|
hooks_t hooks_low;
|
|
|
|
|
hooks_t hooks_normal;
|
|
|
|
|
hooks_t hooks_high;
|
2019-10-27 11:46:18 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct fdm *
|
|
|
|
|
fdm_init(void)
|
|
|
|
|
{
|
|
|
|
|
int epoll_fd = epoll_create1(EPOLL_CLOEXEC);
|
|
|
|
|
if (epoll_fd == -1) {
|
|
|
|
|
LOG_ERRNO("failed to create epoll FD");
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct fdm *fdm = malloc(sizeof(*fdm));
|
|
|
|
|
*fdm = (struct fdm){
|
|
|
|
|
.epoll_fd = epoll_fd,
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
.is_polling = false,
|
2019-10-27 11:46:18 +01:00
|
|
|
.fds = tll_init(),
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
.deferred_delete = tll_init(),
|
2020-01-04 23:26:27 +01:00
|
|
|
.hooks_low = tll_init(),
|
|
|
|
|
.hooks_normal = tll_init(),
|
|
|
|
|
.hooks_high = tll_init(),
|
2019-10-27 11:46:18 +01:00
|
|
|
};
|
|
|
|
|
return fdm;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
fdm_destroy(struct fdm *fdm)
|
|
|
|
|
{
|
|
|
|
|
if (fdm == NULL)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (tll_length(fdm->fds) > 0)
|
|
|
|
|
LOG_WARN("FD list not empty");
|
|
|
|
|
|
2020-01-04 23:26:27 +01:00
|
|
|
if (tll_length(fdm->hooks_low) > 0 ||
|
|
|
|
|
tll_length(fdm->hooks_normal) > 0 ||
|
|
|
|
|
tll_length(fdm->hooks_high) > 0)
|
|
|
|
|
{
|
2020-01-04 19:48:15 +01:00
|
|
|
LOG_WARN("hook list not empty");
|
2020-01-04 23:26:27 +01:00
|
|
|
}
|
2020-01-04 19:48:15 +01:00
|
|
|
|
2019-10-27 11:46:18 +01:00
|
|
|
assert(tll_length(fdm->fds) == 0);
|
2019-11-02 23:36:02 +01:00
|
|
|
assert(tll_length(fdm->deferred_delete) == 0);
|
2020-01-04 23:26:27 +01:00
|
|
|
assert(tll_length(fdm->hooks_low) == 0);
|
|
|
|
|
assert(tll_length(fdm->hooks_normal) == 0);
|
|
|
|
|
assert(tll_length(fdm->hooks_high) == 0);
|
2019-10-27 11:46:18 +01:00
|
|
|
|
|
|
|
|
tll_free(fdm->fds);
|
2019-11-02 23:36:02 +01:00
|
|
|
tll_free(fdm->deferred_delete);
|
2020-01-04 23:26:27 +01:00
|
|
|
tll_free(fdm->hooks_low);
|
|
|
|
|
tll_free(fdm->hooks_normal);
|
|
|
|
|
tll_free(fdm->hooks_high);
|
2019-10-27 11:46:18 +01:00
|
|
|
close(fdm->epoll_fd);
|
|
|
|
|
free(fdm);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool
|
|
|
|
|
fdm_add(struct fdm *fdm, int fd, int events, fdm_handler_t handler, void *data)
|
|
|
|
|
{
|
|
|
|
|
#if defined(_DEBUG)
|
2020-01-10 19:22:10 +01:00
|
|
|
int flags = fcntl(fd, F_GETFL);
|
|
|
|
|
if (!(flags & O_NONBLOCK)) {
|
|
|
|
|
LOG_ERR("FD=%d is in blocking mode", fd);
|
|
|
|
|
assert(false);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-27 11:46:18 +01:00
|
|
|
tll_foreach(fdm->fds, it) {
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
if (it->item->fd == fd) {
|
2019-10-27 11:46:18 +01:00
|
|
|
LOG_ERR("FD=%d already registered", fd);
|
2020-01-10 19:22:10 +01:00
|
|
|
assert(false);
|
2019-10-27 11:46:18 +01:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-11-02 23:37:19 +01:00
|
|
|
struct handler *fd_data = malloc(sizeof(*fd_data));
|
|
|
|
|
*fd_data = (struct handler) {
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
.fd = fd,
|
2019-11-03 00:22:22 +01:00
|
|
|
.events = events,
|
2019-11-02 23:37:19 +01:00
|
|
|
.callback = handler,
|
|
|
|
|
.callback_data = data,
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
.deleted = false,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
tll_push_back(fdm->fds, fd_data);
|
2019-10-27 11:46:18 +01:00
|
|
|
|
|
|
|
|
struct epoll_event ev = {
|
|
|
|
|
.events = events,
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
.data = {.ptr = fd_data},
|
2019-10-27 11:46:18 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
if (epoll_ctl(fdm->epoll_fd, EPOLL_CTL_ADD, fd, &ev) < 0) {
|
2019-11-03 00:22:22 +01:00
|
|
|
LOG_ERRNO("failed to register FD=%d with epoll", fd);
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
free(fd_data);
|
2019-10-27 11:46:18 +01:00
|
|
|
tll_pop_back(fdm->fds);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
static bool
|
|
|
|
|
fdm_del_internal(struct fdm *fdm, int fd, bool close_fd)
|
2019-10-27 11:46:18 +01:00
|
|
|
{
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
if (fd == -1)
|
|
|
|
|
return true;
|
|
|
|
|
|
2019-10-27 11:46:18 +01:00
|
|
|
tll_foreach(fdm->fds, it) {
|
2019-11-03 00:42:34 +01:00
|
|
|
if (it->item->fd != fd)
|
|
|
|
|
continue;
|
2019-10-27 11:46:18 +01:00
|
|
|
|
2019-11-03 00:42:34 +01:00
|
|
|
if (epoll_ctl(fdm->epoll_fd, EPOLL_CTL_DEL, fd, NULL) < 0)
|
|
|
|
|
LOG_ERRNO("failed to unregister FD=%d from epoll", fd);
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
|
2019-11-03 00:42:34 +01:00
|
|
|
if (close_fd)
|
|
|
|
|
close(it->item->fd);
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
|
2019-11-03 00:42:34 +01:00
|
|
|
it->item->deleted = true;
|
|
|
|
|
if (fdm->is_polling)
|
|
|
|
|
tll_push_back(fdm->deferred_delete, it->item);
|
|
|
|
|
else
|
|
|
|
|
free(it->item);
|
|
|
|
|
|
|
|
|
|
tll_remove(fdm->fds, it);
|
|
|
|
|
return true;
|
2019-10-27 11:46:18 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
LOG_ERR("no such FD: %d", fd);
|
2019-12-15 15:06:09 +01:00
|
|
|
close(fd);
|
2019-10-27 11:46:18 +01:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
bool
|
|
|
|
|
fdm_del(struct fdm *fdm, int fd)
|
|
|
|
|
{
|
|
|
|
|
return fdm_del_internal(fdm, fd, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool
|
|
|
|
|
fdm_del_no_close(struct fdm *fdm, int fd)
|
|
|
|
|
{
|
|
|
|
|
return fdm_del_internal(fdm, fd, false);
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-03 00:22:22 +01:00
|
|
|
static bool
|
|
|
|
|
event_modify(struct fdm *fdm, struct handler *fd, int new_events)
|
|
|
|
|
{
|
|
|
|
|
if (new_events == fd->events)
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
struct epoll_event ev = {
|
|
|
|
|
.events = new_events,
|
|
|
|
|
.data = {.ptr = fd},
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
if (epoll_ctl(fdm->epoll_fd, EPOLL_CTL_MOD, fd->fd, &ev) < 0) {
|
|
|
|
|
LOG_ERRNO("failed to modify FD=%d with epoll (events 0x%08x -> 0x%08x)",
|
|
|
|
|
fd->fd, fd->events, new_events);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fd->events = new_events;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool
|
|
|
|
|
fdm_event_add(struct fdm *fdm, int fd, int events)
|
|
|
|
|
{
|
|
|
|
|
tll_foreach(fdm->fds, it) {
|
|
|
|
|
if (it->item->fd != fd)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
return event_modify(fdm, it->item, it->item->events | events);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
LOG_ERR("FD=%d not registered with the FDM", fd);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool
|
|
|
|
|
fdm_event_del(struct fdm *fdm, int fd, int events)
|
|
|
|
|
{
|
|
|
|
|
tll_foreach(fdm->fds, it) {
|
|
|
|
|
if (it->item->fd != fd)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
return event_modify(fdm, it->item, it->item->events & ~events);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
LOG_ERR("FD=%d not registered with the FDM", fd);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-04 23:26:27 +01:00
|
|
|
static hooks_t *
|
|
|
|
|
hook_priority_to_list(struct fdm *fdm, enum fdm_hook_priority priority)
|
|
|
|
|
{
|
|
|
|
|
switch (priority) {
|
|
|
|
|
case FDM_HOOK_PRIORITY_LOW: return &fdm->hooks_low;
|
|
|
|
|
case FDM_HOOK_PRIORITY_NORMAL: return &fdm->hooks_normal;
|
|
|
|
|
case FDM_HOOK_PRIORITY_HIGH: return &fdm->hooks_high;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
assert(false);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-04 19:48:15 +01:00
|
|
|
bool
|
2020-01-04 23:26:27 +01:00
|
|
|
fdm_hook_add(struct fdm *fdm, fdm_hook_t hook, void *data,
|
|
|
|
|
enum fdm_hook_priority priority)
|
2020-01-04 19:48:15 +01:00
|
|
|
{
|
2020-01-04 23:26:27 +01:00
|
|
|
hooks_t *hooks = hook_priority_to_list(fdm, priority);
|
|
|
|
|
|
2020-01-04 19:48:15 +01:00
|
|
|
#if defined(_DEBUG)
|
2020-01-04 23:26:27 +01:00
|
|
|
tll_foreach(*hooks, it) {
|
2020-01-04 19:48:15 +01:00
|
|
|
if (it->item.callback == hook) {
|
|
|
|
|
LOG_ERR("hook=%p already registered", hook);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2020-01-04 23:26:27 +01:00
|
|
|
tll_push_back(*hooks, ((struct hook){hook, data}));
|
2020-01-04 19:48:15 +01:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool
|
2020-01-04 23:26:27 +01:00
|
|
|
fdm_hook_del(struct fdm *fdm, fdm_hook_t hook, enum fdm_hook_priority priority)
|
2020-01-04 19:48:15 +01:00
|
|
|
{
|
2020-01-04 23:26:27 +01:00
|
|
|
hooks_t *hooks = hook_priority_to_list(fdm, priority);
|
|
|
|
|
|
|
|
|
|
tll_foreach(*hooks, it) {
|
2020-01-04 19:48:15 +01:00
|
|
|
if (it->item.callback != hook)
|
|
|
|
|
continue;
|
|
|
|
|
|
2020-01-04 23:26:27 +01:00
|
|
|
tll_remove(*hooks, it);
|
2020-01-04 19:48:15 +01:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-10 19:22:41 +01:00
|
|
|
LOG_WARN("hook=%p not registered", hook);
|
2020-01-04 19:48:15 +01:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-27 11:46:18 +01:00
|
|
|
bool
|
|
|
|
|
fdm_poll(struct fdm *fdm)
|
|
|
|
|
{
|
2019-11-02 13:46:54 +01:00
|
|
|
assert(!fdm->is_polling && "nested calls to fdm_poll() not allowed");
|
|
|
|
|
if (fdm->is_polling) {
|
|
|
|
|
LOG_ERR("nested calls to fdm_poll() not allowed");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-04 23:26:27 +01:00
|
|
|
tll_foreach(fdm->hooks_high, it) {
|
|
|
|
|
LOG_DBG("executing high priority hook %p(fdm=%p, data=%p)",
|
|
|
|
|
it->item.callback, fdm, it->item.callback_data);
|
|
|
|
|
it->item.callback(fdm, it->item.callback_data);
|
|
|
|
|
}
|
|
|
|
|
tll_foreach(fdm->hooks_normal, it) {
|
|
|
|
|
LOG_DBG("executing normal priority hook %p(fdm=%p, data=%p)",
|
|
|
|
|
it->item.callback, fdm, it->item.callback_data);
|
|
|
|
|
it->item.callback(fdm, it->item.callback_data);
|
|
|
|
|
}
|
|
|
|
|
tll_foreach(fdm->hooks_low, it) {
|
|
|
|
|
LOG_DBG("executing low priority hook %p(fdm=%p, data=%p)",
|
2020-01-04 19:48:15 +01:00
|
|
|
it->item.callback, fdm, it->item.callback_data);
|
|
|
|
|
it->item.callback(fdm, it->item.callback_data);
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-27 11:46:18 +01:00
|
|
|
struct epoll_event events[tll_length(fdm->fds)];
|
2019-11-02 23:35:42 +01:00
|
|
|
|
|
|
|
|
int r = epoll_wait(fdm->epoll_fd, events, tll_length(fdm->fds), -1);
|
|
|
|
|
if (r == -1) {
|
2019-10-27 11:46:18 +01:00
|
|
|
if (errno == EINTR)
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
LOG_ERRNO("failed to epoll");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-02 23:35:42 +01:00
|
|
|
bool ret = true;
|
|
|
|
|
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
fdm->is_polling = true;
|
2019-11-03 00:51:47 +01:00
|
|
|
for (int i = 0; i < r; i++) {
|
2019-11-02 23:37:19 +01:00
|
|
|
struct handler *fd = events[i].data.ptr;
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
if (fd->deleted)
|
|
|
|
|
continue;
|
|
|
|
|
|
2019-11-02 23:37:19 +01:00
|
|
|
if (!fd->callback(fdm, fd->fd, events[i].events, fd->callback_data)) {
|
2019-11-02 23:35:42 +01:00
|
|
|
ret = false;
|
|
|
|
|
break;
|
fdm: don't free FD data that may be referenced by epoll return data
It is perfectly possible, and legal, for a FDM handler to delete
another handler. The problem however is when the epoll returned array
of FD events contain the removed FD handler *after* the handler that
removed it.
That is, if the epoll returned array is:
[FD=13, FD=37]
and the handler for FD=13 removes FD=37, then given the current
implementation, the FD user data (our handler callback etc) will point
to a free:d address.
Add support for this situation by deferring FD handler removal *when
called from another handler*.
This is done by "locking" the FDM struct before looping the handlers
for FDs with events (and unlocking afterwards).
In fdm_del(), we check if the FDM has been locked, in which case the
FD is marked as deleted, and put on a deferred list. But
not *actually* deleted.
Meanwhile, in the FDM poll function, we skip calling handlers for
marked-for-deletion FDs.
Then, when all FDs have been processed, we loop the deferred list and
finally deletes the FDs for real.
2019-11-01 19:51:33 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
fdm->is_polling = false;
|
|
|
|
|
|
|
|
|
|
tll_foreach(fdm->deferred_delete, it) {
|
|
|
|
|
free(it->item);
|
|
|
|
|
tll_remove(fdm->deferred_delete, it);
|
2019-10-27 11:46:18 +01:00
|
|
|
}
|
|
|
|
|
|
2019-11-02 23:35:42 +01:00
|
|
|
return ret;
|
2019-10-27 11:46:18 +01:00
|
|
|
}
|