From: Gurchetan Singh <gurchetansingh(a)chromium.org>
We don't want to create a fence for every command submission. It's
only necessary when userspace provides a waitable token for submission.
This could be:
1) bo_handles, to be used with VIRTGPU_WAIT
2) out_fence_fd, to be used with dma_fence apis
3) a ring_idx provided with VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK
+ DRM event API
4) syncobjs in the future
The use case for just submitting a command to the host, and expecting
no response. For example, gfxstream has GFXSTREAM_CONTEXT_PING that
just wakes up the host side worker threads. There's also
CROSS_DOMAIN_CMD_SEND which just sends data to the Wayland server.
This prevents the need to signal the automatically created
virtio_gpu_fence.
In addition, VIRTGPU_EXECBUF_RING_IDX is checked when creating a
DRM event object. VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is
already defined in terms of per-context rings. It was theoretically
possible to create a DRM event on the global timeline (ring_idx == 0),
if the context enabled DRM event polling. However, that wouldn't
work and userspace (Sommelier). Explicitly disallow it for
clarity.
Signed-off-by: Gurchetan Singh <gurchetansingh(a)chromium.org>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> # edited coding style
Link: https://patchwork.freedesktop.org/patch/msgid/20230707213124.494-1-gurcheta…
(cherry picked from commit 70d1ace56db6c79d39dbe9c0d5244452b67e2fde)
Signed-off-by: Alyssa Ross <hi(a)alyssa.is>
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 30 +++++++++++++++-----------
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index da45215a933d..bc8c1e9a845f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -43,13 +43,9 @@ static int virtio_gpu_fence_event_create(struct drm_device *dev,
struct virtio_gpu_fence *fence,
uint32_t ring_idx)
{
- struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
struct virtio_gpu_fence_event *e = NULL;
int ret;
- if (!(vfpriv->ring_idx_mask & BIT_ULL(ring_idx)))
- return 0;
-
e = kzalloc(sizeof(*e), GFP_KERNEL);
if (!e)
return -ENOMEM;
@@ -121,6 +117,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
struct virtio_gpu_fence *out_fence;
+ bool drm_fence_event;
int ret;
uint32_t *bo_handles = NULL;
void __user *user_bo_handles = NULL;
@@ -216,15 +213,24 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
goto out_memdup;
}
- out_fence = virtio_gpu_fence_alloc(vgdev, fence_ctx, ring_idx);
- if(!out_fence) {
- ret = -ENOMEM;
- goto out_unresv;
- }
+ if ((exbuf->flags & VIRTGPU_EXECBUF_RING_IDX) &&
+ (vfpriv->ring_idx_mask & BIT_ULL(ring_idx)))
+ drm_fence_event = true;
+ else
+ drm_fence_event = false;
- ret = virtio_gpu_fence_event_create(dev, file, out_fence, ring_idx);
- if (ret)
- goto out_unresv;
+ if ((exbuf->flags & VIRTGPU_EXECBUF_FENCE_FD_OUT) ||
+ exbuf->num_bo_handles ||
+ drm_fence_event)
+ out_fence = virtio_gpu_fence_alloc(vgdev, fence_ctx, ring_idx);
+ else
+ out_fence = NULL;
+
+ if (drm_fence_event) {
+ ret = virtio_gpu_fence_event_create(dev, file, out_fence, ring_idx);
+ if (ret)
+ goto out_unresv;
+ }
if (out_fence_fd >= 0) {
sync_file = sync_file_create(&out_fence->f);
base-commit: f60d5fd5e950c89a38578ae6f25877de511bb031
--
2.41.0
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
git checkout FETCH_HEAD
git cherry-pick -x 669281ee7ef731fb5204df9d948669bf32a5e68d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023090959-mothproof-scarf-6195@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
Possible dependencies:
669281ee7ef7 ("Multi-gen LRU: fix per-zone reclaim")
6df1b2212950 ("mm: multi-gen LRU: rename lrugen->lists[] to lrugen->folios[]")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 669281ee7ef731fb5204df9d948669bf32a5e68d Mon Sep 17 00:00:00 2001
From: Kalesh Singh <kaleshsingh(a)google.com>
Date: Tue, 1 Aug 2023 19:56:02 -0700
Subject: [PATCH] Multi-gen LRU: fix per-zone reclaim
MGLRU has a LRU list for each zone for each type (anon/file) in each
generation:
long nr_pages[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES];
The min_seq (oldest generation) can progress independently for each
type but the max_seq (youngest generation) is shared for both anon and
file. This is to maintain a common frame of reference.
In order for eviction to advance the min_seq of a type, all the per-zone
lists in the oldest generation of that type must be empty.
The eviction logic only considers pages from eligible zones for
eviction or promotion.
scan_folios() {
...
for (zone = sc->reclaim_idx; zone >= 0; zone--) {
...
sort_folio(); // Promote
...
isolate_folio(); // Evict
}
...
}
Consider the system has the movable zone configured and default 4
generations. The current state of the system is as shown below
(only illustrating one type for simplicity):
Type: ANON
Zone DMA32 Normal Movable Device
Gen 0 0 0 4GB 0
Gen 1 0 1GB 1MB 0
Gen 2 1MB 4GB 1MB 0
Gen 3 1MB 1MB 1MB 0
Now consider there is a GFP_KERNEL allocation request (eligible zone
index <= Normal), evict_folios() will return without doing any work
since there are no pages to scan in the eligible zones of the oldest
generation. Reclaim won't make progress until triggered from a ZONE_MOVABLE
allocation request; which may not happen soon if there is a lot of free
memory in the movable zone. This can lead to OOM kills, although there
is 1GB pages in the Normal zone of Gen 1 that we have not yet tried to
reclaim.
This issue is not seen in the conventional active/inactive LRU since
there are no per-zone lists.
If there are no (not enough) folios to scan in the eligible zones, move
folios from ineligible zone (zone_index > reclaim_index) to the next
generation. This allows for the progression of min_seq and reclaiming
from the next generation (Gen 1).
Qualcomm, Mediatek and raspberrypi [1] discovered this issue independently.
[1] https://github.com/raspberrypi/linux/issues/5395
Link: https://lkml.kernel.org/r/20230802025606.346758-1-kaleshsingh@google.com
Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation")
Signed-off-by: Kalesh Singh <kaleshsingh(a)google.com>
Reported-by: Charan Teja Kalla <quic_charante(a)quicinc.com>
Reported-by: Lecopzer Chen <lecopzer.chen(a)mediatek.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> [mediatek]
Tested-by: Charan Teja Kalla <quic_charante(a)quicinc.com>
Cc: Yu Zhao <yuzhao(a)google.com>
Cc: Barry Song <baohua(a)kernel.org>
Cc: Brian Geffon <bgeffon(a)google.com>
Cc: Jan Alexander Steffens (heftig) <heftig(a)archlinux.org>
Cc: Matthias Brugger <matthias.bgg(a)gmail.com>
Cc: Oleksandr Natalenko <oleksandr(a)natalenko.name>
Cc: Qi Zheng <zhengqi.arch(a)bytedance.com>
Cc: Steven Barrett <steven(a)liquorix.net>
Cc: Suleiman Souhlal <suleiman(a)google.com>
Cc: Suren Baghdasaryan <surenb(a)google.com>
Cc: Aneesh Kumar K V <aneesh.kumar(a)linux.ibm.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 4039620d30fe..489a4fc7d9b1 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4889,7 +4889,8 @@ static int lru_gen_memcg_seg(struct lruvec *lruvec)
* the eviction
******************************************************************************/
-static bool sort_folio(struct lruvec *lruvec, struct folio *folio, int tier_idx)
+static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_control *sc,
+ int tier_idx)
{
bool success;
int gen = folio_lru_gen(folio);
@@ -4939,6 +4940,13 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, int tier_idx)
return true;
}
+ /* ineligible */
+ if (zone > sc->reclaim_idx) {
+ gen = folio_inc_gen(lruvec, folio, false);
+ list_move_tail(&folio->lru, &lrugen->folios[gen][type][zone]);
+ return true;
+ }
+
/* waiting for writeback */
if (folio_test_locked(folio) || folio_test_writeback(folio) ||
(type == LRU_GEN_FILE && folio_test_dirty(folio))) {
@@ -4987,7 +4995,8 @@ static bool isolate_folio(struct lruvec *lruvec, struct folio *folio, struct sca
static int scan_folios(struct lruvec *lruvec, struct scan_control *sc,
int type, int tier, struct list_head *list)
{
- int gen, zone;
+ int i;
+ int gen;
enum vm_event_item item;
int sorted = 0;
int scanned = 0;
@@ -5003,9 +5012,10 @@ static int scan_folios(struct lruvec *lruvec, struct scan_control *sc,
gen = lru_gen_from_seq(lrugen->min_seq[type]);
- for (zone = sc->reclaim_idx; zone >= 0; zone--) {
+ for (i = MAX_NR_ZONES; i > 0; i--) {
LIST_HEAD(moved);
int skipped = 0;
+ int zone = (sc->reclaim_idx + i) % MAX_NR_ZONES;
struct list_head *head = &lrugen->folios[gen][type][zone];
while (!list_empty(head)) {
@@ -5019,7 +5029,7 @@ static int scan_folios(struct lruvec *lruvec, struct scan_control *sc,
scanned += delta;
- if (sort_folio(lruvec, folio, tier))
+ if (sort_folio(lruvec, folio, sc, tier))
sorted += delta;
else if (isolate_folio(lruvec, folio, sc)) {
list_add(&folio->lru, list);
Hi,
We found that OVS group always selected the same bucket for different L4
flows between two given IPv6 addresses on 6.5. It was because commit
e069ba07e6c7 ("net: openvswitch: add support for l4 symmetric hashing")
introduced support for symmetric hashing and used the flow dissector,
which had a problem that it didn't incorporate transport ports when
flow label is present in IPv6 header. The bug is fixed by this commit:
a5e2151ff9d5 ("net/ipv6: SKB symmetric hash should incorporate transport ports")
Could you please backport it to 6.5.y?
Issue: https://github.com/antrea-io/antrea/issues/5457
Thanks,
Quan
On Tue, Sep 12, 2023 at 03:31:16PM +0000, Pillai, Aurabindo wrote:
> [AMD Official Use Only - General]
>
> Hi Greg,
>
> It was reverted but has been re-applied.
>
> Here is a chronological summary of what happened:
>
>
> 1. Michel bisected some major issues to "drm/amd/display: Do not set drr on pipe commit" and was revered in upstream. ". Along with that patch, "drm/amd/display: Block optimize on consecutive FAMS enables" was also reverted due to dependency.
> 2. We found that reverting these patches caused some multi monitor configurations to hang on RDNA3.
> 3. We debugged Michel's issue and merged a workaround (https://gitlab.freedesktop.org/agd5f/linux/-/commit/cc225c8af276396c3379885…
> 4. Subsequently, the two patches were reapplied (https://gitlab.freedesktop.org/agd5f/linux/-/commit/bfe1b43c1acee1251ddb091… and https://gitlab.freedesktop.org/agd5f/linux/-/commit/f3c2a89c5103b4ffdd88f09…)
>
> Hence, the stable kernel should have all 3 patches - the workaround and 2 others. Hope that clarifies the situation.
Great, what are the ids of those in Linus's tree?
thanks,
greg k-h
On 23-06-22 04:49 pm, Mathias Nyman wrote:
> From: Hongyu Xie <xy521521(a)gmail.com>
>
> irq is disabled in xhci_quiesce(called by xhci_halt, with bit:2 cleared
> in USBCMD register), but xhci_run(called by usb_add_hcd) re-enable it.
> It's possible that you will receive thousands of interrupt requests
> after initialization for 2.0 roothub. And you will get a lot of
> warning like, "xHCI dying, ignoring interrupt. Shouldn't IRQs be
> disabled?". This amount of interrupt requests will cause the entire
> system to freeze.
> This problem was first found on a device with ASM2142 host controller
> on it.
>
> [tidy up old code while moving it, reword header -Mathias]
> Cc: stable(a)kernel.org
> Signed-off-by: Hongyu Xie <xiehongyu1(a)kylinos.cn>
> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
> ---
> drivers/usb/host/xhci.c | 35 ++++++++++++++++++++++-------------
> 1 file changed, 22 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 9ac56e9ffc64..cb99bed5f755 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -611,15 +611,37 @@ static int xhci_init(struct usb_hcd *hcd)
>
> static int xhci_run_finished(struct xhci_hcd *xhci)
> {
> + unsigned long flags;
> + u32 temp;
> +
> + /*
> + * Enable interrupts before starting the host (xhci 4.2 and 5.5.2).
> + * Protect the short window before host is running with a lock
> + */
> + spin_lock_irqsave(&xhci->lock, flags);
> +
> + xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Enable interrupts");
> + temp = readl(&xhci->op_regs->command);
> + temp |= (CMD_EIE);
> + writel(temp, &xhci->op_regs->command);
> +
> + xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Enable primary interrupter");
> + temp = readl(&xhci->ir_set->irq_pending);
> + writel(ER_IRQ_ENABLE(temp), &xhci->ir_set->irq_pending);
> +
> if (xhci_start(xhci)) {
> xhci_halt(xhci);
> + spin_unlock_irqrestore(&xhci->lock, flags);
> return -ENODEV;
> }
> +
> xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
>
> if (xhci->quirks & XHCI_NEC_HOST)
> xhci_ring_cmd_db(xhci);
>
> + spin_unlock_irqrestore(&xhci->lock, flags);
> +
> return 0;
> }
>
> @@ -668,19 +690,6 @@ int xhci_run(struct usb_hcd *hcd)
> temp |= (xhci->imod_interval / 250) & ER_IRQ_INTERVAL_MASK;
> writel(temp, &xhci->ir_set->irq_control);
>
> - /* Set the HCD state before we enable the irqs */
> - temp = readl(&xhci->op_regs->command);
> - temp |= (CMD_EIE);
> - xhci_dbg_trace(xhci, trace_xhci_dbg_init,
> - "// Enable interrupts, cmd = 0x%x.", temp);
> - writel(temp, &xhci->op_regs->command);
> -
> - temp = readl(&xhci->ir_set->irq_pending);
> - xhci_dbg_trace(xhci, trace_xhci_dbg_init,
> - "// Enabling event ring interrupter %p by writing 0x%x to irq_pending",
> - xhci->ir_set, (unsigned int) ER_IRQ_ENABLE(temp));
> - writel(ER_IRQ_ENABLE(temp), &xhci->ir_set->irq_pending);
> -
> if (xhci->quirks & XHCI_NEC_HOST) {
> struct xhci_command *command;
>
This is not available to older kernels [< 5.19]. Can we get this
backported to 5.15 as well? Please let me know if there is some other
way to do it.
Cc: <stable(a)vger.kernel.org> # 5.15
Thanks,
Prashanth K