Page MenuHomeFreeBSD

bz (Bjoern A. Zeeb)
User

Projects (6)

User Details

User Since
Aug 29 2014, 12:11 PM (250 w, 3 d)

Recent Activity

Today

bz added a comment to D16851: Add support for header chain validation on IPv6 Fragments (RFC7112).

I have a kind-of stupid question: where in all this do you actually walk an entire header chain to the end rather than just checking the next one? Are there no cases when this might be needed?

Mon, Jun 17, 9:29 AM

Thu, Jun 13

bz added a comment to D17512: Fix dpcpu and vnet panics with complex types at the end of the section.

Over in powerpc land, we've been chasing crashes with dpcpu and vnet as well. Our current prospective fix is https://reviews.freebsd.org/D20461 but we don't understand why it seems to fix it.

Thu, Jun 13, 7:14 PM
bz added a comment to D20461: [PowerPC64] Don't mark module data as static on PowerPC64 - Fixes panic when loading ipfw.ko and if_epair.ko built with modern compiler..

Does this patch fix your issues?
https://svnweb.freebsd.org/base?view=revision&revision=336909 has a brief explanation of the problem; can you look at the code and see if you get a similar problem, just to confirm (and for you to understand as-to why that is?

Thu, Jun 13, 7:12 PM

Mon, Jun 10

bz committed rS348885: A bit of code hygiene (no functional changes)..
A bit of code hygiene (no functional changes).
Mon, Jun 10, 11:25 PM
bz committed rS348878: Add a bus_add_child device method to bcm2835_sdhci..
Add a bus_add_child device method to bcm2835_sdhci.
Mon, Jun 10, 9:25 PM
bz committed rS348861: Enhance the comment ieee80211_add_channel() to avoid a.
Enhance the comment ieee80211_add_channel() to avoid a
Mon, Jun 10, 2:31 PM
bz committed rS348860: allwinner mmc: move variable assignment into block.
allwinner mmc: move variable assignment into block
Mon, Jun 10, 1:46 PM

Sat, Jun 8

bz committed rD53126: Document __FreeBSD_version bump to 1300031 with src r348808.
Document __FreeBSD_version bump to 1300031 with src r348808
Sat, Jun 8, 6:14 PM
bz committed rS348808: Fix dpcpu and vnet panics with complex types at the end of the section..
Fix dpcpu and vnet panics with complex types at the end of the section.
Sat, Jun 8, 5:44 PM
bz closed D17512: Fix dpcpu and vnet panics with complex types at the end of the section.
Sat, Jun 8, 5:44 PM
bz added inline comments to D19749: Add a CAM-Newbus SDIO support module..
Sat, Jun 8, 5:39 PM
bz committed rS348807: Remove extra stray + from a diff from the beginning of the lines after.
Remove extra stray + from a diff from the beginning of the lines after
Sat, Jun 8, 5:38 PM
bz committed rS348805: Add SDIO support..
Add SDIO support.
Sat, Jun 8, 4:27 PM
bz closed D19749: Add a CAM-Newbus SDIO support module..
Sat, Jun 8, 4:27 PM
bz closed D20199: bcm2835_sdhci.c: exit DMA if not enough data left to avoid timeout errors.
Sat, Jun 8, 4:15 PM
bz committed rS348804: bcm2835_sdhci.c: exit DMA if not enough data left to avoid timeout errors.
bcm2835_sdhci.c: exit DMA if not enough data left to avoid timeout errors
Sat, Jun 8, 4:15 PM
bz closed D20197: bcm2835_sdhci.c: save block registers to avoid controller bug.
Sat, Jun 8, 4:05 PM
bz committed rS348803: bcm2835_sdhci.c: save block registers to avoid controller bug.
bcm2835_sdhci.c: save block registers to avoid controller bug
Sat, Jun 8, 4:05 PM
bz closed D19747: Improve sdhci slot_printf() debug printing..
Sat, Jun 8, 3:24 PM
bz committed rS348801: Improve sdhci slot_printf() debug printing..
Improve sdhci slot_printf() debug printing.
Sat, Jun 8, 3:24 PM
bz committed rS348800: Introduce sim_dev and cam_sim_alloc_dev()..
Introduce sim_dev and cam_sim_alloc_dev().
Sat, Jun 8, 3:20 PM
bz closed D19746: Introduce sim_dev and cam_sim_alloc_dev()..
Sat, Jun 8, 3:20 PM

Tue, Jun 4

bz committed rS348671: Rather than using the legacy IP struct fields in the union for the.
Rather than using the legacy IP struct fields in the union for the
Tue, Jun 4, 8:53 PM

Sat, Jun 1

bz added a comment to D20199: bcm2835_sdhci.c: exit DMA if not enough data left to avoid timeout errors.

I'd like to commit this the next days. Can someone please review? If not it'll go in by Sat 8 June.

Sat, Jun 1, 5:47 PM
bz added a comment to D20197: bcm2835_sdhci.c: save block registers to avoid controller bug.

I'd like to commit this the next days. Can someone please review? If not it'll go in by Sat 8 June.

Sat, Jun 1, 5:46 PM
bz added a comment to D19749: Add a CAM-Newbus SDIO support module..

Warner if you have any further comments .. I'd like to commit this the next days. If not it'll go in by Sat 8 June.

Sat, Jun 1, 5:46 PM
bz added a comment to D19747: Improve sdhci slot_printf() debug printing..

I'd like to commit this the next days. Can someone please review? If not it'll go in by Sat 8 June.

Sat, Jun 1, 5:46 PM
bz added a comment to D19746: Introduce sim_dev and cam_sim_alloc_dev()..

I'd like to commit this the next days. Can someone please review? If not it'll go in by Sat 8 June.

Sat, Jun 1, 5:45 PM
bz added inline comments to D19749: Add a CAM-Newbus SDIO support module..
Sat, Jun 1, 3:49 PM
bz closed D20338: Fix a race condition in udp_output().

https://svnweb.freebsd.org/changeset/base/348494 missed the Diff-Rev: tag.

Sat, Jun 1, 3:02 PM
bz committed rS348494: After parts of the locking fixes in r346595, syzkaller found.
After parts of the locking fixes in r346595, syzkaller found
Sat, Jun 1, 2:58 PM
bz committed rS348493: Improve error/debug messages in sdhci.c.
Improve error/debug messages in sdhci.c
Sat, Jun 1, 2:39 PM
bz closed D19748: Improve error/debug messages in sdhci.c.
Sat, Jun 1, 2:39 PM

Wed, May 29

bz requested changes to D20278: vimage: support kmods determining VIMAGE status at runtime.

I just only scrolled through this and there's a few things. I am not going into detail at the moment as I'd love to give this a full review once my brain capacity for yet-another-module-thing-complication is there. It'll be helpful to later decompose this into "whitespace change" and functional change (as a lot of renaming, etc. makes this hard to read).

Wed, May 29, 2:47 PM
bz added a comment to D19622: Fix panic in network stack due memory use after free in relation to fragmented packets.

I'll register strong desire to discard fragments immediately on interface vanishing. I don't expect that to come with any significant weight, my rational is whatever makes state management easier within current codebase and usage patterns of fbsd.

Why do you want to discard a packet if the interface it was received from is going away?
The packet is there, it doesn't matter if the interface goes away after it was received. And we don't have to wait for the interface to come back before continuing processing. We should be able to just process the packet even without that interface it was received on still being present when the processing happens.

Wed, May 29, 9:47 AM

Sun, May 26

bz added a comment to D17512: Fix dpcpu and vnet panics with complex types at the end of the section.
In D17512#439294, @jhb wrote:

I still don't understand why i386 is special in this regard. Surely i386 isn't the only architecture to ever use this type of relocation?

Sun, May 26, 4:18 PM

Wed, May 22

bz reclaimed D17512: Fix dpcpu and vnet panics with complex types at the end of the section.

so this happened as well with ipsec.ko not just carp.ko so we need a solution to the problem which scales. We discussed it here a bit in Waterloo and I think the only question is as to whether to use the BYTE(1) option and just put a padding byte at the end, or as to whether put a larger magic number there and actually check that the module might be compiled with the right options?

Wed, May 22, 9:33 PM
bz updated the summary of D20338: Fix a race condition in udp_output().
Wed, May 22, 3:24 PM

Tue, May 21

bz added a comment to D20340: Add deprecation warnings for IPsec algorithms deprecated in RFC 8221..

Did you also want something for ipcomp?

Tue, May 21, 10:28 PM
bz committed rS348063: Add very basic afinet socket tests which I started to write in order.
Add very basic afinet socket tests which I started to write in order
Tue, May 21, 7:42 PM
bz created D20338: Fix a race condition in udp_output().
Tue, May 21, 7:37 PM
bz committed rS348061: Massively blow up the locking-related KASSERTs used to make sure.
Massively blow up the locking-related KASSERTs used to make sure
Tue, May 21, 7:24 PM
bz committed rS348060: Similarly to r338257,338306 try to fold the two consecutive.
Similarly to r338257,338306 try to fold the two consecutive
Tue, May 21, 7:19 PM

Sat, May 18

bz accepted D20311: Change ed(4), ep(4), and fxp(4) examples to em(4)..

Thank you!!!! And for the .Dd changes discussed in person :-)

Sat, May 18, 8:57 PM

May 10 2019

bz accepted D20051: Factor out vnet ready check.

LGTM

May 10 2019, 9:47 AM

May 8 2019

bz added a comment to D20051: Factor out vnet ready check.

I kept thinking which states we can really observe and when:

May 8 2019, 5:34 PM
bz updated the diff for D19749: Add a CAM-Newbus SDIO support module..

Handle reviewer comments:

  • add SDIO disclaimer
  • fix typos
  • split up CMD53 function
  • add one device per function (and with that re-adjust to use the parent device as we no longer cache that, add ivar support rather than having hand-rolled accessor functions)
  • Use CMD52 to set blocksize
  • use a sdio specific awk to generate device and vendor defines
  • remove the DEFAULT implementations from the sdio_if.m file as they were only providing the general default
  • rework some error handling
  • rename field "smb" into more descriptive
  • Use dprintfs instead of printfs in the middle of a parsing API
May 8 2019, 12:56 PM
bz created D20199: bcm2835_sdhci.c: exit DMA if not enough data left to avoid timeout errors.
May 8 2019, 10:19 AM
bz created D20197: bcm2835_sdhci.c: save block registers to avoid controller bug.
May 8 2019, 9:45 AM

May 6 2019

bz abandoned D3879: Conflicting use of CCNT by DEV_PMU and HWPMC.

I think a dependency was rejected. This was Cambridge Teaching material code. I would assume this is overcome by time and changes a lot since. I have no more access to these trees where this came from to see. I am abandoning it to clean up.

May 6 2019, 8:52 PM

May 5 2019

bz added a comment to D19749: Add a CAM-Newbus SDIO support module..

I've fixed all requests in my internal tree but the CMD53 request (which I left a comment for what I'll do).
I'll upload a new diff the next 48 hours (need to also adjust the driver to deal with multiple devices).

May 5 2019, 6:32 PM

May 3 2019

bz accepted D20060: Select lacp egress ports based on NUMA domain.
May 3 2019, 7:15 AM

May 2 2019

bz added a comment to D20117: Restructure mbuf send tags to provide stronger guarantees..

The ip6_fragment() change seems fine if you want to go ahead and factor that out.

May 2 2019, 8:31 PM
bz requested changes to D20060: Select lacp egress ports based on NUMA domain.
May 2 2019, 5:51 PM

Apr 30 2019

bz updated the diff for D19747: Improve sdhci slot_printf() debug printing..

Update based on feedback from marius/imp.

Apr 30 2019, 8:36 PM

Apr 25 2019

bz added a reviewer for D20044: tun/tap: merge: tuexen.

Adding @tuexen as a reviewer. If my memory serves me right he worked on a small part of of tun recently.

Apr 25 2019, 5:38 AM

Apr 24 2019

bz accepted D20028: Track TCP connection's NUMA domain in the inpcb.

LGTM... waiting for more beef :-)

Apr 24 2019, 4:14 PM

Apr 23 2019

bz closed D19594: Fix udp_output() locking strategy in one case.
Apr 23 2019, 10:12 AM
bz committed rS346595: iFix udp_output() lock inconsistency..
iFix udp_output() lock inconsistency.
Apr 23 2019, 10:12 AM
bz updated subscribers of D19622: Fix panic in network stack due memory use after free in relation to fragmented packets.

@bz: There is another bug I believe in the IPv6 VNET shutdown code.
Where is the counterpart mtx_destroy() for the following mtx_init():

void
frag6_init(void)
{

struct ip6q *q6;
int i;
V_ip6_maxfragpackets = IP6_MAXFRAGPACKETS;
frag6_set_bucketsize();
for (i = 0; i < IP6REASS_NHASH; i++) {
        q6 = IP6Q_HEAD(i);
        q6->ip6q_next = q6->ip6q_prev = q6;
        mtx_init(&V_ip6q[i].lock, "ip6qlock", NULL, MTX_DEF);
        V_ip6q[i].count = 0;
}
Apr 23 2019, 10:07 AM
bz requested changes to D19622: Fix panic in network stack due memory use after free in relation to fragmented packets.

Sorry my bad for missing the VIMAGE state problem in the initial submit.

Apr 23 2019, 10:04 AM

Apr 22 2019

bz committed rS346556: r297225 move the assignment of sin from add to the top of the function..
r297225 move the assignment of sin from add to the top of the function.
Apr 22 2019, 2:54 PM
bz updated the diff for D19594: Fix udp_output() locking strategy in one case.

@emaste update the comment a bit.
@tuexen removed the KASSERT and left the sin = to be removed in a separate commit (as it is noise here)
@karels I think with the change we are fine as splitting up the case was for IP_SENDSRCADDR.

Apr 22 2019, 2:45 PM
bz committed rS346554: Remove some excessive brackets..
Remove some excessive brackets.
Apr 22 2019, 2:21 PM
bz accepted D20006: ipoib: assign link-local address according to RFC.

Seems fine to me.

Apr 22 2019, 11:45 AM

Apr 21 2019

bz added a comment to D19973: ip6_id: Avoid blocking if random(4) is not available.
In D19973#429776, @cem wrote:
In D19973#429748, @thj wrote:

I think we can just use zero for the label if enough entropy is not available. A flow label of zero indicates no flow label "treatment" in the network.

That’s easy and fine with me. Is that reasonable, @bz?

Apr 21 2019, 9:35 PM
bz added a reviewer for D19594: Fix udp_output() locking strategy in one case: tuexen.
Apr 21 2019, 8:00 PM
bz accepted D19622: Fix panic in network stack due memory use after free in relation to fragmented packets.

Thanks for persevering on this. Let's get this for now. I also think the discussion had in the last days was very fruitful. Either way, there is a way forward now beyond just the IP reassembly queues, whether we start fixing the ifp on the mbuf replacing it or adding more event handlers for other parts of the tree which need clearing.

Apr 21 2019, 4:56 PM

Apr 20 2019

bz requested changes to D19622: Fix panic in network stack due memory use after free in relation to fragmented packets.
Apr 20 2019, 2:33 PM
bz added a comment to D19973: ip6_id: Avoid blocking if random(4) is not available.

Is there a notification for when we are fully seeded the first time and entropy is available? FlowIDs are a controversial subject as to what they mean and what they are good to use for (see various RFCs and drafts, especially from Brian Carpenter in the last years). BSD enable random flowids by default but we could equally, if not set by application, leave them 0 for the first few packets.

Apr 20 2019, 7:40 AM

Apr 19 2019

bz accepted D19969: Don't send ICMPv6 packets when the checksum is wrong.
Apr 19 2019, 5:52 PM
bz committed rS346404: MFC 344740:.
MFC 344740:
Apr 19 2019, 5:29 PM
bz committed rS346403: MFC r344740:.
MFC r344740:
Apr 19 2019, 5:28 PM
bz added inline comments to D19969: Don't send ICMPv6 packets when the checksum is wrong.
Apr 19 2019, 5:22 PM
bz accepted D19969: Don't send ICMPv6 packets when the checksum is wrong.

Again, can you you please mention rip6_input() in the commit message?

Apr 19 2019, 5:20 PM
bz accepted D19968: Improve checksum computation via IPV6_CHECKSUM for received packets.

Again can you please mention "... in rip6_input() ..." in the commit message.

Apr 19 2019, 5:06 PM
bz accepted D19967: Don't overwrite buffer when computing checksum via IPV6_CHECKSUM.

Can you please improve the description before committing stating that it's related to rip6_output().

Apr 19 2019, 4:58 PM
bz accepted D19966: Improve input validation for IPPROTO_IPV6 level socket option IPV6_CHECKSUM.
Apr 19 2019, 4:52 PM
bz added a comment to D19965: Fix various IPV6_CHECKSUM issues.
Apr 19 2019, 4:12 PM
bz requested changes to D19921: Add GRE-in-UDP encapsulation support.
Apr 19 2019, 4:10 PM
bz requested changes to D19965: Fix various IPV6_CHECKSUM issues.

This seems like four different issues and it's kind of hard to keep them apart in a single change. For the sake of having a readable history and easily seeing/understanding each problem, can you please split them up?

Apr 19 2019, 4:03 PM
bz committed rS346397: MFC r345757:.
MFC r345757:
Apr 19 2019, 3:54 PM
bz committed rS346396: MFC r345757:.
MFC r345757:
Apr 19 2019, 3:53 PM
bz committed rS346395: MFC r345372:.
MFC r345372:
Apr 19 2019, 3:52 PM
bz committed rS346394: MFC r345370:.
MFC r345370:
Apr 19 2019, 3:51 PM
bz committed rS346393: MFC r344959:.
MFC r344959:
Apr 19 2019, 3:49 PM
bz committed rS346392: MFC r344700:.
MFC r344700:
Apr 19 2019, 3:46 PM
bz committed rS346391: MFC r344700:.
MFC r344700:
Apr 19 2019, 3:46 PM
bz committed rS346389: MFC r340494:.
MFC r340494:
Apr 19 2019, 3:34 PM
bz committed rS346388: MFC r340494:.
MFC r340494:
Apr 19 2019, 3:34 PM

Apr 18 2019

bz added a comment to D19960: Remove support for RFC2675.

That said, there are vendors who list it (maybe not on the forwarding plane) but as RFC compliance supporting it:
https://www.juniper.net/documentation/en_US/junos/topics/reference/standards/ipv6.html

Apr 18 2019, 9:40 PM
bz added a comment to D19960: Remove support for RFC2675.

Maybe a very short ID to move RFC 2675 to historic... See RFC7805 for a ,much more complex example of such a document.

Apr 18 2019, 9:37 PM
bz added a comment to D19960: Remove support for RFC2675.
In D19960#429029, @jtl wrote:

I agree with @bz about ideal process. I also agree with @kristof about the practical implications of this feature. :-)
Might a valid way forward be to write a draft, propose it, and see if anyone complains by the next IETF (July) before purging this?

Apr 18 2019, 8:17 PM
bz added a comment to D19960: Remove support for RFC2675.

Burn it with fire! This code is not used, and pretty much can't be used, so let's get rid of it.

Apr 18 2019, 8:16 PM
bz resigned from D19960: Remove support for RFC2675.

I'l resign as a reviewer from this as removing valid RFC support seems counter-intuitive to me just because currently to your best knowledge no device supporting it exists. Someone should write the draft first to deprecate this and see if people stand up and then remove it.

Apr 18 2019, 5:18 PM
bz accepted D19952: Add a bugs section to pflog man page.
Apr 18 2019, 10:55 AM

Apr 15 2019

bz added a comment to D19622: Fix panic in network stack due memory use after free in relation to fragmented packets.

Sorry, I withdraw my approval. The more I think about this, the more I dislike it. What the patch does - it fixes the panic in a most straightforward way. But let's look at it from standpoint of network engineer, not kernel developer.

Apr 15 2019, 10:43 PM
bz accepted D19587: net: adjust randomized address bits.

I think this looks fine now. I haven't given it a full read-down or test again (just going by the diff of changes and last comments).

Apr 15 2019, 10:24 PM

Apr 13 2019

bz accepted D19861: Update and clarify pflog man page.

lgtm

Apr 13 2019, 8:51 PM
bz added inline comments to D19587: net: adjust randomized address bits.
Apr 13 2019, 2:03 PM