linux-kernel - Re: [RFC PATCH] s390: vfio-ap: Register the vfio

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 linux-cve-announce 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]

Message-ID: <8512bb0a-a34a-09b0-65f3-781f3d092364@linux.ibm.com>
Date:   Mon, 13 Dec 2021 16:44:39 +0100
From:   Harald Freudenberger <freude@...ux.ibm.com>
To:     Thomas Huth <thuth@...hat.com>, linux-s390@...r.kernel.org,
        Tony Krowiak <akrowiak@...ux.ibm.com>,
        Halil Pasic <pasic@...ux.ibm.com>,
        Jason Herne <jjherne@...ux.ibm.com>
Cc:     linux-kernel@...r.kernel.org, Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: [RFC PATCH] s390: vfio-ap: Register the vfio_ap module for the
 "ap" parent bus

On 01.12.21 15:11, Thomas Huth wrote:
> The crypto devices that we can use with the vfio_ap module are sitting
> on the "ap" bus, not on the "vfio_ap" bus that the module defines
> itself. With this change, the vfio_ap module now gets automatically
> loaded if a supported crypto adapter is available in the host.
>
> Signed-off-by: Thomas Huth <thuth@...hat.com>
> ---
>  Note: Marked as "RFC" since I'm not 100% sure about it ...
>        please review carefully!
>
>  drivers/s390/crypto/vfio_ap_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
> index 4d2556bc7fe5..5580e40608a4 100644
> --- a/drivers/s390/crypto/vfio_ap_drv.c
> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> @@ -39,7 +39,7 @@ static struct ap_device_id ap_queue_ids[] = {
>  	{ /* end of sibling */ },
>  };
>  
> -MODULE_DEVICE_TABLE(vfio_ap, ap_queue_ids);
> +MODULE_DEVICE_TABLE(ap, ap_queue_ids);
>  
>  /**
>   * vfio_ap_queue_dev_probe:
I had a chance to check this now.
First I have to apologize about the dispute with vfio devices appearing on the ap bus.
That's not the case with this patch. As Connie states the MODULE_DEVICE_TABLE() does not
change the parent of a device and vfio_ap_drv is a driver for ap devices and thus
belongs to the ap bus anyway.
So what's left is that with this change the vfio_ap kernel module is automatically loaded
when an ap device type 10-13 is recognized by the ap bus. So the intention of the patch
is fulfilled.
Yet another kernel module which may occupy memory but will never get used by most customers.
This may not be a problem but I had a glance at the list of kernel modules loaded on my
LPAR with and without the patch and the difference is:
...
kvm                   512000  1 vfio_ap
vfio_ap                28672  0
...
So the vfio_ap module has a dependency to the biggest kernel module ever - kvm.
Do I need to say something more?

If this dependency is removed then I would not hesitate to accept this patch. However
this is up to Tony as he is the maintainer of the vfio ap device driver.