summaryrefslogtreecommitdiffstats
path: root/fs/ext4/fsync.c
diff options
context:
space:
mode:
authorTheodore Ts'o <tytso@mit.edu>2016-03-26 16:14:34 -0400
committerTheodore Ts'o <tytso@mit.edu>2016-03-26 16:14:34 -0400
commitc9af28fdd44922a6c10c9f8315718408af98e315 (patch)
treeb5bc491b5d141ba710bc6da44b00125b8d5d589c /fs/ext4/fsync.c
parent9e92f48c34eb2b9af9d12f892e2fe1fce5e8ce35 (diff)
downloadlinux-c9af28fdd44922a6c10c9f8315718408af98e315.tar.gz
linux-c9af28fdd44922a6c10c9f8315718408af98e315.tar.bz2
linux-c9af28fdd44922a6c10c9f8315718408af98e315.zip
ext4 crypto: don't let data integrity writebacks fail with ENOMEM
We don't want the writeback triggered from the journal commit (in data=writeback mode) to cause the journal to abort due to generic_writepages() returning an ENOMEM error. In addition, if fsync() fails with ENOMEM, most applications will probably not do the right thing. So if we are doing a data integrity sync, and ext4_encrypt() returns ENOMEM, we will submit any queued I/O to date, and then retry the allocation using GFP_NOFAIL. Google-Bug-Id: 27641567 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'fs/ext4/fsync.c')
0 files changed, 0 insertions, 0 deletions