| Message ID | 20200901141539.1757549-1-npiggin@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Use asm-generic for mmu_context no-op functions | expand |
On Wed, 2 Sep 2020 00:15:16 +1000, Nicholas Piggin wrote: > It would be nice to be able to modify mmu_context functions or add a > hook without updating all architectures, many of which will be no-ops. > > The motivation for this series is a change to lazy mmu handling, but > this series stands on its own as a good cleanup whether or not we end > up making that change. > > [...] Applied to asm-generic, thanks! [01/23] asm-generic: add generic MMU versions of mmu context functions (no commit info) [02/23] alpha: use asm-generic/mmu_context.h for no-op implementations (no commit info) [03/23] arc: use asm-generic/mmu_context.h for no-op implementations (no commit info) [04/23] arm: use asm-generic/mmu_context.h for no-op implementations (no commit info) [05/23] arm64: use asm-generic/mmu_context.h for no-op implementations (no commit info) [06/23] csky: use asm-generic/mmu_context.h for no-op implementations (no commit info) [07/23] hexagon: use asm-generic/mmu_context.h for no-op implementations (no commit info) [08/23] ia64: use asm-generic/mmu_context.h for no-op implementations (no commit info) [09/23] m68k: use asm-generic/mmu_context.h for no-op implementations (no commit info) [10/23] microblaze: use asm-generic/mmu_context.h for no-op implementations (no commit info) [11/23] mips: use asm-generic/mmu_context.h for no-op implementations (no commit info) [12/23] nds32: use asm-generic/mmu_context.h for no-op implementations (no commit info) [13/23] nios2: use asm-generic/mmu_context.h for no-op implementations (no commit info) [14/23] openrisc: use asm-generic/mmu_context.h for no-op implementations (no commit info) [15/23] parisc: use asm-generic/mmu_context.h for no-op implementations (no commit info) [16/23] powerpc: use asm-generic/mmu_context.h for no-op implementations (no commit info) [17/23] riscv: use asm-generic/mmu_context.h for no-op implementations (no commit info) [18/23] s390: use asm-generic/mmu_context.h for no-op implementations (no commit info) [19/23] sh: use asm-generic/mmu_context.h for no-op implementations (no commit info) [20/23] sparc: use asm-generic/mmu_context.h for no-op implementations (no commit info) [21/23] um: use asm-generic/mmu_context.h for no-op implementations (no commit info) [22/23] x86: use asm-generic/mmu_context.h for no-op implementations (no commit info) [23/23] xtensa: use asm-generic/mmu_context.h for no-op implementations (no commit info) Arnd
On Wed, Sep 9, 2020 at 1:27 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Wed, 2 Sep 2020 00:15:16 +1000, Nicholas Piggin wrote: > > It would be nice to be able to modify mmu_context functions or add a > > hook without updating all architectures, many of which will be no-ops. > > > > The motivation for this series is a change to lazy mmu handling, but > > this series stands on its own as a good cleanup whether or not we end > > up making that change. > > > > [...] > > Applied to asm-generic, thanks! Hi Nick, I just noticed a fatal mistake I made when pushing it to the branch on kernel.org: I used to have both a 'master' and an 'asm-generic' branch in asm-generic.git but tried to remove the 'master' one as there is not really any point in having two. Unfortunately I forgot to check which one of the two was part of linux-next, and it was the other one, so none of the patches I picked up ever saw any wider testing aside from the 0day bot building it (successfully). Are there other changes that depend on this? If not, I would just wait until -rc1 and then either push the branch correctly or rebase the patches on that first, to avoid pushing something that did not see the necessary testing. Arnd
Hi Arnd, On Fri, 9 Oct 2020 16:01:22 +0200 Arnd Bergmann <arnd@arndb.de> wrote: > > On Wed, Sep 9, 2020 at 1:27 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > > On Wed, 2 Sep 2020 00:15:16 +1000, Nicholas Piggin wrote: > > > It would be nice to be able to modify mmu_context functions or add a > > > hook without updating all architectures, many of which will be no-ops. > > > > > > The motivation for this series is a change to lazy mmu handling, but > > > this series stands on its own as a good cleanup whether or not we end > > > up making that change. > > > > > > [...] > > > > Applied to asm-generic, thanks! > > Hi Nick, > > I just noticed a fatal mistake I made when pushing it to the branch on > kernel.org: I used to have both a 'master' and an 'asm-generic' branch > in asm-generic.git but tried to remove the 'master' one as there is not > really any point in having two. > > Unfortunately I forgot to check which one of the two was part of > linux-next, and it was the other one, so none of the patches I picked > up ever saw any wider testing aside from the 0day bot building it > (successfully). > > Are there other changes that depend on this? If not, I would > just wait until -rc1 and then either push the branch correctly or > rebase the patches on that first, to avoid pushing something that > did not see the necessary testing. If it is useful enough (or important enough), then put in in your linux-next included branch, but don't ask Linus to merge it until the second week of the merge window ... no worse than some other stuff I see :-(
On Sat, Oct 10, 2020 at 4:02 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > On Fri, 9 Oct 2020 16:01:22 +0200 Arnd Bergmann <arnd@arndb.de> wrote: > > > Are there other changes that depend on this? If not, I would > > just wait until -rc1 and then either push the branch correctly or > > rebase the patches on that first, to avoid pushing something that > > did not see the necessary testing. > > If it is useful enough (or important enough), then put in in your > linux-next included branch, but don't ask Linus to merge it until the > second week of the merge window ... no worse than some other stuff I > see :-( By itself, it's a nice cleanup, but it doesn't provide any immediate benefit over the previous state, while potentially introducing a regression in one of the less tested architectures. The question to me is really whether Nick has any pending work that he would like to submit after this branch is merged into mainline. Arnd
Hi Arnd, On Sat, 10 Oct 2020 10:25:11 +0200 Arnd Bergmann <arnd@arndb.de> wrote: > > On Sat, Oct 10, 2020 at 4:02 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Fri, 9 Oct 2020 16:01:22 +0200 Arnd Bergmann <arnd@arndb.de> wrote: > > > > > Are there other changes that depend on this? If not, I would > > > just wait until -rc1 and then either push the branch correctly or > > > rebase the patches on that first, to avoid pushing something that > > > did not see the necessary testing. > > > > If it is useful enough (or important enough), then put in in your > > linux-next included branch, but don't ask Linus to merge it until the > > second week of the merge window ... no worse than some other stuff I > > see :-( > > By itself, it's a nice cleanup, but it doesn't provide any immediate > benefit over the previous state, while potentially introducing a > regression in one of the less tested architectures. OK. > The question to me is really whether Nick has any pending work > that he would like to submit after this branch is merged into > mainline.
Excerpts from Arnd Bergmann's message of October 10, 2020 6:25 pm: > On Sat, Oct 10, 2020 at 4:02 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: >> On Fri, 9 Oct 2020 16:01:22 +0200 Arnd Bergmann <arnd@arndb.de> wrote: >> >> > Are there other changes that depend on this? If not, I would >> > just wait until -rc1 and then either push the branch correctly or >> > rebase the patches on that first, to avoid pushing something that >> > did not see the necessary testing. >> >> If it is useful enough (or important enough), then put in in your >> linux-next included branch, but don't ask Linus to merge it until the >> second week of the merge window ... no worse than some other stuff I >> see :-( > > By itself, it's a nice cleanup, but it doesn't provide any immediate > benefit over the previous state, while potentially introducing a > regression in one of the less tested architectures. > > The question to me is really whether Nick has any pending work > that he would like to submit after this branch is merged into > mainline. Not for this merge window but I was hoping to submit something for improving lazy tlb handling in the next one. Thanks, Nick