summaryrefslogtreecommitdiff
path: root/crypto/async_tx/async_xor.c
diff options
context:
space:
mode:
authorHugh Dickins <hugh@veritas.com>2008-02-04 22:28:51 -0800
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2008-02-05 09:44:15 -0800
commita0ee5ec520ede1dc8e2194623bcebfd9fab408f2 (patch)
tree74a3668798213661a9e62a1b576f081f1ce44838 /crypto/async_tx/async_xor.c
parentd9fe526a83b84edc9c5ff217a00c896bfc20b2ce (diff)
tmpfs: allocate on read when stacked
tmpfs is expected to limit the memory used (unless mounted with nr_blocks=0 or size=0). But if a stacked filesystem such as unionfs gets pages from a sparse tmpfs file by reading holes, and then writes to them, it can easily exceed any such limit at present. So suppress the SGP_READ "don't allocate page" ZERO_PAGE optimization when reading for the kernel (a KERNEL_DS check, ugh, sorry about that). Indeed, pessimistically mark such pages as dirty, so they cannot get reclaimed and unaccounted by mistake. The venerable shmem_recalc_inode code (originally to account for the reclaim of clean pages) suffices to get the accounting right when swappages are dropped in favour of more uptodate filepages. This also fixes the NULL shmem_swp_entry BUG or oops in shmem_writepage, caused by unionfs writing to a very sparse tmpfs file: to minimize memory allocation in swapout, tmpfs requires the swap vector be allocated upfront, which wasn't always happening in this stacked case. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'crypto/async_tx/async_xor.c')
0 files changed, 0 insertions, 0 deletions