linux-kernel - Re: [PATCH] VFIO: platform: AMD xgbe reset module

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: <3768580.4oTvTNW7Bh@wuerfel>
Date:	Fri, 16 Oct 2015 15:26:34 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Eric Auger <eric.auger@...aro.org>
Cc:	Alex Williamson <alex.williamson@...hat.com>,
	Christoffer Dall <christoffer.dall@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, eric.auger@...com,
	b.reynal@...tualopensystems.com, kvmarm@...ts.cs.columbia.edu,
	kvm@...r.kernel.org, thomas.lendacky@....com, patches@...aro.org,
	suravee.suthikulpanit@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] VFIO: platform: AMD xgbe reset module

On Friday 16 October 2015 15:06:45 Eric Auger wrote:

>  I've since forgotten his answer, but the fact that
> > __symbol_get() is only defined for modules makes it moot, we either need
> > to make symbol_get() work or define __symbol_get() for non-module
> > builds.
> I currently don't see any solution for any of those. The only solution I
> can see is someone registers the reset function pointer to vfio.
> 
> I think we could keep the existing reset modules, do the request_module
> from VFIO, using their module name registered in the lookup table. But
> instead of having the reset function in the look-up table we would have
> the reset modules register their reset function pointer to VFIO. I think
> this could work around the symbol_get issue.
> 
> This still leaves the layer violation argument though.
> 
> Assuming this works, would that be an acceptable solution, although I
> acknowledge this does not perfectly fit into the driver model?

I think it's possible to avoid the layering violation that way too,
by loading the module based on the compatible string, with a module_alias.

static void vfio_platform_get_reset(struct vfio_platform_device *vdev,
                                    struct device *dev)
{
        const char *compat;
        int (*reset)(struct vfio_platform_device *);
        int ret, i;
	char modname[256];

        ret = device_property_read_string(dev, "compatible", &compat);
        if (ret)
                return;

	reset = vfio_platform_lookup_reset(compat);
	if (!reset) {
		snprintf(modname, "vfio-reset:%s", compat);
		request_module(modname);
		reset = vfio_platform_lookup_reset(compat);
	}

	vdev->reset = reset;
}

---

#define module_vfio_reset_handler(compat, reset)			\
MODULE_ALIAS("vfio_reset" compat);					\
static int reset ## _module_init(void)					\
{									\
	return vfio_reset_register(THIS_MODULE, compat, &reset);	\
}

I think that solution is good enough, as it avoids most of the
problems with the current implementation but is a simple enough change.

	Arnd
--
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/