Tue, Jul 16
@cem, sorry about the delayed response.
I was trying to use the "arc" tool for updating the patch. But it asks to create a new commit as below. I am unsure whether to accept it.
Mon, Jul 15
I'd just drop the extra * on the other of the definition/declaration, but I don't know if we have a style(9) preference. Functionally / semantically it looks good.
Tue, Jul 9
The general idea of the change looks good to me, thanks!
Thanks @mav for reviewing and pushing the patch upstream. I verified it to work properly. I have some more minor changes to this Driver (basically to add support for another PCI Device ID). Shall I submit the additional patch here itself? or should I open another review for the same?
FWIW, I also work on an embedded appliance.
Mon, Jul 8
I would change the commit summary/title, though. Really we're just disabling a feature when it is unsupported by some particular configuration; it's not bhyve-specific.
Sun, Jul 7
Looks good to me.
Sat, Jul 6
Wed, Jul 3
LGTM. For future reference, please upload patches with more context. That could mean using the arc command line tool, which simplifies the process somewhat once it is set up, or diff -U99999 if you prefer not to use the arc ("Arcanist") tool.
Fri, Jun 28
But I've added the justification (explanation of what's the point of ARB, from the consumer point of view) to the man page already. What else is needed?
Thu, Jun 27
Wed, Jun 26
I think there are open questions around rounding behavior and making the extensive macros into functions.
The problem with functions is that in many places it uses Q_TC() (which boils down to __typeof()), or macros that expand to Q_TC(). I guess I could try to rework the ones which don't, but that would look inconsistent.
The design seems kind of poor (random last 32k corruption?). Alternatively / relatedly, we (ISLN) have a syslogd patch we can share that parses newsyslogd.conf and manually invokes newsyslogd directly when logs grow beyond configured rotation size.
Tue, Jun 25
So... is there anything else left for me to do here before this can get committed?
Mon, Jun 24
Fri, Jun 21
- Fix a typo in rc.d/motd
- Update login(1) and motd.5
Thu, Jun 20
Wrap in vfs_vnops.c at line 502. Currently, the largest possible overflow is about 2x. So using an int16_t makes it safe.
FYI, I discovered that f_seqcount needs to be int16_t rather than int8_t in order to detect an overflow. Otherwise the slightest overflow of IO_SEQMAX will wrap.
Need to change fifofs to actually use f_pipegen instead of f_seqcount :)
Rebase on recent HEAD
Actually, I don't think the usage in fifo_vnops.c is a potential overflow. AFAICT fifos use that field for a completely different purpose. It really should be a different field (and in fact, it used to be). See r238936.
Also: nice find! :)
Looks like you could get a similar overflow by having 64k readers on a pipe too (fs/fifofs/fifo_vnops.c). You could also overflow in sequential_heuristic() if uio_resid is big enough (especially with a narrower f_seqcount).
Adding Kirk for UFS change.
Ah, I was thinking of FIEMAP I think. So the better question might be, why not add FIEMAP instead? https://www.kernel.org/doc/Documentation/filesystems/fiemap.txt
The name, etc, beg the question: what's the motivation to differ from FIOBMAP in Linux (or NetBSD)?
Wed, Jun 19
As mjg@ points out, the mktemp file may be on a different filesystem than /etc
(e.g., tmpfs, but any other filesystem invalidates the initial fsync). Copy to
a temporary /etc file, sync that, then rename over /etc/motd.
I encountered a technical problem trying to replace the printf with KASSERT.
bus.h does not include systm.h and there are multiple places where bus.h is included before systm.h (or systm.h not included at all).
Jun 18 2019
Jun 17 2019
Rename uint128_add to the more appropriate uint128_add64
As a first-cut workaround, LGTM.
Jun 15 2019
(<sys/param.h> includes <sys/types.h>; do not include both.)
Jun 14 2019
Jun 13 2019
Regarding the LUT idea - it does make sense, but I believe it would require somewhat complicated code surgery, and I'd rather not do it at this time: it's a vendor code which I'm trying to upstream, not to rewrite. It also sounds like something that can be done later, if neccessary.
Jun 10 2019
(bump .Dd if needed)
Thanks for splitting up the pages.
Jun 9 2019
Jun 8 2019
Jun 7 2019
For the microoptimization: Note that it's possible to avoid the additional branching by doing unlock in both cases, e.g.:
Rebase on D20312 changes
@delphij , this one technically touches sys/dev/random (fix a declaration name typo but mostly add #ifndef _KERNEL compatibility shims), so I need secteam blessing to commit. I'd appreciate a look when you get a chance.
- Drop DELAY() entirely
- Minor optimization: drop global lock over 1-15 bytes of memcpy and 16 bytes explicit_bzero.
- Rebase on newer version of D20312
- Refactor somewhat to improve clarity
- Continue to artificially limit lock hold duration to 4kB in "locked" == "!concurrent" mode
- Continue to rekey AES at 1MB intervals
Replace tsleep with DELAY().