- 26 Jul, 2019 40 commits
-
-
Robert Hancock authored
[ Upstream commit 7de44285 ] It is possible that the interrupt handler fires and frees up space in the TX ring in between checking for sufficient TX ring space and stopping the TX queue in axienet_start_xmit. If this happens, the queue wake from the interrupt handler will occur before the queue is stopped, causing a lost wakeup and the adapter's transmit hanging. To avoid this, after stopping the queue, check again whether there is sufficient space in the TX ring. If so, wake up the queue again. Signed-off-by:
Robert Hancock <hancock@sedsystems.ca> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Fabio Estevam authored
[ Upstream commit a19a0582 ] When a valid MAC address is not found the current messages are shown: fec 2188000.ethernet (unnamed net_device) (uninitialized): Invalid MAC address: 00:00:00:00:00:00 fec 2188000.ethernet (unnamed net_device) (uninitialized): Using random MAC address: aa:9f:25:eb:7e:aa Since the network device has not been registered at this point, it is better to use dev_err()/dev_info() instead, which will provide cleaner log messages like these: fec 2188000.ethernet: Invalid MAC address: 00:00:00:00:00:00 fec 2188000.ethernet: Using random MAC address: aa:9f:25:eb:7e:aa Tested on a imx6dl-pico-pi board. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Antoine Tenart authored
[ Upstream commit 89332590 ] When performing a transformation the hardware is given result descriptors to save the result data. Those result descriptors are batched using a 'first' and a 'last' bit. There are cases were more descriptors than needed are given to the engine, leading to the engine only using some of them, and not setting the last bit on the last descriptor we gave. This causes issues were the driver and the hardware aren't in sync anymore about the number of result descriptors given (as the driver do not give a pool of descriptor to use for any transformation, but a pool of descriptors to use *per* transformation). This patch fixes it by attaching the number of given result descriptors to the requests, and by using this number instead of the 'last' bit found on the descriptors to process them. Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Biao Huang authored
[ Upstream commit d2facb4b ] the default value of tx-frames is 25, it's too late when passing tstamp to stack, then the ptp4l will fail: ptp4l -i eth0 -f gPTP.cfg -m ptp4l: selected /dev/ptp0 as PTP clock ptp4l: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l: port 1: link up ptp4l: timed out while polling for tx timestamp ptp4l: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l: port 1: send peer delay response failed ptp4l: port 1: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l tests pass when changing the tx-frames from 25 to 1 with ethtool -C option. It should be fine to set tx-frames default value to 1, so ptp4l will pass by default. Signed-off-by:
Biao Huang <biao.huang@mediatek.com> Signed-off-by:
-
Biao Huang authored
[ Upstream commit ee326fd0 ] Current dwmac4_flow_ctrl will not clear GMAC_RX_FLOW_CTRL_RFE/GMAC_RX_FLOW_CTRL_RFE bits, so MAC hw will keep flow control on although expecting flow control off by ethtool. Add codes to fix it. Fixes: 477286b5 ("stmmac: add GMAC4 core support") Signed-off-by:
-
Jiri Olsa authored
[ Upstream commit 279ab04d ] We are getting false positive gcc warning when we compile with gcc9 (9.1.1): CC jvmti/libjvmti.o In file included from /usr/include/string.h:494, from jvmti/libjvmti.c:5: In function ‘strncpy’, inlined from ‘copy_class_filename.constprop’ at jvmti/libjvmti.c:166:3: /usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ jvmti/libjvmti.c: In function ‘copy_class_filename.constprop’: jvmti/libjvmti.c:165:26: note: length computed here 165 | size_t file_name_len = strlen(file_name); | ^~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors As per Arnaldo's suggestion use strlcpy(), which does the same thing and keeps gcc silent. Suggested-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ben Gainey <ben.gainey@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/20190531131321.GB1281@kravaSigned-off-by:
-
Miles Chen authored
[ Upstream commit 0c1f14ed ] This change makes CONFIG_ZONE_DMA32 defuly y and allows users to overwrite it only when CONFIG_EXPERT=y. For the SoCs that do not need CONFIG_ZONE_DMA32, this is the first step to manage all available memory by a single zone(normal zone) to reduce the overhead of multiple zones. The change also fixes a build error when CONFIG_NUMA=y and CONFIG_ZONE_DMA32=n. arch/arm64/mm/init.c:195:17: error: use of undeclared identifier 'ZONE_DMA32' max_zone_pfns[ZONE_DMA32] = PFN_DOWN(max_zone_dma_phys()); Change since v1: 1. only expose CONFIG_ZONE_DMA32 when CONFIG_EXPERT=y 2. remove redundant IS_ENABLED(CONFIG_ZONE_DMA32) Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Miles Chen <miles.chen@mediatek.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Abhishek Goel authored
[ Upstream commit 04507c0a ] To set frequency on specific cpus using cpupower, following syntax can be used : cpupower -c #i frequency-set -f #f -r While setting frequency using cpupower frequency-set command, if we use '-r' option, it is expected to set frequency for all cpus related to cpu #i. But it is observed to be missing the last cpu in related cpu list. This patch fixes the problem. Signed-off-by:
Abhishek Goel <huntbag@linux.vnet.ibm.com> Reviewed-by:
Thomas Renninger <trenn@suse.de> Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Weihang Li authored
[ Upstream commit 594a81b3 ] The hclge/hclgevf and hns3 module can be unloaded independently, when hclge/hclgevf unloaded firstly, the ops of ae_dev should be set to NULL, otherwise it will cause an use-after-free problem. Fixes: 38caee9d ("net: hns3: Add support of the HNAE3 framework") Signed-off-by:
Weihang Li <liweihang@hisilicon.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Kefeng Wang authored
[ Upstream commit 69fbb3f4 ] X-Originating-IP: [10.175.113.25] X-CFilter-Loop: Reflected The fm_v4l2_init_video_device() forget to unregister v4l2/video device in the error path, it could lead to UAF issue, eg, BUG: KASAN: use-after-free in atomic64_read include/asm-generic/atomic-instrumented.h:836 [inline] BUG: KASAN: use-after-free in atomic_long_read include/asm-generic/atomic-long.h:28 [inline] BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0x92/0x690 kernel/locking/mutex.c:1206 Read of size 8 at addr ffff8881e84a7c70 by task v4l_id/3659 CPU: 1 PID: 3659 Comm: v4l_id Not tainted 5.1.0 #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xa9/0x10e lib/dump_stack.c:113 print_address_description+0x65/0x270 mm/kasan/report.c:187 kasan_report+0x149/0x18d mm/kasan/report.c:317 atomic64_read include/asm-generic/atomic-instrumented.h:836 [inline] atomic_long_read include/asm-generic/atomic-long.h:28 [inline] __mutex_unlock_slowpath+0x92/0x690 kernel/locking/mutex.c:1206 fm_v4l2_fops_open+0xac/0x120 [fm_drv] v4l2_open+0x191/0x390 [videodev] chrdev_open+0x20d/0x570 fs/char_dev.c:417 do_dentry_open+0x700/0xf30 fs/open.c:777 do_last fs/namei.c:3416 [inline] path_openat+0x7c4/0x2a90 fs/namei.c:3532 do_filp_open+0x1a5/0x2b0 fs/namei.c:3563 do_sys_open+0x302/0x490 fs/open.c:1069 do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f8180c17c8e ... Allocated by task 3642: set_track mm/kasan/common.c:87 [inline] __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:497 fm_drv_init+0x13/0x1000 [fm_drv] do_one_initcall+0xbc/0x47d init/main.c:901 do_init_module+0x1b5/0x547 kernel/module.c:3456 load_module+0x6405/0x8c10 kernel/module.c:3804 __do_sys_finit_module+0x162/0x190 kernel/module.c:3898 do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 3642: set_track mm/kasan/common.c:87 [inline] __kasan_slab_free+0x130/0x180 mm/kasan/common.c:459 slab_free_hook mm/slub.c:1429 [inline] slab_free_freelist_hook mm/slub.c:1456 [inline] slab_free mm/slub.c:3003 [inline] kfree+0xe1/0x270 mm/slub.c:3958 fm_drv_init+0x1e6/0x1000 [fm_drv] do_one_initcall+0xbc/0x47d init/main.c:901 do_init_module+0x1b5/0x547 kernel/module.c:3456 load_module+0x6405/0x8c10 kernel/module.c:3804 __do_sys_finit_module+0x162/0x190 kernel/module.c:3898 do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Add relevant unregister functions to fix it. Cc: Hans Verkuil <hans.verkuil@cisco.com> Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Imre Deak authored
[ Upstream commit d9349850 ] The sequence static DEFINE_WW_CLASS(test_ww_class); struct ww_acquire_ctx ww_ctx; struct ww_mutex ww_lock_a; struct ww_mutex ww_lock_b; struct ww_mutex ww_lock_c; struct mutex lock_c; ww_acquire_init(&ww_ctx, &test_ww_class); ww_mutex_init(&ww_lock_a, &test_ww_class); ww_mutex_init(&ww_lock_b, &test_ww_class); ww_mutex_init(&ww_lock_c, &test_ww_class); mutex_init(&lock_c); ww_mutex_lock(&ww_lock_a, &ww_ctx); mutex_lock(&lock_c); ww_mutex_lock(&ww_lock_b, &ww_ctx); ww_mutex_lock(&ww_lock_c, &ww_ctx); mutex_unlock(&lock_c); (*) ww_mutex_unlock(&ww_lock_c); ww_mutex_unlock(&ww_lock_b); ww_mutex_unlock(&ww_lock_a); ww_acquire_fini(&ww_ctx); (**) will trigger the following error in __lock_release() when calling mutex_release() at **: DEBUG_LOCKS_WARN_ON(depth <= 0) The problem is that the hlock merging happening at * updates the references for test_ww_class incorrectly to 3 whereas it should've updated it to 4 (representing all the instances for ww_ctx and ww_lock_[abc]). Fix this by updating the references during merging correctly taking into account that we can have non-zero references (both for the hlock that we merge into another hlock or for the hlock we are merging into). Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Link: https://lkml.kernel.org/r/20190524201509.9199-2-imre.deak@intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Sven Eckelmann authored
[ Upstream commit 9e6b5648 ] The state of slave interfaces are handled differently depending on whether the interface is up or not. All active interfaces (IFF_UP) will transmit OGMs. But for B.A.T.M.A.N. IV, also non-active interfaces are scheduling (low TTL) OGMs on active interfaces. The code which setups and schedules the OGMs must therefore already be called when the interfaces gets added as slave interface and the transmit function must then check whether it has to send out the OGM or not on the specific slave interface. But the commit f0d97253 ("batman-adv: remove ogm_emit and ogm_schedule API calls") moved the setup code from the enable function to the activate function. The latter is called either when the added slave was already up when batadv_hardif_enable_interface processed the new interface or when a NETDEV_UP event was received for this slave interfac. As result, each NETDEV_UP would schedule a new OGM worker for the interface and thus OGMs would be send a lot more than expected. Fixes: f0d97253 ("batman-adv: remove ogm_emit and ogm_schedule API calls") Reported-by:
Linus Lüssing <linus.luessing@c0d3.blue> Tested-by:
Marek Lindner <mareklindner@neomailbox.ch> Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 621ccc6c ] Rename _P to _P_VAL and _R to _R_VAL to avoid global namespace conflicts: drivers/media/dvb-frontends/tua6100.c: In function ‘tua6100_set_params’: drivers/media/dvb-frontends/tua6100.c:79: warning: "_P" redefined #define _P 32 In file included from ./include/acpi/platform/aclinux.h:54, from ./include/acpi/platform/acenv.h:152, from ./include/acpi/acpi.h:22, from ./include/linux/acpi.h:34, from ./include/linux/i2c.h:17, from drivers/media/dvb-frontends/tua6100.h:30, from drivers/media/dvb-frontends/tua6100.c:32: ./include/linux/ctype.h:14: note: this is the location of the previous definition #define _P 0x10 /* punct */ Signed-off-by:
-
Christophe Leroy authored
[ Upstream commit c9cca703 ] The MPC885 reference manual states: SEC Lite-initiated 8xx writes can occur only on 32-bit-word boundaries, but reads can occur on any byte boundary. Writing back a header read from a non-32-bit-word boundary will yield unpredictable results. In order to ensure that, cra_alignmask is set to 3 for SEC1. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Fixes: 9c4a7965 ("crypto: talitos - Freescale integrated security engine (SEC) driver") Signed-off-by:
-
Christophe Leroy authored
[ Upstream commit eae55a58 ] The driver assumes that the ICV is as a single piece in the last element of the scatterlist. This assumption is wrong. This patch ensures that the ICV is properly handled regardless of the scatterlist layout. Fixes: 9c4a7965 ("crypto: talitos - Freescale integrated security engine (SEC) driver") Signed-off-by:
-
Ioana Ciornei authored
[ Upstream commit 82c76aca ] In general, we don't want MAC drivers calling phy_attach_direct with the net_device being NULL. Add checks against this in all the functions calling it: phy_attach() and phy_connect_direct(). Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Suggested-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Shailendra Verma authored
[ Upstream commit 6995a659 ] Fix to avoid possible memory leak if the decoder initialization got failed.Free the allocated memory for file handle object before return in case decoder initialization fails. Signed-off-by:
Shailendra Verma <shailendra.v@samsung.com> Signed-off-by:
-
Kefeng Wang authored
[ Upstream commit 50710eee ] if saa7164_proc_create() fails, saa7164_fini() will trigger a warning, name 'saa7164' WARNING: CPU: 1 PID: 6311 at fs/proc/generic.c:672 remove_proc_entry+0x1e8/0x3a0 ? remove_proc_entry+0x1e8/0x3a0 ? try_stop_module+0x7b/0x240 ? proc_readdir+0x70/0x70 ? rcu_read_lock_sched_held+0xd7/0x100 saa7164_fini+0x13/0x1f [saa7164] __x64_sys_delete_module+0x30c/0x480 ? __ia32_sys_delete_module+0x480/0x480 ? __x64_sys_clock_gettime+0x11e/0x1c0 ? __x64_sys_timer_create+0x1a0/0x1a0 ? trace_hardirqs_off_caller+0x40/0x180 ? do_syscall_64+0x18/0x450 do_syscall_64+0x9f/0x450 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fix it by checking the return of proc_create_single() before calling remove_proc_entry(). Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> [hverkuil-cisco@xs4all.nl: use 0444 instead of S_IRUGO] [hverkuil-cisco@xs4all.nl: use pr_info instead of KERN_INFO] Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit 518fa4e0 ] You can't memset the contents of a __user pointer. Instead, call copy_to_user to copy links.reserved (which is zeroed) to the user memory. This fixes this sparse warning: SPARSE:drivers/media/mc/mc-device.c drivers/media/mc/mc-device.c:521:16: warning: incorrect type in argument 1 (different address spaces) Fixes: f4930887 ("media: media_device_enum_links32: clean a reserved field") Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit da201963 ] Some compilers will complain when using a member of a struct to initialize another member, in the same struct initialization. For instance: debian:8 Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0) oraclelinux:7 clang version 3.4.2 (tags/RELEASE_34/dot2-final) Produce: ui/browsers/annotate.c:104:12: error: variable 'ops' is uninitialized when used within its own initialization [-Werror,-Wuninitialized] (!ops.current_entry || ^~~ 1 error generated. So use an extra variable, initialized just before that struct, to have the value used in the expressions used to init two of the struct members. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Fixes: c298304b ("perf annotate: Use a ops table for annotation_line__write()") Link: https://lkml.kernel.org/n/tip-f9nexro58q62l3o9hez8hr0i@git.kernel.orgSigned-off-by:
-
Eric Biggers authored
[ Upstream commit eeacfdc6 ] Replace some BUG_ON()s with WARN_ON_ONCE() and returning an error code, and move the check for len divisible by FS_CRYPTO_BLOCK_SIZE into fscrypt_crypt_block() so that it's done for both encryption and decryption, not just encryption. Reviewed-by:
Chandan Rajendra <chandan@linux.ibm.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Anirudh Gupta authored
[ Upstream commit b38ff407 ] Family of src/dst can be different from family of selector src/dst. Use xfrm selector family to validate address prefix length, while verifying new sa from userspace. Validated patch with this command: ip xfrm state add src 1.1.6.1 dst 1.1.6.2 proto esp spi 4260196 \ reqid 20004 mode tunnel aead "rfc4106(gcm(aes))" \ 0x1111016400000000000000000000000044440001 128 \ sel src 1011:1:4::2/128 sel dst 1021:1:4::2/128 dev Port5 Fixes: 07bf7908 ("xfrm: Validate address prefix lengths in the xfrm selector.") Signed-off-by:
Anirudh Gupta <anirudh.gupta@sophos.com> Acked-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Jeremy Sowden authored
[ Upstream commit 7c80eb1c ] In both functions, if pfkey_xfrm_policy2msg failed we leaked the newly allocated sk_buff. Free it on error. Fixes: 55569ce2 ("Fix conversion between IPSEC_MODE_xxx and XFRM_MODE_xxx.") Reported-by: syzbot+4f0529365f7f2208d9f0@syzkaller.appspotmail.com Signed-off-by:
Jeremy Sowden <jeremy@azazel.net> Signed-off-by:
-
Eric W. Biederman authored
[ Upstream commit f9070dc9 ] The locking in force_sig_info is not prepared to deal with a task that exits or execs (as sighand may change). The is not a locking problem in force_sig as force_sig is only built to handle synchronous exceptions. Further the function force_sig_info changes the signal state if the signal is ignored, or blocked or if SIGNAL_UNKILLABLE will prevent the delivery of the signal. The signal SIGKILL can not be ignored and can not be blocked and SIGNAL_UNKILLABLE won't prevent it from being delivered. So using force_sig rather than send_sig for SIGKILL is confusing and pointless. Because it won't impact the sending of the signal and and because using force_sig is wrong, replace force_sig with send_sig. Cc: Daniel Lezcano <daniel.lezcano@free.fr> Cc: Serge Hallyn <serge@hallyn.com> Cc: Oleg Nesterov <oleg@redhat.com> Fixes: cf3f8921 ("pidns: add reboot_pid_ns() to handle the reboot syscall") Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Michal Kalderon authored
[ Upstream commit 8366d520 ] In 100g mode the doorbell bar is united for both engines. Set the correct offset in the hwfn so that the doorbell returned for RoCE is in the affined hwfn. Signed-off-by:
Ariel Elior <ariel.elior@marvell.com> Signed-off-by:
Denis Bolotin <denis.bolotin@marvell.com> Signed-off-by:
Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by:
-
Jose Abreu authored
[ Upstream commit 0620ec6c ] In case we don't use a given address entry we need to clear it because it could contain previous values that are no longer valid. Found out while running stmmac selftests. Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Cc: Joao Pinto <jpinto@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by:
-
Jose Abreu authored
[ Upstream commit 9463c445 ] In case we don't use a given address entry we need to clear it because it could contain previous values that are no longer valid. Found out while running stmmac selftests. Signed-off-by:
-
Jungo Lin authored
[ Upstream commit f4930887 ] In v4l2-compliance utility, test MEDIA_IOC_ENUM_ENTITIES will check whether reserved field of media_links_enum filled with zero. However, for 32 bit program, the reserved field is missing copy from kernel space to user space in media_device_enum_links32 function. This patch adds the cleaning a reserved field logic in media_device_enum_links32 function. Signed-off-by:
Jungo Lin <jungo.lin@mediatek.com> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit e08f0761 ] In case ioremap fails, the fix returns -ENOMEM to avoid NULL pointer dereference. Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Acked-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
-
Lubomir Rintel authored
[ Upstream commit 0c7aa329 ] The commit d790b7ed ("[media] vb2-dma-sg: move dma_(un)map_sg here") left dma_desc_nent unset. It previously contained the number of DMA descriptors as returned from dma_map_sg(). We can now (since the commit referred to above) obtain the same value from the sg_table and drop dma_desc_nent altogether. Tested on OLPC XO-1.75 machine. Doesn't affect the OLPC XO-1's Cafe driver, since that one doesn't do DMA. [mchehab+samsung@kernel.org: fix a checkpatch warning] Fixes: d790b7ed ("[media] vb2-dma-sg: move dma_(un)map_sg here") Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
-
Akinobu Mita authored
[ Upstream commit 6e4ab830 ] If the requested framesize by VIDIOC_SUBDEV_S_FMT is larger than supported framesizes, it causes an out of bounds array access and the resulting framesize is unexpected. Avoid out of bounds array access and select the default framesize. Cc: Wenyou Yang <wenyou.yang@microchip.com> Cc: Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
-
Christophe Leroy authored
[ Upstream commit 3e03e792 ] Selftests report the following: [ 2.984845] alg: skcipher: cbc-aes-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place" [ 2.995377] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41 [ 3.032673] alg: skcipher: cbc-des-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place" [ 3.043185] 00000000: fe dc ba 98 76 54 32 10 [ 3.063238] alg: skcipher: cbc-3des-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place" [ 3.073818] 00000000: 7d 33 88 93 0f 93 b2 42 This above dumps show that the actual output IV is indeed the input IV. This is due to the IV not being copied back into the request. This patch fixes that. Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Daniel Gomez authored
[ Upstream commit 24e4cf77 ] MODULE_DEVICE_TABLE(of, <of_match_table> should be called to complete DT OF mathing mechanism and register it. Before this patch: modinfo drivers/media/rc/ir-spi.ko | grep alias After this patch: modinfo drivers/media/rc/ir-spi.ko | grep alias alias: of:N*T*Cir-spi-ledC* alias: of:N*T*Cir-spi-led Reported-by:
Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by:
Daniel Gomez <dagmcr@gmail.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Oliver Neukum authored
[ Upstream commit 6cf97230 ] dvb_usb_device_exit() frees and uses the device name in that order. Fix by storing the name in a buffer before freeing it. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Reported-by: syzbot+26ec41e9f788b3eba396@syzkaller.appspotmail.com Signed-off-by:
-
Jeremy Sowden authored
[ Upstream commit 17f78dd1 ] A handler for BATADV_TVLV_ROAM was being registered when the translation-table was initialized, but not unregistered when the translation-table was freed. Unregister it. Fixes: 122edaa0 ("batman-adv: tvlv - convert roaming adv packet to use tvlv unicast packets") Reported-by: syzbot+d454a826e670502484b8@syzkaller.appspotmail.com Signed-off-by:
-
Daniel Baluta authored
[ Upstream commit 2899872b ] As detected by kmemleak running on i.MX6ULL board: nreferenced object 0xd8366600 (size 64): comm "swapper/0", pid 1, jiffies 4294937370 (age 933.220s) hex dump (first 32 bytes): 64 75 6d 6d 79 2d 69 6f 6d 75 78 63 2d 67 70 72 dummy-iomuxc-gpr 40 32 30 65 34 30 30 30 00 e3 f3 ab fe d1 1b dd @20e4000........ backtrace: [<b0402aec>] kasprintf+0x2c/0x54 [<a6fbad2c>] regmap_debugfs_init+0x7c/0x31c [<9c8d91fa>] __regmap_init+0xb5c/0xcf4 [<5b1c3d2a>] of_syscon_register+0x164/0x2c4 [<596a5d80>] syscon_node_to_regmap+0x64/0x90 [<49bd597b>] imx6ul_init_machine+0x34/0xa0 [<250a4dac>] customize_machine+0x1c/0x30 [<2d19fdaf>] do_one_initcall+0x7c/0x398 [<e6084469>] kernel_init_freeable+0x328/0x448 [<168c9101>] kernel_init+0x8/0x114 [<913268aa>] ret_from_fork+0x14/0x20 [<ce7b131a>] 0x0 Root cause is that map->debugfs_name is allocated using kasprintf and then the pointer is lost by assigning it other memory address. Reported-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Anilkumar Kolli authored
[ Upstream commit d8792393 ] Increase pulse width range from 1-2usec to 0-4usec. During data traffic HW occasionally fails detecting radar pulses, so that SW cannot get enough radar reports to achieve the success rate. Tested ath10k hw and fw: * QCA9888(10.4-3.5.1-00052) * QCA4019(10.4-3.2.1.1-00017) * QCA9984(10.4-3.6-00104) * QCA988X(10.2.4-1.0-00041) Tested ath9k hw: AR9300 Tested-by:
Tamizh chelvam <tamizhr@codeaurora.org> Signed-off-by:
Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Maya Erez authored
[ Upstream commit e10b0edd ] Interrupt is set in ICM (ICR & ~IMV) rising trigger. As the driver masks the IRQ after clearing it, there can be a race where an additional spurious interrupt is triggered when the driver unmask the IRQ. This can happen in case HW triggers an interrupt after the clear and before the mask. To prevent the second spurious interrupt the driver needs to mask the IRQ before reading and clearing it. Signed-off-by:
Maya Erez <merez@codeaurora.org> Signed-off-by:
-
Wen Gong authored
[ Upstream commit 49ed34b8 ] For some SDIO chip, the peer id is 65535 for MPDU with error status, then test_bit will trigger buffer overflow for peer's memory, if kasan enabled, it will report error. Reason is when station is in disconnecting status, firmware do not delete the peer info since it not disconnected completely, meanwhile some AP will still send data packet to station, then hardware will receive the packet and send to firmware, firmware's logic will report peer id of 65535 for MPDU with error status. Add check for overflow the size of peer's peer_ids will avoid the buffer overflow access. Call trace of kasan: dump_backtrace+0x0/0x2ec show_stack+0x20/0x2c __dump_stack+0x20/0x28 dump_stack+0xc8/0xec print_address_description+0x74/0x240 kasan_report+0x250/0x26c __asan_report_load8_noabort+0x20/0x2c ath10k_peer_find_by_id+0x180/0x1e4 [ath10k_core] ath10k_htt_t2h_msg_handler+0x100c/0x2fd4 [ath10k_core] ath10k_htt_htc_t2h_msg_handler+0x20/0x34 [ath10k_core] ath10k_sdio_irq_handler+0xcc8/0x1678 [ath10k_sdio] process_sdio_pending_irqs+0xec/0x370 sdio_run_irqs+0x68/0xe4 sdio_irq_work+0x1c/0x28 process_one_work+0x3d8/0x8b0 worker_thread+0x508/0x7cc kthread+0x24c/0x264 ret_from_fork+0x10/0x18 Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1. Signed-off-by:
Wen Gong <wgong@codeaurora.org> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 5d6751ea ] The "ev->traffic_class" and "reply->ac" variables come from the network and they're used as an offset into the wmi->stream_exist_for_ac[] array. Those variables are u8 so they can be 0-255 but the stream_exist_for_ac[] array only has WMM_NUM_AC (4) elements. We need to add a couple bounds checks to prevent array overflows. I also modified one existing check from "if (traffic_class > 3) {" to "if (traffic_class >= WMM_NUM_AC) {" just to make them all consistent. Fixes: bdcd8170 (" Add ath6kl cleaned up driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
