You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
net/rds: make copy_page_from_iter and copy_page_to_iter stay within page boundaries (WORKAROUND!)
The original UEK-4.1 code allocated multiple pages via rds_page_remainder_alloc
up to RDS_MAX_FRAG_SIZE (16kiB), as introduced in commit 23f90cc.
Before commit 23f90cc, as well as the upstream-Linux version allocates
single pages only.
Since these multiple pages are allocated in a physically contiguous area (alloc_pages),
neither the review nor tests revealed the fact that copy_page_from_iter does not
support crossing page-boundaries:
The code wasn't tested on platforms where HIGHMEM pages would have to be
mapped into the kernel (kmap) explicitly, such as i386 (32bit) anymore.
On those platforms it most likely would have just crashed!
Only when commit 72e809e came along, that
introduced an explicit check for not crossing page boundaries in iov_iter.c
came along, did this problem become obvious.
There's also the issue with this approach of allocating physically contiguous 16KiB areas:
it does not back down and try to allocate smaller orders (down to 0), in case allocation failed.
Also, copy_page_from_iter may not be the only function mapping HIGHMEM pages,
hence unable to cross page boundaries (as kmap maps a single page).
So the idea came up to simply revert commit 23f90cc, since it was also just introduced
on behalf of the PSIF project, which is now defunct.
Unfortunately and unexpectedly the old code (of allocating single pages) no longer works!
That leads to the obvious conclusion:
Some code change that happened after commit 23f90cc in UEK makes either an
explicit assumption (without or with hidden note), or an implicit assumption (e.g. a one-off bug)
about the presence of this multi-page allocation.
Orabug: 27222215
Orabug: 27364391
Signed-off-by: Gerd Rausch <[email protected]>
Reviewed-by: Sudhakar Dindukurti <[email protected]>
Signed-off-by: Somasundaram Krishnasamy <[email protected]>
0 commit comments