- Linux-stable-mirror - lists.linaro.org

Patch "ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()'" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()' to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Sat, 6 Jan 2018 21:18:24 +0100 Subject: ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()' From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit eaadb1caa966a91128297b754e90b7c92b350a00 ] In some error handling paths, an error code is assiegned to 'ret'. However, the function always return 0. Fix it and return the error code if such an error paths is taken. Fixes: 3d9ff34622ba ("ASoC: Intel: sst: add stream operations") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/intel/atom/sst/sst_stream.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/soc/intel/atom/sst/sst_stream.c +++ b/sound/soc/intel/atom/sst/sst_stream.c @@ -221,7 +221,7 @@ int sst_send_byte_stream_mrfld(struct in sst_free_block(sst_drv_ctx, block); out: test_and_clear_bit(pvt_id, &sst_drv_ctx->pvt_id); - return 0; + return ret; } /* Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.9/cpuidle-dt-add-missing-of_node_put.patch queue-4.9/drm-vc4-fix-resource-leak-in-vc4_get_hang_state_ioctl-in-error-handling-path.patch queue-4.9/edac-mv64x60-fix-an-error-handling-path.patch queue-4.9/smb2-fix-share-type-handling.patch queue-4.9/asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch

7 years, 8 months

1
0
0 0

Patch "ASoC: Intel: cht_bsw_rt5645: Analog Mic support" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: Intel: cht_bsw_rt5645: Analog Mic support to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: asoc-intel-cht_bsw_rt5645-analog-mic-support.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Tue, 2 Jan 2018 19:53:14 +0100 Subject: ASoC: Intel: cht_bsw_rt5645: Analog Mic support From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit b70b309950418437bbd2a30afd169c4f09dee3e5 ] Various Cherry Trail boards with a rt5645 codec have an analog mic connected to IN2P + IN2N. The mic on this boards also needs micbias to be enabled, on some boards micbias1 is used and on others micbias2, so we enable both. This commit adds a new "Int Analog Mic" DAPM widget for this, so that we do not end up enabling micbias on boards with a digital mic which uses the already present "Int Mic" widget. Some existing UCM files already refer to "Int Mic" for their "Internal Analog Microphones" SectionDevice, but these don't work anyways since they enable the RECMIX BST1 Switch instead of the BST2 switch. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/intel/boards/cht_bsw_rt5645.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/sound/soc/intel/boards/cht_bsw_rt5645.c +++ b/sound/soc/intel/boards/cht_bsw_rt5645.c @@ -111,6 +111,7 @@ static const struct snd_soc_dapm_widget SND_SOC_DAPM_HP("Headphone", NULL), SND_SOC_DAPM_MIC("Headset Mic", NULL), SND_SOC_DAPM_MIC("Int Mic", NULL), + SND_SOC_DAPM_MIC("Int Analog Mic", NULL), SND_SOC_DAPM_SPK("Ext Spk", NULL), SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0, platform_clock_control, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD), @@ -121,6 +122,8 @@ static const struct snd_soc_dapm_route c {"IN1N", NULL, "Headset Mic"}, {"DMIC L1", NULL, "Int Mic"}, {"DMIC R1", NULL, "Int Mic"}, + {"IN2P", NULL, "Int Analog Mic"}, + {"IN2N", NULL, "Int Analog Mic"}, {"Headphone", NULL, "HPOL"}, {"Headphone", NULL, "HPOR"}, {"Ext Spk", NULL, "SPOL"}, @@ -134,6 +137,9 @@ static const struct snd_soc_dapm_route c {"Headphone", NULL, "Platform Clock"}, {"Headset Mic", NULL, "Platform Clock"}, {"Int Mic", NULL, "Platform Clock"}, + {"Int Analog Mic", NULL, "Platform Clock"}, + {"Int Analog Mic", NULL, "micbias1"}, + {"Int Analog Mic", NULL, "micbias2"}, {"Ext Spk", NULL, "Platform Clock"}, }; @@ -162,6 +168,7 @@ static const struct snd_kcontrol_new cht SOC_DAPM_PIN_SWITCH("Headphone"), SOC_DAPM_PIN_SWITCH("Headset Mic"), SOC_DAPM_PIN_SWITCH("Int Mic"), + SOC_DAPM_PIN_SWITCH("Int Analog Mic"), SOC_DAPM_PIN_SWITCH("Ext Spk"), }; Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.9/gpio-crystalcove-do-not-write-regular-gpio-registers-for-virtual-gpios.patch queue-4.9/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.9/hid-i2c-call-acpi_device_fix_up_power-for-acpi-enumerated-devices.patch queue-4.9/ata-libahci-properly-propagate-return-value-of-platform_get_irq.patch queue-4.9/input-goodix-disable-irqs-while-suspended.patch queue-4.9/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.9/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 8 months

1
0
0 0

Patch "arp: honour gratuitous ARP _replies_" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arp: honour gratuitous ARP _replies_ to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arp-honour-gratuitous-arp-_replies_.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Ihar Hrachyshka <ihrachys(a)redhat.com> Date: Tue, 16 May 2017 07:53:43 -0700 Subject: arp: honour gratuitous ARP _replies_ From: Ihar Hrachyshka <ihrachys(a)redhat.com> [ Upstream commit 23d268eb240954e6e78f7cfab04f2b1e79f84489 ] When arp_accept is 1, gratuitous ARPs are supposed to override matching entries irrespective of whether they arrive during locktime. This was implemented in commit 56022a8fdd87 ("ipv4: arp: update neighbour address when a gratuitous arp is received and arp_accept is set") There is a glitch in the patch though. RFC 2002, section 4.6, "ARP, Proxy ARP, and Gratuitous ARP", defines gratuitous ARPs so that they can be either of Request or Reply type. Those Reply gratuitous ARPs can be triggered with standard tooling, for example, arping -A option does just that. This patch fixes the glitch, making both Request and Reply flavours of gratuitous ARPs to behave identically. As per RFC, if gratuitous ARPs are of Reply type, their Target Hardware Address field should also be set to the link-layer address to which this cache entry should be updated. The field is present in ARP over Ethernet but not in IEEE 1394. In this patch, I don't consider any broadcasted ARP replies as gratuitous if the field is not present, to conform the standard. It's not clear whether there is such a thing for IEEE 1394 as a gratuitous ARP reply; until it's cleared up, we will ignore such broadcasts. Note that they will still update existing ARP cache entries, assuming they arrive out of locktime time interval. Signed-off-by: Ihar Hrachyshka <ihrachys(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/arp.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) --- a/net/ipv4/arp.c +++ b/net/ipv4/arp.c @@ -658,6 +658,7 @@ static int arp_process(struct net *net, unsigned char *arp_ptr; struct rtable *rt; unsigned char *sha; + unsigned char *tha = NULL; __be32 sip, tip; u16 dev_type = dev->type; int addr_type; @@ -729,6 +730,7 @@ static int arp_process(struct net *net, break; #endif default: + tha = arp_ptr; arp_ptr += dev->addr_len; } memcpy(&tip, arp_ptr, 4); @@ -847,8 +849,18 @@ static int arp_process(struct net *net, It is possible, that this option should be enabled for some devices (strip is candidate) */ - is_garp = arp->ar_op == htons(ARPOP_REQUEST) && tip == sip && - addr_type == RTN_UNICAST; + is_garp = tip == sip && addr_type == RTN_UNICAST; + + /* Unsolicited ARP _replies_ also require target hwaddr to be + * the same as source. + */ + if (is_garp && arp->ar_op == htons(ARPOP_REPLY)) + is_garp = + /* IPv4 over IEEE 1394 doesn't provide target + * hardware address field in its ARP payload. + */ + tha && + !memcmp(tha, sha, dev->addr_len); if (!n && ((arp->ar_op == htons(ARPOP_REPLY) && Patches currently in stable-queue which might be from ihrachys(a)redhat.com are queue-4.9/arp-honour-gratuitous-arp-_replies_.patch queue-4.9/neighbour-update-neigh-timestamps-iff-update-is-effective.patch

7 years, 8 months

1
0
0 0

Patch "arm64: perf: Ignore exclude_hv when kernel is running in HYP" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: perf: Ignore exclude_hv when kernel is running in HYP to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-perf-ignore-exclude_hv-when-kernel-is-running-in-hyp.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Ganapatrao Kulkarni <ganapatrao.kulkarni(a)cavium.com> Date: Tue, 2 May 2017 21:59:34 +0530 Subject: arm64: perf: Ignore exclude_hv when kernel is running in HYP From: Ganapatrao Kulkarni <ganapatrao.kulkarni(a)cavium.com> [ Upstream commit 78a19cfdf37d19002c83c8790853c1cc10feccdc ] commit d98ecdaca296 ("arm64: perf: Count EL2 events if the kernel is running in HYP") returns -EINVAL when perf system call perf_event_open is called with exclude_hv != exclude_kernel. This change breaks applications on VHE enabled ARMv8.1 platforms. The issue was observed with HHVM application, which calls perf_event_open with exclude_hv = 1 and exclude_kernel = 0. There is no separate hypervisor privilege level when VHE is enabled, the host kernel runs at EL2. So when VHE is enabled, we should ignore exclude_hv from the application. This behaviour is consistent with PowerPC where the exclude_hv is ignored when the hypervisor is not present and with x86 where this flag is ignored. Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni(a)cavium.com> [will: added comment to justify the behaviour of exclude_hv] Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/kernel/perf_event.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) --- a/arch/arm64/kernel/perf_event.c +++ b/arch/arm64/kernel/perf_event.c @@ -871,15 +871,24 @@ static int armv8pmu_set_event_filter(str if (attr->exclude_idle) return -EPERM; - if (is_kernel_in_hyp_mode() && - attr->exclude_kernel != attr->exclude_hv) - return -EINVAL; + + /* + * If we're running in hyp mode, then we *are* the hypervisor. + * Therefore we ignore exclude_hv in this configuration, since + * there's no hypervisor to sample anyway. This is consistent + * with other architectures (x86 and Power). + */ + if (is_kernel_in_hyp_mode()) { + if (!attr->exclude_kernel) + config_base |= ARMV8_PMU_INCLUDE_EL2; + } else { + if (attr->exclude_kernel) + config_base |= ARMV8_PMU_EXCLUDE_EL1; + if (!attr->exclude_hv) + config_base |= ARMV8_PMU_INCLUDE_EL2; + } if (attr->exclude_user) config_base |= ARMV8_PMU_EXCLUDE_EL0; - if (!is_kernel_in_hyp_mode() && attr->exclude_kernel) - config_base |= ARMV8_PMU_EXCLUDE_EL1; - if (!attr->exclude_hv) - config_base |= ARMV8_PMU_INCLUDE_EL2; /* * Install the filter into config_base as this is used to Patches currently in stable-queue which might be from ganapatrao.kulkarni(a)cavium.com are queue-4.9/arm64-perf-ignore-exclude_hv-when-kernel-is-running-in-hyp.patch

7 years, 8 months

1
0
0 0

Patch "arm64: kernel: restrict /dev/mem read() calls to linear region" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: kernel: restrict /dev/mem read() calls to linear region to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-kernel-restrict-dev-mem-read-calls-to-linear-region.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Fri, 19 May 2017 16:42:00 +0100 Subject: arm64: kernel: restrict /dev/mem read() calls to linear region From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [ Upstream commit 1151f838cb626005f4d69bf675dacaaa5ea909d6 ] When running lscpu on an AArch64 system that has SMBIOS version 2.0 tables, it will segfault in the following way: Unable to handle kernel paging request at virtual address ffff8000bfff0000 pgd = ffff8000f9615000 [ffff8000bfff0000] *pgd=0000000000000000 Internal error: Oops: 96000007 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 task: ffff8000fa78e800 task.stack: ffff8000f9780000 PC is at __arch_copy_to_user+0x90/0x220 LR is at read_mem+0xcc/0x140 This is caused by the fact that lspci issues a read() on /dev/mem at the offset where it expects to find the SMBIOS structure array. However, this region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), and so it is omitted from the linear mapping. So let's restrict /dev/mem read/write access to those areas that are covered by the linear region. Reported-by: Alexander Graf <agraf(a)suse.de> Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/mm/mmap.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) --- a/arch/arm64/mm/mmap.c +++ b/arch/arm64/mm/mmap.c @@ -18,6 +18,7 @@ #include <linux/elf.h> #include <linux/fs.h> +#include <linux/memblock.h> #include <linux/mm.h> #include <linux/mman.h> #include <linux/export.h> @@ -102,12 +103,18 @@ void arch_pick_mmap_layout(struct mm_str */ int valid_phys_addr_range(phys_addr_t addr, size_t size) { - if (addr < PHYS_OFFSET) - return 0; - if (addr + size > __pa(high_memory - 1) + 1) - return 0; - - return 1; + /* + * Check whether addr is covered by a memory region without the + * MEMBLOCK_NOMAP attribute, and whether that region covers the + * entire range. In theory, this could lead to false negatives + * if the range is covered by distinct but adjacent memory regions + * that only differ in other attributes. However, few of such + * attributes have been defined, and it is debatable whether it + * follows that /dev/mem read() calls should be able traverse + * such boundaries. + */ + return memblock_is_region_memory(addr, size) && + memblock_is_map_memory(addr); } /* Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.9/x86-efi-disable-runtime-services-on-kexec-kernel-if-booted-with-efi-old_map.patch queue-4.9/arm64-kernel-restrict-dev-mem-read-calls-to-linear-region.patch

7 years, 8 months

1
0
0 0

Patch "ARM64: PCI: Fix struct acpi_pci_root_ops allocation failure path" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM64: PCI: Fix struct acpi_pci_root_ops allocation failure path to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-pci-fix-struct-acpi_pci_root_ops-allocation-failure-path.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Timmy Li <lixiaoping3(a)huawei.com> Date: Mon, 22 May 2017 16:48:28 +0100 Subject: ARM64: PCI: Fix struct acpi_pci_root_ops allocation failure path From: Timmy Li <lixiaoping3(a)huawei.com> [ Upstream commit 717902cc93118119a6fce7765da6cf2786987418 ] Commit 093d24a20442 ("arm64: PCI: Manage controller-specific data on per-controller basis") added code to allocate ACPI PCI root_ops dynamically on a per host bridge basis but failed to update the corresponding memory allocation failure path in pci_acpi_scan_root() leading to a potential memory leakage. Fix it by adding the required kfree call. Fixes: 093d24a20442 ("arm64: PCI: Manage controller-specific data on per-controller basis") Reviewed-by: Tomasz Nowicki <tn(a)semihalf.com> Signed-off-by: Timmy Li <lixiaoping3(a)huawei.com> [lorenzo.pieralisi(a)arm.com: refactored code, rewrote commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> CC: Will Deacon <will.deacon(a)arm.com> CC: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/kernel/pci.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/arch/arm64/kernel/pci.c +++ b/arch/arm64/kernel/pci.c @@ -175,8 +175,10 @@ struct pci_bus *pci_acpi_scan_root(struc return NULL; root_ops = kzalloc_node(sizeof(*root_ops), GFP_KERNEL, node); - if (!root_ops) + if (!root_ops) { + kfree(ri); return NULL; + } ri->cfg = pci_acpi_setup_ecam_mapping(root); if (!ri->cfg) { Patches currently in stable-queue which might be from lixiaoping3(a)huawei.com are queue-4.9/arm64-pci-fix-struct-acpi_pci_root_ops-allocation-failure-path.patch

7 years, 8 months

1
0
0 0

Patch "arm64: futex: Fix undefined behaviour with FUTEX_OP_OPARG_SHIFT usage" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: futex: Fix undefined behaviour with FUTEX_OP_OPARG_SHIFT usage to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-futex-fix-undefined-behaviour-with-futex_op_oparg_shift-usage.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Will Deacon <will.deacon(a)arm.com> Date: Wed, 5 Apr 2017 11:14:05 +0100 Subject: arm64: futex: Fix undefined behaviour with FUTEX_OP_OPARG_SHIFT usage From: Will Deacon <will.deacon(a)arm.com> [ Upstream commit 5f16a046f8e144c294ef98cd29d9458b5f8273e5 ] FUTEX_OP_OPARG_SHIFT instructs the futex code to treat the 12-bit oparg field as a shift value, potentially leading to a left shift value that is negative or with an absolute value that is significantly larger then the size of the type. UBSAN chokes with: ================================================================================ UBSAN: Undefined behaviour in ./arch/arm64/include/asm/futex.h:60:13 shift exponent -1 is negative CPU: 1 PID: 1449 Comm: syz-executor0 Not tainted 4.11.0-rc4-00005-g977eb52-dirty #11 Hardware name: linux,dummy-virt (DT) Call trace: [<ffff200008094778>] dump_backtrace+0x0/0x538 arch/arm64/kernel/traps.c:73 [<ffff200008094cd0>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228 [<ffff200008c194a8>] __dump_stack lib/dump_stack.c:16 [inline] [<ffff200008c194a8>] dump_stack+0x120/0x188 lib/dump_stack.c:52 [<ffff200008cc24b8>] ubsan_epilogue+0x18/0x98 lib/ubsan.c:164 [<ffff200008cc3098>] __ubsan_handle_shift_out_of_bounds+0x250/0x294 lib/ubsan.c:421 [<ffff20000832002c>] futex_atomic_op_inuser arch/arm64/include/asm/futex.h:60 [inline] [<ffff20000832002c>] futex_wake_op kernel/futex.c:1489 [inline] [<ffff20000832002c>] do_futex+0x137c/0x1740 kernel/futex.c:3231 [<ffff200008320504>] SYSC_futex kernel/futex.c:3281 [inline] [<ffff200008320504>] SyS_futex+0x114/0x268 kernel/futex.c:3249 [<ffff200008084770>] el0_svc_naked+0x24/0x28 ================================================================================ syz-executor1 uses obsolete (PF_INET,SOCK_PACKET) sock: process `syz-executor0' is using obsolete setsockopt SO_BSDCOMPAT This patch attempts to fix some of this by: * Making encoded_op an unsigned type, so we can shift it left even if the top bit is set. * Casting to signed prior to shifting right when extracting oparg and cmparg * Consider only the bottom 5 bits of oparg when using it as a left-shift value. Whilst I think this catches all of the issues, I'd much prefer to remove this stuff, as I think it's unused and the bugs are copy-pasted between a bunch of architectures. Reviewed-by: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/include/asm/futex.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/arch/arm64/include/asm/futex.h +++ b/arch/arm64/include/asm/futex.h @@ -51,16 +51,16 @@ : "memory") static inline int -futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr) +futex_atomic_op_inuser(unsigned int encoded_op, u32 __user *uaddr) { int op = (encoded_op >> 28) & 7; int cmp = (encoded_op >> 24) & 15; - int oparg = (encoded_op << 8) >> 20; - int cmparg = (encoded_op << 20) >> 20; + int oparg = (int)(encoded_op << 8) >> 20; + int cmparg = (int)(encoded_op << 20) >> 20; int oldval = 0, ret, tmp; if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) - oparg = 1 << oparg; + oparg = 1U << (oparg & 0x1f); if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32))) return -EFAULT; Patches currently in stable-queue which might be from will.deacon(a)arm.com are queue-4.9/perf-callchain-force-user_ds-when-invoking-perf_callchain_user.patch queue-4.9/arm64-pci-fix-struct-acpi_pci_root_ops-allocation-failure-path.patch queue-4.9/arm64-perf-ignore-exclude_hv-when-kernel-is-running-in-hyp.patch queue-4.9/arm64-kernel-restrict-dev-mem-read-calls-to-linear-region.patch queue-4.9/arm64-futex-fix-undefined-behaviour-with-futex_op_oparg_shift-usage.patch

7 years, 8 months

1
0
0 0

Patch "ARM: imx: Add MXC_CPU_IMX6ULL and cpu_is_imx6ull" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: imx: Add MXC_CPU_IMX6ULL and cpu_is_imx6ull to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-imx-add-mxc_cpu_imx6ull-and-cpu_is_imx6ull.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Leonard Crestez <leonard.crestez(a)nxp.com> Date: Tue, 6 Jun 2017 20:50:42 +0300 Subject: ARM: imx: Add MXC_CPU_IMX6ULL and cpu_is_imx6ull From: Leonard Crestez <leonard.crestez(a)nxp.com> [ Upstream commit b3ea575770c7eeb259c77b6861cd14d00eb309df ] Support for imx6ull is already present but it's based on of_machine_is_compatible("fsl,imx6ull") checks. Add it to the MXC_CPU_* enumeration as well. This also fixes /sys/devices/soc0/soc_id reading "Unknown". Signed-off-by: Leonard Crestez <leonard.crestez(a)nxp.com> Reviewed-by: Fabio Estevam <fabio.estevam(a)nxp.com> Signed-off-by: Shawn Guo <shawnguo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/mach-imx/cpu.c | 3 +++ arch/arm/mach-imx/mxc.h | 6 ++++++ 2 files changed, 9 insertions(+) --- a/arch/arm/mach-imx/cpu.c +++ b/arch/arm/mach-imx/cpu.c @@ -131,6 +131,9 @@ struct device * __init imx_soc_device_in case MXC_CPU_IMX6UL: soc_id = "i.MX6UL"; break; + case MXC_CPU_IMX6ULL: + soc_id = "i.MX6ULL"; + break; case MXC_CPU_IMX7D: soc_id = "i.MX7D"; break; --- a/arch/arm/mach-imx/mxc.h +++ b/arch/arm/mach-imx/mxc.h @@ -39,6 +39,7 @@ #define MXC_CPU_IMX6SX 0x62 #define MXC_CPU_IMX6Q 0x63 #define MXC_CPU_IMX6UL 0x64 +#define MXC_CPU_IMX6ULL 0x65 #define MXC_CPU_IMX7D 0x72 #define IMX_DDR_TYPE_LPDDR2 1 @@ -73,6 +74,11 @@ static inline bool cpu_is_imx6ul(void) return __mxc_cpu_type == MXC_CPU_IMX6UL; } +static inline bool cpu_is_imx6ull(void) +{ + return __mxc_cpu_type == MXC_CPU_IMX6ULL; +} + static inline bool cpu_is_imx6q(void) { return __mxc_cpu_type == MXC_CPU_IMX6Q; Patches currently in stable-queue which might be from leonard.crestez(a)nxp.com are queue-4.9/arm-imx-add-mxc_cpu_imx6ull-and-cpu_is_imx6ull.patch queue-4.9/net-phy-micrel-restore-led_mode-and-clk_sel-on-resume.patch

7 years, 8 months

1
0
0 0

Patch "ARM: dts: qcom: ipq4019: fix i2c_0 node" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: qcom: ipq4019: fix i2c_0 node to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-qcom-ipq4019-fix-i2c_0-node.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Christian Lamparter <chunkeey(a)googlemail.com> Date: Tue, 2 May 2017 21:19:24 +0200 Subject: ARM: dts: qcom: ipq4019: fix i2c_0 node From: Christian Lamparter <chunkeey(a)googlemail.com> [ Upstream commit 650df439cfb96c303328935559b2d06127a5a0b0 ] This patch fixes two typos in the i2c_0 node for the ipq4019. The reg property length is just 0x600. The core clock is GCC_BLSP1_QUP1_I2C_APPS_CLK. GCC_BLSP1_QUP2_I2C_APPS_CLK is used by the second i2c. Fixes: e76b4284b520ba3 ("qcom: ipq4019: add i2c node to ipq4019 SoC and DK01 device tree") Signed-off-by: Christian Lamparter <chunkeey(a)googlemail.com> Signed-off-by: Andy Gross <andy.gross(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/qcom-ipq4019.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm/boot/dts/qcom-ipq4019.dtsi +++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi @@ -154,10 +154,10 @@ i2c_0: i2c@78b7000 { compatible = "qcom,i2c-qup-v2.2.1"; - reg = <0x78b7000 0x6000>; + reg = <0x78b7000 0x600>; interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; clocks = <&gcc GCC_BLSP1_AHB_CLK>, - <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>; + <&gcc GCC_BLSP1_QUP1_I2C_APPS_CLK>; clock-names = "iface", "core"; #address-cells = <1>; #size-cells = <0>; Patches currently in stable-queue which might be from chunkeey(a)googlemail.com are queue-4.9/net-emac-fix-reset-timeout-with-ar8035-phy.patch queue-4.9/arm-dts-qcom-ipq4019-fix-i2c_0-node.patch

7 years, 8 months

1
0
0 0

Patch "ARM: dts: rockchip: fix rk322x i2s1 pinctrl error" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: rockchip: fix rk322x i2s1 pinctrl error to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-rockchip-fix-rk322x-i2s1-pinctrl-error.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Sugar Zhang <sugar.zhang(a)rock-chips.com> Date: Wed, 17 May 2017 17:52:24 +0800 Subject: ARM: dts: rockchip: fix rk322x i2s1 pinctrl error From: Sugar Zhang <sugar.zhang(a)rock-chips.com> [ Upstream commit 9d420e9b4140f8938ad6aa0d29e2428a2af6122b ] Refer to Chapter 5.3.2 of rk3229 TRM, we can see that GPIO1A[2,4,5] using RK_FUNC_2 not RK_FUNC_1. This patch fixes it. Signed-off-by: Sugar Zhang <sugar.zhang(a)rock-chips.com> Signed-off-by: Frank Wang <frank.wang(a)rock-chips.com> Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/rk322x.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/arm/boot/dts/rk322x.dtsi +++ b/arch/arm/boot/dts/rk322x.dtsi @@ -617,9 +617,9 @@ <0 12 RK_FUNC_1 &pcfg_pull_none>, <0 13 RK_FUNC_1 &pcfg_pull_none>, <0 14 RK_FUNC_1 &pcfg_pull_none>, - <1 2 RK_FUNC_1 &pcfg_pull_none>, - <1 4 RK_FUNC_1 &pcfg_pull_none>, - <1 5 RK_FUNC_1 &pcfg_pull_none>; + <1 2 RK_FUNC_2 &pcfg_pull_none>, + <1 4 RK_FUNC_2 &pcfg_pull_none>, + <1 5 RK_FUNC_2 &pcfg_pull_none>; }; }; Patches currently in stable-queue which might be from sugar.zhang(a)rock-chips.com are queue-4.9/arm-dts-rockchip-fix-rk322x-i2s1-pinctrl-error.patch

7 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror