On 21.06.2019 16:02, Scott Long wrote:
> Hi Alexander,
>
> Thanks for the explanation, sorry I didn’t realize sooner that it’s
> not used as a copyout buffer anymore. FWIW, that code is really
> hard to read on an 80 column window, would you be ok if it was
> refactored for better readability?
S
Hi Alexander,
Thanks for the explanation, sorry I didn’t realize sooner that it’s
not used as a copyout buffer anymore. FWIW, that code is really
hard to read on an 80 column window, would you be ok if it was
refactored for better readability?
Thanks,
Scott
> On Jun 20, 2019, at 6:04 PM, Alexa
Hi Scott,
You may see this buffer content is not returned directly to user any
more. It is used only as temporary storage to pull
CDAI_TYPE_SCSI_DEVID, which is then converted into readable form,
returned to user. And the code is explicitly made to not read outside
the range that was copied to t
+1 for M_ZERO.
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
On Thu, Jun 20, 2019 at 04:59:4
Hi Alexander,
I’m not a fan of removing the M_ZERO. I understand your argument that
lengths are provided elsewhere, but having the buffer be zero’d is defensive
against future bugs that might leak buffer contents. GETATTR isn’t typically
in a performance path, is there any measurable benefit to
Author: mav
Date: Thu Jun 20 20:29:42 2019
New Revision: 349243
URL: https://svnweb.freebsd.org/changeset/base/349243
Log:
Optimize xpt_getattr().
Do not allocate temporary buffer for attributes we are going to return
as-is, just make sure to NUL-terminate them. Do not zero temporary 64K
