networkUmbrella
ActivePublic

Recent Activity

Sat, Nov 18

rockyhotas_post.com added a comment to D10600: Revision of LDAP section of the FreeBSD Handbook.

In general, we are getting better and better. Please keep up with that, it is much appreciated!

I do think we need to make the writing a bit more formal. Previous writing was always more formal (not restricted/limited to the ldap section) which makes the handbook more coherent. I'll graw the raw diff and look into that a bit more because that might be easier to read(for me). Phabricator mixes up a bit of the comments and rewrites and places them on the wrong lines for me. I'll get back to you as soon as time permits (hopefully this weekend or early next week).

Sat, Nov 18, 2:02 PM · Doc Committers, network
remko added a comment to D10600: Revision of LDAP section of the FreeBSD Handbook.

In general, we are getting better and better. Please keep up with that, it is much appreciated!

Sat, Nov 18, 12:56 PM · Doc Committers, network
rockyhotas_post.com updated the diff for D10600: Revision of LDAP section of the FreeBSD Handbook.

@remko Thank you for your suggestions.
This is a new diff, which is now based on the last revision of the chapter (50922). This even includes some final modifications I had made before uploading the diff in the bug report, where I had already fixed some typos/errors/bad phrases.
I followed all your advices, except two:

Sat, Nov 18, 12:44 PM · Doc Committers, network

Fri, Nov 17

remko added a comment to D10600: Revision of LDAP section of the FreeBSD Handbook.

More updates :) please look into them and poke me whenever I can assist you :)

Fri, Nov 17, 8:46 PM · Doc Committers, network
remko added inline comments to D10600: Revision of LDAP section of the FreeBSD Handbook.
Fri, Nov 17, 7:17 PM · Doc Committers, network
sevan edited reviewers for D10600: Revision of LDAP section of the FreeBSD Handbook, added: Doc Committers; removed: bjk, brd, bcr.
Fri, Nov 17, 7:08 PM · Doc Committers, network
rstone added inline comments to D12101: swfw_sync DELAY -> sleep conversion.
Fri, Nov 17, 2:37 PM · network

Mon, Nov 13

vangyzen added a comment to D12101: swfw_sync DELAY -> sleep conversion.

When running head at r325049, my home firewall would often hit an LOR in iflib_timer() when it jumped to the hung label. This happened twice a day.

Mon, Nov 13, 2:21 AM · network

Tue, Oct 31

gallatin added a comment to D12101: swfw_sync DELAY -> sleep conversion.

I think you'll get a lot less pushback if you serialize the multicast stuff in the stack, rather than the driver framework. This will allow you to put warnings / asserts into all the ioctl entry points above the drivers, so as to lock in the "you can't hold a lock while calling into a driver" rule.

Tue, Oct 31, 3:47 PM · network
pawel.biernacki-gmail.com added a comment to D9649: Enable VNET operations for ifconfig and route.

OK, let me take a look at creating some in-kernel interface for this.

Tue, Oct 31, 11:36 AM · network
allanjude added a comment to D9649: Enable VNET operations for ifconfig and route.

I think an interface like mjg described is the best approach.

Tue, Oct 31, 11:21 AM · network
pawel.biernacki-gmail.com added a comment to D9649: Enable VNET operations for ifconfig and route.

I don't know if I understand. jexec uses exactly the same syscall, jail_attach to achieve the same effect. Putting ifconfig and route inside a jail allows even more actions to be taken by the in-jail admin.
Also, there is no obvious other way to achieve this with current interfaces.
I see two other options: additional interface to manage jails and vnet without attaching process to the jail, or finding a way to avoid duplicated interface names but adding some sort of unique id(?).

Tue, Oct 31, 11:19 AM · network
allanjude requested changes to D9649: Enable VNET operations for ifconfig and route.

jail_attach() is not the correct approach, because it makes the actions of the administrator on the host visible within the jail.

Tue, Oct 31, 11:08 AM · network
robak added a reviewer for D9649: Enable VNET operations for ifconfig and route: mjg.
Tue, Oct 31, 11:04 AM · network
hselasky added a comment to D12101: swfw_sync DELAY -> sleep conversion.

../dev/usb/usb_util.c:usb_pause_mtx(struct mtx *mtx, int timo)

Tue, Oct 31, 7:39 AM · network
hselasky added inline comments to D12101: swfw_sync DELAY -> sleep conversion.
Tue, Oct 31, 7:39 AM · network
hselasky added inline comments to D12101: swfw_sync DELAY -> sleep conversion.
Tue, Oct 31, 7:36 AM · network
hselasky added inline comments to D12101: swfw_sync DELAY -> sleep conversion.
Tue, Oct 31, 7:36 AM · network
kmacy added a comment to D12101: swfw_sync DELAY -> sleep conversion.

So let me try to sum up in my own words what's going on here:

  1. We want to be able to sleep when talking to the hardware, rather than poll
  2. We want to change the driver lock from a mutex to an sx lock to allow sleeping when talking to h/w
  3. We can't just change to an SX lock and be done because the multicast code holds a mutex (and maybe an RW lock) when calling ifioctl
  4. We noticed that the multicast code does not check return values from driver ioctls, so it seems safe to defer it into another context
  5. We decided to defer mutlicast (and promisc, since it can be coming from the multicast code) into another context at the iflib level

    While, obviously the best solution would be to refactor the multicast code to avoid holding a lock, I think that I generally agree with the approach, and think it is very clever.

    However, if we're going to defer the mutlicast code into another context, can we please consider *NOT* doing it at the iflib level? I'm thinking we could re-work this hack so this works for all drivers if we made an mcast kproc and submitted mutlicast add/del requests to a global mcast work queue. Then the deferred multicast kproc can call down into drivers with no locks held. Then we assert no locks in the ifioctl entry points.
Tue, Oct 31, 4:40 AM · network

Sun, Oct 29

robak added a comment to D9649: Enable VNET operations for ifconfig and route.

Guys, since there was a discussion over how the patch does what it does, can I get one more approval before I commit this, Just In Case™?

Sun, Oct 29, 6:54 PM · network
jamie accepted D9649: Enable VNET operations for ifconfig and route.
Sun, Oct 29, 2:54 PM · network

Sat, Oct 28

pawel.biernacki-gmail.com updated the diff for D9649: Enable VNET operations for ifconfig and route.

Address comments and sync with r325058.

Sat, Oct 28, 7:32 PM · network

Fri, Oct 27

jamie added a comment to D9649: Enable VNET operations for ifconfig and route.

I'm good with it - I was just waiting for suggested changed to make it in.

Fri, Oct 27, 2:47 PM · network
robak added a comment to D9649: Enable VNET operations for ifconfig and route.

Any update on that? Should it be accepted or rejected?

Fri, Oct 27, 12:19 PM · network

Mon, Oct 23

gallatin added a comment to D12101: swfw_sync DELAY -> sleep conversion.

So let me try to sum up in my own words what's going on here:

Mon, Oct 23, 3:40 PM · network

Sep 29 2017

D3133: Fixes on Bridge+CARP crashes/freezes now requires changes to proceed.
Sep 29 2017, 7:39 AM · network

Sep 26 2017

eugen_grosbein.net added a comment to D12086: ng_ether should notify lower and orphan nodes when underlying interface link layer address is changed.
In D12086#258234, @mav wrote:

Do you think the case when lower and orphan hooks are connected to the same node is realistic enough to make this code so tangled?

Sep 26 2017, 11:52 AM · network
eugen_grosbein.net added a comment to D12086: ng_ether should notify lower and orphan nodes when underlying interface link layer address is changed.
In D12086#258234, @mav wrote:

While I understand your valid motivation, I can't say that I very much like this in patch for several reasons:

  • NGM_ETHER_SET_ENADDR is a control command supposed to be targeted to ng_ether node, not from it, and it is a action request, not notification.
Sep 26 2017, 11:44 AM · network
eugen_grosbein.net updated the diff for D12086: ng_ether should notify lower and orphan nodes when underlying interface link layer address is changed.

Expand a comment explaining code.

Sep 26 2017, 11:42 AM · network

Sep 22 2017

mav added a comment to D12086: ng_ether should notify lower and orphan nodes when underlying interface link layer address is changed.

PS: Read how to create patches with context for the phabricator. May be it is a problem of phabricator and it modified the diff after you, if I download the raw diff here, there is no even normal diff -p context, which is almost always useful.

Sep 22 2017, 11:58 AM · network
mav added a comment to D12086: ng_ether should notify lower and orphan nodes when underlying interface link layer address is changed.

While I understand your valid motivation, I can't say that I very much like this in patch for several reasons:

  • NGM_ETHER_SET_ENADDR is a control command supposed to be targeted to ng_ether node, not from it, and it is a action request, not notification. I suppose if you connect two ng_ether nodes with lower hooks to create poor mans bridge, this won't work as expected.
  • ng_pppoe has method to explicitly set MAC address, and it may get overwritten by this, which may or may not be correct.
  • We just fought one locking issue, and here I don't see any hook locks or even references (I understand that your problem is narrower, but still).
Sep 22 2017, 11:53 AM · network
eugen_grosbein.net edited reviewers for D12086: ng_ether should notify lower and orphan nodes when underlying interface link layer address is changed, added: avg, mav; removed: glebius, ae, network.
Sep 22 2017, 11:16 AM · network

Sep 5 2017

shurd updated the diff for D12101: swfw_sync DELAY -> sleep conversion.

Remove extra directory adds

Sep 5 2017, 11:25 PM · network
shurd added a comment to D12101: swfw_sync DELAY -> sleep conversion.

Not sure where those head/* directories came from...

Sep 5 2017, 11:19 PM · network

Sep 4 2017

shurd updated the diff for D12101: swfw_sync DELAY -> sleep conversion.

Update my tree before updating revision

Sep 4 2017, 10:58 PM · network
shurd updated the diff for D12101: swfw_sync DELAY -> sleep conversion.

incorporate some missing changes from dev branch

Sep 4 2017, 10:45 PM · network
shurd reopened D12101: swfw_sync DELAY -> sleep conversion.

Commit was reverted

Sep 4 2017, 10:45 PM · network

Aug 30 2017

sbruno closed D12101: swfw_sync DELAY -> sleep conversion by committing rS323008: Continuation of lock cleanup in e1000..
Aug 30 2017, 12:20 AM · network

Aug 29 2017

sbruno accepted D12101: swfw_sync DELAY -> sleep conversion.
Aug 29 2017, 10:30 PM · network

Aug 26 2017

kmacy added a comment to D12101: swfw_sync DELAY -> sleep conversion.

Huh .... Testing this review by itself this morning. I see the following startup panic:

Sleeping on "e1000_delay" with the following non-sleepable locks held:
exclusive sleep mutex em2:tx(0):callo (em2:tx(0):callo) r = 0 (0xfffff80004175068) locked @ /home/sbruno/bsd/fbsd_head/sys/kern/kern_mutex.c:182
stack backtrace:
#0 0xffffffff80ac85d3 at witness_debugger+0x73
#1 0xffffffff80ac99cf at witness_warn+0x43f
#2 0xffffffff80a708fc at _sleep+0x6c
#3 0xffffffff80a71117 at pause_sbt+0x117
#4 0xffffffff805620e1 at e1000_read_phy_reg_mdic+0xf1
#5 0xffffffff80562b5b at e1000_read_phy_reg_igp+0x5b
#6 0xffffffff80535d6c at em_if_timer+0xcc
#7 0xffffffff80b76279 at iflib_timer+0x69
#8 0xffffffff80a7e375 at softclock_call_cc+0x155
#9 0xffffffff80a7e75c at softclock+0x7c
#10 0xffffffff80a2bed1 at intr_event_execute_handlers+0x91
#11 0xffffffff80a2c5d6 at ithread_loop+0xb6
#12 0xffffffff80a29304 at fork_exit+0x84
#13 0xffffffff80ecf7ce at fork_trampoline+0xe
panic: sleepq_add: td 0xfffff80003d59000 to sleep on wchan 0xffffffff81c7d260 with sleeping prohibited
cpuid = 0
time = 4
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00f55f4730
vpanic() at vpanic+0x19c/frame 0xfffffe00f55f47b0
kassert_panic() at kassert_panic+0x126/frame 0xfffffe00f55f4820
sleepq_add() at sleepq_add+0x34f/frame 0xfffffe00f55f4870
_sleep() at _sleep+0x26c/frame 0xfffffe00f55f4910
pause_sbt() at pause_sbt+0x117/frame 0xfffffe00f55f4960
e1000_read_phy_reg_mdic() at e1000_read_phy_reg_mdic+0xf1/frame 0xfffffe00f55f49b0
e1000_read_phy_reg_igp() at e1000_read_phy_reg_igp+0x5b/frame 0xfffffe00f55f49e0
em_if_timer() at em_if_timer+0xcc/frame 0xfffffe00f55f4a10
iflib_timer() at iflib_timer+0x69/frame 0xfffffe00f55f4a40
softclock_call_cc() at softclock_call_cc+0x155/frame 0xfffffe00f55f4af0
softclock() at softclock+0x7c/frame 0xfffffe00f55f4b20
intr_event_execute_handlers() at intr_event_execute_handlers+0x91/frame 0xfffffe00f55f4b60
ithread_loop() at ithread_loop+0xb6/frame 0xfffffe00f55f4bb0
fork_exit() at fork_exit+0x84/frame 0xfffffe00f55f4bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00f55f4bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 12 tid 100023 ]
Stopped at      kdb_enter+0x3b: movq    $0,kdb_why
Aug 26 2017, 11:44 PM · network
kmacy updated the diff for D12101: swfw_sync DELAY -> sleep conversion.

move more blocking work to deferred context

Aug 26 2017, 11:43 PM · network

Aug 25 2017

sbruno added a comment to D12101: swfw_sync DELAY -> sleep conversion.

Yeah, legacy em(4) device on em2:

Aug 25 2017, 7:11 PM · network
sbruno added a comment to D12101: swfw_sync DELAY -> sleep conversion.

Huh .... Testing this review by itself this morning. I see the following startup panic:

Aug 25 2017, 7:02 PM · network
johalun0_gmail.com added a comment to D12101: swfw_sync DELAY -> sleep conversion.
In D12101#251488, @erj wrote:

The busy waiting would cause 10% CPU usage on my system when no cable connected to em0 (traced to em_if_update_admin_status).
This patch also fixes this. I can no longer detect any unusual CPU usage.

Getting a lot of witness output. Like a few per second or so.

I think this revision depends on D11969. It changes the core lock from a mutex to an sx lock, which would allow sleeping while its held.

Actually the problem is that I didn't completely eliminate the use of mutexes in the OS independent code. Update forthcoming.

Aug 25 2017, 8:26 AM · network

Aug 24 2017

kmacy updated the diff for D12101: swfw_sync DELAY -> sleep conversion.
  • Eliminate remaining mutex use in os independent e1000 code.
  • Fold in iflib updates.
Aug 24 2017, 10:06 PM · network
kmacy added a comment to D12101: swfw_sync DELAY -> sleep conversion.
In D12101#251488, @erj wrote:

The busy waiting would cause 10% CPU usage on my system when no cable connected to em0 (traced to em_if_update_admin_status).
This patch also fixes this. I can no longer detect any unusual CPU usage.

Getting a lot of witness output. Like a few per second or so.

I think this revision depends on D11969. It changes the core lock from a mutex to an sx lock, which would allow sleeping while its held.

Aug 24 2017, 10:02 PM · network
erj added a comment to D12101: swfw_sync DELAY -> sleep conversion.

The busy waiting would cause 10% CPU usage on my system when no cable connected to em0 (traced to em_if_update_admin_status).
This patch also fixes this. I can no longer detect any unusual CPU usage.

Getting a lot of witness output. Like a few per second or so.

Aug 24 2017, 6:08 PM · network
johalun0_gmail.com added a comment to D12101: swfw_sync DELAY -> sleep conversion.

The busy waiting would cause 10% CPU usage on my system when no cable connected to em0 (traced to em_if_update_admin_status).
This patch also fixes this. I can no longer detect any unusual CPU usage.

Aug 24 2017, 6:57 AM · network
kmacy added a comment to D12101: swfw_sync DELAY -> sleep conversion.

@jtl any comments?

Aug 24 2017, 4:24 AM · network
kmacy added a reviewer for D12101: swfw_sync DELAY -> sleep conversion: jtl.
Aug 24 2017, 4:23 AM · network