linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Jann Horn <jannh@google.com>,
	Suren Baghdasaryan <surenb@google.com>,
	linux-mm@kvack.org, Arjun Roy <arjunroy@google.com>,
	Eric Dumazet <edumazet@google.com>,
	linux-fsdevel@vger.kernel.org,
	Punit Agrawal <punit.agrawal@bytedance.com>,
	"David S. Miller" <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH v2 1/9] Revert "tcp: Use per-vma locking for receive zerocopy"
Date: Mon, 24 Jul 2023 14:42:50 -0700	[thread overview]
Message-ID: <20230724144250.4cef3f4e@kernel.org> (raw)
In-Reply-To: <ZL6TWDCasQon3h4r@casper.infradead.org>

On Mon, 24 Jul 2023 16:06:00 +0100 Matthew Wilcox wrote:
> > Are you saying you want them to revert it before it reaches mainline?
> > That commit landed in v6.5-rc1.  
> 
> ... what?  It was posted on June 16th.  How does it end up in rc1 on
> July 9th?  6.4 was June 25th.  9 days is long enough for something
> that's not an urgent fix to land in rc1?  Networking doesn't close
> development at rc5/6 like most subsystem trees?

We don't, and yeah this one was a bit risky. We close for the merge
window (the two weeks), we could definitely push back on risky changes
starting a week or two before the window... but we don't know how long
the release will last :( if we stop taking large changes at rc6 and
release goes until rc8 that's 5 out of 11 weeks of the cycle when we
can't apply substantial patches. It's way too long. The weeks after 
the merge window are already super stressful, if we shut down for longer
it'll only get worse. I'm typing all this because I was hoping we can
bring up making the release schedule even more predictable with Linus,
I'm curious if others feel the same way.

On the matter at hand - I thought the patches were just conflicting
with your upcoming work. Are they already broken in v6.5? No problem
with queuing the revert for v6.5 here if they are.


  reply	other threads:[~2023-07-24 21:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 20:20 [PATCH v2 0/9] Avoid the mmap lock for fault-around Matthew Wilcox (Oracle)
2023-07-11 20:20 ` [PATCH v2 1/9] Revert "tcp: Use per-vma locking for receive zerocopy" Matthew Wilcox (Oracle)
2023-07-14  3:02   ` Suren Baghdasaryan
2023-07-14  3:34     ` Matthew Wilcox
2023-07-24 14:49       ` Jann Horn
2023-07-24 15:06         ` Matthew Wilcox
2023-07-24 21:42           ` Jakub Kicinski [this message]
2023-07-11 20:20 ` [PATCH v2 2/9] mm: Allow per-VMA locks on file-backed VMAs Matthew Wilcox (Oracle)
2023-07-14  3:03   ` Suren Baghdasaryan
2023-07-11 20:20 ` [PATCH v2 3/9] mm: Move FAULT_FLAG_VMA_LOCK check from handle_mm_fault() Matthew Wilcox (Oracle)
2023-07-14  3:04   ` Suren Baghdasaryan
2023-07-11 20:20 ` [PATCH v2 4/9] mm: Move FAULT_FLAG_VMA_LOCK check into handle_pte_fault() Matthew Wilcox (Oracle)
2023-07-14  3:17   ` Suren Baghdasaryan
2023-07-24 15:46   ` Jann Horn
2023-07-24 16:37     ` Matthew Wilcox
2023-07-11 20:20 ` [PATCH v2 5/9] mm: Move FAULT_FLAG_VMA_LOCK check down in handle_pte_fault() Matthew Wilcox (Oracle)
2023-07-14  3:26   ` Suren Baghdasaryan
2023-07-24 15:46   ` Jann Horn
2023-07-24 17:45     ` Matthew Wilcox
2023-07-11 20:20 ` [PATCH v2 6/9] mm: Move the FAULT_FLAG_VMA_LOCK check down from do_fault() Matthew Wilcox (Oracle)
2023-07-14  3:27   ` Suren Baghdasaryan
2023-07-11 20:20 ` [PATCH v2 7/9] mm: Run the fault-around code under the VMA lock Matthew Wilcox (Oracle)
2023-07-14  3:32   ` Suren Baghdasaryan
2023-07-24 17:38     ` Matthew Wilcox
2023-07-11 20:20 ` [PATCH v2 8/9] mm: Remove CONFIG_PER_VMA_LOCK ifdefs Matthew Wilcox (Oracle)
2023-07-14  3:34   ` Suren Baghdasaryan
2023-07-11 20:20 ` [PATCH v2 9/9] tcp: Use per-vma locking for receive zerocopy Matthew Wilcox (Oracle)
2023-07-14  3:40   ` Suren Baghdasaryan
2023-07-21 18:48   ` Matthew Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230724144250.4cef3f4e@kernel.org \
    --to=kuba@kernel.org \
    --cc=arjunroy@google.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jannh@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=punit.agrawal@bytedance.com \
    --cc=surenb@google.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).