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
| ||
|
Date: Thu, 22 Oct 2015 12:12:23 +0200 From: Arnd Bergmann <arnd@...db.de> To: Eric Auger <eric.auger@...aro.org> Cc: eric.auger@...com, alex.williamson@...hat.com, b.reynal@...tualopensystems.com, linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu, kvm@...r.kernel.org, christoffer.dall@...aro.org, linux-kernel@...r.kernel.org, patches@...aro.org Subject: Re: [PATCH v2 2/6] vfio: platform: reset: add vfio_platform_reset_private.h On Thursday 22 October 2015 11:41:58 Eric Auger wrote: > v2: creation > - this defines the module_vfio_reset_handler macro as suggested by Arnd > > Although Arnd suggested me to remove the vfio_platform_register_reset > symbol_get (since the module manager can handle the case where the > vfio-platform driver is not loaded), I prefered to keep it while > introducing the macro. The rationale is, when using symbol_get/put > we are able to release the hold from the reset module on vfio-platform > as soon as the registration is complete and I think this makes sense. This makes it highly unusual. I can't think of a good reason to allow unloading the vfio platform module while a reset module is registered, that just causes a memory leak (or possibly a crash) when you do unload the core module while it's used by a reset driver, it prevents the reset module from getting loaded without loading the vfio module first (because the autoloading doesn't work), and it means we don't catch build errors in invalid configurations where you have only the reset driver but not the vfio driver enabled. 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/
Powered by blists - more mailing lists