- User Since
- Jul 9 2015, 9:56 PM (188 w, 6 d)
Prior to this change, ctfdump shows  FUNC (kern_chflagsat) returns: 1 args: (1173, 1, 5, 142, 91, 1); ... <142> ENUM uio_seg (i.e., no idea it's been const-ed out of the ABI).
Thanks, the locking around the global ioat list seems more robust. How much testing have you been able to perform with this patch? Do you have a test that can induce an error condition?
Tue, Feb 19
Why is the MK_PIE PIE_SUFFIX “_pic”? That seems inconsistent. Otherwise, LGTM.
Mon, Feb 18
+CC jimharris@, who might have some feedback or ability to help facilitate access to NDA'd register documents
I realize this is old, but I figure the same group is still likely to be interested. I think we'll need more like this to support GCC6+ ctfconvert. E.g.,
Sat, Feb 16
Thanks for doing this, Ben! I'm sorry it took me so long to take a look and appreciate your patience.
Fri, Feb 15
Thu, Feb 14
All of the changes since the initial patch LGTM; I count 4 issues from my initial pass that I'd consider unresolved for now (all commented on in the previous update, should be pretty clear). Like before, mostly LGTM, minus the few relatively minor issues.
Tue, Feb 12
Mon, Feb 11
Looks good except for one remaining item.
Sun, Feb 10
Sat, Feb 9
I suspect the rcorder -p mode could be implemented much less invasively than this change. It's fundamentally the same graph algorithm. I'll give it a shot.
Fri, Feb 8
Thu, Feb 7
My guess is that the author intended for defconf input to parse_file() to be a *reference* rather than a bare pointer. If you look at parse_file(), you can see it initializes its copy of defconf_p when the special entry "<default>" is encountered in a file. However, that pointer is never stored anywhere and is leaked when parse_file() returns.
Two ideas (just spitballing) re: forward compatibility.
Wed, Feb 6
Thanks, mostly looks good! The feedback is a bit verbose but I try to go over crypto code with a fine-toothed comb. I'll try to get some time to look at the latest version of the previous change.
Tue, Feb 5
I think this one can be closed, a version of this was committed in r340425
Fri, Feb 1
Fri, Jan 25
To elaborate a bit more, the stated commit log:
Wed, Jan 23
Jan 18 2019
Jan 17 2019
I really like this, even if it isn't ready to land yet.
Jan 16 2019
Jan 12 2019
Jan 10 2019
Jan 9 2019
Jan 8 2019
I didn't really look at this driver thoroughly and don't plan to, but just skimmed through and pointed out some possible improvements.
Jan 7 2019
(Lua lerrno.c change looks fine.)
Thanks for the quick review and test!
This proposal is to create a new EINTEGRITY error number. EINTEGRITY's purpose is to respond to errors where an integrity check such as a check-hash or a cross-correlation has failed. For example, an uncorrectable error has been found in a filesystem or a disk subsystem such as gmirror(8) or graid3(8).