Re: kern/54322: strange kdump output

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/54322; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/54322: strange kdump output
Date: Thu, 4 Jul 2019 19:55:00 +0000

 On Mon, Jun 24, 2019 at 09:15:01AM +0000, martin%NetBSD.org@localhost wrote:
  > While ktracing a threaded application I noticed strange output in kdump:
  > 
  >   6851      1 gxemul   CALL  read(4,0x7d05e3f9e000,0x1000)
  >   6851      1 gxemul   GIO   fd 4 read 4088 bytes
  > [... data content stripped ...]
  >   6851      1 gxemul   GIO   fd 4 read 8 bytes
  >        "%\M^@\M^@\0\^D\0@\^P"
  >   6851      1 gxemul   RET   read 4096/0x1000
  > 
  > I expected a request of 0x1000 to just trigger the transfer of upto
  > 4096/0x1000 bytes. Why is GIO accounting for additional stuff?
 
 Well, it did read 4096 bytes. Though it's odd that it should do it in
 two chunks. However, it looks to me like this is a ktrace artifact --
 the ktrace code is not super clear but it looks like ktealloc() does
 one page at a time and ktr_io loops until it finishes. Meanwhile
 there's a ktrace header to stick into the buffer, and I'm guessing
 that header's 8 bytes, so the first ktrace record gets all but 8 bytes
 of the block and the rest goes in a second record.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost