4.9.291-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 173/207 ALSA: gus: fix null pointer dereference on pointer block
In reply to Greg Kroah-HartmanFrom: Chengfeng Ye <[email protected]>
[ Upstream commit a0d21bb3279476c777434c40d969ea88ca64f9aa ]
The pointer block return from snd_gf1_dma_next_block could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.
--- sound/isa/gus/gus_dma.c | 2 ++ 1 file changed, 2 insertions(+)
sound/isa/gus/gus_dma.c +2 -0
@@ -141,6 +141,8 @@ static void snd_gf1_dma_interrupt(struct snd_gus_card * gus) } block =snd_gf1_dma_next_block (gus);spin_unlock (&gus->dma_lock); +if (!block) +return ;snd_gf1_dma_program (gus, block->addr, block->buf_addr, block->count, (unsigned short ) block->cmd);kfree (block);#if 0
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 174/207 powerpc/dcr: Use cmplwi instead of 3-argument cmpli
In reply to Greg Kroah-HartmanFrom: Michael Ellerman <[email protected]>
[ Upstream commit fef071be57dc43679a32d5b0e6ee176d6f12e9f2 ]
In dcr-low.S we use cmpli with three arguments, instead of four arguments as defined in the ISA:
cmpli cr0,r3,1024
This appears to be a PPC440-ism, looking at the "PPC440x5 CPU Core User’s Manual" it shows cmpli having no L field, but implied to be 0 due to the core being 32-bit. It mentions that the ISA defines four arguments and recommends using cmplwi.
It also corresponds to the old POWER instruction set, which had no L field there, a reserved bit instead.
dcr-low.S is only built 32-bit, because it is only built when DCR_NATIVE=y, which is only selected by 40x and 44x. Looking at the generated code (with gcc/gas) we see cmplwi as expected.
Although gas is happy with the 3-argument version when building for 32-bit, the LLVM assembler is not and errors out with:
arch/powerpc/sysdev/dcr-low.S:27:10: error: invalid operand for instruction
cmpli 0,%r3,1024; ...
^
Switch to the cmplwi extended opcode, which avoids any confusion when reading the ISA, fixes the issue with the LLVM assembler, and also means the code could be built 64-bit in future (though that's very unlikely).
--- arch/powerpc/sysdev/dcr-low.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/sysdev/dcr-low.S +1 -1
@@ -15,7 +15,7 @@ #include <asm/export.h> #define DCR_ACCESS_PROLOG(table) \ - cmpli cr0,r3,1024; \ + cmplwi cr0,r3,1024; \ rlwinm r3,r3,4,18,27; \ lis r5,table@h; \ ori r5,r5,table@l; \
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 175/207 sh: check return code of request_irq
In reply to Greg Kroah-HartmanFrom: Nick Desaulniers <[email protected]>
[ Upstream commit 0e38225c92c7964482a8bb6b3e37fde4319e965c ]
request_irq is marked __must_check, but the call in shx3_prepare_cpus has a void return type, so it can't propagate failure to the caller. Follow cues from hexagon and just print an error.
--- arch/sh/kernel/cpu/sh4a/smp-shx3.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/sh/kernel/cpu/sh4a/smp-shx3.c +3 -2
@@ -76,8 +76,9 @@ static void shx3_prepare_cpus(unsigned int max_cpus)BUILD_BUG_ON (SMP_MSG_NR >=8 );for (i =0 ; i <SMP_MSG_NR ; i++) -request_irq (104 + i, ipi_interrupt_handler, -IRQF_PERCPU ,"IPI" , (void *)(long )i); +if (request_irq (104 + i, ipi_interrupt_handler, +IRQF_PERCPU ,"IPI" , (void *)(long )i)) +pr_err ("Failed to request irq %d\n" , i);for (i =0 ; i < max_cpus; i++)set_cpu_present (i, true);
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 176/207 maple: fix wrong return value of maple_bus_init().
In reply to Greg Kroah-HartmanFrom: Lu Wei <[email protected]>
[ Upstream commit bde82ee391fa6d3ad054313c4aa7b726d32515ce ]
If KMEM_CACHE or maple_alloc_dev failed, the maple_bus_init() will return 0 rather than error, because the retval is not changed after KMEM_CACHE or maple_alloc_dev failed.
--- drivers/sh/maple/maple.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/sh/maple/maple.c +4 -1
@@ -835,8 +835,10 @@ static int __init maple_bus_init(void) maple_queue_cache =KMEM_CACHE (maple_buffer,SLAB_HWCACHE_ALIGN ); -if (!maple_queue_cache) +if (!maple_queue_cache) { + retval = -ENOMEM ; goto cleanup_bothirqs; + }INIT_LIST_HEAD (&maple_waitq);INIT_LIST_HEAD (&maple_sentq);
@@ -849,6 +851,7 @@ static int __init maple_bus_init(void)if (!mdev[i]) {while (i-- >0 )maple_free_dev (mdev[i]); + retval = -ENOMEM ; goto cleanup_cache; } baseunits[i] = mdev[i];
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 177/207 sh: fix kconfig unmet dependency warning for FRAME_POINTER
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit fda1bc533094a7db68b11e7503d2c6c73993d12a ]
FRAME_POINTER depends on DEBUG_KERNEL so DWARF_UNWINDER should depend on DEBUG_KERNEL before selecting FRAME_POINTER.
WARNING: unmet direct dependencies detected for FRAME_POINTER
Depends on [n]: DEBUG_KERNEL [=n] && (M68K || UML || SUPERH [=y]) || ARCH_WANT_FRAME_POINTERS [=n] Selected by [y]:
- DWARF_UNWINDER [=y]
--- arch/sh/Kconfig.debug | 1 + 1 file changed, 1 insertion(+)
arch/sh/Kconfig.debug +1 -0
@@ -60,6 +60,7 @@ config DUMP_CODE config DWARF_UNWINDER bool "Enable the DWARF unwinder for stacktraces" + depends on DEBUG_KERNEL select FRAME_POINTER depends on SUPERH32 default n
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 178/207 sh: define __BIG_ENDIAN for math-emu
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit b929926f01f2d14635345d22eafcf60feed1085e ]
Fix this by defining both ENDIAN macros in <asm/sfp-machine.h> so that they can be utilized in <math-emu/soft-fp.h> according to the latter's comment:
/* Allow sfp-machine to have its own byte order definitions. */
(This is what is done in arch/nds32/include/asm/sfp-machine.h.)
This placates these build warnings:
In file included from ../arch/sh/math-emu/math.c:23:.../include/math-emu/single.h:50:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
50 | #if __BYTE_ORDER == __BIG_ENDIAN
In file included from ../arch/sh/math-emu/math.c:24:.../include/math-emu/double.h:59:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
59 | #if __BYTE_ORDER == __BIG_ENDIAN
--- arch/sh/include/asm/sfp-machine.h | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/sh/include/asm/sfp-machine.h +8 -0
@@ -25,6 +25,14 @@#ifndef _SFP_MACHINE_H#define _SFP_MACHINE_H +#ifdef __BIG_ENDIAN__ +#define __BYTE_ORDER __BIG_ENDIAN +#define __LITTLE_ENDIAN 0 +#else +#define __BYTE_ORDER __LITTLE_ENDIAN +#define __BIG_ENDIAN 0 +#endif +#define _FP_W_TYPE_SIZE 32#define _FP_W_TYPE unsigned long#define _FP_WS_TYPE signed long
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 179/207 mips: BCM63XX: ensure that CPU_SUPPORTS_32BIT_KERNEL is set
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit 5eeaafc8d69373c095e461bdb39e5c9b62228ac5 ]
Several header files need info on CONFIG_32BIT or CONFIG_64BIT, but kconfig symbol BCM63XX does not provide that info. This leads to many build errors, e.g.:
arch/mips/include/asm/page.h:196:13: error: use of undeclared identifier 'CAC_BASE'
return x - PAGE_OFFSET + PHYS_OFFSET;
arch/mips/include/asm/mach-generic/spaces.h:91:23: note: expanded from macro 'PAGE_OFFSET'
#define PAGE_OFFSET (CAC_BASE + PHYS_OFFSET)
arch/mips/include/asm/io.h:134:28: error: use of undeclared identifier 'CAC_BASE'
return (void *)(address + PAGE_OFFSET - PHYS_OFFSET);
arch/mips/include/asm/mach-generic/spaces.h:91:23: note: expanded from macro 'PAGE_OFFSET'
#define PAGE_OFFSET (CAC_BASE + PHYS_OFFSET)arch/mips/include/asm/uaccess.h:82:10: error: use of undeclared identifier '__UA_LIMIT'
return (__UA_LIMIT & (addr | (addr + size) | __ua_size(size))) == 0;
Selecting the SYS_HAS_CPU_BMIPS* symbols causes SYS_HAS_CPU_BMIPS to be set, which then selects CPU_SUPPORT_32BIT_KERNEL, which causes CONFIG_32BIT to be set. (a bit more indirect than v1 [RFC].)
--- arch/mips/Kconfig | 3 +++ 1 file changed, 3 insertions(+)
arch/mips/Kconfig +3 -0
@@ -267,6 +267,9 @@ config BCM63XX select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN select SYS_HAS_EARLY_PRINTK + select SYS_HAS_CPU_BMIPS32_3300 + select SYS_HAS_CPU_BMIPS4350 + select SYS_HAS_CPU_BMIPS4380 select SWAP_IO_SPACE select GPIOLIB select HAVE_CLK
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 180/207 sched/core: Mitigate race cpus_share_cache()/update_top_cache_domain()
In reply to Greg Kroah-HartmanFrom: Vincent Donnefort <[email protected]>
[ Upstream commit 42dc938a590c96eeb429e1830123fef2366d9c80 ]
Nothing protects the access to the per_cpu variable sd_llc_id. When testing the same CPU (i.e. this_cpu == that_cpu), a race condition exists with update_top_cache_domain(). One scenario being:
CPU1 CPU2
==================================================================
per_cpu(sd_llc_id, CPUX) => 0
partition_sched_domains_locked()
detach_destroy_domains()
cpus_share_cache(CPUX, CPUX) update_top_cache_domain(CPUX)
per_cpu(sd_llc_id, CPUX) => 0
per_cpu(sd_llc_id, CPUX) = CPUX
per_cpu(sd_llc_id, CPUX) => CPUX
return false
ttwu_queue_cond() wouldn't catch smp_processor_id() == cpu and the result is a warning triggered from ttwu_queue_wakelist().
Avoid a such race in cpus_share_cache() by always returning true when this_cpu == that_cpu.
--- kernel/sched/core.c | 3 +++ 1 file changed, 3 insertions(+)
kernel/sched/core.c +3 -0
@@ -1875,6 +1875,9 @@ out:bool cpus_share_cache (int this_cpu,int that_cpu) { +if (this_cpu == that_cpu) +return true; +return per_cpu (sd_llc_id, this_cpu) ==per_cpu (sd_llc_id, that_cpu); }#endif /* CONFIG_SMP */
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 181/207 net: bnx2x: fix variable dereferenced before check
In reply to Greg Kroah-HartmanFrom: Pavel Skripkin <[email protected]>
[ Upstream commit f8885ac89ce310570e5391fe0bf0ec9c7c9b4fdc ]
Smatch says:
bnx2x_init_ops.h:640 bnx2x_ilt_client_mem_op() warn: variable dereferenced before check 'ilt' (see line 638)
Move ilt_cli variable initialization _after_ ilt validation, because it's unsafe to deref the pointer before validation check.
--- drivers/net/ethernet/broadcom/bnx2x/bnx2x_init_ops.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_init_ops.h +3 -1
@@ -635,11 +635,13 @@ static int bnx2x_ilt_client_mem_op(struct bnx2x *bp, int cli_num, {int i, rc;struct bnx2x_ilt *ilt =BP_ILT (bp); -struct ilt_client_info *ilt_cli = &ilt->clients[cli_num]; +struct ilt_client_info *ilt_cli;if (!ilt || !ilt->lines)return -1 ; + ilt_cli = &ilt->clients[cli_num]; +if (ilt_cli->flags & (ILT_CLIENT_SKIP_INIT |ILT_CLIENT_SKIP_MEM ))return 0 ;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 182/207 iavf: Fix for the false positive ASQ/ARQ errors while issuing VF reset
In reply to Greg Kroah-HartmanFrom: Surabhi Boob <[email protected]>
[ Upstream commit 321421b57a12e933f92b228e0e6d0b2c6541f41d ]
While issuing VF Reset from the guest OS, the VF driver prints logs about critical / Overflow error detection. This is not an actual error since the VF_MBX_ARQLEN register is set to all FF's for a short period of time and the VF would catch the bits set if it was reading the register during that spike of time. This patch introduces an additional check to ignore this condition since the VF is in reset.
--- drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/i40evf/i40evf_main.c +1 -1
@@ -1889,7 +1889,7 @@ static void i40evf_adminq_task(struct work_struct *work)/* check for error indications */ val =rd32 (hw, hw->aq.arq.len); -if (val ==0xdeadbeef )/* indicates device in reset */ +if (val ==0xdeadbeef || val ==0xffffffff )/* device in reset */ goto freedom; oldval = val;if (val &I40E_VF_ARQLEN1_ARQVFE_MASK ) {
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 183/207 mips: bcm63xx: add support for clk_get_parent()
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit e8f67482e5a4bc8d0b65d606d08cb60ee123b468 ]
BCM63XX selects HAVE_LEGACY_CLK but does not provide/support clk_get_parent(), so add a simple implementation of that function so that callers of it will build without errors.
Fixes these build errors:
mips-linux-ld: drivers/iio/adc/ingenic-adc.o: in function `jz4770_adc_init_clk_div':
ingenic-adc.c:(.text+0xe4): undefined reference to `clk_get_parent'
mips-linux-ld: drivers/iio/adc/ingenic-adc.o: in function `jz4725b_adc_init_clk_div':
ingenic-adc.c:(.text+0x1b8): undefined reference to `clk_get_parent'
--- arch/mips/bcm63xx/clk.c | 6 ++++++ 1 file changed, 6 insertions(+)
arch/mips/bcm63xx/clk.c +6 -0
@@ -336,6 +336,12 @@ void clk_disable(struct clk *clk)EXPORT_SYMBOL (clk_disable); +struct clk *clk_get_parent (struct clk *clk) +{ +return NULL ; +} +EXPORT_SYMBOL (clk_get_parent); +unsigned long clk_get_rate (struct clk *clk) {return clk->rate;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 184/207 platform/x86: hp_accel: Fix an error handling path in lis3lv02d_probe()
In reply to Greg Kroah-HartmanFrom: Christophe JAILLET <[email protected]>
[ Upstream commit c961a7d2aa23ae19e0099fbcdf1040fb760eea83 ]
If 'led_classdev_register()' fails, some additional resources should be released.
Add the missing 'i8042_remove_filter()' and 'lis3lv02d_remove_fs()' calls that are already in the remove function but are missing here.
--- drivers/platform/x86/hp_accel.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/platform/x86/hp_accel.c +2 -0
@@ -382,9 +382,11 @@ static int lis3lv02d_add(struct acpi_device *device)INIT_WORK (&hpled_led.work, delayed_set_status_worker); ret =led_classdev_register (NULL , &hpled_led.led_classdev);if (ret) { +i8042_remove_filter (hp_accel_i8042_filter);lis3lv02d_joystick_disable (&lis3_dev);lis3lv02d_poweroff (&lis3_dev);flush_work (&hpled_led.work); +lis3lv02d_remove_fs (&lis3_dev);return ret; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 185/207 NFC: reorganize the functions in nci_request
In reply to Greg Kroah-HartmanFrom: Lin Ma <[email protected]>
[ Upstream commit 86cdf8e38792545161dbe3350a7eced558ba4d15 ]
There is a possible data race as shown below:
thread-A in nci_request() | thread-B in nci_close_device()
| mutex_lock(&ndev->req_lock);
test_bit(NCI_UP, &ndev->flags); |
... | test_and_clear_bit(NCI_UP, &ndev->flags)
mutex_lock(&ndev->req_lock); |
|This race will allow __nci_request() to be awaked while the device is getting removed.
Similar to commit e2cb6b891ad2 ("bluetooth: eliminate the potential race condition when removing the HCI controller"). this patch alters the function sequence in nci_request() to prevent the data races between the nci_close_device().
--- net/nfc/nci/core.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
net/nfc/nci/core.c +7 -4
@@ -157,12 +157,15 @@ inline int nci_request(struct nci_dev *ndev, {int rc; -if (!test_bit (NCI_UP , &ndev->flags)) -return -ENETDOWN ; -/* Serialize all requests */ mutex_lock (&ndev->req_lock); - rc =__nci_request (ndev, req, opt, timeout); +/* check the state after obtaing the lock against any races +* from nci_close_device when the device gets removed. +*/ +if (test_bit (NCI_UP , &ndev->flags)) + rc =__nci_request (ndev, req, opt, timeout); +else + rc = -ENETDOWN ;mutex_unlock (&ndev->req_lock);return rc;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 186/207 NFC: reorder the logic in nfc_{un,}register_device
In reply to Greg Kroah-HartmanFrom: Lin Ma <[email protected]>
[ Upstream commit 3e3b5dfcd16a3e254aab61bd1e8c417dd4503102 ]
There is a potential UAF between the unregistration routine and the NFC netlink operations.
The race that cause that UAF can be shown as below:
(FREE) | (USE)
nfcmrvl_nci_unregister_dev | nfc_genl_dev_up
nci_close_device |
nci_unregister_device | nfc_get_device
nfc_unregister_device | nfc_dev_up
rfkill_destory |
device_del | rfkill_blocked
... | ...The root cause for this race is concluded below:
1. The rfkill_blocked (USE) in nfc_dev_up is supposed to be placed after the device_is_registered check.
2. Since the netlink operations are possible just after the device_add in nfc_register_device, the nfc_dev_up() can happen anywhere during the rfkill creation process, which leads to data race.
This patch reorder these actions to permit
1. Once device_del is finished, the nfc_dev_up cannot dereference the rfkill object.
2. The rfkill_register need to be placed after the device_add of nfc_dev because the parent device need to be created first. So this patch keeps the order but inject device_lock to prevent the data race.
--- net/nfc/core.c | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-)
net/nfc/core.c +18 -14
@@ -106,13 +106,13 @@ int nfc_dev_up(struct nfc_dev *dev)device_lock (&dev->dev); -if (dev->rfkill &&rfkill_blocked (dev->rfkill)) { - rc = -ERFKILL ; +if (!device_is_registered (&dev->dev)) { + rc = -ENODEV ; goto error; } -if (!device_is_registered (&dev->dev)) { - rc = -ENODEV ; +if (dev->rfkill &&rfkill_blocked (dev->rfkill)) { + rc = -ERFKILL ; goto error; }
@@ -1133,11 +1133,7 @@ int nfc_register_device(struct nfc_dev *dev)if (rc)pr_err ("Could not register llcp device\n" ); - rc =nfc_genl_device_added (dev); -if (rc) -pr_debug ("The userspace won't be notified that the device %s was added\n" , -dev_name (&dev->dev)); - +device_lock (&dev->dev); dev->rfkill =rfkill_alloc (dev_name (&dev->dev), &dev->dev,RFKILL_TYPE_NFC , &nfc_rfkill_ops, dev);if (dev->rfkill) {
@@ -1146,6 +1142,12 @@ int nfc_register_device(struct nfc_dev *dev) dev->rfkill =NULL ; } } +device_unlock (&dev->dev); + + rc =nfc_genl_device_added (dev); +if (rc) +pr_debug ("The userspace won't be notified that the device %s was added\n" , +dev_name (&dev->dev));return 0 ; }
@@ -1162,10 +1164,17 @@ void nfc_unregister_device(struct nfc_dev *dev)pr_debug ("dev_name=%s\n" ,dev_name (&dev->dev)); + rc =nfc_genl_device_removed (dev); +if (rc) +pr_debug ("The userspace won't be notified that the device %s " +"was removed\n" ,dev_name (&dev->dev)); + +device_lock (&dev->dev);if (dev->rfkill) {rfkill_unregister (dev->rfkill);rfkill_destroy (dev->rfkill); } +device_unlock (&dev->dev);if (dev->ops->check_presence) {device_lock (&dev->dev);
@@ -1175,11 +1184,6 @@ void nfc_unregister_device(struct nfc_dev *dev)cancel_work_sync (&dev->check_pres_work); } - rc =nfc_genl_device_removed (dev); -if (rc) -pr_debug ("The userspace won't be notified that the device %s " -"was removed\n" ,dev_name (&dev->dev)); -nfc_llcp_unregister_device (dev);mutex_lock (&nfc_devlist_mutex);
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 187/207 perf bench: Fix two memory leaks detected with ASan
In reply to Greg Kroah-HartmanFrom: Sohaib Mohamed <[email protected]>
[ Upstream commit 92723ea0f11d92496687db8c9725248e9d1e5e1d ]
ASan reports memory leaks while running:
$ perf bench sched all
--- tools/perf/bench/sched-messaging.c | 4 ++++ 1 file changed, 4 insertions(+)
tools/perf/bench/sched-messaging.c +4 -0
@@ -225,6 +225,8 @@ static unsigned int group(pthread_t *pth, snd_ctx->out_fds[i] = fds[1 ];if (!thread_mode)close (fds[0 ]); + +free (ctx); }/* Now we have all the fds, fork the senders */
@@ -241,6 +243,8 @@ static unsigned int group(pthread_t *pth,for (i =0 ; i < num_fds; i++)close (snd_ctx->out_fds[i]); +free (snd_ctx); +/* Return number of children to reap */ return num_fds *2 ; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 188/207 perf/x86/intel/uncore: Fix filter_tid mask for CHA events on Skylake Server
In reply to Greg Kroah-HartmanFrom: Alexander Antonov <[email protected]>
[ Upstream commit e324234e0aa881b7841c7c713306403e12b069ff ]
According Uncore Reference Manual: any of the CHA events may be filtered by Thread/Core-ID by using tid modifier in CHA Filter 0 Register. Update skx_cha_hw_config() to follow Uncore Guide.
--- arch/x86/events/intel/uncore_snbep.c | 3 +++ 1 file changed, 3 insertions(+)
arch/x86/events/intel/uncore_snbep.c +3 -0
@@ -3363,6 +3363,9 @@ static int skx_cha_hw_config(struct intel_uncore_box *box, struct perf_event *evstruct hw_perf_event_extra *reg1 = &event->hw.extra_reg;struct extra_reg *er;int idx =0 ; +/* Any of the CHA events may be filtered by Thread/Core-ID.*/ +if (event->hw.config &SNBEP_CBO_PMON_CTL_TID_EN ) + idx =SKX_CHA_MSR_PMON_BOX_FILTER_TID ;for (er = skx_uncore_cha_extra_regs; er->msr; er++) {if (er->event != (event->hw.config & er->config_mask))
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 189/207 perf/x86/intel/uncore: Fix IIO event constraints for Skylake Server
In reply to Greg Kroah-HartmanFrom: Alexander Antonov <[email protected]>
[ Upstream commit 3866ae319c846a612109c008f43cba80b8c15e86 ]
According to the latest uncore document, COMP_BUF_OCCUPANCY (0xd5) event can be collected on 2-3 counters. Update uncore IIO event constraints for Skylake Server.
--- arch/x86/events/intel/uncore_snbep.c | 1 + 1 file changed, 1 insertion(+)
arch/x86/events/intel/uncore_snbep.c +1 -0
@@ -3433,6 +3433,7 @@ static struct event_constraint skx_uncore_iio_constraints[] = {UNCORE_EVENT_CONSTRAINT (0xc0 ,0xc ),UNCORE_EVENT_CONSTRAINT (0xc5 ,0xc ),UNCORE_EVENT_CONSTRAINT (0xd4 ,0xc ), +UNCORE_EVENT_CONSTRAINT (0xd5 ,0xc ), EVENT_CONSTRAINT_END };
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 190/207 tun: fix bonding active backup with arp monitoring
In reply to Greg Kroah-HartmanFrom: Nicolas Dichtel <[email protected]>
commit a31d27fbed5d518734cb60956303eb15089a7634 upstream.
As stated in the bonding doc, trans_start must be set manually for drivers using NETIF_F_LLTX:
Drivers that use NETIF_F_LLTX flag must also update netdev_queue->trans_start. If they do not, then the ARP monitor will immediately fail any slaves using that driver, and those slaves will stay down.
--- drivers/net/tun.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/tun.c +5 -0
@@ -855,6 +855,7 @@ static netdev_tx_t tun_net_xmit(struct s {struct tun_struct *tun =netdev_priv (dev);int txq = skb->queue_mapping; +struct netdev_queue *queue;struct tun_file *tfile;u32 numqueues =0 ;
@@ -920,6 +921,10 @@ static netdev_tx_t tun_net_xmit(struct sif (skb_array_produce (&tfile->tx_array, skb)) goto drop; +/* NETIF_F_LLTX requires to do our own update of trans_start */ + queue =netdev_get_tx_queue (dev, txq); + queue->trans_start = jiffies; +/* Notify and wake up reader process */ if (tfile->flags &TUN_FASYNC )kill_fasync (&tfile->fasync,SIGIO ,POLL_IN );
Greg Kroah-Hartman
maintainerPATCH 191/207 hexagon: export raw I/O routines for modules
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
commit ffb92ce826fd801acb0f4e15b75e4ddf0d189bde upstream.
Patch series "Fixes for ARCH=hexagon allmodconfig", v2.
This series fixes some issues noticed with ARCH=hexagon allmodconfig.
This patch (of 3):
When building ARCH=hexagon allmodconfig, the following errors occur:
ERROR: modpost: "__raw_readsl" [drivers/i3c/master/svc-i3c-master.ko] undefined!
ERROR: modpost: "__raw_writesl" [drivers/i3c/master/dw-i3c-master.ko] undefined!
ERROR: modpost: "__raw_readsl" [drivers/i3c/master/dw-i3c-master.ko] undefined!
ERROR: modpost: "__raw_writesl" [drivers/i3c/master/i3c-master-cdns.ko] undefined!
ERROR: modpost: "__raw_readsl" [drivers/i3c/master/i3c-master-cdns.ko] undefined!
Export these symbols so that modules can use them without any errors.
--- arch/hexagon/lib/io.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/hexagon/lib/io.c +4 -0
@@ -40,6 +40,7 @@ void __raw_readsw(const void __iomem *ad *dst++ = *src; } +EXPORT_SYMBOL (__raw_readsw);/* * __raw_writesw - read words a short at a time
@@ -60,6 +61,7 @@ void __raw_writesw(void __iomem *addr, c } +EXPORT_SYMBOL (__raw_writesw);/* Pretty sure len is pre-adjusted for the length of the access already */ void __raw_readsl (const void __iomem *addr,void *data,int len)
@@ -75,6 +77,7 @@ void __raw_readsl(const void __iomem *ad } +EXPORT_SYMBOL (__raw_readsl);void __raw_writesl (void __iomem *addr,const void *data,int len) {
@@ -89,3 +92,4 @@ void __raw_writesl(void __iomem *addr, c } +EXPORT_SYMBOL (__raw_writesl);
Greg Kroah-Hartman
maintainerPATCH 192/207 mm: kmemleak: slob: respect SLAB_NOLEAKTRACE flag
In reply to Greg Kroah-HartmanFrom: Rustam Kovhaev <[email protected]>
commit 34dbc3aaf5d9e89ba6cc5e24add9458c21ab1950 upstream.
When kmemleak is enabled for SLOB, system does not boot and does not print anything to the console. At the very early stage in the boot process we hit infinite recursion from kmemleak_init() and eventually kernel crashes.
kmemleak_init() specifies SLAB_NOLEAKTRACE for KMEM_CACHE(), but kmem_cache_create_usercopy() removes it because CACHE_CREATE_MASK is not valid for SLOB.
Let's fix CACHE_CREATE_MASK and make kmemleak work with SLOB
--- mm/slab.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/slab.h +1 -1
@@ -139,7 +139,7 @@ static inline unsigned long kmem_cache_f#define SLAB_CACHE_FLAGS (SLAB_NOLEAKTRACE | SLAB_RECLAIM_ACCOUNT | \ SLAB_TEMPORARY | SLAB_NOTRACK | SLAB_ACCOUNT)#else -#define SLAB_CACHE_FLAGS (0) +#define SLAB_CACHE_FLAGS (SLAB_NOLEAKTRACE)#endif #define CACHE_CREATE_MASK (SLAB_CORE_FLAGS | SLAB_DEBUG_FLAGS | SLAB_CACHE_FLAGS)
Greg Kroah-Hartman
maintainerPATCH 193/207 btrfs: fix memory ordering between normal and ordered work functions
In reply to Greg Kroah-HartmanFrom: Nikolay Borisov <[email protected]>
commit 45da9c1767ac31857df572f0a909fbe88fd5a7e9 upstream.
Ordered work functions aren't guaranteed to be handled by the same thread which executed the normal work functions. The only way execution between normal/ordered functions is synchronized is via the WORK_DONE_BIT, unfortunately the used bitops don't guarantee any ordering whatsoever.
This manifested as seemingly inexplicable crashes on ARM64, where async_chunk::inode is seen as non-null in async_cow_submit which causes submit_compressed_extents to be called and crash occurs because async_chunk::inode suddenly became NULL. The call trace was similar to:
pc : submit_compressed_extents+0x38/0x3d0
lr : async_cow_submit+0x50/0xd0
sp : ffff800015d4bc20 <registers omitted for brevity>
Call trace:
submit_compressed_extents+0x38/0x3d0
async_cow_submit+0x50/0xd0
run_ordered_work+0xc8/0x280
btrfs_work_helper+0x98/0x250
process_one_work+0x1f0/0x4ac
worker_thread+0x188/0x504
kthread+0x110/0x114
ret_from_fork+0x10/0x18Fix this by adding respective barrier calls which ensure that all accesses preceding setting of WORK_DONE_BIT are strictly ordered before setting the flag. At the same time add a read barrier after reading of WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads would be strictly ordered after reading the bit. This in turn ensures are all accesses before WORK_DONE_BIT are going to be strictly ordered before any access that can occur in ordered_func.
--- fs/btrfs/async-thread.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
fs/btrfs/async-thread.c +14 -0
@@ -283,6 +283,13 @@ static void run_ordered_work(struct __bt ordered_list);if (!test_bit (WORK_DONE_BIT , &work->flags))break ; +/* +* Orders all subsequent loads after reading WORK_DONE_BIT, +* paired with the smp_mb__before_atomic in btrfs_work_helper +* this guarantees that the ordered function will see all +* updates from ordinary work function. +*/ +smp_rmb ();/* * we are going to call the ordered done function, but
@@ -368,6 +375,13 @@ static void normal_work_helper(struct btthresh_exec_hook (wq); work->func (work);if (need_order) { +/* +* Ensures all memory accesses done in the work function are +* ordered before setting the WORK_DONE_BIT. Ensuring the thread +* which is going to executed the ordered work sees them. +* Pairs with the smp_rmb in run_ordered_work. +*/ +smp_mb__before_atomic ();set_bit (WORK_DONE_BIT , &work->flags);run_ordered_work (wq, work); }
Greg Kroah-Hartman
maintainerPATCH 194/207 parisc/sticon: fix reverse colors
In reply to Greg Kroah-HartmanFrom: Sven Schnelle <[email protected]>
commit bec05f33ebc1006899c6d3e59a00c58881fe7626 upstream.
sticon_build_attr() checked the reverse argument and flipped background and foreground color, but returned the non-reverse value afterwards. Fix this and also add two local variables for foreground and background color to make the code easier to read.
--- drivers/video/console/sticon.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/video/console/sticon.c +6 -6
@@ -290,13 +290,13 @@ static unsigned long sticon_getxy(structstatic u8 sticon_build_attr (struct vc_data *conp,u8 color,u8 intens,u8 blink,u8 underline,u8 reverse,u8 italic) { -u8 attr = ((color &0x70 ) >>1 ) | ((color &7 )); +u8 fg = color &7 ; +u8 bg = (color &0x70 ) >>4 ; -if (reverse) { - color = ((color >>3 ) &0x7 ) | ((color &0x7 ) <<3 ); - } - -return attr; +if (reverse) +return (fg <<3 ) | bg; +else +return (bg <<3 ) | fg; }static void sticon_invert_region (struct vc_data *conp,u16 *p,int count)
Greg Kroah-Hartman
maintainerPATCH 195/207 cfg80211: call cfg80211_stop_ap when switch from P2P_GO type
In reply to Greg Kroah-HartmanFrom: Nguyen Dinh Phi <[email protected]>
commit 563fbefed46ae4c1f70cffb8eb54c02df480b2c2 upstream.
If the userspace tools switch from NL80211_IFTYPE_P2P_GO to NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it does not call the cleanup cfg80211_stop_ap(), this leads to the initialization of in-use data. For example, this path re-init the sdata->assigned_chanctx_list while it is still an element of assigned_vifs list, and makes that linked list corrupt.
--- net/wireless/util.c | 1 + 1 file changed, 1 insertion(+)
net/wireless/util.c +1 -0
@@ -1035,6 +1035,7 @@ int cfg80211_change_iface(struct cfg8021switch (otype) {case NL80211_IFTYPE_AP : +case NL80211_IFTYPE_P2P_GO :cfg80211_stop_ap (rdev, dev, true);break ;case NL80211_IFTYPE_ADHOC :
Greg Kroah-Hartman
maintainerPATCH 196/207 drm/udl: fix control-message timeout
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 5591c8f79db1729d9c5ac7f5b4d3a5c26e262d93 upstream.
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ.
--- drivers/gpu/drm/udl/udl_connector.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/udl/udl_connector.c +1 -1
@@ -37,7 +37,7 @@ static u8 *udl_get_edid(struct udl_devic ret =usb_control_msg (udl->udev,usb_rcvctrlpipe (udl->udev,0 ), (0x02 ), (0x80 | (0x02 <<5 )), i <<8 ,0xA1 , rbuf,2 , -HZ ); +1000 );if (ret <1 ) {DRM_ERROR ("Read EDID byte %d failed err %x\n" , i, ret); goto error;
Greg Kroah-Hartman
maintainerPATCH 197/207 drm/amdgpu: fix set scaling mode Full/Full aspect/Center not works on vga and dvi connectors
In reply to Greg Kroah-HartmanFrom: hongao <[email protected]>
commit bf552083916a7f8800477b5986940d1c9a31b953 upstream.
amdgpu_connector_vga_get_modes missed function amdgpu_get_native_mode which assign amdgpu_encoder->native_mode with *preferred_mode result in amdgpu_encoder->native_mode.clock always be 0. That will cause amdgpu_connector_set_property returned early on:
if ((rmx_type != DRM_MODE_SCALE_NONE) &&
(amdgpu_encoder->native_mode.clock == 0))
when we try to set scaling mode Full/Full aspect/Center.
Add the missing function to amdgpu_connector_vga_get_mode can fix this. It also works on dvi connectors because amdgpu_connector_dvi_helper_funcs.get_mode use the same method.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +1 -0
@@ -844,6 +844,7 @@ static int amdgpu_connector_vga_get_modeamdgpu_connector_get_edid (connector); ret =amdgpu_connector_ddc_get_modes (connector); +amdgpu_get_native_mode (connector);return ret; }
Greg Kroah-Hartman
maintainerPATCH 198/207 batman-adv: Keep fragments equally sized
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit 1c2bcc766be44467809f1798cd4ceacafe20a852 upstream.
The batman-adv fragmentation packets have the design problem that they cannot be refragmented and cannot handle padding by the underlying link. The latter often leads to problems when networks are incorrectly configured and don't use a common MTU.
The sender could for example fragment a 1271 byte frame (plus external ethernet header (14) and batadv unicast header (10)) to fit in a 1280 bytes large MTU of the underlying link (max. 1294 byte frames). This would create a 1294 bytes large frame (fragment 2) and a 55 bytes large frame (fragment 1). The extra 54 bytes are the fragment header (20) added to each fragment and the external ethernet header (14) for the second fragment.
Let us assume that the next hop is then not able to transport 1294 bytes to its next hop. The 1294 byte large frame will be dropped but the 55 bytes large fragment will still be forwarded to its destination.
Or let us assume that the underlying hardware requires that each frame has a minimum size (e.g. 60 bytes). Then it will pad the 55 bytes frame to 60 bytes. The receiver of the 60 bytes frame will no longer be able to correctly assemble the two frames together because it is not aware that 5 bytes of the 60 bytes frame are padding and don't belong to the reassembled frame.
This can partly be avoided by splitting frames more equally. In this example, the 675 and 674 bytes large fragment frames could both potentially reach its destination without being too large or too small.
--- net/batman-adv/fragmentation.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-)
net/batman-adv/fragmentation.c +13 -7
@@ -396,7 +396,7 @@ out:* batadv_frag_create - create a fragment from skb * @skb: skb to create fragment from * @frag_head: header to use in new fragment -* @mtu: size of new fragment +* @fragment_size: size of new fragment * * Split the passed skb into two fragments: A new one with size matching the * passed mtu and the old one with the rest. The new skb contains data from the
@@ -406,11 +406,11 @@ out:*/ static struct sk_buff *batadv_frag_create (struct sk_buff *skb,struct batadv_frag_packet *frag_head, -unsigned int mtu) +unsigned int fragment_size) {struct sk_buff *skb_fragment;unsigned int header_size =sizeof (*frag_head); -unsigned int fragment_size = mtu - header_size; +unsigned int mtu = fragment_size + header_size; skb_fragment =netdev_alloc_skb (NULL , mtu +ETH_HLEN );if (!skb_fragment)
@@ -449,7 +449,7 @@ int batadv_frag_send_packet(struct sk_bustruct sk_buff *skb_fragment;unsigned int mtu = neigh_node->if_incoming->net_dev->mtu;unsigned int header_size =sizeof (frag_header); -unsigned int max_fragment_size, max_packet_size; +unsigned int max_fragment_size, num_fragments;int ret =-1 ;/* To avoid merge and refragmentation at next-hops we never send
@@ -457,10 +457,15 @@ int batadv_frag_send_packet(struct sk_bu*/ mtu = min_t(unsigned int, mtu, BATADV_FRAG_MAX_FRAG_SIZE); max_fragment_size = mtu - header_size; - max_packet_size = max_fragment_size *BATADV_FRAG_MAX_FRAGMENTS ; + +if (skb->len ==0 || max_fragment_size ==0 ) +return -EINVAL ; + + num_fragments = (skb->len -1 ) / max_fragment_size +1 ; + max_fragment_size = (skb->len -1 ) / num_fragments +1 ;/* Don't even try to fragment, if we need more than 16 fragments */ -if (skb->len > max_packet_size) +if (num_fragments >BATADV_FRAG_MAX_FRAGMENTS ) goto out; bat_priv = orig_node->bat_priv;
@@ -498,7 +503,8 @@ int batadv_frag_send_packet(struct sk_bu goto out; } - skb_fragment =batadv_frag_create (skb, &frag_header, mtu); + skb_fragment =batadv_frag_create (skb, &frag_header, + max_fragment_size);if (!skb_fragment) goto out;
Greg Kroah-Hartman
maintainerPATCH 199/207 batman-adv: Fix own OGM check in aggregated OGMs
In reply to Greg Kroah-HartmanFrom: Linus L�ssing <[email protected]>
commit d8bf0c01642275c7dca1e5d02c34e4199c200b1f upstream.
The own OGM check is currently misplaced and can lead to the following issues:
For one thing we might receive an aggregated OGM from a neighbor node which has our own OGM in the first place. We would then not only skip our own OGM but erroneously also any other, following OGM in the aggregate.
For another, we might receive an OGM aggregate which has our own OGM in a place other then the first one. Then we would wrongly not skip this OGM, leading to populating the orginator and gateway table with ourself.
--- net/batman-adv/bat_v_ogm.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
net/batman-adv/bat_v_ogm.c +6 -5
@@ -690,6 +690,12 @@ static void batadv_v_ogm_process(const sntohl (ogm_packet->seqno), ogm_throughput, ogm_packet->ttl, ogm_packet->version, ntohs(ogm_packet->tvlv_len)); +if (batadv_is_my_mac (bat_priv, ogm_packet->orig)) { +batadv_dbg (BATADV_DBG_BATMAN , bat_priv, +"Drop packet: originator packet from ourself\n" ); +return ; + } +/* If the troughput metric is 0, immediately drop the packet. No need to * create orig_node / neigh_node for an unusable route. */
@@ -788,11 +794,6 @@ int batadv_v_ogm_packet_recv(struct sk_bif (batadv_is_my_mac (bat_priv, ethhdr->h_source))return NET_RX_DROP ; - ogm_packet = (struct batadv_ogm2_packet *)skb->data; - -if (batadv_is_my_mac (bat_priv, ogm_packet->orig)) -return NET_RX_DROP ; -batadv_inc_counter (bat_priv,BATADV_CNT_MGMT_RX );batadv_add_counter (bat_priv,BATADV_CNT_MGMT_RX_BYTES , skb->len +ETH_HLEN );
Greg Kroah-Hartman
maintainerPATCH 200/207 batman-adv: mcast: fix duplicate mcast packets in BLA backbone from LAN
In reply to Greg Kroah-HartmanFrom: Linus L�ssing <[email protected]>
commit 3236d215ad38a3f5372e65cd1e0a52cf93d3c6a2 upstream.
Scenario:
* Multicast frame send from a BLA backbone (multiple nodes with their bat0 bridged together, with BLA enabled)
Issue:
* BLA backbone nodes receive the frame multiple times on bat0
For multicast frames received via batman-adv broadcast packets the originator of the broadcast packet is checked before decapsulating and forwarding the frame to bat0 (batadv_bla_is_backbone_gw()-> batadv_recv_bcast_packet()). If it came from a node which shares the same BLA backbone with us then it is not forwarded to bat0 to avoid a loop.
When sending a multicast frame in a non-4-address batman-adv unicast packet we are currently missing this check - and cannot do so because the batman-adv unicast packet has no originator address field.
However, we can simply fix this on the sender side by only sending the multicast frame via unicasts to interested nodes which do not share the same BLA backbone with us. This also nicely avoids some unnecessary transmissions on mesh side.
Note that no infinite loop was observed, probably because of dropping via batadv_interface_tx()->batadv_bla_tx(). However the duplicates still utterly confuse switches/bridges, ICMPv6 duplicate address detection and neighbor discovery and therefore leads to long delays before being able to establish TCP connections, for instance. And it also leads to the Linux bridge printing messages like:
"br-lan: received packet on eth1 with own address as source address ..."
--- net/batman-adv/multicast.c | 31 +++++++++++++++++++++++++++++++ net/batman-adv/multicast.h | 15 +++++++++++++++ net/batman-adv/soft-interface.c | 5 ++--- 3 files changed, 48 insertions(+), 3 deletions(-)
net/batman-adv/multicast.c +31 -0
@@ -53,10 +53,12 @@#include <net/ip.h> #include <net/ipv6.h> +#include "bridge_loop_avoidance.h" #include "hard-interface.h" #include "hash.h" #include "log.h" #include "packet.h" +#include "send.h" #include "translation-table.h" #include "tvlv.h"
@@ -1252,6 +1254,35 @@ void batadv_mcast_free(struct batadv_pri }/** +* batadv_mcast_forw_send_orig() - send a multicast packet to an originator +* @bat_priv: the bat priv with all the soft interface information +* @skb: the multicast packet to send +* @vid: the vlan identifier +* @orig_node: the originator to send the packet to +* +* Return: NET_XMIT_DROP in case of error or NET_XMIT_SUCCESS otherwise. +*/ +int batadv_mcast_forw_send_orig (struct batadv_priv *bat_priv, +struct sk_buff *skb, +unsigned short vid, +struct batadv_orig_node *orig_node) +{ +/* Avoid sending multicast-in-unicast packets to other BLA +* gateways - they already got the frame from the LAN side +* we share with them. +* TODO: Refactor to take BLA into account earlier, to avoid +* reducing the mcast_fanout count. +*/ +if (batadv_bla_is_backbone_gw_orig (bat_priv, orig_node->orig, vid)) { +dev_kfree_skb (skb); +return NET_XMIT_SUCCESS ; + } + +return batadv_send_skb_unicast (bat_priv, skb,BATADV_UNICAST ,0 , + orig_node, vid); +} + +/** * batadv_mcast_purge_orig - reset originator global mcast state modifications * @orig: the originator which is going to get purged */
net/batman-adv/multicast.h +15 -0
@@ -45,6 +45,11 @@ enum batadv_forw_mode batadv_mcast_forw_mode(struct batadv_priv *bat_priv, struct sk_buff *skb, struct batadv_orig_node **mcast_single_orig); +int batadv_mcast_forw_send_orig (struct batadv_priv *bat_priv, +struct sk_buff *skb, +unsigned short vid, +struct batadv_orig_node *orig_node); +void batadv_mcast_init (struct batadv_priv *bat_priv);int batadv_mcast_flags_seq_print_text (struct seq_file *seq,void *offset);
@@ -71,6 +76,16 @@ static inline int batadv_mcast_init(strureturn 0 ; } +static inline int +batadv_mcast_forw_send_orig (struct batadv_priv *bat_priv, +struct sk_buff *skb, +unsigned short vid, +struct batadv_orig_node *orig_node) +{ +kfree_skb (skb); +return NET_XMIT_DROP ; +} +static inline void batadv_mcast_free (struct batadv_priv *bat_priv) { }
net/batman-adv/soft-interface.c +2 -3
@@ -356,9 +356,8 @@ send: goto dropped; ret =batadv_send_skb_via_gw (bat_priv, skb, vid); }else if (mcast_single_orig) { - ret =batadv_send_skb_unicast (bat_priv, skb, -BATADV_UNICAST ,0 , - mcast_single_orig, vid); + ret =batadv_mcast_forw_send_orig (bat_priv, skb, vid, + mcast_single_orig); }else {if (batadv_dat_snoop_outgoing_arp_request (bat_priv, skb))
Greg Kroah-Hartman
maintainerPATCH 201/207 batman-adv: mcast: fix duplicate mcast packets from BLA backbone to mesh
In reply to Greg Kroah-HartmanFrom: Linus L�ssing <[email protected]>
commit 2369e827046920ef0599e6a36b975ac5c0a359c2 upstream.
Scenario:
* Multicast frame send from BLA backbone gateways (multiple nodes with their bat0 bridged together, with BLA enabled) sharing the same LAN to nodes in the mesh
Issue:
* Nodes receive the frame multiple times on bat0 from the mesh, once from each foreign BLA backbone gateway which shares the same LAN with another
For multicast frames via batman-adv broadcast packets coming from the same BLA backbone but from different backbone gateways duplicates are currently detected via a CRC history of previously received packets.
However this CRC so far was not performed for multicast frames received via batman-adv unicast packets. Fixing this by appyling the same check for such packets, too.
Room for improvements in the future: Ideally we would introduce the possibility to not only claim a client, but a complete originator, too. This would allow us to only send a multicast-in-unicast packet from a BLA backbone gateway claiming the node and by that avoid potential redundant transmissions in the first place.
--- net/batman-adv/bridge_loop_avoidance.c | 105 +++++++++++++++++++++++++++------ 1 file changed, 88 insertions(+), 17 deletions(-)
net/batman-adv/bridge_loop_avoidance.c +88 -17
@@ -1593,13 +1593,16 @@ int batadv_bla_init(struct batadv_priv * }/** -* batadv_bla_check_bcast_duplist - Check if a frame is in the broadcast dup. +* batadv_bla_check_duplist() - Check if a frame is in the broadcast dup. * @bat_priv: the bat priv with all the soft interface information -* @skb: contains the bcast_packet to be checked -* -* check if it is on our broadcast list. Another gateway might -* have sent the same packet because it is connected to the same backbone, -* so we have to remove this duplicate. +* @skb: contains the multicast packet to be checked +* @payload_ptr: pointer to position inside the head buffer of the skb +* marking the start of the data to be CRC'ed +* @orig: originator mac address, NULL if unknown +* +* Check if it is on our broadcast list. Another gateway might have sent the +* same packet because it is connected to the same backbone, so we have to +* remove this duplicate. * * This is performed by checking the CRC, which will tell us * with a good chance that it is the same packet. If it is furthermore
@@ -1608,19 +1611,17 @@ int batadv_bla_init(struct batadv_priv ** * Return: true if a packet is in the duplicate list, false otherwise. */ -bool batadv_bla_check_bcast_duplist (struct batadv_priv *bat_priv, -struct sk_buff *skb) +static bool batadv_bla_check_duplist (struct batadv_priv *bat_priv, +struct sk_buff *skb,u8 *payload_ptr, +const u8 *orig) { -int i, curr; -__be32 crc; -struct batadv_bcast_packet *bcast_packet;struct batadv_bcast_duplist_entry *entry;bool ret = false; - - bcast_packet = (struct batadv_bcast_packet *)skb->data; +int i, curr; +__be32 crc;/* calculate the crc ... */ - crc =batadv_skb_crc32 (skb, (u8 *)(bcast_packet +1 )); + crc =batadv_skb_crc32 (skb, payload_ptr);spin_lock_bh (&bat_priv->bla.bcast_duplist_lock);
@@ -1639,8 +1640,21 @@ bool batadv_bla_check_bcast_duplist(struif (entry->crc != crc)continue ; -if (batadv_compare_eth (entry->orig, bcast_packet->orig)) -continue ; +/* are the originators both known and not anonymous? */ +if (orig && !is_zero_ether_addr (orig) && + !is_zero_ether_addr (entry->orig)) { +/* If known, check if the new frame came from +* the same originator: +* We are safe to take identical frames from the +* same orig, if known, as multiplications in +* the mesh are detected via the (orig, seqno) pair. +* So we can be a bit more liberal here and allow +* identical frames from the same orig which the source +* host might have sent multiple times on purpose. +*/ +if (batadv_compare_eth (entry->orig, orig)) +continue ; + }/* this entry seems to match: same crc, not too old, * and from another gw. therefore return true to forbid it.
@@ -1656,7 +1670,14 @@ bool batadv_bla_check_bcast_duplist(stru entry = &bat_priv->bla.bcast_duplist[curr]; entry->crc = crc; entry->entrytime = jiffies; -ether_addr_copy (entry->orig, bcast_packet->orig); + +/* known originator */ +if (orig) +ether_addr_copy (entry->orig, orig); +/* anonymous originator */ +else +eth_zero_addr (entry->orig); + bat_priv->bla.bcast_duplist_curr = curr; out:
@@ -1666,6 +1687,48 @@ out: }/** +* batadv_bla_check_ucast_duplist() - Check if a frame is in the broadcast dup. +* @bat_priv: the bat priv with all the soft interface information +* @skb: contains the multicast packet to be checked, decapsulated from a +* unicast_packet +* +* Check if it is on our broadcast list. Another gateway might have sent the +* same packet because it is connected to the same backbone, so we have to +* remove this duplicate. +* +* Return: true if a packet is in the duplicate list, false otherwise. +*/ +static bool batadv_bla_check_ucast_duplist (struct batadv_priv *bat_priv, +struct sk_buff *skb) +{ +return batadv_bla_check_duplist (bat_priv, skb, (u8 *)skb->data,NULL ); +} + +/** +* batadv_bla_check_bcast_duplist() - Check if a frame is in the broadcast dup. +* @bat_priv: the bat priv with all the soft interface information +* @skb: contains the bcast_packet to be checked +* +* Check if it is on our broadcast list. Another gateway might have sent the +* same packet because it is connected to the same backbone, so we have to +* remove this duplicate. +* +* Return: true if a packet is in the duplicate list, false otherwise. +*/ +bool batadv_bla_check_bcast_duplist (struct batadv_priv *bat_priv, +struct sk_buff *skb) +{ +struct batadv_bcast_packet *bcast_packet; +u8 *payload_ptr; + + bcast_packet = (struct batadv_bcast_packet *)skb->data; + payload_ptr = (u8 *)(bcast_packet +1 ); + +return batadv_bla_check_duplist (bat_priv, skb, payload_ptr, + bcast_packet->orig); +} + +/** * batadv_bla_is_backbone_gw_orig - Check if the originator is a gateway for * the VLAN identified by vid. * @bat_priv: the bat priv with all the soft interface information
@@ -1879,6 +1942,14 @@ bool batadv_bla_rx(struct batadv_priv *b packet_type == BATADV_UNICAST) goto handled; +/* potential duplicates from foreign BLA backbone gateways via +* multicast-in-unicast packets +*/ +if (is_multicast_ether_addr (ethhdr->h_dest) && + packet_type ==BATADV_UNICAST && +batadv_bla_check_ucast_duplist (bat_priv, skb)) + goto handled; +ether_addr_copy (search_claim.addr, ethhdr->h_source); search_claim.vid = vid; claim =batadv_claim_hash_find (bat_priv, &search_claim);
Greg Kroah-Hartman
maintainerPATCH 202/207 batman-adv: Consider fragmentation for needed_headroom
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit 4ca23e2c2074465bff55ea14221175fecdf63c5f upstream.
If a batman-adv packets has to be fragmented, then the original batman-adv packet header is not stripped away. Instead, only a new header is added in front of the packet after it was split.
This size must be considered to avoid cost intensive reallocations during the transmission through the various device layers.
--- net/batman-adv/hard-interface.c | 3 +++ 1 file changed, 3 insertions(+)
net/batman-adv/hard-interface.c +3 -0
@@ -359,6 +359,9 @@ static void batadv_hardif_recalc_extra_s needed_headroom = lower_headroom + (lower_header_len -ETH_HLEN ); needed_headroom +=batadv_max_header_len (); +/* fragmentation headers don't strip the unicast/... header */ + needed_headroom +=sizeof (struct batadv_frag_packet ); + soft_iface->needed_headroom = needed_headroom; soft_iface->needed_tailroom = lower_tailroom; }
Greg Kroah-Hartman
maintainerPATCH 203/207 batman-adv: Reserve needed_*room for fragments
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit c5cbfc87558168ef4c3c27ce36eba6b83391db19 upstream.
The batadv net_device is trying to propagate the needed_headroom and needed_tailroom from the lower devices. This is needed to avoid cost intensive reallocations using pskb_expand_head during the transmission.
But the fragmentation code split the skb's without adding extra room at the end/beginning of the various fragments. This reduced the performance of transmissions over complex scenarios (batadv on vxlan on wireguard) because the lower devices had to perform the reallocations at least once.
--- net/batman-adv/fragmentation.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
net/batman-adv/fragmentation.c +10 -5
@@ -394,6 +394,7 @@ out:/** * batadv_frag_create - create a fragment from skb +* @net_dev: outgoing device for fragment * @skb: skb to create fragment from * @frag_head: header to use in new fragment * @fragment_size: size of new fragment
@@ -404,22 +405,25 @@ out:* * Return: the new fragment, NULL on error. */ -static struct sk_buff *batadv_frag_create (struct sk_buff *skb, +static struct sk_buff *batadv_frag_create (struct net_device *net_dev, +struct sk_buff *skb,struct batadv_frag_packet *frag_head,unsigned int fragment_size) { +unsigned int ll_reserved =LL_RESERVED_SPACE (net_dev); +unsigned int tailroom = net_dev->needed_tailroom;struct sk_buff *skb_fragment;unsigned int header_size =sizeof (*frag_head);unsigned int mtu = fragment_size + header_size; - skb_fragment =netdev_alloc_skb (NULL , mtu +ETH_HLEN ); + skb_fragment =dev_alloc_skb (ll_reserved + mtu + tailroom);if (!skb_fragment) goto err; skb_fragment->priority = skb->priority;/* Eat the last mtu-bytes of the skb */ -skb_reserve (skb_fragment, header_size +ETH_HLEN ); +skb_reserve (skb_fragment, ll_reserved + header_size);skb_split (skb, skb_fragment, skb->len - fragment_size);/* Add the header */
@@ -443,11 +447,12 @@ int batadv_frag_send_packet(struct sk_bustruct batadv_orig_node *orig_node, struct batadv_neigh_node *neigh_node) { + struct net_device *net_dev = neigh_node->if_incoming->net_dev;struct batadv_priv *bat_priv;struct batadv_hard_iface *primary_if =NULL ;struct batadv_frag_packet frag_header;struct sk_buff *skb_fragment; -unsigned int mtu = neigh_node->if_incoming->net_dev->mtu; +unsigned int mtu = net_dev->mtu;unsigned int header_size =sizeof (frag_header);unsigned int max_fragment_size, num_fragments;int ret =-1 ;
@@ -503,7 +508,7 @@ int batadv_frag_send_packet(struct sk_bu goto out; } - skb_fragment =batadv_frag_create (skb, &frag_header, + skb_fragment =batadv_frag_create (net_dev, skb, &frag_header, max_fragment_size);if (!skb_fragment) goto out;
Greg Kroah-Hartman
maintainerPATCH 204/207 batman-adv: Dont always reallocate the fragmentation skb head
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit 992b03b88e36254e26e9a4977ab948683e21bd9f upstream.
When a packet is fragmented by batman-adv, the original batman-adv header is not modified. Only a new fragmentation is inserted between the original one and the ethernet header. The code must therefore make sure that it has a writable region of this size in the skbuff head.
But it is not useful to always reallocate the skbuff by this size even when there would be more than enough headroom still in the skb. The reallocation is just to costly during in this codepath.
--- net/batman-adv/fragmentation.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
net/batman-adv/fragmentation.c +6 -3
@@ -528,11 +528,14 @@ int batadv_frag_send_packet(struct sk_bu frag_header.no++; } -/* Make room for the fragment header. */ -if (batadv_skb_head_push (skb, header_size) <0 || -pskb_expand_head (skb, header_size +ETH_HLEN ,0 ,GFP_ATOMIC ) <0 ) +/* make sure that there is at least enough head for the fragmentation +* and ethernet headers +*/ + ret =skb_cow_head (skb,ETH_HLEN + header_size); +if (ret <0 ) goto out; +skb_push (skb, header_size);memcpy (skb->data, &frag_header, header_size);/* Send the last fragment */
Greg Kroah-Hartman
maintainerPATCH 205/207 ASoC: DAPM: Cover regression by kctl change notification fix
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit 827b0913a9d9d07a0c3e559dbb20ca4d6d285a54 upstream.
The recent fix for DAPM to correct the kctl change notification by the commit 5af82c81b2c4 ("ASoC: DAPM: Fix missing kctl change notifications") caused other regressions since it changed the behavior of snd_soc_dapm_set_pin() that is called from several API functions. Formerly it returned always 0 for success, but now it returns 0 or 1.
This patch addresses it, restoring the old behavior of snd_soc_dapm_set_pin() while keeping the fix in snd_soc_dapm_put_pin_switch().
--- sound/soc/soc-dapm.c | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-)
sound/soc/soc-dapm.c +23 -6
@@ -2406,8 +2406,13 @@ static struct snd_soc_dapm_widget *dapm_return NULL ; } -static int snd_soc_dapm_set_pin (struct snd_soc_dapm_context *dapm, -const char *pin,int status) +/* +* set the DAPM pin status: +* returns 1 when the value has been updated, 0 when unchanged, or a negative +* error code; called from kcontrol put callback +*/ +static int __snd_soc_dapm_set_pin (struct snd_soc_dapm_context *dapm, +const char *pin,int status) {struct snd_soc_dapm_widget *w =dapm_find_widget (dapm, pin, true);int ret =0 ;
@@ -2433,6 +2438,18 @@ static int snd_soc_dapm_set_pin(struct sreturn ret; } +/* +* similar as __snd_soc_dapm_set_pin(), but returns 0 when successful; +* called from several API functions below +*/ +static int snd_soc_dapm_set_pin (struct snd_soc_dapm_context *dapm, +const char *pin,int status) +{ +int ret =__snd_soc_dapm_set_pin (dapm, pin, status); + +return ret <0 ? ret :0 ; +} +/** * snd_soc_dapm_sync_unlocked - scan and power dapm paths * @dapm: DAPM context
@@ -3327,10 +3344,10 @@ int snd_soc_dapm_put_pin_switch(struct sconst char *pin = (const char *)kcontrol->private_value;int ret; -if (ucontrol->value.integer.value[0 ]) - ret =snd_soc_dapm_enable_pin (&card->dapm, pin); -else - ret =snd_soc_dapm_disable_pin (&card->dapm, pin); +mutex_lock_nested (&card->dapm_mutex,SND_SOC_DAPM_CLASS_RUNTIME ); + ret =__snd_soc_dapm_set_pin (&card->dapm, pin, + !!ucontrol->value.integer.value[0 ]); +mutex_unlock (&card->dapm_mutex);snd_soc_dapm_sync (&card->dapm);return ret;
Greg Kroah-Hartman
maintainerPATCH 206/207 usb: max-3421: Use driver data instead of maintaining a list of bound devices
In reply to Greg Kroah-HartmanFrom: Uwe Kleine-König <[email protected]>
commit fc153aba3ef371d0d76eb88230ed4e0dee5b38f2 upstream.
Instead of maintaining a single-linked list of devices that must be searched linearly in .remove() just use spi_set_drvdata() to remember the link between the spi device and the driver struct. Then the global list and the next member can be dropped.
This simplifies the driver, reduces the memory footprint and the time to search the list. Also it makes obvious that there is always a corresponding driver struct for a given device in .remove(), so the error path for !max3421_hcd can be dropped, too.
As a side effect this fixes a data inconsistency when .probe() races with itself for a second max3421 device in manipulating max3421_hcd_list. A similar race is fixed in .remove(), too.
--- drivers/usb/host/max3421-hcd.c | 25 +++++-------------------- 1 file changed, 5 insertions(+), 20 deletions(-)
drivers/usb/host/max3421-hcd.c +5 -20
@@ -121,8 +121,6 @@ struct max3421_hcd {struct task_struct *spi_thread; -struct max3421_hcd *next; -enum max3421_rh_state rh_state;/* lower 16 bits contain port status, upper 16 bits the change mask: */ u32 port_status;
@@ -170,8 +168,6 @@ struct max3421_ep {u8 retransmit;/* packet needs retransmission */ }; -static struct max3421_hcd *max3421_hcd_list; -#define MAX3421_FIFO_SIZE 64#define MAX3421_SPI_DIR_RD 0/* read register from MAX3421 */
@@ -1835,9 +1831,8 @@ max3421_probe(struct spi_device *spi) }set_bit (HCD_FLAG_POLL_RH , &hcd->flags); max3421_hcd =hcd_to_max3421 (hcd); - max3421_hcd->next = max3421_hcd_list; - max3421_hcd_list = max3421_hcd;INIT_LIST_HEAD (&max3421_hcd->ep_list); +spi_set_drvdata (spi, max3421_hcd); max3421_hcd->tx =kmalloc (sizeof (*max3421_hcd->tx),GFP_KERNEL );if (!max3421_hcd->tx)
@@ -1882,28 +1877,18 @@ error:static int max3421_remove (struct spi_device *spi) { -struct max3421_hcd *max3421_hcd =NULL , **prev; -struct usb_hcd *hcd =NULL ; +struct max3421_hcd *max3421_hcd; +struct usb_hcd *hcd;unsigned long flags; -for (prev = &max3421_hcd_list; *prev; prev = &(*prev)->next) { - max3421_hcd = *prev; - hcd =max3421_to_hcd (max3421_hcd); -if (hcd->self.controller == &spi->dev) -break ; - } -if (!max3421_hcd) { -dev_err (&spi->dev,"no MAX3421 HCD found for SPI device %p\n" , - spi); -return -ENODEV ; - } + max3421_hcd =spi_get_drvdata (spi); + hcd =max3421_to_hcd (max3421_hcd);usb_remove_hcd (hcd);spin_lock_irqsave (&max3421_hcd->lock, flags);kthread_stop (max3421_hcd->spi_thread); - *prev = max3421_hcd->next;spin_unlock_irqrestore (&max3421_hcd->lock, flags);
Greg Kroah-Hartman
maintainerPATCH 207/207 hugetlbfs: flush TLBs correctly after huge_pmd_unshare
In reply to Greg Kroah-HartmanFrom: Nadav Amit <[email protected]>
commit a4a118f2eead1d6c49e00765de89878288d4b890 upstream.
When __unmap_hugepage_range() calls to huge_pmd_unshare() succeed, a TLB flush is missing. This TLB flush must be performed before releasing the i_mmap_rwsem, in order to prevent an unshared PMDs page from being released and reused before the TLB flush took place.
Arguably, a comprehensive solution would use mmu_gather interface to batch the TLB flushes and the PMDs page release, however it is not an easy solution: (1) try_to_unmap_one() and try_to_migrate_one() also call huge_pmd_unshare() and they cannot use the mmu_gather interface; and (2) deferring the release of the page reference for the PMDs page until after i_mmap_rwsem is dropeed can confuse huge_pmd_unshare() into thinking PMDs are shared when they are not.
Fix __unmap_hugepage_range() by adding the missing TLB flush, and forcing a flush when unshare is successful.
--- include/asm-generic/tlb.h | 17 +++++++++++++++++ mm/hugetlb.c | 19 +++++++++++++++++++ 2 files changed, 36 insertions(+)
include/asm-generic/tlb.h +17 -0
@@ -202,6 +202,23 @@ static inline bool __tlb_remove_pte_page#define tlb_end_vma __tlb_end_vma#endif +static inline void tlb_flush_pmd_range (struct mmu_gather *tlb, +unsigned long address,unsigned long size) +{ +if (tlb->page_size !=0 && tlb->page_size !=PMD_SIZE ) +tlb_flush_mmu (tlb); + + tlb->page_size =PMD_SIZE ; + tlb->start =min (tlb->start, address); + tlb->end =max (tlb->end, address + size); +/* +* Track the last address with which we adjusted the range. This +* will be used later to adjust again after a mmu_flush due to +* failed __tlb_remove_page +*/ + tlb->addr = address + size -PMD_SIZE ; +} +#ifndef __tlb_remove_tlb_entry#define __tlb_remove_tlb_entry (tlb, ptep, address) do { } while (0)#endif
mm/hugetlb.c +19 -0
@@ -3395,6 +3395,7 @@ void __unmap_hugepage_range(struct mmu_gunsigned long sz =huge_page_size (h);const unsigned long mmun_start = start;/* For mmu_notifiers */ const unsigned long mmun_end = end;/* For mmu_notifiers */ +bool force_flush = false;WARN_ON (!is_vm_hugetlb_page (vma));BUG_ON (start & ~huge_page_mask (h));
@@ -3411,6 +3412,8 @@ void __unmap_hugepage_range(struct mmu_g ptl =huge_pte_lock (h, mm, ptep);if (huge_pmd_unshare (mm, &address, ptep)) {spin_unlock (ptl); +tlb_flush_pmd_range (tlb, address &PUD_MASK ,PUD_SIZE ); + force_flush = true;continue ; }
@@ -3467,6 +3470,22 @@ void __unmap_hugepage_range(struct mmu_g }mmu_notifier_invalidate_range_end (mm, mmun_start, mmun_end);tlb_end_vma (tlb, vma); + +/* +* If we unshared PMDs, the TLB flush was not recorded in mmu_gather. We +* could defer the flush until now, since by holding i_mmap_rwsem we +* guaranteed that the last refernece would not be dropped. But we must +* do the flushing before we return, as otherwise i_mmap_rwsem will be +* dropped and the last reference to the shared PMDs page might be +* dropped as well. +* +* In theory we could defer the freeing of the PMD pages as well, but +* huge_pmd_unshare() relies on the exact page_count for the PMD page to +* detect sharing, so we cannot defer the release of the page either. +* Instead, do flush now. +*/ +if (force_flush) +tlb_flush_mmu (tlb); } void __unmap_hugepage_range_final(struct mmu_gather *tlb,
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.291 release. There are 207 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
c6x, microblaze builds:
In file included from arch/c6x/include/asm/tlb.h:6,
from mm/oom_kill.c:42:
include/asm-generic/tlb.h: In function 'tlb_flush_pmd_range':include/asm-generic/tlb.h:208:47: error: 'PMD_SIZE' undeclared
There are probably going to be more failures; builds are not complete yet.
Guenter
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.291 release. There are 207 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.291-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
Regression found on arm gcc-11 builds with tinyconfig and allnoconfig. As a reported in this email,
https://lore.kernel.org/stable/CA+G9fYvU4yoOx7BEBxJXRVZx4pO5fYPRELmkNz+iBu7kdN_9Ew@mail.gmail.com/
build error :
--------------
make --silent --keep-going --jobs=8 O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 'CC=sccache arm-linux-gnueabihf-gcc' 'HOSTCC=sccache gcc' In file included from arch/arm/include/asm/tlb.h:28,
from arch/arm/mm/init.c:34:
include/asm-generic/tlb.h: In function 'tlb_flush_pmd_range':
include/asm-generic/tlb.h:208:54: error: 'PMD_SIZE' undeclared (first
use in this function); did you mean 'PUD_SIZE'?
208 | if (tlb->page_size != 0 && tlb->page_size != PMD_SIZE)
| ^~~~~~~~
| PUD_SIZEinclude/asm-generic/tlb.h:208:54: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [scripts/Makefile.build:307: arch/arm/mm/init.o] Error 1 make[2]: Target '__build' not remade because of errors. make[1]: *** [Makefile:1036: arch/arm/mm] Error 2
Patch pointing to,
hugetlbfs: flush TLBs correctly after huge_pmd_unshare commit a4a118f2eead1d6c49e00765de89878288d4b890 upstream.
--
Linaro LKFT
https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 47 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.291 release. There are 207 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.291-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
Regression found on arm gcc-11 builds with tinyconfig and allnoconfig. As a reported in this email,
https://lore.kernel.org/stable/CA+G9fYvU4yoOx7BEBxJXRVZx4pO5fYPRELmkNz+iBu7kdN_9Ew@mail.gmail.com/
build error :
--------------
make --silent --keep-going --jobs=8 O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 'CC=sccache arm-linux-gnueabihf-gcc' 'HOSTCC=sccache gcc' In file included fromarch/arm/include/asm/tlb.h:28,from arch/arm/mm/init.c:34: include/asm-generic/tlb.h: In function 'tlb_flush_pmd_range': include/asm-generic/tlb.h:208:54: error: 'PMD_SIZE' undeclared (first use in this function); did you mean 'PUD_SIZE'? 208 | if (tlb->page_size != 0 && tlb->page_size != PMD_SIZE) | ^~~~~~~~ | PUD_SIZE
include/asm-generic/tlb.h:208:54: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [scripts/Makefile.build:307:arch/arm/mm/init.o] Error 1 make[2]: Target '__build' not remade because of errors. make[1]: *** [Makefile:1036:arch/arm/mm] Error 2
Quoted 6 lines
Patch pointing to,
hugetlbfs: flush TLBs correctly after
huge_pmd_unsharecommita4a118f2eead1d6c49e00765de89878288d4b890upstream.
Should be fixed in -rc2
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.291 release. There are 207 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
sh:dreamcast_defconfig:
mm/hugetlb.c: In function '__unmap_hugepage_range':mm/hugetlb.c:3415:25: error: implicit declaration of function 'tlb_flush_pmd_range'
Guenter
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.291 release. There are 207 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
Build results:
total: 163 pass: 134 fail: 29 Failed builds: arm:allnoconfig arm:tinyconfig arm:efm32_defconfig blackfin:defconfig blackfin:BF561-EZKIT-SMP_defconfig c6x:dsk6455_defconfig c6x:evmc6457_defconfig c6x:evmc6678_defconfig h8300:allnoconfig h8300:tinyconfig h8300:edosk2674_defconfig h8300:h8300h-sim_defconfig h8300:h8s-sim_defconfig ia64:defconfig m68k:allnoconfig m68k:tinyconfig m68k_nommu:m5272c3_defconfig m68k_nommu:m5307c3_defconfig m68k_nommu:m5249evb_defconfig m68k_nommu:m5407c3_defconfig microblaze:nommu_defconfig microblaze:allnoconfig microblaze:tinyconfig s390:defconfig s390:allmodconfig s390:performance_defconfig sh:dreamcast_defconfig sh:microdev_defconfig sh:shx3_defconfig Qemu test results: total: 396 pass: 389 fail: 7 Failed tests: arm:mps2-an385:mps2_defconfig:mps2-an385:initrd mcf5208evb:m5208:m5208evb_defconfig:initrd s390:defconfig:nolocktests:smp2:net,default:initrd s390:defconfig:nolocktests:smp2:virtio-blk-ccw:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:smp2:scsi[virtio-ccw]:net,default:rootfs s390:defconfig:nolocktests:virtio-pci:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:scsi[virtio-pci]:net,default:rootfs
include/asm-generic/tlb.h: In function 'tlb_flush_pmd_range':include/asm-generic/tlb.h:208:54: error: 'PMD_SIZE' undeclared
mm/hugetlb.c: In function '__unmap_hugepage_range':mm/hugetlb.c:3415:25: error: implicit declaration of function 'tlb_flush_pmd_range'
Guenter
Greg Kroah-Hartman
maintainerQuoted 53 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.291 release. There are 207 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
Build results:
total: 163 pass: 134 fail: 29 Failed builds: arm:allnoconfig arm:tinyconfig arm:efm32_defconfig blackfin:defconfig blackfin:BF561-EZKIT-SMP_defconfig c6x:dsk6455_defconfig c6x:evmc6457_defconfig c6x:evmc6678_defconfig h8300:allnoconfig h8300:tinyconfig h8300:edosk2674_defconfig h8300:h8300h-sim_defconfig h8300:h8s-sim_defconfig ia64:defconfig m68k:allnoconfig m68k:tinyconfig m68k_nommu:m5272c3_defconfig m68k_nommu:m5307c3_defconfig m68k_nommu:m5249evb_defconfig m68k_nommu:m5407c3_defconfig microblaze:nommu_defconfig microblaze:allnoconfig microblaze:tinyconfig s390:defconfig s390:allmodconfig s390:performance_defconfig sh:dreamcast_defconfig sh:microdev_defconfig sh:shx3_defconfig Qemu test results: total: 396 pass: 389 fail: 7 Failed tests: arm:mps2-an385:mps2_defconfig:mps2-an385:initrd mcf5208evb:m5208:m5208evb_defconfig:initrd s390:defconfig:nolocktests:smp2:net,default:initrd s390:defconfig:nolocktests:smp2:virtio-blk-ccw:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:smp2:scsi[virtio-ccw]:net,default:rootfs s390:defconfig:nolocktests:virtio-pci:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:scsi[virtio-pci]:net,default:rootfs
Quoted 7 lines
include/asm-generic/tlb.h: In function 'tlb_flush_pmd_range':include/asm-generic/tlb.h:208:54: error: 'PMD_SIZE' undeclared
mm/hugetlb.c: In function '__unmap_hugepage_range':mm/hugetlb.c:3415:25: error: implicit declaration of function 'tlb_flush_pmd_range'Guenter
Hopefully all now fixed in -rc2
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.291 release. There are 207 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.291-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
FYI,
New warnings noticed,
Linux 4.9.291-rc1 on arm (defconfig) with gcc-11
drivers/soc/tegra/pmc.c: In function 'tegra_powergate_power_up':drivers/soc/tegra/pmc.c:412:1: warning: label 'powergate_off' defined but not used [-Wunused-label]
412 | powergate_off:
| ^~~~~~~~~~~~~
--
Linaro LKFT
https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 26 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.291 release. There are 207 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.291-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
FYI,
New warnings noticed,Linux 4.9.291-rc1 on arm (defconfig) with gcc-11
Quoted 7 lines
drivers/soc/tegra/pmc.c: In function 'tegra_powergate_power_up':drivers/soc/tegra/pmc.c:412:1: warning: label 'powergate_off' defined but not used [-Wunused-label]
412 |powergate_off:| ^~~~~~~~~~~~~
Now fixed up, thanks.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.291 release. There are 207 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.291-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.9:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
32 tests: 32 pass, 0 failLinux version: 4.9.291-rc1-gb2ae18f41670
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Jon