I don't really know the internals of this driver (ideally this should be done by someone who is familiar with it), but are we sure that the write method is always called before a read? Also, if the discard callout is fired, should the owner tid be reset (because the contents is now discarded)?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 11 2019
Apr 6 2019
Noticed a few minor issues, please see comment inline. Overall I think the change is good.
Apr 5 2019
Apr 4 2019
Apr 3 2019
Mar 31 2019
LGTM, thanks!
Mar 29 2019
The shutdown script change LGTM, but I insist that libexec/save-entropy/save-entropy.sh line 83 should be removed as explained in previous comment.
In D19742#423456, @cem wrote:In D19742#423197, @delphij wrote:I think a 'fsync saved-entropy.1 .' should be sufficient.
We don't really care if the renames were not persistent until the new entropy is saved,
Sure, if that is the power-fail/crash behavior of un-fsynced renames. But I don't believe that model is accurate. There is no requirement that the underlying filesystem order the dirent writes in a way that matches this observable behavior; the only requirement is that it is persisted by fsync.
FS&K §9.6.2 is clear, "All updates to the seed file must be atomic" and goes into more detail in §9.6.5.
I think you should separate most of the read_random() -> arc4random_buf() change out because in most cases the code should use the latter exclusively, especially places where the return value of read_random() were not tested because it would be a strict improvement to the status quo.
I think a 'fsync saved-entropy.1 .' should be sufficient.
Mar 28 2019
In D19706#422829, @ota_j.email.ne.jp wrote:I need to understand better kernel malloc/free as they take 1 extra argument compare to stdlib.h.
Mar 27 2019
Hi, first of all, kudos for taking on this! The change looks mostly Ok to me except a few minor issues commented inline.
Mar 23 2019
Why is the partition index changed from 1 to 2? (The change looks otherwise fine to me).
Mar 22 2019
Thanks! LGTM (note that discard_buffer_callout should probably also be drained, but it's unrelated to this change).
Mar 21 2019
I have noticed a few minor issues and have commented inline.
Mar 7 2019
(Note that randomdev_getkey() have similar issue and should be fixed too, feel free to fix it prior to commit)
Looks good to me in principle and I like the fact that fortuna.c no longer cares about the keystream context internals.
Mar 1 2019
Feb 25 2019
Abandoned in favor of D19216.
Sorry, this looks good to me & thanks!
Feb 19 2019
Feb 13 2019
Ah I didn't realized that we haven't upstreamed it & thanks for forward-porting it for so many years...
Feb 7 2019
Feb 5 2019
Jan 29 2019
Jan 28 2019
In D18920#405658, @oshogbo wrote:Is this some common pattern?
Jan 27 2019
Jan 24 2019
One last change request -- could you please use ${PAGER} instead of $PAGER while there? The change looks otherwise fine to me.
LGTM & Thanks for your work!
Jan 22 2019
In D18859#403540, @aryeeteygerald_rogers.com wrote:Note that most IDS_run output shouldn't be considered as "informational", especially checksum differences: these should not be suppressed because they suggest there are real issues.
Where are the checksum diffs? I don't think they are currently suppressed but maybe I missed it.
I like this change in principle, but I think you could simplify the code a little bit (see my comments in line).
I really don't like this approach because it would bar us from retrofit publishing freebsd-update bits (and would create problems for users who have their own freebsd-update instance running). I think it's more appropriate to make fetch_key to provide more meaningful output instead of "Fetching public key from ... failed".
Jan 21 2019
Jan 18 2019
LGTM in principal (except the style issue raised by @emaste which is minor and I think he would take care of it when committing).
In D18859#403307, @aryeeteygerald_rogers.com wrote:It may be because it is hard to follow but warnings/errors are redirected to the stderr
LGTM, thanks!
I think this is not complete. For example, /usr may be a symlink to somewhere else, and freebsd-update needs to have write access there (this applies to /boot, /var, etc. too).
I like the idea in general, but I think there were some implementation issues:
Jan 15 2019
Jan 13 2019
Jan 9 2019
LGTM now, thanks!
Jan 8 2019
I'd like to request that the change be either extended to disable RTREE (my preference; we don't use rtree in base either), or reduced to build with FTS4 (to match upstream; arguably FTS5 should be also enabled if that's the approach taken) for consistency.
Jan 7 2019
Jan 6 2019
Jan 4 2019
In D18536#400014, @jpaetzel wrote:In D18536#400013, @markj wrote:In D18536#395272, @jpaetzel wrote:In D18536#395145, @delphij wrote:LGTM (the unlocked use of sc->ioctl_data_mem looks worrisome to me, but the proposed change won't worsen the situation). Do you have a chance to test this on real hardware? (@jpaetzel do you know someone who may be able to help with that?).
My last 9750 died a while ago. I'll ping Austin @ ix to see if he can rig up a system for us to test with.
Ping?
I haven't been deemed worthy of a reply, so I guess that's a no.
Jan 1 2019
Dec 31 2018
Dec 30 2018
In D18689#398817, @loader wrote:I would think this would affect any program that calls strftime(3) with abbreviated weekday name (%a),
for example ps(1):https://svnweb.freebsd.org/base/head/bin/ps/print.c?revision=335023&view=markup#l411
410 } else if (now - k->ki_p->ki_start.tv_sec < 7 * 86400) { 411 (void)strftime(buf, buflen, "%a%H ", tp);then it would just print out a 五 here instead of 周五:
% env LANG=zh_CN.UTF-8 ps auwwx | grep '[s]bin/sshd' root 26612 0.0 0.0 20784 100 - IsJ 五12 0:00.02 /usr/sbin/sshd % env LANG=en_US.UTF-8 ps auwwx | grep '[s]bin/sshd' root 26612 0.0 0.0 20784 100 - IsJ Fri12 0:00.02 /usr/sbin/sshd
Rebase after r342614.
Properly set MIME type for zh_CN.UTF-8.src.
Dec 21 2018
Looks good to me (except please do use FBSD_1.6 version).
Dec 13 2018
LGTM (the unlocked use of sc->ioctl_data_mem looks worrisome to me, but the proposed change won't worsen the situation). Do you have a chance to test this on real hardware? (@jpaetzel do you know someone who may be able to help with that?).