[PATCH v2 0/2] Rework find_get_entries() and find_lock_entries()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

---
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  | 32 +++++++++++++++++++++++++-------
 mm/internal.h |  4 ++--
 mm/shmem.c    | 19 ++++++-------------
 mm/truncate.c | 30 ++++++++++--------------------
 4 files changed, 43 insertions(+), 42 deletions(-)

-- 
2.36.1





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux