From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 6B10B385D97 for ; Wed, 8 Jul 2026 23:24:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783553063; cv=none; b=m7YUuiLaRQfz9WIM//aUgJIQK2xxETPOQNeCWi3w5EgzaRpxbVH84ErvvbwTvFbymreKM/htcok00z8FlRvMETNrjkMUm+HxPW2I2jEabCdX326YDw5dpneJs4/DYm6IYQZ05EBsvQBxhBKhFiI8//exlxp2JEzJ0LGIx0koKrw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783553063; c=relaxed/simple; bh=JtRB+pY0jGgOOTlVurcxI4B+c+Yq3YAfLr+R/J5xOM4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=H+6yehGr+q/QC27+5PUpvy4+GHynoGykWvoLKolX/grPKYULsmzkchVJfc/FehkxcdKyYG6aaCsw66KE/bKhu2Yp2Mn/MJudvg3rLmEYNUKRmS+PTv3Tay7REtvcRhTV50csTEXMYPbKxIUbav7OosMKq1LGqeeYf4AXgPCazx0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=FjeiTpJb; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FjeiTpJb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1783553061; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=p9Tdbre0PNKSXvRptozBBT+tS7NebUWHcrzp9pkL8yo=; b=FjeiTpJbGwyvSUgksUYIf46hIzpQdaTWJ6huyV2IyvDIGhZhxafCyiWY046ZmTdFHMgESX RlAvrVlmbWM3TA2NkWDQ/fv0e2cLMIQ51etAiWLuzJbbyo0Qh2g9bS0bsxiF+7BKue15dZ BCloUHNH778syfJVQKIFtKBCWP/uslg= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-412-zC17dWHfNZ2Q1N59mu4B1w-1; Wed, 08 Jul 2026 19:24:18 -0400 X-MC-Unique: zC17dWHfNZ2Q1N59mu4B1w-1 X-Mimecast-MFC-AGG-ID: zC17dWHfNZ2Q1N59mu4B1w_1783553056 Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2DBE419560B7; Wed, 8 Jul 2026 23:24:16 +0000 (UTC) Received: from bmarzins-01.fast.eng.rdu2.dc.redhat.com (bmarzins-01.fast.eng.rdu2.dc.redhat.com [10.6.23.12]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 372943F317; Wed, 8 Jul 2026 23:24:15 +0000 (UTC) Received: from bmarzins-01.fast.eng.rdu2.dc.redhat.com (localhost [127.0.0.1]) by bmarzins-01.fast.eng.rdu2.dc.redhat.com (8.18.1/8.17.1) with ESMTPS id 668NOD8G2029519 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 8 Jul 2026 19:24:14 -0400 Received: (from bmarzins@localhost) by bmarzins-01.fast.eng.rdu2.dc.redhat.com (8.18.1/8.18.1/Submit) id 668NODbv2029518; Wed, 8 Jul 2026 19:24:13 -0400 Date: Wed, 8 Jul 2026 19:24:13 -0400 From: Benjamin Marzinski To: Mike Snitzer Cc: Keith Busch , axboe@kernel.dk, Mikulas Patocka , Keith Busch , dm-devel@lists.linux.dev, linux-block@vger.kernel.org, "Dr. David Alan Gilbert" , Vjaceslavs Klimovs Subject: Re: [PATCH 2/2] dm-raid1: don't fail the mirror for invalid I/O errors Message-ID: References: <20260616150554.1686662-1-kbusch@meta.com> <0bd687cf-82ac-eacf-844b-c179a52dc72c@redhat.com> Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 On Tue, Jul 07, 2026 at 03:44:54PM -0400, Mike Snitzer wrote: > On Mon, Jul 06, 2026 at 02:52:33PM -0600, Keith Busch wrote: > > On Wed, Jun 24, 2026 at 01:14:03PM +0200, Mikulas Patocka wrote: > > > This approach is OK, I will stage the patches when 7.2-rc1 comes out and > > > when I'll fork the dm git branches. > > > > > > I suggest one change - it is kind of hacky when multiple I/O completion > > > callbacks write into io->orig_bio->bi_status concurrently - so it would be > > > better to not do it and maintain and return separate bit mask for > > > non-retryable errors. > > > > > > For example: > > > > > > static void complete_io(struct io *io) > > > { > > > unsigned long error_bits = io->error_bits; > > > unsigned long nonretryable_error_bits = io->nonretryable_error_bits; > > > io_notify_fn fn = io->callback; > > > void *context = io->context; > > > > > > if (io->vma_invalidate_size) > > > invalidate_kernel_vmap_range(io->vma_invalidate_address, > > > io->vma_invalidate_size); > > > > > > mempool_free(io, &io->client->pool); > > > fn(error_bits, nonretryable_error_bits, context); > > > } > > > > > > static void dec_count(struct io *io, unsigned int region, blk_status_t error) > > > { > > > if (unlikely(error == BLK_STS_NOTSUPP) || unlikely(error == BLK_STS_INVAL)) > > > set_bit(region, &io->nonretryable_error_bits); > > > else if (unlikely(error != BLK_STS_OK)) > > > set_bit(region, &io->error_bits); > > > > > > if (atomic_dec_and_test(&io->count)) > > > complete_io(io); > > > } > > > > > > Please send the updated patch that uses this approach. > > > > Sure thing, I can get started on that. Though I think it's largely > > obviated if we get the block layer to handle things early rather than > > submit malformed bio's, and this will accomplish that: > > > > https://lore.kernel.org/dm-devel/20260624170905.3972095-1-kbusch@meta.com/ > > Jens hasn't picked that series up yet. Jens? > > > But I can certainly respin this series as it provides a more indepth > > defence. > > > > I also owe an update on the relaxed dm-crypt direct-io memory alignment > > as well, as that series fell through the cracks on me for the previous > > merge window. > > So where does dm-raid1 and dm-crypt stand relative to these DIO memory > alignment changes? Inferring they are pretty exposed. > > > > BTW. I think that blk_path_error should also test for BLK_STS_INVAL and > > > return false, otherwise, dm-multipath would be suffering from this bug > > > too. Ben, could you test it? > > > > Good point. > > Would appreciate knowing if multipath exposed too. I can't make it happen. I can reproduce this using dm-mirror, but when I try with dm-multipath, it fails with BLK_STS_INVAL before it ever makes it into the request layer. blk_mq_submit_bio() -> __bio_split_to_limits() -> bio_split_rw() -> bio_split_rw_at() -> bio_split_io_at() bio_split_io_at() checks the bio_vec alignment and fails with -EINVAL, causing the bio to get failed. -Ben > > Thanks, > Mike