Age | Commit message (Collapse) | Author | Files | Lines |
|
Toke Høiland-Jørgensen says:
====================
samples/bpf: Remove unmaintained XDP sample utilities
The samples/bpf directory in the kernel tree started out as a way of showcasing
different aspects of BPF functionality by writing small utility programs for
each feature. However, as the BPF subsystem has matured, the preferred way of
including userspace code with a feature has become the BPF selftests, which also
have the benefit of being consistently run as part of the BPF CI system.
As a result of this shift, the utilities in samples/bpf have seen little love,
and have slowly bitrotted. There have been sporadic cleanup patches over the
years, but it's clear that the utilities are far from maintained.
For XDP in particular, some of the utilities have been used as benchmarking aids
when implementing new kernel features, which seems to be the main reason they
have stuck around; any updates the utilities have seen have been targeted at
this use case. However, as the BPF subsystem as a whole has moved on, it has
become increasingly difficult to incorporate new features into these utilities
because they predate most of the modern BPF features (such as kfuncs and BTF).
Rather than try to update these utilities and keep maintaining them in the
kernel tree, we have ported the useful features of the utilities to the
xdp-tools package. In the porting process we also updated the utilities to take
advantage of modern BPF features, integrated them with libxdp, and polished the
user interface.
As these utilities are standalone tools, maintaining them out of tree is
simpler, and we plan to keep maintaining them in the xdp-tools repo. To direct
users of these utilities to the right place, this series removes the utilities
from samples/bpf, leaving in place only a couple of utilities whose
functionality have not yet been ported to xdp-tools.
The xdp-tools repository is located on Github at the following URL:
https://github.com/xdp-project/xdp-tools
The commits in the series removes one utility each, explaining how the
equivalent functionality can be obtained with xdp-tools.
v2:
- Add equivalent xdp-tools commands for each removed utility
v3:
- Add link to xdp-tools in the README
Toke Høiland-Jørgensen (7):
samples/bpf: Remove the xdp_monitor utility
samples/bpf: Remove the xdp_redirect* utilities
samples/bpf: Remove the xdp_rxq_info utility
samples/bpf: Remove the xdp1 and xdp2 utilities
samples/bpf: Remove the xdp_sample_pkts utility
samples/bpf: Cleanup .gitignore
samples/bpf: Add note to README about the XDP utilities moved to
xdp-tools
samples/bpf/.gitignore | 12 -
samples/bpf/Makefile | 48 +-
samples/bpf/README.rst | 6 +
samples/bpf/xdp1_kern.c | 100 ----
samples/bpf/xdp1_user.c | 166 ------
samples/bpf/xdp2_kern.c | 125 -----
samples/bpf/xdp_monitor.bpf.c | 8 -
samples/bpf/xdp_monitor_user.c | 118 -----
samples/bpf/xdp_redirect.bpf.c | 49 --
samples/bpf/xdp_redirect_cpu.bpf.c | 539 -------------------
samples/bpf/xdp_redirect_cpu_user.c | 559 --------------------
samples/bpf/xdp_redirect_map.bpf.c | 97 ----
samples/bpf/xdp_redirect_map_multi.bpf.c | 77 ---
samples/bpf/xdp_redirect_map_multi_user.c | 232 --------
samples/bpf/xdp_redirect_map_user.c | 228 --------
samples/bpf/xdp_redirect_user.c | 172 ------
samples/bpf/xdp_rxq_info_kern.c | 140 -----
samples/bpf/xdp_rxq_info_user.c | 614 ----------------------
samples/bpf/xdp_sample_pkts_kern.c | 57 --
samples/bpf/xdp_sample_pkts_user.c | 196 -------
20 files changed, 7 insertions(+), 3536 deletions(-)
delete mode 100644 samples/bpf/xdp1_kern.c
delete mode 100644 samples/bpf/xdp1_user.c
delete mode 100644 samples/bpf/xdp2_kern.c
delete mode 100644 samples/bpf/xdp_monitor.bpf.c
delete mode 100644 samples/bpf/xdp_monitor_user.c
delete mode 100644 samples/bpf/xdp_redirect.bpf.c
delete mode 100644 samples/bpf/xdp_redirect_cpu.bpf.c
delete mode 100644 samples/bpf/xdp_redirect_cpu_user.c
delete mode 100644 samples/bpf/xdp_redirect_map.bpf.c
delete mode 100644 samples/bpf/xdp_redirect_map_multi.bpf.c
delete mode 100644 samples/bpf/xdp_redirect_map_multi_user.c
delete mode 100644 samples/bpf/xdp_redirect_map_user.c
delete mode 100644 samples/bpf/xdp_redirect_user.c
delete mode 100644 samples/bpf/xdp_rxq_info_kern.c
delete mode 100644 samples/bpf/xdp_rxq_info_user.c
delete mode 100644 samples/bpf/xdp_sample_pkts_kern.c
delete mode 100644 samples/bpf/xdp_sample_pkts_user.c
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
To help users find the XDP utilities, add a note to the README about the
new location and the conversion documentation in the commit messages.
Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
Remove no longer present XDP utilities from .gitignore. Apart from the
recently removed XDP utilities this also includes the previously removed
xdpsock and xsk utilities.
Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
The functionality of this utility is covered by the xdpdump utility in
xdp-tools.
There's a slight difference in usage as the xdpdump utility's main focus is
to dump packets before or after they are processed by an existing XDP
program. However, xdpdump also has the --load-xdp-program switch, which
will make it attach its own program if no existing program is loaded. With
this, xdp_sample_pkts usage can be converted as:
xdp_sample_pkts eth0
--> xdpdump --load-xdp-program eth0
To get roughly equivalent behaviour.
Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
The functionality of these utilities have been incorporated into the
xdp-bench utility in xdp-tools.
Equivalent functionality is:
xdp1 eth0
--> xdp-bench drop -p parse-ip -l load-bytes eth0
xdp2 eth0
--> xdp-bench drop -p swap-macs eth0
Note that there's a slight difference in behaviour of those examples: the
swap-macs operation of xdp-bench doesn't use the bpf_xdp_load_bytes()
helper to load the packet data, whereas the xdp2 utility did so
unconditionally. For the parse-ip action the use of bpf_xdp_load_bytes()
can be selected by the '-l load-bytes' switch, with the difference that the
xdp-bench utility will perform two separate calls to the helper, one to
load the ethernet header and another to load the IP header; where the xdp1
utility only performed one call always loading 60 bytes of data.
Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
The functionality of this utility has been incorporated into the xdp-bench
utility in xdp-tools, by way of the --rxq-stats argument to the 'drop',
'pass' and 'tx' commands of xdp-bench.
Some examples of how to convert xdp_rxq_info invocations into equivalent
xdp-bench commands:
xdp_rxq_info -d eth0
--> xdp-bench pass --rxq-stats eth0
xdp_rxq_info -d eth0 -a XDP_DROP -m
--> xdp-bench drop --rxq-stats -p swap-macs eth0
Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
These utilities have all been ported to xdp-tools as functions of the
xdp-bench utility. The four different utilities in samples are incorporated
as separate subcommands to xdp-bench, with most of the command line
parameters left intact, except that mandatory arguments are always
positional in xdp-bench. For full usage details see the --help output of
each command, or the xdp-bench man page.
Some examples of how to convert usage to xdp-bench are:
xdp_redirect eth0 eth1
--> xdp-bench redirect eth0 eth1
xdp_redirect_map eth0 eth1
--> xdp-bench redirect-map eth0 eth1
xdp_redirect_map_multi eth0 eth1 eth2 eth3
--> xdp-bench redirect-multi eth0 eth1 eth2 eth3
xdp_redirect_cpu -d eth0 -c 0 -c 1
--> xdp-bench redirect-cpu -c 0 -c 1 eth0
xdp_redirect_cpu -d eth0 -c 0 -c 1 -r eth1
--> xdp-bench redirect-cpu -c 0 -c 1 eth0 -r redirect -D eth1
Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
This utility has been ported as-is to xdp-tools as 'xdp-monitor'. The only
difference in usage between the samples and xdp-tools versions is that the
'-v' command line parameter has been changed to '-e' in the xdp-tools
version for consistency with the other utilities.
Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Paolo Abeni:
"Including fixes from wifi, can and netfilter.
Fixes to fixes:
- nf_tables:
- GC transaction race with abort path
- defer gc run if previous batch is still pending
Previous releases - regressions:
- ipv4: fix data-races around inet->inet_id
- phy: fix deadlocking in phy_error() invocation
- mdio: fix C45 read/write protocol
- ipvlan: fix a reference count leak warning in ipvlan_ns_exit()
- ice: fix NULL pointer deref during VF reset
- i40e: fix potential NULL pointer dereferencing of pf->vf in
i40e_sync_vsi_filters()
- tg3: use slab_build_skb() when needed
- mtk_eth_soc: fix NULL pointer on hw reset
Previous releases - always broken:
- core: validate veth and vxcan peer ifindexes
- sched: fix a qdisc modification with ambiguous command request
- devlink: add missing unregister linecard notification
- wifi: mac80211: limit reorder_buf_filtered to avoid UBSAN warning
- batman:
- do not get eth header before batadv_check_management_packet
- fix batadv_v_ogm_aggr_send memory leak
- bonding: fix macvlan over alb bond support
- mlxsw: set time stamp fields also when its type is MIRROR_UTC"
* tag 'net-6.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (54 commits)
selftests: bonding: add macvlan over bond testing
selftest: bond: add new topo bond_topo_2d1c.sh
bonding: fix macvlan over alb bond support
rtnetlink: Reject negative ifindexes in RTM_NEWLINK
netfilter: nf_tables: defer gc run if previous batch is still pending
netfilter: nf_tables: fix out of memory error handling
netfilter: nf_tables: use correct lock to protect gc_list
netfilter: nf_tables: GC transaction race with abort path
netfilter: nf_tables: flush pending destroy work before netlink notifier
netfilter: nf_tables: validate all pending tables
ibmveth: Use dcbf rather than dcbfl
i40e: fix potential NULL pointer dereferencing of pf->vf i40e_sync_vsi_filters()
net/sched: fix a qdisc modification with ambiguous command request
igc: Fix the typo in the PTM Control macro
batman-adv: Hold rtnl lock during MTU update via netlink
igb: Avoid starting unnecessary workqueues
can: raw: add missing refcount for memory leak fix
can: isotp: fix support for transmission of SF without flow control
bnx2x: new flag for track HW resource allocation
sfc: allocate a big enough SKB for loopback selftest packet
...
|
|
Add a local kptr test with no special fields in the struct. Without the
previous patch, the following warning will hit:
[ 44.683877] WARNING: CPU: 3 PID: 485 at kernel/bpf/syscall.c:660 bpf_obj_free_fields+0x220/0x240
[ 44.684640] Modules linked in: bpf_testmod(OE)
[ 44.685044] CPU: 3 PID: 485 Comm: kworker/u8:5 Tainted: G OE 6.5.0-rc5-01703-g260d855e9b90 #248
[ 44.685827] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 44.686693] Workqueue: events_unbound bpf_map_free_deferred
[ 44.687297] RIP: 0010:bpf_obj_free_fields+0x220/0x240
[ 44.687775] Code: e8 55 17 1f 00 49 8b 74 24 08 4c 89 ef e8 e8 14 05 00 e8 a3 da e2 ff e9 55 fe ff ff 0f 0b e9 4e fe ff
ff 0f 0b e9 47 fe ff ff <0f> 0b e8 d9 d9 e2 ff 31 f6 eb d5 48 83 c4 10 5b 41 5c e
[ 44.689353] RSP: 0018:ffff888106467cb8 EFLAGS: 00010246
[ 44.689806] RAX: 0000000000000000 RBX: ffff888112b3a200 RCX: 0000000000000001
[ 44.690433] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffff8881128ad988
[ 44.691094] RBP: 0000000000000002 R08: ffffffff81370bd0 R09: 1ffff110216231a5
[ 44.691643] R10: dffffc0000000000 R11: ffffed10216231a6 R12: ffff88810d68a488
[ 44.692245] R13: ffff88810767c288 R14: ffff88810d68a400 R15: ffff88810d68a418
[ 44.692829] FS: 0000000000000000(0000) GS:ffff8881f7580000(0000) knlGS:0000000000000000
[ 44.693484] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 44.693964] CR2: 000055c7f2afce28 CR3: 000000010fee4002 CR4: 0000000000370ee0
[ 44.694513] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 44.695102] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 44.695747] Call Trace:
[ 44.696001] <TASK>
[ 44.696183] ? __warn+0xfe/0x270
[ 44.696447] ? bpf_obj_free_fields+0x220/0x240
[ 44.696817] ? report_bug+0x220/0x2d0
[ 44.697180] ? handle_bug+0x3d/0x70
[ 44.697507] ? exc_invalid_op+0x1a/0x50
[ 44.697887] ? asm_exc_invalid_op+0x1a/0x20
[ 44.698282] ? btf_find_struct_meta+0xd0/0xd0
[ 44.698634] ? bpf_obj_free_fields+0x220/0x240
[ 44.699027] ? bpf_obj_free_fields+0x1e2/0x240
[ 44.699414] array_map_free+0x1a3/0x260
[ 44.699763] bpf_map_free_deferred+0x7b/0xe0
[ 44.700154] process_one_work+0x46d/0x750
[ 44.700523] worker_thread+0x49e/0x900
[ 44.700892] ? pr_cont_work+0x270/0x270
[ 44.701224] kthread+0x1ae/0x1d0
[ 44.701516] ? kthread_blkcg+0x50/0x50
[ 44.701860] ret_from_fork+0x34/0x50
[ 44.702178] ? kthread_blkcg+0x50/0x50
[ 44.702508] ret_from_fork_asm+0x11/0x20
[ 44.702880] </TASK>
With the previous patch, there is no warnings.
Signed-off-by: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
Currently, in function bpf_obj_free_fields(), for local kptr,
a warning will be issued if the struct does not contain any
special fields. But actually the kernel seems totally okay
with a local kptr without any special fields. Permitting
no special fields also aligns with future percpu kptr which
also allows no special fields.
Acked-by: Dave Marchevsky <[email protected]>
Signed-off-by: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
The fixed commit erroneously removed a call to nfsd_end_grace(),
which makes calls to write_v4_end_grace() a no-op.
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-lkp/[email protected]
Fixes: 39d432fc7630 ("NFSD: trace nfsctl operations")
Reviewed-by: Jeff Layton <[email protected]>
Signed-off-by: Chuck Lever <[email protected]>
|
|
As following backtrace, the struct file_lock request , in posix_lock_inode
is free before ftrace function using.
Replace the ftrace function ahead free flow could fix the use-after-free
issue.
[name:report&]===============================================
BUG:KASAN: use-after-free in trace_event_raw_event_filelock_lock+0x80/0x12c
[name:report&]Read at addr f6ffff8025622620 by task NativeThread/16753
[name:report_hw_tags&]Pointer tag: [f6], memory tag: [fe]
[name:report&]
BT:
Hardware name: MT6897 (DT)
Call trace:
dump_backtrace+0xf8/0x148
show_stack+0x18/0x24
dump_stack_lvl+0x60/0x7c
print_report+0x2c8/0xa08
kasan_report+0xb0/0x120
__do_kernel_fault+0xc8/0x248
do_bad_area+0x30/0xdc
do_tag_check_fault+0x1c/0x30
do_mem_abort+0x58/0xbc
el1_abort+0x3c/0x5c
el1h_64_sync_handler+0x54/0x90
el1h_64_sync+0x68/0x6c
trace_event_raw_event_filelock_lock+0x80/0x12c
posix_lock_inode+0xd0c/0xd60
do_lock_file_wait+0xb8/0x190
fcntl_setlk+0x2d8/0x440
...
[name:report&]
[name:report&]Allocated by task 16752:
...
slab_post_alloc_hook+0x74/0x340
kmem_cache_alloc+0x1b0/0x2f0
posix_lock_inode+0xb0/0xd60
...
[name:report&]
[name:report&]Freed by task 16752:
...
kmem_cache_free+0x274/0x5b0
locks_dispose_list+0x3c/0x148
posix_lock_inode+0xc40/0xd60
do_lock_file_wait+0xb8/0x190
fcntl_setlk+0x2d8/0x440
do_fcntl+0x150/0xc18
...
Signed-off-by: Will Shiu <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
|
|
Signed-off-by: Jakub Wilk <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
|
|
Test the basic locking stuff on 2 fds: multiple read locks,
conflicts between read and write locks, use of len==0 for queries.
Also tests for F_UNLCK F_OFD_GETLK extension.
[ jlayton: fix unlink() pathname in selftest ]
Cc: Jeff Layton <[email protected]>
Cc: Chuck Lever <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Christian Brauner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Shuah Khan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Stas Sergeev <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5-updates-2023-08-22
1) Patches #1..#13 From Jiri:
The goal of this patchset is to make the SF code cleaner.
Benefit from previously introduced devlink_port struct containerization
to avoid unnecessary lookups in devlink port ops.
Also, benefit from the devlink locking changes and avoid unnecessary
reference counting.
2) Patches #14,#15:
Add ability to configure proto both UDP and TCP selectors in RX and TX
directions.
* tag 'mlx5-updates-2023-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux:
net/mlx5e: Support IPsec upper TCP protocol selector
net/mlx5e: Support IPsec upper protocol selector field offload for RX
net/mlx5: Store vport in struct mlx5_devlink_port and use it in port ops
net/mlx5: Check vhca_resource_manager capability in each op and add extack msg
net/mlx5: Relax mlx5_devlink_eswitch_get() return value checking
net/mlx5: Return -EOPNOTSUPP in mlx5_devlink_port_fn_migratable_set() directly
net/mlx5: Reduce number of vport lookups passing vport pointer instead of index
net/mlx5: Embed struct devlink_port into driver structure
net/mlx5: Don't register ops for non-PF/VF/SF port and avoid checks in ops
net/mlx5: Remove no longer used mlx5_esw_offloads_sf_vport_enable/disable()
net/mlx5: Introduce mlx5_eswitch_load/unload_sf_vport() and use it from SF code
net/mlx5: Allow mlx5_esw_offloads_devlink_port_register() to register SFs
net/mlx5: Push devlink port PF/VF init/cleanup calls out of devlink_port_register/unregister()
net/mlx5: Push out SF devlink port init and cleanup code to separate helpers
net/mlx5: Rework devlink port alloc/free into init/cleanup
====================
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Paolo Abeni <[email protected]>
|
|
Lenovo 82SJ doesn't have DMIC connected like 82V2 does. Narrow
the match down to only cover 82V2.
Reported-by: [email protected]
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217063
Fixes: 2232b2dd8cd4 ("ASoC: amd: yc: Add Lenovo Yoga Slim 7 Pro X to quirks table")
Signed-off-by: Mario Limonciello <[email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]
|
|
This commit implements the runtime PM operations to disable eMMC card clock
when idle.
Reviewed-by: David Thompson <[email protected]>
Signed-off-by: Liming Sun <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
This commit adds handling in dwcmshc_resume() for different error
cases.
Signed-off-by: Liming Sun <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
preserve_pci_rom_image() was accessing the romsize field in
efi_pci_io_protocol_t directly instead of using the efi_table_attr()
helper. This prevents the ROM image from being saved correctly during a
mixed mode boot.
Fixes: 2c3625cb9fa2 ("efi/x86: Fold __setup_efi_pci32() and __setup_efi_pci64() into one function")
Signed-off-by: Mikel Rychliski <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
|
|
0-Day found a 34.6% regression in stress-ng's 'af-alg' test case, and
bisected it to commit b81fac906a8f ("x86/fpu: Move FPU initialization into
arch_cpu_finalize_init()"), which optimizes the FPU init order, and moves
the CR4_OSXSAVE enabling into a later place:
arch_cpu_finalize_init
identify_boot_cpu
identify_cpu
generic_identify
get_cpu_cap --> setup cpu capability
...
fpu__init_cpu
fpu__init_cpu_xstate
cr4_set_bits(X86_CR4_OSXSAVE);
As the FPU is not yet initialized the CPU capability setup fails to set
X86_FEATURE_OSXSAVE. Many security module like 'camellia_aesni_avx_x86_64'
depend on this feature and therefore fail to load, causing the regression.
Cure this by setting X86_FEATURE_OSXSAVE feature right after OSXSAVE
enabling.
[ tglx: Moved it into the actual BSP FPU initialization code and added a comment ]
Fixes: b81fac906a8f ("x86/fpu: Move FPU initialization into arch_cpu_finalize_init()")
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Feng Tang <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/lkml/[email protected]
Link: https://lore.kernel.org/lkml/[email protected]
|
|
The thread flag TIF_NEED_FPU_LOAD indicates that the FPU saved state is
valid and should be reloaded when returning to userspace. However, the
kernel will skip doing this if the FPU registers are already valid as
determined by fpregs_state_valid(). The logic embedded there considers
the state valid if two cases are both true:
1: fpu_fpregs_owner_ctx points to the current tasks FPU state
2: the last CPU the registers were live in was the current CPU.
This is usually correct logic. A CPU’s fpu_fpregs_owner_ctx is set to
the current FPU during the fpregs_restore_userregs() operation, so it
indicates that the registers have been restored on this CPU. But this
alone doesn’t preclude that the task hasn’t been rescheduled to a
different CPU, where the registers were modified, and then back to the
current CPU. To verify that this was not the case the logic relies on the
second condition. So the assumption is that if the registers have been
restored, AND they haven’t had the chance to be modified (by being
loaded on another CPU), then they MUST be valid on the current CPU.
Besides the lazy FPU optimizations, the other cases where the FPU
registers might not be valid are when the kernel modifies the FPU register
state or the FPU saved buffer. In this case the operation modifying the
FPU state needs to let the kernel know the correspondence has been
broken. The comment in “arch/x86/kernel/fpu/context.h” has:
/*
...
* If the FPU register state is valid, the kernel can skip restoring the
* FPU state from memory.
*
* Any code that clobbers the FPU registers or updates the in-memory
* FPU state for a task MUST let the rest of the kernel know that the
* FPU registers are no longer valid for this task.
*
* Either one of these invalidation functions is enough. Invalidate
* a resource you control: CPU if using the CPU for something else
* (with preemption disabled), FPU for the current task, or a task that
* is prevented from running by the current task.
*/
However, this is not completely true. When the kernel modifies the
registers or saved FPU state, it can only rely on
__fpu_invalidate_fpregs_state(), which wipes the FPU’s last_cpu
tracking. The exec path instead relies on fpregs_deactivate(), which sets
the CPU’s FPU context to NULL. This was observed to fail to restore the
reset FPU state to the registers when returning to userspace in the
following scenario:
1. A task is executing in userspace on CPU0
- CPU0’s FPU context points to tasks
- fpu->last_cpu=CPU0
2. The task exec()’s
3. While in the kernel the task is preempted
- CPU0 gets a thread executing in the kernel (such that no other
FPU context is activated)
- Scheduler sets task’s fpu->last_cpu=CPU0 when scheduling out
4. Task is migrated to CPU1
5. Continuing the exec(), the task gets to
fpu_flush_thread()->fpu_reset_fpregs()
- Sets CPU1’s fpu context to NULL
- Copies the init state to the task’s FPU buffer
- Sets TIF_NEED_FPU_LOAD on the task
6. The task reschedules back to CPU0 before completing the exec() and
returning to userspace
- During the reschedule, scheduler finds TIF_NEED_FPU_LOAD is set
- Skips saving the registers and updating task’s fpu→last_cpu,
because TIF_NEED_FPU_LOAD is the canonical source.
7. Now CPU0’s FPU context is still pointing to the task’s, and
fpu->last_cpu is still CPU0. So fpregs_state_valid() returns true even
though the reset FPU state has not been restored.
So the root cause is that exec() is doing the wrong kind of invalidate. It
should reset fpu->last_cpu via __fpu_invalidate_fpregs_state(). Further,
fpu__drop() doesn't really seem appropriate as the task (and FPU) are not
going away, they are just getting reset as part of an exec. So switch to
__fpu_invalidate_fpregs_state().
Also, delete the misleading comment that says that either kind of
invalidate will be enough, because it’s not always the case.
Fixes: 33344368cb08 ("x86/fpu: Clean up the fpu__clear() variants")
Reported-by: Lei Wang <[email protected]>
Signed-off-by: Rick Edgecombe <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Lijun Pan <[email protected]>
Reviewed-by: Sohil Mehta <[email protected]>
Acked-by: Lijun Pan <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Florian Westphal says:
====================
netfilter updates for net
This PR contains nf_tables updates for your *net* tree.
First patch fixes table validation, I broke this in 6.4 when tracking
validation state per table, reported by Pablo, fixup from myself.
Second patch makes sure objects waiting for memory release have been
released, this was broken in 6.1, patch from Pablo Neira Ayuso.
Patch three is a fix-for-fix from previous PR: In case a transaction
gets aborted, gc sequence counter needs to be incremented so pending
gc requests are invalidated, from Pablo.
Same for patch 4: gc list needs to use gc list lock, not destroy lock,
also from Pablo.
Patch 5 fixes a UaF in a set backend, but this should only occur when
failslab is enabled for GFP_KERNEL allocations, broken since feature
was added in 5.6, from myself.
Patch 6 fixes a double-free bug that was also added via previous PR:
We must not schedule gc work if the previous batch is still queued.
netfilter pull request 2023-08-23
* tag 'nf-23-08-23' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
netfilter: nf_tables: defer gc run if previous batch is still pending
netfilter: nf_tables: fix out of memory error handling
netfilter: nf_tables: use correct lock to protect gc_list
netfilter: nf_tables: GC transaction race with abort path
netfilter: nf_tables: flush pending destroy work before netlink notifier
netfilter: nf_tables: validate all pending tables
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
|
|
Hangbin Liu says:
====================
fix macvlan over alb bond support
Currently, the macvlan over alb bond is broken after commit
14af9963ba1e ("bonding: Support macvlans on top of tlb/rlb mode bonds").
Fix this and add relate tests.
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
|
|
Add a macvlan over bonding test with mode active-backup, balance-tlb
and balance-alb.
]# ./bond_macvlan.sh
TEST: active-backup: IPv4: client->server [ OK ]
TEST: active-backup: IPv6: client->server [ OK ]
TEST: active-backup: IPv4: client->macvlan_1 [ OK ]
TEST: active-backup: IPv6: client->macvlan_1 [ OK ]
TEST: active-backup: IPv4: client->macvlan_2 [ OK ]
TEST: active-backup: IPv6: client->macvlan_2 [ OK ]
TEST: active-backup: IPv4: macvlan_1->macvlan_2 [ OK ]
TEST: active-backup: IPv6: macvlan_1->macvlan_2 [ OK ]
TEST: active-backup: IPv4: server->client [ OK ]
TEST: active-backup: IPv6: server->client [ OK ]
TEST: active-backup: IPv4: macvlan_1->client [ OK ]
TEST: active-backup: IPv6: macvlan_1->client [ OK ]
TEST: active-backup: IPv4: macvlan_2->client [ OK ]
TEST: active-backup: IPv6: macvlan_2->client [ OK ]
TEST: active-backup: IPv4: macvlan_2->macvlan_2 [ OK ]
TEST: active-backup: IPv6: macvlan_2->macvlan_2 [ OK ]
[...]
TEST: balance-alb: IPv4: client->server [ OK ]
TEST: balance-alb: IPv6: client->server [ OK ]
TEST: balance-alb: IPv4: client->macvlan_1 [ OK ]
TEST: balance-alb: IPv6: client->macvlan_1 [ OK ]
TEST: balance-alb: IPv4: client->macvlan_2 [ OK ]
TEST: balance-alb: IPv6: client->macvlan_2 [ OK ]
TEST: balance-alb: IPv4: macvlan_1->macvlan_2 [ OK ]
TEST: balance-alb: IPv6: macvlan_1->macvlan_2 [ OK ]
TEST: balance-alb: IPv4: server->client [ OK ]
TEST: balance-alb: IPv6: server->client [ OK ]
TEST: balance-alb: IPv4: macvlan_1->client [ OK ]
TEST: balance-alb: IPv6: macvlan_1->client [ OK ]
TEST: balance-alb: IPv4: macvlan_2->client [ OK ]
TEST: balance-alb: IPv6: macvlan_2->client [ OK ]
TEST: balance-alb: IPv4: macvlan_2->macvlan_2 [ OK ]
TEST: balance-alb: IPv6: macvlan_2->macvlan_2 [ OK ]
Signed-off-by: Hangbin Liu <[email protected]>
Acked-by: Jay Vosburgh <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
Add a new testing topo bond_topo_2d1c.sh which is used more commonly.
Make bond_topo_3d1c.sh just source bond_topo_2d1c.sh and add the
extra link.
Signed-off-by: Hangbin Liu <[email protected]>
Acked-by: Jay Vosburgh <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
The commit 14af9963ba1e ("bonding: Support macvlans on top of tlb/rlb mode
bonds") aims to enable the use of macvlans on top of rlb bond mode. However,
the current rlb bond mode only handles ARP packets to update remote neighbor
entries. This causes an issue when a macvlan is on top of the bond, and
remote devices send packets to the macvlan using the bond's MAC address
as the destination. After delivering the packets to the macvlan, the macvlan
will rejects them as the MAC address is incorrect. Consequently, this commit
makes macvlan over bond non-functional.
To address this problem, one potential solution is to check for the presence
of a macvlan port on the bond device using netif_is_macvlan_port(bond->dev)
and return NULL in the rlb_arp_xmit() function. However, this approach
doesn't fully resolve the situation when a VLAN exists between the bond and
macvlan.
So let's just do a partial revert for commit 14af9963ba1e in rlb_arp_xmit().
As the comment said, Don't modify or load balance ARPs that do not originate
locally.
Fixes: 14af9963ba1e ("bonding: Support macvlans on top of tlb/rlb mode bonds")
Reported-by: [email protected]
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2117816
Signed-off-by: Hangbin Liu <[email protected]>
Acked-by: Jay Vosburgh <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
Documentation/process/license-rules.rst and checkpatch expect the SPDX
identifier syntax for multiple licenses to use capital "OR". Correct it
to keep consistent format and avoid copy-paste issues.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
Negative ifindexes are illegal, but the kernel does not validate the
ifindex in the ancillary header of RTM_NEWLINK messages, resulting in
the kernel generating a warning [1] when such an ifindex is specified.
Fix by rejecting negative ifindexes.
[1]
WARNING: CPU: 0 PID: 5031 at net/core/dev.c:9593 dev_index_reserve+0x1a2/0x1c0 net/core/dev.c:9593
[...]
Call Trace:
<TASK>
register_netdevice+0x69a/0x1490 net/core/dev.c:10081
br_dev_newlink+0x27/0x110 net/bridge/br_netlink.c:1552
rtnl_newlink_create net/core/rtnetlink.c:3471 [inline]
__rtnl_newlink+0x115e/0x18c0 net/core/rtnetlink.c:3688
rtnl_newlink+0x67/0xa0 net/core/rtnetlink.c:3701
rtnetlink_rcv_msg+0x439/0xd30 net/core/rtnetlink.c:6427
netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2545
netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
netlink_unicast+0x536/0x810 net/netlink/af_netlink.c:1368
netlink_sendmsg+0x93c/0xe40 net/netlink/af_netlink.c:1910
sock_sendmsg_nosec net/socket.c:728 [inline]
sock_sendmsg+0xd9/0x180 net/socket.c:751
____sys_sendmsg+0x6ac/0x940 net/socket.c:2538
___sys_sendmsg+0x135/0x1d0 net/socket.c:2592
__sys_sendmsg+0x117/0x1e0 net/socket.c:2621
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fixes: 38f7b870d4a6 ("[RTNETLINK]: Link creation API")
Reported-by: [email protected]
Signed-off-by: Ido Schimmel <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Reviewed-by: Jakub Kicinski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.5
A relatively large but generally not super urgent set of fixes for ASoC,
including some quirks and a MAINTAINERS update. There's also an update
to cs35l56 to change the firmware ABI, there are no current shipping
systems which use the current interface and the sooner we get the new
interface in the less likely it is that something will start.
It'd be nice if these landed for v6.5 but not the end of the world if
they wait till v6.6.
|
|
The header file crypto/algapi.h is for internal use only. Use the
header file crypto/utils.h instead.
Signed-off-by: Herbert Xu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
|
|
Extracting btf_int_encoding() is only meaningful for BTF_KIND_INT, so we
need to check that first before inferring signedness.
Closes: https://github.com/libbpf/libbpf/issues/704
Reported-by: Lorenz Bauer <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Acked-by: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin KaFai Lau <[email protected]>
|
|
It seems like it was forgotten to add uprobe_multi binary to .gitignore.
Fix this trivial omission.
Signed-off-by: Andrii Nakryiko <[email protected]>
Acked-by: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin KaFai Lau <[email protected]>
|
|
Daniel Golle says:
====================
net: ethernet: mtk_eth_soc: improve support for MT7988
This series fixes and completes commit 445eb6448ed3b ("net: ethernet:
mtk_eth_soc: add basic support for MT7988 SoC") and also adds support
for using the in-SoC SRAM to previous MT7986 and MT7981 SoCs.
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Systems having 4 GiB of RAM and more require DMA addressing beyond the
current 32-bit limit. Starting from MT7988 the hardware now supports
36-bit DMA addressing, let's use that new capability in the driver to
avoid running into swiotlb on systems with 4 GiB of RAM or more.
Signed-off-by: Daniel Golle <[email protected]>
Link: https://lore.kernel.org/r/95b919c98876c9e49761e44662e7c937479eecb8.1692721443.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
MT7981, MT7986 and MT7988 come with in-SoC SRAM dedicated for Ethernet
DMA rings. Support using the SRAM without breaking existing device tree
bindings, ie. only new SoC starting from MT7988 will have the SRAM
declared as additional resource in device tree. For MT7981 and MT7986
an offset on top of the main I/O base is used.
Signed-off-by: Daniel Golle <[email protected]>
Link: https://lore.kernel.org/r/e45e0f230c63ad58869e8fe35b95a2fb8925b625.1692721443.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Add bits needed to reset the frame engine on MT7988.
Fixes: 445eb6448ed3 ("net: ethernet: mtk_eth_soc: add basic support for MT7988 SoC")
Signed-off-by: Daniel Golle <[email protected]>
Link: https://lore.kernel.org/r/89b6c38380e7a3800c1362aa7575600717bc7543.1692721443.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
More register macros need to be adjusted for the 3rd GMAC on MT7988.
Account for added bit in SYSCFG0_SGMII_MASK.
Fixes: 445eb6448ed3 ("net: ethernet: mtk_eth_soc: add basic support for MT7988 SoC")
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Link: https://lore.kernel.org/r/1c8da012e2ca80939906d85f314138c552139f0f.1692721443.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
As we already added the exception tracing for XDP_TX, I think it is
necessary to add the exception tracing for other XDP actions, such
as XDP_REDIRECT, XDP_ABORTED and unknown error actions.
Signed-off-by: Wei Fang <[email protected]>
Suggested-by: Jakub Kicinski <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Use the standard error pointer macro to shorten the code and simplify.
Signed-off-by: Yu Liao <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
For bpf_object__pin_programs() there is bpf_object__unpin_programs().
Likewise bpf_object__unpin_maps() for bpf_object__pin_maps().
But no bpf_object__unpin() for bpf_object__pin(). Adding the former adds
symmetry to the API.
It's also convenient for cleanup in application code. It's an API I
would've used if it was available for a repro I was writing earlier.
Signed-off-by: Daniel Xu <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Reviewed-by: Song Liu <[email protected]>
Link: https://lore.kernel.org/bpf/b2f9d41da4a350281a0b53a804d11b68327e14e5.1692832478.git.dxu@dxuuu.xyz
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fix from Rafael Wysocki:
"Make an existing ACPI IRQ override quirk for PCSpecialist Elimina Pro
16 M work as intended (Hans de Goede)"
* tag 'acpi-6.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: resource: Fix IRQ override quirk for PCSpecialist Elimina Pro 16 M
|
|
After the commit in the Fixes: line below, HPD polling stopped working
on i915, since after that change calling drm_kms_helper_poll_enable()
doesn't restart drm_mode_config::output_poll_work if the work was
stopped (no connectors needing polling) and enabling polling for a
connector (during runtime suspend or detecting an HPD IRQ storm).
After the above change calling drm_kms_helper_poll_enable() is a nop
after it's been called already and polling for some connectors was
disabled/re-enabled.
Fix this by calling drm_kms_helper_poll_reschedule() added in the
previous patch instead, which reschedules the work whenever expected.
Fixes: d33a54e3991d ("drm/probe_helper: sort out poll_running vs poll_enabled")
CC: [email protected] # 6.4+
Cc: Dmitry Baryshkov <[email protected]>
Cc: [email protected]
Reviewed-by: Jouni Högander <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 50452f2f76852322620b63e62922b85e955abe94)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Add a helper to reschedule drm_mode_config::output_poll_work after
polling has been enabled for a connector (and needing a reschedule,
since previously polling was disabled for all connectors and hence
output_poll_work was not running).
This is needed by the next patch fixing HPD polling on i915.
CC: [email protected] # 6.4+
Cc: Dmitry Baryshkov <[email protected]>
Cc: [email protected]
Reviewed-by: Jouni Högander <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit fe2352fd64029918174de4b460dfe6df0c6911cd)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Andy Chiu <[email protected]> says:
We add a vlenb field in Vector context and save it with the
riscv_vstate_save() macro. It should not cause performance regression as
VLENB is a design-time constant and is frequently used by hardware.
Also, adding this field into the __sc_riscv_v_state may benifit us on a
future compatibility issue becuse a hardware may have writable VLENB.
Adding and saving VLENB have an immediate benifit as it gives ptrace a
better view of the Vector extension and makes it possible to reconstruct
Vector register files from the dump without doing an additional csr read.
This patchset also sync the number of note types between us and gdb for
riscv to solve a conflicting note.
This is not an ABI break given that 6.5 has not been released yet.
* b4-shazam-merge:
RISC-V: vector: export VLENB csr in __sc_riscv_v_state
RISC-V: Remove ptrace support for vectors
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
Associate the swnode of the GPIO device's (which is the interrupt
controller here) with the irq domain. Otherwise the interrupt-controller
device attribute is a no-op.
Fixes: cb8c474e79be ("gpio: sim: new testing module")
Signed-off-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
|
|
If a GPIO simulator device is unbound with interrupts still requested,
we will hit a use-after-free issue in __irq_domain_deactivate_irq(). The
owner of the irq domain must dispose of all mappings before destroying
the domain object.
Fixes: cb8c474e79be ("gpio: sim: new testing module")
Signed-off-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
|
|
vmw_bo_unreference sets the input buffer to null on exit, resulting in
null ptr deref's on the subsequent drm gem put calls.
This went unnoticed because only very old userspace would be exercising
those paths but it wouldn't be hard to hit on old distros with brand
new kernels.
Introduce a new function that abstracts unrefing of user bo's to make
the code cleaner and more explicit.
Signed-off-by: Zack Rusin <[email protected]>
Reported-by: Ian Forbes <[email protected]>
Fixes: 9ef8d83e8e25 ("drm/vmwgfx: Do not drop the reference to the handle too soon")
Cc: <[email protected]> # v6.4+
Reviewed-by: Maaz Mombasawala<[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
For multiple commands the driver was not correctly validating the shader
stages resulting in possible kernel oopses. The validation code was only.
if ever, checking the upper bound on the shader stages but never a lower
bound (valid shader stages start at 1 not 0).
Fixes kernel oopses ending up in vmw_binding_add, e.g.:
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 2443 Comm: testcase Not tainted 6.3.0-rc4-vmwgfx #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
RIP: 0010:vmw_binding_add+0x4c/0x140 [vmwgfx]
Code: 7e 30 49 83 ff 0e 0f 87 ea 00 00 00 4b 8d 04 7f 89 d2 89 cb 48 c1 e0 03 4c 8b b0 40 3d 93 c0 48 8b 80 48 3d 93 c0 49 0f af de <48> 03 1c d0 4c 01 e3 49 8>
RSP: 0018:ffffb8014416b968 EFLAGS: 00010206
RAX: ffffffffc0933ec0 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 00000000ffffffff RSI: ffffb8014416b9c0 RDI: ffffb8014316f000
RBP: ffffb8014416b998 R08: 0000000000000003 R09: 746f6c735f726564
R10: ffffffffaaf2bda0 R11: 732e676e69646e69 R12: ffffb8014316f000
R13: ffffb8014416b9c0 R14: 0000000000000040 R15: 0000000000000006
FS: 00007fba8c0af740(0000) GS:ffff8a1277c80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000007c0933eb8 CR3: 0000000118244001 CR4: 00000000003706e0
Call Trace:
<TASK>
vmw_view_bindings_add+0xf5/0x1b0 [vmwgfx]
? ___drm_dbg+0x8a/0xb0 [drm]
vmw_cmd_dx_set_shader_res+0x8f/0xc0 [vmwgfx]
vmw_execbuf_process+0x590/0x1360 [vmwgfx]
vmw_execbuf_ioctl+0x173/0x370 [vmwgfx]
? __drm_dev_dbg+0xb4/0xe0 [drm]
? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
drm_ioctl_kernel+0xbc/0x160 [drm]
drm_ioctl+0x2d2/0x580 [drm]
? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
? do_fault+0x1a6/0x420
vmw_generic_ioctl+0xbd/0x180 [vmwgfx]
vmw_unlocked_ioctl+0x19/0x20 [vmwgfx]
__x64_sys_ioctl+0x96/0xd0
do_syscall_64+0x5d/0x90
? handle_mm_fault+0xe4/0x2f0
? debug_smp_processor_id+0x1b/0x30
? fpregs_assert_state_consistent+0x2e/0x50
? exit_to_user_mode_prepare+0x40/0x180
? irqentry_exit_to_user_mode+0xd/0x20
? irqentry_exit+0x3f/0x50
? exc_page_fault+0x8b/0x180
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Signed-off-by: Zack Rusin <[email protected]>
Cc: [email protected]
Reported-by: Ziming Zhang <[email protected]>
Testcase-found-by: Niels De Graef <[email protected]>
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Cc: <[email protected]> # v4.3+
Reviewed-by: Maaz Mombasawala<[email protected]>
Reviewed-by: Martin Krastev <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Yafang Shao says:
====================
bpf: Fix an issue in verifing allow_ptr_leaks
Patch #1: An issue found in our local 6.1 kernel.
This issue also exists in bpf-next.
Patch #2: Selftess for #1
v1->v2:
- Add acked-by from Eduard
- Fix build error reported by Alexei
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|