November 2020 - Linux-stable-mirror

[PATCH v3] riscv: set max_pfn to the PFN of the last page

by Vincent Chen

The current max_pfn equals to zero. In this case, I found it caused users cannot get some page information through /proc such as kpagecount in v5.6 kernel because of new sanity checks. The following message is displayed by stress-ng test suite with the command "stress-ng --verbose --physpage 1 -t 1" on HiFive unleashed board. # stress-ng --verbose --physpage 1 -t 1 stress-ng: debug: [109] 4 processors online, 4 processors configured stress-ng: info: [109] dispatching hogs: 1 physpage stress-ng: debug: [109] cache allocate: reducing cache level from L3 (too high) to L0 stress-ng: debug: [109] get_cpu_cache: invalid cache_level: 0 stress-ng: info: [109] cache allocate: using built-in defaults as no suitable cache found stress-ng: debug: [109] cache allocate: default cache size: 2048K stress-ng: debug: [109] starting stressors stress-ng: debug: [109] 1 stressor spawned stress-ng: debug: [110] stress-ng-physpage: started [110] (instance 0) stress-ng: error: [110] stress-ng-physpage: cannot read page count for address 0x3fd34de000 in /proc/kpagecount, errno=0 (Success) stress-ng: error: [110] stress-ng-physpage: cannot read page count for address 0x3fd32db078 in /proc/kpagecount, errno=0 (Success) ... stress-ng: error: [110] stress-ng-physpage: cannot read page count for address 0x3fd32db078 in /proc/kpagecount, errno=0 (Success) stress-ng: debug: [110] stress-ng-physpage: exited [110] (instance 0) stress-ng: debug: [109] process [110] terminated stress-ng: info: [109] successful run completed in 1.00s # After applying this patch, the kernel can pass the test. # stress-ng --verbose --physpage 1 -t 1 stress-ng: debug: [104] 4 processors online, 4 processors configured stress-ng: info: [104] dispatching hogs: 1 physpage stress-ng: info: [104] cache allocate: using defaults, can't determine cache details from sysfs stress-ng: debug: [104] cache allocate: default cache size: 2048K stress-ng: debug: [104] starting stressors stress-ng: debug: [104] 1 stressor spawned stress-ng: debug: [105] stress-ng-physpage: started [105] (instance 0) stress-ng: debug: [105] stress-ng-physpage: exited [105] (instance 0) stress-ng: debug: [104] process [105] terminated stress-ng: info: [104] successful run completed in 1.01s # Fixes: 0651c263c8e3 (RISC-V: Move setup_bootmem() to mm/init.c) Cc: stable(a)vger.kernel.org Signed-off-by: Vincent Chen <vincent.chen(a)sifive.com> Reviewed-by: Anup Patel <anup(a)brainfault.org> Reviewed-by: Yash Shah <yash.shah(a)sifive.com> Tested-by: Yash Shah <yash.shah(a)sifive.com> Changes since v1: 1. Add Fixes line and Cc stable kernel Changes since v2: 1. Fix typo in Anup email address --- arch/riscv/mm/init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index fab855963c73..157924baa191 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -149,7 +149,8 @@ void __init setup_bootmem(void) memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start); set_max_mapnr(PFN_DOWN(mem_size)); - max_low_pfn = PFN_DOWN(memblock_end_of_DRAM()); + max_pfn = PFN_DOWN(memblock_end_of_DRAM()); + max_low_pfn = max_pfn; #ifdef CONFIG_BLK_DEV_INITRD setup_initrd(); -- 2.7.4

3 years, 2 months

3
2
0 0

[PATCH] drm/i915/gt: Program mocs:63 for cache eviction on gen9

by Chris Wilson

Ville noticed that the last mocs entry is used unconditionally by the HW when it performs cache evictions, and noted that while the value is not meant to be writable by the driver, we should program it to a reasonable value nevertheless. As it turns out, we can change the value of mocs:63 and the value we were programming into it would cause hard hangs in conjunction with atomic operations. Suggested-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2707 Fixes: 3bbaba0ceaa2 ("drm/i915: Added Programming of the MOCS") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Jason Ekstrand <jason(a)jlekstrand.net> Cc: <stable(a)vger.kernel.org> # v4.3+ --- drivers/gpu/drm/i915/gt/intel_mocs.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c b/drivers/gpu/drm/i915/gt/intel_mocs.c index 254873e1646e..6ae512847f64 100644 --- a/drivers/gpu/drm/i915/gt/intel_mocs.c +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c @@ -131,7 +131,10 @@ static const struct drm_i915_mocs_entry skl_mocs_table[] = { GEN9_MOCS_ENTRIES, MOCS_ENTRY(I915_MOCS_CACHED, LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3), - L3_3_WB) + L3_3_WB), + MOCS_ENTRY(63, + LE_3_WB | LE_TC_1_LLC | LE_LRUM(3), + L3_1_UC) }; /* NOTE: the LE_TGT_CACHE is not used on Broxton */ -- 2.20.1

3 years, 2 months

3
4
0 0

[PATCH v1] trace: Fix race in trace_open and buffer resize call

by Gaurav Kohli

Below race can come, if trace_open and resize of cpu buffer is running parallely on different cpus CPUX CPUY ring_buffer_resize atomic_read(&buffer->resize_disabled) tracing_open tracing_reset_online_cpus ring_buffer_reset_cpu rb_reset_cpu rb_update_pages remove/insert pages resetting pointer This race can cause data abort or some times infinte loop in rb_remove_pages and rb_insert_pages while checking pages for sanity. Take buffer lock to fix this. Signed-off-by: Gaurav Kohli <gkohli(a)codeaurora.org> Cc: stable(a)vger.kernel.org --- Changes since v0: -Addressed Steven's review comments. diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 93ef0ab..15bf28b 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -4866,6 +4866,9 @@ void ring_buffer_reset_cpu(struct trace_buffer *buffer, int cpu) if (!cpumask_test_cpu(cpu, buffer->cpumask)) return; + /* prevent another thread from changing buffer sizes */ + mutex_lock(&buffer->mutex); + atomic_inc(&cpu_buffer->resize_disabled); atomic_inc(&cpu_buffer->record_disabled); @@ -4876,6 +4879,8 @@ void ring_buffer_reset_cpu(struct trace_buffer *buffer, int cpu) atomic_dec(&cpu_buffer->record_disabled); atomic_dec(&cpu_buffer->resize_disabled); + + mutex_unlock(&buffer->mutex); } EXPORT_SYMBOL_GPL(ring_buffer_reset_cpu); @@ -4889,6 +4894,9 @@ void ring_buffer_reset_online_cpus(struct trace_buffer *buffer) struct ring_buffer_per_cpu *cpu_buffer; int cpu; + /* prevent another thread from changing buffer sizes */ + mutex_lock(&buffer->mutex); + for_each_online_buffer_cpu(buffer, cpu) { cpu_buffer = buffer->buffers[cpu]; @@ -4907,6 +4915,8 @@ void ring_buffer_reset_online_cpus(struct trace_buffer *buffer) atomic_dec(&cpu_buffer->record_disabled); atomic_dec(&cpu_buffer->resize_disabled); } + + mutex_unlock(&buffer->mutex); } /** -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 years, 2 months

4
12
0 0

Re: [PATCH 1/1] kernel/crash_core.c - Add crashkernel=auto for x86 and ARM

by Kairui Song

On Fri, Nov 20, 2020 at 4:28 AM Saeed Mirzamohammadi <saeed.mirzamohammadi(a)oracle.com> wrote: > > Hi, > > And I think crashkernel=auto could be used as an indicator that user > want the kernel to control the crashkernel size, so some further work > could be done to adjust the crashkernel more accordingly. eg. when > memory encryption is enabled, increase the crashkernel value for the > auto estimation, as it's known to consume more crashkernel memory. > > Thanks for the suggestion! I tried to keep it simple and leave it to the user to change Kconfig in case a different range is needed. Based on experience, these ranges work well for most of the regular cases. Yes, I think the current implementation is a very good start. There are some use cases, where kernel is expected to reserve more memory, like: - when memory encryption is enabled, an extra swiotlb size of memory should be reserved - on pcc, fadump will expect more memory to be reserved I believe there are a lot more cases like these. I tried to come up with some patches to let the kernel reserve more memory automatically, when such conditions are detected, but changing the crashkernel= specified value is really weird. But if we have a crashkernel=auto, then kernel automatically reserve more memory will make sense. > But why not make it arch-independent? This crashkernel=auto idea > should simply work with every arch. > > > Thanks! I’ll be making it arch-independent in the v2 patch. > > > #include <asm/page.h> > #include <asm/sections.h> > @@ -41,6 +42,15 @@ static int __init parse_crashkernel_mem(char *cmdline, > unsigned long long *crash_base) > { > char *cur = cmdline, *tmp; > + unsigned long long total_mem = system_ram; > + > + /* > + * Firmware sometimes reserves some memory regions for it's own use. > + * so we get less than actual system memory size. > + * Workaround this by round up the total size to 128M which is > + * enough for most test cases. > + */ > + total_mem = roundup(total_mem, SZ_128M); > > > I think this rounding may be better moved to the arch specified part > where parse_crashkernel is called? > > > Thanks for the suggestion. Could you please elaborate why do we need to do that? Every arch gets their total memory value using different methods, (just check every parse_crashkernel call, and the system_ram param is filled in many different ways), so I'm really not sure if this rounding is always suitable. > > Thanks, > Saeed > > -- Best Regards, Kairui Song

3 years, 2 months

4
5
0 0

[RESEND PATCH] PCI: qcom: use PHY_REFCLK_USE_PAD only for ipq8064

by Ansuel Smith

The use of PHY_REFCLK_USE_PAD introduced a regression for apq8064 devices. It was tested that while apq doesn't require the padding, ipq SoC must use it or the kernel hangs on boot. Fixes: de3c4bf6489 ("PCI: qcom: Add support for tx term offset for rev 2.1.0") Reported-by: Ilia Mirkin <imirkin(a)alum.mit.edu> Signed-off-by: Ilia Mirkin <imirkin(a)alum.mit.edu> Signed-off-by: Ansuel Smith <ansuelsmth(a)gmail.com> Cc: stable(a)vger.kernel.org # v4.19+ --- drivers/pci/controller/dwc/pcie-qcom.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c index 3aac77a295ba..dad6e9ce66ba 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -387,7 +387,9 @@ static int qcom_pcie_init_2_1_0(struct qcom_pcie *pcie) /* enable external reference clock */ val = readl(pcie->parf + PCIE20_PARF_PHY_REFCLK); - val &= ~PHY_REFCLK_USE_PAD; + /* USE_PAD is required only for ipq806x */ + if (!of_device_is_compatible(node, "qcom,pcie-apq8064")) + val &= ~PHY_REFCLK_USE_PAD; val |= PHY_REFCLK_SSP_EN; writel(val, pcie->parf + PCIE20_PARF_PHY_REFCLK); -- 2.27.0

3 years, 3 months

3
3
0 0

[PATCH AUTOSEL 5.7 01/30] drm/msm: fix potential memleak in error branch

by Sasha Levin

From: Bernard Zhao <bernard(a)vivo.com> [ Upstream commit 177d3819633cd520e3f95df541a04644aab4c657 ] In function msm_submitqueue_create, the queue is a local variable, in return -EINVAL branch, queue didn`t add to ctx`s list yet, and also didn`t kfree, this maybe bring in potential memleak. Signed-off-by: Bernard Zhao <bernard(a)vivo.com> [trivial commit msg fixup] Signed-off-by: Rob Clark <robdclark(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c b/drivers/gpu/drm/msm/msm_submitqueue.c index 001fbf537440a..a1d94be7883a0 100644 --- a/drivers/gpu/drm/msm/msm_submitqueue.c +++ b/drivers/gpu/drm/msm/msm_submitqueue.c @@ -71,8 +71,10 @@ int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private *ctx, queue->flags = flags; if (priv->gpu) { - if (prio >= priv->gpu->nr_rings) + if (prio >= priv->gpu->nr_rings) { + kfree(queue); return -EINVAL; + } queue->prio = prio; } -- 2.25.1

3 years, 3 months

5
27
0 0

[PATCH 1/3] bfq: Avoid false bfq queue merging

by Jan Kara

bfq_setup_cooperator() uses bfqd->in_serv_last_pos so detect whether it makes sense to merge current bfq queue with the in-service queue. However if the in-service queue is freshly scheduled and didn't dispatch any requests yet, bfqd->in_serv_last_pos is stale and contains value from the previously scheduled bfq queue which can thus result in a bogus decision that the two queues should be merged. This bug can be observed for example with the following fio jobfile: [global] direct=0 ioengine=sync invalidate=1 size=1g rw=read [reader] numjobs=4 directory=/mnt where the 4 processes will end up in the one shared bfq queue although they do IO to physically very distant files (for some reason I was able to observe this only with slice_idle=1ms setting). Fix the problem by invalidating bfqd->in_serv_last_pos when switching in-service queue. Fixes: 058fdecc6de7 ("block, bfq: fix in-service-queue check for queue merging") CC: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> --- block/bfq-iosched.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 3d411716d7ee..50017275915f 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -2937,6 +2937,7 @@ static void __bfq_set_in_service_queue(struct bfq_data *bfqd, } bfqd->in_service_queue = bfqq; + bfqd->in_serv_last_pos = 0; } /* -- 2.16.4

3 years, 3 months

2
4
0 0

[PATCH] drm/i915/gt: Limit VFE threads based on GT

by Chris Wilson

MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the range [0, n-1] where n is #EU * (#threads/EU) with the number of threads based on plaform and the number of EU based on the number of slices and subslices. This is a fixed number per platform/gt, so appropriately limit the number of threads we spawn to match the device. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024 Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan(a)intel.com> Cc: Akeem G Abodunrin <akeem.g.abodunrin(a)intel.com> Cc: Balestrieri Francesco <francesco.balestrieri(a)intel.com> Cc: Bloomfield Jon <jon.bloomfield(a)intel.com> Cc: <stable(a)vger.kernel.org> # v5.7+ --- drivers/gpu/drm/i915/gt/gen7_renderclear.c | 35 +++++++++++++++------- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c b/drivers/gpu/drm/i915/gt/gen7_renderclear.c index d93d85cd3027..f3b8fea6226e 100644 --- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c +++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c @@ -7,8 +7,6 @@ #include "i915_drv.h" #include "intel_gpu_commands.h" -#define MAX_URB_ENTRIES 64 -#define STATE_SIZE (4 * 1024) #define GT3_INLINE_DATA_DELAYS 0x1E00 #define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS)) @@ -34,8 +32,7 @@ struct batch_chunk { }; struct batch_vals { - u32 max_primitives; - u32 max_urb_entries; + u32 max_primitives; /* == number of VFE threads */ u32 cmd_size; u32 state_size; u32 state_start; @@ -50,18 +47,35 @@ static void batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv) { if (IS_HASWELL(i915)) { - bv->max_primitives = 280; - bv->max_urb_entries = MAX_URB_ENTRIES; + switch (INTEL_INFO(i915)->gt) { + default: + case 1: + bv->max_primitives = 70; + break; + case 2: + bv->max_primitives = 140; + break; + case 3: + bv->max_primitives = 280; + break; + } bv->surface_height = 16 * 16; bv->surface_width = 32 * 2 * 16; } else { - bv->max_primitives = 128; - bv->max_urb_entries = MAX_URB_ENTRIES / 2; + switch (INTEL_INFO(i915)->gt) { + default: + case 1: /* including vlv */ + bv->max_primitives = 36; + break; + case 2: + bv->max_primitives = 128; + break; + } bv->surface_height = 16 * 8; bv->surface_width = 32 * 16; } bv->cmd_size = bv->max_primitives * 4096; - bv->state_size = STATE_SIZE; + bv->state_size = SZ_4K; bv->state_start = bv->cmd_size; bv->batch_size = bv->cmd_size + bv->state_size; bv->scratch_size = bv->surface_height * bv->surface_width; @@ -244,7 +258,6 @@ gen7_emit_vfe_state(struct batch_chunk *batch, u32 urb_size, u32 curbe_size, u32 mode) { - u32 urb_entries = bv->max_urb_entries; u32 threads = bv->max_primitives - 1; u32 *cs = batch_alloc_items(batch, 32, 8); @@ -254,7 +267,7 @@ gen7_emit_vfe_state(struct batch_chunk *batch, *cs++ = 0; /* number of threads & urb entries for GPGPU vs Media Mode */ - *cs++ = threads << 16 | urb_entries << 8 | mode << 2; + *cs++ = threads << 16 | 1 << 8 | mode << 2; *cs++ = 0; -- 2.20.1

3 years, 3 months

3
3
0 0

[BACKPORT] xen/pvh: correctly setup the PV EFI interface for dom0

by Roger Pau Monne

commit 72813bfbf0276a97c82af038efb5f02dcdd9e310 upstream This involves initializing the boot params EFI related fields and the efi global variable. Without this fix a PVH dom0 doesn't detect when booted from EFI, and thus doesn't support accessing any of the EFI related data. Reported-by: PGNet Dev <pgnet.dev(a)gmail.com> Signed-off-by: Roger Pau Monné <roger.pau(a)citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Cc: stable(a)vger.kernel.org # 4.19+ --- arch/x86/xen/efi.c | 12 ++++++------ arch/x86/xen/enlighten_pv.c | 2 +- arch/x86/xen/enlighten_pvh.c | 4 ++++ arch/x86/xen/xen-ops.h | 4 ++-- 4 files changed, 13 insertions(+), 9 deletions(-) diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c index 1804b27f9632..30edb9bc58e2 100644 --- a/arch/x86/xen/efi.c +++ b/arch/x86/xen/efi.c @@ -170,7 +170,7 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void) return efi_secureboot_mode_unknown; } -void __init xen_efi_init(void) +void __init xen_efi_init(struct boot_params *boot_params) { efi_system_table_t *efi_systab_xen; @@ -179,12 +179,12 @@ void __init xen_efi_init(void) if (efi_systab_xen == NULL) return; - strncpy((char *)&boot_params.efi_info.efi_loader_signature, "Xen", - sizeof(boot_params.efi_info.efi_loader_signature)); - boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen); - boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32); + strncpy((char *)&boot_params->efi_info.efi_loader_signature, "Xen", + sizeof(boot_params->efi_info.efi_loader_signature)); + boot_params->efi_info.efi_systab = (__u32)__pa(efi_systab_xen); + boot_params->efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32); - boot_params.secure_boot = xen_efi_get_secureboot(); + boot_params->secure_boot = xen_efi_get_secureboot(); set_bit(EFI_BOOT, &efi.flags); set_bit(EFI_PARAVIRT, &efi.flags); diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 782f98b332f0..0f8da4aebe7b 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -1399,7 +1399,7 @@ asmlinkage __visible void __init xen_start_kernel(void) /* We need this for printk timestamps */ xen_setup_runstate_info(0); - xen_efi_init(); + xen_efi_init(&boot_params); /* Start the world */ #ifdef CONFIG_X86_32 diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c index dab07827d25e..f04d22bcf08d 100644 --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -14,6 +14,8 @@ #include <xen/interface/memory.h> #include <xen/interface/hvm/start_info.h> +#include "xen-ops.h" + /* * PVH variables. * @@ -79,6 +81,8 @@ static void __init init_pvh_bootparams(void) pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ x86_init.acpi.get_root_pointer = pvh_get_root_pointer; + + xen_efi_init(&pvh_bootparams); } /* diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h index 0e60bd918695..2f111f47ba98 100644 --- a/arch/x86/xen/xen-ops.h +++ b/arch/x86/xen/xen-ops.h @@ -122,9 +122,9 @@ static inline void __init xen_init_vga(const struct dom0_vga_console_info *info, void __init xen_init_apic(void); #ifdef CONFIG_XEN_EFI -extern void xen_efi_init(void); +extern void xen_efi_init(struct boot_params *boot_params); #else -static inline void __init xen_efi_init(void) +static inline void __init xen_efi_init(struct boot_params *boot_params) { } #endif -- 2.20.1 (Apple Git-117)

3 years, 3 months

3
2
0 0

[PATCH 4.19] dmaengine: at_hdmac: Fix memory leak

by Pavel Machek

This fixes memory leak in at_hdmac. Mainline does not have the same problem. Signed-off-by: Pavel Machek (CIP) <pavel(a)denx.de> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c index 86427f6ba78c..0847b2055857 100644 --- a/drivers/dma/at_hdmac.c +++ b/drivers/dma/at_hdmac.c @@ -1714,8 +1714,10 @@ static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec, atslave->dma_dev = &dmac_pdev->dev; chan = dma_request_channel(mask, at_dma_filter, atslave); - if (!chan) + if (!chan) { + kfree(atslave); return NULL; + } atchan = to_at_dma_chan(chan); atchan->per_if = dma_spec->args[0] & 0xff; -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

3 years, 3 months

4
6
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2020