aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-10-19drm: xlnx: zynqmp_dpsub: Move CRTC to zynqmp_dpsub structureLaurent Pinchart2-11/+12
Decouple the zynqmp_disp, which handles the hardware configuration, from the DRM CRTC by moving the CRTC to the zynqmp_dpsub structure. The CRTC handling code will be moved to a separate file in a subsequent step. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Move audio clk from zynqmp_disp to zynqmp_dpsubLaurent Pinchart5-60/+65
The audio clock is an external resource from the DPSUB point of view, not a resource internal to the display controller. Move it to the zynqmp_dpsub structure, to allow accessing it from outside the disp code. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Move pclk from zynqmp_disp to zynqmp_dpsubLaurent Pinchart3-29/+28
The video clock is an external resource from the DPSUB point of view, not a resource internal to the display controller. Move it to the zynqmp_dpsub structure, to allow accessing it from outside the disp code. While at it, rename the fields from pclk and pclk_from_ps to vid_clk and vid_clk_from_ps, to better reflect their purpose and match the documentation. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Don't use drmm_kcalloc() for temporary dataLaurent Pinchart1-11/+34
The array of formats passed to drm_universal_plane_init() doesn't need to outlive the function call, as it's copied internally. Use kcalloc() instead of drmm_kcalloc() to allocate it, and free it right after usage. While at it, move the allocation and initialization of the formats array to a separate function, to prepare for splitting the DRM plane handling to a separate file. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Remplace hardcoded values with ARRAY_SIZE()Laurent Pinchart1-4/+4
Use the ARRAY_SIZE() macro to iterate over arrays, instead of hardcoding their size. This makes the code less error-prone should the array size change. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Pass format info to zynqmp_disp_layer_set_format()Laurent Pinchart1-6/+4
The zynqmp_disp_layer_set_format() function only needs format information, not a full plane state. Get the necessary info from the plane state in the caller and pass it to zynqmp_disp_layer_set_format(). This prepares for calling the function from non-DRM code. This doesn't introduce any functional change. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Use local variable in zynqmp_disp_layer_update()Laurent Pinchart1-1/+1
Reuse the local info variable instead of going through the layer pointer in zynqmp_disp_layer_update(). This doesn't introduce any functional change. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Configure blender in zynqmp_disp_enable()Laurent Pinchart1-3/+3
To prepare for control of the blender outside of the CRTC code, move the setup of the blender to the zynqmp_disp_enable() function. This doesn't introduce any functional change. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Don't pass CRTC to zynqmp_disp_setup_clock()Laurent Pinchart1-10/+8
To prepare for usage of the clock setup function outside of the CRTC code, replace the DRM-specific structures passed as parameters with a pointer to the zynqmp_disp and the requested clock rate. This doesn't introduce any functional change. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Drop unused zynqmp_disp_format.bus_fmt fieldLaurent Pinchart1-2/+0
The bus_fmt field of the zynqmp_disp_format structure is unused. Drop it. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Drop unused zynqmp_disp.event fieldLaurent Pinchart1-3/+0
The event field of the zynqmp_disp structure is unused. Drop it. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Report HPD through the bridgeLaurent Pinchart1-6/+5
Now that the driver uses the connector bridge helper, HPD can be reported directly for the connector through the drm_bridge_hpd_notify() function. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Use DRM connector bridge helperLaurent Pinchart2-90/+20
Replace the manual connector implementation and registration in the DP encoder with the DRM connector bridge helper. This removes boilerplate code and simplifies the driver. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Attach to the next bridgeLaurent Pinchart1-0/+18
The next component in the display chain, after the DP encoder, is most likely a DP connector. The display connector driver registers a bridge for it. That bridge doesn't need to be controlled, but is needed in order to use the DRM connector bridge helper. Retrieve it at init time, and attach to it in the DP bridge attach handler. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Move encoder to DPSUB coreLaurent Pinchart3-78/+25
As part of the transitition of the DP encoder to a DRM bridge, turn the DRM encoder into a dummy encoder and move it out of the DP code, to the DPSUB core. DP encoder operations are handled by the DP bridge, which is now attached to the encoder. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Move connector registration to bridge attachLaurent Pinchart1-13/+24
Connector creation requires the DRM encoder, and it thus typically performed in the bridge attach operation. Move it there, to prepare for registration of the DRM bridge. For now the zynqmp_dp_bridge_attach() is called manually at initialization time. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Don't access connector in zynqmp_dp_set_format()Laurent Pinchart1-7/+8
To prepare for the removal of the connector from the DP encoder, pass the display info pointer to the zynqmp_dp_set_format() function instead of accessing the connector internally. The display info is NULL when the function is called at initialization time, as we have no display info at that point. This doesn't change the existing behaviour, given that the zynqmp_dp_set_format() was already handling this as a special case (the display info isn't initialized at init time and is all zeroes). Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Create DRM bridge to model DP encoderLaurent Pinchart1-108/+225
The DP encoder is currently modelled as a DRM encoder and DRM connector. This doesn't support system configurations where the DP encoder is driven by the FPGA programmable logic, using the live video input to the DP subsystem. To enable such use cases, we need to model the encoder as a DRM bridge. As a first step, create a DRM bridge in the DP encoder driver. Move and delegate the implementation of the DRM encoder and connector operations to the bridge to prepare for the transition. The bridge will be registered with the DRM core as a separate change. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Constify mode argument to functionLaurent Pinchart1-1/+1
The zynqmp_dp_encoder_mode_set_transfer_unit() function takes a mode pointer argument that it doesn't need to modify. Make it const. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19drm: xlnx: zynqmp_dpsub: Switch to atomic encoder enable/disableLaurent Pinchart1-4/+6
To prepare for the transition to the DRM bridge API, switch the encoder operations to the atomic versions of .enable() and .disable(). This doesn't cause any functional change by itself. Signed-off-by: Laurent Pinchart <[email protected]>
2022-10-19dt-bindings: display: xlnx: zynqmp-dpsub: Add OF graph portsLaurent Pinchart1-0/+67
The DPSUB doesn't live in isolation, but is connected to the programmable logic for live inputs and outputs, and also has a DisplayPort output. Model all those using OF graph. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Rob Herring <[email protected]>
2022-10-19Merge branch 'qdisc-ingress-success'David S. Miller3-0/+84
Paul Blakey says: ==================== net: Fix return value of qdisc ingress handling on success Fix patch + self-test with the currently broken scenario. v4->v3: Removed new line in self test and rebase (Paolo). v2->v3: Added DROP return to TC_ACT_SHOT case (Cong). v1->v2: Changed blamed commit Added self-test ==================== Signed-off-by: David S. Miller <[email protected]>
2022-10-19selftests: add selftest for chaining of tc ingress handling to egressPaul Blakey2-0/+80
This test runs a simple ingress tc setup between two veth pairs, then adds a egress->ingress rule to test the chaining of tc ingress pipeline to tc egress piepline. Signed-off-by: Paul Blakey <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-10-19net: Fix return value of qdisc ingress handling on successPaul Blakey1-0/+4
Currently qdisc ingress handling (sch_handle_ingress()) doesn't set a return value and it is left to the old return value of the caller (__netif_receive_skb_core()) which is RX drop, so if the packet is consumed, caller will stop and return this value as if the packet was dropped. This causes a problem in the kernel tcp stack when having a egress tc rule forwarding to a ingress tc rule. The tcp stack sending packets on the device having the egress rule will see the packets as not successfully transmitted (although they actually were), will not advance it's internal state of sent data, and packets returning on such tcp stream will be dropped by the tcp stack with reason ack-of-unsent-data. See reproduction in [0] below. Fix that by setting the return value to RX success if the packet was handled successfully. [0] Reproduction steps: $ ip link add veth1 type veth peer name peer1 $ ip link add veth2 type veth peer name peer2 $ ifconfig peer1 5.5.5.6/24 up $ ip netns add ns0 $ ip link set dev peer2 netns ns0 $ ip netns exec ns0 ifconfig peer2 5.5.5.5/24 up $ ifconfig veth2 0 up $ ifconfig veth1 0 up #ingress forwarding veth1 <-> veth2 $ tc qdisc add dev veth2 ingress $ tc qdisc add dev veth1 ingress $ tc filter add dev veth2 ingress prio 1 proto all flower \ action mirred egress redirect dev veth1 $ tc filter add dev veth1 ingress prio 1 proto all flower \ action mirred egress redirect dev veth2 #steal packet from peer1 egress to veth2 ingress, bypassing the veth pipe $ tc qdisc add dev peer1 clsact $ tc filter add dev peer1 egress prio 20 proto ip flower \ action mirred ingress redirect dev veth1 #run iperf and see connection not running $ iperf3 -s& $ ip netns exec ns0 iperf3 -c 5.5.5.6 -i 1 #delete egress rule, and run again, now should work $ tc filter del dev peer1 egress $ ip netns exec ns0 iperf3 -c 5.5.5.6 -i 1 Fixes: f697c3e8b35c ("[NET]: Avoid unnecessary cloning for ingress filtering") Signed-off-by: Paul Blakey <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-10-19Merge branch 'qdisc-null-deref'David S. Miller3-9/+23
Zhengchao Shao says: ==================== net: fix null pointer access issue in qdisc These three patches fix the same type of problem. Set the default qdisc, and then construct an init failure scenario when the dev qdisc is configured on mqprio to trigger the reset process. NULL pointer access may occur during the reset process. --- v2: for fq_codel, revert the patch --- ==================== Signed-off-by: David S. Miller <[email protected]>
2022-10-19net: sched: sfb: fix null pointer access issue when sfb_init() failsZhengchao Shao1-1/+2
When the default qdisc is sfb, if the qdisc of dev_queue fails to be inited during mqprio_init(), sfb_reset() is invoked to clear resources. In this case, the q->qdisc is NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() sfb_init() tcf_block_get() --->failed, q->qdisc is NULL ... qdisc_put() ... sfb_reset() qdisc_reset(q->qdisc) --->q->qdisc is NULL ops = qdisc->ops The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:qdisc_reset+0x2b/0x6f0 Call Trace: <TASK> sfb_reset+0x37/0xd0 qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0 qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000 tc_modify_qdisc+0x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100 ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f2164122d04 </TASK> Fixes: e13e02a3c68d ("net_sched: SFB flow scheduler") Signed-off-by: Zhengchao Shao <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-10-19Revert "net: sched: fq_codel: remove redundant resource cleanup in ↵Zhengchao Shao1-8/+17
fq_codel_init()" This reverts commit 494f5063b86cd6e972cb41a27e083c9a3664319d. When the default qdisc is fq_codel, if the qdisc of dev_queue fails to be inited during mqprio_init(), fq_codel_reset() is invoked to clear resources. In this case, the flow is NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() fq_codel_init() ... q->flows_cnt = 1024; ... q->flows = kvcalloc(...) --->failed, q->flows is NULL ... qdisc_put() ... fq_codel_reset() ... flow = q->flows + i --->q->flows is NULL The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:fq_codel_reset+0x14d/0x350 Call Trace: <TASK> qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0 qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000 tc_modify_qdisc+0x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100 ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fd272b22d04 </TASK> Signed-off-by: Zhengchao Shao <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-10-19net: sched: cake: fix null pointer access issue when cake_init() failsZhengchao Shao1-0/+4
When the default qdisc is cake, if the qdisc of dev_queue fails to be inited during mqprio_init(), cake_reset() is invoked to clear resources. In this case, the tins is NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() cake_init() q->tins = kvcalloc(...) --->failed, q->tins is NULL ... qdisc_put() ... cake_reset() ... cake_dequeue_one() b = &q->tins[...] --->q->tins is NULL The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:cake_dequeue_one+0xc9/0x3c0 Call Trace: <TASK> cake_reset+0xb1/0x140 qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0 qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000 tc_modify_qdisc+0x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100 ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f89e5122d04 </TASK> Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Zhengchao Shao <[email protected]> Acked-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-10-19ethernet: marvell: octeontx2 Fix resource not freed after mallocManank Patel1-0/+2
fix rxsc and txsc not getting freed before going out of scope Fixes: c54ffc73601c ("octeontx2-pf: mcs: Introduce MACSEC hardware offloading") Signed-off-by: Manank Patel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-10-19ACPI: PCI: Fix device reference counting in acpi_get_pci_dev()Rafael J. Wysocki1-0/+1
Commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") failed to reference count the device returned by acpi_get_pci_dev() as expected by its callers which in some cases may cause device objects to be dropped prematurely. Add the missing get_device() to acpi_get_pci_dev(). Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") Reported-by: Ville Syrjälä <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2022-10-19drm/amdgpu: use DRM_SCHED_FENCE_DONT_PIPELINE for VM updatesChristian König1-1/+8
Make sure that we always have a CPU round trip to let the submission code correctly decide if a TLB flush is necessary or not. Signed-off-by: Christian König <[email protected]> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2113#note_1579296 Reviewed-by: Alex Deucher <[email protected]> Acked-by: Luben Tuikov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-19nvmet: fix invalid memory reference in nvmet_subsys_attr_qid_max_showDaniel Wagner1-4/+0
The item passed into nvmet_subsys_attr_qid_max_show is not a member of struct nvmet_port, it is part of nvmet_subsys. Hence, don't try to dereference it as struct nvme_ctrl pointer. Fixes: 3e980f5995e0 ("nvmet: Expose max queues to configfs") Reported-by: Shinichiro Kawasaki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Wagner <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Acked-by: Sagi Grimberg <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-10-19nvmet: fix workqueue MEM_RECLAIM flushing dependencySagi Grimberg1-1/+1
The keep alive timer needs to stay on nvmet_wq, and not modified to reschedule on the system_wq. This fixes a warning: ------------[ cut here ]------------ workqueue: WQ_MEM_RECLAIM nvmet-wq:nvmet_rdma_release_queue_work [nvmet_rdma] is flushing !WQ_MEM_RECLAIM events:nvmet_keep_alive_timer [nvmet] WARNING: CPU: 3 PID: 1086 at kernel/workqueue.c:2628 check_flush_dependency+0x16c/0x1e0 Reported-by: Yi Zhang <[email protected]> Fixes: 8832cf922151 ("nvmet: use a private workqueue instead of the system workqueue") Signed-off-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-10-19nvme-hwmon: kmalloc the NVME SMART log bufferSerge Semin1-7/+16
Recent commit 52fde2c07da6 ("nvme: set dma alignment to dword") has caused a regression on our platform. It turned out that the nvme_get_log() method invocation caused the nvme_hwmon_data structure instance corruption. In particular the nvme_hwmon_data.ctrl pointer was overwritten either with zeros or with garbage. After some research we discovered that the problem happened even before the actual NVME DMA execution, but during the buffer mapping. Since our platform is DMA-noncoherent, the mapping implied the cache-line invalidations or write-backs depending on the DMA-direction parameter. In case of the NVME SMART log getting the DMA was performed from-device-to-memory, thus the cache-invalidation was activated during the buffer mapping. Since the log-buffer isn't cache-line aligned, the cache-invalidation caused the neighbour data to be discarded. The neighbouring data turned to be the data surrounding the buffer in the framework of the nvme_hwmon_data structure. In order to fix that we need to make sure that the whole log-buffer is defined within the cache-line-aligned memory region so the cache-invalidation procedure wouldn't involve the adjacent data. One of the option to guarantee that is to kmalloc the DMA-buffer [1]. Seeing the rest of the NVME core driver prefer that method it has been chosen to fix this problem too. Note after a deeper researches we found out that the denoted commit wasn't a root cause of the problem. It just revealed the invalidity by activating the DMA-based NVME SMART log getting performed in the framework of the NVME hwmon driver. The problem was here since the initial commit of the driver. [1] Documentation/core-api/dma-api-howto.rst Fixes: 400b6a7b13a3 ("nvme: Add hardware monitoring support") Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-10-19nvme-hwmon: consistently ignore errors from nvme_hwmon_initChristoph Hellwig2-6/+13
An NVMe controller works perfectly fine even when the hwmon initialization fails. Stop returning errors that do not come from a controller reset from nvme_hwmon_init to handle this case consistently. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Serge Semin <[email protected]>
2022-10-19drm/sched: add DRM_SCHED_FENCE_DONT_PIPELINE flagChristian König2-1/+11
Setting this flag on a scheduler fence prevents pipelining of jobs depending on this fence. In other words we always insert a full CPU round trip before dependent jobs are pushed to the pipeline. Signed-off-by: Christian König <[email protected]> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2113#note_1579296 Reviewed-by: Alex Deucher <[email protected]> Acked-by: Luben Tuikov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-19nvme: add Guenther as nvme-hwmon maintainerChristoph Hellwig1-0/+6
Given that non of the overall NVMe maintainers knows this code very deeply it probably makes sense to add Guenther as an additional MAINTAINER for it. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Acked-by: Guenter Roeck <[email protected]>
2022-10-19nvme-apple: don't limit DMA segement sizeRussell King (Oracle)1-0/+2
NVMe uses PRPs for data transfers and has no specific limit for a single DMA segement. Limiting the size will cause problems because the block layer assumes PRP-ish devices using a virt boundary mask don't have a segment limit. And while this is true, we also really need to tell the DMA mapping layer about it, otherwise dma-debug will trip over it. Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Suggested-by: Sven Peter <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> [hch: rewrote the commit message based on the PCIe commit] Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Eric Curtin <[email protected]> Reviewed-by: Sven Peter <[email protected]>
2022-10-19nvme-pci: disable write zeroes on various Kingston SSDXander Li1-0/+10
Kingston SSDs do support NVMe Write_Zeroes cmd but take long time to process. The firmware version is locked by these SSDs, we can not expect firmware improvement, so disable Write_Zeroes cmd. Signed-off-by: Xander Li <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-10-19nvme: fix error pointer dereference in error handlingDan Carpenter1-1/+1
There is typo here so it releases the wrong variable. "ctrl->admin_q" was intended instead of "ctrl->fabrics_q". Fixes: fe60e8c53411 ("nvme: add common helpers to allocate and free tagsets") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-10-19netfilter: nf_tables: relax NFTA_SET_ELEM_KEY_END set flags requirementsPablo Neira Ayuso1-2/+3
Otherwise EINVAL is bogusly reported to userspace when deleting a set element. NFTA_SET_ELEM_KEY_END does not need to be set in case of: - insertion: if not present, start key is used as end key. - deletion: only start key needs to be specified, end key is ignored. Hence, relax the sanity check. Fixes: 88cccd908d51 ("netfilter: nf_tables: NFTA_SET_ELEM_KEY_END requires concat and interval flags") Signed-off-by: Pablo Neira Ayuso <[email protected]>
2022-10-19netfilter: rpfilter/fib: Set ->flowic_uid correctly for user namespaces.Guillaume Nault4-0/+5
Currently netfilter's rpfilter and fib modules implicitely initialise ->flowic_uid with 0. This is normally the root UID. However, this isn't the case in user namespaces, where user ID 0 is mapped to a different kernel UID. By initialising ->flowic_uid with sock_net_uid(), we get the root UID of the user namespace, thus keeping the same behaviour whether or not we're running in a user namepspace. Note, this is similar to commit 8bcfd0925ef1 ("ipv4: add missing initialization for flowi4_uid"), which fixed the rp_filter sysctl. Fixes: 622ec2c9d524 ("net: core: add UID to flows, rules, and routes") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2022-10-18ionic: catch NULL pointer issue on reconfigBrett Creeley1-4/+8
It's possible that the driver will dereference a qcq that doesn't exist when calling ionic_reconfigure_queues(), which causes a page fault BUG. If a reduction in the number of queues is followed by a different reconfig such as changing the ring size, the driver can hit a NULL pointer when trying to clean up non-existent queues. Fix this by checking to make sure both the qcqs array and qcq entry exists bofore trying to use and free the entry. Fixes: 101b40a0171f ("ionic: change queue count with no reset") Signed-off-by: Brett Creeley <[email protected]> Signed-off-by: Shannon Nelson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-18net: hsr: avoid possible NULL deref in skb_clone()Eric Dumazet1-6/+6
syzbot got a crash [1] in skb_clone(), caused by a bug in hsr_get_untagged_frame(). When/if create_stripped_skb_hsr() returns NULL, we must not attempt to call skb_clone(). While we are at it, replace a WARN_ONCE() by netdev_warn_once(). [1] general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 1 PID: 754 Comm: syz-executor.0 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 RIP: 0010:skb_clone+0x108/0x3c0 net/core/skbuff.c:1641 Code: 93 02 00 00 49 83 7c 24 28 00 0f 85 e9 00 00 00 e8 5d 4a 29 fa 4c 8d 75 7e 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 4c 89 f2 83 e2 07 38 d0 7f 08 84 c0 0f 85 9e 01 00 00 RSP: 0018:ffffc90003ccf4e0 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: ffffc90003ccf5f8 RCX: ffffc9000c24b000 RDX: 000000000000000f RSI: ffffffff8751cb13 RDI: 0000000000000000 RBP: 0000000000000000 R08: 00000000000000f0 R09: 0000000000000140 R10: fffffbfff181d972 R11: 0000000000000000 R12: ffff888161fc3640 R13: 0000000000000a20 R14: 000000000000007e R15: ffffffff8dc5f620 FS: 00007feb621e4700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb621e3ff8 CR3: 00000001643a9000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> hsr_get_untagged_frame+0x4e/0x610 net/hsr/hsr_forward.c:164 hsr_forward_do net/hsr/hsr_forward.c:461 [inline] hsr_forward_skb+0xcca/0x1d50 net/hsr/hsr_forward.c:623 hsr_handle_frame+0x588/0x7c0 net/hsr/hsr_slave.c:69 __netif_receive_skb_core+0x9fe/0x38f0 net/core/dev.c:5379 __netif_receive_skb_one_core+0xae/0x180 net/core/dev.c:5483 __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5599 netif_receive_skb_internal net/core/dev.c:5685 [inline] netif_receive_skb+0x12f/0x8d0 net/core/dev.c:5744 tun_rx_batched+0x4ab/0x7a0 drivers/net/tun.c:1544 tun_get_user+0x2686/0x3a00 drivers/net/tun.c:1995 tun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2025 call_write_iter include/linux/fs.h:2187 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x9e9/0xdd0 fs/read_write.c:584 ksys_write+0x127/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: f266a683a480 ("net/hsr: Better frame dispatch") Reported-by: syzbot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-18bnxt_en: fix memory leak in bnxt_nvm_test()Vikas Gupta1-5/+6
Free the kzalloc'ed buffer before returning in the success path. Fixes: 5b6ff128fdf6 ("bnxt_en: implement callbacks for devlink selftests") Signed-off-by: Vikas Gupta <[email protected]> Signed-off-by: Michael Chan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-18drm/amdgpu: Fix for BO move issueArunpravin Paneer Selvam1-0/+3
A user reported a bug on CAPE VERDE system where uvd_v3_1 IP component failed to initialize as there is an issue with BO move code from one memory to other. In function amdgpu_mem_visible() called by amdgpu_bo_move(), when there are no blocks to compare or if we have a single block then break the loop. Fixes: 312b4dc11d4f ("drm/amdgpu: Fix VRAM BO swap issue") Signed-off-by: Arunpravin Paneer Selvam <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2022-10-18drm/amdgpu: dequeue mes scheduler during finiYuBiao Wang1-3/+39
[Why] If mes is not dequeued during fini, mes will be in an uncleaned state during reload, then mes couldn't receive some commands which leads to reload failure. [How] Perform MES dequeue via MMIO after all the unmap jobs are done by mes and before kiq fini. v2: Move the dequeue operation inside kiq_hw_fini. Signed-off-by: YuBiao Wang <[email protected]> Reviewed-by: Jack Xiao <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2022-10-18drm/amd/pm: enable thermal alert on smu_v13_0_10Kenneth Feng1-6/+4
enable thermal alert on smu_v13_0_10 Signed-off-by: Kenneth Feng <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2022-10-18drm/amdgpu: Program GC registers through RLCG interface in gfx_v11/gmc_v11Yifan Zha3-9/+13
[Why] L1 blocks most of GC registers accessing by MMIO. [How] Use RLCG interface to program GC registers under SRIOV VF in full access time. Signed-off-by: Yifan Zha <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2022-10-18drm/amdkfd: Fix type of reset_type parameter in hqd_destroy() callbackNathan Chancellor1-2/+3
When booting a kernel compiled with CONFIG_CFI_CLANG on a machine with an RX 6700 XT, there is a CFI failure in kfd_destroy_mqd_cp(): [ 12.894543] CFI failure at kfd_destroy_mqd_cp+0x2a/0x40 [amdgpu] (target: hqd_destroy_v10_3+0x0/0x260 [amdgpu]; expected type: 0x8594d794) Clang's kernel Control Flow Integrity (kCFI) makes sure that all indirect call targets have a type that exactly matches the function pointer prototype. In this case, hqd_destroy()'s third parameter, reset_type, should have a type of 'uint32_t' but every implementation of this callback has a third parameter type of 'enum kfd_preempt_type'. Update the function pointer prototype to match reality so that there is no more CFI violation. Link: https://github.com/ClangBuiltLinux/linux/issues/1738 Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.