lkml.org 
[lkml]   [2022]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[PATCH v3 0/2] Rework find_get_entries() and find_lock_entries()
Date
Originally the callers of find_get_entries() and find_lock_entries()
were keeping track of the start index themselves as
they traverse the search range.

This resulted in hacky code such as in shmem_undo_range():

index = folio->index + folio_nr_pages(folio) - 1;

where the - 1 is only present to stay in the right spot after
incrementing index later. This sort of calculation was also being done
on every folio despite not even using index later within that function.

These patches change find_get_entries() and find_lock_entries() to calculate
the new index instead of leaving it to the callers so we can avoid all
these complications.

---
v3:
Fixed a typo in commit messages
Shifted calculations to after the rcu_read_unlock()

v2:
Fixed an issue when handling shadow entries
Dropped patches removing the indices array; it is required for value
entries

Vishal Moola (Oracle) (2):
filemap: find_lock_entries() now updates start offset
filemap: find_get_entries() now updates start offset

mm/filemap.c | 28 +++++++++++++++++++++++-----
mm/internal.h | 4 ++--
mm/shmem.c | 19 ++++++-------------
mm/truncate.c | 30 ++++++++++--------------------
4 files changed, 41 insertions(+), 40 deletions(-)

--
2.36.1

\
 
 \ /
  Last update: 2022-10-17 18:18    [W:0.063 / U:0.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site