| Message ID | cover.11189864684e31260d1408779fac9db80122047b.1736488799.git-series.apopple@nvidia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | fs/dax: Fix ZONE_DEVICE page reference counts | expand |
Alistair Popple wrote: > Main updates since v5: > > - Reworked patch 1 based on Dan's feedback. > > - Fixed build issues on PPC and when CONFIG_PGTABLE_HAS_HUGE_LEAVES > is no defined. > > - Minor comment formatting and documentation fixes. > > - Remove PTE_DEVMAP definitions from Loongarch which were added since > this series was initially written. [..] > > base-commit: e25c8d66f6786300b680866c0e0139981273feba If this is going to go through nvdimm.git I will need it against a mainline tag baseline. Linus will want to see the merge conflicts. Otherwise if that merge commit is too messy, or you would rather not rebase, then it either needs to go one of two options: - Andrew's tree which is the only tree I know of that can carry patches relative to linux-next. - Wait for v6.14-rc1 and get this into nvdimm.git early in the cycle when the conflict storm will be low. Last I attempted the merge conflict resolution with v4, they were not *that* bad. However, that rebase may need to keep some definitions around to avoid compile breakage and the need to expand the merge commit to carrying things like the Loongarch PTE_DEVMAP removal. I.e. move some of the after-the-fact cleanups to a post merge branch.
On Thu, 9 Jan 2025 23:05:56 -0800 Dan Williams <dan.j.williams@intel.com> wrote: > > - Remove PTE_DEVMAP definitions from Loongarch which were added since > > this series was initially written. > [..] > > > > base-commit: e25c8d66f6786300b680866c0e0139981273feba > > If this is going to go through nvdimm.git I will need it against a > mainline tag baseline. Linus will want to see the merge conflicts. > > Otherwise if that merge commit is too messy, or you would rather not > rebase, then it either needs to go one of two options: > > - Andrew's tree which is the only tree I know of that can carry > patches relative to linux-next. I used to be able to do that but haven't got around to setting up such a thing with mm.git. This is the first time the need has arisen, really. > - Wait for v6.14-rc1 I'm thinking so. Darrick's review comments indicate that we'll be seeing a v7. > and get this into nvdimm.git early in the cycle > when the conflict storm will be low. erk. This patchset hits mm/ a lot, and nvdimm hardly at all. Is it not practical to carry this in mm.git?
Andrew Morton wrote: > On Thu, 9 Jan 2025 23:05:56 -0800 Dan Williams <dan.j.williams@intel.com> wrote: > > > > - Remove PTE_DEVMAP definitions from Loongarch which were added since > > > this series was initially written. > > [..] > > > > > > base-commit: e25c8d66f6786300b680866c0e0139981273feba > > > > If this is going to go through nvdimm.git I will need it against a > > mainline tag baseline. Linus will want to see the merge conflicts. > > > > Otherwise if that merge commit is too messy, or you would rather not > > rebase, then it either needs to go one of two options: > > > > - Andrew's tree which is the only tree I know of that can carry > > patches relative to linux-next. > > I used to be able to do that but haven't got around to setting up such > a thing with mm.git. This is the first time the need has arisen, > really. Oh, good to know. > > > - Wait for v6.14-rc1 > > I'm thinking so. Darrick's review comments indicate that we'll be seeing a v7. > > > and get this into nvdimm.git early in the cycle > > when the conflict storm will be low. > > erk. This patchset hits mm/ a lot, and nvdimm hardly at all. Is it > not practical to carry this in mm.git? I'm totally fine with it going through mm.git. nvdimm.git is just the historical path for touches to fs/dax.c, and git blame points mostly to me for the issues Alistair is fixing. I am happy to review and ack and watch this go through mm.git.
On Fri, Jan 10, 2025 at 07:35:57PM -0800, Dan Williams wrote: > Andrew Morton wrote: > > On Thu, 9 Jan 2025 23:05:56 -0800 Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > - Remove PTE_DEVMAP definitions from Loongarch which were added since > > > > this series was initially written. > > > [..] > > > > > > > > base-commit: e25c8d66f6786300b680866c0e0139981273feba > > > > > > If this is going to go through nvdimm.git I will need it against a > > > mainline tag baseline. Linus will want to see the merge conflicts. > > > > > > Otherwise if that merge commit is too messy, or you would rather not > > > rebase, then it either needs to go one of two options: > > > > > > - Andrew's tree which is the only tree I know of that can carry > > > patches relative to linux-next. > > > > I used to be able to do that but haven't got around to setting up such > > a thing with mm.git. This is the first time the need has arisen, > > really. > > Oh, good to know. > > > > > > - Wait for v6.14-rc1 > > > > I'm thinking so. Darrick's review comments indicate that we'll be seeing a v7. I'm ok with that. It could do with a decent soak in linux-next anyway given it touches a lot of mm and fs. Once v6.14-rc1 is released I will do a rebase on top of that. > > > and get this into nvdimm.git early in the cycle > > > when the conflict storm will be low. > > > > erk. This patchset hits mm/ a lot, and nvdimm hardly at all. Is it > > not practical to carry this in mm.git? > > I'm totally fine with it going through mm.git. nvdimm.git is just the > historical path for touches to fs/dax.c, and git blame points mostly to > me for the issues Alistair is fixing. I am happy to review and ack and > watch this go through mm.git.