From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0887250E5A7; Thu, 17 Sep 2026 17:11:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789665113; cv=none; b=A7xYZd82c9slNh7J7pSzDBMw5ADdDlwN19yekfmchypCHqAMC0gm/x/A6KWe2ATo6yNrwj4CkvprxYgeRmHRPsyqFck02elpqFWdaQ64i0anrDQfVoSbb8eQBvNzFYIp4gmHYEhJStzIXo7NIaHzBoRJfOUCGMdMnp2/LHKZCgU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789665113; c=relaxed/simple; bh=y3L3XuU3Qk055EFc2tuetZ+9cSuMdZIKem4AGABz4Wo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qorhvO61wr4mf/smASBNCD9Ug7/AvfaMBvEEwtM8cLM0mWJPNViNMujMfFcXADriBIUe9GTe/5orsDQI4Zw9jzmwNnbTmKZBXvGzkrmtxakGaexg0MAOo2Dv9Y+4iUH3fYsQPXxtqTuolmw2XYT+SPgzqKW5XloL3lcPz3ZQCh0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=EtZdO76I; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="EtZdO76I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE5951F000FF; Thu, 17 Sep 2026 17:11:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1789665111; bh=olyuG0jenuC/i/rkufbDRLbWOfdMDbVTJ35wO42/TaM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=EtZdO76I1mqmMsR5HpERBBrD5kV021vA46KvHDbwVjBAnfvwOx5auyf8bKIGhVD1p kYPxGyPKbPazVGfQB6wxL3fTjbuAs37quiomUO1ZSCmDtmLSeqeV/jFdNkvsqH1+gr P/bM8110EjoCwG7wjvfl9mdzuM+ogkkksTV0vOok= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Jia Jia , "Michael S. Tsirkin" , Sasha Levin Subject: [PATCH 6.18 0559/1250] vhost-scsi: flush backend after device ioctls Date: Thu, 17 Sep 2026 16:05:54 +0100 Message-ID: <20260917151607.082567058@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260917151551.901433442@linuxfoundation.org> References: <20260917151551.901433442@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jia Jia [ Upstream commit 22598f55a4c2b510b3df5e69e563387a963222ae ] vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns. Signed-off-by: Jia Jia Signed-off-by: Michael S. Tsirkin Message-ID: <20260724060919.1569170-1-physicalmtea@gmail.com> Signed-off-by: Sasha Levin --- drivers/vhost/scsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c index 29716ce714554..deb4c8bfd3d57 100644 --- a/drivers/vhost/scsi.c +++ b/drivers/vhost/scsi.c @@ -2448,9 +2448,10 @@ vhost_scsi_ioctl(struct file *f, default: mutex_lock(&vs->dev.mutex); r = vhost_dev_ioctl(&vs->dev, ioctl, argp); - /* TODO: flush backend after dev ioctl. */ if (r == -ENOIOCTLCMD) r = vhost_vring_ioctl(&vs->dev, ioctl, argp); + else + vhost_scsi_flush(vs); mutex_unlock(&vs->dev.mutex); return r; } -- 2.53.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CFE283CC7F8; Thu, 17 Sep 2026 19:02:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789671740; cv=none; b=d48qsSKkdoLKsg55XVRxlYIzYD/1JZ0NzQY5Bj/EBnunHnaOXHRZkMtxTp5v1ylqkCFP8dX+tHcbFLoJ7KjPSBLHaWqKF5F4tqyDZMbjgSvHfdeiQjd7F7l2D0V6J5oBcxocKjW+Em8dQfr5rDYs21+TVUkcbTYqK7S8DQi1Rjg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789671740; c=relaxed/simple; bh=c6wwXlNoPoGVgTHJangoi38XRSmB07wE2Cz4ao/jwLc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=E4ngit6nsEZAjUTBXOeTLAvC6jyYudCT+WY1dlJAnpN2IM0sVBvyk171QWx/BUjRXvIPm4d+YCObnojRmfrn1Em31qhJrjlvEJvb8M5dkey3wooX0ox7etV1NFE+PKO9vCF7Ue4/EMdirtCJLeRi0AfV36ltKTEjovINH+3BToU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Y+BAy3RF; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Y+BAy3RF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3308B1F000FF; Thu, 17 Sep 2026 19:02:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1789671738; bh=pHzg22qT6pkTkiiCE2sJ6IIrIAkdU/jqn/6yXaIBQYw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Y+BAy3RFVHIYRlyNOu9PnU+qHv6nf1+HzRq36CJ6tKP5K6ifcsOwCm10LS4r97WP0 1g1B0+PRkcixoGpv5EDVLYu0tFLeTveOMi/um6iiG1jZOTxMGMoODK0Cbg2EPbd/ia 2imFj4H+0q3AKIbM3fy+pqC0qEysKB3ZN6bJHpfg= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Filipe Manana , Qu Wenruo , David Sterba , Sasha Levin Subject: [PATCH 6.12 1047/1102] btrfs: prepare btrfs_punch_hole_lock_range() for large data folios Date: Thu, 17 Sep 2026 16:16:30 +0100 Message-ID: <20260917151607.082567058@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260917151539.408551884@linuxfoundation.org> References: <20260917151539.408551884@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <20260917151630.sFcsUYJnubdFvysniojdr9ezKToknOE1pcUp__ALZcc@z> 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Qu Wenruo [ Upstream commit 1e5773e0bab761c853eaf7286394905a544ef02d ] The function btrfs_punch_hole_lock_range() needs to make sure there is no other folio in the range, thus it goes with filemap_range_has_page(), which works pretty fine. But if we have large folios, under the following case filemap_range_has_page() will always return true, forcing btrfs_punch_hole_lock_range() to do a very time consuming busy loop: start end | | |//|//|//|//| | | | | | | | |//|//| \ / \ / Folio A Folio B In the above case, folio A and B contain our start/end indexes, and there are no other folios in the range. Thus we do not need to retry inside btrfs_punch_hole_lock_range(). To prepare for large data folios, introduce a helper, check_range_has_page(), which will: - Shrink the search range towards page boundaries If the rounded down end (exclusive, otherwise it can underflow when @end is inside the folio at file offset 0) is no larger than the rounded up start, it means the range contains no other pages other than the ones covering @start and @end. Can return false directly in that case. - Grab all the folios inside the range - Skip any large folios that cover the start and end indexes - If any other folios are found return true - Otherwise return false This new helper is going to handle both large folios and regular ones. Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Stable-dep-of: 3f950867c307 ("btrfs: fix extent map leak in NOCOW direct I/O write") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/file.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 56 insertions(+), 11 deletions(-) --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -2204,11 +2204,29 @@ static int find_first_non_hole(struct bt return ret; } -static void btrfs_punch_hole_lock_range(struct inode *inode, - const u64 lockstart, - const u64 lockend, - struct extent_state **cached_state) +/* + * Check if there is no folio in the range. + * + * We cannot utilize filemap_range_has_page() in a filemap with large folios + * as we can hit the following false positive: + * + * start end + * | | + * |//|//|//|//| | | | | | | | |//|//| + * \ / \ / + * Folio A Folio B + * + * That large folio A and B cover the start and end indexes. + * In that case filemap_range_has_page() will always return true, but the above + * case is fine for btrfs_punch_hole_lock_range() usage. + * + * So here we only ensure that no other folios is in the range, excluding the + * head/tail large folio. + */ +static bool check_range_has_page(struct inode *inode, u64 start, u64 end) { + struct folio_batch fbatch; + bool ret = false; /* * For subpage case, if the range is not at page boundary, we could * have pages at the leading/tailing part of the range. @@ -2219,17 +2237,45 @@ static void btrfs_punch_hole_lock_range( * * And do not decrease page_lockend right now, as it can be 0. */ - const u64 page_lockstart = round_up(lockstart, PAGE_SIZE); - const u64 page_lockend = round_down(lockend + 1, PAGE_SIZE); + const u64 page_lockstart = round_up(start, PAGE_SIZE); + const u64 page_lockend = round_down(end + 1, PAGE_SIZE); + const pgoff_t start_index = page_lockstart >> PAGE_SHIFT; + const pgoff_t end_index = (page_lockend - 1) >> PAGE_SHIFT; + pgoff_t tmp = start_index; + int found_folios; + + /* The same page or adjacent pages. */ + if (page_lockend <= page_lockstart) + return false; + folio_batch_init(&fbatch); + found_folios = filemap_get_folios(inode->i_mapping, &tmp, end_index, &fbatch); + for (int i = 0; i < found_folios; i++) { + struct folio *folio = fbatch.folios[i]; + + /* A large folio begins before the start. Not a target. */ + if (folio->index < start_index) + continue; + /* A large folio extends beyond the end. Not a target. */ + if (folio->index + folio_nr_pages(folio) > end_index) + continue; + /* A folio doesn't cover the head/tail index. Found a target. */ + ret = true; + break; + } + folio_batch_release(&fbatch); + return ret; +} + +static void btrfs_punch_hole_lock_range(struct inode *inode, + const u64 lockstart, const u64 lockend, + struct extent_state **cached_state) +{ while (1) { truncate_pagecache_range(inode, lockstart, lockend); lock_extent(&BTRFS_I(inode)->io_tree, lockstart, lockend, cached_state); - /* The same page or adjacent pages. */ - if (page_lockend <= page_lockstart) - break; /* * We can't have ordered extents in the range, nor dirty/writeback * pages, because we have locked the inode's VFS lock in exclusive @@ -2240,8 +2286,7 @@ static void btrfs_punch_hole_lock_range( * locking the range check if we have pages in the range, and if * we do, unlock the range and retry. */ - if (!filemap_range_has_page(inode->i_mapping, page_lockstart, - page_lockend - 1)) + if (!check_range_has_page(inode, lockstart, lockend)) break; unlock_extent(&BTRFS_I(inode)->io_tree, lockstart, lockend,