From: Christoph Hellwig To: axboe@kernel.dk Cc: linux-block@vger.kernel.org, kernel test robot Subject: [PATCH] loop: remove the unused inode variable in loop_configure Date: Fri, 5 Jul 2024 07:31:14 +0200 Message-ID: <20240705053114.2042976-1-hch@lst.de> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-block:93836 Newsgroups: org.kernel.vger.linux-block Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Remove the inode variable now that the last user is gone. Fixes: a17ece76bcfe ("loop: regularize upgrading the block size for direct I/O") Reported-by: kernel test robot Signed-off-by: Christoph Hellwig --- drivers/block/loop.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index bba4c920508f88..1580327dbc1e15 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1019,7 +1019,6 @@ static int loop_configure(struct loop_device *lo, blk_mode_t mode, const struct loop_config *config) { struct file *file = fget(config->fd); - struct inode *inode; struct address_space *mapping; int error; loff_t size; @@ -1056,7 +1055,6 @@ static int loop_configure(struct loop_device *lo, blk_mode_t mode, goto out_unlock; mapping = file->f_mapping; - inode = mapping->host; if ((config->info.lo_flags & ~LOOP_CONFIGURE_SETTABLE_FLAGS) != 0) { error = -EINVAL; -- 2.43.0 . From: boy.wu To: Tejun Heo , Josef Bacik , Jens Axboe CC: Matthias Brugger , AngeloGioacchino Del Regno , Boris Burkov , , , , , , , Boy Wu Subject: [PATCH] blk-cgroup: add spin_lock for u64_stats_update Date: Fri, 5 Jul 2024 15:55:44 +0800 Message-ID: <20240705075544.11315-1-boy.wu@mediatek.com> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Xref: photonic.trudheim.com org.kernel.vger.linux-block:93843 org.kernel.vger.linux-kernel:1268763 Newsgroups: org.kernel.vger.linux-block,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-mediatek,org.kernel.vger.cgroups,org.kernel.vger.linux-kernel Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail From: Boy Wu In 32bit SMP systems, if the system is stressed on the sys node by processes, it may cause blkcg_fill_root_iostats to have a concurrent problem on the seqlock in u64_stats_update, which will cause a deadlock on u64_stats_fetch_begin in blkcg_print_one_stat. To prevent this problem, add spin_locks. Fixes: ef45fe470e1e ("blk-cgroup: show global disk stats in root cgroup io.stat") Signed-off-by: Boy Wu --- block/blk-cgroup.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c index 37e6cc91d576..a633b7431e91 100644 --- a/block/blk-cgroup.c +++ b/block/blk-cgroup.c @@ -1134,9 +1134,15 @@ static void blkcg_fill_root_iostats(void) cpu_dkstats->sectors[STAT_DISCARD] << 9; } +#if BITS_PER_LONG == 32 + spin_lock_irq(&blkg->q->queue_lock); +#endif flags = u64_stats_update_begin_irqsave(&blkg->iostat.sync); blkg_iostat_set(&blkg->iostat.cur, &tmp); u64_stats_update_end_irqrestore(&blkg->iostat.sync, flags); +#if BITS_PER_LONG == 32 + spin_unlock_irq(&blkg->q->queue_lock); +#endif } } -- 2.18.0 . Return-Path: From: Christoph Hellwig To: Kanchan Joshi , Anuj Gupta , "Martin K . Petersen" Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org Subject: fine-grained PI control Date: Fri, 5 Jul 2024 10:32:04 +0200 Message-ID: <20240705083205.2111277-1-hch@lst.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: linux-nvme@lists.infradead.org X-Mailman-Version: 2.1.34 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-nvme" Errors-To: linux-nvme-bounces+linux-nvme=archiver.kernel.org@lists.infradead.org Xref: photonic.trudheim.com org.infradead.lists.linux-nvme:61694 org.kernel.vger.linux-block:93844 Newsgroups: org.infradead.lists.linux-nvme,org.kernel.vger.linux-block,org.kernel.vger.linux-scsi Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hi all, I'm trying to kick of a discussion on fine grained control of T10 PI flags. This concerns the new io_uring metadata interface including comments made by Martin in response to earlier series, and observations on how block devices with PI enabled don't work quite right right now for a few uses cases. The SCSI and NVMe PI interfaces allow fine-grained checking of the guard, reference and app tags. The io_uring interface exposes them to userspace, which is useful. The in-kernel implementation in the posted patch set only uses these flags when detecting user passthrough and currently only in the nvme driver. I think we'll need to change the in-kernel interface matches the user one, and the submitter of the PI data chooses which of the tags to generate and check. Martin also mentioned he wanted to see the BIP_CTRL_NOCHECK, BIP_DISK_NOCHECK and BIP_IP_CHECKSUM checksum flags exposed. Can you explain how you want them to fit into the API? Especially as AFAIK they can't work generically, e.g. NVMe never has an IP checksum and SCSI controllers might not offer them either. NVMe doesn't have a way to distinguish between disk and controller. Last but not least the fact that all reads and writes on PI enabled devices by default check the guard (and reference if available for the PI type) tags leads to a lot of annoying warnings when the kernel or userspace does speculative reads. Most of this is to read signatures of file systems or partitions, and that previously always succeeded, but now returns an error and warns in the block layer. I've been wondering a few things here: - is there much of a point in having block layer and driver warnings (for NVMe we'll currently get both) by default, or should we leave that to the submitter that needs to check errors anyway? - should we have an opt-out or even opt-in for guard tag verification to avoid the higher level code tripping up on returned errors where they just want to check if a signature matches? . From: Christoph Hellwig To: Jens Axboe Cc: Geert Uytterhoeven , linux-m68k@lists.linux-m68k.org, linux-block@vger.kernel.org Subject: add a bvec_phys helper Date: Fri, 5 Jul 2024 10:14:32 +0200 Message-ID: <20240705081508.2110169-1-hch@lst.de> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-block:93845 Newsgroups: org.kernel.vger.linux-block,org.kernel.vger.linux-m68k Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hi Jens, this series adds a bvec_phys helper to get the physical address of a bio_vec so that callers don't have to poke into bvec internals. There aren't a whole lot of user of it yet, but with the new proposed DMA mapping API we might grow a lot more soon. Diffstat: arch/m68k/emu/nfblock.c | 2 +- block/bio.c | 2 +- block/blk-merge.c | 22 +++++++++------------- block/blk.h | 4 ++-- include/linux/bvec.h | 15 +++++++++++++++ 5 files changed, 28 insertions(+), 17 deletions(-) . From: John Garry To: axboe@kernel.dk, mst@redhat.com, jasowang@redhat.com, xuanzhuo@linux.alibaba.com, eperezma@redhat.com, pbonzini@redhat.com, stefanha@redhat.com, hare@suse.de, kbusch@kernel.org, hch@lst.de Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux.dev, John Garry Subject: [PATCH 0/5] Validate logical block size in blk_validate_limits() Date: Fri, 5 Jul 2024 11:51:22 +0000 Message-Id: <20240705115127.3417539-1-john.g.garry@oracle.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Xref: photonic.trudheim.com org.kernel.vger.linux-block:93854 org.kernel.vger.linux-kernel:1269082 Newsgroups: org.kernel.vger.linux-block,dev.linux.lists.virtualization,org.kernel.vger.linux-kernel Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail This series adds validation of the logical block size in blk_validate_limits(). Some drivers had already been validating this themselves. As such, we can mostly drop that driver validation. nbd is problematic, as we cannot only change to just stop calling blk_validate_limits(). This is because the LBS is updated in a 2-stage process: a. update block size in the driver and validate b. update queue limits So if we stop validating the limits in a., there is a user-visible change in behaviour (as we stop rejecting invalid limits from the NBD_SET_BLKSIZE ioctl). So I left that untouched. This topic was originally mentioned in [0] and then again in [1] by Keith. I have also included a related virtio_blk change to deal with blk_size config fallback. [0] https://lore.kernel.org/linux-block/10b3e3fe-6ad5-4e0e-b822-f51656c976ee@oracle.com/ [1] https://lore.kernel.org/linux-block/Zl4dxaQgPbw19Irk@kbusch-mbp.dhcp.thefacebook.com/ John Garry (5): virtio_blk: Fix default logical block size fallback block: Validate logical block size in blk_validate_limits() null_blk: Don't bother validating blocksize virtio_blk: Don't bother validating blocksize loop: Don't bother validating blocksize block/blk-settings.c | 2 ++ drivers/block/loop.c | 12 +----------- drivers/block/null_blk/main.c | 3 --- drivers/block/virtio_blk.c | 31 +++++++++++-------------------- include/linux/blkdev.h | 1 + 5 files changed, 15 insertions(+), 34 deletions(-) -- 2.31.1 . From: Christoph Hellwig To: Jens Axboe Cc: Geert Uytterhoeven , linux-m68k@lists.linux-m68k.org, linux-block@vger.kernel.org Subject: add a bvec_phys helper v2 Date: Fri, 5 Jul 2024 14:32:18 +0200 Message-ID: <20240705123232.2165187-1-hch@lst.de> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-block:93867 Newsgroups: org.kernel.vger.linux-block,org.kernel.vger.linux-m68k Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hi Jens, this series adds a bvec_phys helper to get the physical address of a bio_vec so that callers don't have to poke into bvec internals. There aren't a whole lot of user of it yet, but with the new proposed DMA mapping API we might grow a lot more soon. Changes since v1: - reorder the two patches as suggested by Geert - fix a comment typo - use PFN_PHYS instead of open coding it - also pass a len argument to get_max_segment_size instead of open coding a min in both callers Diffstat: arch/m68k/emu/nfblock.c | 2 +- block/bio.c | 2 +- block/blk-merge.c | 27 ++++++++++++--------------- block/blk.h | 4 ++-- include/linux/bvec.h | 14 ++++++++++++++ 5 files changed, 30 insertions(+), 19 deletions(-) . From: Sebastian Andrzej Siewior To: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Jens Axboe , Mike Galbraith , Minchan Kim , Sergey Senozhatsky , Thomas Gleixner , Alexander Lobakin Subject: [PATCH v3 0/3] zram: Replace bit spinlocks with a spinlock_t. Date: Fri, 5 Jul 2024 14:49:13 +0200 Message-ID: <20240705125058.1564001-1-bigeasy@linutronix.de> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: photonic.trudheim.com org.kernel.vger.linux-block:93872 org.kernel.vger.linux-kernel:1269154 Newsgroups: org.kernel.vger.linux-block,org.kernel.vger.linux-kernel Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hi, this is follow up to the previous posting, making the lock unconditionally. The original problem with bit spinlock is that it disabled preemption and the following operations (within the atomic section) perform operations that may sleep on PREEMPT_RT. Mike expressed that he would like to keep using zram on PREEMPT_RT. v2=E2=80=A6v3 https://lore.kernel.org/all/20240620153556.777272-1-bigeasy@l= inutronix.de/ - Do "size_t index" within the for loop. v1=E2=80=A6v2: https://lore.kernel.org/all/20240619150814.BRAvaziM@linutron= ix.de/: - Add the spinlock_t unconditionally - Remove ZRAM_LOCK since it has no user after the lock has been added. - Make zram_table_entry::flags an integer so struct zram_table_entry does not gain additional weight. Sebastian . From: Christoph Hellwig To: Jens Axboe Cc: Ming Lei , linux-block@vger.kernel.org Subject: extend the bio alignment check to bio based drivers Date: Fri, 5 Jul 2024 14:56:49 +0200 Message-ID: <20240705125700.2174367-1-hch@lst.de> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-block:93876 Newsgroups: org.kernel.vger.linux-block Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hi Jens, this series extends the bio alignment check in the block layer to cover bio based drivers in addition to the blk-mq based path, and then drops the equivalent debug checks in brd. Diffstat: block/blk-core.c | 7 +++++-- block/blk-mq.c | 11 ----------- block/blk.h | 11 +++++++++++ drivers/block/brd.c | 4 ---- 4 files changed, 16 insertions(+), 17 deletions(-) .