From: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
To: linux-scsi@vger.kernel.org, target-devel@vger.kernel.org
Cc: linux-block@vger.kernel.org, bostroesser@gmail.com
Subject: [PATCH v2 2/3] scsi: target: tcmu: Fix possible data corruption
Date: Wed, 23 Mar 2022 21:49:39 +0800 [thread overview]
Message-ID: <20220323134940.31463-3-xiaoguang.wang@linux.alibaba.com> (raw)
In-Reply-To: <20220323134940.31463-1-xiaoguang.wang@linux.alibaba.com>
When tcmu_vma_fault() gets one page successfully, before the current
context completes page fault procedure, find_free_blocks() may run in
and call unmap_mapping_range() to unmap this page. Assume when
find_free_blocks() completes its job firstly, previous page fault
procedure starts to run again and completes, then one truncated page has
beed mapped to use space, but note that tcmu_vma_fault() has gotten one
refcount for this page, so any other subsystem won't use this page,
unless later the use space addr is unmapped.
If another command runs in later and needs to extends dbi_thresh, it may
reuse the corresponding slot to previous page in data_bitmap, then thouth
we'll allocate new page for this slot in data_area, but no page fault will
happen again, because we have a valid map, real request's data will lose.
To fix this issue, when extending dbi_thresh, we'll need to call
unmap_mapping_range() to unmap use space data area which may exist,
which I think it's a simple method.
Filesystem implementations will also run into this issue, but they
ususally lock page when vm_operations_struct->fault gets one page, and
unlock page after finish_fault() completes. In truncate sides, they
lock pages in truncate_inode_pages() to protect race with page fault.
We can also have similar codes like filesystem to fix this issue.
Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
---
drivers/target/target_core_user.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/target/target_core_user.c b/drivers/target/target_core_user.c
index 06a5c4086551..9196188504ec 100644
--- a/drivers/target/target_core_user.c
+++ b/drivers/target/target_core_user.c
@@ -862,6 +862,7 @@ static int tcmu_alloc_data_space(struct tcmu_dev *udev, struct tcmu_cmd *cmd,
if (space < cmd->dbi_cnt) {
unsigned long blocks_left =
(udev->max_blocks - udev->dbi_thresh) + space;
+ loff_t off, len;
if (blocks_left < cmd->dbi_cnt) {
pr_debug("no data space: only %lu available, but ask for %u\n",
@@ -870,6 +871,10 @@ static int tcmu_alloc_data_space(struct tcmu_dev *udev, struct tcmu_cmd *cmd,
return -1;
}
+ off = udev->data_off + (loff_t)udev->dbi_thresh * udev->data_blk_size;
+ len = cmd->dbi_cnt * udev->data_blk_size;
+ unmap_mapping_range(udev->inode->i_mapping, off, len, 1);
+
udev->dbi_thresh += cmd->dbi_cnt;
if (udev->dbi_thresh > udev->max_blocks)
udev->dbi_thresh = udev->max_blocks;
--
2.14.4.44.g2045bb6
next prev parent reply other threads:[~2022-03-23 13:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-23 13:49 [PATCH v2 0/3] three bug fixes about tcmu page fault handle Xiaoguang Wang
2022-03-23 13:49 ` [PATCH v2 1/3] scsi: target: tcmu: Fix possible page UAF Xiaoguang Wang
2022-03-23 13:49 ` Xiaoguang Wang [this message]
2022-04-01 19:45 ` [PATCH v2 2/3] scsi: target: tcmu: Fix possible data corruption Bodo Stroesser
2022-04-04 16:13 ` Xiaoguang Wang
2022-04-05 16:03 ` Xiaoguang Wang
2022-04-08 10:33 ` Bodo Stroesser
2022-04-11 4:49 ` Xiaoguang Wang
2022-03-23 13:49 ` [PATCH v2 3/3] scsi: target: tcmu: Use address_space->invalidate_lock Xiaoguang Wang
2022-04-01 19:58 ` Bodo Stroesser
2022-04-04 15:09 ` Xiaoguang Wang
2022-04-08 11:34 ` Bodo Stroesser
2022-04-11 6:16 ` Xiaoguang Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220323134940.31463-3-xiaoguang.wang@linux.alibaba.com \
--to=xiaoguang.wang@linux.alibaba.com \
--cc=bostroesser@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).