[DTrace-devel] [PATCH v3 05/19] alloca: new bad-size fault

[Nick Alcock]

On 29 Mar 2022, Kris Van Hees said:

> On Thu, Mar 24, 2022 at 06:24:31PM +0000, Nick Alcock via DTrace-devel wrote:
>> We'll use DTRACEFLT_BADSIZE to distinguish in error messages between
>> out-of-bounds errors in bcopy and the like, and size-too-large errors.
>> (Without this, it's hard to tell if a, say, 0x12 in the fault value
>> is a nearly-NULL pointer or a wrong size.)
>
> Looking at the patch series, I only see this used on patch 10/19, in the
> implementation of dt_cg_check_outscratch_bounds() which got added because
> of the bcopy implementation needing it.  I don't think it is really conveying

... which patch series are you looking at? It's been used in
dt_cg_check_bounds as well since at least series v2.

> information that is relevant to a user.  If the size is deemed out of range,
> then you still face two potential causes:
>
>   (1) the base address is valid but we are trying to access more data than we
>       should
>   (2) the base address is invalid and we are actually trying to access a valid
>       mount of data
>
> I don't think you can really distinguish between those two cases, so even with

You could (easily), and we do. The former yields BADADDR, the latter BADSIZE.

> As such, I think we should just report BADADDR and leave it at that.  That is

No thanks. This is here because I spent over a day trying to track down
a spurious BADADDR once and couldn't figure out where the near-NULL was
coming from, when it was actually a one-byte-too-large size being
misreported as an address.

(It really is clearer. There are examples in the testcases.)