wow some
Hey friend, Have you heard about that really wow some stuff? You won't regret, believe me, read more here http://maria.dreambitches.org/2a2b Sent from my iPhone, devesas.campos ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h
David_A_Bright_DELL.com added a comment. Just a couple style nits. INLINE COMMENTS > if_var.h:407 > EVENTHANDLER_DECLARE(ifnet_link_event, ifnet_link_event_handler_t); > +/* Interface up/ifdown event */ > +#define IFNET_EVENT_UP 0 I would stick with the previous "ifup/ifdown" or go with "Interface up/down". I think "Interface up/ifdown" reads poorly. > if_var.h:408 > +/* Interface up/ifdown event */ > +#define IFNET_EVENT_UP 0 > +#define IFNET_EVENT_DOWN 1 It would be nice to have the 0/1 values for these two defines line up. In any case, it definitely seems like there is extraneous whitespace between "IFNET_EVENT_UP" and "0". REVISION DETAIL https://reviews.freebsd.org/D9345 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: decui_microsoft.com, hselasky, sepherosa_gmail.com, cem, np, kmacy, kib, honzhan_microsoft.com, howard0su_gmail.com, jhb, ae, delphij, royger, glebius, gnn, rwatson Cc: David_A_Bright_DELL.com, freebsd-net-list ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h
decui_microsoft.com added inline comments. INLINE COMMENTS > David_A_Bright_DELL.com wrote in if_var.h:407 > I would stick with the previous "ifup/ifdown" or go with "Interface up/down". > I think "Interface up/ifdown" reads poorly. I was trying to keep the consistency with Line 392, 395, 401 and 404. I would tend to leave the patch as it is, if you won't strongly object to it. :-) > David_A_Bright_DELL.com wrote in if_var.h:408 > It would be nice to have the 0/1 values for these two defines line up. In any > case, it definitely seems like there is extraneous whitespace between > "IFNET_EVENT_UP" and "0". Actually the 2 lines do line up. The visual confusion is due to the nasty Tab issue in the case of a patch. :-) With "set list" in my Vim, the lines of the file net/if_var.h (rather than the patch with a leading + at the beginning of the lines) shows #define IFNET_EVENT_UP^I^I0$ #define IFNET_EVENT_DOWN^I1$ ^I means a Tab. $ means a CR-LF. REVISION DETAIL https://reviews.freebsd.org/D9345 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: decui_microsoft.com, hselasky, sepherosa_gmail.com, cem, np, kmacy, kib, honzhan_microsoft.com, howard0su_gmail.com, jhb, ae, delphij, royger, glebius, gnn, rwatson Cc: David_A_Bright_DELL.com, freebsd-net-list ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h
David_A_Bright_DELL.com accepted this revision. David_A_Bright_DELL.com added a reviewer: David_A_Bright_DELL.com. David_A_Bright_DELL.com added inline comments. This revision has a positive review. INLINE COMMENTS > decui_microsoft.com wrote in if_var.h:407 > I was trying to keep the consistency with Line 392, 395, 401 and 404. > I would tend to leave the patch as it is, if you won't strongly object to it. > :-) No objection to "Interface ..." but then I'd use "Interface up/down event" (the "if" in "ifdown" meaning "interface" is redundant). But, then, this is a nit. I don't strongly object to the patch as-is. > decui_microsoft.com wrote in if_var.h:408 > Actually the 2 lines do line up. > The visual confusion is due to the nasty Tab issue in the case of a patch. :-) > > With "set list" in my Vim, the lines of the file net/if_var.h (rather than > the patch with a leading + at the beginning of the lines) shows > > #define IFNET_EVENT_UP^I^I0$ > #define IFNET_EVENT_DOWN^I1$ > > ^I means a Tab. > $ means a CR-LF. Hmmm, you are right; Phabricator is deceiving me. They don't line up at all in the diff display it shows me, but you are right that they do in code. Sorry about that. (Just a note that style(9) says to use just a single tab between name and value, which would mean they wouldn't line up. See similar situation at lines 185-186.) REVISION DETAIL https://reviews.freebsd.org/D9345 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: decui_microsoft.com, hselasky, sepherosa_gmail.com, cem, np, kmacy, kib, honzhan_microsoft.com, howard0su_gmail.com, jhb, ae, delphij, royger, glebius, gnn, rwatson, David_A_Bright_DELL.com Cc: David_A_Bright_DELL.com, freebsd-net-list ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h
decui_microsoft.com added inline comments. INLINE COMMENTS > David_A_Bright_DELL.com wrote in if_var.h:407 > No objection to "Interface ..." but then I'd use "Interface up/down event" > (the "if" in "ifdown" meaning "interface" is redundant). > > But, then, this is a nit. I don't strongly object to the patch as-is. Oh... Sorry, my bad! I failed to understand what you meant -- it's late at night here and obviously my eyes or brain didn't work very good :-) REVISION DETAIL https://reviews.freebsd.org/D9345 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: decui_microsoft.com, hselasky, sepherosa_gmail.com, cem, np, kmacy, kib, honzhan_microsoft.com, howard0su_gmail.com, jhb, ae, delphij, royger, glebius, gnn, rwatson, David_A_Bright_DELL.com Cc: David_A_Bright_DELL.com, freebsd-net-list ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h
decui_microsoft.com updated this revision to Diff 24479. decui_microsoft.com added a comment. This revision now requires review to proceed. fixed the comment typo pointed out by David. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D9345?vs=24465&id=24479 REVISION DETAIL https://reviews.freebsd.org/D9345 AFFECTED FILES sys/net/if.c sys/net/if_var.h sys/sys/eventhandler.h EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: decui_microsoft.com, hselasky, sepherosa_gmail.com, cem, np, kmacy, kib, honzhan_microsoft.com, howard0su_gmail.com, jhb, ae, delphij, royger, glebius, gnn, rwatson, David_A_Bright_DELL.com Cc: David_A_Bright_DELL.com, freebsd-net-list diff --git a/sys/sys/eventhandler.h b/sys/sys/eventhandler.h --- a/sys/sys/eventhandler.h +++ b/sys/sys/eventhandler.h @@ -284,11 +284,4 @@ EVENTHANDLER_DECLARE(swapon, swapon_fn); EVENTHANDLER_DECLARE(swapoff, swapoff_fn); -/* ifup/ifdown events */ -#define IFNET_EVENT_UP 0 -#define IFNET_EVENT_DOWN 1 -struct ifnet; -typedef void (*ifnet_event_fn)(void *, struct ifnet *ifp, int event); -EVENTHANDLER_DECLARE(ifnet_event, ifnet_event_fn); - #endif /* _SYS_EVENTHANDLER_H_ */ diff --git a/sys/net/if_var.h b/sys/net/if_var.h --- a/sys/net/if_var.h +++ b/sys/net/if_var.h @@ -404,6 +404,11 @@ /* Interface link state change event */ typedef void (*ifnet_link_event_handler_t)(void *, struct ifnet *, int); EVENTHANDLER_DECLARE(ifnet_link_event, ifnet_link_event_handler_t); +/* Interface up/down event */ +#define IFNET_EVENT_UP 0 +#define IFNET_EVENT_DOWN 1 +typedef void (*ifnet_event_fn)(void *, struct ifnet *ifp, int event); +EVENTHANDLER_DECLARE(ifnet_event, ifnet_event_fn); #endif /* _SYS_EVENTHANDLER_H_ */ /* diff --git a/sys/net/if.c b/sys/net/if.c --- a/sys/net/if.c +++ b/sys/net/if.c @@ -59,7 +59,6 @@ #include #include #include -#include #include #include ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ifmedia status callback is non-sleepable
Hello, I'd like to double-check that it is intended/known limitation on ifmedia status callback to be non-sleepable. The limitation is imposed by usage of the ifmedia ioctl to get status from lacp/lagg code on port creation (it holds non-sleepable rm_wlock). Backtrace of the corresponding panic: Sleeping thread (tid 100578, pid 10653) owns a non-sleepable lock KDB: stack backtrace of thread 100578: #0 0x80ae46e2 at mi_switch+0xd2 #1 0x80b31e6a at sleepq_wait+0x3a #2 0x80ae34e2 at _sx_xlock_hard+0x592 #3 0x8222fd7e at sfxge_media_status+0x2e #4 0x80be7b90 at ifmedia_ioctl+0x170 #5 0x8222c3d0 at sfxge_if_ioctl+0x1f0 #6 0x82277fbe at lagg_port_ioctl+0xde #7 0x82278f9b at lacp_linkstate+0x4b #8 0x822794c2 at lacp_port_create+0x1e2 #9 0x82276a73 at lagg_ioctl+0x1243 #10 0x80bdcbec at ifioctl+0xfbc #11 0x80b41ab4 at kern_ioctl+0x2d4 #12 0x80b41771 at sys_ioctl+0x171 #13 0x80fa16ae at amd64_syscall+0x4ce #14 0x80f8442b at Xfast_syscall+0xfb panic: sleeping thread cpuid = 23 KDB: stack backtrace: #0 0x80b24077 at kdb_backtrace+0x67 #1 0x80ad93e2 at vpanic+0x182 #2 0x80ad9253 at panic+0x43 #3 0x80b39a99 at propagate_priority+0x299 #4 0x80b3a59f at turnstile_wait+0x3ef #5 0x80ab493d at __mtx_lock_sleep+0x13d #6 0x80ad39f2 at _rm_wlock+0xb2 #7 0x82275479 at lagg_port_setlladdr+0x29 #8 0x80b363ca at taskqueue_run_locked+0x14a #9 0x80b361bf at taskqueue_run+0xbf #10 0x80a9340f at intr_event_execute_handlers+0x20f #11 0x80a93676 at ithread_loop+0xc6 #12 0x80a90055 at fork_exit+0x85 #13 0x80f8467e at fork_trampoline+0xe I think vnic driver has the problem as well since it grabs sx_lock from ifmedia status callback. Andrew. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 216304] Adding xn0 to bridge0 causes kernel panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216304 nv...@gmx.com changed: What|Removed |Added CC||nv...@gmx.com --- Comment #5 from nv...@gmx.com --- Hi, I am getting something similar and I am not sure whether it's related. > panic: _mtx_lock_sleep: recursed on non-recursive mutex if_bridge @ > /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2117 > > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00954a3260 > vpanic() at vpanic+0x186/frame 0xfe00954a32e0 > kassert_panic() at kassert_panic+0x126/frame 0xfe00954a3350 > __mtx_lock_sleep() at __mtx_lock_sleep+0x3e2/frame 0xfe00954a33d0 > __mtx_lock_flags() at __mtx_lock_flags+0x116/frame 0xfe00954a3430 > bridge_transmit() at bridge_transmit+0x61/frame 0xfe00954a3470 > ether_output() at ether_output+0x703/frame 0xfe00954a3510 > arprequest() at arprequest+0x413/frame 0xfe00954a3620 > arp_ifinit() at arp_ifinit+0x56/frame 0xfe00954a3660 > arp_handle_ifllchange() at arp_handle_ifllchange+0x3d/frame 0xfe00954a3680 > bridge_ioctl_add() at bridge_ioctl_add+0x3b4/frame 0xfe00954a36d0 > bridge_ioctl() at bridge_ioctl+0x29f/frame 0xfe00954a3770 > ifioctl() at ifioctl+0xbc8/frame 0xfe00954a37f0 > kern_ioctl() at kern_ioctl+0x2b0/frame 0xfe00954a3850 > sys_ioctl() at sys_ioctl+0x13f/frame 0xfe00954a3930 > amd64_syscall() at amd64_syscall+0x2f9/frame 0xfe00954a3ab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00954a3ab0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800fd5aaa, rsp = > 0x7fffe1f8, rbp = 0x7fffe2a0 --- > KDB: enter: panic > [ thread pid 770 tid 100560 ] > Stopped at kdb_enter+0x3b: movq$0,kdb_why -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 216304] Adding xn0 to bridge0 causes kernel panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216304 --- Comment #6 from Kristof Provost --- (In reply to nvass from comment #5) That looks like a different problem. Can you file a new bug with the backtrace and a description of how you reproduce this? Please cc me on it. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 216304] Adding xn0 to bridge0 causes kernel panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216304 --- Comment #7 from nv...@gmx.com --- Thanks for the quick reply! https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216510 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h
glebius accepted this revision. This revision has a positive review. REVISION DETAIL https://reviews.freebsd.org/D9345 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: decui_microsoft.com, hselasky, sepherosa_gmail.com, cem, np, kmacy, kib, honzhan_microsoft.com, howard0su_gmail.com, jhb, ae, delphij, royger, gnn, rwatson, David_A_Bright_DELL.com, glebius Cc: David_A_Bright_DELL.com, freebsd-net-list ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ifmedia status callback is non-sleepable
I think it's a bad idea in general for the kernel to be holding non-sleepable locks around driver ioctls. Regards, Navdeep On Thu, Jan 26, 2017 at 9:19 AM, Andrew Rybchenko wrote: > Hello, > > I'd like to double-check that it is intended/known limitation on ifmedia > status callback to be non-sleepable. > The limitation is imposed by usage of the ifmedia ioctl to get status from > lacp/lagg code on port creation (it holds non-sleepable rm_wlock). > > Backtrace of the corresponding panic: > > Sleeping thread (tid 100578, pid 10653) owns a non-sleepable lock > KDB: stack backtrace of thread 100578: > #0 0x80ae46e2 at mi_switch+0xd2 > #1 0x80b31e6a at sleepq_wait+0x3a > #2 0x80ae34e2 at _sx_xlock_hard+0x592 > #3 0x8222fd7e at sfxge_media_status+0x2e > #4 0x80be7b90 at ifmedia_ioctl+0x170 > #5 0x8222c3d0 at sfxge_if_ioctl+0x1f0 > #6 0x82277fbe at lagg_port_ioctl+0xde > #7 0x82278f9b at lacp_linkstate+0x4b > #8 0x822794c2 at lacp_port_create+0x1e2 > #9 0x82276a73 at lagg_ioctl+0x1243 > #10 0x80bdcbec at ifioctl+0xfbc > #11 0x80b41ab4 at kern_ioctl+0x2d4 > #12 0x80b41771 at sys_ioctl+0x171 > #13 0x80fa16ae at amd64_syscall+0x4ce > #14 0x80f8442b at Xfast_syscall+0xfb > panic: sleeping thread > cpuid = 23 > KDB: stack backtrace: > #0 0x80b24077 at kdb_backtrace+0x67 > #1 0x80ad93e2 at vpanic+0x182 > #2 0x80ad9253 at panic+0x43 > #3 0x80b39a99 at propagate_priority+0x299 > #4 0x80b3a59f at turnstile_wait+0x3ef > #5 0x80ab493d at __mtx_lock_sleep+0x13d > #6 0x80ad39f2 at _rm_wlock+0xb2 > #7 0x82275479 at lagg_port_setlladdr+0x29 > #8 0x80b363ca at taskqueue_run_locked+0x14a > #9 0x80b361bf at taskqueue_run+0xbf > #10 0x80a9340f at intr_event_execute_handlers+0x20f > #11 0x80a93676 at ithread_loop+0xc6 > #12 0x80a90055 at fork_exit+0x85 > #13 0x80f8467e at fork_trampoline+0xe > > I think vnic driver has the problem as well since it grabs sx_lock from > ifmedia status callback. > > Andrew. > ___ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
listening sockets as non sockets
Hi guys,
as some of you already heard, I'm trying to separate listening sockets
into a new file descriptor type. If we look into current struct socket,
we see that some functional fields belong to normal data flow sockets,
and other belong to listening socket. They are never used simultaneously.
Now, if we look at socket API, we see that once a socket underwent
transformation
to a listening socket, only 3 regular syscalls now may be called: listen(2),
accept(2) and close(2) and a subset of ioctl() and setsockopt() parameters is
accepted. A listening socket cannot be closed from the protocol side, only from
user side. So, listening socket is so different from a dataflow socket, that
separating them looks architecturally right thing to do.
The benefits are:
1) Nicer code (I hope).
2) Smaller 'struct socket'.
3) Having two different locks for socket and solisten, we can try to get rid
of ACCEPT_LOCK global lock.
The patch is in a very pre-alpha state. It has been run only in my bhyve VM.
It passes regression tests from tools/regression/sockets and tests/sys,
including the race tests, and including accept filter ones.
For TCP it passes basic functionality testing, but likely there are still races
remaining after ACCEPT_LOCK removal.
For SCTP the patch is unfinished yet. The tricky thing with SCTP is that it
can un-listen a listening socket back to normal socket, doing listen(fd, 0)
on it. My patch has API for that I started working on SCTP, but temporarily
put this problem aside. It looks solvable, but I don't know yet how to test
it. Better first see results with TCP.
I've put current snapshot to Phab, so that you can view it there. The snap
patch is also attached to this email.
https://reviews.freebsd.org/D9356
At this moment I'd like to start doing some testing (and doing polishing
in parallel), and here I seek for your help. Those, who run FreeBSD at
very high connection rates and observe contention on the accept global
mutex, anybody willing to collaborate with me on this?
--
Totus tuus, Glebius.
Index: sys/kern/kern_sendfile.c
===
--- sys/kern/kern_sendfile.c (revision 312784)
+++ sys/kern/kern_sendfile.c (working copy)
@@ -510,7 +510,7 @@ sendfile_getsock(struct thread *td, int s, struct
* The socket must be a stream socket and connected.
*/
error = getsock_cap(td, s, cap_rights_init(&rights, CAP_SEND),
- sock_fp, NULL, NULL);
+ sock_fp, NULL, NULL, DTYPE_SOCKET);
if (error != 0)
return (error);
*so = (*sock_fp)->f_data;
Index: sys/kern/sys_socket.c
===
--- sys/kern/sys_socket.c (revision 312784)
+++ sys/kern/sys_socket.c (working copy)
@@ -115,6 +115,28 @@ struct fileops socketops = {
.fo_flags = DFLAG_PASSABLE
};
+static fo_rdwr_t notconn_readwrite;
+static fo_ioctl_t sol_ioctl;
+static fo_poll_t sol_poll;
+extern fo_kqfilter_t sol_kqfilter;
+static fo_stat_t sol_stat;
+static fo_close_t sol_close;
+
+struct fileops solistenops = {
+ .fo_read = notconn_readwrite,
+ .fo_write = notconn_readwrite,
+ .fo_truncate = invfo_truncate,
+ .fo_ioctl = sol_ioctl,
+ .fo_poll = sol_poll,
+ .fo_kqfilter = sol_kqfilter,
+ .fo_stat = sol_stat, /* XXXGL: to do? */
+ .fo_close = sol_close,
+ .fo_chmod = invfo_chmod,
+ .fo_chown = invfo_chown,
+ .fo_sendfile = invfo_sendfile,
+ .fo_flags = DFLAG_PASSABLE
+};
+
static int
soo_read(struct file *fp, struct uio *uio, struct ucred *active_cred,
int flags, struct thread *td)
@@ -153,6 +175,14 @@ soo_write(struct file *fp, struct uio *uio, struct
}
static int
+notconn_readwrite(struct file *fp, struct uio *uio, struct ucred *active_cred,
+int flags, struct thread *td)
+{
+
+ return (ENOTCONN);
+}
+
+static int
soo_ioctl(struct file *fp, u_long cmd, void *data, struct ucred *active_cred,
struct thread *td)
{
@@ -262,6 +292,61 @@ soo_ioctl(struct file *fp, u_long cmd, void *data,
}
static int
+sol_ioctl(struct file *fp, u_long cmd, void *data, struct ucred *active_cred,
+struct thread *td)
+{
+ struct solisten *sol = fp->f_data;
+ int error = 0;
+
+ switch (cmd) {
+ case FIONBIO:
+ SOLISTEN_LOCK(sol);
+ if (*(int *)data)
+ sol->sol_state |= SS_NBIO;
+ else
+ sol->sol_state &= ~SS_NBIO;
+ SOLISTEN_UNLOCK(sol);
+ break;
+
+ case FIOASYNC:
+ SOLISTEN_LOCK(sol);
+ /* To be copied to child sockets. */
+ if (*(int *)data)
+ sol->sol_state |= SS_ASYNC;
+ else
+ sol->sol_state &= ~SS_ASYNC;
+ SOLISTEN_UNLOCK(sol);
+ break;
+
+ case FIOSETOWN:
+ error = fsetown(*(int *)data, &sol->sol_sigio);
+ break;
+
+ case FIOGETOWN:
+ *(int *)data = fgetown(&sol->sol_sigio);
+ break;
+
+ case SIOCSPGRP:
+ error = fsetown(-(*(int *)data), &sol->sol_sigio);
+ break;
+
+ case SIOCGPGRP:
+ *(int *)data = -fgetown(&sol->sol_sigio);
+ break;
+
+ case FIONREAD:
+ case FIONWRITE:
+ case FIONSPACE:
+ case SIOCATMARK:
+ /* XXXGL: find a better error code for these. ENOBUFS? */
+
Re: listening sockets as non sockets
On Thu, Jan 26, 2017 at 04:52:51PM -0800, Gleb Smirnoff wrote: > Hi guys, > > as some of you already heard, I'm trying to separate listening sockets > into a new file descriptor type. If we look into current struct socket, > we see that some functional fields belong to normal data flow sockets, > and other belong to listening socket. They are never used simultaneously. > Now, if we look at socket API, we see that once a socket underwent > transformation > to a listening socket, only 3 regular syscalls now may be called: listen(2), > accept(2) and close(2) and a subset of ioctl() and setsockopt() parameters is > accepted. A listening socket cannot be closed from the protocol side, only > from > user side. So, listening socket is so different from a dataflow socket, that > separating them looks architecturally right thing to do. > > The benefits are: > > 1) Nicer code (I hope). > 2) Smaller 'struct socket'. > 3) Having two different locks for socket and solisten, we can try to get rid >of ACCEPT_LOCK global lock. > > The patch is in a very pre-alpha state. It has been run only in my bhyve VM. > > It passes regression tests from tools/regression/sockets and tests/sys, > including the race tests, and including accept filter ones. I haven't yet looked much at the diff, so sorry in advance if this question is inappropriate. One problem I've fought a couple of times (with Infiniband SDP and unix sockets) is a race between accept(2) and a concurrent close of the listening socket. Right now, this problem has to be handled in the domain-specific code (see r303855 for instance), and it's generally awkward to do so. Does your work address this intrinsic race in any way? FWIW, I have a basic test case for unix sockets here, though I believe it's been incorporated into stress2: https://people.freebsd.org/~markj/unix_socket_detach.c > > For TCP it passes basic functionality testing, but likely there are still > races > remaining after ACCEPT_LOCK removal. > > For SCTP the patch is unfinished yet. The tricky thing with SCTP is that it > can un-listen a listening socket back to normal socket, doing listen(fd, 0) > on it. My patch has API for that I started working on SCTP, but temporarily > put this problem aside. It looks solvable, but I don't know yet how to test > it. Better first see results with TCP. > > I've put current snapshot to Phab, so that you can view it there. The snap > patch is also attached to this email. > > https://reviews.freebsd.org/D9356 > > At this moment I'd like to start doing some testing (and doing polishing > in parallel), and here I seek for your help. Those, who run FreeBSD at > very high connection rates and observe contention on the accept global > mutex, anybody willing to collaborate with me on this? ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h
sepherosa_gmail.com accepted this revision. REVISION DETAIL https://reviews.freebsd.org/D9345 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: decui_microsoft.com, hselasky, cem, np, kmacy, kib, honzhan_microsoft.com, howard0su_gmail.com, jhb, ae, delphij, royger, gnn, rwatson, David_A_Bright_DELL.com, glebius, sepherosa_gmail.com Cc: David_A_Bright_DELL.com, freebsd-net-list ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: listening sockets as non sockets
On Thu, Jan 26, 2017 at 05:41:17PM -0800, Mark Johnston wrote: M> > It passes regression tests from tools/regression/sockets and tests/sys, M> > including the race tests, and including accept filter ones. M> M> I haven't yet looked much at the diff, so sorry in advance if this M> question is inappropriate. M> M> One problem I've fought a couple of times (with Infiniband SDP and unix M> sockets) is a race between accept(2) and a concurrent close of the M> listening socket. Right now, this problem has to be handled in the M> domain-specific code (see r303855 for instance), and it's generally M> awkward to do so. Does your work address this intrinsic race in any way? M> M> FWIW, I have a basic test case for unix sockets here, though I believe M> it's been incorporated into stress2: M> https://people.freebsd.org/~markj/unix_socket_detach.c This is strees2/misc/unix_socket_detach.sh, isn't it? My patch survived running it during night. I have also looked at r303855 and its code isn't touched by my patch. I will look further if the problem can be solved in general at socket layer. Thanks for point. -- Totus tuus, Glebius. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: listening sockets as non sockets
On Thu, Jan 26, 2017 at 08:15:57PM -0800, Gleb Smirnoff wrote: > On Thu, Jan 26, 2017 at 05:41:17PM -0800, Mark Johnston wrote: > M> > It passes regression tests from tools/regression/sockets and tests/sys, > M> > including the race tests, and including accept filter ones. > M> > M> I haven't yet looked much at the diff, so sorry in advance if this > M> question is inappropriate. > M> > M> One problem I've fought a couple of times (with Infiniband SDP and unix > M> sockets) is a race between accept(2) and a concurrent close of the > M> listening socket. Right now, this problem has to be handled in the > M> domain-specific code (see r303855 for instance), and it's generally > M> awkward to do so. Does your work address this intrinsic race in any way? > M> > M> FWIW, I have a basic test case for unix sockets here, though I believe > M> it's been incorporated into stress2: > M> https://people.freebsd.org/~markj/unix_socket_detach.c > > This is strees2/misc/unix_socket_detach.sh, isn't it? Yep. unix_socket_detach2.sh too. > My patch survived > running it during night. I have also looked at r303855 and its code isn't > touched by my patch. I will look further if the problem can be solved > in general at socket layer. Thanks for point. Thanks for looking! ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 183148] [patch] add getaddrinfo(1) tool from NetBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183148 --- Comment #4 from Lohith Bellad --- Adopted the patch to FreeBSD. Made little change to getaddrinfo Makefile based on new LIBADD framework. getaddrinfo utility is working as expected on FreeBSD Head. Thanks, Lohith -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 216460] 82599ES 10-Gigabit SFI/SFP+ Network Connection link constantly flaps
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216460 Mark Linimon changed: What|Removed |Added Summary|82599ES 10-Gigabit SFI/SFP+ |82599ES 10-Gigabit SFI/SFP+ |Network Connection link |Network Connection link |constantly falps|constantly flaps CC|freebsd-am...@freebsd.org | Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org Keywords||IntelNetworking -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
