On Fri, May 02, 2025 at 11:59:23AM +0200, Jens Wiklander wrote:
> Export the two functions cma_alloc() and cma_release().
Why? This is clearly part of a larger series, but you've given those of
us who are subscribed to linux-mm absolutely no information about why
you want to do this.
The ->writepage operation is being removed. Since this function
exclusively deals with shmem folios, we can call shmem_writeout()
to write it.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/gpu/drm/ttm/ttm_backup.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --gi
Call swap_writeout() and shmem_writeout() from pageout() instead.
Signed-off-by: Matthew Wilcox (Oracle)
Reviewed-by: Baolin Wang
Tested-by: Baolin Wang
---
block/blk-wbt.c | 2 +-
mm/page_io.c| 3 +--
mm/shmem.c | 23 +--
mm/swap.h | 4 ++--
mm
The ->writepage operation has been removed from all filesystems but
shmem and swap, neither of which call in here. Remove this alternative
to calling ->writepages.
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/page-writeback.c | 28 ++--
1 file changed, 2 inse
s they were merged
- Add 9p patch
- Add warning in migration code about aops which set writepages but not
migrate_folio
Matthew Wilcox (Oracle) (9):
9p: Add a migrate_folio method
vboxsf: Convert to writepages
migrate: Remove call to ->writepage
writeback: Remove writeback_use_
On Fri, Apr 04, 2025 at 01:31:11AM -0700, Christoph Hellwig wrote:
> The whole series looks good to me:
>
> Reviewed-by: Christoph Hellwig
Thanks! And thanks for removing writepage from some filesystems.
On Fri, Apr 04, 2025 at 01:26:29AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 02, 2025 at 04:00:00PM +0100, Matthew Wilcox (Oracle) wrote:
> > Convert from an inefficient loop to the standard writeback iterator.
>
> Not for this patch but a follow on: we really need
On Thu, Apr 03, 2025 at 12:46:17PM +0900, Dominique Martinet wrote:
> Matthew Wilcox (Oracle) wrote on Wed, Apr 02, 2025 at 03:59:55PM +0100:
> > The migration code used to be able to migrate dirty 9p folios by writing
> > them back using writepage. When the writepage method was
few hidden calls to compound_head().
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/vboxsf/file.c | 47 +--
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/fs/vboxsf/file.c b/fs/vboxsf/file.c
index b780deb81b02..b492794f8e9a 100644
--- a
The writepage callback is going away; filesystems must implement
migrate_folio or else dirty folios will not be migratable.
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/migrate.c | 60 ++--
1 file changed, 7 insertions(+), 53 deletions(-)
diff
All callers and implementations are now removed, so remove the operation
and update the documentation to match.
Signed-off-by: Matthew Wilcox (Oracle)
---
Documentation/admin-guide/cgroup-v2.rst | 2 +-
Documentation/filesystems/fscrypt.rst | 2 +-
Documentation/filesystems/locking.rst
on machines which use 9p heavily.
Fixes: 80105ed2fd27 (9p: Use netfslib read/write_iter)
Cc: sta...@vger.kernel.org
Cc: David Howells
Cc: v...@lists.linux.dev
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/9p/vfs_addr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/9p/vfs_addr.c b/fs/9p
Convert from an inefficient loop to the standard writeback iterator.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 32 ++-
1 file changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b
This will be the replacement for shmem_writepage().
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/shmem_fs.h | 7 ---
mm/shmem.c | 20 ++--
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/include/linux/shmem_fs.h b/include/linux
On Thu, Mar 06, 2025 at 12:25:53AM +0900, Ryosuke Yasuoka wrote:
> Some drivers can use vmap in drm_panic, however, vmap is sleepable and
> takes locks. Since drm_panic will vmap in panic handler, atomic_vmap
> requests pages with GFP_ATOMIC and maps KVA without locks and sleep.
In addition to the
On Wed, Mar 05, 2025 at 08:39:17AM +0100, Simona Vetter wrote:
> On Tue, Mar 04, 2025 at 04:21:30PM +0000, Matthew Wilcox wrote:
> > On Fri, Feb 21, 2025 at 05:53:16PM +, Lorenzo Stoakes wrote:
> > > On Fri, Feb 21, 2025 at 05:31:29PM +0000, Matthew Wilcox (Oracle) wrote:
&
On Fri, Feb 21, 2025 at 05:53:16PM +, Lorenzo Stoakes wrote:
> On Fri, Feb 21, 2025 at 05:31:29PM +0000, Matthew Wilcox (Oracle) wrote:
> > There is no need to print out page->index as part of the debug message.
> >
> > Signed-off-by: Matthew Wilcox (Oracle)
There is no need to print out page->index as part of the debug message.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/staging/fbtft/fbtft-core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-cor
On Thu, Jan 30, 2025 at 12:00:40PM +0200, Kirill A. Shutemov wrote:
> Use folios instead of pages.
>
> This is preparation for removing PG_reclaim.
Well, this is a horrid little function. Rather than iterating just the
dirty folios, it iterates all folios, then locks them before checking
whether
On Mon, Jan 27, 2025 at 04:55:58PM +0200, Jani Nikula wrote:
> You could have static const within functions too. You get the rodata
> protection and function local scope, best of both worlds?
timer_active is on the stack, so it can't be static const.
Does this really need to be cc'd to such a wid
On Wed, Jan 15, 2025 at 11:31:29AM +0200, Kirill A. Shutemov wrote:
> -static void lru_deactivate_file(struct lruvec *lruvec, struct folio *folio)
> -{
> - bool active = folio_test_active(folio) || lru_gen_enabled();
> - long nr_pages = folio_nr_pages(folio);
> -
> - if (folio_test_unev
On Mon, Jan 13, 2025 at 11:34:53AM +0200, Kirill A. Shutemov wrote:
> diff --git a/mm/migrate.c b/mm/migrate.c
> index caadbe393aa2..beba72da5e33 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -686,6 +686,8 @@ void folio_migrate_flags(struct folio *newfolio, struct
> folio *folio)
>
On Mon, Jan 13, 2025 at 11:34:45AM +0200, Kirill A. Shutemov wrote:
> Use PG_dropbehind instead of PG_reclaim and remove PG_reclaim.
I was hoping we'd end up with the name PG_reclaim instead of the name
PG_dropbehind. PG_reclaim is a better name for this functionality.
On Wed, Jan 08, 2025 at 10:12:36PM +0100, David Hildenbrand wrote:
> On 08.01.25 21:54, Matthew Wilcox wrote:
> > Not necessarily! We already do that (since 2022) for DAX (see
> > 6a8e0596f004). rmap lets you find every place that a given range
> > of a file is mapped int
On Wed, Jan 08, 2025 at 09:14:53PM +0100, David Hildenbrand wrote:
> On 08.01.25 18:32, Matthew Wilcox wrote:
> > On Wed, Jan 08, 2025 at 04:18:42PM +, Lorenzo Stoakes wrote:
> > > @@ -280,7 +269,10 @@ static void fb_deferred_io_work(struct work_s
On Wed, Jan 08, 2025 at 04:18:42PM +, Lorenzo Stoakes wrote:
> @@ -280,7 +269,10 @@ static void fb_deferred_io_work(struct work_struct *work)
> struct folio *folio = page_folio(pageref->page);
>
> folio_lock(folio);
> - folio_mkclean(folio);
> +
On Wed, Jan 08, 2025 at 04:18:41PM +, Lorenzo Stoakes wrote:
> +++ b/include/linux/rmap.h
> @@ -754,6 +754,26 @@ unsigned long page_address_in_vma(const struct folio
> *folio,
> */
> int folio_mkclean(struct folio *);
>
> +/**
The kerneldoc comment should be with the implementation, not
On Wed, Jan 08, 2025 at 04:18:40PM +, Lorenzo Stoakes wrote:
> +/*
> + * rmap_walk_file - do something to file page using the object-based rmap
> method
> + * @folio: the folio to be handled
> + * @rwc: control variable according to each walk type
> + * @locked: caller holds relevant rmap lock
I've pushed out a new tree to
git://git.infradead.org/users/willy/pagecache.git shrunk-page
aka
http://git.infradead.org/?p=users/willy/pagecache.git;a=shortlog;h=refs/heads/shrunk-page
The observant will notice that it doesn't actually shrink struct page
yet. However, we're getting close. What
On Tue, Nov 12, 2024 at 03:22:46PM +0100, David Hildenbrand wrote:
> On 12.11.24 14:53, Jason Gunthorpe wrote:
> > On Tue, Nov 12, 2024 at 10:10:06AM +0100, David Hildenbrand wrote:
> > > On 12.11.24 06:26, Matthew Wilcox wrote:
> > > > I don't want you to
On Mon, Nov 11, 2024 at 08:26:54AM +, Fuad Tabba wrote:
> Thanks for your comments Jason, and for clarifying my cover letter
> David. I think David has covered everything, and I'll make sure to
> clarify this in the cover letter when I respin.
I don't want you to respin. I think this is a bad
On Sun, Jun 23, 2024 at 10:29:30AM +0800, Yafang Shao wrote:
> On Fri, Jun 21, 2024 at 9:57 PM Matthew Wilcox wrote:
> >
> > On Fri, Jun 21, 2024 at 10:29:54AM +0800, Yafang Shao wrote:
> > > +++ b/mm/internal.h
> >
> > Why are you putting __kstrndup in a he
On Fri, Jun 21, 2024 at 10:29:54AM +0800, Yafang Shao wrote:
> +++ b/mm/internal.h
Why are you putting __kstrndup in a header file when it's only used
in util.c?
Also, I think this function is actually __kmemdup_nul(), not
__kstrndup().
On Sat, Mar 23, 2024 at 10:01:47PM +0530, Amogh Cheluvaraj wrote:
> Fix duplicate C declaration warnings at
> Documentation/gpu/drm-kms.rst that was found by
> compiling htmldocs
I'm sure this removes the warning, but it removes all kernel-doc
which exists in drivers/gpu/drm/drm_fourcc.c. Isn't t
We're currently trying to remove page->mapping from the entire kernel.
This has me interested in fb_defio and since I made such a mess of it
with commits ccf953d8f3d6 / 0b78f8bcf495, I'd like to discuss what to
do before diving in.
Folios continue to have a mapping. So we can effectively do
page_
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"
> 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
On Wed, Jan 10, 2024 at 05:28:22PM +0200, Joonas Lahtinen wrote:
> Quoting Joonas Lahtinen (2024-01-10 17:20:24)
> > However we specifically pass "huge=within_size" to vfs_kern_mount when
> > creating a private mount of tmpfs for the purpose of i915 created
> > allocations.
> >
> > Older hardware
On Wed, Jan 10, 2024 at 10:21:07AM +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
On Fri, Dec 15, 2023 at 10:05:33PM -0800, Vivek Kasireddy wrote:
> +++ b/include/linux/memfd.h
> @@ -6,11 +6,16 @@
>
> #ifdef CONFIG_MEMFD_CREATE
> extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int
> arg);
> +extern struct folio *memfd_alloc_folio(struct file *memfd, pg
On Mon, Dec 11, 2023 at 11:38:02PM -0800, Vivek Kasireddy wrote:
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -42,7 +42,7 @@ static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf)
> if (pgoff >= ubuf->pagecount)
> return VM_FAULT_SIGBUS;
>
> - pfn = page_to_pfn(&ubuf->folios[p
On Mon, Dec 11, 2023 at 11:38:01PM -0800, Vivek Kasireddy wrote:
> @@ -42,7 +42,7 @@ static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf)
> if (pgoff >= ubuf->pagecount)
> return VM_FAULT_SIGBUS;
>
> - pfn = page_to_pfn(ubuf->pages[pgoff]);
> + pfn = page_to_pfn(&u
As far as anybody can tell, this product never shipped. If it did,
it shipped in 2007 and nobody has access to one any more. Remove the
fbdev driver and the backlight driver.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/video/backlight/Kconfig |7 -
drivers/video/backlight
As far as anybody can tell, this product never shipped. If it did,
it shipped in 2007 and nobody has access to one any more. Remove the
mtd NOR driver.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/mtd/maps/Kconfig| 7 -
drivers/mtd/maps/Makefile | 1 -
drivers/mtd/maps
If the shared memory object is larger than the DRM object that it backs,
we can overrun the page array. Limit the number of pages we install
from each folio to prevent this.
Signed-off-by: Matthew Wilcox (Oracle)
Reported-by: Oleksandr Natalenko
Tested-by: Oleksandr Natalenko
Link: https
On Thu, Oct 05, 2023 at 02:30:55PM +0200, Oleksandr Natalenko wrote:
> No-no, sorry for possible confusion. Let me explain again:
>
> 1. we had an issue with i915, which was introduced by 0b62af28f249, and later
> was fixed by 863a8eb3f270
> 2. now I've discovered another issue, which looks very
On Thu, Oct 05, 2023 at 09:56:03AM +0200, Oleksandr Natalenko wrote:
> Hello.
>
> On čtvrtek 5. října 2023 9:44:42 CEST Thomas Zimmermann wrote:
> > Hi
> >
> > Am 02.10.23 um 17:38 schrieb Oleksandr Natalenko:
> > > On pondělí 2. října 2023 16:32:45 CEST Matt
On Mon, Oct 02, 2023 at 01:02:52PM +0200, Oleksandr Natalenko wrote:
> > > > > BUG: KFENCE: memory corruption in drm_gem_put_pages+0x186/0x250
> > > > >
> > > > > Corrupted memory at 0xe173a294 [ ! ! ! ! ! ! ! ! ! ! ! ! ! !
> > > > > ! ! ] (in kfence-#108):
> > > > > drm_gem_put_pages+0x
functions may also have been affected.
Clamp the length of the last entry in the sg list to be the expected
length.
Signed-off-by: Matthew Wilcox (Oracle)
Fixes: 0b62af28f249 ("i915: convert shmem_sg_free_table() to use a folio_batch")
Cc: sta...@vger.kernel.org # 6.5.x
L
On Tue, Sep 19, 2023 at 08:11:47PM +0200, Oleksandr Natalenko wrote:
> I can confirm this one fixes the issue for me on T460s laptop. Thank you!
Yay!
> Should you submit it, please add:
>
> Fixes: 0b62af28f2 ("i915: convert shmem_sg_free_table() to use a folio_batch")
Thanks for collecting all
On Tue, Sep 19, 2023 at 04:43:41PM +0100, Matthew Wilcox wrote:
> Could I ask you to try this patch? I'll follow up with another patch
> later because I think I made another assumption that may not be valid.
Ah, no, never mind. I thought we could start in the middle of a folio,
bu
On Tue, Sep 19, 2023 at 10:26:42AM +0200, Oleksandr Natalenko wrote:
> Andrzej asked me to try to revert commits 0b62af28f249, e0b72c14d8dc and
> 1e0877d58b1e, and reverting those fixed the i915 crash for me. The
> e0b72c14d8dc and 1e0877d58b1e commits look like just prerequisites, so I
> assume
On Tue, Aug 29, 2023 at 02:35:34PM -0400, James Zhu wrote:
>
> On 2023-08-29 14:33, Matthew Wilcox wrote:
> > On Tue, Aug 29, 2023 at 01:34:22PM -0400, James Zhu wrote:
> > > > > > @@ -1067,7 +1055,7 @@ static void drm_core_exit(void)
> > > > > &g
On Tue, Aug 29, 2023 at 01:34:22PM -0400, James Zhu wrote:
> > > > @@ -1067,7 +1055,7 @@ static void drm_core_exit(void)
> > > > unregister_chrdev(DRM_MAJOR, "drm");
> > > > debugfs_remove(drm_debugfs_root);
> > > > drm_sysfs_destroy();
> > > > - idr_destroy(&drm_minor
Signed-off-by: Xueshi Hu
Reviewed-by: Matthew Wilcox (Oracle)
On Mon, Aug 21, 2023 at 01:16:43PM +0200, Jan Kara wrote:
> On Sat 19-08-23 20:42:25, Xueshi Hu wrote:
> > In folio_mark_dirty(), it will automatically fallback to
> > noop_dirty_folio() if a_ops->dirty_folio is not registered.
> >
> > As anon_aops, dev_dax_aops and fb_deferred_io_aops becames emp
On Mon, Aug 21, 2023 at 12:46:37PM +0900, Byungchul Park wrote:
> @@ -377,44 +421,88 @@ static __always_inline int Page##uname(struct page
> *page) \
> #define SETPAGEFLAG(uname, lname, policy)\
> static __always_inline
On Mon, Aug 21, 2023 at 12:46:20PM +0900, Byungchul Park wrote:
> @@ -1219,6 +1220,9 @@ static inline bool folio_trylock_flag(struct folio
> *folio, int bit_nr,
> /* How many times do we accept lock stealing from under a waiter? */
> int sysctl_page_lock_unfairness = 5;
>
> +static struct dept
On Sun, Jul 30, 2023 at 09:57:06PM +0800, Zhu Yanjun wrote:
>
> 在 2023/7/30 19:18, Matthew Wilcox 写道:
> > On Sun, Jul 30, 2023 at 07:01:26PM +0800, Zhu Yanjun wrote:
> > > Does the following function have folio version?
> > >
> > > "
>
On Sun, Jul 30, 2023 at 07:01:26PM +0800, Zhu Yanjun wrote:
> Does the following function have folio version?
>
> "
> int sg_alloc_append_table_from_pages(struct sg_append_table *sgt_append,
> struct page **pages, unsigned int n_pages, unsigned int offset,
> unsigned lo
Remove the last usage of pagevecs. There is a slight change here; we
now free the folio_batch as soon as it fills up instead of freeing the
folio_batch when we try to add a page to a full batch. This should have
no effect in practice.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux
Most of these should just refer to the LRU cache rather than the
data structure used to implement the LRU cache.
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/huge_memory.c| 2 +-
mm/khugepaged.c | 6 +++---
mm/ksm.c| 6 +++---
mm/memory.c | 6 +++---
mm
olios.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/scatterlist.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index ec46d8e8e49d..77df3d7b18a6 100644
--- a/include/linux/scatterlist.h
+++ b/include/
: Matthew Wilcox (Oracle)
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 55 +--
1 file changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 33d5d5178103..8f1633c3fb93 100644
--- a
We don't use pagevecs for the LRU cache any more, and we don't know
that the failed invalidations were due to the folio being in an
LRU cache. So rename it to be more accurate.
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/fadvise.c | 16 +++-
mm/internal.h |
This performs the same role as __pagevec_release(), ie skipping the
check for batch length of 0.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/pagevec.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/linux/pagevec.h b/include/linux/pagevec.h
index
All callers have now been converted to call check_move_unevictable_folios().
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/swap.h | 1 -
mm/vmscan.c | 17 -
2 files changed, 18 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index
We're almost done with the pagevec -> folio_batch conversion. Finish
the job.
Matthew Wilcox (Oracle) (13):
afs: Convert pagevec to folio_batch in afs_extend_writeback()
mm: Add __folio_batch_release()
scatterlist: Add sg_set_folio()
i915: Convert shmem_sg_free_table()
Remove a few hidden compound_head() calls by converting the returned
page to a folio once and using the folio APIs.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/gpu/drm/drm_gem.c | 68 ++-
1 file changed, 39 insertions(+), 29 deletions(-)
diff --git a
Remove one of the last remaining users of pagevec.
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/gpu/drm/i915/i915_gpu_error.c | 50 +--
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915
Removes a folio->page->folio conversion for each folio that's involved.
More importantly, removes one of the last few uses of a pagevec.
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/afs/write.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/
This should always have been called folio_batch_count().
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/pagevec.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/pagevec.h b/include/linux/pagevec.h
index 42aad53e382e..3a9d29dd28a3 100644
--- a
These files no longer need pagevec.h, mostly due to function declarations
being moved out of it.
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/fadvise.c| 1 -
mm/memory_hotplug.c | 1 -
mm/migrate.c| 1 -
mm/readahead.c | 1 -
mm/swap_state.c | 1 -
5 files changed, 5
All users are now converted to use the folio_batch so we can get rid of
this data structure.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/pagevec.h | 63 +++--
mm/swap.c | 18 ++--
2 files changed, 13 insertions(+), 68
On Thu, Jun 15, 2023 at 03:33:12PM -0400, Peter Xu wrote:
> My question is whether page_zonenum() is ready for taking all kinds of tail
> pages?
>
> Zone device tail pages all look fine, per memmap_init_zone_device(). The
> question was other kinds of usual compound pages, like either thp or
> hu
On Mon, Feb 27, 2023 at 06:39:33PM +0100, Danilo Krummrich wrote:
> On 2/21/23 19:31, Matthew Wilcox wrote:
> > Lockdep will shout at you if you get it wrong ;-) But you can safely
> > take the spinlock before calling mas_store_gfp(GFP_KERNEL) because
> > mas_nomem() knows to
On Wed, Feb 22, 2023 at 05:11:34PM +0100, Danilo Krummrich wrote:
> On 2/21/23 19:31, Matthew Wilcox wrote:
> > on tue, feb 21, 2023 at 03:37:49pm +0100, danilo krummrich wrote:
> > > It feels a bit weird that I, as a user of the API, would need to lock
> > > c
On Tue, Feb 21, 2023 at 03:37:49PM +0100, Danilo Krummrich wrote:
> On Mon, Feb 20, 2023 at 08:33:35PM +0000, Matthew Wilcox wrote:
> > On Mon, Feb 20, 2023 at 06:06:03PM +0100, Danilo Krummrich wrote:
> > > On 2/20/23 16:10, Matthew Wilcox wrote:
> > > > This is
On Mon, Feb 20, 2023 at 06:06:03PM +0100, Danilo Krummrich wrote:
> On 2/20/23 16:10, Matthew Wilcox wrote:
> > This is why we like people to use the spinlock embedded in the tree.
> > There's nothing for the user to care about. If the access really is
> > serialise
On Mon, Feb 20, 2023 at 03:00:59PM +0100, Danilo Krummrich wrote:
> On 2/17/23 20:38, Matthew Wilcox wrote:
> > On Fri, Feb 17, 2023 at 02:44:10PM +0100, Danilo Krummrich wrote:
> > > Generic components making use of the maple tree (such as the
> > > DRM GPUVA Manager)
On Fri, Feb 17, 2023 at 02:44:09PM +0100, Danilo Krummrich wrote:
> \#define SAMPLE_ITER(name, __mgr) \
> struct sample_iter name = { \
> .mas = __MA_STATE(&(__mgr)->mt, 0, 0),
This is usually called MA_STATE_INIT()
> #define sample_iter_for_each_range(it__, start__, end__) \
On Fri, Feb 17, 2023 at 02:44:10PM +0100, Danilo Krummrich wrote:
> Generic components making use of the maple tree (such as the
> DRM GPUVA Manager) delegate the responsibility of ensuring mutual
> exclusion to their users.
>
> While such components could inherit the concept of an external lock,
On Thu, Jan 26, 2023 at 04:50:59PM +0200, Mike Rapoport wrote:
> On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> > On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > > +/* Use when VMA is not part of the VMA tree and needs no locking */
> > > +static inline voi
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> +/* Use when VMA is not part of the VMA tree and needs no locking */
> +static inline void init_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
> +{
> + vma->vm_flags = flags;
vm_fl
On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
> > > + /*
> > > + * Flags, see mm.h.
> > > + * WARNING! Do not modify directly.
> > > + * Use {init|reset|set|clear|mod}_vm_flags() functions instead.
> >
On Mon, Jan 23, 2023 at 12:50:52PM -0800, Dan Williams wrote:
> Matthew Wilcox wrote:
> > On Mon, Jan 23, 2023 at 11:36:51AM -0800, Dan Williams wrote:
> > > Jason Gunthorpe via Lsf-pc wrote:
> > > > I would like to have a session at LSF to talk about Matthew'
On Mon, Jan 23, 2023 at 11:36:51AM -0800, Dan Williams wrote:
> Jason Gunthorpe via Lsf-pc wrote:
> > I would like to have a session at LSF to talk about Matthew's
> > physr discussion starter:
> >
> > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infradead.org/
> >
> > I have become
On Sat, Jan 21, 2023 at 11:03:05AM -0400, Jason Gunthorpe wrote:
> I would like to have a session at LSF to talk about Matthew's
> physr discussion starter:
>
> https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infradead.org/
I'm definitely interested in discussing phyrs (even if you'd ra
On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote:
> Boqun wrote:
> > * Looks like the DEPT dependency graph doesn't handle the
> > fair/unfair readers as lockdep current does. Which bring the
> > next question.
>
> No. DEPT works better for unfair read. It works based on wa
changing how DRM + ACCEL do minor id handling.
>
> This sounds sane to me. However, this appears to be something that Matthew
> Wilcox should be aware of (added for visibility). Perhaps he has a very
> quick solution. If not, at-least he might have ideas on how to best address
> in t
On Sun, Nov 06, 2022 at 04:51:39PM +0200, Oded Gabbay wrote:
> I tried executing the following code in a dummy driver I wrote:
You don't need to write a dummy driver; you can write test-cases
entirely in userspace. Just add them to lib/test_xarray.c and then
make -C tools/testing/radix-tree/
> s
On Thu, Oct 20, 2022 at 03:35:16PM +0200, Kwapulinski, Maciej wrote:
> +++ b/drivers/gpu/drm/gna/Kconfig
> @@ -0,0 +1,12 @@
> +#
> +# Intel(R) Gaussian & Neural Accelerator (Intel(R) GNA)
> +#
> +
> +config DRM_GNA
> + tristate "Intel(R) Gaussian & Neural Accelerator (Intel(R) GNA)"
> + dep
ne in IRQ context.
>
> Signed-off-by: Michał Winiarski
> Suggested-by: Matthew Wilcox
I have a few questions, but I like where you're going.
> @@ -98,21 +98,18 @@ static struct drm_minor **drm_minor_get_slot(struct
> drm_device *dev,
> static void drm_minor_alloc_re
On Tue, Sep 06, 2022 at 04:01:13PM +0200, Michał Winiarski wrote:
> 64 DRM device nodes is not enough for everyone.
> Upgrade it to ~512K (which definitely is more than enough).
>
> To allow testing userspace support for >64 devices, add additional DRM
> modparam (skip_legacy_minors) which causes
On Wed, Jul 27, 2022 at 03:14:07PM -0400, Zack Rusin wrote:
> From: Zack Rusin
>
> Write page faults on last references might not have a valid page anymore.
> wp_page_reuse has always dealt with that scenario by making
> sure the page isn't null (or the reference was shared) before doing
> anythi
On Mon, Jul 11, 2022 at 03:35:42PM +0200, David Hildenbrand wrote:
> > + /*
> > +* Device coherent pages are managed by a driver and should not
> > +* be pinned indefinitely as it prevents the driver moving the
> > +* page. So when trying to pin with FO
On Thu, May 26, 2022 at 11:48:32AM +0300, Dan Carpenter wrote:
> On Thu, May 26, 2022 at 02:16:34AM +0100, Matthew Wilcox wrote:
> > Bizarre this started showing up now. The recent patch was:
> >
> > - info->alloced += compound_nr(page);
> > - inod
On Wed, May 25, 2022 at 03:20:06PM -0700, Andrew Morton wrote:
> 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
On Tue, Apr 12, 2022 at 02:08:04PM -0700, Andrew Morton wrote:
> 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.
I noticed it was an order-9 page and was set to take responsibility
for it, but it's clearly not a filesystem pag
On Wed, Mar 30, 2022 at 04:24:20PM -0500, Alex Sierra wrote:
> From: Philip Yang
>
> SVMAPISupported property added to HSA_CAPABILITY, the value match
> HSA_CAPABILITY defined in Thunk spec:
>
> SVMAPISupported: it will not be supported on older kernels that don't
> have HMM or on systems with G
On Thu, Mar 10, 2022 at 11:26:31AM -0600, Alex Sierra wrote:
> @@ -606,7 +606,7 @@ static void print_bad_pte(struct vm_area_struct *vma,
> unsigned long addr,
> * PFNMAP mappings in order to support COWable mappings.
> *
> */
> -struct page *vm_normal_page(struct vm_area_struct *vma, unsigne
1 - 100 of 292 matches
Mail list logo
