On 06/11/2023 16:28, Kevin Brodsky wrote:
On 04/11/2023 00:21, Tudor Cretu wrote:
Why do you have &ic_ptr->response[0] here? That should be equivalent to ic_ptr->response, unless I'm missing something. ic_ptr->response looks correct here, but this is different from what it was before &(ic_ptr->response), so I'm sligthly confused. Is this a bug in the upstream kernel...?
Ah, that is a good point, I hadn't realised what the original code was going. We talked about this offline with Akram, clearly what we want here is a standard pointer to the buffer, which can be obtained in two ways:
- Array to pointer decay: ic_ptr->response
- Taking the address of the first member: &ic_ptr->response[0]
Both approaches are fairly common, but I agree it would make sense to prefer the first one, to match the source pointer (ic->response).
The existing code does seem to be confused. &ic_ptr->response yields a pointer to array, of type __u32 (*)[4]. This goes unnoticed because copy_to_user() takes a void *, so any pointer type is acceptable. This is certainly unnecessary complication though (and arithmetic on that pointer would not work as intended). It wouldn't hurt to fix that upstream, though it doesn't seem to be essential either.
Kevin _______________________________________________ linux-morello mailing list -- linux-morello@op-lists.linaro.org To unsubscribe send an email to linux-morello-leave@op-lists.linaro.org
Thanks for the feedback Tudor! Just to confirm in that case, shall I correct this in V6? I.e. use the array to pointer decay rather than the address of the first member.
Many thanks,
Akram