Age | Commit message (Collapse) | Author |
|
device_link_add() returns NULL pointer not PTR_ERR() when it fails,
so replace the IS_ERR() check with NULL pointer check.
Fixes: 72f5801a4e2b ("dmaengine: fsl-edma: integrate v3 support")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20231129090000.841440-1-yangyingliang@huaweicloud.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The eDP 1.5 spec adds a clarification for eDP 1.4x:
> For eDP v1.4x, if the Source device chooses the Main-Link rate by way
> of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0].
We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using
DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the panel
to ignore the rate set method.
Moreover, 0 is a reserved value for DP_LINK_BW_SET, and should not be
used.
v2: Improve the comments (Ville)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081
Tested-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231205180551.2476228-1-jani.nikula@intel.com
(cherry picked from commit 23b392b94acb0499f69706c5808c099f590ebcf4)
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
the original
plane_view_scanout_stride() currently assumes that we had to pad the
mapping stride with dummy pages in order to align it. But that is not
the case if the original fb stride exceeds the aligned stride used
to populate the remapped view, which is calculated from the user
specified framebuffer width rather than the user specified framebuffer
stride.
Ignore the original fb stride in this case and just stick to the POT
aligned stride. Getting this wrong will cause the plane to fetch the
wrong data, and can lead to fault errors if the page tables at the
bogus location aren't even populated.
TODO: figure out if this is OK for CCS, or if we should instead increase
the width of the view to cover the entire user specified fb stride
instead...
Cc: Imre Deak <imre.deak@intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231204202443.31247-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
(cherry picked from commit 01a39f1c4f1220a4e6a25729fae87ff5794cbc52)
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Since the plane_state variable is declared outside the scaler_users
loop in intel_atomic_setup_scalers(), and it's never reset back to
NULL inside the loop we may end up calling intel_atomic_setup_scaler()
with a non-NULL plane state for the pipe scaling case. That is bad
because intel_atomic_setup_scaler() determines whether we are doing
plane scaling or pipe scaling based on plane_state!=NULL. The end
result is that we may miscalculate the scaler mode for pipe scaling.
The hardware becomes somewhat upset if we end up in this situation
when scanning out a planar format on a SDR plane. We end up
programming the pipe scaler into planar mode as well, and the
result is a screenfull of garbage.
Fix the situation by making sure we pass the correct plane_state==NULL
when calculating the scaler mode for pipe scaling.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231207193441.20206-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit e81144106e21271c619f0c722a09e27ccb8c043d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
On ADL+ the hardware automagically calculates the CCS AUX surface
stride from the main surface stride, so when remapping we can't
really play a lot of tricks with the main surface stride, or else
the AUX surface stride would get miscalculated and no longer
match the actual data layout in memory.
Supposedly we could remap in 256 main surface tile units
(AUX page(4096)/cachline(64)*4(4x1 main surface tiles per
AUX cacheline)=256 main surface tiles), but the extra complexity
is probably not worth the hassle.
So let's just make sure our mapping stride is calculated from
the full framebuffer stride (instead of the framebuffer width).
This way the stride we program into PLANE_STRIDE will be the
original framebuffer stride, and thus there will be no change
to the AUX stride/layout.
Cc: stable@vger.kernel.org
Cc: Imre Deak <imre.deak@intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231205180308.7505-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
(cherry picked from commit 2c12eb36f849256f5eb00ffaee9bf99396fd3814)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Commit 503579448db9 ("drm/i915/gsc: Mark internal GSC engine with reserved uabi class")
made the GSC0 engine not have a valid uabi class and so broke the engine
reset counting, which in turn was made class based in cb823ed9915b ("drm/i915/gt: Use intel_gt as the primary object for handling resets").
Despite the title and commit text of the latter is not mentioning it (and
has left the storage array incorrectly sized), tracking by class, despite
it adding aliasing in hypthotetical multi-tile systems, is handy for
virtual engines which for instance do not have a valid engine->id.
Therefore we keep that but just change it to use the internal class which
is always valid. We also add a helper to increment the count, which
aligns with the existing getter.
What was broken without this fix were out of bounds reads every time a
reset would happen on the GSC0 engine, or during selftests when storing
and cross-checking the counts in igt_live_test_begin and
igt_live_test_end.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 503579448db9 ("drm/i915/gsc: Mark internal GSC engine with reserved uabi class")
[tursulin: fixed Fixes tag]
Reported-by: Alan Previn Teres Alexis <alan.previn.teres.alexis@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231201122109.729006-2-tvrtko.ursulin@linux.intel.com
(cherry picked from commit cf9cb028ac56696ff879af1154c4b2f0b12701fd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Engine->id namespace is per-tile so struct igt_live_test->reset_engine[]
needs to be two-dimensional so engine reset counts from all tiles can be
stored with no aliasing. With aliasing, if we had a real multi-tile
platform, the reset counts would be incorrect for same engine instance on
different tiles.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 0c29efa23f5c ("drm/i915/selftests: Consider multi-gt instead of to_gt()")
Reported-by: Alan Previn Teres Alexis <alan.previn.teres.alexis@intel.com>
Cc: Tejas Upadhyay <tejas.upadhyay@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231201122109.729006-1-tvrtko.ursulin@linux.intel.com
(cherry picked from commit 0647ece3819b018cb62a71c3bcb7c2c3243e78ac)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The current implementation's default Pause Forward setting is causing
unnecessary network traffic. This patch disables Pause Forward to
address this issue.
Fixes: 1121f6b02e7a ("octeontx2-af: Priority flow control configuration support")
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The efi_relocate_kernel() may load the PIE kernel to anywhere, the
loaded address may not be equal to link address or
EFI_KIMG_PREFERRED_ADDRESS.
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Wang Yao <wangyao@lemote.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Hariprasad Kelam says:
====================
octeontx2: Fix issues with promisc/allmulti mode
When interface is configured in promisc/all multi mode, low network
performance observed. This series patches address the same.
Patch1: Change the promisc/all multi mcam entry action to unicast if
there are no trusted vfs associated with PF.
Patch2: Configures RSS flow algorithm in promisc/all multi mcam entries
to address flow distribution issues.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The RSS flow algorithm is not set up correctly for promiscuous or all
multi MCAM entries. This has an impact on flow distribution.
This patch fixes the issue by updating flow algorithm index in above
mentioned MCAM entries.
Fixes: 967db3529eca ("octeontx2-af: add support for multicast/promisc packet replication feature")
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Current implementation is such that, promisc mcam entry action
is set as multicast even when there are no trusted VFs. multicast
action causes the hardware to copy packet data, which reduces
the performance.
This patch fixes this issue by setting the promisc mcam entry action to
unicast instead of multicast when there are no trusted VFs. The same
change is made for the 'allmulti' mcam entry action.
Fixes: ffd2f89ad05c ("octeontx2-pf: Enable promisc/allmulti match MCAM entries.")
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The firmware ready value is 1, and get firmware ready status
function should explicitly test for that value. The firmware
ready value read will be 2 after driver load, and on unbind
till firmware rewrites the firmware ready back to 0, the value
seen by driver will be 2, which should be regarded as not ready.
Fixes: 10c073e40469 ("octeon_ep: defer probe if firmware not ready")
Signed-off-by: Shinas Rasheed <srasheed@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The referenced change added custom cleanup code to act_ct to delete any
callbacks registered on the parent block when deleting the
tcf_ct_flow_table instance. However, the underlying issue is that the
drivers don't obtain the reference to the tcf_ct_flow_table instance when
registering callbacks which means that not only driver callbacks may still
be on the table when deleting it but also that the driver can still have
pointers to its internal nf_flowtable and can use it concurrently which
results either warning in netfilter[0] or use-after-free.
Fix the issue by taking a reference to the underlying struct
tcf_ct_flow_table instance when registering the callback and release the
reference when unregistering. Expose new API required for such reference
counting by adding two new callbacks to nf_flowtable_type and implementing
them for act_ct flowtable_ct type. This fixes the issue by extending the
lifetime of nf_flowtable until all users have unregistered.
[0]:
[106170.938634] ------------[ cut here ]------------
[106170.939111] WARNING: CPU: 21 PID: 3688 at include/net/netfilter/nf_flow_table.h:262 mlx5_tc_ct_del_ft_cb+0x267/0x2b0 [mlx5_core]
[106170.940108] Modules linked in: act_ct nf_flow_table act_mirred act_skbedit act_tunnel_key vxlan cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress mlx5_vdpa vringh vhost_iotlb vdpa bonding openvswitch nsh rpcrdma rdma_ucm
ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_regis
try overlay mlx5_core
[106170.943496] CPU: 21 PID: 3688 Comm: kworker/u48:0 Not tainted 6.6.0-rc7_for_upstream_min_debug_2023_11_01_13_02 #1
[106170.944361] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[106170.945292] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]
[106170.945846] RIP: 0010:mlx5_tc_ct_del_ft_cb+0x267/0x2b0 [mlx5_core]
[106170.946413] Code: 89 ef 48 83 05 71 a4 14 00 01 e8 f4 06 04 e1 48 83 05 6c a4 14 00 01 48 83 c4 28 5b 5d 41 5c 41 5d c3 48 83 05 d1 8b 14 00 01 <0f> 0b 48 83 05 d7 8b 14 00 01 e9 96 fe ff ff 48 83 05 a2 90 14 00
[106170.947924] RSP: 0018:ffff88813ff0fcb8 EFLAGS: 00010202
[106170.948397] RAX: 0000000000000000 RBX: ffff88811eabac40 RCX: ffff88811eabad48
[106170.949040] RDX: ffff88811eab8000 RSI: ffffffffa02cd560 RDI: 0000000000000000
[106170.949679] RBP: ffff88811eab8000 R08: 0000000000000001 R09: ffffffffa0229700
[106170.950317] R10: ffff888103538fc0 R11: 0000000000000001 R12: ffff88811eabad58
[106170.950969] R13: ffff888110c01c00 R14: ffff888106b40000 R15: 0000000000000000
[106170.951616] FS: 0000000000000000(0000) GS:ffff88885fd40000(0000) knlGS:0000000000000000
[106170.952329] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[106170.952834] CR2: 00007f1cefd28cb0 CR3: 000000012181b006 CR4: 0000000000370ea0
[106170.953482] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[106170.954121] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[106170.954766] Call Trace:
[106170.955057] <TASK>
[106170.955315] ? __warn+0x79/0x120
[106170.955648] ? mlx5_tc_ct_del_ft_cb+0x267/0x2b0 [mlx5_core]
[106170.956172] ? report_bug+0x17c/0x190
[106170.956537] ? handle_bug+0x3c/0x60
[106170.956891] ? exc_invalid_op+0x14/0x70
[106170.957264] ? asm_exc_invalid_op+0x16/0x20
[106170.957666] ? mlx5_del_flow_rules+0x10/0x310 [mlx5_core]
[106170.958172] ? mlx5_tc_ct_block_flow_offload_add+0x1240/0x1240 [mlx5_core]
[106170.958788] ? mlx5_tc_ct_del_ft_cb+0x267/0x2b0 [mlx5_core]
[106170.959339] ? mlx5_tc_ct_del_ft_cb+0xc6/0x2b0 [mlx5_core]
[106170.959854] ? mapping_remove+0x154/0x1d0 [mlx5_core]
[106170.960342] ? mlx5e_tc_action_miss_mapping_put+0x4f/0x80 [mlx5_core]
[106170.960927] mlx5_tc_ct_delete_flow+0x76/0xc0 [mlx5_core]
[106170.961441] mlx5_free_flow_attr_actions+0x13b/0x220 [mlx5_core]
[106170.962001] mlx5e_tc_del_fdb_flow+0x22c/0x3b0 [mlx5_core]
[106170.962524] mlx5e_tc_del_flow+0x95/0x3c0 [mlx5_core]
[106170.963034] mlx5e_flow_put+0x73/0xe0 [mlx5_core]
[106170.963506] mlx5e_put_flow_list+0x38/0x70 [mlx5_core]
[106170.964002] mlx5e_rep_update_flows+0xec/0x290 [mlx5_core]
[106170.964525] mlx5e_rep_neigh_update+0x1da/0x310 [mlx5_core]
[106170.965056] process_one_work+0x13a/0x2c0
[106170.965443] worker_thread+0x2e5/0x3f0
[106170.965808] ? rescuer_thread+0x410/0x410
[106170.966192] kthread+0xc6/0xf0
[106170.966515] ? kthread_complete_and_exit+0x20/0x20
[106170.966970] ret_from_fork+0x2d/0x50
[106170.967332] ? kthread_complete_and_exit+0x20/0x20
[106170.967774] ret_from_fork_asm+0x11/0x20
[106170.970466] </TASK>
[106170.970726] ---[ end trace 0000000000000000 ]---
Fixes: 77ac5e40c44e ("net/sched: act_ct: remove and free nf_table callbacks")
Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
Reviewed-by: Paul Blakey <paulb@nvidia.com>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Using PCI Device ID/Revision to initialize the interrupt_clear_with_0
workaround is problematic - there are many pre-production
steppings with different behavior, even with the same PCI ID/Revision
Instead of checking for PCI Device ID/Revision, check the VPU
buttress interrupt status register behavior - if this register
is not zero after writing 1s it means there register is RW
instead of RW1C and we need to enable the interrupt_clear_with_0
workaround.
Fixes: 7f34e01f77f8 ("accel/ivpu: Clear specific interrupt status bits on C0")
Signed-off-by: Andrzej Kacprowski <Andrzej.Kacprowski@intel.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://lore.kernel.org/all/20231204122331.40560-1-jacek.lawrynowicz@linux.intel.com
|
|
The code does not properly check whether the calibration variable is
available in the EFI. If it is not available, it causes a NULL pointer
dereference.
Check the return value of the first get_variable call also.
BUG: kernel NULL pointer dereference, address: 0000000000000000
Call Trace:
<TASK>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? srso_alias_return_thunk+0x5/0x7f
? schedule+0x5e/0xd0
? exc_page_fault+0x7f/0x180
? asm_exc_page_fault+0x26/0x30
? crc32_body+0x2c/0x120
? tas2781_save_calibration+0xe4/0x220 [snd_hda_scodec_tas2781_i2c]
tasdev_fw_ready+0x1af/0x280 [snd_hda_scodec_tas2781_i2c]
request_firmware_work_func+0x59/0xa0
Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver")
CC: stable@vger.kernel.org
Signed-off-by: Gergo Koteles <soyer@irl.hu>
Link: https://lore.kernel.org/r/f1f6583bda918f78556f67d522ca7b3b91cebbd5.1702251102.git.soyer@irl.hu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Fix incorrect descriptions for the GRPCFG register which has three
sub-registers (GRPWQCFG, GRPENGCFG and GRPFLGCFG).
No functional changes
Signed-off-by: Guanjun <guanjun@linux.alibaba.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Fenghua Yu <fenghua.yu@intel.com>
Acked-by: Lijun Pan <lijun.pan@intel.com>
Link: https://lore.kernel.org/r/20231211053704.2725417-3-guanjun@linux.alibaba.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The int_handle field in hw descriptor should also be protected
by wmb() before possibly triggering a DMA read.
Fixes: eb0cf33a91b4 (dmaengine: idxd: move interrupt handle assignment)
Signed-off-by: Guanjun <guanjun@linux.alibaba.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Fenghua Yu <fenghua.yu@intel.com>
Reviewed-by: Lijun Pan <lijun.pan@intel.com>
Link: https://lore.kernel.org/r/20231211053704.2725417-2-guanjun@linux.alibaba.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
|
|
Since outstanding journal buffers hold a journal pin, when flushing all
pins we need to close the current journal entry if necessary so its pin
can be released.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fix from Borislav Petkov:
- Make sure tasks are thawed exactly and only once to avoid their state
getting corrupted
* tag 'sched_urgent_for_v6.7_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
freezer,sched: Do not restore saved_state of a thawed task
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf event fix from Borislav Petkov:
- Make sure perf event size validation is done on every event in the
group
* tag 'perf_urgent_for_v6.7_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf: Fix perf_event_validate_size()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Borislav Petkov:
- Add a forgotten CPU vendor check in the AMD microcode post-loading
callback so that the callback runs only on AMD
- Make sure SEV-ES protocol negotiation happens only once and on the
BSP
* tag 'x86_urgent_for_v6.7_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/CPU/AMD: Check vendor in the AMD microcode callback
x86/sev: Fix kernel crash due to late update to read-only ghcb_version
|
|
The rvu_dl will be freed in rvu_nix_health_reporters_destroy(rvu_dl)
after the create_workqueue fails, and after that free, the rvu_dl will
be translate back through the following call chain:
rvu_nix_health_reporters_destroy
|-> rvu_nix_health_reporters_create
|-> rvu_health_reporters_create
|-> rvu_register_dl (label err_dl_health)
Finally. in the err_dl_health label, rvu_dl being freed again in
rvu_health_reporters_destroy(rvu) by rvu_nix_health_reporters_destroy.
In the second calls of rvu_nix_health_reporters_destroy, however,
it uses rvu_dl->rvu_nix_health_reporter, which is already freed at
the end of rvu_nix_health_reporters_destroy in the first call.
So this patch prevents the first destroy by instantly returning -ENONMEN
when create_workqueue fails. In addition, since the failure of
create_workqueue is the only entrence of label err, it has been
integrated into the error-handling path of create_workqueue.
Fixes: 5ed66306eab6 ("octeontx2-af: Add devlink health reporters for NIX")
Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Pull kvm fixes from Paolo Bonzini:
"Generic:
- Set .owner for various KVM file_operations so that files refcount
the KVM module until KVM is done executing _all_ code, including
the last few instructions of kvm_put_kvm(). And then revert the
misguided attempt to rely on "struct kvm" refcounts to pin
KVM-the-module.
ARM:
- Do not redo the mapping of vLPIs, if they have already been mapped
s390:
- Do not leave bits behind in PTEs
- Properly catch page invalidations that affect the prefix of a
nested guest
x86:
- When checking if a _running_ vCPU is "in-kernel", i.e. running at
CPL0, get the CPL directly instead of relying on
preempted_in_kernel (which is valid if and only if the vCPU was
preempted, i.e. NOT running).
- Fix a benign "return void" that was recently introduced.
Selftests:
- Makefile tweak for dependency generation
- '-Wformat' fix"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: SVM: Update EFER software model on CR0 trap for SEV-ES
KVM: selftests: add -MP to CFLAGS
KVM: selftests: Actually print out magic token in NX hugepages skip message
KVM: x86: Remove 'return void' expression for 'void function'
Revert "KVM: Prevent module exit until all VMs are freed"
KVM: Set file_operations.owner appropriately for all such structures
KVM: x86: Get CPL directly when checking if loaded vCPU is in kernel mode
KVM: arm64: GICv4: Do not perform a map to a mapped vLPI
KVM: s390/mm: Properly reset no-dat
KVM: s390: vsie: fix wrong VIR 37 when MSO is used
|
|
The old implementation extracted VLAN TCI info from the payload
before the VLAN tag has been pushed in the payload.
Another problem was that the VLAN TCI was extracted even if the
packet did not have VLAN protocol header.
This resulted in invalid VLAN TCI and as a consequence a random
queue was computed.
This patch fixes the above issues and use the VLAN TCI from the
skb if it is present or VLAN TCI from payload if present. If no
VLAN header is present queue 0 is selected.
Fixes: 52c4a1a85f4b ("net: fec: add ndo_select_queue to fix TX bandwidth fluctuations")
Signed-off-by: Radu Bulie <radu-andrei.bulie@nxp.com>
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
|
|
If DMA is used, burst length should be set to the bus width of the DMA.
Otherwise, the SPI hardware will transmit/receive one word per DMA
request.
Since this issue affects both transmission and reception, it cannot be
detected with a loopback test.
Replace magic numbers 512 and 0xfff with MX51_ECSPI_CTRL_MAX_BURST.
Reported-by Stefan Bigler <linux@bigler.io>
Signed-off-by: Benjamin Bigler <benjamin@bigler.one>
Fixes: 15a6af94a277 ("spi: Increase imx51 ecspi burst length based on transfer length")
Link: https://lore.kernel.org/r/8a415902c751cdbb4b20ce76569216ed@mail.infomaniak.com
Link: https://lore.kernel.org/r/20231209222338.5564-1-benjamin@bigler.one
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Unloading then loading the module causes a NULL ponter dereference.
The hda_unbind zeroes the hda_component, later the hda_bind tries
to dereference the codec field.
The hda_component is only initialized once by tas2781_generic_fixup.
Set only previously modified fields to NULL.
BUG: kernel NULL pointer dereference, address: 0000000000000322
Call Trace:
<TASK>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? exc_page_fault+0x7f/0x180
? asm_exc_page_fault+0x26/0x30
? tas2781_hda_bind+0x59/0x140 [snd_hda_scodec_tas2781_i2c]
component_bind_all+0xf3/0x240
try_to_bring_up_aggregate_device+0x1c3/0x270
__component_add+0xbc/0x1a0
tas2781_hda_i2c_probe+0x289/0x3a0 [snd_hda_scodec_tas2781_i2c]
i2c_device_probe+0x136/0x2e0
Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver")
Cc: stable@vger.kernel.org
Signed-off-by: Gergo Koteles <soyer@irl.hu>
Link: https://lore.kernel.org/r/8b8ed2bd5f75fbb32e354a3226c2f966fa85b46b.1702156522.git.soyer@irl.hu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP laptop 15-db0403ng uses the ALC236 codec and controls the mute
LED using COEF 0x07 index 1.
Sound card subsystem: Hewlett-Packard Company Device [103c:84ae]
Use the existing quirk for this model.
Signed-off-by: Hartmut Knaack <knaack.h@gmx.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/e61815d0-f1c7-b164-e49d-6ca84771476a@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
On ASUSTeK Z170M PLUS and Z170 PRO GAMING systems, the display codec
pins are not registered properly without the force-connect quirk. The
codec will report only one pin as having external connectivity, but i915
finds all three connectors on the system, so the two drivers are not
in sync.
Issue found with DRM igt-gpu-tools test kms_hdmi_inject@inject-audio.
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9801
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Saarinen <jani.saarinen@intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20231208132127.2438067-3-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add one more older NUC model that requires quirk to force all pins to be
connected. The display codec pins are not registered properly without
the force-connect quirk. The codec will report only one pin as having
external connectivity, but i915 finds all three connectors on the
system, so the two drivers are not in sync.
Issue found with DRM igt-gpu-tools test kms_hdmi_inject@inject-audio.
Link: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Saarinen <jani.saarinen@intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20231208132127.2438067-2-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fix from Michael Ellerman:
- Fix stack teardown in ftrace_no_trace, seen as crashes doing CPU
hotplug while ftrace is active.
Thanks to Naveen N Rao.
* tag 'powerpc-6.7-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/ftrace: Fix stack teardown in ftrace_no_trace
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fix from Bartosz Golaszewski:
- fix an error path after a failed export in sysfs code
* tag 'gpio-fixes-for-v6.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpiolib: sysfs: Fix error handling on failed export
|
|
File reference cycles have caused lots of problems for io_uring
in the past, and it still doesn't work exactly right and races with
unix_stream_read_generic(). The safest fix would be to completely
disallow sending io_uring files via sockets via SCM_RIGHT, so there
are no possible cycles invloving registered files and thus rendering
SCM accounting on the io_uring side unnecessary.
Cc: stable@vger.kernel.org
Fixes: 0091bfc81741b ("io_uring/af_unix: defer registered files gc to io_uring release")
Reported-and-suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
As &card->tx_queue_lock is acquired under softirq context along the
following call chain from solos_bh(), other acquisition of the same
lock inside process context should disable at least bh to avoid double
lock.
<deadlock #2>
pclose()
--> spin_lock(&card->tx_queue_lock)
<interrupt>
--> solos_bh()
--> fpga_tx()
--> spin_lock(&card->tx_queue_lock)
This flaw was found by an experimental static analysis tool I am
developing for irq-related deadlock.
To prevent the potential deadlock, the patch uses spin_lock_bh()
on &card->tx_queue_lock under process context code consistently to
prevent the possible deadlock scenario.
Fixes: 213e85d38912 ("solos-pci: clean up pclose() function")
Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
As &card->cli_queue_lock is acquired under softirq context along the
following call chain from solos_bh(), other acquisition of the same
lock inside process context should disable at least bh to avoid double
lock.
<deadlock #1>
console_show()
--> spin_lock(&card->cli_queue_lock)
<interrupt>
--> solos_bh()
--> spin_lock(&card->cli_queue_lock)
This flaw was found by an experimental static analysis tool I am
developing for irq-related deadlock.
To prevent the potential deadlock, the patch uses spin_lock_bh()
on the card->cli_queue_lock under process context code consistently
to prevent the possible deadlock scenario.
Fixes: 9c54004ea717 ("atm: Driver for Solos PCI ADSL2+ card.")
Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB fixes for 6.7-rc5 to resolve some reported
issues. Included in here are:
- usb gadget f_hid, and uevent fix
- xhci driver revert to resolve a much-reported issue
- typec driver fix
All of these have been in linux-next with no reported issues"
* tag 'usb-6.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: gadget: f_hid: fix report descriptor allocation
Revert "xhci: Loosen RPM as default policy to cover for AMD xHC 1.1"
usb: typec: class: fix typec_altmode_put_partner to put plugs
USB: gadget: core: adjust uevent timing on gadget unbind
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull serial driver fixes from Greg KH:
"Here are some small serial driver fixes for 6.7-rc4 to resolve some
reported issues. Included in here are:
- pl011 dma support fix
- sc16is7xx driver fix
- ma35d1 console index fix
- 8250 driver fixes for small issues
All of these have been in linux-next with no reported issues"
* tag 'tty-6.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
serial: 8250_dw: Add ACPI ID for Granite Rapids-D UART
serial: ma35d1: Validate console index before assignment
ARM: PL011: Fix DMA support
serial: sc16is7xx: address RX timeout interrupt errata
serial: 8250: 8250_omap: Clear UART_HAS_RHR_IT_DIS bit
serial: 8250_omap: Add earlycon support for the AM654 UART controller
serial: 8250: 8250_omap: Do not start RX DMA on THRI interrupt
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char / misc driver fixes from Greg KH:
"Here are some small fixes for 6.7-rc5 for a variety of small driver
subsystems. Included in here are:
- debugfs revert for reported issue
- greybus revert for reported issue
- greybus fixup for endian build warning
- coresight driver fixes
- nvmem driver fixes
- devcoredump fix
- parport new device id
- ndtest build fix
All of these have ben in linux-next with no reported issues"
* tag 'char-misc-6.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
nvmem: Do not expect fixed layouts to grab a layout driver
parport: Add support for Brainboxes IX/UC/PX parallel cards
Revert "greybus: gb-beagleplay: Ensure le for values in transport"
greybus: gb-beagleplay: Ensure le for values in transport
greybus: BeaglePlay driver needs CRC_CCITT
Revert "debugfs: annotate debugfs handlers vs. removal with lockdep"
devcoredump: Send uevent once devcd is ready
ndtest: fix typo class_regster -> class_register
misc: mei: client.c: fix problem of return '-EOVERFLOW' in mei_cl_write
misc: mei: client.c: return negative error code in mei_cl_write
mei: pxp: fix mei_pxp_send_message return value
coresight: ultrasoc-smb: Fix uninitialized before use buf_hw_base
coresight: ultrasoc-smb: Config SMB buffer before register sink
coresight: ultrasoc-smb: Fix sleep while close preempt in enable_smb
Documentation: coresight: fix `make refcheckdocs` warning
hwtracing: hisi_ptt: Don't try to attach a task
hwtracing: hisi_ptt: Handle the interrupt in hardirq context
hwtracing: hisi_ptt: Add dummy callback pmu::read()
coresight: Fix crash when Perf and sysfs modes are used concurrently
coresight: etm4x: Remove bogous __exit annotation for some functions
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
Pull LoongArch fixes from Huacai Chen:
"Preserve syscall nr across execve(), slightly clean up drdtime(), fix
the Clang built zboot kernel, fix a stack unwinder bug and several bpf
jit bugs"
* tag 'loongarch-fixes-6.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson:
LoongArch: BPF: Fix unconditional bswap instructions
LoongArch: BPF: Fix sign-extension mov instructions
LoongArch: BPF: Don't sign extend function return value
LoongArch: BPF: Don't sign extend memory load operand
LoongArch: Preserve syscall nr across execve()
LoongArch: Set unwind stack type to unknown rather than set error flag
LoongArch: Slightly clean up drdtime()
LoongArch: Apply dynamic relocations for LLD
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
Pull MIPS fixes from Thomas Bogendoerfer:
- Fixes for broken Loongson firmware
- Fix lockdep splat
- Fix FPU states when creating kernel threads
* tag 'mips-fixes_6.7_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: kernel: Clear FPU states when setting up kernel threads
MIPS: Loongson64: Handle more memory types passed from firmware
MIPS: Loongson64: Enable DMA noncoherent support
MIPS: Loongson64: Reserve vgabios memory on boot
mips/smp: Call rcutree_report_cpu_starting() earlier
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools
Pull perf tools fixes from Namhyung Kim:
"A random set of small bug fixes including:
- Fix segfault on AmpereOne due to missing default metricgroup name
- Fix segfault on `perf list --json` due to NULL pointer"
* tag 'perf-tools-fixes-for-v6.7-2-2023-12-08' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools:
perf list: Fix JSON segfault by setting the used skip_duplicate_pmus callback
perf vendor events arm64: AmpereOne: Add missing DefaultMetricgroupName fields
perf metrics: Avoid segv if default metricgroup isn't set
|
|
Pull smb client fixes from Steve French:
"Six smb3 client fixes:
- Fixes for copy_file_range and clone (cache invalidation and file
size), also addresses an xfstest failure
- Fix to return proper error if REMAP_FILE_DEDUP set (also fixes
xfstest generic/304)
- Fix potential null pointer reference with DFS
- Multichannel fix addressing (reverting an earlier patch) some of
the problems with enabling/disabling channels dynamically
Still working on a followon multichannel fix to address another issue
found in reconnect testing that will send next week"
* tag '6.7-rc4-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
cifs: reconnect worker should take reference on server struct unconditionally
Revert "cifs: reconnect work should have reference on server struct"
cifs: Fix non-availability of dedup breaking generic/304
smb: client: fix potential NULL deref in parse_dfs_referrals()
cifs: Fix flushing, invalidation and file size with FICLONE
cifs: Fix flushing, invalidation and file size with copy_file_range()
|
|
We can see that "bswap32: Takes an unsigned 32-bit number in either big-
or little-endian format and returns the equivalent number with the same
bit width but opposite endianness" in BPF Instruction Set Specification,
so it should clear the upper 32 bits in "case 32:" for both BPF_ALU and
BPF_ALU64.
[root@linux fedora]# echo 1 > /proc/sys/net/core/bpf_jit_enable
[root@linux fedora]# modprobe test_bpf
Before:
test_bpf: #313 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89 jited:1 ret 1460850314 != -271733879 (0x5712ce8a != 0xefcdab89)FAIL (1 times)
test_bpf: #317 BSWAP 32: 0xfedcba9876543210 -> 0x10325476 jited:1 ret -1460850316 != 271733878 (0xa8ed3174 != 0x10325476)FAIL (1 times)
After:
test_bpf: #313 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89 jited:1 4 PASS
test_bpf: #317 BSWAP 32: 0xfedcba9876543210 -> 0x10325476 jited:1 4 PASS
Fixes: 4ebf9216e7df ("LoongArch: BPF: Support unconditional bswap instructions")
Acked-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
We can see that "Short form of movsx, dst_reg = (s8,s16,s32)src_reg" in
include/linux/filter.h, additionally, for BPF_ALU64 the value of the
destination register is unchanged whereas for BPF_ALU the upper 32 bits
of the destination register are zeroed, so it should clear the upper 32
bits for BPF_ALU.
[root@linux fedora]# echo 1 > /proc/sys/net/core/bpf_jit_enable
[root@linux fedora]# modprobe test_bpf
Before:
test_bpf: #81 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
test_bpf: #82 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
After:
test_bpf: #81 ALU_MOVSX | BPF_B jited:1 6 PASS
test_bpf: #82 ALU_MOVSX | BPF_H jited:1 6 PASS
By the way, the bpf selftest case "./test_progs -t verifier_movsx" can
also be fixed with this patch.
Fixes: f48012f16150 ("LoongArch: BPF: Support sign-extension mov instructions")
Acked-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
The `cls_redirect` test triggers a kernel panic like:
# ./test_progs -t cls_redirect
Can't find bpf_testmod.ko kernel module: -2
WARNING! Selftests relying on bpf_testmod.ko will be skipped.
[ 30.938489] CPU 3 Unable to handle kernel paging request at virtual address fffffffffd814de0, era == ffff800002009fb8, ra == ffff800002009f9c
[ 30.939331] Oops[#1]:
[ 30.939513] CPU: 3 PID: 1260 Comm: test_progs Not tainted 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6
[ 30.939732] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
[ 30.939901] pc ffff800002009fb8 ra ffff800002009f9c tp 9000000104da4000 sp 9000000104da7ab0
[ 30.940038] a0 fffffffffd814de0 a1 9000000104da7a68 a2 0000000000000000 a3 9000000104da7c10
[ 30.940183] a4 9000000104da7c14 a5 0000000000000002 a6 0000000000000021 a7 00005555904d7f90
[ 30.940321] t0 0000000000000110 t1 0000000000000000 t2 fffffffffd814de0 t3 0004c4b400000000
[ 30.940456] t4 ffffffffffffffff t5 00000000c3f63600 t6 0000000000000000 t7 0000000000000000
[ 30.940590] t8 000000000006d803 u0 0000000000000020 s9 9000000104da7b10 s0 900000010504c200
[ 30.940727] s1 fffffffffd814de0 s2 900000010504c200 s3 9000000104da7c10 s4 9000000104da7ad0
[ 30.940866] s5 0000000000000000 s6 90000000030e65bc s7 9000000104da7b44 s8 90000000044f6fc0
[ 30.941015] ra: ffff800002009f9c bpf_prog_846803e5ae81417f_cls_redirect+0xa0/0x590
[ 30.941535] ERA: ffff800002009fb8 bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
[ 30.941696] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[ 30.942224] PRMD: 00000004 (PPLV0 +PIE -PWE)
[ 30.942330] EUEN: 00000003 (+FPE +SXE -ASXE -BTE)
[ 30.942453] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
[ 30.942612] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
[ 30.942764] BADV: fffffffffd814de0
[ 30.942854] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
[ 30.942974] Modules linked in:
[ 30.943078] Process test_progs (pid: 1260, threadinfo=00000000ce303226, task=000000007d10bb76)
[ 30.943306] Stack : 900000010a064000 90000000044f6fc0 9000000104da7b48 0000000000000000
[ 30.943495] 0000000000000000 9000000104da7c14 9000000104da7c10 900000010504c200
[ 30.943626] 0000000000000001 ffff80001b88c000 9000000104da7b70 90000000030e6668
[ 30.943785] 0000000000000000 9000000104da7b58 ffff80001b88c048 9000000003d05000
[ 30.943936] 900000000303ac88 0000000000000000 0000000000000000 9000000104da7b70
[ 30.944091] 0000000000000000 0000000000000001 0000000731eeab00 0000000000000000
[ 30.944245] ffff80001b88c000 0000000000000000 0000000000000000 54b99959429f83b8
[ 30.944402] ffff80001b88c000 90000000044f6fc0 9000000101d70000 ffff80001b88c000
[ 30.944538] 000000000000005a 900000010504c200 900000010a064000 900000010a067000
[ 30.944697] 9000000104da7d88 0000000000000000 9000000003d05000 90000000030e794c
[ 30.944852] ...
[ 30.944924] Call Trace:
[ 30.945120] [<ffff800002009fb8>] bpf_prog_846803e5ae81417f_cls_redirect+0xbc/0x590
[ 30.945650] [<90000000030e6668>] bpf_test_run+0x1ec/0x2f8
[ 30.945958] [<90000000030e794c>] bpf_prog_test_run_skb+0x31c/0x684
[ 30.946065] [<90000000026d4f68>] __sys_bpf+0x678/0x2724
[ 30.946159] [<90000000026d7288>] sys_bpf+0x20/0x2c
[ 30.946253] [<90000000032dd224>] do_syscall+0x7c/0x94
[ 30.946343] [<9000000002541c5c>] handle_syscall+0xbc/0x158
[ 30.946492]
[ 30.946549] Code: 0015030e 5c0009c0 5001d000 <28c00304> 02c00484 29c00304 00150009 2a42d2e4 0280200d
[ 30.946793]
[ 30.946971] ---[ end trace 0000000000000000 ]---
[ 32.093225] Kernel panic - not syncing: Fatal exception in interrupt
[ 32.093526] Kernel relocated by 0x2320000
[ 32.093630] .text @ 0x9000000002520000
[ 32.093725] .data @ 0x9000000003400000
[ 32.093792] .bss @ 0x9000000004413200
[ 34.971998] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
This is because we signed-extend function return values. When subprog
mode is enabled, we have:
cls_redirect()
-> get_global_metrics() returns pcpu ptr 0xfffffefffc00b480
The pointer returned is later signed-extended to 0xfffffffffc00b480 at
`BPF_JMP | BPF_EXIT`. During BPF prog run, this triggers unhandled page
fault and a kernel panic.
Drop the unnecessary signed-extension on return values like other
architectures do.
With this change, we have:
# ./test_progs -t cls_redirect
Can't find bpf_testmod.ko kernel module: -2
WARNING! Selftests relying on bpf_testmod.ko will be skipped.
#51/1 cls_redirect/cls_redirect_inlined:OK
#51/2 cls_redirect/IPv4 TCP accept unknown (no hops, flags: SYN):OK
#51/3 cls_redirect/IPv6 TCP accept unknown (no hops, flags: SYN):OK
#51/4 cls_redirect/IPv4 TCP accept unknown (no hops, flags: ACK):OK
#51/5 cls_redirect/IPv6 TCP accept unknown (no hops, flags: ACK):OK
#51/6 cls_redirect/IPv4 TCP forward unknown (one hop, flags: ACK):OK
#51/7 cls_redirect/IPv6 TCP forward unknown (one hop, flags: ACK):OK
#51/8 cls_redirect/IPv4 TCP accept known (one hop, flags: ACK):OK
#51/9 cls_redirect/IPv6 TCP accept known (one hop, flags: ACK):OK
#51/10 cls_redirect/IPv4 UDP accept unknown (no hops, flags: none):OK
#51/11 cls_redirect/IPv6 UDP accept unknown (no hops, flags: none):OK
#51/12 cls_redirect/IPv4 UDP forward unknown (one hop, flags: none):OK
#51/13 cls_redirect/IPv6 UDP forward unknown (one hop, flags: none):OK
#51/14 cls_redirect/IPv4 UDP accept known (one hop, flags: none):OK
#51/15 cls_redirect/IPv6 UDP accept known (one hop, flags: none):OK
#51/16 cls_redirect/cls_redirect_subprogs:OK
#51/17 cls_redirect/IPv4 TCP accept unknown (no hops, flags: SYN):OK
#51/18 cls_redirect/IPv6 TCP accept unknown (no hops, flags: SYN):OK
#51/19 cls_redirect/IPv4 TCP accept unknown (no hops, flags: ACK):OK
#51/20 cls_redirect/IPv6 TCP accept unknown (no hops, flags: ACK):OK
#51/21 cls_redirect/IPv4 TCP forward unknown (one hop, flags: ACK):OK
#51/22 cls_redirect/IPv6 TCP forward unknown (one hop, flags: ACK):OK
#51/23 cls_redirect/IPv4 TCP accept known (one hop, flags: ACK):OK
#51/24 cls_redirect/IPv6 TCP accept known (one hop, flags: ACK):OK
#51/25 cls_redirect/IPv4 UDP accept unknown (no hops, flags: none):OK
#51/26 cls_redirect/IPv6 UDP accept unknown (no hops, flags: none):OK
#51/27 cls_redirect/IPv4 UDP forward unknown (one hop, flags: none):OK
#51/28 cls_redirect/IPv6 UDP forward unknown (one hop, flags: none):OK
#51/29 cls_redirect/IPv4 UDP accept known (one hop, flags: none):OK
#51/30 cls_redirect/IPv6 UDP accept known (one hop, flags: none):OK
#51/31 cls_redirect/cls_redirect_dynptr:OK
#51/32 cls_redirect/IPv4 TCP accept unknown (no hops, flags: SYN):OK
#51/33 cls_redirect/IPv6 TCP accept unknown (no hops, flags: SYN):OK
#51/34 cls_redirect/IPv4 TCP accept unknown (no hops, flags: ACK):OK
#51/35 cls_redirect/IPv6 TCP accept unknown (no hops, flags: ACK):OK
#51/36 cls_redirect/IPv4 TCP forward unknown (one hop, flags: ACK):OK
#51/37 cls_redirect/IPv6 TCP forward unknown (one hop, flags: ACK):OK
#51/38 cls_redirect/IPv4 TCP accept known (one hop, flags: ACK):OK
#51/39 cls_redirect/IPv6 TCP accept known (one hop, flags: ACK):OK
#51/40 cls_redirect/IPv4 UDP accept unknown (no hops, flags: none):OK
#51/41 cls_redirect/IPv6 UDP accept unknown (no hops, flags: none):OK
#51/42 cls_redirect/IPv4 UDP forward unknown (one hop, flags: none):OK
#51/43 cls_redirect/IPv6 UDP forward unknown (one hop, flags: none):OK
#51/44 cls_redirect/IPv4 UDP accept known (one hop, flags: none):OK
#51/45 cls_redirect/IPv6 UDP accept known (one hop, flags: none):OK
#51 cls_redirect:OK
Summary: 1/45 PASSED, 0 SKIPPED, 0 FAILED
Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support")
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
The `cgrp_local_storage` test triggers a kernel panic like:
# ./test_progs -t cgrp_local_storage
Can't find bpf_testmod.ko kernel module: -2
WARNING! Selftests relying on bpf_testmod.ko will be skipped.
[ 550.930632] CPU 1 Unable to handle kernel paging request at virtual address 0000000000000080, era == ffff80000200be34, ra == ffff80000200be00
[ 550.931781] Oops[#1]:
[ 550.931966] CPU: 1 PID: 1303 Comm: test_progs Not tainted 6.7.0-rc2-loong-devel-g2f56bb0d2327 #35 a896aca3f4164f09cc346f89f2e09832e07be5f6
[ 550.932215] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
[ 550.932403] pc ffff80000200be34 ra ffff80000200be00 tp 9000000108350000 sp 9000000108353dc0
[ 550.932545] a0 0000000000000000 a1 0000000000000517 a2 0000000000000118 a3 00007ffffbb15558
[ 550.932682] a4 00007ffffbb15620 a5 90000001004e7700 a6 0000000000000021 a7 0000000000000118
[ 550.932824] t0 ffff80000200bdc0 t1 0000000000000517 t2 0000000000000517 t3 00007ffff1c06ee0
[ 550.932961] t4 0000555578ae04d0 t5 fffffffffffffff8 t6 0000000000000004 t7 0000000000000020
[ 550.933097] t8 0000000000000040 u0 00000000000007b8 s9 9000000108353e00 s0 90000001004e7700
[ 550.933241] s1 9000000004005000 s2 0000000000000001 s3 0000000000000000 s4 0000555555eb2ec8
[ 550.933379] s5 00007ffffbb15bb8 s6 00007ffff1dafd60 s7 000055555663f610 s8 00007ffff1db0050
[ 550.933520] ra: ffff80000200be00 bpf_prog_98f1b9e767be2a84_on_enter+0x40/0x200
[ 550.933911] ERA: ffff80000200be34 bpf_prog_98f1b9e767be2a84_on_enter+0x74/0x200
[ 550.934105] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[ 550.934596] PRMD: 00000004 (PPLV0 +PIE -PWE)
[ 550.934712] EUEN: 00000003 (+FPE +SXE -ASXE -BTE)
[ 550.934836] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)
[ 550.934976] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
[ 550.935097] BADV: 0000000000000080
[ 550.935181] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
[ 550.935291] Modules linked in:
[ 550.935391] Process test_progs (pid: 1303, threadinfo=000000006c3b1c41, task=0000000061f84a55)
[ 550.935643] Stack : 00007ffffbb15bb8 0000555555eb2ec8 0000000000000000 0000000000000001
[ 550.935844] 9000000004005000 ffff80001b864000 00007ffffbb15450 90000000029aa034
[ 550.935990] 0000000000000000 9000000108353ec0 0000000000000118 d07d9dfb09721a09
[ 550.936175] 0000000000000001 0000000000000000 9000000108353ec0 0000000000000118
[ 550.936314] 9000000101d46ad0 900000000290abf0 000055555663f610 0000000000000000
[ 550.936479] 0000000000000003 9000000108353ec0 00007ffffbb15450 90000000029d7288
[ 550.936635] 00007ffff1dafd60 000055555663f610 0000000000000000 0000000000000003
[ 550.936779] 9000000108353ec0 90000000035dd1f0 00007ffff1dafd58 9000000002841c5c
[ 550.936939] 0000000000000119 0000555555eea5a8 00007ffff1d78780 00007ffffbb153e0
[ 550.937083] ffffffffffffffda 00007ffffbb15518 0000000000000040 00007ffffbb15558
[ 550.937224] ...
[ 550.937299] Call Trace:
[ 550.937521] [<ffff80000200be34>] bpf_prog_98f1b9e767be2a84_on_enter+0x74/0x200
[ 550.937910] [<90000000029aa034>] bpf_trace_run2+0x90/0x154
[ 550.938105] [<900000000290abf0>] syscall_trace_enter.isra.0+0x1cc/0x200
[ 550.938224] [<90000000035dd1f0>] do_syscall+0x48/0x94
[ 550.938319] [<9000000002841c5c>] handle_syscall+0xbc/0x158
[ 550.938477]
[ 550.938607] Code: 580009ae 50016000 262402e4 <28c20085> 14092084 03a00084 16000024 03240084 00150006
[ 550.938851]
[ 550.939021] ---[ end trace 0000000000000000 ]---
Further investigation shows that this panic is triggered by memory
load operations:
ptr = bpf_cgrp_storage_get(&map_a, task->cgroups->dfl_cgrp, 0,
BPF_LOCAL_STORAGE_GET_F_CREATE);
The expression `task->cgroups->dfl_cgrp` involves two memory load.
Since the field offset fits in imm12 or imm14, we use ldd or ldptrd
instructions. But both instructions have the side effect that it will
signed-extended the imm operand. Finally, we got the wrong addresses
and panics is inevitable.
Use a generic ldxd instruction to avoid this kind of issues.
With this change, we have:
# ./test_progs -t cgrp_local_storage
Can't find bpf_testmod.ko kernel module: -2
WARNING! Selftests relying on bpf_testmod.ko will be skipped.
test_cgrp_local_storage:PASS:join_cgroup /cgrp_local_storage 0 nsec
#48/1 cgrp_local_storage/tp_btf:OK
test_attach_cgroup:PASS:skel_open 0 nsec
test_attach_cgroup:PASS:prog_attach 0 nsec
test_attach_cgroup:PASS:prog_attach 0 nsec
libbpf: prog 'update_cookie_tracing': failed to attach: ERROR: strerror_r(-524)=22
test_attach_cgroup:FAIL:prog_attach unexpected error: -524
#48/2 cgrp_local_storage/attach_cgroup:FAIL
test_recursion:PASS:skel_open_and_load 0 nsec
libbpf: prog 'on_lookup': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'on_lookup': failed to auto-attach: -524
test_recursion:FAIL:skel_attach unexpected error: -524 (errno 524)
#48/3 cgrp_local_storage/recursion:FAIL
#48/4 cgrp_local_storage/negative:OK
#48/5 cgrp_local_storage/cgroup_iter_sleepable:OK
test_yes_rcu_lock:PASS:skel_open 0 nsec
test_yes_rcu_lock:PASS:skel_load 0 nsec
libbpf: prog 'yes_rcu_lock': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'yes_rcu_lock': failed to auto-attach: -524
test_yes_rcu_lock:FAIL:skel_attach unexpected error: -524 (errno 524)
#48/6 cgrp_local_storage/yes_rcu_lock:FAIL
#48/7 cgrp_local_storage/no_rcu_lock:OK
#48 cgrp_local_storage:FAIL
All error logs:
test_cgrp_local_storage:PASS:join_cgroup /cgrp_local_storage 0 nsec
test_attach_cgroup:PASS:skel_open 0 nsec
test_attach_cgroup:PASS:prog_attach 0 nsec
test_attach_cgroup:PASS:prog_attach 0 nsec
libbpf: prog 'update_cookie_tracing': failed to attach: ERROR: strerror_r(-524)=22
test_attach_cgroup:FAIL:prog_attach unexpected error: -524
#48/2 cgrp_local_storage/attach_cgroup:FAIL
test_recursion:PASS:skel_open_and_load 0 nsec
libbpf: prog 'on_lookup': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'on_lookup': failed to auto-attach: -524
test_recursion:FAIL:skel_attach unexpected error: -524 (errno 524)
#48/3 cgrp_local_storage/recursion:FAIL
test_yes_rcu_lock:PASS:skel_open 0 nsec
test_yes_rcu_lock:PASS:skel_load 0 nsec
libbpf: prog 'yes_rcu_lock': failed to attach: ERROR: strerror_r(-524)=22
libbpf: prog 'yes_rcu_lock': failed to auto-attach: -524
test_yes_rcu_lock:FAIL:skel_attach unexpected error: -524 (errno 524)
#48/6 cgrp_local_storage/yes_rcu_lock:FAIL
#48 cgrp_local_storage:FAIL
Summary: 0/4 PASSED, 0 SKIPPED, 1 FAILED
No panics any more (The test still failed because lack of BPF trampoline
which I am actively working on).
Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support")
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Currently, we store syscall nr in pt_regs::regs[11] and syscall execve()
accidentally overrides it during its execution:
sys_execve()
-> do_execve()
-> do_execveat_common()
-> bprm_execve()
-> exec_binprm()
-> search_binary_handler()
-> load_elf_binary()
-> ELF_PLAT_INIT()
ELF_PLAT_INIT() reset regs[11] to 0, so in syscall_exit_to_user_mode()
we later get a wrong syscall nr. This breaks tools like execsnoop since
it relies on execve() tracepoints.
Skip pt_regs::regs[11] reset in ELF_PLAT_INIT() to fix the issue.
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
During unwinding, unwind_done() is used as an end condition. Normally it
unwind to the user stack and then set the stack type to unknown, which
is a normal exit. When something unexpected happens in unwind process
and we cannot unwind anymore, we should set the error flag, and also set
the stack type to unknown to indicate that the unwind process can not
continue. The error flag emphasizes that the unwind process produce an
unexpected error. There is no unexpected things when we unwind the PT_REGS
in the top of IRQ stack and find out that is an user mode PT_REGS. Thus,
we should not set error flag and just set stack type to unknown.
Reported-by: Hengqi Chen <hengqi.chen@gmail.com>
Acked-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|