Re: [PATCH v7 0/8] dma-buf: Use revoke mechanism to invalidate shared buffers

[Leon Romanovsky <leon@kernel.org>]

On Wed, Feb 04, 2026 at 09:56:57AM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 04, 2026 at 02:44:42PM +0100, Maxime Ripard wrote:
> > > From what I have seen, subsystems such as netdev, the block layer, and RDMA continue
> > > to accept code that is ready for merging, especially when it has been thoroughly
> > > reviewed by multiple maintainers across different subsystems.
> > 
> > He said it multiple times, but here's one of such examples:
> > 
> > https://lore.kernel.org/all/CA+55aFwdd30eBsnMLB=ncExY0-P=eAsxkn_O6ir10JUyVSYdhA@mail.gmail.com/
> 
> Woah, nobody is saying to skip linux-next. It is Wednesday, if it
> lands in the public tree today it will be in linux next probably for a
> week before a PR is sent. This is a fairly normal thing for many trees
> in Linux.
> 
> Linus is specifically complaining about people *entirely* skipping
> linux-next.

Yes and yes.

> 
> > So, yeah, we can make exceptions. But you should ask and justify for
> > one, instead of expecting us to pick up a patch submission that was
> > already late.
> 
> I think Leon is only pointing out that a hard cut off two weeks before
> the merge window even opens is a DRMism, not a kernel wide convention.

Correct. I would like to see it in linux-next as soon as possible, and to
ensure I do not need to constantly rebase the patches because DRM changed
something in the .move_notify() area.

BTW, the series is in my tree:
https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dmabuf-revoke-v7
and is monitored by the kbuild bot, so this is not a random or untested
submission.

Thanks

> 
> Jason
>