On Fri, Dec 14, 2018 at 01:56:16PM +0000, James Morse wrote:
> /me digs a bit,
>
> ghes_estatus_pool_init() allocates memory from hest_ghes_dev_register().
> Its caller is behind a 'if (!ghes_disable)' in acpi_hest_init(), and is after
> another 2 calls to apei_hest_parse().
>
> If ghes_disable is set, we don't call this thing.
> If hest_disable is set, acpi_hest_init() exits early.
> If we don't have a HEST table, acpi_hest_init() exits early.
>
> ... if the HEST table doesn't have any GHES entries, hest_ghes_dev_register() is
> called with ghes_count==0, and does nothing useful. (kmalloc_alloc_array(0,...)
> great!) But we do call ghes_estatus_pool_init().
>
> I think a check that ghes_count is non-zero before calling
> hest_ghes_dev_register() is the cleanest way to avoid this.
Grrr, what an effing mess that code is! There's hest_disable *and*
ghes_disable. Do we really need them both?
With my simplifier hat on I wanna say, we should have a single switch -
apei_disable - and kill those other two. What a damn mess that is.
> I wanted the estatus pool to be initialised before creating the platform devices
> in case the order of these things is changed in the future and they get probed
> immediately, before the pool is initialised.
Hmmm.
Actually, I meant flipping those two calls:
rc = ghes_estatus_pool_init(ghes_count);
if (rc)
goto out;
rc = apei_hest_parse(hest_parse_ghes, &ghes_arr);
if (rc)
goto err;
to
rc = apei_hest_parse(hest_parse_ghes, &ghes_arr);
if (rc)
goto err;
rc = ghes_estatus_pool_init(ghes_count);
if (rc)
goto out;
so as not to alloc the pool unnecessarily if the parsing fails.
Also, AFAICT, the order you have them in now might be a problem anyway
if
apei_hest_parse(hest_parse_ghes, &ghes_arr);
fails because then you goto err and and that pool leaks, right?
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
