Hi Tyler,
Is it more polite to invoke cond_resched() at the beginning/end of the potentially long-time loop?
Cheers,
Li Wang
---------- Origin message ----------
>From："Tyler Hicks" <tyhicks@xxxxxxxxxxxxx>
>To：ecryptfs@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx
>Subject：[PATCH 1/3] eCryptfs: Make truncate path killable
>Date：2012-01-21 06:35:05
ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a
page, zeroes out the appropriate portions, and then encrypts the page
before writing it to the lower filesystem. It was unkillable and due to
the lack of sparse file support could result in tying up a large portion
of system resources, while encrypting pages of zeros, with no way for
the truncate operation to be stopped from userspace.
This patch adds the ability for ecryptfs_write() to detect a pending
fatal signal and return as gracefully as possible. The intent is to
leave the lower file in a useable state, while still allowing a user to
break out of the encryption loop. If a pending fatal signal is detected,
the eCryptfs inode size is updated to reflect the modified inode size
and then -EINTR is returned.
Signed-off-by: Tyler Hicks <tyhicks@xxxxxxxxxxxxx>
Cc: <stable@xxxxxxxxxxxxxxx>
---
fs/ecryptfs/read_write.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
?韬{.n?壏煯壄?%娝?檩?w?{.n?壏{饼?z鳐?韰骅w* jg?秹殠娸?G珴?⒏ ⒎:+v墾妛鑚豰稛?? 畐娻＂穐殢鉂?嗁?
