| Message ID | 1443182280-15868-4-git-send-email-l.stach@pengutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Sep 25, 2015 at 01:57:15PM +0200, Lucas Stach wrote: > There is no point in keeping backwards compatibility to older > kernel versions in a driver destined to mainline. You are correct, however the repository I keep is always based on the previous non-rc kernel release, and I want it to work not only with that release, but also the future -rc's as well. It means that from time to time, I will include compatibility across a merge window, but I do intend to drop it.
On Fri, Sep 25, 2015 at 01:18:48PM +0100, Russell King - ARM Linux wrote: > On Fri, Sep 25, 2015 at 01:57:15PM +0200, Lucas Stach wrote: > > There is no point in keeping backwards compatibility to older > > kernel versions in a driver destined to mainline. > > You are correct, however the repository I keep is always based on the > previous non-rc kernel release, and I want it to work not only with > that release, but also the future -rc's as well. It means that from > time to time, I will include compatibility across a merge window, but > I do intend to drop it. I'm not sure what version you've generated this patch against, but I can't apply it without significant changes to your patch. I think instead, I'm going to create a patch removing the v4.1 code from my commit myself, and merge it into my original commit as the 4.1 code is no longer relevant.
Am Mittwoch, den 21.10.2015, 12:35 +0100 schrieb Russell King - ARM Linux: > On Fri, Sep 25, 2015 at 01:18:48PM +0100, Russell King - ARM Linux wrote: > > On Fri, Sep 25, 2015 at 01:57:15PM +0200, Lucas Stach wrote: > > > There is no point in keeping backwards compatibility to older > > > kernel versions in a driver destined to mainline. > > > > You are correct, however the repository I keep is always based on the > > previous non-rc kernel release, and I want it to work not only with > > that release, but also the future -rc's as well. It means that from > > time to time, I will include compatibility across a merge window, but > > I do intend to drop it. > > I'm not sure what version you've generated this patch against, but I > can't apply it without significant changes to your patch. > > I think instead, I'm going to create a patch removing the v4.1 code > from my commit myself, and merge it into my original commit as the > 4.1 code is no longer relevant. > That's fine with me. Regards, Lucas
On Wed, Oct 21, 2015 at 02:37:16PM +0200, Lucas Stach wrote: > Am Mittwoch, den 21.10.2015, 12:35 +0100 schrieb Russell King - ARM > Linux: > > On Fri, Sep 25, 2015 at 01:18:48PM +0100, Russell King - ARM Linux wrote: > > > On Fri, Sep 25, 2015 at 01:57:15PM +0200, Lucas Stach wrote: > > > > There is no point in keeping backwards compatibility to older > > > > kernel versions in a driver destined to mainline. > > > > > > You are correct, however the repository I keep is always based on the > > > previous non-rc kernel release, and I want it to work not only with > > > that release, but also the future -rc's as well. It means that from > > > time to time, I will include compatibility across a merge window, but > > > I do intend to drop it. > > > > I'm not sure what version you've generated this patch against, but I > > can't apply it without significant changes to your patch. > > > > I think instead, I'm going to create a patch removing the v4.1 code > > from my commit myself, and merge it into my original commit as the > > 4.1 code is no longer relevant. > > > > That's fine with me. Applying these patches on top of my drm-etnaviv-devel branch: staging: etnaviv: debugfs: add possibility to dump kernel buffer staging: etnaviv: change etnaviv_buffer_init() to return prefetch staging: etnaviv: remove submit type staging: etnaviv: rewrite submit interface to use copy from user with the corresponding DDX changes results in a kernel which silently locks solid when Xorg starts up.
Am Mittwoch, den 21.10.2015, 14:37 +0100 schrieb Russell King - ARM Linux: > On Wed, Oct 21, 2015 at 02:37:16PM +0200, Lucas Stach wrote: > > Am Mittwoch, den 21.10.2015, 12:35 +0100 schrieb Russell King - ARM > > Linux: > > > On Fri, Sep 25, 2015 at 01:18:48PM +0100, Russell King - ARM Linux wrote: > > > > On Fri, Sep 25, 2015 at 01:57:15PM +0200, Lucas Stach wrote: > > > > > There is no point in keeping backwards compatibility to older > > > > > kernel versions in a driver destined to mainline. > > > > > > > > You are correct, however the repository I keep is always based on the > > > > previous non-rc kernel release, and I want it to work not only with > > > > that release, but also the future -rc's as well. It means that from > > > > time to time, I will include compatibility across a merge window, but > > > > I do intend to drop it. > > > > > > I'm not sure what version you've generated this patch against, but I > > > can't apply it without significant changes to your patch. > > > > > > I think instead, I'm going to create a patch removing the v4.1 code > > > from my commit myself, and merge it into my original commit as the > > > 4.1 code is no longer relevant. > > > > > > > That's fine with me. > > Applying these patches on top of my drm-etnaviv-devel branch: > > staging: etnaviv: debugfs: add possibility to dump kernel buffer > staging: etnaviv: change etnaviv_buffer_init() to return prefetch > staging: etnaviv: remove submit type > staging: etnaviv: rewrite submit interface to use copy from user > > with the corresponding DDX changes results in a kernel which silently > locks solid when Xorg starts up. > For the ML records: As discussed on IRC this is another case of missing input validation with userspace passing in wrong reloc offsets, the kernel omitting proper validation and consequently stomping over unrelated memory.
On Wed, Oct 21, 2015 at 04:53:50PM +0200, Lucas Stach wrote: > Am Mittwoch, den 21.10.2015, 14:37 +0100 schrieb Russell King - ARM > Linux: > > On Wed, Oct 21, 2015 at 02:37:16PM +0200, Lucas Stach wrote: > > > Am Mittwoch, den 21.10.2015, 12:35 +0100 schrieb Russell King - ARM > > > Linux: > > > > On Fri, Sep 25, 2015 at 01:18:48PM +0100, Russell King - ARM Linux wrote: > > > > > On Fri, Sep 25, 2015 at 01:57:15PM +0200, Lucas Stach wrote: > > > > > > There is no point in keeping backwards compatibility to older > > > > > > kernel versions in a driver destined to mainline. > > > > > > > > > > You are correct, however the repository I keep is always based on the > > > > > previous non-rc kernel release, and I want it to work not only with > > > > > that release, but also the future -rc's as well. It means that from > > > > > time to time, I will include compatibility across a merge window, but > > > > > I do intend to drop it. > > > > > > > > I'm not sure what version you've generated this patch against, but I > > > > can't apply it without significant changes to your patch. > > > > > > > > I think instead, I'm going to create a patch removing the v4.1 code > > > > from my commit myself, and merge it into my original commit as the > > > > 4.1 code is no longer relevant. > > > > > > > > > > That's fine with me. > > > > Applying these patches on top of my drm-etnaviv-devel branch: > > > > staging: etnaviv: debugfs: add possibility to dump kernel buffer > > staging: etnaviv: change etnaviv_buffer_init() to return prefetch > > staging: etnaviv: remove submit type > > staging: etnaviv: rewrite submit interface to use copy from user > > > > with the corresponding DDX changes results in a kernel which silently > > locks solid when Xorg starts up. > > > For the ML records: > > As discussed on IRC this is another case of missing input validation > with userspace passing in wrong reloc offsets, the kernel omitting > proper validation and consequently stomping over unrelated memory. I think it wasn't stomping on unrelated memory, but on parts of the command buffer which were part of valid commands for the GPU - and changing them to be invalid commands. I wonder how many GPU drivers that's possible - how many verify that the list of relocations points to places that need addresses filled in and not GPU commands... and can relocations be used to exploit the GPU to do something it shouldn't. I guess that's less of a problem where the GPU sits behind an IOMMU which prevents it getting at random bits of user memory, but allowing userspace to trample over the command stream in this way can't be good.
diff --git a/drivers/staging/etnaviv/etnaviv_iommu.c b/drivers/staging/etnaviv/etnaviv_iommu.c index 5735319215a3..8f92578ea3ee 100644 --- a/drivers/staging/etnaviv/etnaviv_iommu.c +++ b/drivers/staging/etnaviv/etnaviv_iommu.c @@ -20,16 +20,11 @@ #include <linux/slab.h> #include <linux/dma-mapping.h> #include <linux/bitops.h> -#include <linux/version.h> #include "etnaviv_gpu.h" #include "etnaviv_iommu.h" #include "state_hi.xml.h" -#if LINUX_VERSION_CODE < KERNEL_VERSION(4,1,0) -#define OLD_IOMMU -#endif - #define PT_SIZE SZ_512K #define PT_ENTRIES (PT_SIZE / sizeof(uint32_t)) @@ -126,33 +121,17 @@ static int __etnaviv_iommu_init(struct etnaviv_iommu_domain *etnaviv_domain) return 0; } -static void __etnaviv_iommu_free(struct etnaviv_iommu_domain *etnaviv_domain) +static void etnaviv_domain_free(struct iommu_domain *domain) { - pgtable_free(&etnaviv_domain->pgtable, PT_SIZE); + struct etnaviv_iommu_domain *etnaviv_domain = to_etnaviv_domain(domain); + pgtable_free(&etnaviv_domain->pgtable, PT_SIZE); dma_free_coherent(etnaviv_domain->dev, SZ_4K, etnaviv_domain->bad_page_cpu, etnaviv_domain->bad_page_dma); - kfree(etnaviv_domain); } -#ifdef OLD_IOMMU -static void etnaviv_iommu_domain_destroy(struct iommu_domain *domain) -{ - struct etnaviv_iommu_domain *etnaviv_domain = domain->priv; - - __etnaviv_iommu_free(etnaviv_domain); - - domain->priv = NULL; -} -#else -static void etnaviv_domain_free(struct iommu_domain *domain) -{ - __etnaviv_iommu_free(to_etnaviv_domain(domain)); -} -#endif - static int etnaviv_iommu_map(struct iommu_domain *domain, unsigned long iova, phys_addr_t paddr, size_t size, int prot) { @@ -193,11 +172,7 @@ static phys_addr_t etnaviv_iommu_iova_to_phys(struct iommu_domain *domain, } static struct iommu_ops etnaviv_iommu_ops = { -#ifdef OLD_IOMMU - .domain_destroy = etnaviv_iommu_domain_destroy, -#else .domain_free = etnaviv_domain_free, -#endif .map = etnaviv_iommu_map, .unmap = etnaviv_iommu_unmap, .iova_to_phys = etnaviv_iommu_iova_to_phys, @@ -231,9 +206,7 @@ struct iommu_domain *etnaviv_iommu_domain_alloc(struct etnaviv_gpu *gpu) etnaviv_domain->dev = gpu->dev; -#ifndef OLD_IOMMU etnaviv_domain->domain.type = __IOMMU_DOMAIN_PAGING; -#endif etnaviv_domain->domain.ops = &etnaviv_iommu_ops; etnaviv_domain->domain.geometry.aperture_start = GPU_MEM_START; etnaviv_domain->domain.geometry.aperture_end = GPU_MEM_START + PT_ENTRIES * SZ_4K;
There is no point in keeping backwards compatibility to older kernel versions in a driver destined to mainline. May squash this patch into "staging: etnaviv: restructure iommu handling" Signed-off-by: Lucas Stach <l.stach@pengutronix.de> --- drivers/staging/etnaviv/etnaviv_iommu.c | 33 +++------------------------------ 1 file changed, 3 insertions(+), 30 deletions(-)