In D37359#849134, @kib wrote:I believe all uses of &ap->a_gen are mine, and the casts are historic.
Isn't it more reliable to avoid cast and explicitly take the address of the generic member? Either case depends on the generic being the first member of the vop_arg struct for now.Anyway, I am curious about your choice of the cast, Is it due to the calculated number of each case in the source?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Nov 15 2022
Nov 15 2022
Nov 11 2022
Nov 11 2022
Remove dead code in the cscope target
Remove the style change.
Nov 10 2022
Nov 10 2022
In D36402#836213, @jhb wrote:Hmm, does cscope fail because the directory name doesn't exist? (I confess to always using ALL_ARCH=yes myself)
Sep 9 2022
Sep 9 2022
def edited reviewers for D36402: Remove dead code in the cscope target, added: oshogbo; removed: pjd.
Aug 31 2022
Aug 31 2022
Apr 10 2022
Apr 10 2022
Aug 26 2018
Aug 26 2018
def added inline comments to D16900: Refactor crashinfo(8) script before extending its functionality..
This update fixes typos, style and changes die() to write messages to stderr.
Aug 25 2018
Aug 25 2018
def updated the summary of D16900: Refactor crashinfo(8) script before extending its functionality..
Jan 29 2018
Jan 29 2018
Fix misspelling of encryptedcore.
Aug 6 2017
Aug 6 2017
Aug 3 2017
Aug 3 2017
I'm using a script to test kernel dumps in bhyve. It exercises combinations of minidumps vs. full dumps, compression, encryption, and dump device sector size.
def added inline comments to D11603: Shift some of the EKCD funcs around to keep them grouped together..
def added inline comments to D11584: Factor out common kerneldump code into dump_start()/dump_finish()..
Aug 2 2017
Aug 2 2017
def added inline comments to D11603: Shift some of the EKCD funcs around to keep them grouped together..
def added inline comments to D11584: Factor out common kerneldump code into dump_start()/dump_finish()..
Jul 31 2017
Jul 31 2017
def added inline comments to D11584: Factor out common kerneldump code into dump_start()/dump_finish()..
Feb 8 2017
Feb 8 2017
Don't decrypt a core if a vmcore file already exists by default.
Feb 4 2017
Feb 4 2017
Fix bugs found by Coverity in decryptcore(8) and savecore(8):
Dec 10 2016
Dec 10 2016
Add support for encrypted kernel crash dumps.
def closed D4712: Encrypted kernel crash dumps. by committing rS309818: Add support for encrypted kernel crash dumps..
Nov 14 2016
Nov 14 2016
Move text dump version as it's not an architecture version.
Nov 12 2016
Nov 12 2016
Add myself (def) as a src committer and pjd as my mentor.
Add myself (def) as a src committer.
Aug 16 2016
Aug 16 2016
This revision fixes alignment of the kdc_dumpkey member of the kerneldumpcrypto structure and uses roundup2 macro to round a kernel dump key size.
Aug 15 2016
Aug 15 2016
The patch was updated to fix two problems:
- Use a packed structure instead of writing a kernel dump key structure byte per byte;
- Allocate require memory using malloc(9) when it's safe to do that which is during a dump device setup.
Jul 31 2016
Jul 31 2016
I've merged the changes from HEAD. The current patch is against r303588 [1]. The main changes include:
- ambrisko submitted a patch to write crash dumps on dump devices with a block size other than 512B. EKCD should be compatible with these changes now;
- DIOCSKERNELDUMP_FREEBSD10 became DIOCSKERNELDUMP_FREEBSD11 as we already have FreeBSD 12.0-CURRENT;
- DIOCSKERNELDUMP ioctl has a new number as a new DIOCZONECMD ioctl was introduced in [3].
Apr 14 2016
Apr 14 2016
Thanks for the review. I sent some replies to the inline comments.
Apr 2 2016
Apr 2 2016
In D4712#124230, @cem wrote:In D4712#123472, @def wrote:In D4712#99936, @kib wrote:Still, I have a question. You choice was to modify the dump code, which resulted in spreading the patch over the MI dump and all MD minidump code. Semi-obvious alternate approach is to introduce a geom which would write the generated encrypted symmetric key into the first block and write data block N into encrypted block N+1 of the underlying provider. Then you do not have to touch the kernel dump code at all.
I agree with kib@. It would be nice not to have separate userspace tools here.
In fact we already have encrypted GEOM providers (g_eli, ...). All we lack is a way to dump core through them—maybe? I'm not even sure we lack that.
The kerneldumpkey structure has an arbitrary size.
I am sure this is not a problem in practice. An AES key is far smaller than 512 bytes.
Mar 30 2016
Mar 30 2016
In D4712#99936, @kib wrote:I looked over the patch, it looks fine to me.
Still, I have a question. You choice was to modify the dump code, which resulted in spreading the patch over the MI dump and all MD minidump code. Semi-obvious alternate approach is to introduce a geom which would write the generated encrypted symmetric key into the first block and write data block N into encrypted block N+1 of the underlying provider. Then you do not have to touch the kernel dump code at all.
Is it possible technically ?
Dec 26 2015
Dec 26 2015
Oct 16 2015
Oct 16 2015
I have made some inline comments. I think a partial vmcore shouldn't be removed because another panic might happen before a user tries to run savecore manually again.