[pull] master from torvalds:master #170
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
cougar_id_table[] is not changed and can be made const to allow the compiler to put it in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
macally_id_table is not modified and can be made const to allow the compiler to put it in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Before this commit i2c_hid_parse() consists of the following steps: 1. Send power on cmd 2. usleep_range(1000, 5000) 3. Send reset cmd 4. Wait for reset to complete (device interrupt, or msleep(100)) 5. Send power on cmd 6. Try to read HID descriptor Notice how there is an usleep_range(1000, 5000) after the first power-on command, but not after the second power-on command. Testing has shown that at least on the BMAX Y13 laptop's i2c-hid touchpad, not having a delay after the second power-on command causes the HID descriptor to read as all zeros. In case we hit this on other devices too, the descriptor being all zeros can be recognized by the following message being logged many, many times: hid-generic 0018:0911:5288.0002: unknown main item tag 0x0 At the same time as the BMAX Y13's touchpad issue was debugged, Kai-Heng was working on debugging some issues with Goodix i2c-hid touchpads. It turns out that these need a delay after a PWR_ON command too, otherwise they stop working after a suspend/resume cycle. According to Goodix a delay of minimal 60ms is needed. Having multiple cases where we need a delay after sending the power-on command, seems to indicate that we should always sleep after the power-on command. This commit fixes the mentioned issues by moving the existing 1ms sleep to the i2c_hid_set_power() function and changing it to a 60ms sleep. Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208247 Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reported-and-tested-by: Andrea Borgia <andrea@borgia.bo.it> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The PixArt OEM mice are known for disconnecting every minute in runlevel 1 or 3 if they are not always polled. One Lenovo PixArt mouse is already fixed. Got two references for 17ef:602e and three references for 17ef:6019 misbehaving like this. Got one direct bug report for 17ef:6093 from Wyatt Ward (wyatt8740). So add HID_QUIRK_ALWAYS_POLL for all of them. Link: https://github.com/sriemer/fix-linux-mouse issue 22 Signed-off-by: Sebastian Parschauer <s.parschauer@gmx.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
`uref->usage_index` is not always being properly checked, causing hiddev_ioctl_usage() to go out of bounds under some cases. Fix it. Reported-by: syzbot+34ee1b45d88571c2fa8b@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=f2aebe90b8c56806b050a20b36f51ed6acabe802 Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Because the last member of the "nvdimm_firmware_attributes" array was not assigned a null ptr, when traversal of "grp->attrs" array is out of bounds in "create_files" func. func: create_files: ->for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) ->.... BUG: KASAN: global-out-of-bounds in create_files fs/sysfs/group.c:43 [inline] BUG: KASAN: global-out-of-bounds in internal_create_group+0x9d8/0xb20 fs/sysfs/group.c:149 Read of size 8 at addr ffffffff8a2e4cf0 by task kworker/u17:10/959 CPU: 2 PID: 959 Comm: kworker/u17:10 Not tainted 5.8.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Workqueue: events_unbound async_run_entry_fn Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x497 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 create_files fs/sysfs/group.c:43 [inline] internal_create_group+0x9d8/0xb20 fs/sysfs/group.c:149 internal_create_groups.part.0+0x90/0x140 fs/sysfs/group.c:189 internal_create_groups fs/sysfs/group.c:185 [inline] sysfs_create_groups+0x25/0x50 fs/sysfs/group.c:215 device_add_groups drivers/base/core.c:2024 [inline] device_add_attrs drivers/base/core.c:2178 [inline] device_add+0x7fd/0x1c40 drivers/base/core.c:2881 nd_async_device_register+0x12/0x80 drivers/nvdimm/bus.c:506 async_run_entry_fn+0x121/0x530 kernel/async.c:123 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x3b5/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 The buggy address belongs to the variable: nvdimm_firmware_attributes+0x10/0x40 Link: https://lore.kernel.org/r/20200812085501.30963-1-qiang.zhang@windriver.com Link: https://lore.kernel.org/r/20200814150509.225615-1-vaibhav@linux.ibm.com Fixes: 48001ea ("PM, libnvdimm: Add runtime firmware activation support") Reported-by: syzbot+1cf0ffe61aecf46f588f@syzkaller.appspotmail.com Reported-by: Sandipan Das <sandipan@linux.ibm.com> Reported-by: Vaibhav Jain <vaibhav@linux.ibm.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Zqiang <qiang.zhang@windriver.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
This reverts commit d313279. This patch causes a regression with quite a few devices, as probing fails because of the race where the first IRQ is dropped on the floor (after hid_device_io_start() happens, but before the 50ms timeout passess), and report descriptor never gets parsed and populated. As this is just a boot time micro-optimization, let's revert the patch for 5.9 now, and fix this properly eventually for next merge window. Link: https://bugzilla.kernel.org/show_bug.cgi?id=208935 Reported-by: Johannes Hirte <johannes.hirte@datenkhaos.de> Reported-by: Marius Zachmann <mail@mariuszachmann.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 2316097 ("dax: print error message by pr_info() in __generic_fsdax_supported()") happens to print the following error message during booting when the non-persistent memory block devices are configured by device mapper. Those error messages are caused by the variable 'dax_dev' is NULL. Users might be confused with those error messages since they do not use the persistent memory device. Moreover, users might scare about "what's wrong with my disks" because they see the 'error' and 'failed' keywords. # dmesg | grep fail sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdk3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) sdb3: error: dax access failed (-95) # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.1T 0 disk ├─sda1 8:1 0 156M 0 part ├─sda2 8:2 0 40G 0 part └─sda3 8:3 0 1.1T 0 part sdb 8:16 0 1.1T 0 disk ├─sdb1 8:17 0 600M 0 part ├─sdb2 8:18 0 1G 0 part └─sdb3 8:19 0 1.1T 0 part ├─rhel00-swap 254:3 0 4G 0 lvm ├─rhel00-home 254:4 0 1T 0 lvm └─rhel00-root 254:5 0 50G 0 lvm sdc 8:32 0 1.1T 0 disk sdd 8:48 0 1.1T 0 disk sde 8:64 0 1.1T 0 disk sdf 8:80 0 1.1T 0 disk sdg 8:96 0 1.1T 0 disk sdh 8:112 0 3.3T 0 disk ├─sdh1 8:113 0 500M 0 part /boot/efi ├─sdh2 8:114 0 40G 0 part / ├─sdh3 8:115 0 2.9T 0 part /home └─sdh4 8:116 0 314.6G 0 part [SWAP] sdi 8:128 0 1.1T 0 disk sdj 8:144 0 3.3T 0 disk ├─sdj1 8:145 0 512M 0 part └─sdj2 8:146 0 3.3T 0 part sdk 8:160 0 119.2G 0 disk ├─sdk1 8:161 0 200M 0 part ├─sdk2 8:162 0 1G 0 part └─sdk3 8:163 0 118G 0 part ├─rhel-swap 254:0 0 4G 0 lvm ├─rhel-home 254:1 0 64G 0 lvm └─rhel-root 254:2 0 50G 0 lvm sdl 8:176 0 119.2G 0 disk The call path is shown as follows: dm_table_determine_type dm_table_supports_dax device_supports_dax generic_fsdax_supported __generic_fsdax_supported With the disk configuration listing from the command 'lsblk', the member 'dev->dax_dev' of the block devices 'sdb3' and 'sdk3' (configured by device mapper) is NULL in function generic_fsdax_supported() because the member is configured in function open_table_device(). To prevent the confusing error messages in this scenario (this is normal behavior), just print those error messages by pr_debug() by checking if dax_dev is NULL and the block device does not support DAX. Link: https://lore.kernel.org/r/20200819154236.24191-1-adrianhuang0701@gmail.com Fixes: 2316097 ("dax: print error message by pr_info() in __generic_fsdax_supported()") Cc: Coly Li <colyli@suse.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Alasdair Kergon <agk@redhat.com> Cc: Mike Snitzer <snitzer@redhat.com> Acked-by: Coly Li <colyli@suse.de> Signed-off-by: Adrian Huang <ahuang12@lenovo.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
binfmt_flat loader uses the gap between text and data to store data segment pointers for the libraries. Even in the absence of shared libraries it stores at least one pointer to the executable's own data segment. Text and data can go back to back in the flat binary image and without offsetting data segment last few instructions in the text segment may get corrupted by the data segment pointer. Fix it by reverting commit a235722 ("binfmt_flat: don't offset the data start"). Cc: stable@vger.kernel.org Fixes: a235722 ("binfmt_flat: don't offset the data start") Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
…/git/hid/hid Pull HID fixes from Jiri Kosina: - regression fix / revert of a commit that intended to reduce probing delay by ~50ms, but introduced a race that causes quite a few devices not to enumerate, or get stuck on first IRQ - buffer overflow fix in hiddev, from Peilin Ye * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: Revert "HID: usbhid: do not sleep when opening device" HID: hiddev: Fix slab-out-of-bounds write in hiddev_ioctl_usage() HID: quirks: Always poll three more Lenovo PixArt mice HID: i2c-hid: Always sleep 60ms after I2C_HID_PWR_ON commands HID: macally: Constify macally_id_table HID: cougar: Constify cougar_id_table
…nux/kernel/git/nvdimm/nvdimm Pull libnvdimm fixes from Vishal Verma: "A couple of minor fixes for things merged in 5.9-rc1. One is an out-of-bounds access caught by KASAN, and the second is a tweak to some overzealous logging about dax support even for traditional block devices which was unnecessary" * tag 'libnvdimm-fix-v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: dax: do not print error message for non-persistent memory block device libnvdimm: KASAN: global-out-of-bounds Read in internal_create_group
…nux/kernel/git/gerg/m68knommu Pull m68knommu fix from Greg Ungerer: "Only a single fix for the binfmt_flat loader (reverting a recent change)" * tag 'm68knommu-for-v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: binfmt_flat: revert "binfmt_flat: don't offset the data start"
pull bot
pushed a commit
that referenced
this pull request
May 17, 2024
Recent additions in BPF like cpu v4 instructions, test_bpf module exhibits the following failures: test_bpf: #82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #172 ALU64_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #313 BSWAP 16: 0x0123456789abcdef -> 0xefcd eBPF filter opcode 00d7 (@2) unsupported jited:0 301 PASS test_bpf: #314 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89 eBPF filter opcode 00d7 (@2) unsupported jited:0 555 PASS test_bpf: #315 BSWAP 64: 0x0123456789abcdef -> 0x67452301 eBPF filter opcode 00d7 (@2) unsupported jited:0 268 PASS test_bpf: #316 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89 eBPF filter opcode 00d7 (@2) unsupported jited:0 269 PASS test_bpf: #317 BSWAP 16: 0xfedcba9876543210 -> 0x1032 eBPF filter opcode 00d7 (@2) unsupported jited:0 460 PASS test_bpf: #318 BSWAP 32: 0xfedcba9876543210 -> 0x10325476 eBPF filter opcode 00d7 (@2) unsupported jited:0 320 PASS test_bpf: #319 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe eBPF filter opcode 00d7 (@2) unsupported jited:0 222 PASS test_bpf: #320 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476 eBPF filter opcode 00d7 (@2) unsupported jited:0 273 PASS test_bpf: #344 BPF_LDX_MEMSX | BPF_B eBPF filter opcode 0091 (@5) unsupported jited:0 432 PASS test_bpf: #345 BPF_LDX_MEMSX | BPF_H eBPF filter opcode 0089 (@5) unsupported jited:0 381 PASS test_bpf: #346 BPF_LDX_MEMSX | BPF_W eBPF filter opcode 0081 (@5) unsupported jited:0 505 PASS test_bpf: #490 JMP32_JA: Unconditional jump: if (true) return 1 eBPF filter opcode 0006 (@1) unsupported jited:0 261 PASS test_bpf: Summary: 1040 PASSED, 10 FAILED, [924/1038 JIT'ed] Fix them by adding missing processing. Fixes: daabb2b ("bpf/tests: add tests for cpuv4 instructions") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/91de862dda99d170697eb79ffb478678af7e0b27.1709652689.git.christophe.leroy@csgroup.eu
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]. Want to support this open source service? Please star it : )