On δΈ‰, 2019-01-30 at 11:04 +0100, Daniel Lezcano wrote: > On 30/01/2019 10:25, Pi-Hsun Shih wrote: > > > > On Wed, Jan 30, 2019 at 3:44 PM Daniel Lezcano > > <daniel.lezc...@linaro.org> wrote: > > > > > > > > > On 30/01/2019 07:04, Peter Shih wrote: > > > > > > > > Adding Michael Kao to cc list. > > > > > > > > On Wed, Jan 9, 2019 at 1:57 PM Pi-Hsun Shih <pih...@chromium.or > > > > g> wrote: > > > > > > > > > > > > > > > The mtk_thermal struct contains a 'struct mtk_thermal_bank > > > > > banks[];', > > > > > but the allocation only allocates sizeof(struct mtk_thermal) > > > > > bytes, > > > > > which cause out of bound access with the ->banks[] member. > > > > > Change it to > > > > > a fixed size array instead. > > > Even if the fix is correct, it pushes back the bug later in time > > > if a > > > new board containing more than MAX_NUM_ZONES is introduced. I > > > suggest to > > > dynamically allocate the array with the 'num_banks' value. > > > > > For the current code structure, those mtk_thermal_data are > > statically declared, > > so if there's new board containing more than MAX_NUM_ZONES of > > bank_data, it > > would actually be a compile error. > > > > I'm fine with either way, but feel like that this is simpler than > > manually > > calculating the size needed for allocation. > Right, I missed it can be caught at compile time. > > Reviewed-by: Daniel Lezcano <daniel.lezc...@linaro.org> > As this is a bugfix, I will take it and queue it for next -rc.
thanks, rui > >
