Page MenuHomeFreeBSD
Differential D28169

epoll: Store epoll_event udata member in ext member of kevent.
ClosedPublic
Actions

Authored by wulf on Jan 14 2021, 8:51 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Mar 29, 5:39 AM
Unknown Object (File)
Tue, Mar 25, 2:28 PM
Unknown Object (File)
Mar 13 2025, 11:42 AM
Unknown Object (File)
Mar 5 2025, 9:01 PM
Unknown Object (File)
Feb 22 2025, 2:01 AM
Unknown Object (File)
Feb 18 2025, 8:01 AM
Unknown Object (File)
Feb 8 2025, 8:29 PM
Unknown Object (File)
Feb 7 2025, 9:14 AM
View All 67 Files
Subscribers
ankohuu_outlook.com

Details

Reviewers
trasz
Group Reviewers
Linux Emulation
Commits
rGfd140c52160a: epoll: Store epoll_event udata member in ext member of kevent.
rGb3c6fe663bb9: epoll: Store epoll_event udata member in ext member of kevent.
Summary

Current epoll implementation stores udata fields of epoll_event
structure in special dynamically-sized table rather than in udata field
of backing kevent structure because of 2 reasons:

  1. Kevent's udata size is smaller than epoll's on 32-bit archs.
  2. Kevent's udata can be clobbered on execution EPOLL_CTL_ADD as kqueue modifies existing event while epoll returns error in this case.

After r320043 has introduced 4 new 64bit user data members (ext[]),
we can store epoll udata in one of them and drop aforementioned table.
According to kqueue_register() source code ext members are not updated
when existing kevent is modified that fixes p.2.

As a side effect the patch fixes PR/252582.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Revision Contents
Changeset List

PathSize
sys/
compat/
linux/
1 line
21 lines
81 lines

Diff 82292

View Options

sys/compat/linux/linux_emul.h

Show First 20 Lines • Show All 215 Lines • ▼ Show 20 Linesprocfile(const char *fn)
for (c = 0; c == 0 || !(lflag || qflag); ) { for (c = 0; c == 0 || !(lflag || qflag); ) {
ln.off += ln.len + 1; ln.off += ln.len + 1;
if ((ln.dat = grep_fgetln(f, &ln.len)) == NULL || ln.len == 0) { if ((ln.dat = grep_fgetln(f, &ln.len)) == NULL || ln.len == 0) {
if (ln.line_no == 0 && matchall) if (ln.line_no == 0 && matchall)
exit(0); exit(0);
else else
break; break;
} }
if (ln.len > 0 && ln.dat[ln.len - 1] == '\n') if (ln.len > 0 && ln.dat[ln.len - 1] == fileeol)
--ln.len; --ln.len;
ln.line_no++; ln.line_no++;
/* Return if we need to skip a binary file */ /* Return if we need to skip a binary file */
if (f->binary && binbehave == BINFILE_SKIP) { if (f->binary && binbehave == BINFILE_SKIP) {
grep_close(f); grep_close(f);
free(ln.file); free(ln.file);
free(f); free(f);
▲ Show 20 Lines • Show All 254 Lines • ▼ Show 20 Lines if ((oflag || color) && m > 0) {
} }
if (!oflag) { if (!oflag) {
if (line->len - a > 0) if (line->len - a > 0)
fwrite(line->dat + a, line->len - a, 1, stdout); fwrite(line->dat + a, line->len - a, 1, stdout);
putchar('\n'); putchar('\n');
} }
} else { } else {
fwrite(line->dat, line->len, 1, stdout); fwrite(line->dat, line->len, 1, stdout);
putchar('\n'); putchar(fileeol);
cemUnsubmitted
Not Done
Inline Actions

Hm, should the nul input separater really be used for outputting matched lines?

And if so, shouldn't it also be used with oflag above?

cem: Hm, should the nul input separater really be used for outputting matched lines? And if so…
kevansAuthorUnsubmitted
Not Done
Inline Actions

So, it depends. If we're supposed to be printing the matched lines, we need to do so faithful to the input file -- i.e., this line, and actually line 491 that I missed (!oflag, but color). Everything else is printing excerpts and should use the standard grep newline separator.

kevans: So, it depends. If we're supposed to be printing the matched lines, we need to do so faithful…
} }
} }
View Options

sys/compat/linux/linux_emul.c

Show First 20 Lines • Show All 215 Lines • ▼ Show 20 Linesprocfile(const char *fn)
for (c = 0; c == 0 || !(lflag || qflag); ) { for (c = 0; c == 0 || !(lflag || qflag); ) {
ln.off += ln.len + 1; ln.off += ln.len + 1;
if ((ln.dat = grep_fgetln(f, &ln.len)) == NULL || ln.len == 0) { if ((ln.dat = grep_fgetln(f, &ln.len)) == NULL || ln.len == 0) {
if (ln.line_no == 0 && matchall) if (ln.line_no == 0 && matchall)
exit(0); exit(0);
else else
break; break;
} }
if (ln.len > 0 && ln.dat[ln.len - 1] == '\n') if (ln.len > 0 && ln.dat[ln.len - 1] == fileeol)
--ln.len; --ln.len;
ln.line_no++; ln.line_no++;
/* Return if we need to skip a binary file */ /* Return if we need to skip a binary file */
if (f->binary && binbehave == BINFILE_SKIP) { if (f->binary && binbehave == BINFILE_SKIP) {
grep_close(f); grep_close(f);
free(ln.file); free(ln.file);
free(f); free(f);
▲ Show 20 Lines • Show All 254 Lines • ▼ Show 20 Lines if ((oflag || color) && m > 0) {
} }
if (!oflag) { if (!oflag) {
if (line->len - a > 0) if (line->len - a > 0)
fwrite(line->dat + a, line->len - a, 1, stdout); fwrite(line->dat + a, line->len - a, 1, stdout);
putchar('\n'); putchar('\n');
} }
} else { } else {
fwrite(line->dat, line->len, 1, stdout); fwrite(line->dat, line->len, 1, stdout);
putchar('\n'); putchar(fileeol);
cemUnsubmitted
Not Done
Inline Actions

Hm, should the nul input separater really be used for outputting matched lines?

And if so, shouldn't it also be used with oflag above?

cem: Hm, should the nul input separater really be used for outputting matched lines? And if so…
kevansAuthorUnsubmitted
Not Done
Inline Actions

So, it depends. If we're supposed to be printing the matched lines, we need to do so faithful to the input file -- i.e., this line, and actually line 491 that I missed (!oflag, but color). Everything else is printing excerpts and should use the standard grep newline separator.

kevans: So, it depends. If we're supposed to be printing the matched lines, we need to do so faithful…
} }
} }
View Options

sys/compat/linux/linux_event.c

Show First 20 Lines • Show All 215 Lines • ▼ Show 20 Linesprocfile(const char *fn)
for (c = 0; c == 0 || !(lflag || qflag); ) { for (c = 0; c == 0 || !(lflag || qflag); ) {
ln.off += ln.len + 1; ln.off += ln.len + 1;
if ((ln.dat = grep_fgetln(f, &ln.len)) == NULL || ln.len == 0) { if ((ln.dat = grep_fgetln(f, &ln.len)) == NULL || ln.len == 0) {
if (ln.line_no == 0 && matchall) if (ln.line_no == 0 && matchall)
exit(0); exit(0);
else else
break; break;
} }
if (ln.len > 0 && ln.dat[ln.len - 1] == '\n') if (ln.len > 0 && ln.dat[ln.len - 1] == fileeol)
--ln.len; --ln.len;
ln.line_no++; ln.line_no++;
/* Return if we need to skip a binary file */ /* Return if we need to skip a binary file */
if (f->binary && binbehave == BINFILE_SKIP) { if (f->binary && binbehave == BINFILE_SKIP) {
grep_close(f); grep_close(f);
free(ln.file); free(ln.file);
free(f); free(f);
▲ Show 20 Lines • Show All 254 Lines • ▼ Show 20 Lines if ((oflag || color) && m > 0) {
} }
if (!oflag) { if (!oflag) {
if (line->len - a > 0) if (line->len - a > 0)
fwrite(line->dat + a, line->len - a, 1, stdout); fwrite(line->dat + a, line->len - a, 1, stdout);
putchar('\n'); putchar('\n');
} }
} else { } else {
fwrite(line->dat, line->len, 1, stdout); fwrite(line->dat, line->len, 1, stdout);
putchar('\n'); putchar(fileeol);
cemUnsubmitted
Not Done
Inline Actions

Hm, should the nul input separater really be used for outputting matched lines?

And if so, shouldn't it also be used with oflag above?

cem: Hm, should the nul input separater really be used for outputting matched lines? And if so…
kevansAuthorUnsubmitted
Not Done
Inline Actions

So, it depends. If we're supposed to be printing the matched lines, we need to do so faithful to the input file -- i.e., this line, and actually line 491 that I missed (!oflag, but color). Everything else is printing excerpts and should use the standard grep newline separator.

kevans: So, it depends. If we're supposed to be printing the matched lines, we need to do so faithful…
} }
} }