public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 0/2] block: Generalize physical entry definition
@ 2025-12-17  9:41 Leon Romanovsky
  2025-12-17  9:41 ` [PATCH v3 1/2] nvme-pci: Use size_t for length fields to handle larger sizes Leon Romanovsky
                   ` (3 more replies)
  0 siblings, 4 replies; 14+ messages in thread
From: Leon Romanovsky @ 2025-12-17  9:41 UTC (permalink / raw)
  To: Jens Axboe, Keith Busch, Christoph Hellwig, Sagi Grimberg
  Cc: linux-block, linux-kernel, linux-nvme, Chaitanya Kulkarni

Jens,

I would like to ask you to put these patches on some shared branch based
on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
and DMABUF code.

--------------------------------------------------------------------------------
Changelog:
v3:
 * Rebased on top v6.19-rc1
 * Added note that memory size is not changed despite change in the
   variable type.
v2: https://lore.kernel.org/linux-nvme/20251117-nvme-phys-types-v2-0-c75a60a2c468@nvidia.com/
 * Added Chaitanya's Reviewed-by tags.
 * Removed explicit casting from size_t to unsigned int.
v1: https://patch.msgid.link/20251115-nvme-phys-types-v1-0-c0f2e5e9163d@kernel.org

--------------------------------------------------------------------------------
The block layer code is declared "struct phys_vec" entry which describes
contiguous chunk of physical memory. That definition is useful for all
possible users of DMA physical address-based API.

This series changes NVMe code to support larger chunks of memory by changing
length field from u32 to be size_t, which will be u64 on 64-bits platforms,
and promotes "struct phys_vec" to general place.

This change doesn't change memory footprint because on 32-bits systems,
size_t will be u32 as before and on 64bits system previous uint32_t
variable was padded to be uint64_t anyway.

Thanks

---
Leon Romanovsky (2):
      nvme-pci: Use size_t for length fields to handle larger sizes
      types: move phys_vec definition to common header

 block/blk-mq-dma.c      | 11 +++++------
 drivers/nvme/host/pci.c |  4 ++--
 include/linux/types.h   |  5 +++++
 3 files changed, 12 insertions(+), 8 deletions(-)
---
base-commit: 5674abb82e2b74205a6a5cd1ffd79a3ba48a469d
change-id: 20251030-nvme-phys-types-988893249454

Best regards,
--
Leon Romanovsky <leonro@nvidia.com>

---
Leon Romanovsky (2):
      nvme-pci: Use size_t for length fields to handle larger sizes
      types: move phys_vec definition to common header

 block/blk-mq-dma.c      | 11 +++++------
 drivers/nvme/host/pci.c |  4 ++--
 include/linux/types.h   |  5 +++++
 3 files changed, 12 insertions(+), 8 deletions(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251217-nvme-phys-types-5bf34e42b2df

Best regards,
--  
Leon Romanovsky <leonro@nvidia.com>


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v3 1/2] nvme-pci: Use size_t for length fields to handle larger sizes
  2025-12-17  9:41 [PATCH v3 0/2] block: Generalize physical entry definition Leon Romanovsky
@ 2025-12-17  9:41 ` Leon Romanovsky
  2025-12-17  9:41 ` [PATCH v3 2/2] types: move phys_vec definition to common header Leon Romanovsky
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 14+ messages in thread
From: Leon Romanovsky @ 2025-12-17  9:41 UTC (permalink / raw)
  To: Jens Axboe, Keith Busch, Christoph Hellwig, Sagi Grimberg
  Cc: linux-block, linux-kernel, linux-nvme, Chaitanya Kulkarni

From: Leon Romanovsky <leonro@nvidia.com>

This patch changes the length variables from unsigned int to size_t.
Using size_t ensures that we can handle larger sizes, as size_t is
always equal to or larger than the previously used u32 type.

Originally, u32 was used because blk-mq-dma code evolved from
scatter-gather implementation, which uses unsigned int to describe length.
This change will also allow us to reuse the existing struct phys_vec in places
that don't need scatter-gather.

Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
---
 block/blk-mq-dma.c      | 8 ++++++--
 drivers/nvme/host/pci.c | 4 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c
index fb018fffffdc..a2bedc8f8666 100644
--- a/block/blk-mq-dma.c
+++ b/block/blk-mq-dma.c
@@ -8,7 +8,7 @@
 
 struct phys_vec {
 	phys_addr_t	paddr;
-	u32		len;
+	size_t		len;
 };
 
 static bool __blk_map_iter_next(struct blk_map_iter *iter)
@@ -112,8 +112,8 @@ static bool blk_rq_dma_map_iova(struct request *req, struct device *dma_dev,
 		struct phys_vec *vec)
 {
 	enum dma_data_direction dir = rq_dma_dir(req);
-	unsigned int mapped = 0;
 	unsigned int attrs = 0;
+	size_t mapped = 0;
 	int error;
 
 	iter->addr = state->addr;
@@ -297,6 +297,8 @@ int __blk_rq_map_sg(struct request *rq, struct scatterlist *sglist,
 	blk_rq_map_iter_init(rq, &iter);
 	while (blk_map_iter_next(rq, &iter, &vec)) {
 		*last_sg = blk_next_sg(last_sg, sglist);
+
+		WARN_ON_ONCE(overflows_type(vec.len, unsigned int));
 		sg_set_page(*last_sg, phys_to_page(vec.paddr), vec.len,
 				offset_in_page(vec.paddr));
 		nsegs++;
@@ -417,6 +419,8 @@ int blk_rq_map_integrity_sg(struct request *rq, struct scatterlist *sglist)
 
 	while (blk_map_iter_next(rq, &iter, &vec)) {
 		sg = blk_next_sg(&sg, sglist);
+
+		WARN_ON_ONCE(overflows_type(vec.len, unsigned int));
 		sg_set_page(sg, phys_to_page(vec.paddr), vec.len,
 				offset_in_page(vec.paddr));
 		segments++;
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 0e4caeab739c..3b528369f545 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -290,14 +290,14 @@ struct nvme_iod {
 	u8 flags;
 	u8 nr_descriptors;
 
-	unsigned int total_len;
+	size_t total_len;
 	struct dma_iova_state dma_state;
 	void *descriptors[NVME_MAX_NR_DESCRIPTORS];
 	struct nvme_dma_vec *dma_vecs;
 	unsigned int nr_dma_vecs;
 
 	dma_addr_t meta_dma;
-	unsigned int meta_total_len;
+	size_t meta_total_len;
 	struct dma_iova_state meta_dma_state;
 	struct nvme_sgl_desc *meta_descriptor;
 };

-- 
2.51.1


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH v3 2/2] types: move phys_vec definition to common header
  2025-12-17  9:41 [PATCH v3 0/2] block: Generalize physical entry definition Leon Romanovsky
  2025-12-17  9:41 ` [PATCH v3 1/2] nvme-pci: Use size_t for length fields to handle larger sizes Leon Romanovsky
@ 2025-12-17  9:41 ` Leon Romanovsky
  2026-01-04 15:15 ` [PATCH v3 0/2] block: Generalize physical entry definition Leon Romanovsky
  2026-01-07  2:10 ` Jens Axboe
  3 siblings, 0 replies; 14+ messages in thread
From: Leon Romanovsky @ 2025-12-17  9:41 UTC (permalink / raw)
  To: Jens Axboe, Keith Busch, Christoph Hellwig, Sagi Grimberg
  Cc: linux-block, linux-kernel, linux-nvme, Chaitanya Kulkarni

From: Leon Romanovsky <leonro@nvidia.com>

Move the struct phys_vec definition from block/blk-mq-dma.c to
include/linux/types.h to make it available for use across the kernel.

The phys_vec structure represents a physical address range with a
length, which is used by the new physical address-based DMA mapping
API. This structure is already used by the block layer and will be
needed for DMA phys API users.

Moving this definition to types.h provides a centralized location
for this common data structure and eliminates code duplication
across subsystems that need to work with physical address ranges.

Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
---
 block/blk-mq-dma.c    | 5 -----
 include/linux/types.h | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c
index a2bedc8f8666..752060d7261c 100644
--- a/block/blk-mq-dma.c
+++ b/block/blk-mq-dma.c
@@ -6,11 +6,6 @@
 #include <linux/blk-mq-dma.h>
 #include "blk.h"
 
-struct phys_vec {
-	phys_addr_t	paddr;
-	size_t		len;
-};
-
 static bool __blk_map_iter_next(struct blk_map_iter *iter)
 {
 	if (iter->iter.bi_size)
diff --git a/include/linux/types.h b/include/linux/types.h
index d4437e9c452c..d673747eda8a 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -171,6 +171,11 @@ typedef u64 phys_addr_t;
 typedef u32 phys_addr_t;
 #endif
 
+struct phys_vec {
+	phys_addr_t	paddr;
+	size_t		len;
+};
+
 typedef phys_addr_t resource_size_t;
 
 /*

-- 
2.51.1


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH v3 0/2] block: Generalize physical entry definition
  2025-12-17  9:41 [PATCH v3 0/2] block: Generalize physical entry definition Leon Romanovsky
  2025-12-17  9:41 ` [PATCH v3 1/2] nvme-pci: Use size_t for length fields to handle larger sizes Leon Romanovsky
  2025-12-17  9:41 ` [PATCH v3 2/2] types: move phys_vec definition to common header Leon Romanovsky
@ 2026-01-04 15:15 ` Leon Romanovsky
  2026-01-06 12:46   ` Jens Axboe
  2026-01-07  2:10 ` Jens Axboe
  3 siblings, 1 reply; 14+ messages in thread
From: Leon Romanovsky @ 2026-01-04 15:15 UTC (permalink / raw)
  To: Jens Axboe, Keith Busch, Christoph Hellwig, Sagi Grimberg
  Cc: linux-block, linux-kernel, linux-nvme, Chaitanya Kulkarni

On Wed, Dec 17, 2025 at 11:41:22AM +0200, Leon Romanovsky wrote:
> Jens,
> 
> I would like to ask you to put these patches on some shared branch based
> on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
> and DMABUF code.

Jens,

Can we please progress with this simple series?

Thanks

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3 0/2] block: Generalize physical entry definition
  2026-01-04 15:15 ` [PATCH v3 0/2] block: Generalize physical entry definition Leon Romanovsky
@ 2026-01-06 12:46   ` Jens Axboe
  2026-01-07  2:13     ` Jens Axboe
                       ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Jens Axboe @ 2026-01-06 12:46 UTC (permalink / raw)
  To: Leon Romanovsky, Keith Busch, Christoph Hellwig, Sagi Grimberg
  Cc: linux-block, linux-kernel, linux-nvme, Chaitanya Kulkarni

On 1/4/26 8:15 AM, Leon Romanovsky wrote:
> On Wed, Dec 17, 2025 at 11:41:22AM +0200, Leon Romanovsky wrote:
>> Jens,
>>
>> I would like to ask you to put these patches on some shared branch based
>> on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
>> and DMABUF code.
> 
> Jens,
> 
> Can we please progress with this simple series?

If Keith/Christoph are happy with it?

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3 0/2] block: Generalize physical entry definition
  2025-12-17  9:41 [PATCH v3 0/2] block: Generalize physical entry definition Leon Romanovsky
                   ` (2 preceding siblings ...)
  2026-01-04 15:15 ` [PATCH v3 0/2] block: Generalize physical entry definition Leon Romanovsky
@ 2026-01-07  2:10 ` Jens Axboe
  2026-01-14 20:32   ` Alex Williamson
  3 siblings, 1 reply; 14+ messages in thread
From: Jens Axboe @ 2026-01-07  2:10 UTC (permalink / raw)
  To: Keith Busch, Christoph Hellwig, Sagi Grimberg, Leon Romanovsky
  Cc: linux-block, linux-kernel, linux-nvme, Chaitanya Kulkarni


On Wed, 17 Dec 2025 11:41:22 +0200, Leon Romanovsky wrote:
> Jens,
> 
> I would like to ask you to put these patches on some shared branch based
> on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
> and DMABUF code.
> 
> --------------------------------------------------------------------------------
> Changelog:
> v3:
>  * Rebased on top v6.19-rc1
>  * Added note that memory size is not changed despite change in the
>    variable type.
> v2: https://lore.kernel.org/linux-nvme/20251117-nvme-phys-types-v2-0-c75a60a2c468@nvidia.com/
>  * Added Chaitanya's Reviewed-by tags.
>  * Removed explicit casting from size_t to unsigned int.
> v1: https://patch.msgid.link/20251115-nvme-phys-types-v1-0-c0f2e5e9163d@kernel.org
> 
> [...]

Applied, thanks!

[1/2] nvme-pci: Use size_t for length fields to handle larger sizes
      commit: 073b9bf9af463d32555c5ebaf7e28c3a44c715d0
[2/2] types: move phys_vec definition to common header
      commit: fcf463b92a08686d1aeb1e66674a72eb7a8bfb9b

Best regards,
-- 
Jens Axboe




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3 0/2] block: Generalize physical entry definition
  2026-01-06 12:46   ` Jens Axboe
@ 2026-01-07  2:13     ` Jens Axboe
  2026-01-07  7:54       ` Leon Romanovsky
  2026-01-07  8:29     ` Keith Busch
  2026-01-07 15:36     ` Christoph Hellwig
  2 siblings, 1 reply; 14+ messages in thread
From: Jens Axboe @ 2026-01-07  2:13 UTC (permalink / raw)
  To: Leon Romanovsky, Keith Busch, Christoph Hellwig, Sagi Grimberg
  Cc: linux-block, linux-kernel, linux-nvme, Chaitanya Kulkarni

On 1/6/26 5:46 AM, Jens Axboe wrote:
> On 1/4/26 8:15 AM, Leon Romanovsky wrote:
>> On Wed, Dec 17, 2025 at 11:41:22AM +0200, Leon Romanovsky wrote:
>>> Jens,
>>>
>>> I would like to ask you to put these patches on some shared branch based
>>> on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
>>> and DMABUF code.
>>
>> Jens,
>>
>> Can we please progress with this simple series?
> 
> If Keith/Christoph are happy with it?

It's here:

for-7.0/blk-pvec

now.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3 0/2] block: Generalize physical entry definition
  2026-01-07  2:13     ` Jens Axboe
@ 2026-01-07  7:54       ` Leon Romanovsky
  0 siblings, 0 replies; 14+ messages in thread
From: Leon Romanovsky @ 2026-01-07  7:54 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Keith Busch, Christoph Hellwig, Sagi Grimberg, linux-block,
	linux-kernel, linux-nvme, Chaitanya Kulkarni

On Tue, Jan 06, 2026 at 07:13:41PM -0700, Jens Axboe wrote:
> On 1/6/26 5:46 AM, Jens Axboe wrote:
> > On 1/4/26 8:15 AM, Leon Romanovsky wrote:
> >> On Wed, Dec 17, 2025 at 11:41:22AM +0200, Leon Romanovsky wrote:
> >>> Jens,
> >>>
> >>> I would like to ask you to put these patches on some shared branch based
> >>> on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
> >>> and DMABUF code.
> >>
> >> Jens,
> >>
> >> Can we please progress with this simple series?
> > 
> > If Keith/Christoph are happy with it?
> 
> It's here:
> 
> for-7.0/blk-pvec

Thanks a lot.

> 
> now.
> 
> -- 
> Jens Axboe
> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3 0/2] block: Generalize physical entry definition
  2026-01-06 12:46   ` Jens Axboe
  2026-01-07  2:13     ` Jens Axboe
@ 2026-01-07  8:29     ` Keith Busch
  2026-01-07 15:14       ` Jens Axboe
  2026-01-07 15:36     ` Christoph Hellwig
  2 siblings, 1 reply; 14+ messages in thread
From: Keith Busch @ 2026-01-07  8:29 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Leon Romanovsky, Christoph Hellwig, Sagi Grimberg, linux-block,
	linux-kernel, linux-nvme, Chaitanya Kulkarni

On Tue, Jan 06, 2026 at 05:46:21AM -0700, Jens Axboe wrote:
> On 1/4/26 8:15 AM, Leon Romanovsky wrote:
> > On Wed, Dec 17, 2025 at 11:41:22AM +0200, Leon Romanovsky wrote:
> >> Jens,
> >>
> >> I would like to ask you to put these patches on some shared branch based
> >> on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
> >> and DMABUF code.
> > 
> > Jens,
> > 
> > Can we please progress with this simple series?
> 
> If Keith/Christoph are happy with it?

Yes, I'm happy with this. Sorry for the delay, I'm still abroad and
encountered some issues when I should have been holidaying (nothing
serious, just bad luck), so it's a slow start to the year for me so far.

Acked-by: Keith Busch <kbusch@kernel.org>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3 0/2] block: Generalize physical entry definition
  2026-01-07  8:29     ` Keith Busch
@ 2026-01-07 15:14       ` Jens Axboe
  0 siblings, 0 replies; 14+ messages in thread
From: Jens Axboe @ 2026-01-07 15:14 UTC (permalink / raw)
  To: Keith Busch
  Cc: Leon Romanovsky, Christoph Hellwig, Sagi Grimberg, linux-block,
	linux-kernel, linux-nvme, Chaitanya Kulkarni

On 1/7/26 1:29 AM, Keith Busch wrote:
> On Tue, Jan 06, 2026 at 05:46:21AM -0700, Jens Axboe wrote:
>> On 1/4/26 8:15 AM, Leon Romanovsky wrote:
>>> On Wed, Dec 17, 2025 at 11:41:22AM +0200, Leon Romanovsky wrote:
>>>> Jens,
>>>>
>>>> I would like to ask you to put these patches on some shared branch based
>>>> on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
>>>> and DMABUF code.
>>>
>>> Jens,
>>>
>>> Can we please progress with this simple series?
>>
>> If Keith/Christoph are happy with it?
> 
> Yes, I'm happy with this. Sorry for the delay, I'm still abroad and
> encountered some issues when I should have been holidaying (nothing
> serious, just bad luck), so it's a slow start to the year for me so far.
> 
> Acked-by: Keith Busch <kbusch@kernel.org>

OK good, thanks for taking a look. It's all queued up since yesterday.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3 0/2] block: Generalize physical entry definition
  2026-01-06 12:46   ` Jens Axboe
  2026-01-07  2:13     ` Jens Axboe
  2026-01-07  8:29     ` Keith Busch
@ 2026-01-07 15:36     ` Christoph Hellwig
  2 siblings, 0 replies; 14+ messages in thread
From: Christoph Hellwig @ 2026-01-07 15:36 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Leon Romanovsky, Keith Busch, Christoph Hellwig, Sagi Grimberg,
	linux-block, linux-kernel, linux-nvme, Chaitanya Kulkarni

On Tue, Jan 06, 2026 at 05:46:21AM -0700, Jens Axboe wrote:
> > Can we please progress with this simple series?
> 
> If Keith/Christoph are happy with it?

Fine with me.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3 0/2] block: Generalize physical entry definition
  2026-01-07  2:10 ` Jens Axboe
@ 2026-01-14 20:32   ` Alex Williamson
  2026-01-18  8:01     ` Leon Romanovsky
  2026-01-18 13:28     ` Jens Axboe
  0 siblings, 2 replies; 14+ messages in thread
From: Alex Williamson @ 2026-01-14 20:32 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Keith Busch, Christoph Hellwig, Sagi Grimberg, Leon Romanovsky,
	linux-block, linux-kernel, linux-nvme, Chaitanya Kulkarni

On Tue, 06 Jan 2026 19:10:46 -0700
Jens Axboe <axboe@kernel.dk> wrote:

> On Wed, 17 Dec 2025 11:41:22 +0200, Leon Romanovsky wrote:
> > Jens,
> > 
> > I would like to ask you to put these patches on some shared branch based
> > on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
> > and DMABUF code.
> > 
> > --------------------------------------------------------------------------------
> > Changelog:
> > v3:
> >  * Rebased on top v6.19-rc1
> >  * Added note that memory size is not changed despite change in the
> >    variable type.
> > v2: https://lore.kernel.org/linux-nvme/20251117-nvme-phys-types-v2-0-c75a60a2c468@nvidia.com/
> >  * Added Chaitanya's Reviewed-by tags.
> >  * Removed explicit casting from size_t to unsigned int.
> > v1: https://patch.msgid.link/20251115-nvme-phys-types-v1-0-c0f2e5e9163d@kernel.org
> > 
> > [...]  
> 
> Applied, thanks!
> 
> [1/2] nvme-pci: Use size_t for length fields to handle larger sizes
>       commit: 073b9bf9af463d32555c5ebaf7e28c3a44c715d0
> [2/2] types: move phys_vec definition to common header
>       commit: fcf463b92a08686d1aeb1e66674a72eb7a8bfb9b

Hi Jens,

I see this is currently on your for-7.0/blk-pvec branch, thanks for
splitting it out.  I haven't seen this merged into your for-next branch
though, which gives me some pause merging it for a dependent series
from Leon.  Is there anything blocking that merge?  Thanks,

Alex

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3 0/2] block: Generalize physical entry definition
  2026-01-14 20:32   ` Alex Williamson
@ 2026-01-18  8:01     ` Leon Romanovsky
  2026-01-18 13:28     ` Jens Axboe
  1 sibling, 0 replies; 14+ messages in thread
From: Leon Romanovsky @ 2026-01-18  8:01 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Alex Williamson, Keith Busch, Christoph Hellwig, Sagi Grimberg,
	linux-block, linux-kernel, linux-nvme, Chaitanya Kulkarni

On Wed, Jan 14, 2026 at 01:32:41PM -0700, Alex Williamson wrote:
> On Tue, 06 Jan 2026 19:10:46 -0700
> Jens Axboe <axboe@kernel.dk> wrote:
> 
> > On Wed, 17 Dec 2025 11:41:22 +0200, Leon Romanovsky wrote:
> > > Jens,
> > > 
> > > I would like to ask you to put these patches on some shared branch based
> > > on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
> > > and DMABUF code.
> > > 
> > > --------------------------------------------------------------------------------
> > > Changelog:
> > > v3:
> > >  * Rebased on top v6.19-rc1
> > >  * Added note that memory size is not changed despite change in the
> > >    variable type.
> > > v2: https://lore.kernel.org/linux-nvme/20251117-nvme-phys-types-v2-0-c75a60a2c468@nvidia.com/
> > >  * Added Chaitanya's Reviewed-by tags.
> > >  * Removed explicit casting from size_t to unsigned int.
> > > v1: https://patch.msgid.link/20251115-nvme-phys-types-v1-0-c0f2e5e9163d@kernel.org
> > > 
> > > [...]  
> > 
> > Applied, thanks!
> > 
> > [1/2] nvme-pci: Use size_t for length fields to handle larger sizes
> >       commit: 073b9bf9af463d32555c5ebaf7e28c3a44c715d0
> > [2/2] types: move phys_vec definition to common header
> >       commit: fcf463b92a08686d1aeb1e66674a72eb7a8bfb9b
> 
> Hi Jens,
> 
> I see this is currently on your for-7.0/blk-pvec branch, thanks for
> splitting it out.  I haven't seen this merged into your for-next branch
> though, which gives me some pause merging it for a dependent series
> from Leon.  Is there anything blocking that merge?  Thanks,

Jens,

Could you please merge the for-7.0/blk-pvec branch into your block/for-next
tree? The VFIO changes depend on the blk-pvec branch, and the RDMA changes
are based on the VFIO updates.

Thanks

> 
> Alex

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3 0/2] block: Generalize physical entry definition
  2026-01-14 20:32   ` Alex Williamson
  2026-01-18  8:01     ` Leon Romanovsky
@ 2026-01-18 13:28     ` Jens Axboe
  1 sibling, 0 replies; 14+ messages in thread
From: Jens Axboe @ 2026-01-18 13:28 UTC (permalink / raw)
  To: Alex Williamson
  Cc: Keith Busch, Christoph Hellwig, Sagi Grimberg, Leon Romanovsky,
	linux-block, linux-kernel, linux-nvme, Chaitanya Kulkarni

On 1/14/26 1:32 PM, Alex Williamson wrote:
> On Tue, 06 Jan 2026 19:10:46 -0700
> Jens Axboe <axboe@kernel.dk> wrote:
> 
>> On Wed, 17 Dec 2025 11:41:22 +0200, Leon Romanovsky wrote:
>>> Jens,
>>>
>>> I would like to ask you to put these patches on some shared branch based
>>> on v6.19-rcX tag, so I will be able to reuse this general type in VFIO
>>> and DMABUF code.
>>>
>>> --------------------------------------------------------------------------------
>>> Changelog:
>>> v3:
>>>  * Rebased on top v6.19-rc1
>>>  * Added note that memory size is not changed despite change in the
>>>    variable type.
>>> v2: https://lore.kernel.org/linux-nvme/20251117-nvme-phys-types-v2-0-c75a60a2c468@nvidia.com/
>>>  * Added Chaitanya's Reviewed-by tags.
>>>  * Removed explicit casting from size_t to unsigned int.
>>> v1: https://patch.msgid.link/20251115-nvme-phys-types-v1-0-c0f2e5e9163d@kernel.org
>>>
>>> [...]  
>>
>> Applied, thanks!
>>
>> [1/2] nvme-pci: Use size_t for length fields to handle larger sizes
>>       commit: 073b9bf9af463d32555c5ebaf7e28c3a44c715d0
>> [2/2] types: move phys_vec definition to common header
>>       commit: fcf463b92a08686d1aeb1e66674a72eb7a8bfb9b
> 
> Hi Jens,
> 
> I see this is currently on your for-7.0/blk-pvec branch, thanks for
> splitting it out.  I haven't seen this merged into your for-next branch
> though, which gives me some pause merging it for a dependent series
> from Leon.  Is there anything blocking that merge?  Thanks,

Nope, I can certainly merge it in. Did so now.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2026-01-18 13:28 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-17  9:41 [PATCH v3 0/2] block: Generalize physical entry definition Leon Romanovsky
2025-12-17  9:41 ` [PATCH v3 1/2] nvme-pci: Use size_t for length fields to handle larger sizes Leon Romanovsky
2025-12-17  9:41 ` [PATCH v3 2/2] types: move phys_vec definition to common header Leon Romanovsky
2026-01-04 15:15 ` [PATCH v3 0/2] block: Generalize physical entry definition Leon Romanovsky
2026-01-06 12:46   ` Jens Axboe
2026-01-07  2:13     ` Jens Axboe
2026-01-07  7:54       ` Leon Romanovsky
2026-01-07  8:29     ` Keith Busch
2026-01-07 15:14       ` Jens Axboe
2026-01-07 15:36     ` Christoph Hellwig
2026-01-07  2:10 ` Jens Axboe
2026-01-14 20:32   ` Alex Williamson
2026-01-18  8:01     ` Leon Romanovsky
2026-01-18 13:28     ` Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox