linux-kernel - Re: [PATCH v2] drm/etnaviv: Fix flush sequence logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e58546c244fcea7d418879edf8d899393f6bd5bb.camel@pengutronix.de>
Date: Wed, 30 Jul 2025 16:30:34 +0200
From: Lucas Stach <l.stach@...gutronix.de>
To: Christian Gmeiner <christian.gmeiner@...il.com>, Tomeu Vizoso
	 <tomeu@...euvizoso.net>
Cc: linux-kernel@...r.kernel.org, Russell King
 <linux+etnaviv@...linux.org.uk>,  David Airlie <airlied@...il.com>, Simona
 Vetter <simona@...ll.ch>, Philipp Zabel <p.zabel@...gutronix.de>,  Guido
 Günther <agx@...xcpu.org>,
 etnaviv@...ts.freedesktop.org,  dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2] drm/etnaviv: Fix flush sequence logic

Hi Christian,

Am Montag, dem 28.07.2025 um 00:28 +0200 schrieb Christian Gmeiner:
> Hi Lucas,
> 
> > > > We should be comparing the last submitted sequence number with that of
> > > > the address space we may be switching to.
> > > > 
> > > This isn't the relevant change here though: if we switch the address
> > > space, the comparison is moot, as we do a full flush on AS switch
> > > anyway. The relevant change is that with the old code we would record
> > > the flush sequence of the AS we switch away from as the current flush
> > > sequence, so we might miss a necessary flush on the next submission if
> > > that one doesn't require a AS switch, but would only flush based on
> > > sequence mismatch.
> > 
> > Ah, you are right.
> > 
> > > Mind if I rewrite the commit message along those lines while applying?
> > 
> 
> Now that v6.16 has been tagged, I was wondering why this patch didn’t make
> it into this release. From the timeline, it seemed like there was
> enough time for it
> to be included, so I’m just trying to understand if it was overlooked
> or deferred for a reason.
> 
That's 100% on me. I've applied the patch with the reworded commit
message into my repo, but then didn't push it out as I was planning on
batching this with some other patches. This didn't happen due to other
tasks pushing this down in my priority list.

> I also haven’t seen any recent activity at
> https://git.pengutronix.de/cgit/lst/linux/, which
> made me unsure about the current status of patch queue handling.
> 
Yea, the current workflow of funneling things through this repository
doesn't work too well for the occasional small fix/patch. It works okay
as long as there are some more patches queued, but small patches tend
to get deferred for too long.
I'm pondering the idea of applying small fixes directly into drm-misc
to get them on a more predictable schedule to upstream. This will
require some changes to my workflow and I'll probably announce this via
a appropriate change to MAINTAINERS, as soon as I'm ready to make the
switch.

Regards,
Lucas