Re: [PATCH] kernel.h: Add for_each_if()

On Wed, 11 Jul 2018 13:51:08 +0200 Daniel Vetter wrote: > But I still have the situation that a bunch of maintainers acked this > and Andrew Morton defacto nacked it, which I guess means I'll keep the > macro in drm? The common way to go about this seems to be to just push > the

Re: [RFC] Per file OOM badness

On Thu, 18 Jan 2018 11:47:48 -0500 Andrey Grodzovsky wrote: > Hi, this series is a revised version of an RFC sent by Christian König > a few years ago. The original RFC can be found at > https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html > >

Re: [patch 1/1] drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union initializer issue

On Thu, 08 Mar 2018 12:06:46 +0200 Jani Nikula <jani.nik...@linux.intel.com> wrote: > On Wed, 07 Mar 2018, a...@linux-foundation.org wrote: > > From: Andrew Morton <a...@linux-foundation.org> > > Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 u

Re: [PATCH 3/3] mm/mmu_notifier: contextual information for event triggering invalidation

On Mon, 3 Dec 2018 15:18:17 -0500 jgli...@redhat.com wrote: > CPU page table update can happens for many reasons, not only as a result > of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also > as a result of kernel activities (memory compression, reclaim, migration, > ...). > >

Re: [PATCH] mm: Replace all open encodings for NUMA_NO_NODE

On Fri, 23 Nov 2018 15:24:16 +0530 Anshuman Khandual wrote: > At present there are multiple places where invalid node number is encoded > as -1. Even though implicitly understood it is always better to have macros > in there. Replace these open encodings for an invalid node number with the >

Re: [PATCH v8 0/7] mm: Merge hmm into devm_memremap_pages, mark GPL-only

On Tue, 20 Nov 2018 15:12:49 -0800 Dan Williams wrote: > Changes since v7 [1]: > At Maintainer Summit, Greg brought up a topic I proposed around > EXPORT_SYMBOL_GPL usage. The motivation was considerations for when > EXPORT_SYMBOL_GPL is warranted and the criteria for taking the > exceptional

Re: [PATCH v4 0/9] mmu notifier provide context informations

On Thu, 31 Jan 2019 11:10:06 -0500 Jerome Glisse wrote: > Andrew what is your plan for this ? I had a discussion with Peter Xu > and Andrea about change_pte() and kvm. Today the change_pte() kvm > optimization is effectively disabled because of invalidate_range > calls. With a minimal couple

Re: [PATCH v6 0/8] mmu notifier provide context informations

On Tue, 26 Mar 2019 12:47:39 -0400 jgli...@redhat.com wrote: > From: Jérôme Glisse > > (Andrew this apply on top of my HMM patchset as otherwise you will have > conflict with changes to mm/hmm.c) > > Changes since v5: > - drop KVM bits waiting for KVM people to express interest if they >

Re: RFC: Run a dedicated hmm.git for 5.3

On Fri, 24 May 2019 09:44:55 -0300 Jason Gunthorpe wrote: > Now that -mm merged the basic hmm API skeleton I think running like > this would get us quickly to the place we all want: comprehensive in tree > users of hmm. > > Andrew, would this be acceptable to you? Sure. Please take care not

Re: dev_pagemap related cleanups

On Thu, 13 Jun 2019 14:24:20 -0600 Logan Gunthorpe wrote: > > > On 2019-06-13 2:21 p.m., Dan Williams wrote: > > On Thu, Jun 13, 2019 at 1:18 PM Logan Gunthorpe wrote: > >> > >> > >> > >> On 2019-06-13 12:27 p.m., Dan Williams wrote: > >>> On Thu, Jun 13, 2019 at 2:43 AM Christoph Hellwig

Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro

On Wed, 12 Jun 2019 01:08:36 +0530 Shyam Saini wrote: > Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD > and FIELD_SIZEOF which are used to calculate the size of a member of > structure, so to bring uniformity in entire kernel source tree lets use > FIELD_SIZEOF and

Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro

On Tue, 11 Jun 2019 15:00:10 -0600 Andreas Dilger wrote: > >> to FIELD_SIZEOF > > > > As Alexey has pointed out, C structs and unions don't have fields - > > they have members. So this is an opportunity to switch everything to > > a new member_sizeof(). > > > > What do people think of that

Re: [PATCH 1/2] mm/hmm: support automatic NUMA balancing

On Fri, 10 May 2019 19:53:23 + "Kuehling, Felix" wrote: > From: Philip Yang > > While the page is migrating by NUMA balancing, HMM failed to detect this > condition and still return the old page. Application will use the new > page migrated, but driver pass the old page physical address

Re: mmotm 2019-07-04-15-01 uploaded (gpu/drm/i915/oa/)

On Thu, 04 Jul 2019 22:22:41 -0700 Joe Perches wrote: > > So when comparing a zero-length file with a non-existent file, diff > > produces no output. > > Why use the -N option ? > > $ diff --help > [...] > -N, --new-file treat absent files as empty > > otherwise > > $ cd

Re: mmotm 2019-07-04-15-01 uploaded (gpu/drm/i915/oa/)

On Fri, 5 Jul 2019 13:14:35 +1000 Stephen Rothwell wrote: > > I checked next-20190704 tag. > > > > I see the empty file > > drivers/gpu/drm/i915/oa/Makefile > > > > Did someone delete it? > > Commit > > 5ed7a0cf3394 ("drm/i915: Move OA files to separate folder") > > from the drm-intel

Re: [PATCH 16/25] device-dax: use the dev_pagemap internal refcount

On Fri, 28 Jun 2019 12:14:44 -0700 Dan Williams wrote: > I believe -mm auto drops patches when they appear in the -next > baseline. So it should "just work" to pull it into the series and send > it along for -next inclusion. Yup. Although it isn't very "auto" - I manually check that the patch

Re: [Bug 204407] New: Bad page state in process Xorg

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 01 Aug 2019 22:34:16 + bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=204407 > > Bug ID: 204407 >Summary: Bad page

Re: [PATCH 1/5] mm: Check if mmu notifier callbacks are allowed to fail

On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote: > Just a bit of paranoia, since if we start pushing this deep into > callchains it's hard to spot all places where an mmu notifier > implementation might fail when it's not allowed to. > > Inspired by some confusion we had discussing i915

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter wrote: > In some special cases we must not block, but there's not a > spinlock, preempt-off, irqs-off or similar critical section already > that arms the might_sleep() debug checks. Add a non_block_start/end() > pair to annotate these. > > This

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, 15 Aug 2019 10:44:29 +0200 Michal Hocko wrote: > > I continue to struggle with this. It introduces a new kernel state > > "running preemptibly but must not call schedule()". How does this make > > any sense? > > > > Perhaps a much, much more detailed description of the oom_reaper > >

Re: [PATCH 3/4] kernel.h: Add non_block_start/end()

On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter wrote: > Hi Peter, > > Iirc you've been involved at least somewhat in discussing this. -mm folks > are a bit undecided whether these new non_block semantics are a good idea. > Michal Hocko still is in support, but Andrew M

Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel

On Thu, 8 Aug 2019 14:12:19 -0700 Kees Cook wrote: > > The ones that are left are the mm ones: 4, 5, 6, 7 and 8. > > > > Andrew, could you take a look and give your Acked-by or pick them up > > directly? > > Given the subsystem Acks, it seems like 3-10 and 12 could all just go > via Andrew? I

Re: [Bug 205065] New: workqueue: PF_MEMALLOC task 173(kswapd0) is flushing !WQ_MEM_RECLAIM events:gen6_pm_rps_work [i915]

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 01 Oct 2019 17:06:35 + bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=205065 > > Bug ID: 205065 >Summary: workqueue:

Re: [PATCH] drm: Limit to INT_MAX in create_blob ioctl

On Wed, 6 Nov 2019 09:24:18 -0800 Kees Cook wrote: > > Since this is -mm can I have a stable sha1 or something for > > referencing? Or do you want to include this in the -mm patch bomb for > > the merge window? > > Traditionally these things live in akpm's tree when they are fixes for > patches

Re: [PATCH v8 20/26] powerpc: book3s64: convert to pin_user_pages() and put_user_page()

On Mon, 9 Dec 2019 21:53:00 -0800 John Hubbard wrote: > > Correction: this is somehow missing the fixes that resulted from Jan Kara's > > review (he > > noted that we can't take a page lock in this context). I must have picked > > up the > > wrong version of it, when I rebased for -rc1. > > >

Re: [PATCH v8 17/26] media/v4l2-core: set pages dirty upon releasing DMA buffers

On Mon, 9 Dec 2019 14:53:35 -0800 John Hubbard wrote: > After DMA is complete, and the device and CPU caches are synchronized, > it's still required to mark the CPU pages as dirty, if the data was > coming from the device. However, this driver was just issuing a > bare put_page() call, without

Re: [PATCH] dma-buf: free dmabuf->name in dma_buf_release()

On Tue, 25 Feb 2020 12:44:46 -0800 Cong Wang wrote: > dma-buff name can be set via DMA_BUF_SET_NAME ioctl, but once set > it never gets freed. > > Free it in dma_buf_release(). > > ... > > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -108,6 +108,7 @@ static int

Re: [PATCH 2/8] mm: Split huge pages on write-notify or COW

On Tue, 3 Dec 2019 14:22:33 +0100 Thomas Hellström (VMware) wrote: > We currently only do COW and write-notify on the PTE level, so if the > huge_fault() handler returns VM_FAULT_FALLBACK on wp faults, > split the huge pages and page-table entries. Also do this for huge PUDs > if there is no

Re: [PATCH v4 0/9] Huge page-table entries for TTM

On Fri, 28 Feb 2020 14:08:04 +0100 Thomas Hellström (VMware) wrote: > I'm wondering what's the best way here to get the patches touching mm > reviewed and accepted? > While drm people and VMware internal people have looked at them, I think > the huge_fault() fallback splitting and the

Re: [PATCH 1/8] mm: Introduce vma_is_special_huge

On Tue, 3 Dec 2019 14:22:32 +0100 Thomas Hellström (VMware) wrote: > From: Thomas Hellstrom > > For VM_PFNMAP and VM_MIXEDMAP vmas that want to support transhuge pages > and -page table entries, introduce vma_is_special_huge() that takes the > same codepaths as vma_is_dax(). > > The use of

Re: [PATCH 0/8] Huge page-table entries for TTM

On Tue, 3 Dec 2019 14:22:31 +0100 Thomas Hellström (VMware) wrote: > In order to save TLB space and CPU usage this patchset enables huge- and giant > page-table entries for TTM and TTM-enabled graphics drivers. Have these savings been measured? They shouild be, please. And documented in

Re: [Bug 206697] #PF: supervisor read access in kernel mode, #PF: error_code(0x0000) - not-present page while building a large project

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 02 Mar 2020 21:55:10 + bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=206697 > > --- Comment #2 from Erhard F. (erhar...@mailbox.org) --- >

Re: + dma-buf-free-dmabuf-name-in-dma_buf_release.patch added to -mm tree

On Wed, 26 Feb 2020 10:36:26 +0100 Daniel Vetter wrote: > On Wed, Feb 26, 2020 at 5:29 AM Sumit Semwal wrote: > > > > Hello Andrew, > > > > > > On Wed, 26 Feb 2020 at 07:25, Andrew Morton > > wrote: > > > > > > > > &g

Re: [PATCH] dma-buf: free dmabuf->name in dma_buf_release()

On Thu, 27 Feb 2020 13:38:03 -0800 Cong Wang wrote: > On Tue, Feb 25, 2020 at 5:54 PM Andrew Morton > wrote: > > > > On Tue, 25 Feb 2020 12:44:46 -0800 Cong Wang > > wrote: > > > > > dma-buff name can be set via DMA_BUF_SET_NAME ioctl, but once set >

Re: [PATCH 01/52] mm/sl[uo]b: export __kmalloc_track(_node)_caller

On Wed, 19 Feb 2020 11:20:31 +0100 Daniel Vetter wrote: > tracker in drm for stuff that's tied to the lifetime of a drm_device, > not the underlying struct device. Kinda like devres, but for drm. > > ... > > Ack for merging through drm trees very much appreciated. Acked

Re: [PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN

On Tue, 14 Jan 2020 12:15:08 -0800 John Hubbard wrote: > > > > Hi Andrew and all, > > > > To clarify: I'm hoping that this series can go into 5.6. > > > > Meanwhile, I'm working on tracking down and solving the problem that Leon > > reported, in the "track FOLL_PIN pages" patch, and that

Re: Ack to merge through DRM tree? WAS [PATCH v4 0/2] mm, drm/ttm: Fix pte insertion with customized protection

from struct vm_area_struct::vm_page_prot. (Michal Hocko) > > Changes since v3: > > *) More documentation regarding under which conditions it's safe to use a > > page protection different from struct vm_area_struct::vm_page_prot. This > > time also in core vm. (Micha

Re: [Bug 206697] #PF: supervisor read access in kernel mode, #PF: error_code(0x0000) - not-present page while building a large project

On Mon, 2 Mar 2020 15:03:29 -0800 Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Mon, 02 Mar 2020 21:55:10 + bugzilla-dae...@bugzilla.kernel.org wrote: > > > https://bugzilla.ke

Re: [PATCH] get_maintainer: Add email addresses from .yaml files

On Sun, 26 Apr 2020 23:33:02 -0700 Joe Perches wrote: > On Mon, 2020-04-27 at 07:57 +0200, Sam Ravnborg wrote: > > Hi Joe. > > Hi Sam. > > > On Sun, Apr 26, 2020 at 10:40:52PM -0700, Joe Perches wrote: > > > .yaml files can contain maintainer/author addresses and it seems > > > unlikely or

Re: [PATCH 21/29] mm: remove the pgprot argument to __vmalloc

On Thu, 30 Apr 2020 22:38:10 -0400 John Dorminy wrote: > the change > description refers to PROT_KERNEL, which is a symbol which does not > appear to exist; perhaps PAGE_KERNEL was meant? Yes, thanks, fixed. ___ dri-devel mailing list

Re: [PATCH hmm v2 1/5] mm/hmm: make CONFIG_DEVICE_PRIVATE into a select

On Fri, 1 May 2020 15:20:44 -0300 Jason Gunthorpe wrote: > From: Jason Gunthorpe > > There is no reason for a user to select this or not directly - it should > be selected by drivers that are going to use the feature, similar to how > CONFIG_HMM_MIRROR works. > > Currently all drivers

Re: Ack to merge through DRM? WAS [PATCH v6 0/9] Huge page-table entries for TTM

On Mon, 16 Mar 2020 13:32:08 +0100 Thomas Hellström (VMware) wrote: > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > Andrew, would it be possible to have an ack

Re: Ack to merge through DRM? WAS [PATCH v6 0/9] Huge page-table entries for TTM

On Thu, 19 Mar 2020 11:20:44 +0100 Thomas Hellström (VMware) wrote: > On 3/19/20 12:27 AM, Andrew Morton wrote: > > On Mon, 16 Mar 2020 13:32:08 +0100 Thomas Hellström (VMware) > > wrote: > > > >>> ___ > >&g

Re: [PATCH V3 15/15] kmap: Consolidate kmap_prot definitions

ase report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Ira Weiny Signed-off-by: Andrew Morton --- arch/sparc/include/asm/highmem.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/sparc/include/asm/highm

Re: [PATCH V3 13/15] parisc/kmap: Remove duplicate kmap code

On Thu, 7 May 2020 08:00:01 -0700 ira.we...@intel.com wrote: > parisc reimplements the kmap calls except to flush it's dcache. This is > arguably an abuse of kmap but regardless it is messy and confusing. > > Remove the duplicate code and have parisc define > ARCH_HAS_FLUSH_ON_KUNMAP for a

Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM

On Mon, 5 Oct 2020 14:47:47 -0300 Jason Gunthorpe wrote: > Andrew please let me know if you need a resend Andrew is rather confused. Can we please identify the minimal patch(es) which are needed for 5.9 and -stable? ___ dri-devel mailing list

Re: [PATCH 1/6] mm: mmap: fix fput in error path

On Fri, 9 Oct 2020 17:03:37 +0200 "Christian König" wrote: > Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..." > adds a workaround for a bug in mmap_region. > > As the comment states ->mmap() callback can change > vma->vm_file and so we might call fput() on the wrong file. > > Revert

Re: [PATCH v4 00/23] device-dax: Support sub-dividing soft-reserved ranges

On Wed, 19 Aug 2020 18:53:57 -0700 Dan Williams wrote: > > I think I am missing some important pieces. Bear with me. > > No worries, also bear with me, I'm going to be offline intermittently > until at least mid-September. Hopefully Joao and/or Vishal can jump in > on this discussion.

Re: [PATCH v4 15/23] device-dax: Add resize support

On Sun, 02 Aug 2020 22:03:46 -0700 Dan Williams wrote: > Make the device-dax 'size' attribute writable to allow capacity to be > split between multiple instances in a region. The intended consumers of > this capability are users that want to split a scarce memory resource > between device-dax

Re: remove alloc_vm_area v2

On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > this series removes alloc_vm_area, which was left over from the big > vmalloc interface rework. It is a rather arkane interface, basicaly > the equivalent of get_vm_area + actually faulting in all PTEs in > the allocated area. It

Re: [PATCH v2] io-mapping: Indicate mapping failure

On Tue, 21 Jul 2020 21:02:44 + "Ruhl, Michael J" wrote: > >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix > >+++ a/include/linux/io-mapping.h > >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io > >resource_size_t base, > >

Re: [PATCH v2] io-mapping: Indicate mapping failure

On Tue, 21 Jul 2020 13:19:36 -0400 "Michael J. Ruhl" wrote: > The !ATOMIC_IOMAP version of io_maping_init_wc will always return > success, even when the ioremap fails. > > Since the ATOMIC_IOMAP version returns NULL when the init fails, and > callers check for a NULL return on error this is

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote: > > > > > > Actually it occurs to me that the patch consolidating kmap_prot is odd for > > > sparc 32 bit... > > > > > > Its a long shot but could you try reverting this patch? > > > > > > 4ea7d2419e3f kmap: consolidate kmap_prot definitions

Re: [PATCH 1/2] mm: mmap: fix fput in error path v2

On Wed, 18 Nov 2020 11:57:44 +0100 Christian König wrote: > Am 06.11.20 um 23:48 schrieb Andrew Morton: > > On Fri, 6 Nov 2020 12:48:05 +0100 "Christian König" > > wrote: > > > >> Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args...&quo

Re: [PATCH 1/2] mm: mmap: fix fput in error path v2

On Fri, 6 Nov 2020 12:48:05 +0100 "Christian König" wrote: > Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..." > adds a workaround for a bug in mmap_region. > > As the comment states ->mmap() callback can change > vma->vm_file and so we might call fput() on the wrong file. > > Revert

Re: [PATCH v11 00/10] Add support for SVM atomics in Nouveau

On Wed, 16 Jun 2021 20:59:27 +1000 Alistair Popple wrote: > This is my series to add support for SVM atomics in Nouveau Can we please have a nice [0/n] overview for this patchset?

Re: [PATCH v9 07/10] mm: Device exclusive memory access

On Mon, 24 May 2021 23:27:22 +1000 Alistair Popple wrote: > Some devices require exclusive write access to shared virtual > memory (SVM) ranges to perform atomic operations on that memory. This > requires CPU page tables to be updated to deny access whilst atomic > operations are occurring. > >

Fw: [Bug 211587] New: X: page allocation failure: order:8, mode:0x190dc2(GFP_HIGHUSER|__GFP_NORETRY|__GFP_ZERO|__GFP_NOMEMALLOC), nodemask=(null),cpuset=/,mems_allowed=0

I'm not sure who this belongs to... Begin forwarded message: Date: Sat, 06 Feb 2021 01:49:51 + From: bugzilla-dae...@bugzilla.kernel.org To: a...@linux-foundation.org Subject: [Bug 211587] New: X: page allocation failure: order:8,

Fw: [Bug 211707] New: BUG: unable to handle page fault for address: ffffa147bdf6b91d

Looks like a recent regression? Begin forwarded message: Date: Thu, 11 Feb 2021 14:27:43 + From: bugzilla-dae...@bugzilla.kernel.org To: a...@linux-foundation.org Subject: [Bug 211707] New: BUG: unable to handle page fault for address: a147bdf6b91d

Re: [PATCH 2/2] drm/ttm: optimize the pool shrinker a bit v2

On Thu, 15 Apr 2021 13:56:24 +0200 "Christian König" wrote: > @@ -530,6 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool) > for (j = 0; j < MAX_ORDER; ++j) > ttm_pool_type_fini(>caching[i].orders[j]); > } > + > + /* We removed the

Re: [PATCH 1/2] mm/vmscan: add sync_shrinkers function v2

or every alloc/free operation. > > v2: rework the commit message to make clear why we need this Acked-by: Andrew Morton

Re: [PATCH v1 00/12] MEMORY_DEVICE_COHERENT for CPU-accessible coherent device memory

On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote: > This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory > owned by a device that can be mapped into CPU page tables like > MEMORY_DEVICE_GENERIC and can also be migrated like MEMORY_DEVICE_PRIVATE. > With

Re: [PATCH v1 00/12] MEMORY_DEVICE_COHERENT for CPU-accessible coherent device memory

On Tue, 12 Oct 2021 15:56:29 -0300 Jason Gunthorpe wrote: > > To what other uses will this infrastructure be put? > > > > Because I must ask: if this feature is for one single computer which > > presumably has a custom kernel, why add it to mainline Linux? > > Well, it certainly isn't just

Re: [next] [dragonboard 410c] Unable to handle kernel paging request at virtual address 00000000007c4240

On Thu, 21 Oct 2021 19:51:20 +0200 Vlastimil Babka wrote: > >> Then we have to figure out how to order a fix between DRM and mmotm... > > > > That is the question! The problem exists only in the merge of the > > two. On current DRM side stack_depot_init() exists but it's __init and > > does not

Re: [PATCH RFC v2] mm: Add f_ops->populate()

On Sun, 6 Mar 2022 05:26:55 +0200 Jarkko Sakkinen wrote: > Sometimes you might want to use MAP_POPULATE to ask a device driver to > initialize the device memory in some specific manner. SGX driver can use > this to request more memory by issuing ENCLS[EAUG] x86 opcode for each > page in the

Re: [PATCH v4 00/10] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping

On Thu, 27 Jan 2022 17:20:40 -0600 "Sierra Guiza, Alejandro (Alex)" wrote: > Andrew, > We're somehow new on this procedure. Are you referring to rebase this > patch series to > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > <5.17-rc1 tag>? No, against current Linus

Re: [PATCH v4 00/10] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping

On Wed, 26 Jan 2022 21:09:39 -0600 Alex Sierra wrote: > This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory > owned by a device that can be mapped into CPU page tables like > MEMORY_DEVICE_GENERIC and can also be migrated like > MEMORY_DEVICE_PRIVATE. Some more reviewer input

Re: [Bug 215807] Bad page state in process systemd-udevd

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). hm, that's my third `bad page' report in three emails. But I'm not seeing a pattern - this one might be a DRM thing. On Tue, 12 Apr 2022 20:52:18 + bugzilla-dae...@kernel.org wrote: >

Re: [PATCH v4 07/13] lib: test_hmm add ioctl to get zone device type

On Tue, 31 May 2022 10:56:23 -0500 Alex Sierra wrote: > new ioctl cmd added to query zone device type. This will be > used once the test_hmm adds zone device coherent type. > > @@ -1026,6 +1027,15 @@ static int dmirror_snapshot(struct dmirror *dmirror, > return ret; > } > > +static int

Re: [linux-next:master] BUILD REGRESSION 8cb8311e95e3bb58bd84d6350365f14a718faa6d

On Wed, 25 May 2022 23:07:35 +0100 Jessica Clarke wrote: > This is i386, so an unsigned long is 32-bit, but i_blocks is a blkcnt_t > i.e. a u64, which makes the shift without a cast of the LHS fishy. Ah, of course, thanks. I remember 32 bits ;) ---

Re: [linux-next:master] BUILD REGRESSION 8cb8311e95e3bb58bd84d6350365f14a718faa6d

On Thu, 26 May 2022 05:35:20 +0800 kernel test robot wrote: > tree/branch: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > branch HEAD: 8cb8311e95e3bb58bd84d6350365f14a718faa6d Add linux-next > specific files for 20220525 > > Error/Warning reports: > > ... > >

Re: [linux-next:master] BUILD REGRESSION 736ee37e2e8eed7fe48d0a37ee5a709514d478b3

On Wed, 18 May 2022 20:41:27 -0700 Guenter Roeck wrote: > On 5/18/22 17:55, kernel test robot wrote: > > tree/branch: > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > branch HEAD: 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Add linux-next > > specific files for

Re: [PATCH v7 01/14] mm: rename is_pinnable_pages to is_pinnable_longterm_pages

On Thu, 30 Jun 2022 00:15:06 +0200 David Hildenbrand wrote: > On 30.06.22 00:08, Felix Kuehling wrote: > > On 2022-06-29 03:33, David Hildenbrand wrote: > >> On 29.06.22 05:54, Alex Sierra wrote: > >>> is_pinnable_page() and folio_is_pinnable() were renamed to > >>> is_longterm_pinnable_page()

Re: [PATCH v7 03/14] mm: handling Non-LRU pages returned by vm_normal_pages

On Wed, 29 Jun 2022 11:59:26 +0200 David Hildenbrand wrote: > On 29.06.22 05:54, Alex Sierra wrote: > > With DEVICE_COHERENT, we'll soon have vm_normal_pages() return > > device-managed anonymous pages that are not LRU pages. Although they > > behave like normal pages for purposes of mapping in

Re: [PATCH v7 01/14] mm: rename is_pinnable_pages to is_pinnable_longterm_pages

On Wed, 29 Jun 2022 18:08:40 -0400 Felix Kuehling wrote: > > > > I'd have called it "is_longterm_pinnable_page", but I am not a native > > speaker, so no strong opinion :) > > I think only the patch title has the name backwards. The code uses > is_longterm_pinnable_page. Patch title was

Re: [PATCH v5 00/13] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping

On Tue, 31 May 2022 15:00:28 -0500 Alex Sierra wrote: > This is our MEMORY_DEVICE_COHERENT patch series rebased and updated > for current 5.18.0 I plan to move this series into the non-rebasing mm-stable branch in a few days. Unless sternly told not to do so!

Re: [PATCH v9 06/14] mm/gup: migrate device coherent pages when pinning instead of failing

On Mon, 18 Jul 2022 12:56:29 +0200 David Hildenbrand wrote: > > /* > > * Try to move out any movable page before pinning the range. > > */ > > @@ -1919,7 +1948,8 @@ static long check_and_migrate_movable_pages(unsigned > > long nr_pages, > >

Re: [linux-next:master] BUILD REGRESSION 4662b7adea50bb62e993a67f611f3be625d3df0d

On Thu, 14 Jul 2022 09:56:19 +0800 kernel test robot wrote: > lib/maple_tree.c:1522:52: warning: Parameter 'gaps' can be declared with > const [constParameter] > lib/maple_tree.c:1871:21: warning: Array index 'split' is used before limits > check. [arrayIndexThenCheck] >

Re: [PATCH v9 06/14] mm/gup: migrate device coherent pages when pinning instead of failing

On Mon, 25 Jul 2022 21:22:06 -0500 "Sierra Guiza, Alejandro (Alex)" wrote: > >> a) add the || to the end of the previous line > >> b) indent such the we have a nice-to-read alignment > >> > >> if (!list_empty(_page_list) || isolation_error_count || > >> coherent_pages) > >> > > I missed

Re: [PATCH v2 8/8] hmm-tests: Add test for migrate_device_range()

On Wed, 28 Sep 2022 22:01:22 +1000 Alistair Popple wrote: > @@ -1401,22 +1494,7 @@ static int dmirror_device_init(struct dmirror_device > *mdevice, int id) > > static void dmirror_device_remove(struct dmirror_device *mdevice) > { > - unsigned int i; > - > - if

Re: [PATCH 00/19] Introduce __xchg, non-atomic xchg

On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda wrote: > Hi all, > > I hope there will be place for such tiny helper in kernel. > Quick cocci analyze shows there is probably few thousands places > where it could be useful. So to clarify, the intent here is a simple readability cleanup for

Re: [PATCH mm-unstable v1 16/20] mm/frame-vector: remove FOLL_FORCE usage

On Mon, 28 Nov 2022 09:18:47 +0100 David Hildenbrand wrote: > > Less chances of things going wrong that way. > > > > Just mention in the v2 cover letter that the first patch was added to > > make it easy to backport that fix without being hampered by merge > > conflicts if it was added after

Re: [PATCH v2 0/2] Fix a bunch of allmodconfig errors

On Fri, 25 Nov 2022 12:07:48 + Lee Jones wrote: > Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST") > WERROR > now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig > > builds. This leads to some interesting failures, each resolved in this

Re: [PATCH v2 0/2] Fix a bunch of allmodconfig errors

On Fri, 25 Nov 2022 12:07:48 + Lee Jones wrote: > Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST") > WERROR > now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig > > builds. This leads to some interesting failures, each resolved in this

Re: [PATCH] mm/memremap: Introduce pgmap_request_folio() using pgmap offsets

On Wed, 30 Nov 2022 16:22:50 -0800 Dan Williams wrote: > I think since there is no urgent need for this series to move forward in > v6.2 I can take the time to kill the need for pfn_to_pgmap_offset() and > circle back for this in v6.3. I'll drop v3 of "Fix the DAX-gup mistake" and

Re: [PATCH 1/2] docs: process: allow Closes tags with links

On Wed, 15 Mar 2023 18:44:56 +0100 Matthieu Baerts wrote: > +Closes: https://example.com/issues/1234 I (and a few others) have been using "Addresses:" on occasion. I think "Addresses:" is a bit more general. And more humble - "I tried to fix it", not "there, I fixed it". But

Re: [PATCH 0/4] log2: make is_power_of_2() more generic

On Thu, 30 Mar 2023 13:42:39 +0300 Jani Nikula wrote: > is_power_of_2() only works for types <= sizeof(unsigned long) and it's > also not a constant expression. There are a number of places in kernel > where is_power_of_2() is called on u64, which fails on 32-bit > builds. Try to remedy that.

Re: [PATCH 0/4] log2: make is_power_of_2() more generic

On Thu, 30 Mar 2023 21:53:03 + David Laight wrote: > > But wouldn't all these issues be addressed by simply doing > > > > #define is_power_of_2(n) (n != 0 && ((n & (n - 1)) == 0)) > > > > ? > > > > (With suitable tweaks to avoid evaluating `n' more than once) > > I think you need to use

Re: [PATCH] mm: fix hugetlb page unmap count balance issue

On Wed, 7 Jun 2023 13:53:10 -0700 Mike Kravetz wrote: > > > > BUGs aren't good. Can we please find a way to push this along? > > > > Have we heard anything from any udmabuf people? > > > > I have not heard anything. When this issue popped up, it took me by surprise. > > udmabuf maintainer

Re: [PATCH] mm: fix hugetlb page unmap count balance issue

On Tue, 16 May 2023 15:34:40 -0700 Mike Kravetz wrote: > On 05/15/23 10:04, Mike Kravetz wrote: > > On 05/12/23 16:29, Mike Kravetz wrote: > > > On 05/12/23 14:26, James Houghton wrote: > > > > On Fri, May 12, 2023 at 12:20 AM Junxiao Chang > > > > wrote: > > > > > > > > This alone doesn't

Re: [PATCH v4 1/1] drm/i915: Move abs_diff() to math.h

On Thu, 3 Aug 2023 16:19:18 +0300 Andy Shevchenko wrote: > abs_diff() belongs to math.h. Move it there. > This will allow others to use it. > > ... > > --- a/include/linux/math.h > +++ b/include/linux/math.h > @@ -155,6 +155,13 @@ __STRUCT_FRACT(u32) >

Re: [PATCH 2/2] xfs: disable large folio support in xfile_create

On Thu, 11 Jan 2024 18:22:50 -0800 "Darrick J. Wong" wrote: > On Thu, Jan 11, 2024 at 10:45:53PM +, Matthew Wilcox wrote: > > On Thu, Jan 11, 2024 at 02:00:53PM -0800, Andrew Morton wrote: > > > On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong"

Re: [PATCH] mm/cma: Drop cma_get_name()

On Tue, 6 Feb 2024 09:45:18 +0530 Anshuman Khandual wrote: > cma_get_name() just returns cma->name without any additional transformation > unlike other helpers such as cma_get_base() and cma_get_size(). This helper > is not worth the additional indirection, and can be dropped after replacing >

Re: disable large folios for shmem file used by xfs xfile

On Wed, 10 Jan 2024 10:21:07 +0100 Christoph Hellwig wrote: > Hi all, > > Darrick reported that the fairly new XFS xfile code blows up when force > enabling large folio for shmem. This series fixes this quickly by disabling > large folios for this particular shmem file for now until it can be

Re: [PATCH 2/2] xfs: disable large folio support in xfile_create

On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong" wrote: > > > Fixing this will require a bit of an API change, and prefeably sorting out > > > the hwpoison story for pages vs folio and where it is placed in the shmem > > > API. For now use this one liner to disable large folios. > > > > >

<    1   2