| The article is about allowing bandwidth restrictions in bytes/second that are larger than 2³²-1, not about how fast pf can filter packets. I guess few people with faster ports felt the need to limit bandwidth for a service to something that’s that large. FTA: “OpenBSD's PF packet filter has long supported HFSC traffic shaping with the queue rules in pf.conf(5). However, an internal 32-bit limitation in the HFSC service curve structure (struct hfsc_sc) meant that bandwidth values were silently capped at approximately 4.29 Gbps, ” the maximum value of a u_int ". With 10G, 25G, and 100G network interfaces now commonplace, OpenBSD devs making huge progress unlocking the kernel for SMP, and adding drivers for cards supporting some of these speeds, this limitation started to get in the way. Configuring bandwidth 10G on a queue would silently wrap around, producing incorrect and unpredictable scheduling behaviour. A new patch widens the bandwidth fields in the kernel's HFSC scheduler from 32-bit to 64-bit integers, removing this bottleneck entirely.” |
| |
| ▲ | Someone 2 days ago | parent | next [-] | | It’s a fairly common issue with C code, so you should be scared about more than OpenBSD. As an example: a_long = an_int * another_int;
will do the multiplication in integers, then convert the result to long. That can produce surprising results of the multiplication overflows (I think that, technically, that would be undefined behavior, allowing the compiler to do what it wants, but most compilers will generate a multiplication instruction and let the CPU do whatever it does with int overflow (wrap around and trapping are the most popular options)Also, an_int = a_long;
is valid, and will do a narrowing conversion. I don’t think compilers are required to warn about that. | |
| ▲ | kaashif 3 days ago | parent | prev [-] | | Yeah, that's pretty appalling. Regardless of how good the philosophy of something is, if it's as niche and manpower constrained as OpenBSD is then it's going to accumulate problems like this. | | |
| ▲ | muvlon 3 days ago | parent [-] | | I actually think this isn't even surprising from OpenBSD philosophically. They still subscribe to the Unix philosophy of old, moreso than FreeBSD and much much more than Linux. That is, "worse is better" and it's okay to accept a somewhat leaky abstraction or less helpful diagnostics if it simplifies the implementation. This is why `ed` doesn't bother to say anything but "?" to erroneous commands. If the user messes up, why should it be the job of the OS to handhold them? Garbage in, garbage out. That attitude may seem out of place today but consider that it came from a time when a program might have one author and 1-20 users, so their time was valued almost equally. | | |
| ▲ | tredre3 2 days ago | parent | next [-] | | > That attitude may seem out of place today It absolutely doesn't. Everywhere I've worked we were instructed to give terse error messages to the user. Perhaps not a single "?", but "Oops, something went wrong!" is pretty widespread and equally unhelpful. | | |
| ▲ | nine_k 2 days ago | parent [-] | | This is normal to return a terse message to a remote user via API. The remote user may be hostile, actively trying to gather information useful for breaking in. But the local user who operates pf is already trusted, normally it would be root. In either case, no error should be silently swallowed. Details should be logged in a secure way, else troubleshooting becomes orders of magnitude harder. |
| |
| ▲ | PunchyHamster 2 days ago | parent | prev | next [-] | | > That attitude may seem out of place today That attitude was out of place at every point. Now it was excusable when RAM and disk space was sparse, it isn't today, it have entirely drawbacks | |
| ▲ | FarmerPotato 2 days ago | parent | prev | next [-] | | Code size would balloon if you try to format verbose error messages. I often look at the binaries of old EPROMs. I notice that 1) the amount of ASCII text is a big fraction of the binary 2) still just categories (“Illegal operation”). For the 1970s, we’re talking user programs that fit in 2K. I write really verbose diagnostic messages in my modern code. | | |
| ▲ | kjellsbells 2 days ago | parent [-] | | There was also an implicit saving back then that an error message could be looked up in some other system (typically, a printed manual). You didn't need to write 200 chars to the screen if you could display something much shorter, like SYS-3175, and be confident that the user could look that up in the manual and understand what they're being told and what to do about it. IBM were experts at this, right up to the OS/2 days. And as machines got more powerful, it was easy to put in code to display the extra text by a lookup in a separate file/resource. Plus it made internationalization very easy. |
| |
| ▲ | fluoridation 3 days ago | parent | prev [-] | | Even in that scenario that attitude seems out of place, considering a feature is implemented once and used many times. |
|
|
|
