* mm/thp commits: please wait a few days @ 2021-06-16 23:02 Hugh Dickins 2021-06-17 4:51 ` Greg Kroah-Hartman 0 siblings, 1 reply; 15+ messages in thread From: Hugh Dickins @ 2021-06-16 23:02 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Sasha Levin, Hugh Dickins, stable Hi Greg, Linus has taken in a group of mm/thp commits Cc stable today: 504e070dc08f mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split 22061a1ffabd mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page() 31657170deaf mm/thp: fix page_address_in_vma() on file THP tails 494334e43c16 mm/thp: fix vma_address() if virtual address below file offset 732ed55823fc mm/thp: try_to_unmap() use TTU_SYNC for safe splitting 3b77e8c8cde5 mm/thp: make is_huge_zero_pmd() safe and quicker 99fa8a48203d mm/thp: fix __split_huge_pmd_locked() on shmem migration entry ffc90cbb2970 mm, thp: use head page in __migration_entry_wait() and I expect some more to follow in a few days time (thanks Andrew). No problem with the commits themselves, but I'm aware that some of them have dependencies on other commits not yet in stable, which I have to sort out for you now. I'd prefer to avoid a deluge of "does not apply" messages, so ask you please to hold off trying to merge these into stable trees for a few days: I'll get back to you with what's needed for them to apply. Thanks, Hugh ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-16 23:02 mm/thp commits: please wait a few days Hugh Dickins @ 2021-06-17 4:51 ` Greg Kroah-Hartman 2021-06-23 14:58 ` Greg Kroah-Hartman 0 siblings, 1 reply; 15+ messages in thread From: Greg Kroah-Hartman @ 2021-06-17 4:51 UTC (permalink / raw) To: Hugh Dickins Cc: Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Sasha Levin, stable On Wed, Jun 16, 2021 at 04:02:32PM -0700, Hugh Dickins wrote: > Hi Greg, > > Linus has taken in a group of mm/thp commits Cc stable today: > > 504e070dc08f mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split > 22061a1ffabd mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page() > 31657170deaf mm/thp: fix page_address_in_vma() on file THP tails > 494334e43c16 mm/thp: fix vma_address() if virtual address below file offset > 732ed55823fc mm/thp: try_to_unmap() use TTU_SYNC for safe splitting > 3b77e8c8cde5 mm/thp: make is_huge_zero_pmd() safe and quicker > 99fa8a48203d mm/thp: fix __split_huge_pmd_locked() on shmem migration entry > ffc90cbb2970 mm, thp: use head page in __migration_entry_wait() > > and I expect some more to follow in a few days time (thanks Andrew). > > No problem with the commits themselves, but I'm aware that some of them > have dependencies on other commits not yet in stable, which I have to > sort out for you now. > > I'd prefer to avoid a deluge of "does not apply" messages, so ask you > please to hold off trying to merge these into stable trees for a few days: > I'll get back to you with what's needed for them to apply. Not a problem, thanks for the heads up, I'll restrain from running my scripts on the above patches until you say it's safe to :) greg k-h ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-17 4:51 ` Greg Kroah-Hartman @ 2021-06-23 14:58 ` Greg Kroah-Hartman 2021-06-23 16:44 ` Hugh Dickins 0 siblings, 1 reply; 15+ messages in thread From: Greg Kroah-Hartman @ 2021-06-23 14:58 UTC (permalink / raw) To: Hugh Dickins Cc: Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Sasha Levin, stable On Thu, Jun 17, 2021 at 06:51:44AM +0200, Greg Kroah-Hartman wrote: > On Wed, Jun 16, 2021 at 04:02:32PM -0700, Hugh Dickins wrote: > > Hi Greg, > > > > Linus has taken in a group of mm/thp commits Cc stable today: > > > > 504e070dc08f mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split > > 22061a1ffabd mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page() > > 31657170deaf mm/thp: fix page_address_in_vma() on file THP tails > > 494334e43c16 mm/thp: fix vma_address() if virtual address below file offset > > 732ed55823fc mm/thp: try_to_unmap() use TTU_SYNC for safe splitting > > 3b77e8c8cde5 mm/thp: make is_huge_zero_pmd() safe and quicker > > 99fa8a48203d mm/thp: fix __split_huge_pmd_locked() on shmem migration entry > > ffc90cbb2970 mm, thp: use head page in __migration_entry_wait() > > > > and I expect some more to follow in a few days time (thanks Andrew). > > > > No problem with the commits themselves, but I'm aware that some of them > > have dependencies on other commits not yet in stable, which I have to > > sort out for you now. > > > > I'd prefer to avoid a deluge of "does not apply" messages, so ask you > > please to hold off trying to merge these into stable trees for a few days: > > I'll get back to you with what's needed for them to apply. > > Not a problem, thanks for the heads up, I'll restrain from running my > scripts on the above patches until you say it's safe to :) Any word on this? thanks, greg k-h ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-23 14:58 ` Greg Kroah-Hartman @ 2021-06-23 16:44 ` Hugh Dickins 2021-06-23 16:53 ` Greg Kroah-Hartman 2021-06-23 20:46 ` Andrew Morton 0 siblings, 2 replies; 15+ messages in thread From: Hugh Dickins @ 2021-06-23 16:44 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Hugh Dickins, Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Sasha Levin, stable On Wed, 23 Jun 2021, Greg Kroah-Hartman wrote: > On Thu, Jun 17, 2021 at 06:51:44AM +0200, Greg Kroah-Hartman wrote: > > On Wed, Jun 16, 2021 at 04:02:32PM -0700, Hugh Dickins wrote: > > > Hi Greg, > > > > > > Linus has taken in a group of mm/thp commits Cc stable today: > > > > > > 504e070dc08f mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split > > > 22061a1ffabd mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page() > > > 31657170deaf mm/thp: fix page_address_in_vma() on file THP tails > > > 494334e43c16 mm/thp: fix vma_address() if virtual address below file offset > > > 732ed55823fc mm/thp: try_to_unmap() use TTU_SYNC for safe splitting > > > 3b77e8c8cde5 mm/thp: make is_huge_zero_pmd() safe and quicker > > > 99fa8a48203d mm/thp: fix __split_huge_pmd_locked() on shmem migration entry > > > ffc90cbb2970 mm, thp: use head page in __migration_entry_wait() > > > > > > and I expect some more to follow in a few days time (thanks Andrew). > > > > > > No problem with the commits themselves, but I'm aware that some of them > > > have dependencies on other commits not yet in stable, which I have to > > > sort out for you now. > > > > > > I'd prefer to avoid a deluge of "does not apply" messages, so ask you > > > please to hold off trying to merge these into stable trees for a few days: > > > I'll get back to you with what's needed for them to apply. > > > > Not a problem, thanks for the heads up, I'll restrain from running my > > scripts on the above patches until you say it's safe to :) > > Any word on this? I have a "matrix" of what's needed ready, but I'm still waiting on "I expect some more to follow in a few days time (thanks Andrew)": I believe akpm does still intend to send them in to Linus for 5.13 this week, but they've not gone yet. So eleven don't yet have SHA1s (of SignOffs by Linus) to include. Ten of them (I'm calling pvmw1 through pvmw10) are progressive mods to one function page_vma_mapped_walk(), which were split off from the previous patches to help review. Those ones are easy: they all apply cleanly to all releases in which they are needed, so no special backports from me required. But there's a final futex-pgoff one, which does not apply cleanly to 5.4 or 4.9: so that one I do have to send you variants of, and cannot until it's in Linus's tree. You could proceed with just the first eight already in the tree; but it's all (bar the last) part of the same collection of fixes. I think better to keep them together - unless Andrew or Linus prefers to hold the eleven back until 5.14-rc. Here's the "matrix" and notes I assembled for your delectation (and I verified yesterday that your latest releases do not add any complications); but I'm not yet attaching the tarball of variants, which I expect to update for futex-pgoff when it goes in. 5.12.12 5.10.45 5.4.127 4.19.195 4.14.237 4.9.273 4.14/0001 << chpick 5.10/0001 << chpick << chpick << chpick << chpick 5.10/0002 << chpick << chpick << chpick 5.10/0003 << chpick << chpick << chpick ffc90cbb2970 << chpick << chpick 99fa8a48203d 5.10/0005 << chpick << chpick 3b77e8c8cde5 << chpick << chpick << chpick 732ed55823fc << chpick 5.04/0007 << chpick << chpick 494334e43c16 << chpick 5.04/0008 4.19/0007 << chpick 31657170deaf << chpick << chpick << chpick << chpick 22061a1ffabd 5.10/0010 5.04/0010 << chpick 504e070dc08f 5.10/0011 5.04/0011 4.19/0010 4.14/0008 4.09/0003 pvmw1-pvmw10 << chpick << chpick << chpick << chpick futex-pgoff << chpick 5.04/0022 << chpick << chpick 4.09/0004 Already in 5.13-rc7: ffc90cbb2970 mm, thp: use head page in __migration_entry_wait() 99fa8a48203d mm/thp: fix __split_huge_pmd_locked() on shmem migration entry 3b77e8c8cde5 mm/thp: make is_huge_zero_pmd() safe and quicker 732ed55823fc mm/thp: try_to_unmap() use TTU_SYNC for safe splitting 494334e43c16 mm/thp: fix vma_address() if virtual address below file offset 31657170deaf mm/thp: fix page_address_in_vma() on file THP tails 22061a1ffabd mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page() 504e070dc08f mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split Expected in 5.13 final: pvmw1 mm: page_vma_mapped_walk(): use page for pvmw->page pvmw2 mm: page_vma_mapped_walk(): settle PageHuge on entry pvmw3 mm: page_vma_mapped_walk(): use pmde for *pvmw->pmd pvmw4 mm: page_vma_mapped_walk(): prettify PVMW_MIGRATION block pvmw5 mm: page_vma_mapped_walk(): crossing page table boundary pvmw6 mm: page_vma_mapped_walk(): add a level of indentation pvmw7 mm: page_vma_mapped_walk(): use goto instead of while (1) pvmw8 mm: page_vma_mapped_walk(): get vma_address_end() earlier pvmw9 mm/thp: fix page_vma_mapped_walk() if THP mapped by ptes pvmw10 mm/thp: another PVMW_SYNC fix in page_vma_mapped_walk() futex-pgoff mm, futex: fix shared futex pgoff on shmem huge page Antecedents which get added into some older kernels: 4.14/0001 91241681c62a include/linux/mmdebug.h: make VM_WARN* non-rvals 5.10/0001 a4055888629b (part) mm: add VM_WARN_ON_ONCE_PAGE() macro 5.10/0002 e0af87ff7afc mm/rmap: remove unneeded semicolon in page_not_mapped() 5.10/0003 b7e188ec98b1 mm/rmap: use page_not_mapped in try_to_unmap() Nothing special for 5.12.12: all 19 can be cherry-picked cleanly. Antecedents and fixedups for 5.10.45 and older: 5.10/0001-mm-add-VM_WARN_ON_ONCE_PAGE-macro.patch 5.10/0002-mm-rmap-remove-unneeded-semicolon-in-page_not_mapped.patch 5.10/0003-mm-rmap-use-page_not_mapped-in-try_to_unmap.patch 5.10/0005-mm-thp-fix-__split_huge_pmd_locked-on-shmem-migratio.patch 5.10/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch 5.10/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch Fixedups for 5.4.127 and older: 5.04/0007-mm-thp-try_to_unmap-use-TTU_SYNC-for-safe-splitting.patch 5.04/0008-mm-thp-fix-vma_address-if-virtual-address-below-file.patch 5.04/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch 5.04/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch 5.04/0022-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch Fixedups for 4.19.195 and older: 4.19/0007-mm-thp-fix-vma_address-if-virtual-address-below-file.patch 4.19/0010-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch (Why does matrix say not to port ffc90cbb2970 "use head page" to 4.19 and older? It is correct, and would apply to them: but they do not have put_and_wait_on_page_locked(), so it may behave worse on them.) Antecedent and fixedup for 4.14.237 and older: 4.14/0001-include-linux-mmdebug.h-make-VM_WARN-non-rvals.patch 4.14/0008-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch Fixedups for 4.9.273: 4.09/0003-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch 4.09/0004-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch No backports to 4.4.273: it's too old and different for these. Does that make sense to you? Hugh ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-23 16:44 ` Hugh Dickins @ 2021-06-23 16:53 ` Greg Kroah-Hartman 2021-06-23 20:46 ` Andrew Morton 1 sibling, 0 replies; 15+ messages in thread From: Greg Kroah-Hartman @ 2021-06-23 16:53 UTC (permalink / raw) To: Hugh Dickins Cc: Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Sasha Levin, stable On Wed, Jun 23, 2021 at 09:44:14AM -0700, Hugh Dickins wrote: > On Wed, 23 Jun 2021, Greg Kroah-Hartman wrote: > > On Thu, Jun 17, 2021 at 06:51:44AM +0200, Greg Kroah-Hartman wrote: > > > On Wed, Jun 16, 2021 at 04:02:32PM -0700, Hugh Dickins wrote: > > > > Hi Greg, > > > > > > > > Linus has taken in a group of mm/thp commits Cc stable today: > > > > > > > > 504e070dc08f mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split > > > > 22061a1ffabd mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page() > > > > 31657170deaf mm/thp: fix page_address_in_vma() on file THP tails > > > > 494334e43c16 mm/thp: fix vma_address() if virtual address below file offset > > > > 732ed55823fc mm/thp: try_to_unmap() use TTU_SYNC for safe splitting > > > > 3b77e8c8cde5 mm/thp: make is_huge_zero_pmd() safe and quicker > > > > 99fa8a48203d mm/thp: fix __split_huge_pmd_locked() on shmem migration entry > > > > ffc90cbb2970 mm, thp: use head page in __migration_entry_wait() > > > > > > > > and I expect some more to follow in a few days time (thanks Andrew). > > > > > > > > No problem with the commits themselves, but I'm aware that some of them > > > > have dependencies on other commits not yet in stable, which I have to > > > > sort out for you now. > > > > > > > > I'd prefer to avoid a deluge of "does not apply" messages, so ask you > > > > please to hold off trying to merge these into stable trees for a few days: > > > > I'll get back to you with what's needed for them to apply. > > > > > > Not a problem, thanks for the heads up, I'll restrain from running my > > > scripts on the above patches until you say it's safe to :) > > > > Any word on this? > > I have a "matrix" of what's needed ready, but I'm still waiting on > "I expect some more to follow in a few days time (thanks Andrew)": > I believe akpm does still intend to send them in to Linus for 5.13 > this week, but they've not gone yet. > > So eleven don't yet have SHA1s (of SignOffs by Linus) to include. > Ten of them (I'm calling pvmw1 through pvmw10) are progressive > mods to one function page_vma_mapped_walk(), which were split off > from the previous patches to help review. Those ones are easy: > they all apply cleanly to all releases in which they are needed, > so no special backports from me required. > > But there's a final futex-pgoff one, which does not apply cleanly > to 5.4 or 4.9: so that one I do have to send you variants of, and > cannot until it's in Linus's tree. > > You could proceed with just the first eight already in the tree; > but it's all (bar the last) part of the same collection of fixes. > I think better to keep them together - unless Andrew or Linus > prefers to hold the eleven back until 5.14-rc. > > Here's the "matrix" and notes I assembled for your delectation > (and I verified yesterday that your latest releases do not add any > complications); but I'm not yet attaching the tarball of variants, > which I expect to update for futex-pgoff when it goes in. > > 5.12.12 5.10.45 5.4.127 4.19.195 4.14.237 4.9.273 > 4.14/0001 << chpick > 5.10/0001 << chpick << chpick << chpick << chpick > 5.10/0002 << chpick << chpick << chpick > 5.10/0003 << chpick << chpick << chpick > ffc90cbb2970 << chpick << chpick > 99fa8a48203d 5.10/0005 << chpick << chpick > 3b77e8c8cde5 << chpick << chpick << chpick > 732ed55823fc << chpick 5.04/0007 << chpick << chpick > 494334e43c16 << chpick 5.04/0008 4.19/0007 << chpick > 31657170deaf << chpick << chpick << chpick << chpick > 22061a1ffabd 5.10/0010 5.04/0010 << chpick > 504e070dc08f 5.10/0011 5.04/0011 4.19/0010 4.14/0008 4.09/0003 > pvmw1-pvmw10 << chpick << chpick << chpick << chpick > futex-pgoff << chpick 5.04/0022 << chpick << chpick 4.09/0004 > > Already in 5.13-rc7: > ffc90cbb2970 mm, thp: use head page in __migration_entry_wait() > 99fa8a48203d mm/thp: fix __split_huge_pmd_locked() on shmem migration entry > 3b77e8c8cde5 mm/thp: make is_huge_zero_pmd() safe and quicker > 732ed55823fc mm/thp: try_to_unmap() use TTU_SYNC for safe splitting > 494334e43c16 mm/thp: fix vma_address() if virtual address below file offset > 31657170deaf mm/thp: fix page_address_in_vma() on file THP tails > 22061a1ffabd mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page() > 504e070dc08f mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split > > Expected in 5.13 final: > pvmw1 mm: page_vma_mapped_walk(): use page for pvmw->page > pvmw2 mm: page_vma_mapped_walk(): settle PageHuge on entry > pvmw3 mm: page_vma_mapped_walk(): use pmde for *pvmw->pmd > pvmw4 mm: page_vma_mapped_walk(): prettify PVMW_MIGRATION block > pvmw5 mm: page_vma_mapped_walk(): crossing page table boundary > pvmw6 mm: page_vma_mapped_walk(): add a level of indentation > pvmw7 mm: page_vma_mapped_walk(): use goto instead of while (1) > pvmw8 mm: page_vma_mapped_walk(): get vma_address_end() earlier > pvmw9 mm/thp: fix page_vma_mapped_walk() if THP mapped by ptes > pvmw10 mm/thp: another PVMW_SYNC fix in page_vma_mapped_walk() > futex-pgoff mm, futex: fix shared futex pgoff on shmem huge page > > Antecedents which get added into some older kernels: > 4.14/0001 91241681c62a include/linux/mmdebug.h: make VM_WARN* non-rvals > 5.10/0001 a4055888629b (part) mm: add VM_WARN_ON_ONCE_PAGE() macro > 5.10/0002 e0af87ff7afc mm/rmap: remove unneeded semicolon in page_not_mapped() > 5.10/0003 b7e188ec98b1 mm/rmap: use page_not_mapped in try_to_unmap() > > Nothing special for 5.12.12: all 19 can be cherry-picked cleanly. > > Antecedents and fixedups for 5.10.45 and older: > 5.10/0001-mm-add-VM_WARN_ON_ONCE_PAGE-macro.patch > 5.10/0002-mm-rmap-remove-unneeded-semicolon-in-page_not_mapped.patch > 5.10/0003-mm-rmap-use-page_not_mapped-in-try_to_unmap.patch > 5.10/0005-mm-thp-fix-__split_huge_pmd_locked-on-shmem-migratio.patch > 5.10/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch > 5.10/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > > Fixedups for 5.4.127 and older: > 5.04/0007-mm-thp-try_to_unmap-use-TTU_SYNC-for-safe-splitting.patch > 5.04/0008-mm-thp-fix-vma_address-if-virtual-address-below-file.patch > 5.04/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch > 5.04/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > 5.04/0022-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch > > Fixedups for 4.19.195 and older: > 4.19/0007-mm-thp-fix-vma_address-if-virtual-address-below-file.patch > 4.19/0010-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > > (Why does matrix say not to port ffc90cbb2970 "use head page" to 4.19 > and older? It is correct, and would apply to them: but they do not > have put_and_wait_on_page_locked(), so it may behave worse on them.) > > Antecedent and fixedup for 4.14.237 and older: > 4.14/0001-include-linux-mmdebug.h-make-VM_WARN-non-rvals.patch > 4.14/0008-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > > Fixedups for 4.9.273: > 4.09/0003-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > 4.09/0004-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch > > No backports to 4.4.273: it's too old and different for these. > > Does that make sense to you? Thanks for the information, yes this makes sense. I'll wait until it all "lands properly" in Linus's tree, there's no rush from me, I just wanted to make sure these did not get lost somewhere. thanks so much. greg k-h ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-23 16:44 ` Hugh Dickins 2021-06-23 16:53 ` Greg Kroah-Hartman @ 2021-06-23 20:46 ` Andrew Morton 2021-06-23 21:52 ` Hugh Dickins 1 sibling, 1 reply; 15+ messages in thread From: Andrew Morton @ 2021-06-23 20:46 UTC (permalink / raw) To: Hugh Dickins Cc: Greg Kroah-Hartman, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Sasha Levin, stable On Wed, 23 Jun 2021 09:44:14 -0700 (PDT) Hugh Dickins <hughd@google.com> wrote: > > Any word on this? > > I have a "matrix" of what's needed ready, but I'm still waiting on > "I expect some more to follow in a few days time (thanks Andrew)": > I believe akpm does still intend to send them in to Linus for 5.13 > this week, but they've not gone yet. I'm planning on sending these: mm-page_vma_mapped_walk-use-page-for-pvmw-page.patch mm-page_vma_mapped_walk-settle-pagehuge-on-entry.patch mm-page_vma_mapped_walk-use-pmde-for-pvmw-pmd.patch mm-page_vma_mapped_walk-prettify-pvmw_migration-block.patch mm-page_vma_mapped_walk-crossing-page-table-boundary.patch mm-page_vma_mapped_walk-add-a-level-of-indentation.patch mm-page_vma_mapped_walk-add-a-level-of-indentation-fix.patch mm-page_vma_mapped_walk-use-goto-instead-of-while-1.patch mm-page_vma_mapped_walk-get-vma_address_end-earlier.patch mm-thp-fix-page_vma_mapped_walk-if-thp-mapped-by-ptes.patch mm-thp-another-pvmw_sync-fix-in-page_vma_mapped_walk.patch Linuswards tomorrow. Is that OK? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-23 20:46 ` Andrew Morton @ 2021-06-23 21:52 ` Hugh Dickins 2021-06-26 0:38 ` Hugh Dickins 0 siblings, 1 reply; 15+ messages in thread From: Hugh Dickins @ 2021-06-23 21:52 UTC (permalink / raw) To: Andrew Morton Cc: Hugh Dickins, Greg Kroah-Hartman, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Sasha Levin, stable On Wed, 23 Jun 2021, Andrew Morton wrote: > On Wed, 23 Jun 2021 09:44:14 -0700 (PDT) Hugh Dickins <hughd@google.com> wrote: > > > > Any word on this? > > > > I have a "matrix" of what's needed ready, but I'm still waiting on > > "I expect some more to follow in a few days time (thanks Andrew)": > > I believe akpm does still intend to send them in to Linus for 5.13 > > this week, but they've not gone yet. > > I'm planning on sending these: > > mm-page_vma_mapped_walk-use-page-for-pvmw-page.patch > mm-page_vma_mapped_walk-settle-pagehuge-on-entry.patch > mm-page_vma_mapped_walk-use-pmde-for-pvmw-pmd.patch > mm-page_vma_mapped_walk-prettify-pvmw_migration-block.patch > mm-page_vma_mapped_walk-crossing-page-table-boundary.patch > mm-page_vma_mapped_walk-add-a-level-of-indentation.patch > mm-page_vma_mapped_walk-add-a-level-of-indentation-fix.patch I expect you'll fold that^ one into the previous before sending. > mm-page_vma_mapped_walk-use-goto-instead-of-while-1.patch > mm-page_vma_mapped_walk-get-vma_address_end-earlier.patch > mm-thp-fix-page_vma_mapped_walk-if-thp-mapped-by-ptes.patch > mm-thp-another-pvmw_sync-fix-in-page_vma_mapped_walk.patch mmotm's series shows mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page-fix.patch in the same "mainline-later" grouping, reviewed by Matthew, acked by tglx, so I was hoping you'd send that along too. > > Linuswards tomorrow. Is that OK? That's great, thanks Andrew. Then when they appear in Linus's tree, I'll complete my notes and tarball, and mail GregKH in reply here. Hugh ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-23 21:52 ` Hugh Dickins @ 2021-06-26 0:38 ` Hugh Dickins 2021-06-28 12:17 ` Greg Kroah-Hartman 0 siblings, 1 reply; 15+ messages in thread From: Hugh Dickins @ 2021-06-26 0:38 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Andrew Morton, Hugh Dickins, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Sasha Levin, Alex Shi, Miaohe Lin, Michal Hocko, stable [-- Attachment #1: Type: text/plain, Size: 5136 bytes --] On Wed, 23 Jun 2021, Hugh Dickins wrote: > On Wed, 23 Jun 2021, Andrew Morton wrote: > > On Wed, 23 Jun 2021 09:44:14 -0700 (PDT) Hugh Dickins <hughd@google.com> wrote: > > > > > > Any word on this? > > > > > > I have a "matrix" of what's needed ready, but I'm still waiting on > > > "I expect some more to follow in a few days time (thanks Andrew)": > > > I believe akpm does still intend to send them in to Linus for 5.13 > > > this week, but they've not gone yet. > > > > Linuswards tomorrow. Is that OK? > > That's great, thanks Andrew. Then when they appear in Linus's tree, > I'll complete my notes and tarball, and mail GregKH in reply here. All in now, thanks: so attached is a tarball of the variants, and here the finalized summary of what each stable needs. 5.12.13 5.10.46 5.4.128 4.19.195 4.14.237 4.9.273 4.14/0001 << chpick 5.10/0001 << chpick << chpick << chpick << chpick 5.10/0002 << chpick << chpick << chpick 5.10/0003 << chpick << chpick << chpick ffc90cbb2970 << chpick << chpick 99fa8a48203d 5.10/0005 << chpick << chpick 3b77e8c8cde5 << chpick << chpick << chpick 732ed55823fc << chpick 5.04/0007 << chpick << chpick 494334e43c16 << chpick 5.04/0008 4.19/0007 << chpick 31657170deaf << chpick << chpick << chpick << chpick 22061a1ffabd 5.10/0010 5.04/0010 << chpick 504e070dc08f 5.10/0011 5.04/0011 4.19/0010 4.14/0008 4.09/0003 f003c03^..a7a69d8 chpick << chpick << chpick << chpick fe19bd3dae3d << chpick 5.04/0022 << chpick << chpick 4.09/0004 19 recent THP-related upstream commits for 5.13: ffc90cbb2970 mm, thp: use head page in __migration_entry_wait() 99fa8a48203d mm/thp: fix __split_huge_pmd_locked() on shmem migration entry 3b77e8c8cde5 mm/thp: make is_huge_zero_pmd() safe and quicker 732ed55823fc mm/thp: try_to_unmap() use TTU_SYNC for safe splitting 494334e43c16 mm/thp: fix vma_address() if virtual address below file offset 31657170deaf mm/thp: fix page_address_in_vma() on file THP tails 22061a1ffabd mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page() 504e070dc08f mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split f003c03bd29e mm: page_vma_mapped_walk(): use page for pvmw->page 6d0fd5987657 mm: page_vma_mapped_walk(): settle PageHuge on entry 3306d3119cea mm: page_vma_mapped_walk(): use pmde for *pvmw->pmd e2e1d4076c77 mm: page_vma_mapped_walk(): prettify PVMW_MIGRATION block 448282487483 mm: page_vma_mapped_walk(): crossing page table boundary b3807a91aca7 mm: page_vma_mapped_walk(): add a level of indentation 474466301dfd mm: page_vma_mapped_walk(): use goto instead of while (1) a765c417d876 mm: page_vma_mapped_walk(): get vma_address_end() earlier a9a7504d9bea mm/thp: fix page_vma_mapped_walk() if THP mapped by ptes a7a69d8ba88d mm/thp: another PVMW_SYNC fix in page_vma_mapped_walk() fe19bd3dae3d mm, futex: fix shared futex pgoff on shmem huge page Antecedents which get added into some older kernels: 4.14/0001 91241681c62a include/linux/mmdebug.h: make VM_WARN* non-rvals 5.10/0001 a4055888629b (part) mm: add VM_WARN_ON_ONCE_PAGE() macro 5.10/0002 e0af87ff7afc mm/rmap: remove unneeded semicolon in page_not_mapped() 5.10/0003 b7e188ec98b1 mm/rmap: use page_not_mapped in try_to_unmap() Nothing special for 5.12.13: all 19 can be cherry-picked cleanly. Antecedents and fixedups for 5.10.46 and older: 5.10/0001-mm-add-VM_WARN_ON_ONCE_PAGE-macro.patch 5.10/0002-mm-rmap-remove-unneeded-semicolon-in-page_not_mapped.patch 5.10/0003-mm-rmap-use-page_not_mapped-in-try_to_unmap.patch 5.10/0005-mm-thp-fix-__split_huge_pmd_locked-on-shmem-migratio.patch 5.10/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch 5.10/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch Fixedups for 5.4.128 and older: 5.04/0007-mm-thp-try_to_unmap-use-TTU_SYNC-for-safe-splitting.patch 5.04/0008-mm-thp-fix-vma_address-if-virtual-address-below-file.patch 5.04/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch 5.04/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch 5.04/0022-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch Fixedups for 4.19.195 and older: 4.19/0007-mm-thp-fix-vma_address-if-virtual-address-below-file.patch 4.19/0010-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch (Why does matrix say not to port ffc90cbb2970 "use head page" to 4.19 and older? It is correct, and would apply to them: but they do not have put_and_wait_on_page_locked(), so it may behave worse on them.) Antecedent and fixedup for 4.14.237 and older: 4.14/0001-include-linux-mmdebug.h-make-VM_WARN-non-rvals.patch 4.14/0008-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch Fixedups for 4.9.273: 4.09/0003-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch 4.09/0004-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch No backports to 4.4.273: it's too old and different for these. Thanks! Hugh [-- Attachment #2: Type: application/x-tar, Size: 133120 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-26 0:38 ` Hugh Dickins @ 2021-06-28 12:17 ` Greg Kroah-Hartman 2021-06-28 17:12 ` Hugh Dickins 0 siblings, 1 reply; 15+ messages in thread From: Greg Kroah-Hartman @ 2021-06-28 12:17 UTC (permalink / raw) To: Hugh Dickins Cc: Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Sasha Levin, Alex Shi, Miaohe Lin, Michal Hocko, stable On Fri, Jun 25, 2021 at 05:38:01PM -0700, Hugh Dickins wrote: > On Wed, 23 Jun 2021, Hugh Dickins wrote: > > On Wed, 23 Jun 2021, Andrew Morton wrote: > > > On Wed, 23 Jun 2021 09:44:14 -0700 (PDT) Hugh Dickins <hughd@google.com> wrote: > > > > > > > > Any word on this? > > > > > > > > I have a "matrix" of what's needed ready, but I'm still waiting on > > > > "I expect some more to follow in a few days time (thanks Andrew)": > > > > I believe akpm does still intend to send them in to Linus for 5.13 > > > > this week, but they've not gone yet. > > > > > > Linuswards tomorrow. Is that OK? > > > > That's great, thanks Andrew. Then when they appear in Linus's tree, > > I'll complete my notes and tarball, and mail GregKH in reply here. > > All in now, thanks: so attached is a tarball of the variants, > and here the finalized summary of what each stable needs. > > 5.12.13 5.10.46 5.4.128 4.19.195 4.14.237 4.9.273 > 4.14/0001 << chpick > 5.10/0001 << chpick << chpick << chpick << chpick > 5.10/0002 << chpick << chpick << chpick > 5.10/0003 << chpick << chpick << chpick > ffc90cbb2970 << chpick << chpick > 99fa8a48203d 5.10/0005 << chpick << chpick > 3b77e8c8cde5 << chpick << chpick << chpick > 732ed55823fc << chpick 5.04/0007 << chpick << chpick > 494334e43c16 << chpick 5.04/0008 4.19/0007 << chpick > 31657170deaf << chpick << chpick << chpick << chpick > 22061a1ffabd 5.10/0010 5.04/0010 << chpick > 504e070dc08f 5.10/0011 5.04/0011 4.19/0010 4.14/0008 4.09/0003 > f003c03^..a7a69d8 chpick << chpick << chpick << chpick > fe19bd3dae3d << chpick 5.04/0022 << chpick << chpick 4.09/0004 > > 19 recent THP-related upstream commits for 5.13: > ffc90cbb2970 mm, thp: use head page in __migration_entry_wait() > 99fa8a48203d mm/thp: fix __split_huge_pmd_locked() on shmem migration entry > 3b77e8c8cde5 mm/thp: make is_huge_zero_pmd() safe and quicker > 732ed55823fc mm/thp: try_to_unmap() use TTU_SYNC for safe splitting > 494334e43c16 mm/thp: fix vma_address() if virtual address below file offset > 31657170deaf mm/thp: fix page_address_in_vma() on file THP tails > 22061a1ffabd mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page() > 504e070dc08f mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split > f003c03bd29e mm: page_vma_mapped_walk(): use page for pvmw->page > 6d0fd5987657 mm: page_vma_mapped_walk(): settle PageHuge on entry > 3306d3119cea mm: page_vma_mapped_walk(): use pmde for *pvmw->pmd > e2e1d4076c77 mm: page_vma_mapped_walk(): prettify PVMW_MIGRATION block > 448282487483 mm: page_vma_mapped_walk(): crossing page table boundary > b3807a91aca7 mm: page_vma_mapped_walk(): add a level of indentation > 474466301dfd mm: page_vma_mapped_walk(): use goto instead of while (1) > a765c417d876 mm: page_vma_mapped_walk(): get vma_address_end() earlier > a9a7504d9bea mm/thp: fix page_vma_mapped_walk() if THP mapped by ptes > a7a69d8ba88d mm/thp: another PVMW_SYNC fix in page_vma_mapped_walk() > fe19bd3dae3d mm, futex: fix shared futex pgoff on shmem huge page > > Antecedents which get added into some older kernels: > 4.14/0001 91241681c62a include/linux/mmdebug.h: make VM_WARN* non-rvals > 5.10/0001 a4055888629b (part) mm: add VM_WARN_ON_ONCE_PAGE() macro > 5.10/0002 e0af87ff7afc mm/rmap: remove unneeded semicolon in page_not_mapped() > 5.10/0003 b7e188ec98b1 mm/rmap: use page_not_mapped in try_to_unmap() > > Nothing special for 5.12.13: all 19 can be cherry-picked cleanly. > > Antecedents and fixedups for 5.10.46 and older: > 5.10/0001-mm-add-VM_WARN_ON_ONCE_PAGE-macro.patch > 5.10/0002-mm-rmap-remove-unneeded-semicolon-in-page_not_mapped.patch > 5.10/0003-mm-rmap-use-page_not_mapped-in-try_to_unmap.patch > 5.10/0005-mm-thp-fix-__split_huge_pmd_locked-on-shmem-migratio.patch > 5.10/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch > 5.10/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > > Fixedups for 5.4.128 and older: > 5.04/0007-mm-thp-try_to_unmap-use-TTU_SYNC-for-safe-splitting.patch > 5.04/0008-mm-thp-fix-vma_address-if-virtual-address-below-file.patch > 5.04/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch > 5.04/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > 5.04/0022-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch > > Fixedups for 4.19.195 and older: > 4.19/0007-mm-thp-fix-vma_address-if-virtual-address-below-file.patch > 4.19/0010-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > > (Why does matrix say not to port ffc90cbb2970 "use head page" to 4.19 > and older? It is correct, and would apply to them: but they do not > have put_and_wait_on_page_locked(), so it may behave worse on them.) > > Antecedent and fixedup for 4.14.237 and older: > 4.14/0001-include-linux-mmdebug.h-make-VM_WARN-non-rvals.patch > 4.14/0008-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > > Fixedups for 4.9.273: > 4.09/0003-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > 4.09/0004-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch > > No backports to 4.4.273: it's too old and different for these. Thanks so much for this, and I was able to follow the above directions for 5.12, 5.10, and 5.4. But things fell apart for 4.19.y, when doing the backport of the longer series: > f003c03^..a7a69d8 chpick << chpick << chpick << chpick That just did not work. So could you just send a mbox of patches (or tarball), for the 4.19, 4.14, and 4.9 trees? That would make it much easier to ensure I got them all correct. thanks again, greg k-h ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-28 12:17 ` Greg Kroah-Hartman @ 2021-06-28 17:12 ` Hugh Dickins 2021-06-29 3:27 ` Sasha Levin 0 siblings, 1 reply; 15+ messages in thread From: Hugh Dickins @ 2021-06-28 17:12 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Hugh Dickins, Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Sasha Levin, Alex Shi, Miaohe Lin, Michal Hocko, stable On Mon, 28 Jun 2021, Greg Kroah-Hartman wrote: > On Fri, Jun 25, 2021 at 05:38:01PM -0700, Hugh Dickins wrote: > > On Wed, 23 Jun 2021, Hugh Dickins wrote: > > > On Wed, 23 Jun 2021, Andrew Morton wrote: > > > > On Wed, 23 Jun 2021 09:44:14 -0700 (PDT) Hugh Dickins <hughd@google.com> wrote: > > > > > > > > > > Any word on this? > > > > > > > > > > I have a "matrix" of what's needed ready, but I'm still waiting on > > > > > "I expect some more to follow in a few days time (thanks Andrew)": > > > > > I believe akpm does still intend to send them in to Linus for 5.13 > > > > > this week, but they've not gone yet. > > > > > > > > Linuswards tomorrow. Is that OK? > > > > > > That's great, thanks Andrew. Then when they appear in Linus's tree, > > > I'll complete my notes and tarball, and mail GregKH in reply here. > > > > All in now, thanks: so attached is a tarball of the variants, > > and here the finalized summary of what each stable needs. > > > > 5.12.13 5.10.46 5.4.128 4.19.195 4.14.237 4.9.273 > > 4.14/0001 << chpick > > 5.10/0001 << chpick << chpick << chpick << chpick > > 5.10/0002 << chpick << chpick << chpick > > 5.10/0003 << chpick << chpick << chpick > > ffc90cbb2970 << chpick << chpick > > 99fa8a48203d 5.10/0005 << chpick << chpick > > 3b77e8c8cde5 << chpick << chpick << chpick > > 732ed55823fc << chpick 5.04/0007 << chpick << chpick > > 494334e43c16 << chpick 5.04/0008 4.19/0007 << chpick > > 31657170deaf << chpick << chpick << chpick << chpick > > 22061a1ffabd 5.10/0010 5.04/0010 << chpick > > 504e070dc08f 5.10/0011 5.04/0011 4.19/0010 4.14/0008 4.09/0003 > > f003c03^..a7a69d8 chpick << chpick << chpick << chpick > > fe19bd3dae3d << chpick 5.04/0022 << chpick << chpick 4.09/0004 > > > > 19 recent THP-related upstream commits for 5.13: > > ffc90cbb2970 mm, thp: use head page in __migration_entry_wait() > > 99fa8a48203d mm/thp: fix __split_huge_pmd_locked() on shmem migration entry > > 3b77e8c8cde5 mm/thp: make is_huge_zero_pmd() safe and quicker > > 732ed55823fc mm/thp: try_to_unmap() use TTU_SYNC for safe splitting > > 494334e43c16 mm/thp: fix vma_address() if virtual address below file offset > > 31657170deaf mm/thp: fix page_address_in_vma() on file THP tails > > 22061a1ffabd mm/thp: unmap_mapping_page() to fix THP truncate_cleanup_page() > > 504e070dc08f mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split > > f003c03bd29e mm: page_vma_mapped_walk(): use page for pvmw->page > > 6d0fd5987657 mm: page_vma_mapped_walk(): settle PageHuge on entry > > 3306d3119cea mm: page_vma_mapped_walk(): use pmde for *pvmw->pmd > > e2e1d4076c77 mm: page_vma_mapped_walk(): prettify PVMW_MIGRATION block > > 448282487483 mm: page_vma_mapped_walk(): crossing page table boundary > > b3807a91aca7 mm: page_vma_mapped_walk(): add a level of indentation > > 474466301dfd mm: page_vma_mapped_walk(): use goto instead of while (1) > > a765c417d876 mm: page_vma_mapped_walk(): get vma_address_end() earlier > > a9a7504d9bea mm/thp: fix page_vma_mapped_walk() if THP mapped by ptes > > a7a69d8ba88d mm/thp: another PVMW_SYNC fix in page_vma_mapped_walk() > > fe19bd3dae3d mm, futex: fix shared futex pgoff on shmem huge page > > > > Antecedents which get added into some older kernels: > > 4.14/0001 91241681c62a include/linux/mmdebug.h: make VM_WARN* non-rvals > > 5.10/0001 a4055888629b (part) mm: add VM_WARN_ON_ONCE_PAGE() macro > > 5.10/0002 e0af87ff7afc mm/rmap: remove unneeded semicolon in page_not_mapped() > > 5.10/0003 b7e188ec98b1 mm/rmap: use page_not_mapped in try_to_unmap() > > > > Nothing special for 5.12.13: all 19 can be cherry-picked cleanly. > > > > Antecedents and fixedups for 5.10.46 and older: > > 5.10/0001-mm-add-VM_WARN_ON_ONCE_PAGE-macro.patch > > 5.10/0002-mm-rmap-remove-unneeded-semicolon-in-page_not_mapped.patch > > 5.10/0003-mm-rmap-use-page_not_mapped-in-try_to_unmap.patch > > 5.10/0005-mm-thp-fix-__split_huge_pmd_locked-on-shmem-migratio.patch > > 5.10/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch > > 5.10/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > > > > Fixedups for 5.4.128 and older: > > 5.04/0007-mm-thp-try_to_unmap-use-TTU_SYNC-for-safe-splitting.patch > > 5.04/0008-mm-thp-fix-vma_address-if-virtual-address-below-file.patch > > 5.04/0010-mm-thp-unmap_mapping_page-to-fix-THP-truncate_cleanu.patch > > 5.04/0011-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > > 5.04/0022-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch > > > > Fixedups for 4.19.195 and older: > > 4.19/0007-mm-thp-fix-vma_address-if-virtual-address-below-file.patch > > 4.19/0010-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > > > > (Why does matrix say not to port ffc90cbb2970 "use head page" to 4.19 > > and older? It is correct, and would apply to them: but they do not > > have put_and_wait_on_page_locked(), so it may behave worse on them.) > > > > Antecedent and fixedup for 4.14.237 and older: > > 4.14/0001-include-linux-mmdebug.h-make-VM_WARN-non-rvals.patch > > 4.14/0008-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > > > > Fixedups for 4.9.273: > > 4.09/0003-mm-thp-replace-DEBUG_VM-BUG-with-VM_WARN-when-unmap-.patch > > 4.09/0004-mm-futex-fix-shared-futex-pgoff-on-shmem-huge-page.patch > > > > No backports to 4.4.273: it's too old and different for these. > > Thanks so much for this, and I was able to follow the above directions > for 5.12, 5.10, and 5.4. Yes, I've checked the results, and you've done brilliantly: thanks. > > But things fell apart for 4.19.y, when doing the backport of the longer > series: > > f003c03^..a7a69d8 chpick << chpick << chpick << chpick > > That just did not work. That's very odd. If that worked on 5.12, 5.10, 5.4 then I don't understand how it does not work on 4.19: I've had no trouble repeating it at this end, so can only think that you must have unconsciously changed procedure in some way on reaching 4.19. I say "no trouble", but agree "git cherry-pick f003c03^..a7a69d8" does not work: because linux-stable-rc.git master has not yet been updated to Linus's current tree, so the tree doesn't contain those SHA1s. But you already worked around that correctly on 5.12, 5.10, 5.4; and "the matrix" wasn't expecting you to go back to 5.13 for those on 4.19 anyway, but to cherry-pick those ten from what you already correctly prepared for 5.4. (Perhaps the right command is "git cherry-pick 461d351e7cd4^..d106cf83e3cb", that's what worked for me, but I haven't spent long enough thinking whether my tree is sufficiently identical to yours or not.) If that's not the issue, the other two possibilities that cross my mind are: you're sure that you already applied the first ten patches to that branch, cherry-picking from 5.4 or git-am'ing 0007 and 0010 - there are mods to mm/page_vma_mapped.c in a couple of those earlier patches, which are required for clean application of the later mods. And the other possibility: I did once or twice a few years ago have trouble with "git cherry-pick xxx^..yyy" syntax: it failed, but the equivalent series of individual cherry-picks succeeded. If that was not simply pilot error, I imagine it was a git bug long since fixed, but mention individual cherry-picks as perhaps a workaround. > > So could you just send a mbox of patches (or tarball), for the 4.19, > 4.14, and 4.9 trees? That would make it much easier to ensure I got > them all correct. At risk of irritating you, sorry, I am resisting: the more data I send you, the more likely I am to mess it up in some stupid way. Please ask again and I shall, but I think your success with 5.12, 5.10, 5.4 just means that you were right to take a break before 4.19, 4.14, 4.4. Many thanks, Hugh ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-28 17:12 ` Hugh Dickins @ 2021-06-29 3:27 ` Sasha Levin 2021-06-29 6:08 ` Greg Kroah-Hartman 0 siblings, 1 reply; 15+ messages in thread From: Sasha Levin @ 2021-06-29 3:27 UTC (permalink / raw) To: Hugh Dickins Cc: Greg Kroah-Hartman, Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Alex Shi, Miaohe Lin, Michal Hocko, stable On Mon, Jun 28, 2021 at 10:12:57AM -0700, Hugh Dickins wrote: >On Mon, 28 Jun 2021, Greg Kroah-Hartman wrote: >> So could you just send a mbox of patches (or tarball), for the 4.19, >> 4.14, and 4.9 trees? That would make it much easier to ensure I got >> them all correct. > >At risk of irritating you, sorry, I am resisting: the more data I send >you, the more likely I am to mess it up in some stupid way. Please ask >again and I shall, but I think your success with 5.12, 5.10, 5.4 just >means that you were right to take a break before 4.19, 4.14, 4.4. I've tried following the instructions for 4.19, and that worked fine on my end too. If no one objects, I can pick up 4.9-4.19 after the current set of kernels is released. -- Thanks, Sasha ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-29 3:27 ` Sasha Levin @ 2021-06-29 6:08 ` Greg Kroah-Hartman 2021-06-29 6:51 ` Hugh Dickins 0 siblings, 1 reply; 15+ messages in thread From: Greg Kroah-Hartman @ 2021-06-29 6:08 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Alex Shi, Miaohe Lin, Michal Hocko, stable On Mon, Jun 28, 2021 at 11:27:05PM -0400, Sasha Levin wrote: > On Mon, Jun 28, 2021 at 10:12:57AM -0700, Hugh Dickins wrote: > > On Mon, 28 Jun 2021, Greg Kroah-Hartman wrote: > > > So could you just send a mbox of patches (or tarball), for the 4.19, > > > 4.14, and 4.9 trees? That would make it much easier to ensure I got > > > them all correct. > > > > At risk of irritating you, sorry, I am resisting: the more data I send > > you, the more likely I am to mess it up in some stupid way. Please ask > > again and I shall, but I think your success with 5.12, 5.10, 5.4 just > > means that you were right to take a break before 4.19, 4.14, 4.4. > > I've tried following the instructions for 4.19, and that worked fine on > my end too. > > If no one objects, I can pick up 4.9-4.19 after the current set of > kernels is released. No objection from me, thanks! greg k-h ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-29 6:08 ` Greg Kroah-Hartman @ 2021-06-29 6:51 ` Hugh Dickins 2021-07-01 19:47 ` Hugh Dickins 0 siblings, 1 reply; 15+ messages in thread From: Hugh Dickins @ 2021-06-29 6:51 UTC (permalink / raw) To: Sasha Levin Cc: Greg Kroah-Hartman, Hugh Dickins, Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Alex Shi, Miaohe Lin, Michal Hocko, stable On Tue, 29 Jun 2021, Greg Kroah-Hartman wrote: > On Mon, Jun 28, 2021 at 11:27:05PM -0400, Sasha Levin wrote: > > On Mon, Jun 28, 2021 at 10:12:57AM -0700, Hugh Dickins wrote: > > > On Mon, 28 Jun 2021, Greg Kroah-Hartman wrote: > > > > So could you just send a mbox of patches (or tarball), for the 4.19, > > > > 4.14, and 4.9 trees? That would make it much easier to ensure I got > > > > them all correct. > > > > > > At risk of irritating you, sorry, I am resisting: the more data I send > > > you, the more likely I am to mess it up in some stupid way. Please ask > > > again and I shall, but I think your success with 5.12, 5.10, 5.4 just > > > means that you were right to take a break before 4.19, 4.14, 4.4. > > > > I've tried following the instructions for 4.19, and that worked fine on > > my end too. > > > > If no one objects, I can pick up 4.9-4.19 after the current set of > > kernels is released. > > No objection from me, thanks! > > greg k-h Sure, Sasha, whenever suits you: thanks to you both. Hugh ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-06-29 6:51 ` Hugh Dickins @ 2021-07-01 19:47 ` Hugh Dickins 2021-07-02 11:56 ` Sasha Levin 0 siblings, 1 reply; 15+ messages in thread From: Hugh Dickins @ 2021-07-01 19:47 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Greg Kroah-Hartman, Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Alex Shi, Miaohe Lin, Michal Hocko, stable On Mon, 28 Jun 2021, Hugh Dickins wrote: > On Tue, 29 Jun 2021, Greg Kroah-Hartman wrote: > > On Mon, Jun 28, 2021 at 11:27:05PM -0400, Sasha Levin wrote: > > > On Mon, Jun 28, 2021 at 10:12:57AM -0700, Hugh Dickins wrote: > > > > On Mon, 28 Jun 2021, Greg Kroah-Hartman wrote: > > > > > So could you just send a mbox of patches (or tarball), for the 4.19, > > > > > 4.14, and 4.9 trees? That would make it much easier to ensure I got > > > > > them all correct. > > > > > > > > At risk of irritating you, sorry, I am resisting: the more data I send > > > > you, the more likely I am to mess it up in some stupid way. Please ask > > > > again and I shall, but I think your success with 5.12, 5.10, 5.4 just > > > > means that you were right to take a break before 4.19, 4.14, 4.4. > > > > > > I've tried following the instructions for 4.19, and that worked fine on > > > my end too. > > > > > > If no one objects, I can pick up 4.9-4.19 after the current set of > > > kernels is released. > > > > No objection from me, thanks! > > > > greg k-h > > Sure, Sasha, whenever suits you: thanks to you both. I've now checked today's queue/4.19, queue/4.14, queue/4.9: exactly as intended, thanks. Hugh ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: mm/thp commits: please wait a few days 2021-07-01 19:47 ` Hugh Dickins @ 2021-07-02 11:56 ` Sasha Levin 0 siblings, 0 replies; 15+ messages in thread From: Sasha Levin @ 2021-07-02 11:56 UTC (permalink / raw) To: Hugh Dickins Cc: Greg Kroah-Hartman, Andrew Morton, Kirill A. Shutemov, Yang Shi, Wang Yugui, Xu Yu, Jue Wang, Matthew Wilcox, Alex Shi, Miaohe Lin, Michal Hocko, stable On Thu, Jul 01, 2021 at 12:47:48PM -0700, Hugh Dickins wrote: >On Mon, 28 Jun 2021, Hugh Dickins wrote: >> On Tue, 29 Jun 2021, Greg Kroah-Hartman wrote: >> > On Mon, Jun 28, 2021 at 11:27:05PM -0400, Sasha Levin wrote: >> > > On Mon, Jun 28, 2021 at 10:12:57AM -0700, Hugh Dickins wrote: >> > > > On Mon, 28 Jun 2021, Greg Kroah-Hartman wrote: >> > > > > So could you just send a mbox of patches (or tarball), for the 4.19, >> > > > > 4.14, and 4.9 trees? That would make it much easier to ensure I got >> > > > > them all correct. >> > > > >> > > > At risk of irritating you, sorry, I am resisting: the more data I send >> > > > you, the more likely I am to mess it up in some stupid way. Please ask >> > > > again and I shall, but I think your success with 5.12, 5.10, 5.4 just >> > > > means that you were right to take a break before 4.19, 4.14, 4.4. >> > > >> > > I've tried following the instructions for 4.19, and that worked fine on >> > > my end too. >> > > >> > > If no one objects, I can pick up 4.9-4.19 after the current set of >> > > kernels is released. >> > >> > No objection from me, thanks! >> > >> > greg k-h >> >> Sure, Sasha, whenever suits you: thanks to you both. > >I've now checked today's queue/4.19, queue/4.14, queue/4.9: >exactly as intended, thanks. Thanks for confirming Hugh! -- Thanks, Sasha ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-07-02 11:56 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-16 23:02 mm/thp commits: please wait a few days Hugh Dickins 2021-06-17 4:51 ` Greg Kroah-Hartman 2021-06-23 14:58 ` Greg Kroah-Hartman 2021-06-23 16:44 ` Hugh Dickins 2021-06-23 16:53 ` Greg Kroah-Hartman 2021-06-23 20:46 ` Andrew Morton 2021-06-23 21:52 ` Hugh Dickins 2021-06-26 0:38 ` Hugh Dickins 2021-06-28 12:17 ` Greg Kroah-Hartman 2021-06-28 17:12 ` Hugh Dickins 2021-06-29 3:27 ` Sasha Levin 2021-06-29 6:08 ` Greg Kroah-Hartman 2021-06-29 6:51 ` Hugh Dickins 2021-07-01 19:47 ` Hugh Dickins 2021-07-02 11:56 ` Sasha Levin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.