- Linux-kselftest-mirror - lists.linaro.org

[PATCH bpf,v5 0/4] Socket lookup BPF API from tc/xdp ingress does not respect VRF bindings.

by Gilad Sever

When calling socket lookup from L2 (tc, xdp), VRF boundaries aren't respected. This patchset fixes this by regarding the incoming device's VRF attachment when performing the socket lookups from tc/xdp. The first two patches are coding changes which factor out the tc helper's logic which was shared with cg/sk_skb (which operate correctly). This refactoring is needed in order to avoid affecting the cgroup/sk_skb flows as there does not seem to be a strict criteria for discerning which flow the helper is called from based on the net device or packet information. The third patch contains the actual bugfix. The fourth patch adds bpf tests for these lookup functions. --- v5: Use reverse xmas tree indentation v4: - Move dev_sdif() to include/linux/netdevice.h as suggested by Stanislav Fomichev - Remove SYS and SYS_NOFAIL duplicate definitions v3: - Rename bpf_l2_sdif() to dev_sdif() as suggested by Stanislav Fomichev - Added xdp tests as suggested by Daniel Borkmann - Use start_server() to avoid duplicate code as suggested by Stanislav Fomichev v2: Fixed uninitialized var in test patch (4). Gilad Sever (4): bpf: factor out socket lookup functions for the TC hookpoint. bpf: Call __bpf_sk_lookup()/__bpf_skc_lookup() directly via TC hookpoint bpf: fix bpf socket lookup from tc/xdp to respect socket VRF bindings selftests/bpf: Add vrf_socket_lookup tests include/linux/netdevice.h | 9 + net/core/filter.c | 123 +++++-- .../bpf/prog_tests/vrf_socket_lookup.c | 312 ++++++++++++++++++ .../selftests/bpf/progs/vrf_socket_lookup.c | 88 +++++ 4 files changed, 511 insertions(+), 21 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/vrf_socket_lookup.c create mode 100644 tools/testing/selftests/bpf/progs/vrf_socket_lookup.c -- 2.34.1

2 years

2
5
0 0

[PATCH net 0/2] selftests/ptp: Add support for new timestamp IOCTLs

by Alex Maftei

PTP_SYS_OFFSET_EXTENDED was added in November 2018 in 361800876f80 (" ptp: add PTP_SYS_OFFSET_EXTENDED ioctl") and PTP_SYS_OFFSET_PRECISE was added in February 2016 in 719f1aa4a671 ("ptp: Add PTP_SYS_OFFSET_PRECISE for driver crosstimestamping") The PTP selftest code is lacking support for these two IOCTLS. This short series of patches adds support for them. Alex Maftei (2): selftests/ptp: Add -x option for testing PTP_SYS_OFFSET_EXTENDED selftests/ptp: Add -X option for testing PTP_SYS_OFFSET_PRECISE tools/testing/selftests/ptp/testptp.c | 71 ++++++++++++++++++++++++++- 1 file changed, 69 insertions(+), 2 deletions(-) -- 2.28.0

2 years

5
7
0 0

[PATCH v2 0/3] tracing/user_events: Fix incorrect return value for

by sunliming

Now the writing operation return the count of writes whether events are enabled or disabled. Fix this by just return -ENOENT when events are disabled. v1 -> v2: - Change the returh vale from -EFAULT to -ENOENT sunliming (3): tracing/user_events: Fix incorrect return value for writing operation when events are disabled selftests/user_events: Enable the event before write_fault test in ftrace self-test selftests/user_events: Add test cases when event is disabled kernel/trace/trace_events_user.c | 3 ++- tools/testing/selftests/user_events/ftrace_test.c | 8 ++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) -- 2.25.1

2 years

4
8
0 0

[PATCH 0/3] RFC: F_OFD_GETLK should provide more info

by Stas Sergeev

This patch-set implements 2 small extensions to the current F_OFD_GETLK, allowing it to gather more information than it currently returns. First extension allows to use F_UNLCK on query, which currently returns EINVAL. Instead it can be used to query the locks on a particular fd - something that is not currently possible. The basic idea is that on F_OFD_GETLK, F_UNLCK would "conflict" with (or query) any types of the lock on the same fd, and ignore any locks on other fds. Use-cases: 1. CRIU-alike scenario when you want to read the locking info from an fd for the later reconstruction. This can now be done by setting l_start and l_len to 0 to cover entire file range, and do F_OFD_GETLK. In the loop you need to advance l_start past the returned lock ranges, to eventually collect all locked ranges. 2. Implementing the lock checking/enforcing policy. Say you want to implement an "auditor" module in your program, that checks that the I/O is done only after the proper locking is applied on a file region. In this case you need to know if the particular region is locked on that fd, and if so - with what type of the lock. If you would do that currently (without this extension) then you can only check for the write locks, and for that you need to probe the lock on your fd and then open the same file via nother fd and probe there. That way you can identify the write lock on a particular fd, but such trick is non-atomic and complex. As for finding out the read lock on a particular fd - impossible. This extension allows to do such queries without any extra efforts. 3. Implementing the mandatory locking policy. Suppose you want to make a policy where the write lock inhibits any unlocked readers and writers. Currently you need to check if the write lock is present on some other fd, and if it is not there - allow the I/O operation. But because the write lock can appear at any moment, you need to do that under some global lock, which can be released only when the I/O operation is finished. With the proposed extension you can instead just check the write lock on your own fd first, and if it is there - allow the I/O operation on that fd without using any global lock. Only if there is no write lock on this fd, then you need to take global lock and check for a write lock on other fds. The second patch implements another extension. Currently F_OFD_GETLK returns -1 in the l_pid member. This patch removes the code that writes -1 there, so that the proper pid is returned. I am not sure why it was decided to deliberately hide the owner's pid. It may be needed in case you want to send some message to the offending locker, like eg SIGKILL. The third patch adds a test-case for OFD locks. It tests both the generic things and the proposed extensions. Stas Sergeev (3): fs/locks: F_UNLCK extension for F_OFD_GETLK fd/locks: allow get the lock owner by F_OFD_GETLK selftests: add OFD lock tests fs/locks.c | 25 +++- tools/testing/selftests/locking/Makefile | 2 + tools/testing/selftests/locking/ofdlocks.c | 135 +++++++++++++++++++++ 3 files changed, 157 insertions(+), 5 deletions(-) create mode 100644 tools/testing/selftests/locking/ofdlocks.c CC: Jeff Layton <jlayton(a)kernel.org> CC: Chuck Lever <chuck.lever(a)oracle.com> CC: Alexander Viro <viro(a)zeniv.linux.org.uk> CC: Christian Brauner <brauner(a)kernel.org> CC: linux-fsdevel(a)vger.kernel.org CC: linux-kernel(a)vger.kernel.org CC: Shuah Khan <shuah(a)kernel.org> CC: linux-kselftest(a)vger.kernel.org -- 2.39.2

2 years

2
2
0 0

[PATCH] selftests/input: add test to cover failure on dev->absinfo

by Dana Elfassy

Added coverage for the case where !dev->absinfo, and executing the normal flow as well. Signed-off-by: Dana Elfassy <dangel101(a)gmail.com> --- This patch depends on '[v3] selftests/input: Introduce basic tests for evdev ioctls' [1] sent to the ML. [1] https://patchwork.kernel.org/project/linux-input/patch/20230607153214.15933… tools/testing/selftests/input/evioc-test.c | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/tools/testing/selftests/input/evioc-test.c b/tools/testing/selftests/input/evioc-test.c index ad7b93fe39cf..1a688002e1e7 100644 --- a/tools/testing/selftests/input/evioc-test.c +++ b/tools/testing/selftests/input/evioc-test.c @@ -234,4 +234,27 @@ TEST(eviocsrep_set_repeat_settings) selftest_uinput_destroy(uidev); } +TEST(eviocsabs_set_abs_value_limits) +{ + struct selftest_uinput *uidev; + struct input_absinfo absinfo; + int rc; + + // fail test on dev->absinfo + rc = selftest_uinput_create_device(&uidev); + ASSERT_EQ(0, rc); + ASSERT_NE(NULL, uidev); + rc = ioctl(uidev->evdev_fd, EVIOCSABS(0), &absinfo); + ASSERT_EQ(-1, rc); + selftest_uinput_destroy(uidev); + + // ioctl normal flow + rc = selftest_uinput_create_device(&uidev, EV_ABS, -1); + ASSERT_EQ(0, rc); + ASSERT_NE(NULL, uidev); + rc = ioctl(uidev->evdev_fd, EVIOCSABS(0), &absinfo); + ASSERT_EQ(0, rc); + selftest_uinput_destroy(uidev); +} + TEST_HARNESS_MAIN -- 2.41.0

2 years

1
0
0 0

[PATCH v3 00/10] Add Intel VT-d nested translation

by Yi Liu

This is to add Intel VT-d nested translation based on IOMMUFD nesting infrastructure. As the iommufd nesting infrastructure series[1], iommu core supports new ops to report iommu hardware information, allocate domains with user data and sync stage-1 IOTLB. The data required in the three paths are vendor-specific, so 1) IOMMU_HW_INFO_TYPE_INTEL_VTD and struct iommu_device_info_vtd are defined to report iommu hardware information for Intel VT-d . 2) IOMMU_HWPT_DATA_VTD_S1 is defined for the Intel VT-d stage-1 page table, it will be used in the stage-1 domain allocation and IOTLB syncing path. struct iommu_hwpt_intel_vtd is defined to pass user_data for the Intel VT-d stage-1 domain allocation. struct iommu_hwpt_invalidate_intel_vtd is defined to pass the data for the Intel VT-d stage-1 IOTLB invalidation. With above IOMMUFD extensions, the intel iommu driver implements the three paths to support nested translation. The first Intel platform supporting nested translation is Sapphire Rapids which, unfortunately, has a hardware errata [2] requiring special treatment. This errata happens when a stage-1 page table page (either level) is located in a stage-2 read-only region. In that case the IOMMU hardware may ignore the stage-2 RO permission and still set the A/D bit in stage-1 page table entries during page table walking. A flag IOMMU_HW_INFO_VTD_ERRATA_772415_SPR17 is introduced to report this errata to userspace. With that restriction the user should either disable nested translation to favor RO stage-2 mappings or ensure no RO stage-2 mapping to enable nested translation. Intel-iommu driver is armed with necessary checks to prevent such mix in patch10 of this series. Qemu currently does add RO mappings though. The vfio agent in Qemu simply maps all valid regions in the GPA address space which certainly includes RO regions e.g. vbios. In reality we don't know a usage relying on DMA reads from the BIOS region. Hence finding a way to allow user opt-out RO mappings in Qemu might be an acceptable tradeoff. But how to achieve it cleanly needs more discussion in Qemu community. For now we just hacked Qemu to test. Complete code can be found in [3], QEMU could can be found in [4]. base-commit: ce9b593b1f74ccd090edc5d2ad397da84baa9946 [1] https://lore.kernel.org/linux-iommu/20230511143844.22693-1-yi.l.liu@intel.c… [2] https://www.intel.com/content/www/us/en/content-details/772415/content-deta… [3] https://github.com/yiliu1765/iommufd/tree/iommufd_nesting [4] https://github.com/yiliu1765/qemu/tree/wip/iommufd_rfcv4.mig.reset.v4_var3%… Change log: v3: - Further split the patches into an order of adding helpers for nested domain, iotlb flush, nested domain attachment and nested domain allocation callback, then report the hw_info to userspace. - Add batch support in cache invalidation from userspace - Disallow nested translation usage if RO mappings exists in stage-2 domain due to errata on readonly mappings on Sapphire Rapids platform. v2: https://lore.kernel.org/linux-iommu/20230309082207.612346-1-yi.l.liu@intel.… - The iommufd infrastructure is split to be separate series. v1: https://lore.kernel.org/linux-iommu/20230209043153.14964-1-yi.l.liu@intel.c… Regards, Yi Liu Lu Baolu (5): iommu/vt-d: Extend dmar_domain to support nested domain iommu/vt-d: Add helper for nested domain allocation iommu/vt-d: Add helper to setup pasid nested translation iommu/vt-d: Add nested domain allocation iommu/vt-d: Disallow nesting on domains with read-only mappings Yi Liu (5): iommufd: Add data structure for Intel VT-d stage-1 domain allocation iommu/vt-d: Make domain attach helpers to be extern iommu/vt-d: Set the nested domain to a device iommu/vt-d: Add iotlb flush for nested domain iommu/vt-d: Implement hw_info for iommu capability query drivers/iommu/intel/Makefile | 2 +- drivers/iommu/intel/iommu.c | 78 ++++++++++++--- drivers/iommu/intel/iommu.h | 55 +++++++++-- drivers/iommu/intel/nested.c | 181 +++++++++++++++++++++++++++++++++++ drivers/iommu/intel/pasid.c | 151 +++++++++++++++++++++++++++++ drivers/iommu/intel/pasid.h | 2 + drivers/iommu/iommufd/main.c | 6 ++ include/linux/iommu.h | 1 + include/uapi/linux/iommufd.h | 149 ++++++++++++++++++++++++++++ 9 files changed, 603 insertions(+), 22 deletions(-) create mode 100644 drivers/iommu/intel/nested.c -- 2.34.1

2 years

7
39
0 0

[linux-next:master] BUILD REGRESSION 47045630bc409ce6606d97b790895210dd1d517d

by kernel test robot

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 47045630bc409ce6606d97b790895210dd1d517d Add linux-next specific files for 20230619 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202306122223.HHER4zOo-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202306141934.UKmM9bFX-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202306151954.Rsz6HP7h-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202306191640.NE97q8G3-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202306200328.NX4JlBDv-lkp@intel.com Error/Warning: (recently discovered and may have been fixed) arch/parisc/kernel/pdt.c:65:6: warning: no previous prototype for 'arch_report_meminfo' [-Wmissing-prototypes] arch/riscv/kvm/aia_imsic.c:237:9: error: call to undeclared function 'arch_atomic_long_fetch_or'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] drivers/char/mem.c:164:25: error: implicit declaration of function 'unxlate_dev_mem_ptr'; did you mean 'xlate_dev_mem_ptr'? [-Werror=implicit-function-declaration] drivers/gpu/drm/i915/display/intel_display_power.h:255:70: error: declaration of 'struct seq_file' will not be visible outside of this function [-Werror,-Wvisibility] drivers/leds/leds-cht-wcove.c:144:21: warning: no previous prototype for 'cht_wc_leds_brightness_get' [-Wmissing-prototypes] lib/kunit/executor_test.c:138:4: warning: cast from 'void (*)(const void *)' to 'kunit_action_t *' (aka 'void (*)(void *)') converts to incompatible function type [-Wcast-function-type-strict] lib/kunit/test.c:775:38: warning: cast from 'void (*)(const void *)' to 'kunit_action_t *' (aka 'void (*)(void *)') converts to incompatible function type [-Wcast-function-type-strict] security/apparmor/policy_unpack.c:1173: warning: expecting prototype for verify_dfa_accept_xindex(). Prototype was for verify_dfa_accept_index() instead Unverified Error/Warning (likely false positive, please contact us if interested): drivers/staging/media/atomisp/pci/atomisp_fops.c:517 atomisp_open() warn: missing unwind goto? drivers/usb/cdns3/cdns3-starfive.c:23: warning: expecting prototype for cdns3(). Prototype was for USB_STRAP_HOST() instead fs/smb/client/cifsfs.c:984 cifs_smb3_do_mount() warn: possible memory leak of 'cifs_sb' fs/smb/client/cifssmb.c:4089 CIFSFindFirst() warn: missing error code? 'rc' fs/smb/client/cifssmb.c:4216 CIFSFindNext() warn: missing error code? 'rc' fs/smb/client/connect.c:2775 cifs_match_super() error: 'tlink' dereferencing possible ERR_PTR() fs/smb/client/connect.c:2974 generic_ip_connect() error: we previously assumed 'socket' could be null (see line 2962) {standard input}: Error: local label `"2" (instance number 9 of a fb label)' is not defined {standard input}:1097: Error: pcrel too far Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- i386-allyesconfig | `-- drivers-leds-leds-cht-wcove.c:warning:no-previous-prototype-for-cht_wc_leds_brightness_get |-- i386-randconfig-m021-20230618 | |-- drivers-staging-media-atomisp-pci-atomisp_fops.c-atomisp_open()-warn:missing-unwind-goto | |-- fs-smb-client-cifsfs.c-cifs_smb3_do_mount()-warn:possible-memory-leak-of-cifs_sb | |-- fs-smb-client-cifssmb.c-CIFSFindFirst()-warn:missing-error-code-rc | |-- fs-smb-client-cifssmb.c-CIFSFindNext()-warn:missing-error-code-rc | |-- fs-smb-client-connect.c-cifs_match_super()-error:tlink-dereferencing-possible-ERR_PTR() | `-- fs-smb-client-connect.c-generic_ip_connect()-error:we-previously-assumed-socket-could-be-null-(see-line-) |-- parisc-allyesconfig | `-- arch-parisc-kernel-pdt.c:warning:no-previous-prototype-for-arch_report_meminfo |-- parisc-defconfig | `-- arch-parisc-kernel-pdt.c:warning:no-previous-prototype-for-arch_report_meminfo |-- parisc-randconfig-r001-20230619 | `-- arch-parisc-kernel-pdt.c:warning:no-previous-prototype-for-arch_report_meminfo |-- parisc-randconfig-s042-20230618 | `-- arch-parisc-kernel-pdt.c:warning:no-previous-prototype-for-arch_report_meminfo |-- parisc64-defconfig | `-- arch-parisc-kernel-pdt.c:warning:no-previous-prototype-for-arch_report_meminfo |-- riscv-allmodconfig | `-- drivers-usb-cdns3-cdns3-starfive.c:warning:expecting-prototype-for-cdns3().-Prototype-was-for-USB_STRAP_HOST()-instead |-- riscv-allyesconfig | `-- drivers-usb-cdns3-cdns3-starfive.c:warning:expecting-prototype-for-cdns3().-Prototype-was-for-USB_STRAP_HOST()-instead |-- riscv-randconfig-s051-20230618 | `-- arch-riscv-kernel-signal.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-void-__val-got-void-noderef-__user-assigned-datap |-- sh-allmodconfig | |-- drivers-char-mem.c:error:implicit-declaration-of-function-unxlate_dev_mem_ptr | |-- standard-input:Error:local-label-(instance-number-of-a-fb-label)-is-not-defined | `-- standard-input:Error:pcrel-too-far |-- sh-magicpanelr2_defconfig | `-- drivers-char-mem.c:error:implicit-declaration-of-function-unxlate_dev_mem_ptr |-- sh-rsk7269_defconfig | `-- drivers-char-mem.c:error:implicit-declaration-of-function-unxlate_dev_mem_ptr |-- x86_64-allyesconfig | `-- drivers-leds-leds-cht-wcove.c:warning:no-previous-prototype-for-cht_wc_leds_brightness_get `-- x86_64-randconfig-m001-20230618 |-- fs-smb-client-cifsfs.c-cifs_smb3_do_mount()-warn:possible-memory-leak-of-cifs_sb |-- fs-smb-client-cifssmb.c-CIFSFindFirst()-warn:missing-error-code-rc |-- fs-smb-client-cifssmb.c-CIFSFindNext()-warn:missing-error-code-rc |-- fs-smb-client-connect.c-cifs_match_super()-error:tlink-dereferencing-possible-ERR_PTR() `-- fs-smb-client-connect.c-generic_ip_connect()-error:we-previously-assumed-socket-could-be-null-(see-line-) clang_recent_errors |-- arm-randconfig-r002-20230619 | |-- lib-kunit-executor_test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type | |-- lib-kunit-test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type | `-- security-apparmor-policy_unpack.c:warning:expecting-prototype-for-verify_dfa_accept_xindex().-Prototype-was-for-verify_dfa_accept_index()-instead |-- hexagon-randconfig-r011-20230619 | `-- bin-bash:line:Segmentation-fault-LLVM_OBJCOPY-llvm-objcopy-pahole-J-btf_gen_floats-j-lang_exclude-rust-skip_encoding_btf_inconsistent_proto-btf_gen_optimized-btf_base-vmlinux-drivers-iio-adc-max1363.k |-- hexagon-randconfig-r041-20230619 | |-- lib-kunit-executor_test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type | `-- lib-kunit-test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type |-- hexagon-randconfig-r045-20230619 | |-- lib-kunit-executor_test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type | `-- lib-kunit-test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type |-- powerpc-randconfig-r012-20230619 | |-- lib-kunit-executor_test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type | `-- lib-kunit-test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type |-- riscv-randconfig-r042-20230619 | |-- arch-riscv-kvm-aia_imsic.c:error:call-to-undeclared-function-arch_atomic_long_fetch_or-ISO-C99-and-later-do-not-support-implicit-function-declarations | `-- lib-kunit-test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type |-- x86_64-randconfig-a012-20230619 | `-- security-apparmor-policy_unpack.c:warning:expecting-prototype-for-verify_dfa_accept_xindex().-Prototype-was-for-verify_dfa_accept_index()-instead |-- x86_64-randconfig-r015-20230619 | |-- drivers-gpu-drm-i915-display-intel_display_power.h:error:declaration-of-struct-seq_file-will-not-be-visible-outside-of-this-function-Werror-Wvisibility | `-- drivers-net-ethernet-jme.o:warning:objtool:jme_check_link()-falls-through-to-next-function-jme_powersave_phy() `-- x86_64-rhel-8.3-rust `-- security-apparmor-policy_unpack.c:warning:expecting-prototype-for-verify_dfa_accept_xindex().-Prototype-was-for-verify_dfa_accept_index()-instead elapsed time: 1330m configs tested: 126 configs skipped: 4 tested configs: alpha allyesconfig gcc alpha defconfig gcc alpha randconfig-r023-20230619 gcc arc allyesconfig gcc arc axs101_defconfig gcc arc defconfig gcc arc randconfig-r021-20230619 gcc arc randconfig-r043-20230619 gcc arm alldefconfig clang arm allmodconfig gcc arm allyesconfig gcc arm aspeed_g4_defconfig clang arm collie_defconfig clang arm defconfig gcc arm hisi_defconfig gcc arm imx_v6_v7_defconfig gcc arm jornada720_defconfig gcc arm neponset_defconfig clang arm pxa910_defconfig gcc arm randconfig-r002-20230619 clang arm randconfig-r046-20230619 gcc arm vexpress_defconfig clang arm vf610m4_defconfig gcc arm64 allyesconfig gcc arm64 defconfig gcc arm64 randconfig-r031-20230619 gcc csky defconfig gcc csky randconfig-r022-20230619 gcc hexagon randconfig-r011-20230619 clang hexagon randconfig-r041-20230619 clang hexagon randconfig-r045-20230619 clang i386 allyesconfig gcc i386 buildonly-randconfig-r004-20230619 gcc i386 buildonly-randconfig-r005-20230619 gcc i386 buildonly-randconfig-r006-20230619 gcc i386 debian-10.3 gcc i386 defconfig gcc i386 randconfig-i001-20230619 gcc i386 randconfig-i002-20230619 gcc i386 randconfig-i003-20230619 gcc i386 randconfig-i004-20230619 gcc i386 randconfig-i005-20230619 gcc i386 randconfig-i006-20230619 gcc i386 randconfig-i011-20230619 clang i386 randconfig-i012-20230619 clang i386 randconfig-i013-20230619 clang i386 randconfig-i014-20230619 clang i386 randconfig-i015-20230619 clang i386 randconfig-i016-20230619 clang i386 randconfig-r033-20230619 gcc loongarch allmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc loongarch randconfig-r006-20230619 gcc m68k allmodconfig gcc m68k allyesconfig gcc m68k defconfig gcc m68k m5208evb_defconfig gcc m68k randconfig-r034-20230619 gcc m68k randconfig-r036-20230619 gcc microblaze randconfig-r024-20230619 gcc mips allmodconfig gcc mips allyesconfig gcc mips mtx1_defconfig clang nios2 defconfig gcc nios2 randconfig-r003-20230619 gcc nios2 randconfig-r004-20230619 gcc nios2 randconfig-r016-20230619 gcc nios2 randconfig-r032-20230619 gcc parisc allyesconfig gcc parisc defconfig gcc parisc randconfig-r001-20230619 gcc parisc64 defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc gamecube_defconfig clang powerpc randconfig-r012-20230619 clang riscv allmodconfig gcc riscv allnoconfig gcc riscv allyesconfig gcc riscv defconfig gcc riscv nommu_k210_defconfig gcc riscv nommu_virt_defconfig clang riscv randconfig-r042-20230619 clang riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc s390 defconfig gcc s390 randconfig-r044-20230619 clang sh allmodconfig gcc sh apsh4ad0a_defconfig gcc sh landisk_defconfig gcc sh magicpanelr2_defconfig gcc sh rsk7269_defconfig gcc sh se7750_defconfig gcc sh shx3_defconfig gcc sparc allyesconfig gcc sparc defconfig gcc sparc64 randconfig-r005-20230619 gcc sparc64 randconfig-r014-20230619 gcc um defconfig gcc um i386_defconfig gcc um randconfig-r013-20230619 gcc um x86_64_defconfig gcc x86_64 allyesconfig gcc x86_64 buildonly-randconfig-r001-20230619 gcc x86_64 buildonly-randconfig-r002-20230619 gcc x86_64 buildonly-randconfig-r003-20230619 gcc x86_64 defconfig gcc x86_64 kexec gcc x86_64 randconfig-a001-20230619 gcc x86_64 randconfig-a002-20230619 gcc x86_64 randconfig-a003-20230619 gcc x86_64 randconfig-a004-20230619 gcc x86_64 randconfig-a005-20230619 gcc x86_64 randconfig-a006-20230619 gcc x86_64 randconfig-a011-20230619 clang x86_64 randconfig-a012-20230619 clang x86_64 randconfig-a013-20230619 clang x86_64 randconfig-a014-20230619 clang x86_64 randconfig-a015-20230619 clang x86_64 randconfig-a016-20230619 clang x86_64 randconfig-r015-20230619 clang x86_64 rhel-8.3-rust clang x86_64 rhel-8.3 gcc xtensa randconfig-r025-20230619 gcc -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

2 years

1
0
0 0

[PATCH] selftests/input: add test to cover len > maxlen in bits_to_user()

by Dana Elfassy

In order to cover this case, setting 'maxlen = 0', with the following explanation: EVIOCGKEY is executed from evdev_do_ioctl(), which is called from evdev_ioctl_handler(). evdev_ioctl_handler() is called from 2 functions, where by code coverage, only the first one is in use. ‘compat’ is given the value ‘0’ [1]. Thus, the condition [2] is always false. This means ‘len’ always equals a positive number [3] ‘maxlen’ in evdev_handle_get_val [4] is defined locally in evdev_do_ioctl() [5], and is sent in the variable 'size' [6] [1] https://elixir.bootlin.com/linux/v6.2/source/drivers/input/evdev.c#L1281 [2] https://elixir.bootlin.com/linux/v6.2/source/drivers/input/evdev.c#L705 [3] https://elixir.bootlin.com/linux/v6.2/source/drivers/input/evdev.c#L707 [4] https://elixir.bootlin.com/linux/v6.2/source/drivers/input/evdev.c#L886 [5] https://elixir.bootlin.com/linux/v6.2/source/drivers/input/evdev.c#L1155 [6] https://elixir.bootlin.com/linux/v6.2/source/drivers/input/evdev.c#L1141 Signed-off-by: Dana Elfassy <dangel101(a)gmail.com> --- tools/testing/selftests/input/evioc-test.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/tools/testing/selftests/input/evioc-test.c b/tools/testing/selftests/input/evioc-test.c index ad7b93fe39cf..b94de2ee5596 100644 --- a/tools/testing/selftests/input/evioc-test.c +++ b/tools/testing/selftests/input/evioc-test.c @@ -234,4 +234,23 @@ TEST(eviocsrep_set_repeat_settings) selftest_uinput_destroy(uidev); } +TEST(eviocgkey_get_global_key_state) +{ + struct selftest_uinput *uidev; + int rep_values[2]; + int rc; + + memset(rep_values, 0, sizeof(rep_values)); + + rc = selftest_uinput_create_device(&uidev); + ASSERT_EQ(0, rc); + ASSERT_NE(NULL, uidev); + + /* ioctl to create the scenario where len > maxlen in bits_to_user() */ + rc = ioctl(uidev->evdev_fd, EVIOCGKEY(0), rep_values); + ASSERT_EQ(0, rc); + + selftest_uinput_destroy(uidev); +} + TEST_HARNESS_MAIN -- 2.41.0

2 years

1
0
0 0

[PATCH 5.4 01/64] test_firmware: fix a memory leak with reqs buffer

by Greg Kroah-Hartman

From: Mirsad Goran Todorovac <mirsad.todorovac(a)alu.unizg.hr> [ Upstream commit be37bed754ed90b2655382f93f9724b3c1aae847 ] Dan Carpenter spotted that test_fw_config->reqs will be leaked if trigger_batched_requests_store() is called two or more times. The same appears with trigger_batched_requests_async_store(). This bug wasn't trigger by the tests, but observed by Dan's visual inspection of the code. The recommended workaround was to return -EBUSY if test_fw_config->reqs is already allocated. Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf") Cc: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Russ Weight <russell.h.weight(a)intel.com> Cc: Tianfei Zhang <tianfei.zhang(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Colin Ian King <colin.i.king(a)gmail.com> Cc: Randy Dunlap <rdunlap(a)infradead.org> Cc: linux-kselftest(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v5.4 Suggested-by: Dan Carpenter <error27(a)gmail.com> Suggested-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac(a)alu.unizg.hr> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Acked-by: Luis Chamberlain <mcgrof(a)kernel.org> Link: https://lore.kernel.org/r/20230509084746.48259-2-mirsad.todorovac@alu.unizg… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- lib/test_firmware.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/lib/test_firmware.c b/lib/test_firmware.c index 3146845f01562..38553944e9675 100644 --- a/lib/test_firmware.c +++ b/lib/test_firmware.c @@ -679,6 +679,11 @@ static ssize_t trigger_batched_requests_store(struct device *dev, mutex_lock(&test_fw_mutex); + if (test_fw_config->reqs) { + rc = -EBUSY; + goto out_bail; + } + test_fw_config->reqs = vzalloc(array3_size(sizeof(struct test_batched_req), test_fw_config->num_requests, 2)); @@ -778,6 +783,11 @@ ssize_t trigger_batched_requests_async_store(struct device *dev, mutex_lock(&test_fw_mutex); + if (test_fw_config->reqs) { + rc = -EBUSY; + goto out_bail; + } + test_fw_config->reqs = vzalloc(array3_size(sizeof(struct test_batched_req), test_fw_config->num_requests, 2)); -- 2.39.2

2 years

1
0
0 0

[PATCH 5.10 05/89] test_firmware: fix a memory leak with reqs buffer

by Greg Kroah-Hartman

From: Mirsad Goran Todorovac <mirsad.todorovac(a)alu.unizg.hr> [ Upstream commit be37bed754ed90b2655382f93f9724b3c1aae847 ] Dan Carpenter spotted that test_fw_config->reqs will be leaked if trigger_batched_requests_store() is called two or more times. The same appears with trigger_batched_requests_async_store(). This bug wasn't trigger by the tests, but observed by Dan's visual inspection of the code. The recommended workaround was to return -EBUSY if test_fw_config->reqs is already allocated. Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf") Cc: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Russ Weight <russell.h.weight(a)intel.com> Cc: Tianfei Zhang <tianfei.zhang(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Colin Ian King <colin.i.king(a)gmail.com> Cc: Randy Dunlap <rdunlap(a)infradead.org> Cc: linux-kselftest(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v5.4 Suggested-by: Dan Carpenter <error27(a)gmail.com> Suggested-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac(a)alu.unizg.hr> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Acked-by: Luis Chamberlain <mcgrof(a)kernel.org> Link: https://lore.kernel.org/r/20230509084746.48259-2-mirsad.todorovac@alu.unizg… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- lib/test_firmware.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/lib/test_firmware.c b/lib/test_firmware.c index 4884057eb53f0..ed0455a9ded87 100644 --- a/lib/test_firmware.c +++ b/lib/test_firmware.c @@ -863,6 +863,11 @@ static ssize_t trigger_batched_requests_store(struct device *dev, mutex_lock(&test_fw_mutex); + if (test_fw_config->reqs) { + rc = -EBUSY; + goto out_bail; + } + test_fw_config->reqs = vzalloc(array3_size(sizeof(struct test_batched_req), test_fw_config->num_requests, 2)); @@ -962,6 +967,11 @@ ssize_t trigger_batched_requests_async_store(struct device *dev, mutex_lock(&test_fw_mutex); + if (test_fw_config->reqs) { + rc = -EBUSY; + goto out_bail; + } + test_fw_config->reqs = vzalloc(array3_size(sizeof(struct test_batched_req), test_fw_config->num_requests, 2)); -- 2.39.2

2 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror