Re: [PATCH 08/13] zram: add error handling support for add_disk()

On Fri, Oct 15, 2021 at 04:52:14PM -0700, Luis Chamberlain wrote: > We never checked for errors on add_disk() as this function > returned void. Now that this is fixed, use the shiny new > error handling. > > Signed-off-by: Luis Chamberlain Acked-by: Minchan Kim

Re: [PATCH 9/9] zsmalloc: remove the zsmalloc file system

On Tue, Mar 09, 2021 at 04:53:48PM +0100, Christoph Hellwig wrote: > Just use the generic anon_inode file system. > > Signed-off-by: Christoph Hellwig Acked-by: Minchan Kim

Re: [PATCH 1/9] fs: rename alloc_anon_inode to alloc_anon_inode_sb

On Tue, Mar 09, 2021 at 04:53:40PM +0100, Christoph Hellwig wrote: > Rename alloc_inode to free the name for a new variant that does not > need boilerplate to create a super_block first. > > Signed-off-by: Christoph Hellwig > --- > arch/powerpc/platforms/pseries/cmm.c | 2 +- > drivers/dma-buf/d

Re: [PATCH 11/29] mm: only allow page table mappings for built-in zsmalloc

copies. > > Signed-off-by: Christoph Hellwig > Acked-by: Peter Zijlstra (Intel) Acked-by: Minchan Kim Thanks!

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

Hi Christoph, Sorry for the late. On Sat, Apr 11, 2020 at 09:20:52AM +0200, Christoph Hellwig wrote: > Hi Minchan, > > On Fri, Apr 10, 2020 at 04:11:36PM -0700, Minchan Kim wrote: > > It doesn't mean we couldn't use zsmalloc as module any longer. It means > > we

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

Hi Sergey, On Fri, Apr 10, 2020 at 11:38:45AM +0900, Sergey Senozhatsky wrote: > On (20/04/09 10:08), Minchan Kim wrote: > > > > Even though I don't know how many usecase we have using zsmalloc as > > > > module(I heard only once by dumb reason), it could aff

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

On Thu, Apr 09, 2020 at 06:50:30PM +0200, Peter Zijlstra wrote: > On Thu, Apr 09, 2020 at 09:08:26AM -0700, Minchan Kim wrote: > > On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote: > > > This allows to unexport map_vm_area and unmap_kernel_range, which are

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote: > This allows to unexport map_vm_area and unmap_kernel_range, which are > rather deep internal and should not be available to modules. Even though I don't know how many usecase we have using zsmalloc as module(I heard only once by

Re: [PATCH 09/28] mm: rename CONFIG_PGTABLE_MAPPING to CONFIG_ZSMALLOC_PGTABLE_MAPPING

On Wed, Apr 08, 2020 at 01:59:07PM +0200, Christoph Hellwig wrote: > Rename the Kconfig variable to clarify the scope. > > Signed-off-by: Christoph Hellwig Acked-by: Minchan Kim

Re: [PATCH v10 12/25] mm: cache some VMA fields in the vm_fault structure

On Fri, May 04, 2018 at 11:10:54AM +0200, Laurent Dufour wrote: > On 03/05/2018 17:42, Minchan Kim wrote: > > On Thu, May 03, 2018 at 02:25:18PM +0200, Laurent Dufour wrote: > >> On 23/04/2018 09:42, Minchan Kim wrote: > >>> On Tue, Apr 17, 2018 at 04:33:18

Re: [PATCH v10 12/25] mm: cache some VMA fields in the vm_fault structure

On Thu, May 03, 2018 at 02:25:18PM +0200, Laurent Dufour wrote: > On 23/04/2018 09:42, Minchan Kim wrote: > > On Tue, Apr 17, 2018 at 04:33:18PM +0200, Laurent Dufour wrote: > >> When handling speculative page fault, the vma->vm_flags and > >> vma->vm_page_prot fi

Re: [PATCH v10 08/25] mm: VMA sequence count

On Mon, Apr 30, 2018 at 05:14:27PM +0200, Laurent Dufour wrote: > > > On 23/04/2018 08:42, Minchan Kim wrote: > > On Tue, Apr 17, 2018 at 04:33:14PM +0200, Laurent Dufour wrote: > >> From: Peter Zijlstra > >> > >> Wrap the VMA modifications (

Re: [PATCH v10 06/25] mm: make pte_unmap_same compatible with SPF

On Mon, Apr 30, 2018 at 04:07:30PM +0200, Laurent Dufour wrote: > On 23/04/2018 08:31, Minchan Kim wrote: > > On Tue, Apr 17, 2018 at 04:33:12PM +0200, Laurent Dufour wrote: > >> pte_unmap_same() is making the assumption that the page table are still > >> around b

Re: [PATCH v10 12/25] mm: cache some VMA fields in the vm_fault structure

On Tue, Apr 17, 2018 at 04:33:18PM +0200, Laurent Dufour wrote: > When handling speculative page fault, the vma->vm_flags and > vma->vm_page_prot fields are read once the page table lock is released. So > there is no more guarantee that these fields would not change in our back. > They will be save

Re: [PATCH v10 09/25] mm: protect VMA modifications using VMA sequence count

On Tue, Apr 17, 2018 at 04:33:15PM +0200, Laurent Dufour wrote: > The VMA sequence count has been introduced to allow fast detection of > VMA modification when running a page fault handler without holding > the mmap_sem. > > This patch provides protection against the VMA modification done in : >

Re: [PATCH v10 08/25] mm: VMA sequence count

On Tue, Apr 17, 2018 at 04:33:14PM +0200, Laurent Dufour wrote: > From: Peter Zijlstra > > Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence > counts such that we can easily test if a VMA is changed. So, seqcount is to protect modifying all attributes of vma? > > The unmap

Re: [PATCH v10 06/25] mm: make pte_unmap_same compatible with SPF

On Tue, Apr 17, 2018 at 04:33:12PM +0200, Laurent Dufour wrote: > pte_unmap_same() is making the assumption that the page table are still > around because the mmap_sem is held. > This is no more the case when running a speculative page fault and > additional check must be made to ensure that the fi

Re: [PATCH v10 01/25] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT

Hi Laurent, I guess it's good timing to review. Guess LSF/MM goes so might change a lot since then. :) Anyway, I grap a time to review. On Tue, Apr 17, 2018 at 04:33:07PM +0200, Laurent Dufour wrote: > This configuration variable will be used to build the code needed to > handle speculative page

Re: clear_page, copy_page address align question?

On Tue, Apr 11, 2017 at 01:12:24PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2017-04-11 at 12:08 +0900, Minchan Kim wrote: > > Hello, > > > > When I tested zram in ppc64, I got random corruption. > > With investigation, it seems clear_page corrupted the memory.

clear_page, copy_page address align question?

Hello, When I tested zram in ppc64, I got random corruption. With investigation, it seems clear_page corrupted the memory. I passed 64K kmalloced(kmalloc(PAGE_SIZE)) address to clear_page and turned on slub debug so address is not aligned with PAGE_SIZE. Is it a valid usecase that non-PAGE_SIZE al

Re: [PATCH v3 5/7] zram: Convert to using memset_l

On Fri, Mar 24, 2017 at 09:13:16AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > zram was the motivation for creating memset_l(). Minchan Kim sees a 7% > performance improvement on x86 with 100MB of non-zero deduplicatable > data: > > perf stat -r 10 dd

Re: [PATCH] powerpc: remove newly added extra definition of pmd_dirty

On Thu, Jan 21, 2016 at 01:05:20PM +1100, Stephen Rothwell wrote: > Commit d5d6a443b243 ("arch/powerpc/include/asm/pgtable-ppc64.h: > add pmd_[dirty|mkclean] for THP") added a new identical definition > of pdm_dirty. Remove it again. > > Cc: Minchan Kim > Cc: An

[PATCH v17 4/7] powerpc: add pmd_[dirty|mkclean] for THP

Reviewed-by: Aneesh Kumar K.V Signed-off-by: Minchan Kim --- arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h index 889c6fa9ee01..7c07e5975871 100644 --- a/arch/powerpc

[PATCH v16 4/7] powerpc: add pmd_[dirty|mkclean] for THP

Reviewed-by: Aneesh Kumar K.V Signed-off-by: Minchan Kim --- arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h index 7b3d54fae46f..fb89d8eb96c8 100644 --- a/arch/powerpc

[PATCH v15 4/7] powerpc: add pmd_[dirty|mkclean] for THP

Reviewed-by: Aneesh Kumar K.V Signed-off-by: Minchan Kim --- arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h index eb9261024f51..c9a4bbe8e179 100644 --- a/arch/powerpc

[PATCH v14 4/8] powerpc: add pmd_[dirty|mkclean] for THP

: Aneesh Kumar K.V Reviewed-by: Aneesh Kumar K.V Signed-off-by: Minchan Kim --- arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h index eb9261024f51..c9a4bbe8e179

[PATCH v13 4/8] powerpc: add pmd_[dirty|mkclean] for THP

: linuxppc-dev@lists.ozlabs.org Signed-off-by: Minchan Kim --- arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h index eb9261024f51..c9a4bbe8e179 100644 --- a/arch/power

[PATCH v12 4/8] powerpc: add pmd_[dirty|mkclean] for THP

: linuxppc-dev@lists.ozlabs.org Signed-off-by: Minchan Kim --- arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h index eb9261024f51..c9a4bbe8e179 100644 --- a/arch/power

[PATCH v11 4/7] powerpc: add pmd_[dirty|mkclean] for THP

: linuxppc-dev@lists.ozlabs.org Signed-off-by: Minchan Kim --- arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h index eb9261024f51..c9a4bbe8e179 100644 --- a/arch/power

[PATCH v10 4/7] powerpc: add pmd_[dirty|mkclean] for THP

: linuxppc-dev@lists.ozlabs.org Signed-off-by: Minchan Kim --- arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h index eb9261024f51..c9a4bbe8e179 100644 --- a/arch/power

Re: [PATCH v3 -next 1/9] DMA, CMA: fix possible memory leak

vious problem but simple fix like this but not sure so let's pass the decision to him and will learn a lesson from him and will follow the decision from now on. Thanks. Acked-by: Minchan Kim > > Acked-by: Zhang Yanfei > Reviewed-by: Michal Nazarewicz > Reviewed-by: Anees

Re: [PATCH v2 10/10] mm, cma: use spinlock instead of mutex

*/ > - mutex_unlock(&cma->lock); > + spin_unlock(&cma->lock); > > pfn = cma->base_pfn + (bitmapno << cma->order_per_bit); > mutex_lock(&cma_mutex); > -- > 1.7.9.5 > > -- > To unsubscribe

Re: [PATCH v2 09/10] mm, cma: move output param to the end of param list

7 @@ int __init cma_declare_contiguous(phys_addr_t size, >* Each reserved area must be initialised later, when more kernel >* subsystems (like slab allocator) are available. >*/ > + cma = &cma_areas[cma_area_count]; > cma->base_pfn = PFN_DOWN(base); > cma->count = size >> PAGE_SHIFT; > cma->order_per_bit = order_per_bit; > -- > 1.7.9.5 -- Kind regards, Minchan Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 08/10] mm, cma: clean-up cma allocation error path

On Thu, Jun 12, 2014 at 12:21:45PM +0900, Joonsoo Kim wrote: > We can remove one call sites for clear_cma_bitmap() if we first > call it before checking error number. > > Signed-off-by: Joonsoo Kim Acked-by: Minchan Kim -- Kind regards,

Re: [PATCH v2 06/10] CMA: generalize CMA reserved area management functionality

here is no functional change in DMA APIs. > > v2: There is no big change from v1 in mm/cma.c. Mostly renaming. > > Acked-by: Michal Nazarewicz > Signed-off-by: Joonsoo Kim Acutally, I want to remove bool return of cma_release but it's not a out of scope in this patchs

Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity

. > So support arbitrary bitmap granularity for following generalization. > > Signed-off-by: Joonsoo Kim Acked-by: Minchan Kim Just a nit below. > > diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c > index bc4c171..9bc9340 100644 > --- a/drivers/ba

Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity

On Thu, Jun 12, 2014 at 03:43:55PM +0900, Joonsoo Kim wrote: > On Thu, Jun 12, 2014 at 03:06:10PM +0900, Minchan Kim wrote: > > On Thu, Jun 12, 2014 at 12:21:42PM +0900, Joonsoo Kim wrote: > > > ppc kvm's cma region management requires arbitrary bitmap granularity, > >

Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity

gt; > - pfn = cma->base_pfn + pageno; > + pfn = cma->base_pfn + (bitmapno << cma->order_per_bit); > mutex_lock(&cma_mutex); > ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA); > mutex_unlock(&cma_mutex); > @@ -392,7 +421,7 @@ static struct page *__dma_alloc_from_contiguous(struct > cma *cma, int count, > pr_debug("%s(): memory range at %p is busy, retrying\n", >__func__, pfn_to_page(pfn)); > /* try again with a bit different memory target */ > - start = pageno + mask + 1; > + start = bitmapno + mask + 1; > } > > pr_debug("%s(): returned %p\n", __func__, page); > -- > 1.7.9.5 -- Kind regards, Minchan Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 04/10] DMA, CMA: support alignment constraint on cma region

uous_reserve_area(phys_addr_t size, > phys_addr_t base, > { > int ret; > > - ret = __dma_contiguous_reserve_area(size, base, limit, res_cma, fixed); > + ret = __dma_contiguous_reserve_area(size, base, limit, 0, > + res_cma, fixed); > if (ret) > return ret; > > -- > 1.7.9.5 -- Kind regards, Minchan Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 03/10] DMA, CMA: separate core cma management codes from DMA APIs

t; if (!cma || !pages) > @@ -410,3 +430,11 @@ bool dma_release_from_contiguous(struct device *dev, > struct page *pages, > > return true; > } > + Ditto. > +bool dma_release_from_contiguous(struct device *dev, struct page *pages, > + int count) > +{ > + struct cma *cma = dev_get_cma_area(dev); > + > + return __dma_release_from_contiguous(cma, pages, count); > +} > -- > 1.7.9.5 -- Kind regards, Minchan Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 01/10] DMA, CMA: clean-up log message

%ld MiB at %08lx\n", > + __func__, (unsigned long)size / SZ_1M, (unsigned long)base); > > /* Architecture specific contiguous memory fixup. */ > dma_contiguous_early_fixup(base, size); > return 0; > err: > - pr_err("CMA: failed to

Re: [PATCH v2 02/10] DMA, CMA: fix possible memory leak

} while (--i); > > mutex_init(&cma->lock); > return 0; > + > +err: > + kfree(cma->bitmap); > + return -EINVAL; > } > > static struct cma cma_areas[MAX_CMA_AREAS]; > -- > 1.7.9.5 -- Kind regards, Minchan Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 36/52] zsmalloc: Fix CPU hotplug callback registration

se of the double underscored version of the API */ > __register_cpu_notifier(&foobar_cpu_notifier); > > cpu_notifier_register_done(); > > > Fix the zsmalloc code by using this latter form of callback registration. > > Cc: Minchan Kim > Cc: Nitin Gupt

Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory

t that. If you are ready to submit the patchset, please send out. 1. http://lwn.net/Articles/478049/ Thanks. - Kind regards, Minchan Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory

support to the dimm devices in qemu/seabios: > > > > https://github.com/vliaskov/seabios/commits/memhp-v2 > > https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 > > > > I have not posted the PS3 patches yet in the qemu list, but will post them > > soon for v3