On Thu, 1 Apr 2021 13:10:49 -0700
Yang Shi wrote:
[...]
> > >
> > > Yes, it could be. The old behavior of migration was to return -ENOMEM
> > > if THP migration is not supported then split THP. That behavior was
> > > not very friendly to some usecases, for example, memory policy and
> > > migrat
On Tue, 30 Mar 2021 09:51:46 -0700
Yang Shi wrote:
> On Tue, Mar 30, 2021 at 7:42 AM Gerald Schaefer
> wrote:
> >
> > On Mon, 29 Mar 2021 11:33:06 -0700
> > Yang Shi wrote:
> >
> > >
> > > When the THP NUMA fault support was added THP migrati
On Mon, 29 Mar 2021 11:33:11 -0700
Yang Shi wrote:
> The old behavior didn't split THP if migration is failed due to lack of
> memory on the target node. But the THP migration does split THP, so keep
> the old behavior for misplaced NUMA page migration.
>
> Signed-off-by: Yang Shi
> ---
> mm/
On Mon, 29 Mar 2021 11:33:06 -0700
Yang Shi wrote:
>
> When the THP NUMA fault support was added THP migration was not supported yet.
> So the ad hoc THP migration was implemented in NUMA fault handling. Since
> v4.14
> THP migration has been supported so it doesn't make too much sense to stil
On Thu, 25 Feb 2021 20:58:20 +
Matthew Wilcox wrote:
> In order to walk the page tables without the mmap semaphore, it must
> be possible to prevent them from being freed and reused (eg if munmap()
> races with viewing /proc/$pid/smaps).
>
> There is various commentary within the mm on how t
On Wed, 24 Feb 2021 17:46:08 +0100
Gerald Schaefer wrote:
[...]
> Then we fundamentally changed the way how we deal with that "hugetlb code
> is treating pmds as ptes" issue. Instead of caring about that in all
> huge_pte_xxx primitives, huge_ptep_get() will now return a nic
On Wed, 17 Feb 2021 11:24:15 -0500
Peter Xu wrote:
> On Wed, Feb 10, 2021 at 04:03:18PM -0800, Mike Kravetz wrote:
> > Add interfaces to set and clear soft dirty in hugetlb ptes. Make
> > hugetlb interfaces needed for /proc clear_refs available outside
> > hugetlb.c.
> >
> > arch/s390 has it's
On Tue, 23 Feb 2021 15:57:40 +0100
Gerald Schaefer wrote:
[...]
> What I do not understand is how __free_huge_page() would be called at all
> in the call trace below (set_max_huge_pages -> alloc_pool_huge_page ->
> __free_huge_page -> hugepage_subpool_put_pages). From the co
Hi,
LTP triggered a panic on s390 in hugepage_subpool_put_pages() with
linux-next 5.12.0-20210222, see below.
It crashes on the spin_lock(&spool->lock) at the beginning, because the
passed-in *spool points to 004e, which is not addressable
memory. It rather looks like some flags and n
ux-mm/20201123142237.GF17833@gaia/
> >
> > This series is based on v5.10-rc6 and has been tested on arm64 and x86 but
> > has only been build tested on riscv, s390, arc etc. It would be great if
> > folks could test this on these platforms as well. Thank you.
> >
> >
rder is cleared in
destroy_compound_gigantic_page(), and compound_nr is set to 1U << order == 1
for order 0 in set_compound_order(page, 0).
Fix this by explicitly clearing compound_nr for first tail page after calling
set_compound_order(page, 0).
Cc: # 5.9+
Fixes: 1378a5ee451a ("mm:
ic pages using free_contig_range(). So a "page[1].mapping = NULL"
might also be an option, instead of the "page[1].compound_nr = 0" in my
patch, but that looks even more ugly, since it would clear more than
needed.
Gerald Schaefer (1):
mm/hugetlb: clear compound_nr before freeing gigantic pages
mm/hugetlb.c | 1 +
1 file changed, 1 insertion(+)
--
2.17.1
00962d6980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
962d6a00: fb fb fc fc fc fc fc fc fc fc 00 00 00 00 00 00
962d6a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==
Fixes: 6b251fc96cf2
c: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Niklas Schnelle
> Cc: Gerald Schaefer
> Cc: linux-s...@vger.kernel.org
> ---
> arch/s390/pci/pci_mmio.c | 98 +++
On Thu, 24 Sep 2020 00:02:26 +0200
Gerald Schaefer wrote:
> On Wed, 23 Sep 2020 14:50:36 -0700
> Linus Torvalds wrote:
>
> > On Wed, Sep 23, 2020 at 2:33 PM Gerald Schaefer
> > wrote:
> > >
> > > Thanks, very nice walk-through, need some time
On Wed, 23 Sep 2020 14:50:36 -0700
Linus Torvalds wrote:
> On Wed, Sep 23, 2020 at 2:33 PM Gerald Schaefer
> wrote:
> >
> > Thanks, very nice walk-through, need some time to digest this. The TLB
> > aspect is interesting, and we do have our own __tlb_remove_page_size(),
On Wed, 23 Sep 2020 13:00:45 -0700
Linus Torvalds wrote:
[...]
>
> Ooh. One thing that is *very* different about s390 is that it frees
> the page directly, and doesn't batch things up to happen after the TLB
> flush.
>
> Maybe THAT is the difference? Not that I can tell why it should
> matter,
On Tue, 22 Sep 2020 19:03:50 +0200
Gerald Schaefer wrote:
> On Wed, 16 Sep 2020 16:28:06 +0200
> Heiko Carstens wrote:
>
> > On Sat, Sep 12, 2020 at 09:54:12PM -0400, Qian Cai wrote:
> > > Occasionally, running this LTP test will trigger an error below on
> > &g
On Wed, 16 Sep 2020 16:28:06 +0200
Heiko Carstens wrote:
> On Sat, Sep 12, 2020 at 09:54:12PM -0400, Qian Cai wrote:
> > Occasionally, running this LTP test will trigger an error below on
> > s390:
> > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/security/dirtyc0w/dirtyc
On Thu, 10 Sep 2020 12:20:34 +0200
David Hildenbrand wrote:
> Hi everybody,
>
> I was just exploring how /sys/devices/system/memory/memoryX/phys_device
> is/was used. It's one of these interfaces that most probably never
> should have been added but now we are stuck with it.
>
> "phys_device" w
On Thu, 10 Sep 2020 11:33:17 -0700
Linus Torvalds wrote:
> On Thu, Sep 10, 2020 at 11:13 AM Jason Gunthorpe wrote:
> >
> > So.. To change away from the stack option I think we'd have to pass
> > the READ_ONCE value to pXX_offset() as an extra argument instead of it
> > derefing the pointer inter
On Thu, 10 Sep 2020 10:02:33 -0300
Jason Gunthorpe wrote:
> On Thu, Sep 10, 2020 at 11:39:25AM +0200, Alexander Gordeev wrote:
>
> > As Gerald mentioned, it is very difficult to explain in a clear way.
> > Hopefully, one could make sense ot of it.
>
> I would say the page table API requires thi
On Thu, 10 Sep 2020 12:10:26 -0300
Jason Gunthorpe wrote:
> On Thu, Sep 10, 2020 at 03:28:03PM +0200, Gerald Schaefer wrote:
> > On Thu, 10 Sep 2020 10:02:33 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Thu, Sep 10, 2020 at 11:39:25AM +0200, Alexander Gord
On Thu, 10 Sep 2020 10:02:33 -0300
Jason Gunthorpe wrote:
> On Thu, Sep 10, 2020 at 11:39:25AM +0200, Alexander Gordeev wrote:
>
> > As Gerald mentioned, it is very difficult to explain in a clear way.
> > Hopefully, one could make sense ot of it.
>
> I would say the page table API requires t
On Wed, 9 Sep 2020 15:03:24 -0300
Jason Gunthorpe wrote:
> On Wed, Sep 09, 2020 at 07:25:34PM +0200, Gerald Schaefer wrote:
> > I actually had to draw myself a picture to get some hold of
> > this, or rather a walk-through with a certain pud-crossing
> > range in a folded
On Wed, 9 Sep 2020 09:18:46 -0700
Dave Hansen wrote:
> On 9/9/20 5:29 AM, Gerald Schaefer wrote:
> > This only works well as long there are real pagetable pointers involved,
> > that can also be used for iteration. For gup_fast, or any other future
> > pagetable walkers usin
On Tue, 8 Sep 2020 19:36:50 +0200
Gerald Schaefer wrote:
[..]
>
> It seems now that the generalization is very well accepted so far,
> apart from some apparent issues on arm. Also, merging 2 + 3 and
> putting them first seems to be acceptable, so we could do that for
> v3,
On Tue, 8 Sep 2020 07:30:50 -0700
Dave Hansen wrote:
> On 9/7/20 11:00 AM, Gerald Schaefer wrote:
> > Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
> > code") introduced a subtle but severe bug on s390 with gup_fast, due to
> > dynamic
On Tue, 8 Sep 2020 14:40:10 +0200
Christophe Leroy wrote:
>
>
> Le 08/09/2020 à 14:09, Christian Borntraeger a écrit :
> >
> >
> > On 08.09.20 07:06, Christophe Leroy wrote:
> >>
> >>
> >> Le 07/09/2020 à 20:00, Gerald Schaefer a écr
On Tue, 8 Sep 2020 07:30:50 -0700
Dave Hansen wrote:
> On 9/7/20 11:00 AM, Gerald Schaefer wrote:
> > Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
> > code") introduced a subtle but severe bug on s390 with gup_fast, due to
> > dynamic
On Tue, 8 Sep 2020 07:22:39 +0200
Christophe Leroy wrote:
>
>
> Le 07/09/2020 à 22:12, Mike Rapoport a écrit :
> > On Mon, Sep 07, 2020 at 08:00:55PM +0200, Gerald Schaefer wrote:
> >> This is v2 of an RFC previously discussed here:
> >> https://lore.kern
Signed-off-by: Gerald Schaefer
---
arch/arm/include/asm/pgtable-2level.h| 2 +-
arch/arm/mm/idmap.c | 6 ++--
arch/arm/mm/mmu.c| 8 ++---
arch/arm64/kernel/hibernate.c| 16 ++
arch/arm64/kvm/mmu.c | 16
This is v2 of an RFC previously discussed here:
https://lore.kernel.org/lkml/20200828140314.8556-1-gerald.schae...@linux.ibm.com/
Patch 1 is a fix for a regression in gup_fast on s390, after our conversion
to common gup_fast code. It will introduce special helper functions
pXd_addr_end_folded(), w
change for other architectures
introduced.
Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code")
Cc: # 5.2+
Reviewed-by: Gerald Schaefer
Signed-off-by: Alexander Gordeev
Signed-off-by: Gerald Schaefer
---
arch/s390/include/asm/pgtable.h | 4
subtle bugs.
Signed-off-by: Alexander Gordeev
Signed-off-by: Gerald Schaefer
---
include/linux/pgtable.h | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 67ebc22cf83d..d9e7d16c2263
On Wed, 2 Sep 2020 14:24:37 +0200
Gerald Schaefer wrote:
> On Tue, 1 Sep 2020 16:22:22 -0700
> John Hubbard wrote:
>
> > On 9/1/20 10:40 AM, Gerald Schaefer wrote:
> > > On Mon, 31 Aug 2020 12:15:53 -0700
> > > Andrew Morton wrote:
> > ...
> > >
On Tue, 1 Sep 2020 16:22:22 -0700
John Hubbard wrote:
> On 9/1/20 10:40 AM, Gerald Schaefer wrote:
> > On Mon, 31 Aug 2020 12:15:53 -0700
> > Andrew Morton wrote:
> ...
> > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> > index e8cbc2e795d5.
On Mon, 31 Aug 2020 12:15:53 -0700
Andrew Morton wrote:
> On Mon, 31 Aug 2020 13:53:36 +0200 Christian Borntraeger
> wrote:
>
> >
> >
> > On 28.08.20 16:03, Gerald Schaefer wrote:
> > have some feedback soon if option 1 or option 2 would be acceptable
&
On Fri, 28 Aug 2020 11:21:37 -0300
Jason Gunthorpe wrote:
> On Fri, Aug 28, 2020 at 04:03:12PM +0200, Gerald Schaefer wrote:
> > Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
> > code") introduced a subtle but severe bug on s390 with gup_fast
Hi,
Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
code") introduced a subtle but severe bug on s390 with gup_fast, due to
dynamic page table folding.
The question "What would it require for the generic code to work for s390"
has already been discussed here
https://lkml
ning correct pointers
while still preseving the READ_ONCE logic for gup_fast. No change
for other architectures introduced.
Cc: # 5.2+
Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code")
Reviewed-by: Gerald Schaefer
Reviewed-by: Alexander Gordeev
o change for other architectures
introduced.
Cc: # 5.2+
Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code")
Reviewed-by: Gerald Schaefer
Signed-off-by: Alexander Gordeev
---
arch/s390/include/asm/pgtable.h | 49 +
include/linux
k
> CC: Christian Borntraeger
> CC: linux-s...@vger.kernel.org
> Signed-off-by: Peter Xu
> ---
> arch/s390/mm/fault.c | 16 +---
> 1 file changed, 1 insertion(+), 15 deletions(-)
Reviewed-by: Gerald Schaefer
Acked-by: Gerald Schaefer
On Wed, 24 Jun 2020 16:34:12 -0400
Peter Xu wrote:
> On Wed, Jun 24, 2020 at 08:49:03PM +0200, Gerald Schaefer wrote:
> > On Fri, 19 Jun 2020 12:05:13 -0400
> > Peter Xu wrote:
> >
> > [...]
> >
> > > @@ -4393,6 +4425,38 @@ vm_fault_t handle_
On Fri, 26 Jun 2020 19:22:53 +0200
Gerald Schaefer wrote:
> On Thu, 25 Jun 2020 17:00:29 +0200
> David Hildenbrand wrote:
>
> > I can't come up with a satisfying reason why we still need the memory
> > segment list. We used to represent in the list:
> > - boot m
On Fri, 26 Jun 2020 19:22:53 +0200
Gerald Schaefer wrote:
[...]
>
> That should be OK, as it is also the same message that we already
> see for overlaps with other DCSSs. But you probably also should
> remove that case from the segment_warning() function for
> completeness.
..
On Thu, 25 Jun 2020 17:00:29 +0200
David Hildenbrand wrote:
> I can't come up with a satisfying reason why we still need the memory
> segment list. We used to represent in the list:
> - boot memory
> - standby memory added via add_memory()
> - loaded dcss segments
>
> When loading/unloading dcss
On Fri, 19 Jun 2020 12:13:35 -0400
Peter Xu wrote:
> Use the general page fault accounting by passing regs into handle_mm_fault().
> It naturally solve the issue of multiple page fault accounting when page fault
> retry happened.
>
> CC: Heiko Carstens
> CC: Vasily Gorbik
> CC: Christian Bornt
On Fri, 19 Jun 2020 12:05:13 -0400
Peter Xu wrote:
[...]
> @@ -4393,6 +4425,38 @@ vm_fault_t handle_mm_fault(struct vm_area_struct *vma,
> unsigned long address,
> mem_cgroup_oom_synchronize(false);
> }
>
> + if (ret & VM_FAULT_RETRY)
> + return ret;
On Wed, 24 Jun 2020 13:05:39 +0200
Alexander Gordeev wrote:
> On Wed, Jun 24, 2020 at 08:43:10AM +0530, Anshuman Khandual wrote:
>
> [...]
>
> > Hello Gerald/Christophe/Vineet,
> >
> > It would be really great if you could give this series a quick test
> > on s390/ppc/arc platforms respectivel
Hi,
Some architectures have their page fault accounting code inside the fault
retry loop, and rely on only going through that code once. Before commit
4064b9827063 ("mm: allow VM_FAULT_RETRY for multiple times"), that was
ensured by testing for and clearing FAULT_FLAG_ALLOW_RETRY.
That commit had
s through livepatching.git as part of this series?
>
> Thanks.
>
Ah, forgot about that one, sorry. Also looks good.
Acked-by: Gerald Schaefer # s390
t; memcpy() can be used. Test and add fixes. ]
> >
> > Cc: linux-s...@vger.kernel.org
> > Cc: Heiko Carstens
> > Cc: Gerald Schaefer
> > Cc: Christian Borntraeger
> > Suggested-by: Josh Poimboeuf
> > Signed-off-by: Peter Zijlstra (Intel)
> &g
ike allocated pages that are unmovable (esp.
> > PG_reserved), and therefore, memory offlining fails early, when trying to
> > isolate the page range.
> >
> > We only have to care about the exchange area, make that clear.
> >
> > Cc: Heiko Carstens
> > Cc:
On Wed, 18 Sep 2019 18:26:03 +0200
Christophe Leroy wrote:
[..]
> My suggestion was not to completely drop the #ifdef but to do like you
> did in pgd_clear_tests() for instance, ie to add the following test on
> top of the function:
>
> if (mm_pud_folded(mm) || is_defined(__ARCH_HAS_5LE
On Mon, 9 Sep 2019 11:56:50 +0530
Anshuman Khandual wrote:
[..]
> >
> > Hmm, I simply used this on my system to make pud_clear_tests() work, not
> > sure if it works on all archs:
> >
> > pud_val(*pudp) |= RANDOM_NZVALUE;
>
> Which compiles on arm64 but then fails on x86 because of the way p
On Fri, 6 Sep 2019 11:58:59 +0530
Anshuman Khandual wrote:
> On 09/05/2019 10:36 PM, Gerald Schaefer wrote:
> > On Thu, 5 Sep 2019 14:48:14 +0530
> > Anshuman Khandual wrote:
> >
> >>> [...]
> >>>> +
> >>>> +#if !def
On Thu, 5 Sep 2019 14:48:14 +0530
Anshuman Khandual wrote:
> > [...]
> >> +
> >> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
> >> +static void pud_clear_tests(pud_t *pudp)
> >> +{
> >> + memset(pudp, RANDOM_NZVALUE, sizeof(pud_t));
> >> + pud_clear(pudp);
> >> +
On Tue, 3 Sep 2019 13:31:46 +0530
Anshuman Khandual wrote:
> This adds a test module which will validate architecture page table helpers
> and accessors regarding compliance with generic MM semantics expectations.
> This will help various architectures in validating changes to the existing
> pag
On Mon, 26 Aug 2019 06:18:58 -0700
Matthew Wilcox wrote:
> Why did you not cc Gerald who wrote the patch? You can't just
> run get_maintainers.pl and call it good.
>
> On Sun, Aug 25, 2019 at 02:06:21PM -0600, Yu Zhao wrote:
> > For hugely mapped thp, we use is_huge_zero_pmd() to check if it's
On Tue, 7 May 2019 13:18:06 -0400
Sasha Levin wrote:
> On Tue, May 07, 2019 at 10:15:19AM -0700, Linus Torvalds wrote:
> >On Tue, May 7, 2019 at 10:02 AM Sasha Levin wrote:
> >>
> >> I got it wrong then. I'll fix it up and get efad4e475c31 in instead.
> >
> >Careful. That one had a bug too, and
On Tue, 7 May 2019 13:02:08 -0400
Sasha Levin wrote:
> On Tue, May 07, 2019 at 09:50:50AM -0700, Linus Torvalds wrote:
> >On Tue, May 7, 2019 at 9:31 AM Alexander Duyck
> > wrote:
> >>
> >> Wasn't this patch reverted in Linus's tree for causing a regression on
> >> some platforms? If so I'm not s
On Tue, 29 Jan 2019 14:49:20 +0100
Michal Hocko wrote:
> On Tue 29-01-19 14:14:47, Gerald Schaefer wrote:
> > On Mon, 28 Jan 2019 15:45:04 +0100
> > Michal Hocko wrote:
> >
> > > Hi,
> > > Mikhail has posted fixes for the two bugs quite some time ago
On Mon, 28 Jan 2019 15:45:04 +0100
Michal Hocko wrote:
> Hi,
> Mikhail has posted fixes for the two bugs quite some time ago [1]. I
> have pushed back on those fixes because I believed that it is much
> better to plug the problem at the initialization time rather than play
> whack-a-mole all over
isambiguate MSI region types")
Cc: # v4.11+
Signed-off-by: Gerald Schaefer
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 048b5ab36a02..b83e0f2025bb 100644
--- a/drivers/iommu
_iommu_remove_device,
> .device_group = generic_device_group,
> .pgsize_bitmap = S390_IOMMU_PGSIZES,
> + .get_resv_regions = s390_get_resv_regions,
> + .put_resv_regions = s390_put_resv_regions,
> };
>
> static int __init s390_iommu_init(void)
With the start/end_dma issue addressed (if necessary):
Acked-by: Gerald Schaefer
__vfs_read+0x32/0x178
> >> [<003b55b2>] vfs_read+0x82/0x138
> >> [<003b5be2>] ksys_read+0x5a/0xb0
> >> [<00b86ba0>] system_call+0xdc/0x2d8
> >> Last Breaking-Event-Address:
> >> [<0038596c>]
22 06:20:13, Sasha Levin wrote:
> >> > > From: Gerald Schaefer
> >> > >
> >> > > [ Upstream commit 55a5542a546238354d1f209f794414168cf8c71d ]
> >> > >
> >> > > The resume code checks if the resume cpu is the same as th
On Wed, 12 Sep 2018 14:40:18 +
Pasha Tatashin wrote:
> On 9/12/18 10:27 AM, Gerald Schaefer wrote:
> > On Wed, 12 Sep 2018 15:39:33 +0200
> > Michal Hocko wrote:
> >
> >> On Wed 12-09-18 15:03:56, Gerald Schaefer wrote:
> >> [...]
> >>
On Mon, 10 Sep 2018 15:26:55 +
Pasha Tatashin wrote:
>
> I agree memoryblock is a hack, it fails to do both things it was
> designed to do:
>
> 1. On bare metal you cannot free a physical dimm of memory using
> memoryblock granularity because memory devices do not equal to physical
> dimms.
On Wed, 12 Sep 2018 15:39:33 +0200
Michal Hocko wrote:
> On Wed 12-09-18 15:03:56, Gerald Schaefer wrote:
> [...]
> > BTW, those sysfs attributes are world-readable, so anyone can trigger
> > the panic by simply reading them, or just run lsmem (also available for
> > x
pages w/o DEBUG_VM poisoning).
BTW, those sysfs attributes are world-readable, so anyone can trigger
the panic by simply reading them, or just run lsmem (also available for
x86 since util-linux 2.32). OK, you need a special not-memory-block-aligned
mem= parameter and DEBUG_VM for poison check
On Thu, 26 Apr 2018 10:27:55 -0400
Zi Yan wrote:
> From: Zi Yan
>
> Hi all,
>
> THP migration is only enabled on x86_64 with a special
> ARCH_ENABLE_THP_MIGRATION macro. This patchset enables THP migration for
> all architectures that uses transparent hugepage, so that special macro can
> be d
drivers/iommu/s390-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Gerald Schaefer
>
> diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c
> index 8788640..400d75f 100644
> --- a/drivers/iommu/s390-iommu.c
> +++ b/drivers/iommu
On Mon, 31 Jul 2017 17:53:50 +0200
Michal Hocko wrote:
> On Mon 31-07-17 17:04:59, Gerald Schaefer wrote:
> > On Mon, 31 Jul 2017 14:53:19 +0200
> > Michal Hocko wrote:
> >
> > > On Mon 31-07-17 14:35:21, Gerald Schaefer wrote:
> > > > On Fri, 28 Ju
On Mon, 31 Jul 2017 14:53:19 +0200
Michal Hocko wrote:
> On Mon 31-07-17 14:35:21, Gerald Schaefer wrote:
> > On Fri, 28 Jul 2017 14:19:41 +0200
> > Michal Hocko wrote:
> >
> > > On Thu 27-07-17 08:56:52, Michal Hocko wrote:
> > > > On
On Mon, 31 Jul 2017 14:55:56 +0200
Michal Hocko wrote:
> On Mon 31-07-17 14:40:53, Gerald Schaefer wrote:
> [...]
> > > @@ -247,12 +248,12 @@ int __meminit vmemmap_populate(unsigned long start,
> > > unsigned long end, int node)
> > >* use l
On Wed, 26 Jul 2017 10:33:30 +0200
Michal Hocko wrote:
> From: Michal Hocko
>
> vmem_altmap allows vmemmap_populate to allocate memmap (struct page
> array) from an alternative allocator rather than bootmem resp.
> kmalloc. Only x86 currently supports altmap handling, most likely
> because only
On Fri, 28 Jul 2017 14:19:41 +0200
Michal Hocko wrote:
> On Thu 27-07-17 08:56:52, Michal Hocko wrote:
> > On Wed 26-07-17 17:06:59, Jerome Glisse wrote:
> > [...]
> > > This does not seems to be an opt-in change ie if i am reading patch 3
> > > correctly if an altmap is not provided to __add_pag
On Wed, 26 Jul 2017 14:30:41 +0200
Michal Hocko wrote:
> On Wed 26-07-17 13:45:39, Heiko Carstens wrote:
> [...]
> > In general I do like your idea, however if I understand your patches
> > correctly we might have an ordering problem on s390: it is not possible to
> > access hot-added memory on s
On Tue, 27 Jun 2017 17:28:06 +0200
Joerg Roedel wrote:
> On Mon, Jun 19, 2017 at 05:02:19PM +0200, Gerald Schaefer wrote:
> > On Thu, 15 Jun 2017 15:11:52 +0200
> > Joerg Roedel wrote:
> > > + rc = zpci_init_iommu(zdev);
> > > + if (rc)
> > > +
On Wed, 28 Jun 2017 14:00:56 +0200
Joerg Roedel wrote:
> From: Joerg Roedel
>
> The generic device_group call-backs in iommu.c return NULL
> in case of error. Since they are getting ERR_PTR values from
> iommu_group_alloc(), just pass them up instead.
>
> Reporte
On Thu, 15 Jun 2017 15:11:52 +0200
Joerg Roedel wrote:
> From: Joerg Roedel
>
> Add support for the iommu_device_register interface to make
> the s390 hardware iommus visible to the iommu core and in
> sysfs.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/s390/include/asm/pci.h | 7 +++
>
can make use of
> default domains in the future.
>
> Signed-off-by: Joerg Roedel
Seems pretty straightforward, so
Reviewed-by: Gerald Schaefer
However, looking at iommu_group_get_for_dev(), I wonder if the
generic_device_group() always returns the right thing, but that
would be
f-by: Christoph Hellwig
Acked-by: Gerald Schaefer
device to brd->dax_dev.
Signed-off-by: Gerald Schaefer
---
drivers/block/brd.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 38f38df..57b574f 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -404,9
On Fri, 28 Apr 2017 16:55:13 +0200
Joerg Roedel wrote:
> > I am however a bit confused now, about how we would have allowed group
> > sharing with the current s390 IOMMU code, or IOW in which scenario would
> > iommu_group_get() in the add_device callback find a shareable iommu-group?
>
> The
On Thu, 27 Apr 2017 23:12:32 +0200
Joerg Roedel wrote:
> On Thu, Apr 27, 2017 at 08:11:42PM +0200, Gerald Schaefer wrote:
> > > +void zpci_destroy_iommu(struct zpci_dev *zdev)
> > > +{
> > > + iommu_group_put(zdev->group);
> > > + zdev->group = NUL
Hi Joerg,
I guess we are a bit special on s390 (again), see below. Sebastian is more
familiar with the base s390 PCI code, he may correct me if I'm wrong.
On Thu, 27 Apr 2017 23:03:25 +0200
Joerg Roedel wrote:
> > Well, there is a separate zpci_dev for each pci_dev on s390,
> > and each of thos
On Thu, 27 Apr 2017 17:28:24 +0200
Joerg Roedel wrote:
> From: Joerg Roedel
>
> Currently the s390 iommu driver allocates an iommu-group for
> every device that is added. But that is wrong, as there is
> only one dma-table per pci-root-bus. Make all devices behind
> one dma-table share one iomm
On Thu, 27 Apr 2017 17:28:23 +0200
Joerg Roedel wrote:
> Hey,
>
> here are two patches for the s390 PCI and IOMMU code. It is
> based on the assumption that every pci_dev that points to
> the same zpci_dev shares a single dma-table (and thus a
> single address space).
Well, there is a separate
rations the old dcssblk_direct_access() will be removed.
>
> Reported-by: Gerald Schaefer
> Signed-off-by: Dan Williams
> ---
> Changes since v2:
> * fix return code in the alloc_dax() failure case (Gerald)
> * assign dax_dev to dev_info and kill local variable (Gerald)
>
> drivers/s39
rations the old dcssblk_direct_access() will be removed.
>
> Cc: Gerald Schaefer
> Signed-off-by: Dan Williams
> ---
> drivers/s390/block/Kconfig |1 +
> drivers/s390/block/dcssblk.c | 54
> +++---
> 2 files changed, 46 insertions(+), 9 dele
offline
- Move page_count() check out of dissolve_free_huge_page()
Changes in v2:
- Update comment in dissolve_free_huge_pages()
- Change locking in dissolve_free_huge_page()
Gerald Schaefer (3):
mm/hugetlb: fix memory offline with hugepage size > memory block size
mm/hugetlb: check for reser
dissolve_free_huge_pages() before calling dissolve_free_huge_page(). In
dissolve_free_huge_page(), when holding the spinlock, those checks need
to be revalidated.
Signed-off-by: Gerald Schaefer
---
mm/hugetlb.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
y
lead to the situation where dissolve_free_huge_page() returns an error
and all free hugepages that were dissolved before that error are lost,
while the memory block still cannot be set offline.
Fixes: c8721bbb ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Signe
is preferable to failing the memory
offline, for example in the situation where a (possibly faulty) memory
DIMM needs to go offline.
Fixes: c8721bbb ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Cc:
Signed-off-by: Gerald Schaefer
---
mm/hugetlb.c | 13 +++--
On Fri, 23 Sep 2016 14:40:33 +0800
Rui Teng wrote:
> On 9/22/16 5:51 PM, Michal Hocko wrote:
> > On Wed 21-09-16 14:35:34, Gerald Schaefer wrote:
> >> dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
> >> list corruption and addressing exception
On Thu, 22 Sep 2016 11:12:06 -0700
Dave Hansen wrote:
> On 09/22/2016 09:29 AM, Gerald Schaefer wrote:
> > static void dissolve_free_huge_page(struct page *page)
> > {
> > + struct page *head = compound_head(page);
> > + struct hstate *h = page_hstate(head);
&g
("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Cc:
Signed-off-by: Gerald Schaefer
---
Changes in v3:
- Add Fixes: c8721bbb
- Add Cc: stable
- Elaborate on losing the gigantic page vs. failing memory offline
- Move page_count() check out of dissolve_free_huge_page()
1 - 100 of 206 matches
Mail list logo
