I'm sorry, I completely missed this change in the past. But it looks like it can break ipfw firewall rules, since rcvif is now union with snd_tag. And this means, rcvif can be initialized for packets that were not actually received on specified interface. ipfw uses rcvif in rules to check that a packet was received on specified interface, and this check was correct even for outgoing packets. Now it looks like such checks can be incorrect.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 1 2019
Apr 30 2019
The epoch_call_drain() function is indeed needed (at least to fix such panic https://reviews.freebsd.org/F4491011).
But your example shows that epoch based reclamation is just wrongly used. The right solution should be keeping ifnet detached until all possible consumers stop reference it, and only then it will be safe to free ifnet pointer.
Apr 29 2019
In D20070#432259, @markj wrote:I'm not quite familiar with this code. Is it safe enough to make INP_WUNLOCK(); /* some code */ INP_WLOCK(); without holding extra reference to PCB? Is is it impossible, that another thread can destroy PCB when we release lock?
Sorry, I don't see where the question is coming from. In general, no, you have to acquire a reference before dropping the lock. That's what the old version of the diff did, in order to acquire the sleepable IN_MULTI lock. But dropping the PCB lock introduces races. I changed the code to acquire the IN_MULTI lock first, so we don't have to drop the PCB lock anymore.
Apr 26 2019
I'm not quite familiar with this code. Is it safe enough to make INP_WUNLOCK(); /* some code */ INP_WLOCK(); without holding extra reference to PCB? Is is it impossible, that another thread can destroy PCB when we release lock?
Apr 24 2019
Apr 23 2019
Apr 22 2019
In D20006#430085, @kib wrote:Well, I can take only 8bytes. But what I see on Linux (not me, this is copy/paste from somebody else actions):
# ifconfig ib5 Ifconfig uses the ioctl access method to get the full address information, which limits hardware addresses to 8 bytes. Because Infiniband address has 20 bytes, only the first 8 bytes are displayed correctly. Ifconfig is obsolete! For replacement check ip. ib5 Link encap:InfiniBand HWaddr 80:00:08:87:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00 inet addr:16.7.5.140 Bcast:16.7.255.255 Mask:255.255.0.0 inet6 addr: fe80::ee0d:9a03:43:f7bd/64 Scope:Link
In D20006#430051, @kib wrote:Hm, from my reading of RFC, there is a very explicit requirement to form 20-byte link-local address as [0:qpn:GID], and the 16-byte l/l should be formed by truncating. I also verified that after the patch, l/l address on the ibX is same as configured by Linux.
Are you worrying about the embedded scope id ? If scope is implanted before the call, I can preserve it ?
I'm not sure that is correct. in6_get_hw_ifid() is used by in6_ifattach_linklocal() via get_ifid() to generate IPv6 link local address. IPv6 link local address has already filled first 8 bytes. And in this change you override them. Note in the line 238 says that first 8 bytes should be preserved.
It looks like INFINIBAND_ALEN defines link address length for infiniband. It is 20 bytes. It seems the check if (addrlen != 16) will be always successful.
- remove RSS-related chunks.
- allow use any port number within [V_ipport_hifirstauto, V_ipport_hilastauto] range.
We have single machine, that after automatic firmware upgrade fails to attache the driver:
Apr 20 2019
It seems this is not enough to prevent panics. Simple kernel module to reproduce the panic.
Apr 19 2019
Apr 16 2019
Document GRE-in-UDP in gre(4).
Apr 14 2019
Apr 13 2019
Apr 10 2019
Ok. It is more flexible, but produces additional options. I think ipfw(8) is already very complex.
What if we will make "missing"+"flush" behavior as default.
It seems if user wants to create table, it is expected that later this table will be filled. So, if we are creating some table, and it is already exist, we will check that the table has the same configuration and then flush it.
If configuration is different, then we return error. What you think?
IPv6 has the same code.
Apr 9 2019
I think you can add to the beginning of your ipfw rules script something like this:
ipfw -q flush ipfw -q table all destroy
And then create needed tables and fill them.
Apr 8 2019
Apr 6 2019
Apr 3 2019
Apr 2 2019
Apr 1 2019
Mark, do you suppose that this can fix some another strange panics that appeared after epochification?
Mar 30 2019
LGTM.
Note, that automatic loading for cxgbe can do unexpected firmware update when user does first boot.
Mar 29 2019
Mar 23 2019
Mar 22 2019
LGTM.
Mar 21 2019
I think you may find useful ipfw_pmod module too, it adds support for TCP MSS modification, but, yes, it is not related to IPv6. However, ng_tcpmss does not support TCP over IPv6, but ipfw_pmod does :)
In D19622#421205, @bz wrote:@glebius and @hselasky rather than changing pr_drain I wondered about an eventhandler or something as that way dealing with non-protocol places such as firewalls, netisr, .. would also be possible? I think not queuing is not an option, arp queue is just another one of these places... there's more and more the longer I think about it... We'll need something to get them all (and getting the locking right).
Mar 20 2019
Mar 19 2019
Mar 18 2019
Mar 14 2019
Mar 12 2019
Add missing TOK_STATES_CHUNKS token