From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Fri, 8 Mar 2024 07:40:42 -0800 Subject: [GIT PULL] KVM/riscv changes for 6.9 In-Reply-To: References: Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, Mar 08, 2024, Anup Patel wrote: > On Thu, Mar 7, 2024 at 11:13?PM Sean Christopherson wrote: > > > > On Thu, Mar 07, 2024, Anup Patel wrote: > > > ---------------------------------------------------------------- > > > KVM/riscv changes for 6.9 > > Uh, what's going on with this series? Many of these were committed *yesterday*, > > but you sent a mail on February 12th[1] saying these were queued. That's quite > > the lag. > > > > I don't intend to police the RISC-V tree, but this commit caused a conflict with > > kvm-x86/selftests[2]. It's a non-issue in this case because it's such a trivial > > conflict, and we're all quite lax with selftests, but sending a pull request ~12 > > hours after pushing commits that clearly aren't fixes is a bit ridiciulous. E.g. > > if this were to happen with a less trivial conflict, the other sub-maintainer would > > be left doing a late scramble to figure things out just before sending their own > > pull requests. > > > > tag kvm-riscv-6.9-1 > > Tagger: Anup Patel > > TaggerDate: Thu Mar 7 11:54:34 2024 +0530 > > > > ... > > > > commit d8c0831348e78fdaf67aa95070bae2ef8e819b05 > > Author: Anup Patel > > AuthorDate: Tue Feb 13 13:39:17 2024 +0530 > > Commit: Anup Patel > > CommitDate: Wed Mar 6 20:53:44 2024 +0530 > > > > The other reason this caught my eye is that the conflict happened in common code, > > but the added helper is RISC-V specific and used only from RISC-V code. ARM does > > have an identical helper, but AFAICT ARM's helper is only used from ARM code. > > > > But the prototype of guest_get_vcpuid() is in common code. Which isn't a huge > > deal, but it's rather undesirable because there's no indication that its > > implementation is arch-specific, and trying to use it in code built for s390 or > > x86 (or MIPS or PPC, which are on the horizon), would fail. I'm all for making > > code common where possible, but going halfway and leaving a trap for other > > architectures makes for a poor experience for developers. > > > > And again, this showing up _so_ late means it's unnecessarily difficult to clean > > things up. Which is kinda the whole point of getting thing into linux-next, so > > that folks that weren't involved in the original patch/series can react if there > > is a hiccup/problem/oddity. > > Sorry for the last minute conflict. > > In all release cycles, the riscv_kvm_queue freezes by rc6 and riscv_kvm_next > is updated at least a week before sending PR. > > In this case there was a crucial last minute bug found in RISC-V arch_timer > selftest patches due to which the get-reg-list selftest was broken so I > updated the offending commits in the queue itself before sending out PR. > > I will definitely try my best to avoid such last minute conflict. You're missing the point. I don't care when patches land in the RISC-V tree, nor do I care that you made a last minute tweak to fix a bug. I care when commits show up in linux-next, and *none* of these commits were in linux-next until yesterday. $ git tag -l --contains 2c5af1c8460376751d57c50af88a053a3b869926 next-20240307 next-20240308 The *entire* purpose of linux-next is to integrate *all* work destined for the next kernel into a single tree, so that conflicts, bugs, etc. can be found and fixed *before* the next merge window. Commits should be getting pushed to riscv_kvm_next, i.e. pulled by linux-next, the instant you are confident they are "stable" and unlikely to be amended. The entire RISC-V KVM tree showing up in linux-next a week before the merge window opens is *way* too late. >From Documentation/process/howto.rst: - As soon as a new kernel is released a two week window is open, during this period of time maintainers can submit big diffs to Linus, usually the patches that have already been included in the linux-next for a few weeks. ... linux-next integration testing tree ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Before updates from subsystem trees are merged into the mainline tree, they need to be integration-tested. For this purpose, a special testing repository exists into which virtually all subsystem trees are pulled on an almost daily basis: https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git This way, the linux-next gives a summary outlook onto what will be expected to go into the mainline kernel at the next merge period. Adventurous testers are very welcome to runtime-test the linux-next. The fact that your tree is based on -rc6 means your entire workflow is flawed. There is almost never a need to to use a release candidate later than -rc2 as the base, as the odds of there being a fix in Linus' tree aftern -rc2 that is *absolutely necessary* for testing KVM are vanishingly small. And given that these were "queued" on February 12th, but are now based on -rc6, means that you reparented them at least once. Rebasing/reparenting is explicitly documented as a Bad Idea?, because for all intents and purposes rebasing creates a completely new commit, and thus invalidates much of the testing that was done on the prior incarnation of the branch/commits. E.g. if you make a mistake when rebasing a patch and introduce a bug, bisect will point to the rebased commit, despite the fact that as *submitted* and originally applied, the patch was correct. But if you (or more likely Paolo or Linus) make the same mistake when merging the branch, bisect will point at the merge commit. That is a huge difference, as it pinpoints that the problem wasn't with the patch itself, but instead with how it was integrated without someone else's work. >From Documentation/maintainer/rebasing-and-merging.rst Rebasing ======== "Rebasing" is the process of changing the history of a series of commits within a repository. There are two different types of operations that are referred to as rebasing since both are done with the ``git rebase`` command, but there are significant differences between them: - Changing the parent (starting) commit upon which a series of patches is built. For example, a rebase operation could take a patch set built on the previous kernel release and base it, instead, on the current release. We'll call this operation "reparenting" in the discussion below. - Changing the history of a set of patches by fixing (or deleting) broken commits, adding patches, adding tags to commit changelogs, or changing the order in which commits are applied. In the following text, this type of operation will be referred to as "history modification" The term "rebasing" will be used to refer to both of the above operations. Used properly, rebasing can yield a cleaner and clearer development history; used improperly, it can obscure that history and introduce bugs. There are a few rules of thumb that can help developers to avoid the worst perils of rebasing: - History that has been exposed to the world beyond your private system should usually not be changed. Others may have pulled a copy of your tree and built on it; modifying your tree will create pain for them. If work is in need of rebasing, that is usually a sign that it is not yet ready to be committed to a public repository. That said, there are always exceptions. Some trees (linux-next being a significant example) are frequently rebased by their nature, and developers know not to base work on them. Developers will sometimes expose an unstable branch for others to test with or for automated testing services. If you do expose a branch that may be unstable in this way, be sure that prospective users know not to base work on it. - Do not rebase a branch that contains history created by others. If you have pulled changes from another developer's repository, you are now a custodian of their history. You should not change it. With few exceptions, for example, a broken commit in a tree like this should be explicitly reverted rather than disappeared via history modification. - Do not reparent a tree without a good reason to do so. Just being on a newer base or avoiding a merge with an upstream repository is not generally a good reason. - If you must reparent a repository, do not pick some random kernel commit as the new base. The kernel is often in a relatively unstable state between release points; basing development on one of those points increases the chances of running into surprising bugs. When a patch series must move to a new base, pick a stable point (such as one of the -rc releases) to move to. - Realize that reparenting a patch series (or making significant history modifications) changes the environment in which it was developed and, likely, invalidates much of the testing that was done. A reparented patch series should, as a general rule, be treated like new code and retested from the beginning. A frequent cause of merge-window trouble is when Linus is presented with a patch series that has clearly been reparented, often to a random commit, shortly before the pull request was sent. The chances of such a series having been adequately tested are relatively low - as are the chances of the pull request being acted upon. If, instead, rebasing is limited to private trees, commits are based on a well-known starting point, and they are well tested, the potential for trouble is low. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9CE30C5475B for ; Fri, 8 Mar 2024 15:41:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=1iFCSnuYEklZo3yMI0ny3H+BI/JcKNAejAnm4oZrNkQ=; b=e0Qb+Q3uk79WvOVRLdOnwFaUEf /O5Fu4nrvDZVt46ll4bcGsVZ7NdMbAlfr1pL4r95V32AT6tDGsfHRvJ1ekSTOf6A3ofnDpliMeINK 6rLnNuCbXS/wkr5j6Gowqe0P1WrZ+sKeh3ltxLHQaXwKLbbiohto0NxHwIjwgNnQd3DDP4pEaqP1P AHqgsXLVKTtOrDlH/Lt/1Rsr9kchs87bxbJYFo/v/3fTowLozL6iwI5jhn9ylV06Pctt0agLfXNn0 DGDxQTZgmnzgLs+i/liXu/D5oY7G5fH/v5aYXIiDz+sAQndktR+93HuOCMUdXZ2JurqFU9VhgPKhI YAmVcwZQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ricLA-00000009wAv-056k; Fri, 08 Mar 2024 15:40:56 +0000 Received: from mail-pg1-x54a.google.com ([2607:f8b0:4864:20::54a]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1ricL7-00000009w6i-2glT for linux-riscv@lists.infradead.org; Fri, 08 Mar 2024 15:40:55 +0000 Received: by mail-pg1-x54a.google.com with SMTP id 41be03b00d2f7-5d1bffa322eso2293579a12.1 for ; Fri, 08 Mar 2024 07:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709912444; x=1710517244; darn=lists.infradead.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=yGXij0pXxbNnFrojQkAhwWd7kWJ6lHgt5Xgw5lH9rKY=; b=HxFpQEyzZPOiQUaq2nDR12Mv4Zf3ITX5n0h+waWEvdl2j88f0DX/oLM+T9RdNaDqLO G5WCCEYlWbVjofARUeZSNbMJ92Gb7qzHFzr+pNpfZymjr5HglJg9cuPorjINetzD3FV0 1+mly4/EX8BON832KtGfj/tu1PGtKH7FT3UNlmkwQZVzScukk1eAZLXxBPlQlTRSohSM aykO92Rbqf/JWo27Af6Edz7zyWY01ajQiDuvY1xRHS+if80LN7wE3ibFknvYiE8l8riL lnpfdCj4HKu3xSOEv60eme4AVJTaBWOaRu4L9A9NjhHL72y+FqRuWbACuTz/idMu3lAb jFQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709912444; x=1710517244; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=yGXij0pXxbNnFrojQkAhwWd7kWJ6lHgt5Xgw5lH9rKY=; b=GTO2qIMn87zzpWe/Li1MB5DXwPEFtT0MNsLgmdfTOnZTBiKcB1FT2/xejR/A+u4poD JJyCQtG7BZM3KGsH92ltsYWdWDMKX70hx4qUtzMvWj1fPX508qq6SolTKEqzz3JWVm0w t2anl6wWYUDrDk3D7/ShoFqmE/BXeueBrmD0MAlbFu/k0+Dqc+heUVF5z5B4xTCBKXZS gT3qknSgUFzQdmOb1NK446B+VWHbSHJrRUdUipE0XXw1VBehiaNreYjQJSl0Wp7FXB0c qmLN5KMaRiSFseEmOmD+YHl/lKeAM0aNkg1rQIUM5HfQMi1IFZGB1L2fcevvXkxQMW8G Q+6g== X-Forwarded-Encrypted: i=1; AJvYcCV2/Mniq7Y0jJeE1Tx1i5QckqIder925y6qjbVKOFlUN13Vo+vb5yp3CN/yr8QM/MGOkOmpic22MZiw1SKNQ6oBNtpxr/D7dafLn13FjHrl X-Gm-Message-State: AOJu0Yzz6Yhvy0Z7MHBfo8YhfIa4RHurQ85fyzj9kzG1p7pOtoz/pywi zjZ+TSkKmoWYZYYHaSzAg86+OeZtCGq9CPtelkClVgsf/J7VVOw1MihqJC0x1s85gHjw6kV/UAi 6Eg== X-Google-Smtp-Source: AGHT+IFjEBX6C+7q1SBXQ+tSA4pdjdQXgmJ9UBKLZS/xnmX8tOHGVqK01y9ERowX6ifH4R9/jDDhuoSeDmU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a63:1f64:0:b0:5dc:1c7d:2c75 with SMTP id q36-20020a631f64000000b005dc1c7d2c75mr56894pgm.1.1709912443614; Fri, 08 Mar 2024 07:40:43 -0800 (PST) Date: Fri, 8 Mar 2024 07:40:42 -0800 In-Reply-To: Mime-Version: 1.0 References: Message-ID: Subject: Re: [GIT PULL] KVM/riscv changes for 6.9 From: Sean Christopherson To: Anup Patel Cc: Paolo Bonzini , Palmer Dabbelt , Palmer Dabbelt , Andrew Jones , Atish Patra , Atish Patra , KVM General , "open list:KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv)" , linux-riscv X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240308_074053_696464_ED649586 X-CRM114-Status: GOOD ( 54.02 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org T24gRnJpLCBNYXIgMDgsIDIwMjQsIEFudXAgUGF0ZWwgd3JvdGU6Cj4gT24gVGh1LCBNYXIgNywg MjAyNCBhdCAxMToxM+KAr1BNIFNlYW4gQ2hyaXN0b3BoZXJzb24gPHNlYW5qY0Bnb29nbGUuY29t PiB3cm90ZToKPiA+Cj4gPiBPbiBUaHUsIE1hciAwNywgMjAyNCwgQW51cCBQYXRlbCB3cm90ZToK PiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQo+ID4gPiBLVk0vcmlzY3YgY2hhbmdlcyBmb3IgNi45Cj4gPiBVaCwgd2hh dCdzIGdvaW5nIG9uIHdpdGggdGhpcyBzZXJpZXM/ICBNYW55IG9mIHRoZXNlIHdlcmUgY29tbWl0 dGVkICp5ZXN0ZXJkYXkqLAo+ID4gYnV0IHlvdSBzZW50IGEgbWFpbCBvbiBGZWJydWFyeSAxMnRo WzFdIHNheWluZyB0aGVzZSB3ZXJlIHF1ZXVlZC4gIFRoYXQncyBxdWl0ZQo+ID4gdGhlIGxhZy4K PiA+Cj4gPiBJIGRvbid0IGludGVuZCB0byBwb2xpY2UgdGhlIFJJU0MtViB0cmVlLCBidXQgdGhp cyBjb21taXQgY2F1c2VkIGEgY29uZmxpY3Qgd2l0aAo+ID4ga3ZtLXg4Ni9zZWxmdGVzdHNbMl0u ICBJdCdzIGEgbm9uLWlzc3VlIGluIHRoaXMgY2FzZSBiZWNhdXNlIGl0J3Mgc3VjaCBhIHRyaXZp YWwKPiA+IGNvbmZsaWN0LCBhbmQgd2UncmUgYWxsIHF1aXRlIGxheCB3aXRoIHNlbGZ0ZXN0cywg YnV0IHNlbmRpbmcgYSBwdWxsIHJlcXVlc3QgfjEyCj4gPiBob3VycyBhZnRlciBwdXNoaW5nIGNv bW1pdHMgdGhhdCBjbGVhcmx5IGFyZW4ndCBmaXhlcyBpcyBhIGJpdCByaWRpY2l1bG91cy4gIEUu Zy4KPiA+IGlmIHRoaXMgd2VyZSB0byBoYXBwZW4gd2l0aCBhIGxlc3MgdHJpdmlhbCBjb25mbGlj dCwgdGhlIG90aGVyIHN1Yi1tYWludGFpbmVyIHdvdWxkCj4gPiBiZSBsZWZ0IGRvaW5nIGEgbGF0 ZSBzY3JhbWJsZSB0byBmaWd1cmUgdGhpbmdzIG91dCBqdXN0IGJlZm9yZSBzZW5kaW5nIHRoZWly IG93bgo+ID4gcHVsbCByZXF1ZXN0cy4KPiA+Cj4gPiAgIHRhZyBrdm0tcmlzY3YtNi45LTEKPiA+ ICAgVGFnZ2VyOiAgICAgQW51cCBQYXRlbCA8YW51cEBicmFpbmZhdWx0Lm9yZz4KPiA+ICAgVGFn Z2VyRGF0ZTogVGh1IE1hciA3IDExOjU0OjM0IDIwMjQgKzA1MzAKPiA+Cj4gPiAuLi4KPiA+Cj4g PiAgIGNvbW1pdCBkOGMwODMxMzQ4ZTc4ZmRhZjY3YWE5NTA3MGJhZTJlZjhlODE5YjA1Cj4gPiAg IEF1dGhvcjogICAgIEFudXAgUGF0ZWwgPGFwYXRlbEB2ZW50YW5hbWljcm8uY29tPgo+ID4gICBB dXRob3JEYXRlOiBUdWUgRmViIDEzIDEzOjM5OjE3IDIwMjQgKzA1MzAKPiA+ICAgQ29tbWl0OiAg ICAgQW51cCBQYXRlbCA8YW51cEBicmFpbmZhdWx0Lm9yZz4KPiA+ICAgQ29tbWl0RGF0ZTogV2Vk IE1hciA2IDIwOjUzOjQ0IDIwMjQgKzA1MzAKPiA+Cj4gPiBUaGUgb3RoZXIgcmVhc29uIHRoaXMg Y2F1Z2h0IG15IGV5ZSBpcyB0aGF0IHRoZSBjb25mbGljdCBoYXBwZW5lZCBpbiBjb21tb24gY29k ZSwKPiA+IGJ1dCB0aGUgYWRkZWQgaGVscGVyIGlzIFJJU0MtViBzcGVjaWZpYyBhbmQgdXNlZCBv bmx5IGZyb20gUklTQy1WIGNvZGUuICBBUk0gZG9lcwo+ID4gaGF2ZSBhbiBpZGVudGljYWwgaGVs cGVyLCBidXQgQUZBSUNUIEFSTSdzIGhlbHBlciBpcyBvbmx5IHVzZWQgZnJvbSBBUk0gY29kZS4K PiA+Cj4gPiBCdXQgdGhlIHByb3RvdHlwZSBvZiBndWVzdF9nZXRfdmNwdWlkKCkgaXMgaW4gY29t bW9uIGNvZGUuICBXaGljaCBpc24ndCBhIGh1Z2UKPiA+IGRlYWwsIGJ1dCBpdCdzIHJhdGhlciB1 bmRlc2lyYWJsZSBiZWNhdXNlIHRoZXJlJ3Mgbm8gaW5kaWNhdGlvbiB0aGF0IGl0cwo+ID4gaW1w bGVtZW50YXRpb24gaXMgYXJjaC1zcGVjaWZpYywgYW5kIHRyeWluZyB0byB1c2UgaXQgaW4gY29k ZSBidWlsdCBmb3IgczM5MCBvcgo+ID4geDg2IChvciBNSVBTIG9yIFBQQywgd2hpY2ggYXJlIG9u IHRoZSBob3Jpem9uKSwgd291bGQgZmFpbC4gIEknbSBhbGwgZm9yIG1ha2luZwo+ID4gY29kZSBj b21tb24gd2hlcmUgcG9zc2libGUsIGJ1dCBnb2luZyBoYWxmd2F5IGFuZCBsZWF2aW5nIGEgdHJh cCBmb3Igb3RoZXIKPiA+IGFyY2hpdGVjdHVyZXMgbWFrZXMgZm9yIGEgcG9vciBleHBlcmllbmNl IGZvciBkZXZlbG9wZXJzLgo+ID4KPiA+IEFuZCBhZ2FpbiwgdGhpcyBzaG93aW5nIHVwIF9zb18g bGF0ZSBtZWFucyBpdCdzIHVubmVjZXNzYXJpbHkgZGlmZmljdWx0IHRvIGNsZWFuCj4gPiB0aGlu Z3MgdXAuICBXaGljaCBpcyBraW5kYSB0aGUgd2hvbGUgcG9pbnQgb2YgZ2V0dGluZyB0aGluZyBp bnRvIGxpbnV4LW5leHQsIHNvCj4gPiB0aGF0IGZvbGtzIHRoYXQgd2VyZW4ndCBpbnZvbHZlZCBp biB0aGUgb3JpZ2luYWwgcGF0Y2gvc2VyaWVzIGNhbiByZWFjdCBpZiB0aGVyZQo+ID4gaXMgYSBo aWNjdXAvcHJvYmxlbS9vZGRpdHkuCj4gCj4gU29ycnkgZm9yIHRoZSBsYXN0IG1pbnV0ZSBjb25m bGljdC4KPiAKPiBJbiBhbGwgcmVsZWFzZSBjeWNsZXMsIHRoZSByaXNjdl9rdm1fcXVldWUgZnJl ZXplcyBieSByYzYgYW5kIHJpc2N2X2t2bV9uZXh0Cj4gaXMgdXBkYXRlZCBhdCBsZWFzdCBhIHdl ZWsgYmVmb3JlIHNlbmRpbmcgUFIuCj4gCj4gSW4gdGhpcyBjYXNlIHRoZXJlIHdhcyBhIGNydWNp YWwgbGFzdCBtaW51dGUgYnVnIGZvdW5kIGluIFJJU0MtViBhcmNoX3RpbWVyCj4gc2VsZnRlc3Qg cGF0Y2hlcyBkdWUgdG8gd2hpY2ggdGhlIGdldC1yZWctbGlzdCBzZWxmdGVzdCB3YXMgYnJva2Vu IHNvIEkKPiB1cGRhdGVkIHRoZSBvZmZlbmRpbmcgY29tbWl0cyBpbiB0aGUgcXVldWUgaXRzZWxm IGJlZm9yZSBzZW5kaW5nIG91dCBQUi4KPiAKPiBJIHdpbGwgZGVmaW5pdGVseSB0cnkgbXkgYmVz dCB0byBhdm9pZCBzdWNoIGxhc3QgbWludXRlIGNvbmZsaWN0LgoKWW91J3JlIG1pc3NpbmcgdGhl IHBvaW50LiAgSSBkb24ndCBjYXJlIHdoZW4gcGF0Y2hlcyBsYW5kIGluIHRoZSBSSVNDLVYgdHJl ZSwgbm9yCmRvIEkgY2FyZSB0aGF0IHlvdSBtYWRlIGEgbGFzdCBtaW51dGUgdHdlYWsgdG8gZml4 IGEgYnVnLiAgSSBjYXJlIHdoZW4gY29tbWl0cwpzaG93IHVwIGluIGxpbnV4LW5leHQsIGFuZCAq bm9uZSogb2YgdGhlc2UgY29tbWl0cyB3ZXJlIGluIGxpbnV4LW5leHQgdW50aWwKeWVzdGVyZGF5 LgoKICAkIGdpdCB0YWcgLWwgLS1jb250YWlucyAyYzVhZjFjODQ2MDM3Njc1MWQ1N2M1MGFmODhh MDUzYTNiODY5OTI2CiAgbmV4dC0yMDI0MDMwNwogIG5leHQtMjAyNDAzMDgKClRoZSAqZW50aXJl KiBwdXJwb3NlIG9mIGxpbnV4LW5leHQgaXMgdG8gaW50ZWdyYXRlICphbGwqIHdvcmsgZGVzdGlu ZWQgZm9yIHRoZQpuZXh0IGtlcm5lbCBpbnRvIGEgc2luZ2xlIHRyZWUsIHNvIHRoYXQgY29uZmxp Y3RzLCBidWdzLCBldGMuIGNhbiBiZSBmb3VuZCBhbmQKZml4ZWQgKmJlZm9yZSogdGhlIG5leHQg bWVyZ2Ugd2luZG93LgoKQ29tbWl0cyBzaG91bGQgYmUgZ2V0dGluZyBwdXNoZWQgdG8gcmlzY3Zf a3ZtX25leHQsIGkuZS4gcHVsbGVkIGJ5IGxpbnV4LW5leHQsCnRoZSBpbnN0YW50IHlvdSBhcmUg Y29uZmlkZW50IHRoZXkgYXJlICJzdGFibGUiIGFuZCB1bmxpa2VseSB0byBiZSBhbWVuZGVkLiAg VGhlCmVudGlyZSBSSVNDLVYgS1ZNIHRyZWUgc2hvd2luZyB1cCBpbiBsaW51eC1uZXh0IGEgd2Vl ayBiZWZvcmUgdGhlIG1lcmdlIHdpbmRvdwpvcGVucyBpcyAqd2F5KiB0b28gbGF0ZS4KCkZyb20g RG9jdW1lbnRhdGlvbi9wcm9jZXNzL2hvd3RvLnJzdDoKCiAgLSBBcyBzb29uIGFzIGEgbmV3IGtl cm5lbCBpcyByZWxlYXNlZCBhIHR3byB3ZWVrIHdpbmRvdyBpcyBvcGVuLAogICAgZHVyaW5nIHRo aXMgcGVyaW9kIG9mIHRpbWUgbWFpbnRhaW5lcnMgY2FuIHN1Ym1pdCBiaWcgZGlmZnMgdG8KICAg IExpbnVzLCB1c3VhbGx5IHRoZSBwYXRjaGVzIHRoYXQgaGF2ZSBhbHJlYWR5IGJlZW4gaW5jbHVk ZWQgaW4gdGhlCiAgICBsaW51eC1uZXh0IGZvciBhIGZldyB3ZWVrcy4gCgouLi4KCiAgbGludXgt bmV4dCBpbnRlZ3JhdGlvbiB0ZXN0aW5nIHRyZWUKICB+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fgogIAogIEJlZm9yZSB1cGRhdGVzIGZyb20gc3Vic3lzdGVtIHRyZWVzIGFyZSBt ZXJnZWQgaW50byB0aGUgbWFpbmxpbmUgdHJlZSwKICB0aGV5IG5lZWQgdG8gYmUgaW50ZWdyYXRp b24tdGVzdGVkLiAgRm9yIHRoaXMgcHVycG9zZSwgYSBzcGVjaWFsCiAgdGVzdGluZyByZXBvc2l0 b3J5IGV4aXN0cyBpbnRvIHdoaWNoIHZpcnR1YWxseSBhbGwgc3Vic3lzdGVtIHRyZWVzIGFyZQog IHB1bGxlZCBvbiBhbiBhbG1vc3QgZGFpbHkgYmFzaXM6CiAgCiAgCWh0dHBzOi8vZ2l0Lmtlcm5l bC5vcmcvP3A9bGludXgva2VybmVsL2dpdC9uZXh0L2xpbnV4LW5leHQuZ2l0CiAgCiAgVGhpcyB3 YXksIHRoZSBsaW51eC1uZXh0IGdpdmVzIGEgc3VtbWFyeSBvdXRsb29rIG9udG8gd2hhdCB3aWxs IGJlCiAgZXhwZWN0ZWQgdG8gZ28gaW50byB0aGUgbWFpbmxpbmUga2VybmVsIGF0IHRoZSBuZXh0 IG1lcmdlIHBlcmlvZC4KICBBZHZlbnR1cm91cyB0ZXN0ZXJzIGFyZSB2ZXJ5IHdlbGNvbWUgdG8g cnVudGltZS10ZXN0IHRoZSBsaW51eC1uZXh0LgogIApUaGUgZmFjdCB0aGF0IHlvdXIgdHJlZSBp cyBiYXNlZCBvbiAtcmM2IG1lYW5zIHlvdXIgZW50aXJlIHdvcmtmbG93IGlzIGZsYXdlZC4KVGhl cmUgaXMgYWxtb3N0IG5ldmVyIGEgbmVlZCB0byB0byB1c2UgYSByZWxlYXNlIGNhbmRpZGF0ZSBs YXRlciB0aGFuIC1yYzIgYXMKdGhlIGJhc2UsIGFzIHRoZSBvZGRzIG9mIHRoZXJlIGJlaW5nIGEg Zml4IGluIExpbnVzJyB0cmVlIGFmdGVybiAtcmMyIHRoYXQgaXMKKmFic29sdXRlbHkgbmVjZXNz YXJ5KiBmb3IgdGVzdGluZyBLVk0gYXJlIHZhbmlzaGluZ2x5IHNtYWxsLgoKQW5kIGdpdmVuIHRo YXQgdGhlc2Ugd2VyZSAicXVldWVkIiBvbiBGZWJydWFyeSAxMnRoLCBidXQgYXJlIG5vdyBiYXNl ZCBvbiAtcmM2LAptZWFucyB0aGF0IHlvdSByZXBhcmVudGVkIHRoZW0gYXQgbGVhc3Qgb25jZS4g IFJlYmFzaW5nL3JlcGFyZW50aW5nIGlzIGV4cGxpY2l0bHkKZG9jdW1lbnRlZCBhcyBhIEJhZCBJ ZGVh4oSiLCBiZWNhdXNlIGZvciBhbGwgaW50ZW50cyBhbmQgcHVycG9zZXMgcmViYXNpbmcgY3Jl YXRlcwphIGNvbXBsZXRlbHkgbmV3IGNvbW1pdCwgYW5kIHRodXMgaW52YWxpZGF0ZXMgbXVjaCBv ZiB0aGUgdGVzdGluZyB0aGF0IHdhcyBkb25lCm9uIHRoZSBwcmlvciBpbmNhcm5hdGlvbiBvZiB0 aGUgYnJhbmNoL2NvbW1pdHMuCgpFLmcuIGlmIHlvdSBtYWtlIGEgbWlzdGFrZSB3aGVuIHJlYmFz aW5nIGEgcGF0Y2ggYW5kIGludHJvZHVjZSBhIGJ1ZywgYmlzZWN0IHdpbGwKcG9pbnQgdG8gdGhl IHJlYmFzZWQgY29tbWl0LCBkZXNwaXRlIHRoZSBmYWN0IHRoYXQgYXMgKnN1Ym1pdHRlZCogYW5k IG9yaWdpbmFsbHkKYXBwbGllZCwgdGhlIHBhdGNoIHdhcyBjb3JyZWN0LiAgQnV0IGlmIHlvdSAo b3IgbW9yZSBsaWtlbHkgUGFvbG8gb3IgTGludXMpIG1ha2UKdGhlIHNhbWUgbWlzdGFrZSB3aGVu IG1lcmdpbmcgdGhlIGJyYW5jaCwgYmlzZWN0IHdpbGwgcG9pbnQgYXQgdGhlIG1lcmdlIGNvbW1p dC4KVGhhdCBpcyBhIGh1Z2UgZGlmZmVyZW5jZSwgYXMgaXQgcGlucG9pbnRzIHRoYXQgdGhlIHBy b2JsZW0gd2Fzbid0IHdpdGggdGhlIHBhdGNoCml0c2VsZiwgYnV0IGluc3RlYWQgd2l0aCBob3cg aXQgd2FzIGludGVncmF0ZWQgd2l0aG91dCBzb21lb25lIGVsc2UncyB3b3JrLgoKRnJvbSBEb2N1 bWVudGF0aW9uL21haW50YWluZXIvcmViYXNpbmctYW5kLW1lcmdpbmcucnN0CgogIFJlYmFzaW5n CiAgPT09PT09PT0KICAKICAiUmViYXNpbmciIGlzIHRoZSBwcm9jZXNzIG9mIGNoYW5naW5nIHRo ZSBoaXN0b3J5IG9mIGEgc2VyaWVzIG9mIGNvbW1pdHMKICB3aXRoaW4gYSByZXBvc2l0b3J5LiAg VGhlcmUgYXJlIHR3byBkaWZmZXJlbnQgdHlwZXMgb2Ygb3BlcmF0aW9ucyB0aGF0IGFyZQogIHJl ZmVycmVkIHRvIGFzIHJlYmFzaW5nIHNpbmNlIGJvdGggYXJlIGRvbmUgd2l0aCB0aGUgYGBnaXQg cmViYXNlYGAKICBjb21tYW5kLCBidXQgdGhlcmUgYXJlIHNpZ25pZmljYW50IGRpZmZlcmVuY2Vz IGJldHdlZW4gdGhlbToKICAKICAgLSBDaGFuZ2luZyB0aGUgcGFyZW50IChzdGFydGluZykgY29t bWl0IHVwb24gd2hpY2ggYSBzZXJpZXMgb2YgcGF0Y2hlcyBpcwogICAgIGJ1aWx0LiAgRm9yIGV4 YW1wbGUsIGEgcmViYXNlIG9wZXJhdGlvbiBjb3VsZCB0YWtlIGEgcGF0Y2ggc2V0IGJ1aWx0IG9u CiAgICAgdGhlIHByZXZpb3VzIGtlcm5lbCByZWxlYXNlIGFuZCBiYXNlIGl0LCBpbnN0ZWFkLCBv biB0aGUgY3VycmVudAogICAgIHJlbGVhc2UuICBXZSdsbCBjYWxsIHRoaXMgb3BlcmF0aW9uICJy ZXBhcmVudGluZyIgaW4gdGhlIGRpc2N1c3Npb24KICAgICBiZWxvdy4KICAKICAgLSBDaGFuZ2lu ZyB0aGUgaGlzdG9yeSBvZiBhIHNldCBvZiBwYXRjaGVzIGJ5IGZpeGluZyAob3IgZGVsZXRpbmcp IGJyb2tlbgogICAgIGNvbW1pdHMsIGFkZGluZyBwYXRjaGVzLCBhZGRpbmcgdGFncyB0byBjb21t aXQgY2hhbmdlbG9ncywgb3IgY2hhbmdpbmcKICAgICB0aGUgb3JkZXIgaW4gd2hpY2ggY29tbWl0 cyBhcmUgYXBwbGllZC4gIEluIHRoZSBmb2xsb3dpbmcgdGV4dCwgdGhpcwogICAgIHR5cGUgb2Yg b3BlcmF0aW9uIHdpbGwgYmUgcmVmZXJyZWQgdG8gYXMgImhpc3RvcnkgbW9kaWZpY2F0aW9uIgog IAogIFRoZSB0ZXJtICJyZWJhc2luZyIgd2lsbCBiZSB1c2VkIHRvIHJlZmVyIHRvIGJvdGggb2Yg dGhlIGFib3ZlIG9wZXJhdGlvbnMuCiAgVXNlZCBwcm9wZXJseSwgcmViYXNpbmcgY2FuIHlpZWxk IGEgY2xlYW5lciBhbmQgY2xlYXJlciBkZXZlbG9wbWVudAogIGhpc3Rvcnk7IHVzZWQgaW1wcm9w ZXJseSwgaXQgY2FuIG9ic2N1cmUgdGhhdCBoaXN0b3J5IGFuZCBpbnRyb2R1Y2UgYnVncy4KICAK ICBUaGVyZSBhcmUgYSBmZXcgcnVsZXMgb2YgdGh1bWIgdGhhdCBjYW4gaGVscCBkZXZlbG9wZXJz IHRvIGF2b2lkIHRoZSB3b3JzdAogIHBlcmlscyBvZiByZWJhc2luZzoKICAKICAgLSBIaXN0b3J5 IHRoYXQgaGFzIGJlZW4gZXhwb3NlZCB0byB0aGUgd29ybGQgYmV5b25kIHlvdXIgcHJpdmF0ZSBz eXN0ZW0KICAgICBzaG91bGQgdXN1YWxseSBub3QgYmUgY2hhbmdlZC4gIE90aGVycyBtYXkgaGF2 ZSBwdWxsZWQgYSBjb3B5IG9mIHlvdXIKICAgICB0cmVlIGFuZCBidWlsdCBvbiBpdDsgbW9kaWZ5 aW5nIHlvdXIgdHJlZSB3aWxsIGNyZWF0ZSBwYWluIGZvciB0aGVtLiAgSWYKICAgICB3b3JrIGlz IGluIG5lZWQgb2YgcmViYXNpbmcsIHRoYXQgaXMgdXN1YWxseSBhIHNpZ24gdGhhdCBpdCBpcyBu b3QgeWV0CiAgICAgcmVhZHkgdG8gYmUgY29tbWl0dGVkIHRvIGEgcHVibGljIHJlcG9zaXRvcnku CiAgCiAgICAgVGhhdCBzYWlkLCB0aGVyZSBhcmUgYWx3YXlzIGV4Y2VwdGlvbnMuICBTb21lIHRy ZWVzIChsaW51eC1uZXh0IGJlaW5nCiAgICAgYSBzaWduaWZpY2FudCBleGFtcGxlKSBhcmUgZnJl cXVlbnRseSByZWJhc2VkIGJ5IHRoZWlyIG5hdHVyZSwgYW5kCiAgICAgZGV2ZWxvcGVycyBrbm93 IG5vdCB0byBiYXNlIHdvcmsgb24gdGhlbS4gIERldmVsb3BlcnMgd2lsbCBzb21ldGltZXMKICAg ICBleHBvc2UgYW4gdW5zdGFibGUgYnJhbmNoIGZvciBvdGhlcnMgdG8gdGVzdCB3aXRoIG9yIGZv ciBhdXRvbWF0ZWQKICAgICB0ZXN0aW5nIHNlcnZpY2VzLiAgSWYgeW91IGRvIGV4cG9zZSBhIGJy YW5jaCB0aGF0IG1heSBiZSB1bnN0YWJsZSBpbgogICAgIHRoaXMgd2F5LCBiZSBzdXJlIHRoYXQg cHJvc3BlY3RpdmUgdXNlcnMga25vdyBub3QgdG8gYmFzZSB3b3JrIG9uIGl0LgogIAogICAtIERv IG5vdCByZWJhc2UgYSBicmFuY2ggdGhhdCBjb250YWlucyBoaXN0b3J5IGNyZWF0ZWQgYnkgb3Ro ZXJzLiAgSWYgeW91CiAgICAgaGF2ZSBwdWxsZWQgY2hhbmdlcyBmcm9tIGFub3RoZXIgZGV2ZWxv cGVyJ3MgcmVwb3NpdG9yeSwgeW91IGFyZSBub3cgYQogICAgIGN1c3RvZGlhbiBvZiB0aGVpciBo aXN0b3J5LiAgWW91IHNob3VsZCBub3QgY2hhbmdlIGl0LiAgV2l0aCBmZXcKICAgICBleGNlcHRp b25zLCBmb3IgZXhhbXBsZSwgYSBicm9rZW4gY29tbWl0IGluIGEgdHJlZSBsaWtlIHRoaXMgc2hv dWxkIGJlCiAgICAgZXhwbGljaXRseSByZXZlcnRlZCByYXRoZXIgdGhhbiBkaXNhcHBlYXJlZCB2 aWEgaGlzdG9yeSBtb2RpZmljYXRpb24uCiAgCiAgIC0gRG8gbm90IHJlcGFyZW50IGEgdHJlZSB3 aXRob3V0IGEgZ29vZCByZWFzb24gdG8gZG8gc28uICBKdXN0IGJlaW5nIG9uIGEKICAgICBuZXdl ciBiYXNlIG9yIGF2b2lkaW5nIGEgbWVyZ2Ugd2l0aCBhbiB1cHN0cmVhbSByZXBvc2l0b3J5IGlz IG5vdAogICAgIGdlbmVyYWxseSBhIGdvb2QgcmVhc29uLgogIAogICAtIElmIHlvdSBtdXN0IHJl cGFyZW50IGEgcmVwb3NpdG9yeSwgZG8gbm90IHBpY2sgc29tZSByYW5kb20ga2VybmVsIGNvbW1p dAogICAgIGFzIHRoZSBuZXcgYmFzZS4gIFRoZSBrZXJuZWwgaXMgb2Z0ZW4gaW4gYSByZWxhdGl2 ZWx5IHVuc3RhYmxlIHN0YXRlCiAgICAgYmV0d2VlbiByZWxlYXNlIHBvaW50czsgYmFzaW5nIGRl dmVsb3BtZW50IG9uIG9uZSBvZiB0aG9zZSBwb2ludHMKICAgICBpbmNyZWFzZXMgdGhlIGNoYW5j ZXMgb2YgcnVubmluZyBpbnRvIHN1cnByaXNpbmcgYnVncy4gIFdoZW4gYSBwYXRjaAogICAgIHNl cmllcyBtdXN0IG1vdmUgdG8gYSBuZXcgYmFzZSwgcGljayBhIHN0YWJsZSBwb2ludCAoc3VjaCBh cyBvbmUgb2YKICAgICB0aGUgLXJjIHJlbGVhc2VzKSB0byBtb3ZlIHRvLgogIAogICAtIFJlYWxp emUgdGhhdCByZXBhcmVudGluZyBhIHBhdGNoIHNlcmllcyAob3IgbWFraW5nIHNpZ25pZmljYW50 IGhpc3RvcnkKICAgICBtb2RpZmljYXRpb25zKSBjaGFuZ2VzIHRoZSBlbnZpcm9ubWVudCBpbiB3 aGljaCBpdCB3YXMgZGV2ZWxvcGVkIGFuZCwKICAgICBsaWtlbHksIGludmFsaWRhdGVzIG11Y2gg b2YgdGhlIHRlc3RpbmcgdGhhdCB3YXMgZG9uZS4gIEEgcmVwYXJlbnRlZAogICAgIHBhdGNoIHNl cmllcyBzaG91bGQsIGFzIGEgZ2VuZXJhbCBydWxlLCBiZSB0cmVhdGVkIGxpa2UgbmV3IGNvZGUg YW5kCiAgICAgcmV0ZXN0ZWQgZnJvbSB0aGUgYmVnaW5uaW5nLgogIAogIEEgZnJlcXVlbnQgY2F1 c2Ugb2YgbWVyZ2Utd2luZG93IHRyb3VibGUgaXMgd2hlbiBMaW51cyBpcyBwcmVzZW50ZWQgd2l0 aCBhCiAgcGF0Y2ggc2VyaWVzIHRoYXQgaGFzIGNsZWFybHkgYmVlbiByZXBhcmVudGVkLCBvZnRl biB0byBhIHJhbmRvbSBjb21taXQsCiAgc2hvcnRseSBiZWZvcmUgdGhlIHB1bGwgcmVxdWVzdCB3 YXMgc2VudC4gIFRoZSBjaGFuY2VzIG9mIHN1Y2ggYSBzZXJpZXMKICBoYXZpbmcgYmVlbiBhZGVx dWF0ZWx5IHRlc3RlZCBhcmUgcmVsYXRpdmVseSBsb3cgLSBhcyBhcmUgdGhlIGNoYW5jZXMgb2YK ICB0aGUgcHVsbCByZXF1ZXN0IGJlaW5nIGFjdGVkIHVwb24uCiAgCiAgSWYsIGluc3RlYWQsIHJl YmFzaW5nIGlzIGxpbWl0ZWQgdG8gcHJpdmF0ZSB0cmVlcywgY29tbWl0cyBhcmUgYmFzZWQgb24g YQogIHdlbGwta25vd24gc3RhcnRpbmcgcG9pbnQsIGFuZCB0aGV5IGFyZSB3ZWxsIHRlc3RlZCwg dGhlIHBvdGVudGlhbCBmb3IKICB0cm91YmxlIGlzIGxvdy4KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LXJpc2N2IG1haWxpbmcgbGlzdApsaW51 eC1yaXNjdkBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21h aWxtYW4vbGlzdGluZm8vbGludXgtcmlzY3YK From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5AB5E1F932 for ; Fri, 8 Mar 2024 15:40:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709912446; cv=none; b=MUuEoe5S2GjTLC6D9U5LiEimFAofrlCNnG/oD+vTmrTXL/5ZyRdmHj/hOTk9QU7DnqCYZQ73ArxJUfG7k7zrjKET3oyI3wnHaB/Z5PAgd52kjjJGWcy7GoyFztwJ3Szu44wQ55afLOzwYfMDiWfbjl79d7ZcZglAAS2EKinrtaw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709912446; c=relaxed/simple; bh=DcGK2/3fl/rA0ThXMceF6UGOxdgz7YeQ6d40VzoEefU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=IRzrzElLSnCYxack8lMWnho/WxMZqyUtacHrkWB94BC35Hsh50iab7T5aI8OoI5clVYazWXUldQIO6n5R9HMshMHP2Eavyc2rq7ghm0jam8iR1e1eIxnp2hBmizNlAbWX67AqkJ3cDPw1+FobpccKaPOMUbcThwF79SR90jr5bw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=A1hzkDDo; arc=none smtp.client-ip=209.85.215.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="A1hzkDDo" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-5d1bffa322eso2293577a12.1 for ; Fri, 08 Mar 2024 07:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709912443; x=1710517243; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=yGXij0pXxbNnFrojQkAhwWd7kWJ6lHgt5Xgw5lH9rKY=; b=A1hzkDDokp6aEDVDoaxwHBqjsNur/n/QG19gyuKKsjlwX9KxpKkPCDJtofIXTDUq0y XCjBq3mLoufqZoJFSEwQ7IdRmqgOaV4NSIS3lJg0Nb/001FVYLnR2mcLwvBMcfvgDxqu sj58Z+xYeayCEpG2GW7jZ7/lZDEafyDq+gWvswM8djCcG4OAB7T/BoP1YSd0s8IEudJG etD1Mf7cd9dIXhwwcC77pqTg4mGIrd7iU4EPM5quq0xUZBPdp14ebvd5CHi8CJK+vFcP Girq8XaIufo5TwSKqyWkN89V9dqB6PizZKWCVXCXQ7oTm1TqQ6eJ1sIJCW9pm5nU/FqJ IAZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709912443; x=1710517243; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=yGXij0pXxbNnFrojQkAhwWd7kWJ6lHgt5Xgw5lH9rKY=; b=UFL01wou8e/QtEHyqP4xhe34ujWwj8B8cWdzAie2aTj2C/Uoi9FU04MPfPi/7vHoh3 yJXoXPKOs8y3iafFyPZEPtxwblmKubVGOVFoyxfDc1ija2C20hxmzh87PVrPhogem3uU gxOriENvKSTF0bki+SRyVZkYglVvCdeZv6S1jv0gB/KbnkYTLA0sE1YzcJxiAsMQ111Q jyQmeilt0P5M7G4CyOnurIwkq1AlC1zpVQeQaTIrh8G973+FsxoqayyxrfjqCliEoZpO PBWg13nGRHoDr4/gNX8zbh4xXuS9Au9aL6OOgV7TV00z14zh5hlLrAmBxIkghCqX9Kvg 8b1g== X-Forwarded-Encrypted: i=1; AJvYcCU26UTyUwrDWjfOQUG/T8u32V+x5eE1bLfWYXozlJAWv/ziR7hNkgFYnbQzEWe87qlVhPU9CoZEEUknuTuGxnaHGSKV X-Gm-Message-State: AOJu0YyM0eFmjt73NVYsLa5riharRowYTNPTJnNBDvwWrxLoshHpsG2S 5ALuN+J+WbHRYIJzejAuu0lhywC5o/vcAFT21RkBltU39lJObZQvKGSAGuvuyJ/pCJNeQuK5n1/ 3LQ== X-Google-Smtp-Source: AGHT+IFjEBX6C+7q1SBXQ+tSA4pdjdQXgmJ9UBKLZS/xnmX8tOHGVqK01y9ERowX6ifH4R9/jDDhuoSeDmU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a63:1f64:0:b0:5dc:1c7d:2c75 with SMTP id q36-20020a631f64000000b005dc1c7d2c75mr56894pgm.1.1709912443614; Fri, 08 Mar 2024 07:40:43 -0800 (PST) Date: Fri, 8 Mar 2024 07:40:42 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: Message-ID: Subject: Re: [GIT PULL] KVM/riscv changes for 6.9 From: Sean Christopherson To: Anup Patel Cc: Paolo Bonzini , Palmer Dabbelt , Palmer Dabbelt , Andrew Jones , Atish Patra , Atish Patra , KVM General , "open list:KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv)" , linux-riscv Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 08, 2024, Anup Patel wrote: > On Thu, Mar 7, 2024 at 11:13=E2=80=AFPM Sean Christopherson wrote: > > > > On Thu, Mar 07, 2024, Anup Patel wrote: > > > ---------------------------------------------------------------- > > > KVM/riscv changes for 6.9 > > Uh, what's going on with this series? Many of these were committed *ye= sterday*, > > but you sent a mail on February 12th[1] saying these were queued. That= 's quite > > the lag. > > > > I don't intend to police the RISC-V tree, but this commit caused a conf= lict with > > kvm-x86/selftests[2]. It's a non-issue in this case because it's such = a trivial > > conflict, and we're all quite lax with selftests, but sending a pull re= quest ~12 > > hours after pushing commits that clearly aren't fixes is a bit ridiciul= ous. E.g. > > if this were to happen with a less trivial conflict, the other sub-main= tainer would > > be left doing a late scramble to figure things out just before sending = their own > > pull requests. > > > > tag kvm-riscv-6.9-1 > > Tagger: Anup Patel > > TaggerDate: Thu Mar 7 11:54:34 2024 +0530 > > > > ... > > > > commit d8c0831348e78fdaf67aa95070bae2ef8e819b05 > > Author: Anup Patel > > AuthorDate: Tue Feb 13 13:39:17 2024 +0530 > > Commit: Anup Patel > > CommitDate: Wed Mar 6 20:53:44 2024 +0530 > > > > The other reason this caught my eye is that the conflict happened in co= mmon code, > > but the added helper is RISC-V specific and used only from RISC-V code.= ARM does > > have an identical helper, but AFAICT ARM's helper is only used from ARM= code. > > > > But the prototype of guest_get_vcpuid() is in common code. Which isn't= a huge > > deal, but it's rather undesirable because there's no indication that it= s > > implementation is arch-specific, and trying to use it in code built for= s390 or > > x86 (or MIPS or PPC, which are on the horizon), would fail. I'm all fo= r making > > code common where possible, but going halfway and leaving a trap for ot= her > > architectures makes for a poor experience for developers. > > > > And again, this showing up _so_ late means it's unnecessarily difficult= to clean > > things up. Which is kinda the whole point of getting thing into linux-= next, so > > that folks that weren't involved in the original patch/series can react= if there > > is a hiccup/problem/oddity. >=20 > Sorry for the last minute conflict. >=20 > In all release cycles, the riscv_kvm_queue freezes by rc6 and riscv_kvm_n= ext > is updated at least a week before sending PR. >=20 > In this case there was a crucial last minute bug found in RISC-V arch_tim= er > selftest patches due to which the get-reg-list selftest was broken so I > updated the offending commits in the queue itself before sending out PR. >=20 > I will definitely try my best to avoid such last minute conflict. You're missing the point. I don't care when patches land in the RISC-V tre= e, nor do I care that you made a last minute tweak to fix a bug. I care when comm= its show up in linux-next, and *none* of these commits were in linux-next until yesterday. $ git tag -l --contains 2c5af1c8460376751d57c50af88a053a3b869926 next-20240307 next-20240308 The *entire* purpose of linux-next is to integrate *all* work destined for = the next kernel into a single tree, so that conflicts, bugs, etc. can be found = and fixed *before* the next merge window. Commits should be getting pushed to riscv_kvm_next, i.e. pulled by linux-ne= xt, the instant you are confident they are "stable" and unlikely to be amended.= The entire RISC-V KVM tree showing up in linux-next a week before the merge win= dow opens is *way* too late. >From Documentation/process/howto.rst: - As soon as a new kernel is released a two week window is open, during this period of time maintainers can submit big diffs to Linus, usually the patches that have already been included in the linux-next for a few weeks.=20 ... linux-next integration testing tree ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 Before updates from subsystem trees are merged into the mainline tree, they need to be integration-tested. For this purpose, a special testing repository exists into which virtually all subsystem trees are pulled on an almost daily basis: =20 https://git.kernel.org/?p=3Dlinux/kernel/git/next/linux-next.git =20 This way, the linux-next gives a summary outlook onto what will be expected to go into the mainline kernel at the next merge period. Adventurous testers are very welcome to runtime-test the linux-next. =20 The fact that your tree is based on -rc6 means your entire workflow is flaw= ed. There is almost never a need to to use a release candidate later than -rc2 = as the base, as the odds of there being a fix in Linus' tree aftern -rc2 that = is *absolutely necessary* for testing KVM are vanishingly small. And given that these were "queued" on February 12th, but are now based on -= rc6, means that you reparented them at least once. Rebasing/reparenting is expl= icitly documented as a Bad Idea=E2=84=A2, because for all intents and purposes reb= asing creates a completely new commit, and thus invalidates much of the testing that was = done on the prior incarnation of the branch/commits. E.g. if you make a mistake when rebasing a patch and introduce a bug, bisec= t will point to the rebased commit, despite the fact that as *submitted* and origi= nally applied, the patch was correct. But if you (or more likely Paolo or Linus)= make the same mistake when merging the branch, bisect will point at the merge co= mmit. That is a huge difference, as it pinpoints that the problem wasn't with the= patch itself, but instead with how it was integrated without someone else's work. >From Documentation/maintainer/rebasing-and-merging.rst Rebasing =3D=3D=3D=3D=3D=3D=3D=3D =20 "Rebasing" is the process of changing the history of a series of commits within a repository. There are two different types of operations that ar= e referred to as rebasing since both are done with the ``git rebase`` command, but there are significant differences between them: =20 - Changing the parent (starting) commit upon which a series of patches i= s built. For example, a rebase operation could take a patch set built o= n the previous kernel release and base it, instead, on the current release. We'll call this operation "reparenting" in the discussion below. =20 - Changing the history of a set of patches by fixing (or deleting) broke= n commits, adding patches, adding tags to commit changelogs, or changing the order in which commits are applied. In the following text, this type of operation will be referred to as "history modification" =20 The term "rebasing" will be used to refer to both of the above operations= . Used properly, rebasing can yield a cleaner and clearer development history; used improperly, it can obscure that history and introduce bugs. =20 There are a few rules of thumb that can help developers to avoid the wors= t perils of rebasing: =20 - History that has been exposed to the world beyond your private system should usually not be changed. Others may have pulled a copy of your tree and built on it; modifying your tree will create pain for them. = If work is in need of rebasing, that is usually a sign that it is not yet ready to be committed to a public repository. =20 That said, there are always exceptions. Some trees (linux-next being a significant example) are frequently rebased by their nature, and developers know not to base work on them. Developers will sometimes expose an unstable branch for others to test with or for automated testing services. If you do expose a branch that may be unstable in this way, be sure that prospective users know not to base work on it. =20 - Do not rebase a branch that contains history created by others. If yo= u have pulled changes from another developer's repository, you are now a custodian of their history. You should not change it. With few exceptions, for example, a broken commit in a tree like this should be explicitly reverted rather than disappeared via history modification. =20 - Do not reparent a tree without a good reason to do so. Just being on = a newer base or avoiding a merge with an upstream repository is not generally a good reason. =20 - If you must reparent a repository, do not pick some random kernel comm= it as the new base. The kernel is often in a relatively unstable state between release points; basing development on one of those points increases the chances of running into surprising bugs. When a patch series must move to a new base, pick a stable point (such as one of the -rc releases) to move to. =20 - Realize that reparenting a patch series (or making significant history modifications) changes the environment in which it was developed and, likely, invalidates much of the testing that was done. A reparented patch series should, as a general rule, be treated like new code and retested from the beginning. =20 A frequent cause of merge-window trouble is when Linus is presented with = a patch series that has clearly been reparented, often to a random commit, shortly before the pull request was sent. The chances of such a series having been adequately tested are relatively low - as are the chances of the pull request being acted upon. =20 If, instead, rebasing is limited to private trees, commits are based on a well-known starting point, and they are well tested, the potential for trouble is low.