Re: [PATCH 17/18] libmultipath: checkers: rework mpcontext passing

[Benjamin Marzinski <bmarzins@redhat.com>]

On Tue, May 05, 2026 at 05:43:31PM +0200, Martin Wilck wrote:
> The emc_clariion path checker requires an "mpcontext" that is shared
> between the checkers for all paths of a given multipath map. This context
> is currently represented in struct multipath as a void *, the pointer to
> which is passed to the checker. The checker allocates the actual memory in
> the libcheck_mp_init() function, and changes the pointer in struct
> multipath. This is a dangerous layering violation as the checker operates
> on memory it doesn't own, and not type-safe at all.
> 
> This patch changes the mpcontext handling as follows: The void * pointer
> is replaced by a dedicated union checker_mpcontext. It only contains
> a long integer element, which is sufficient to store the information
> needed by emc_clariion.
> 
> Instead of initializing this value in mp_init, the address of the union is
> passed to libcheck_check() and libcheck_pending() if the path that is being
> checked has an associated struct multipath. Passing a union pointer
> improves compile-time type safety. In order to check whether the value is
> initialized, instead of testing for a NULL pointer like before, the code
> defines an INVALID_MPCONTEXT value. This value must obviously be chosen
> such that it doesn't represent a valid context value, which is the case for
> emc_clariion.
> 
> For a synchronous checker (like emc_clariion), libcheck_check() is allowed
> to write to this memory, because at the time of the call we know that
> pp->mpp is valid. The same holds for libcheck_pending().
> 
> This change requires checker_check() and checker_get_state() to be passed
> a "struct path *" rather than a "struct checker *". The layer separation
> happens in these functions now.
> 
> The async_checker code also gets an implementation of mpcontext handling,
> in preparation of converting emc_clariion to an async checker.
> 
> Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>