On 2/28/2023 9:46 AM, Johannes Berg wrote: > On Tue, 2023-02-28 at 09:44 -0800, Jacob Keller wrote: >> >> Previous to this change, error struct has two pointers to sections of >> memory allocated at the end of the buffer. >> >> The code used to be: >> >> - error = kmalloc(sizeof(*error) + >> - sizeof(*error->elem) * elem_len + >> - sizeof(*error->log) * log_len, GFP_ATOMIC); >> >> i.e. the elem_len is multiplying sizeof(*error->elem). >> >> The code is essentially trying to get two flexible arrays in the same >> allocation, and its a bit messy to do that. I don't see how elem_len >> could be anything other than "number of elems" given this code I removed. > > Yeah, you're right. I was thinking of more modern HW/FW too much I > guess, I see now even in the driver we have an array walk here (and it > trusts the elem_len from firmware... ahrg!) > >> I posted these mainly because I was trying to resolve all of the hits >> that were found by the coccinelle patch I made, posted at [1]. I wanted >> to get it to run clean so that we had no more struct_size hits. >> >> Dropping this would just make that patch have some hits until the driver >> is removed, eventually... >> >> Not really a big deal to me, I just didn't want to post a coccinelle >> patch without also trying to fix the handful of problems it reported, >> since the total number of reports was small. >> > > Makes sense. I don't think we'll drop the driver at any point soon, but > I also don't see it being changed much :) > > johannes I can drop this one out of the series if you don't have an intention of taking it, or I can refactor to just use size_add and array_size without converting it to flexible array, which would prevent that coccinelle patch from complaining and at least ensure that we can't overflow size and under-allocate. Do you have a preference? Thanks, Jake
