- 10 8月, 2021 3 次提交
-
-
由 Aili Yao 提交于
mainline inclusion from mainline-v5.13 commit 47af12ba category: bugfix bugzilla: 175120 CVE: NA ------------------------------------------------- When memory_failure() is called with MF_ACTION_REQUIRED on the page that has already been hwpoisoned, memory_failure() could fail to send SIGBUS to the affected process, which results in infinite loop of MCEs. Currently memory_failure() returns 0 if it's called for already hwpoisoned page, then the caller, kill_me_maybe(), could return without sending SIGBUS to current process. An action required MCE is raised when the current process accesses to the broken memory, so no SIGBUS means that the current process continues to run and access to the error page again soon, so running into MCE loop. This issue can arise for example in the following scenarios: - Two or more threads access to the poisoned page concurrently. If local MCE is enabled, MCE handler independently handles the MCE events. So there's a race among MCE events, and the second or latter threads fall into the situation in question. - If there was a precedent memory error event and memory_failure() for the event failed to unmap the error page for some reason, the subsequent memory access to the error page triggers the MCE loop situation. To fix the issue, make memory_failure() return an error code when the error page has already been hwpoisoned. This allows memory error handler to control how it sends signals to userspace. And make sure that any process touching a hwpoisoned page should get a SIGBUS even in "already hwpoisoned" path of memory_failure() as is done in page fault path. Link: https://lkml.kernel.org/r/20210521030156.2612074-3-nao.horiguchi@gmail.comSigned-off-by: NAili Yao <yaoaili@kingsoft.com> Signed-off-by: NNaoya Horiguchi <naoya.horiguchi@nec.com> Reviewed-by: NOscar Salvador <osalvador@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Borislav Petkov <bp@suse.de> Cc: David Hildenbrand <david@redhat.com> Cc: Jue Wang <juew@google.com> Cc: Tony Luck <tony.luck@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NNanyong Sun <sunnanyong@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Tony Luck 提交于
mainline inclusion from mainline-v5.13 commit 171936dd category: bugfix bugzilla: 175120 CVE: NA ------------------------------------------------- Patch series "mm,hwpoison: fix sending SIGBUS for Action Required MCE", v5. I wrote this patchset to materialize what I think is the current allowable solution mentioned by the previous discussion [1]. I simply borrowed Tony's mutex patch and Aili's return code patch, then I queued another one to find error virtual address in the best effort manner. I know that this is not a perfect solution, but should work for some typical case. [1]: https://lore.kernel.org/linux-mm/20210331192540.2141052f@alex-virtual-machine/ This patch (of 2): There can be races when multiple CPUs consume poison from the same page. The first into memory_failure() atomically sets the HWPoison page flag and begins hunting for tasks that map this page. Eventually it invalidates those mappings and may send a SIGBUS to the affected tasks. But while all that work is going on, other CPUs see a "success" return code from memory_failure() and so they believe the error has been handled and continue executing. Fix by wrapping most of the internal parts of memory_failure() in a mutex. [akpm@linux-foundation.org: make mf_mutex local to memory_failure()] Link: https://lkml.kernel.org/r/20210521030156.2612074-1-nao.horiguchi@gmail.com Link: https://lkml.kernel.org/r/20210521030156.2612074-2-nao.horiguchi@gmail.comSigned-off-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NNaoya Horiguchi <naoya.horiguchi@nec.com> Reviewed-by: NBorislav Petkov <bp@suse.de> Reviewed-by: NOscar Salvador <osalvador@suse.de> Cc: Aili Yao <yaoaili@kingsoft.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: David Hildenbrand <david@redhat.com> Cc: Jue Wang <juew@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Conflicts: mm/memory-failure.c Signed-off-by: NNanyong Sun <sunnanyong@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Ard Biesheuvel 提交于
mainline inclusion from mainline-v5.11-rc1 commit 97d6786e category: bugfix bugzilla: 175103 CVE: NA ----------------------------------------------- As a hardening measure, we currently randomize the placement of physical memory inside the linear region when KASLR is in effect. Since the random offset at which to place the available physical memory inside the linear region is chosen early at boot, it is based on the memblock description of memory, which does not cover hotplug memory. The consequence of this is that the randomization offset may be chosen such that any hotplugged memory located above memblock_end_of_DRAM() that appears later is pushed off the end of the linear region, where it cannot be accessed. So let's limit this randomization of the linear region to ensure that this can no longer happen, by using the CPU's addressable PA range instead. As it is guaranteed that no hotpluggable memory will appear that falls outside of that range, we can safely put this PA range sized window anywhere in the linear region. Signed-off-by: NArd Biesheuvel <ardb@kernel.org> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Steven Price <steven.price@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20201014081857.3288-1-ardb@kernel.orgSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NPeng Liu <liupeng256@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 06 8月, 2021 11 次提交
-
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 175105 CVE: NA ------------------------------------------------- When !CONFIG_SYSCTL, drop_caches_loop_limit is invisible. Add cmdline "drop_caches_loop_limit=" to set it. This parameter can limit the number of loops per node. Fixes: c9b0870a ("mm/vmscan: add drop_caches_loop_limit to break loop in drop_slab_node") Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Shakeel Butt 提交于
mainline inclusion from mainline-v5.8-rc1 commit dd8657b6 category: bugfix CVE: NA -------------------------------- Currently reading memory.numa_stat traverses the underlying memcg tree multiple times to accumulate the stats to present the hierarchical view of the memcg tree. However the kernel already maintains the hierarchical view of the stats and use it in memory.stat. Just use the same mechanism in memory.numa_stat as well. I ran a simple benchmark which reads root_mem_cgroup's memory.numa_stat file in the presense of 10000 memcgs. The results are: Without the patch: $ time cat /dev/cgroup/memory/memory.numa_stat > /dev/null real 0m0.700s user 0m0.001s sys 0m0.697s With the patch: $ time cat /dev/cgroup/memory/memory.numa_stat > /dev/null real 0m0.001s user 0m0.001s sys 0m0.000s [akpm@linux-foundation.org: avoid forcing out-of-line code generation] Signed-off-by: NShakeel Butt <shakeelb@google.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Reviewed-by: NAndrew Morton <akpm@linux-foundation.org> Acked-by: NJohannes Weiner <hannes@cmpxchg.org> Cc: Roman Gushchin <guro@fb.com> Cc: Michal Hocko <mhocko@kernel.org> Link: http://lkml.kernel.org/r/20200304022058.248270-1-shakeelb@google.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Conflicts: mm/memcontrol.c Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Ye Weihua 提交于
hulk inclusion category: bugfix bugzilla: 175623 CVE: NA --------------------------- Livepatch allows users to call hook functions to perform some customized operations when insmod the .ko. During the test, it is found that in the ARM64 architecture, if accesses the global variables defined by other ko in hook functions, a crash occurs. Since relocation is performed during the livepatch insertion, instructions in the icache should be invalid. If the instructions in the icache are directly obtained, incorrect addresses may be obtained, caseing crash. Therefore, flush the icache before calling the hook functions. Signed-off-by: NYe Weihua <yeweihua4@huawei.com> Reviewed-by: NJian Cheng <cj.chengjian@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Eric Dumazet 提交于
mainline inclusion from mainline-v5.6 commit 90c01894 category: bugfix bugzilla: 93967 CVE: NA ----------------------------------------------- The timer_pending() function is mostly used in lockless contexts, so Without proper annotations, KCSAN might detect a data-race [1]. Using hlist_unhashed_lockless() instead of hand-coding it seems appropriate (as suggested by Paul E. McKenney). [1] BUG: KCSAN: data-race in del_timer / detach_if_pending write to 0xffff88808697d870 of 8 bytes by task 10 on cpu 0: __hlist_del include/linux/list.h:764 [inline] detach_timer kernel/time/timer.c:815 [inline] detach_if_pending+0xcd/0x2d0 kernel/time/timer.c:832 try_to_del_timer_sync+0x60/0xb0 kernel/time/timer.c:1226 del_timer_sync+0x6b/0xa0 kernel/time/timer.c:1365 schedule_timeout+0x2d2/0x6e0 kernel/time/timer.c:1896 rcu_gp_fqs_loop+0x37c/0x580 kernel/rcu/tree.c:1639 rcu_gp_kthread+0x143/0x230 kernel/rcu/tree.c:1799 kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352 read to 0xffff88808697d870 of 8 bytes by task 12060 on cpu 1: del_timer+0x3b/0xb0 kernel/time/timer.c:1198 sk_stop_timer+0x25/0x60 net/core/sock.c:2845 inet_csk_clear_xmit_timers+0x69/0xa0 net/ipv4/inet_connection_sock.c:523 tcp_clear_xmit_timers include/net/tcp.h:606 [inline] tcp_v4_destroy_sock+0xa3/0x3f0 net/ipv4/tcp_ipv4.c:2096 inet_csk_destroy_sock+0xf4/0x250 net/ipv4/inet_connection_sock.c:836 tcp_close+0x6f3/0x970 net/ipv4/tcp.c:2497 inet_release+0x86/0x100 net/ipv4/af_inet.c:427 __sock_release+0x85/0x160 net/socket.c:590 sock_close+0x24/0x30 net/socket.c:1268 __fput+0x1e1/0x520 fs/file_table.c:280 ____fput+0x1f/0x30 fs/file_table.c:313 task_work_run+0xf6/0x130 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x2b4/0x2c0 arch/x86/entry/common.c:163 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 12060 Comm: syz-executor.5 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, Signed-off-by: NEric Dumazet <edumazet@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> [ paulmck: Pulled in Eric's later amendments. ] Signed-off-by: NPaul E. McKenney <paulmck@kernel.org> Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Eric Dumazet 提交于
mainline inclusion from mainline-v5.6 commit c54a2744 category: bugfix bugzilla: 93967 CVE: NA ----------------------------------------------- We would like to use hlist_unhashed() from timer_pending(), which runs without protection of a lock. Note that other callers might also want to use this variant. Instead of forcing a READ_ONCE() for all hlist_unhashed() callers, add a new helper with an explicit _lockless suffix in the name to better document what is going on. Also add various WRITE_ONCE() in __hlist_del(), hlist_add_head() and hlist_add_before()/hlist_add_behind() to pair with the READ_ONCE(). Signed-off-by: NEric Dumazet <edumazet@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> [ paulmck: Also add WRITE_ONCE() to rculist.h. ] Signed-off-by: NPaul E. McKenney <paulmck@kernel.org> Conflicts: include/linux/list.h [wangxiongfeng: include patch commit ae325dcd ("list: Don't use WRITE_ONCE() in hlist_add_behind()")] Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yang Yingliang 提交于
hulk inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------- Enable CONFIG_GPIO_HISI by default. Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NJian Cheng <cj.chengjian@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Luo Jiaxing 提交于
mainline inclusion from mainline-v5.11-rc1 commit: 356b01a9 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I42E7W CVE: NA --------------------------- This GPIO driver is for HiSilicon's ARM SoC. HiSilicon's GPIO controller support double-edge interrupt and multi-core concurrent access. ACPI table example for this GPIO controller: Device (GPO0) { Name (_HID, "HiSiliconISI0184") Device (PRTA) enter{ Name (_ADR, Zero) Name (_UID, Zero) Name (_DSD, Package (0x01)your { Package (0x02) { "ngpios", 0x20 } }) } } Signed-off-by: NLuo Jiaxing <luojiaxing@huawei.com> Link: https://lore.kernel.org/r/1607934255-52544-2-git-send-email-luojiaxing@huawei.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org> Conflicts: drivers/gpio/Makefile Signed-off-by:
Jiaran Zhang <zhangjiaran@huawei.com>
Reviewed-by: Sheng Feng < fengsheng5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> -
由 Yang Yingliang 提交于
hulk inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------- Enable CONFIG_I2C_HISI by default. Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NJian Cheng <cj.chengjian@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yicong Yang 提交于
mainline inclusion from mainline-v5.13-rc1 commit d62fbdb9 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I42E7E CVE: NA --------------------------- Add HiSilicon I2C controller driver for the Kunpeng SoC. It provides the access to the i2c busses, which connects to the eeprom, rtc, etc. The driver works with IRQ mode, and supports basic I2C features and 10bit address. The DMA is not supported. Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NDmitry Osipenko <digetx@gmail.com> Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Signed-off-by: NWolfram Sang <wsa@kernel.org> Conflicts: MAINTAINERS Signed-off-by:
Jiaran Zhang <zhangjiaran@huawei.com>
Reviewed-by: Sheng Feng < fengsheng5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> -
由 Yicong Yang 提交于
mainline inclusion from mainline-v5.13-rc1 commit 3b4c747c category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I42E7E CVE: NA --------------------------- Some I2C drivers like Designware and HiSilicon will print the bus frequency mode information, so add a public one that everyone can make use of. Add the definition of the I2C Frequency Modes macro. Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Signed-off-by: NWolfram Sang <wsa@kernel.org> Signed-off-by:
Jiaran Zhang <zhangjiaran@huawei.com>
Reviewed-by: Sheng Feng < fengsheng5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> -
由 Yicong Yang 提交于
mainline inclusion from mainline-v5.13-rc1 commit 07740c92 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I42E7E CVE: NA --------------------------- Some I2C controller drivers will only unregister the I2C adapter in their .remove() callback, which can be done by simply using a managed variant to add the I2C adapter. So add the managed functions for adding the I2C adapter. Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NDmitry Osipenko <digetx@gmail.com> Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Signed-off-by: NWolfram Sang <wsa@kernel.org> Conflicts: drivers/i2c/i2c-core-base.c include/linux/i2c.h Signed-off-by:
Jiaran Zhang <zhangjiaran@huawei.com>
Reviewed-by: Sheng Feng < fengsheng5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 05 8月, 2021 26 次提交
-
-
由 Hou Tao 提交于
hulk inclusion category: bugfix bugzilla: 55097 CVE: NA ------------------------------------------------- Now there no protection between partition operations (e.g, partition rescan) and delete_partition() in del_gendisk(), so the following scenario is possible: CPU 1 blkdev_ioctl del_gendisk blkdev_reread_part lock bd_mutex drop_partitions check_partition lock lookup_sem // for each partition deletion_partion // for each partition add_partition The newly added partitions, the device files (e.g, /dev/sdXN) and the symlinks in /sys/class/block will be left behind. If the deleted disk is online again, the scan of partition will fail with the following error: sysfs: cannot create duplicate filename '/class/block/sdaN' sdX: pN could not be added: 17 Vanilla kernel tries to fix that by commit c76f48eb ("block: take bd_mutex around delete_partitions in del_gendisk"), but it introduces dead-lock for nbd/loop/xen-frontblk drivers. These in-tree drivers can be fixed, but there may be other affected block drivers, especially the out-of-tree ones, so fixing it in another way. Two methods are considered. The first is waiting for the end of partition operations in del_gendisk(). It is OK but it needs adding new fields in gendisk (bool & wait_queue_head_t). The second is reusing lookup_sem and GENHD_FL_UP to serialize partition operations and del_gendisk(). Now the latter is chose and here are the details. There are six partition operations: (1) add_partition() in blkpg_ioctl() (2) deletion_partion() in blkpg_ioctl() (3) resize in blkpg_ioctl() (4) partition rescan in __blkdev_reread_part() (5) partition revalidate in bdev_disk_changed() (6) deletion_partion() in del_gendisk() op (1)~(5) already take bd_mutex, so using down_read() to serialize with down_write() in del_gendisk() is OK. op (3) only updates the values in hd_struct, so no lock is needed, because it already increase the ref of hd_struct. lookup_sem is used to prevent a newly-created blocking device inode from associating with a deleting gendisk, and the locking order is: part->bd_mutex -> disk->lookup_sem or whole->bd_mutex -> disk->lookup_sem Now it is also used to serialize the partition operations and the new locking order will be: part->bd_mutex -> whole->bd_mutex -> disk->lookup_sem and it is OK. Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> -
由 Hou Tao 提交于
hulk inclusion category: bugfix bugzilla: 55097 CVE: NA ------------------------------------------------- This reverts commit 10097449. The patch set for partition symlink cleanup will introduce deadlock for nbd, loop and xen-blkfront driver, so revert it. Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: bugfix bugzilla: 55097 CVE: NA ------------------------------------------------- This reverts commit 375e23ab. The patch set for partition symlink cleanup will introduce deadlock for nbd, loop and xen-blkfront driver, so revert it. Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: bugfix bugzilla: 55097 CVE: NA ------------------------------------------------- This reverts commit d6dd218d. The patch set for partition symlink cleanup will introduce deadlock for nbd, loop and xen-blkfront driver, so revert it. Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Greg Kroah-Hartman 提交于
stable inclusion from linux-4.19.201 commit 6ca2f514c57864e3085a65c5e9d2adca4144bc4c -------------------------------- Merge 30 patches from 4.19.201 stable branch (31 total) beside 1 already merged patches: 96faa82a5ddb2 can: raw: raw_setsockopt(): fix raw_rcv panic for sock UAF Link: https://lore.kernel.org/r/20210802134334.081433902@linuxfoundation.orgTested-by: NPavel Machek (CIP) <pavel@denx.de> Tested-by: NLinux Kernel Functional Testing <lkft@linaro.org> Tested-by: NSudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by: NJon Hunter <jonathanh@nvidia.com> Tested-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Lukasz Cieplicki 提交于
stable inclusion from linux-4.19.201 commit fbb04f7cf9cfaee7d8300c614a06adb813846a74 -------------------------------- commit dc614c46 upstream. In case of PHY type error occurs, the message was too generic. Add additional info to PHY type error indicating that it can be wrong cable connected. Fixes: 124ed15b ("i40e: Add dual speed module support") Signed-off-by: NLukasz Cieplicki <lukaszx.cieplicki@intel.com> Signed-off-by: NMichal Maloszewski <michal.maloszewski@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Arnaldo Carvalho de Melo 提交于
stable inclusion from linux-4.19.201 commit 265c33f7417646cf6a48327e2fdabf49d3262cd3 -------------------------------- commit 9bac1bd6 upstream. This makes 'perf top' abort in some cases, and the right fix will involve surgery that is too much to do at this stage, so revert for now and fix it in the next merge window. This reverts commit 2d6b74ba. Cc: Riccardo Mancini <rickyman7@gmail.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Krister Johansen <kjlx@templeofstupid.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Srikar Dronamraju 提交于
stable inclusion from linux-4.19.201 commit 91bbeacf5a4c78176042aca62708b6bb5ab68a37 -------------------------------- commit 333cf507 upstream. With commit c9f34013 ("powerpc: Always enable queued spinlocks for 64s, disable for others") CONFIG_PPC_QUEUED_SPINLOCKS is always enabled on ppc64le, external modules that use spinlock APIs are failing. ERROR: modpost: GPL-incompatible module XXX.ko uses GPL-only symbol 'shared_processor' Before the above commit, modules were able to build without any issues. Also this problem is not seen on other architectures. This problem can be workaround if CONFIG_UNINLINE_SPIN_UNLOCK is enabled in the config. However CONFIG_UNINLINE_SPIN_UNLOCK is not enabled by default and only enabled in certain conditions like CONFIG_DEBUG_SPINLOCKS is set in the kernel config. #include <linux/module.h> spinlock_t spLock; static int __init spinlock_test_init(void) { spin_lock_init(&spLock); spin_lock(&spLock); spin_unlock(&spLock); return 0; } static void __exit spinlock_test_exit(void) { printk("spinlock_test unloaded\n"); } module_init(spinlock_test_init); module_exit(spinlock_test_exit); MODULE_DESCRIPTION ("spinlock_test"); MODULE_LICENSE ("non-GPL"); MODULE_AUTHOR ("Srikar Dronamraju"); Given that spin locks are one of the basic facilities for module code, this effectively makes it impossible to build/load almost any non GPL modules on ppc64le. This was first reported at https://github.com/openzfs/zfs/issues/11172 Currently shared_processor is exported as GPL only symbol. Fix this for parity with other architectures by exposing shared_processor to non-GPL modules too. Fixes: 14c73bd3 ("powerpc/vcpu: Assume dedicated processors as non-preempt") Cc: stable@vger.kernel.org # v5.5+ Reported-by: marc.c.dionne@gmail.com Signed-off-by: NSrikar Dronamraju <srikar@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210729060449.292780-1-srikar@linux.vnet.ibm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Dan Carpenter 提交于
stable inclusion from linux-4.19.201 commit 5a6c550c2f0e49492a906ebd08d8af9b455c4fa9 -------------------------------- [ Upstream commit f6b3c784 ] The hi3110_cmd() is supposed to return zero on success and negative error codes on failure, but it was accidentally declared as a u8 when it needs to be an int type. Fixes: 57e83fb9 ("can: hi311x: Add Holt HI-311x CAN driver") Link: https://lore.kernel.org/r/20210729141246.GA1267@kiliSigned-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Wang Hai 提交于
stable inclusion from linux-4.19.201 commit 6bee38856647fa679bf08966be7f0c84a3db9994 -------------------------------- [ Upstream commit 89fb62fd ] Replace pci_enable_device() with pcim_enable_device(), pci_disable_device() and pci_release_regions() will be called in release automatically. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by: NHulk Robot <hulkci@huawei.com> Signed-off-by: NWang Hai <wanghai38@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Wang Hai 提交于
stable inclusion from linux-4.19.201 commit fdb90238e5f54868e9c4a176d2b11e6f2105d23c -------------------------------- [ Upstream commit 76a16be0 ] Replace pci_enable_device() with pcim_enable_device(), pci_disable_device() and pci_release_regions() will be called in release automatically. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by: NHulk Robot <hulkci@huawei.com> Signed-off-by: NWang Hai <wanghai38@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Marcelo Ricardo Leitner 提交于
stable inclusion from linux-4.19.201 commit d9b6f0a200bef5fb9ba00e4e7d0d51f0b0fa5c6f -------------------------------- [ Upstream commit 557fb586 ] As Ben Hutchings noticed, this check should have been inverted: the call returns true in case of success. Reported-by: NBen Hutchings <ben@decadent.org.uk> Fixes: 0c5dc070 ("sctp: validate from_addr_param return") Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com> Reviewed-by: NXin Long <lucien.xin@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Maor Gottlieb 提交于
stable inclusion from linux-4.19.201 commit 2a7b6a5203b6f80c35fcd66c995201cb54f4178f -------------------------------- [ Upstream commit 8b54874e ] Fix a bug when flow table is created in priority that already has other flow tables as shown in the below diagram. If the new flow table (FT-B) has the lowest level in the priority, we need to connect the flow tables from the previous priority (p0) to this new table. In addition when this flow table is destroyed (FT-B), we need to connect the flow tables from the previous priority (p0) to the next level flow table (FT-C) in the same priority of the destroyed table (if exists). --------- |root_ns| --------- | -------------------------------- | | | ---------- ---------- --------- |p(prio)-x| | p-y | | p-n | ---------- ---------- --------- | | ---------------- ------------------ |ns(e.g bypass)| |ns(e.g. kernel) | ---------------- ------------------ | | | ------- ------ ---- | p0 | | p1 | |p2| ------- ------ ---- | | \ -------- ------- ------ | FT-A | |FT-B | |FT-C| -------- ------- ------ Fixes: f90edfd2 ("net/mlx5_core: Connect flow tables") Signed-off-by: NMaor Gottlieb <maorg@nvidia.com> Reviewed-by: NMark Bloch <mbloch@nvidia.com> Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Pavel Skripkin 提交于
stable inclusion from linux-4.19.201 commit 9a27cd7f98627ac5166022572f6955da4af4091d -------------------------------- [ Upstream commit c7c9d210 ] Syzbot reported skb_over_panic() in llc_pdu_init_as_xid_cmd(). The problem was in wrong LCC header manipulations. Syzbot's reproducer tries to send XID packet. llc_ui_sendmsg() is doing following steps: 1. skb allocation with size = len + header size len is passed from userpace and header size is 3 since addr->sllc_xid is set. 2. skb_reserve() for header_len = 3 3. filling all other space with memcpy_from_msg() Ok, at this moment we have fully loaded skb, only headers needs to be filled. Then code comes to llc_sap_action_send_xid_c(). This function pushes 3 bytes for LLC PDU header and initializes it. Then comes llc_pdu_init_as_xid_cmd(). It initalizes next 3 bytes *AFTER* LLC PDU header and call skb_push(skb, 3). This looks wrong for 2 reasons: 1. Bytes rigth after LLC header are user data, so this function was overwriting payload. 2. skb_push(skb, 3) call can cause skb_over_panic() since all free space was filled in llc_ui_sendmsg(). (This can happen is user passed 686 len: 686 + 14 (eth header) + 3 (LLC header) = 703. SKB_DATA_ALIGN(703) = 704) So, in this patch I added 2 new private constansts: LLC_PDU_TYPE_U_XID and LLC_PDU_LEN_U_XID. LLC_PDU_LEN_U_XID is used to correctly reserve header size to handle LLC + XID case. LLC_PDU_TYPE_U_XID is used by llc_pdu_header_init() function to push 6 bytes instead of 3. And finally I removed skb_push() call from llc_pdu_init_as_xid_cmd(). This changes should not affect other parts of LLC, since after all steps we just transmit buffer. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-and-tested-by: syzbot+5e5a981ad7cc54c4b2b4@syzkaller.appspotmail.com Signed-off-by: NPavel Skripkin <paskripkin@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Jiapeng Chong 提交于
stable inclusion from linux-4.19.201 commit 6f243cef30e4439122da672f6b845c1a9349da8d -------------------------------- [ Upstream commit 7e4960b3 ] The error code is missing in this code scenario, add the error code '-EINVAL' to the return value 'err'. Eliminate the follow smatch warning: drivers/net/ethernet/mellanox/mlx4/main.c:3538 mlx4_load_one() warn: missing error code 'err'. Reported-by: NAbaci Robot <abaci@linux.alibaba.com> Fixes: 7ae0e400 ("net/mlx4_core: Flexible (asymmetric) allocation of EQs and MSI-X vectors for PF/VFs") Signed-off-by: NJiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by: NTariq Toukan <tariqt@nvidia.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hoang Le 提交于
stable inclusion from linux-4.19.201 commit 01f178e5f855d38da00f87e9ba51764757e9cee4 -------------------------------- [ Upstream commit d237a7f1 ] The release_sock() is blocking function, it would change the state after sleeping. In order to evaluate the stated condition outside the socket lock context, switch to use wait_woken() instead. Fixes: 6398e23c ("tipc: standardize accept routine") Acked-by: NJon Maloy <jmaloy@redhat.com> Signed-off-by: NHoang Le <hoang.h.le@dektech.com.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Jedrzej Jagielski 提交于
stable inclusion from linux-4.19.201 commit 498d7ab105ed4e853065ddc64b2da11e971c0dc0 -------------------------------- [ Upstream commit ea52faae ] Fix missing failed message if driver does not have enough queues to complete TC command. Without this fix no message is displayed in dmesg. Fixes: a9ce82f7 ("i40e: Enable 'channel' mode in mqprio for TC configs") Signed-off-by: NGrzegorz Szczurek <grzegorzx.szczurek@intel.com> Signed-off-by: NJedrzej Jagielski <jedrzej.jagielski@intel.com> Tested-by: NImam Hassan Reza Biswas <imam.hassan.reza.biswas@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Arkadiusz Kubalewski 提交于
stable inclusion from linux-4.19.201 commit 6d51a5fb5b864b137cf1135abb526fff5afdce21 -------------------------------- [ Upstream commit 65662a8d ] Correct the message flow between driver and firmware when disabling queues. Previously in case of PF reset (due to required reinit after reconfig), the error like: "VSI seid 397 Tx ring 60 disable timeout" could show up occasionally. The error was not a real issue of hardware or firmware, it was caused by wrong sequence of messages invoked by the driver. Fixes: 41c445ff ("i40e: main driver core") Signed-off-by: NAleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: NArkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Pablo Neira Ayuso 提交于
stable inclusion from linux-4.19.201 commit 1cb5995a39eb3dc97a7539d00d2c82be030e0bb8 -------------------------------- [ Upstream commit a33f387e ] nft_nat reports a bogus EAFNOSUPPORT if no layer 3 information is specified. Fixes: d07db988 ("netfilter: nf_tables: introduce nft_validate_register_load()") Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Florian Westphal 提交于
stable inclusion from linux-4.19.201 commit 512fd52e2091560de66da26799b3f1ca7ca1d41b -------------------------------- [ Upstream commit 30a56a2b ] In case the entry is evicted via garbage collection there is delay between the timeout value and the eviction event. This adjusts the stop value based on how much time has passed. Fixes: b87a2f91 ("netfilter: conntrack: add gc worker to remove timed-out entries") Signed-off-by: NFlorian Westphal <fw@strlen.de> Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Nguyen Dinh Phi 提交于
stable inclusion from linux-4.19.201 commit 672f6ea510391a85dfce3362ad5d832bce447c14 -------------------------------- commit f9a5c358 upstream. When we exceed the limit of BSS entries, this function will free the new entry, however, at this time, it is the last door to access the inputed ies, so these ies will be unreferenced objects and cause memory leak. Therefore we should free its ies before deallocating the new entry, beside of dropping it from hidden_list. Signed-off-by: NNguyen Dinh Phi <phind.uet@gmail.com> Link: https://lore.kernel.org/r/20210628132334.851095-1-phind.uet@gmail.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Krzysztof Kozlowski 提交于
stable inclusion from linux-4.19.201 commit 0bf3eb2e85f6bfd66b954c5bbcd3330ce64b7ad8 -------------------------------- commit 5e7b30d2 upstream. There is a use after free memory corruption during module exit: - nfcsim_exit() - nfcsim_device_free(dev0) - nfc_digital_unregister_device() This iterates over command queue and frees all commands, - dev->up = false - nfcsim_link_shutdown() - nfcsim_link_recv_wake() This wakes the sleeping thread nfcsim_link_recv_skb(). - nfcsim_link_recv_skb() Wake from wait_event_interruptible_timeout(), call directly the deb->cb callback even though (dev->up == false), - digital_send_cmd_complete() Dereference of "struct digital_cmd" cmd which was freed earlier by nfc_digital_unregister_device(). This causes memory corruption shortly after (with unrelated stack trace): nfc nfc0: NFC: nfcsim_recv_wq: Device is down llcp: nfc_llcp_recv: err -19 nfc nfc1: NFC: nfcsim_recv_wq: Device is down BUG: unable to handle page fault for address: ffffffffffffffed Call Trace: fsnotify+0x54b/0x5c0 __fsnotify_parent+0x1fe/0x300 ? vfs_write+0x27c/0x390 vfs_write+0x27c/0x390 ksys_write+0x63/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae KASAN report: BUG: KASAN: use-after-free in digital_send_cmd_complete+0x16/0x50 Write of size 8 at addr ffff88800a05f720 by task kworker/0:2/71 Workqueue: events nfcsim_recv_wq [nfcsim] Call Trace: dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x21/0x140 ? digital_send_cmd_complete+0x16/0x50 ? digital_send_cmd_complete+0x16/0x50 kasan_report.cold+0x7f/0x11b ? digital_send_cmd_complete+0x16/0x50 ? digital_dep_link_down+0x60/0x60 digital_send_cmd_complete+0x16/0x50 nfcsim_recv_wq+0x38f/0x3d5 [nfcsim] ? nfcsim_in_send_cmd+0x4a/0x4a [nfcsim] ? lock_is_held_type+0x98/0x110 ? finish_wait+0x110/0x110 ? rcu_read_lock_sched_held+0x9c/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x12e/0x1f0 This flow of calling digital_send_cmd_complete() callback on driver exit is specific to nfcsim which implements reading and sending work queues. Since the NFC digital device was unregistered, the callback should not be called. Fixes: 204bddcb ("NFC: nfcsim: Make use of the Digital layer") Cc: <stable@vger.kernel.org> Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Paul Jakma 提交于
stable inclusion from linux-4.19.201 commit 4cd2534cbf6f5986682c12f4a6881fb2fe065e50 -------------------------------- commit 15bbf8bb upstream. Commit 7930742d, reverting 26fd962b, missed out on reverting an incorrect change to a return value. The niu_pci_vpd_scan_props(..) == 1 case appears to be a normal path - treating it as an error and return -EINVAL was breaking VPD_SCAN and causing the driver to fail to load. Fix, so my Neptune card works again. Cc: Kangjie Lu <kjlu@umn.edu> Cc: Shannon Nelson <shannon.lee.nelson@gmail.com> Cc: David S. Miller <davem@davemloft.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable <stable@vger.kernel.org> Fixes: 7930742d ('Revert "niu: fix missing checks of niu_pci_eeprom_read"') Signed-off-by: NPaul Jakma <paul@jakma.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Pavel Skripkin 提交于
stable inclusion from linux-4.19.201 commit 9c9e45112c2331d1a873fba92678b497977fb1e5 -------------------------------- commit 928150fa upstream. In esd_usb2_setup_rx_urbs() MAX_RX_URBS coherent buffers are allocated and there is nothing, that frees them: 1) In callback function the urb is resubmitted and that's all 2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER is not set (see esd_usb2_setup_rx_urbs) and this flag cannot be used with coherent buffers. So, all allocated buffers should be freed with usb_free_coherent() explicitly. Side note: This code looks like a copy-paste of other can drivers. The same patch was applied to mcba_usb driver and it works nice with real hardware. There is no change in functionality, only clean-up code for coherent buffers. Fixes: 96d8e903 ("can: Add driver for esd CAN-USB/2 device") Link: https://lore.kernel.org/r/b31b096926dcb35998ad0271aac4b51770ca7cc8.1627404470.git.paskripkin@gmail.com Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: NPavel Skripkin <paskripkin@gmail.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Pavel Skripkin 提交于
stable inclusion from linux-4.19.201 commit 71758cd0f1b09e8cd7c22059301018ffb0696778 -------------------------------- commit 9969e3c5 upstream. In ems_usb_start() MAX_RX_URBS coherent buffers are allocated and there is nothing, that frees them: 1) In callback function the urb is resubmitted and that's all 2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER is not set (see ems_usb_start) and this flag cannot be used with coherent buffers. So, all allocated buffers should be freed with usb_free_coherent() explicitly. Side note: This code looks like a copy-paste of other can drivers. The same patch was applied to mcba_usb driver and it works nice with real hardware. There is no change in functionality, only clean-up code for coherent buffers. Fixes: 702171ad ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Link: https://lore.kernel.org/r/59aa9fbc9a8cbf9af2bbd2f61a659c480b415800.1627404470.git.paskripkin@gmail.com Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: NPavel Skripkin <paskripkin@gmail.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Pavel Skripkin 提交于
stable inclusion from linux-4.19.201 commit 6c9d61989af94ac67fb0120a7e61a622f6da8068 -------------------------------- commit 0e865f0c upstream. In usb_8dev_start() MAX_RX_URBS coherent buffers are allocated and there is nothing, that frees them: 1) In callback function the urb is resubmitted and that's all 2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER is not set (see usb_8dev_start) and this flag cannot be used with coherent buffers. So, all allocated buffers should be freed with usb_free_coherent() explicitly. Side note: This code looks like a copy-paste of other can drivers. The same patch was applied to mcba_usb driver and it works nice with real hardware. There is no change in functionality, only clean-up code for coherent buffers. Fixes: 0024d8ad ("can: usb_8dev: Add support for USB2CAN interface from 8 devices") Link: https://lore.kernel.org/r/d39b458cd425a1cf7f512f340224e6e9563b07bd.1627404470.git.paskripkin@gmail.com Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: NPavel Skripkin <paskripkin@gmail.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-