lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 29 Dec 2014 13:41:48 +0100
From:	Christian König <deathsimple@...afone.de>
To:	Oded Gabbay <oded.gabbay@....com>, dri-devel@...ts.freedesktop.org,
	Alexander Deucher <Alexander.Deucher@....com>
CC:	linux-kernel@...r.kernel.org, Huang Ying <ying.huang@...el.com>,
	LKP ML <lkp@...org>, ak@...ux.intel.com, rusty@...tcorp.com.au,
	airlied@...ux.ie
Subject: Re: [PATCH v2] drm/radeon: Init amdkfd only if it was compiled

Am 29.12.2014 um 09:59 schrieb Oded Gabbay:
> This patch changes the radeon_kfd_init(), which is used to initialize the
> interface between radeon and amdkfd, so the interface will be initialized only
> if amdkfd was build, either as module or inside the kernel image.
>
> In the modules case, the symbol_request() will be used (same as old code). In
> the in-image compilation case, a direct call to kgd2kfd_init() will be done.
> For other cases, radeon_kfd_init() will just return false.
>
> This patch is necessary because in case of the following specific
> configuration: kernel 32-bit, no modules support, random kernel base and no
> hibernation, the symbol_request() doesn't work as expected - it doesn't return
> NULL if the symbol doesn't exists - which makes the kernel panic.
>
> Signed-off-by: Oded Gabbay <oded.gabbay@....com>

Using symbol_request() in general doesn't seem to be such a good idea, 
because it breaks symbol versioning and as far as I can see is only very 
rarely used in drivers (AFAIK only V4L drivers).

But for the moment I don't have another idea either except for always 
loading the module which on most hardware is completely unnecessary. 
Maybe we should consider restructuring the module load dependencies in 
the next kernel release.

For now the patch is Reviewed-by: Christian König <christian.koenig@....com>

> ---
>   drivers/gpu/drm/radeon/radeon_kfd.c | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c b/drivers/gpu/drm/radeon/radeon_kfd.c
> index 242fd8b..d3e78b4 100644
> --- a/drivers/gpu/drm/radeon/radeon_kfd.c
> +++ b/drivers/gpu/drm/radeon/radeon_kfd.c
> @@ -101,6 +101,7 @@ static const struct kgd2kfd_calls *kgd2kfd;
>   
>   bool radeon_kfd_init(void)
>   {
> +#if defined(CONFIG_HSA_AMD_MODULE)
>   	bool (*kgd2kfd_init_p)(unsigned, const struct kfd2kgd_calls*,
>   				const struct kgd2kfd_calls**);
>   
> @@ -117,6 +118,17 @@ bool radeon_kfd_init(void)
>   	}
>   
>   	return true;
> +#elif defined(CONFIG_HSA_AMD)
> +	if (!kgd2kfd_init(KFD_INTERFACE_VERSION, &kfd2kgd, &kgd2kfd)) {
> +		kgd2kfd = NULL;
> +
> +		return false;
> +	}
> +
> +	return true;
> +#else
> +	return false;
> +#endif
>   }
>   
>   void radeon_kfd_fini(void)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists