From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (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 654E9392824 for ; Wed, 29 Apr 2026 12:34:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777466049; cv=none; b=JJo809MLO2gk3PZgodKWyb3WYdGlXh+Txi50dD3oyHDNHnVawyMZpknkPQJmXoyTLd1fJdPQzDpvUXESjOuwBQJq8V7gsUkRUbgz/yYoRv4NnhsA1uSqe7IAJuJH2LUIMB+7M83zYXA3gJQNgcblhC30OOpZRs0b1LR+gR2CP8o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777466049; c=relaxed/simple; bh=sdcsv9NyXfxxr3df9sMar2q/gbpIVDepv6xljGdN+TE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cW8FvRbEToIJLxhA+/AEdPUpDhl6ONfGKSeUIAJ3dh/1GQaQqgzH0rzeiQSKbEJVZEuTg3Nggn8JiCiMjxEeTL3ZfkgfQj1+Zlws/spuvkhYaj5cZvTkZfIook49TyFV0EmAmxextV/poqoRDwDmGMPEsv0RbmZB6gxGGOThLJo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=Rpk6QOvj; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=aoIhpult; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="Rpk6QOvj"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="aoIhpult" Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 63T8qEVw3066925 for ; Wed, 29 Apr 2026 12:34:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= ESKRVLao67V51kqXr2l1u0fZIaIK0uFsHy1DPkT8I18=; b=Rpk6QOvj/ExBWkDK ufF5Au2L4yaCwWKcCSGrKdknn0mLwhq0VfWLMbDJ8BZUS/uzbqCSCPfVGO8q032g 5H3TwX85uHd6Q0hbQgczNaTTRUiVeF81tUKThK8yNfD/NiKy7Cq1MZKjRWQ775KG p+3hkT05Yb4PJiRCFLr8wpdrzg0r1/xSAVNwQDfrqE7RNjhVg7WVvvqbACu/nXYy 9IwFrXZ4Awv5SRZB/6RRawSqrCKyGGXPZDfS3yjfoif+aZr5YpSNqe4YbVESXPeW Ojxn04MvZEKAqg0ZCGCXZI+skfpldbqzB0ZksyfsU1AspBExBcmfG+BVULN+2Exy SrpNNQ== Received: from mail-dy1-f197.google.com (mail-dy1-f197.google.com [74.125.82.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4du7sxag7s-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 29 Apr 2026 12:34:07 +0000 (GMT) Received: by mail-dy1-f197.google.com with SMTP id 5a478bee46e88-2de07c12745so44339310eec.1 for ; Wed, 29 Apr 2026 05:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1777466046; x=1778070846; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ESKRVLao67V51kqXr2l1u0fZIaIK0uFsHy1DPkT8I18=; b=aoIhpultALsdMyEKWmrEVn84X+liw1MKVTuHgUEGzFYdk/ZLGDub1Qmw94N/DsAWDW c4xKDRcadwkfs0M4Zc0upLm/x3ya2Lg/fkX4Tr9GL+I2h8i5SD7XulOiGkEJCR6WjQNI 433X/Gay561AVEoBSL6coj+bzuOTPRt2WFApZych61VdZmtCkizeb6ZAKHIgljqwZhOd sCxrR59+4dNmjJnFkxFeCgpV7LvJ2HDHAvLhiqLE7zI7eAaK97MTAoBthr/N4PMJoaNX h3EP8gfTgRNDQSWZXROc2WM+mzh4ELgq5yCYcoulyzD3mcqRj4SxDB8goreX4sjYrOIJ cp0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777466046; x=1778070846; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ESKRVLao67V51kqXr2l1u0fZIaIK0uFsHy1DPkT8I18=; b=aacFoIsJB4hobkNs9R0oqqccwWsaQ99GIVaQ/m0coiD6tY+d84xjOL78RSyIuGWm6r zIZDCN6YaK3/VmOgtFnr0nk7Dzhmkw+iphdxQSPPww9xd09Xm6f2gGYX2ZBguHIVkwtc +jbCwMlIEh5UYGjWWYqv69XJhSH06IIfbUg1N9ZUTgT7zlPRCpPqUE8IBIrbr/hhMohz O1uicWuwMH+nJ52tfyQEVOcOPU6xvJkmzOVOjiJvBsQgofiJSQo/T1hcfF1jgOtavZCs 1a5yWSokNaKMwdUl57l+d+YmDqd8XW9nqYIAtt3KGNQzHbgZPWUjicGjDoc+aH+cUkEb 1WmA== X-Forwarded-Encrypted: i=1; AFNElJ/+ViDnbYvTBT9KJ8q+UXoCzVggPiJGWf77KLwuJ2NtuDbGVWfNNoS8pacGXYL6wnj+uJz7PSouPRH8z3w=@vger.kernel.org X-Gm-Message-State: AOJu0Yww3yyuojVW+7sAoaFOcgBF4x6WTq9jQAjERMVMcPrbmGA2DU4k wuKNhwXfasv1c3Cuaz1VzAV6fL0r762Ulyc3SV86vzHvG1qAVyzYdczC4bBRqBP8Mh0bTQg30fg 5K2zKJZ3Rb6GUFQsuMr414UsxLUCQyJXnsmZdJr+dH03Y372xWQISDHrNWnOStsrBnI4= X-Gm-Gg: AeBDieskzGHRjmt6e01HE3kh0irSY9M+udIR34AYESY0Am5cQj8s34lL2+pf2QHftn4 gEB80Zv3aU23c/GxJnNNJEWYkpCnBDBacMJBXjZXhvoo993tR8nzdI+EU+VdPMU8Blis21f0jYB t059w142j6M8SvsAibo3aR7YevP7u6UmSzs+dyJpa63kNrhdtUsgoIi9hFAGoYgsO3IYOHjlj4+ Vck0AUFoNHzfYZRgwlZw+LFTloVmSU+ICakSx0tQaUd8iLgx9uLNRkiy9B5zGkA6YooezHGcUWE rGIVf1gz36IG2sHa9xFg7r572sGQIYRLiRv/iRdaCv/Ia3Y+4/ncVhrJUbZnsweueToYxvhB0Yj xOEa0Z1paagFGFpIYw6MOAvXH1k68UFKZKooYNYC1717t8pBN7DcFAnuffxnlzGRGIHTHJc2Io8 AxdC8j92eI0dZI1g== X-Received: by 2002:a05:693c:3017:b0:2df:7b88:a1b0 with SMTP id 5a478bee46e88-2ed0a1a9028mr3495471eec.27.1777466046135; Wed, 29 Apr 2026 05:34:06 -0700 (PDT) X-Received: by 2002:a05:693c:3017:b0:2df:7b88:a1b0 with SMTP id 5a478bee46e88-2ed0a1a9028mr3495449eec.27.1777466045450; Wed, 29 Apr 2026 05:34:05 -0700 (PDT) Received: from [10.110.45.159] (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2ed1c09c6e3sm1847750eec.25.2026.04.29.05.34.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Apr 2026 05:34:05 -0700 (PDT) Message-ID: <7ab5cd97-30b7-42ca-80ce-6d9cd8c45b73@oss.qualcomm.com> Date: Wed, 29 Apr 2026 20:34:00 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] dm-inlinecrypt: add target for inline block device encryption To: Benjamin Marzinski Cc: linux-block@vger.kernel.org, ebiggers@kernel.org, mpatocka@redhat.com, gmazyland@gmail.com, linux-kernel@vger.kernel.org, adrianvovk@gmail.com, dm-devel@lists.linux.dev, quic_mdalam@quicinc.com, israelr@nvidia.com, hch@infradead.org, axboe@kernel.dk References: <20260410134031.2880675-1-linlin.zhang@oss.qualcomm.com> <20260410134031.2880675-3-linlin.zhang@oss.qualcomm.com> <6390db35-7f8e-4d00-9c1f-43d676007910@oss.qualcomm.com> Content-Language: en-US From: Linlin Zhang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: tlxnfmhWJDnSARGqh9B3zj6IJKQh2sil X-Authority-Analysis: v=2.4 cv=eeANubEH c=1 sm=1 tr=0 ts=69f1fabf cx=c_pps a=Uww141gWH0fZj/3QKPojxA==:117 a=JYp8KDb2vCoCEuGobkYCKw==:17 a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=1XWaLZrsAAAA:8 a=PdZeKNdsCEgzLFXmAeUA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=PxkB5W3o20Ba91AHUih5:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNDI5MDEyNyBTYWx0ZWRfX4NgmYVFFxMOS zaNw8CiMGAjEwA298hJDAkYSby7jhYllIUZU4CpIVkgQISKP9nlz0J/MFzcxIEnxTCcvSjquJvY P0tmRCkqGCWzVECzir5LTd+/JTBSqyRzERo6UAO/4N8i0V6urs4KgWXOcajHsh2Cn58MjGvAci2 RsCWrr2SRwNyBA7Ori+HApy8674mh03OstFuYPr7li/Mbs5xDnCDu7HnSlYVvpyoRaSatASGXy7 AKKzkKTep0uBpoM7fmPd57XjRGm0ceuDnzFPwzJYX7H7VAndRmu3fyFq9vkGuwr1aSOxytexcnP vqsAvuDkPlXZhKwJmE+C9bfpcftsFd6BDDvDREDuiViHosNbrE3tAnlYyMLkWA4TwdFKgS67/xt YZzyU/AzLwS926dyLFc+xfEX5MMGzI0v23zl56oEv2pUNYEovxigCOcxNmnusXTYcZBnUDnct7l CcQOPPa67JvNz2enocA== X-Proofpoint-ORIG-GUID: tlxnfmhWJDnSARGqh9B3zj6IJKQh2sil X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-04-28_05,2026-04-28_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 adultscore=0 clxscore=1015 malwarescore=0 impostorscore=0 phishscore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2604200000 definitions=main-2604290127 On 4/29/2026 12:36 AM, Benjamin Marzinski wrote: > On Tue, Apr 28, 2026 at 05:20:07PM +0800, Linlin Zhang wrote: >> >> >> On 4/28/2026 7:21 AM, Benjamin Marzinski wrote: >>> On Mon, Apr 27, 2026 at 01:23:27AM -0400, Benjamin Marzinski wrote: >>>> On Fri, Apr 10, 2026 at 06:40:30AM -0700, Linlin Zhang wrote: >>>>> From: Eric Biggers >>>>> + /* >>>>> + * Since we've added an encryption context to the bio and >>>>> + * blk-crypto-fallback may be needed to process it, it's necessary to >>>>> + * use the fallback-aware bio submission code rather than >>>>> + * unconditionally returning DM_MAPIO_REMAPPED. >>>>> + * >>>>> + * To get the correct accounting for a dm target in the case where >>>>> + * __blk_crypto_submit_bio() doesn't take ownership of the bio (returns >>>>> + * true), call __blk_crypto_submit_bio() directly and return >>>>> + * DM_MAPIO_REMAPPED in that case, rather than relying on >>>>> + * blk_crypto_submit_bio() which calls submit_bio() in that case. >>>>> + */ >>>>> + if (__blk_crypto_submit_bio(bio)) >>>> >>>> This will still double account for fallback writes (which call >>>> submit_bio() on the encrypted bios, and return DM_MAPIO_SUBMITTED here). >>> >>> Just to clarify, I'm talking about the vmstats accounting. The IO >>> originally gets accounted by submit_bio() when the bio is submitted to >>> the dm device. For actual inline encryption and fallback reads, dm will >>> submit the bio to the underlying device using submit_bio_noacct() to >>> avoid double-counting the IO. >>> >>> For fallback writes, __blk_crypto_submit_bio() will submit the encrypted >>> bios to the underlying device with submit_bio(). This adds the IO >>> sectors again, even though it's the same IO, only encrypted now. >> >> >> Right, thanks for calling this out. >> >> For fallback writes, the IO is still double-counted. Given that this only >> affects IO accounting in the blk-crypto fallback write slow-path and not >> correctness, I think this is an acceptable tradeoff, and we can leave a >> TODO to revisit the accounting once a better solution exists. >> >> Add the bellow to the annotate. >> >> /* >> * TODO: blk-crypto fallback write slow-path currently double-accounts >> * IO in vmstat, as encrypted bios are submitted via submit_bio(). >> * This does not affect data correctness. Consider fixing this if >> * a cleaner accounting model for derived bios is introduced. >> */ >> >> Do you agree? > > You could add an extra argument, for instance "bool need_acct", to > __blk_crypto_submit_bio(), and plumb it through to > __blk_crypto_fallback_encrypt_bio(), where it could be used to choose > between calling submit_bio() and and submit_bio_noacct(). > > We could even add a flag to cloned bios for stacked devices, that could > be checked in submit_bio(), so we didn't need to have > submit_bio_noacct(). But this is a pretty niche case with other > solutions, so I'm not sure if it warrants adding more checks to > submit_bio(). > > I do agree that people probably aren't using dm-inlinecrypt for devices > where they don't actually have inline encryption capabilities, so it's > not a major issue. What to you think, Mikulas? Thanks for the suggestions. Adding a bool need_acct parameter to __blk_crypto_submit_bio() would require updating all existing callers, which feels rather intrusive given that the accounting issue only affects the blk‑crypto fallback write slow‑path. I’m a bit concerned that this would broaden the scope of the change more than necessary for the problem at hand. An alternative might be to track this at the bio level instead — for example, by introducing a bio flag or metadata that indicates whether accounting should be charged for a derived/cloned bio. That would avoid having to thread additional parameters through multiple blk‑crypto entry points. However, this likely needs a broader discussion to make sure it fits well with existing stacking and accounting semantics. Also, as discussed, the current behavior does not affect data correctness; it only results in double vmstat accounting for fallback writes. Given that dm‑inlinecrypt is expected to be used primarily on devices with actual inline encryption support, the fallback write path should be relatively uncommon in practice. With that in mind, would it be acceptable to merge the current change as‑is, with an explicit TODO documenting the double‑accounting in the fallback write path, and revisit the accounting model in a follow‑up patch once we have agreement on a cleaner solution? What do you think, Ben and Mikulas? Happy to iterate further if there’s a preferred direction here. > > -Ben > >>> >>> -Ben >>> >>>> >>>> -Ben >>>> >>>>> + return DM_MAPIO_REMAPPED; >>>>> + return DM_MAPIO_SUBMITTED; >>>>> +} >>>> >>> >