From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F398385D90 for ; Thu, 2 Jul 2026 06:19:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782973200; cv=none; b=Liv7vWW9d6s0zVqdNrU1MoUXtY7eSoWIP/PNJVfSZsD7FzsmZ+hTU/b4I2RKPI9iDoQbzWQpnNxhxJPHFKvzJ7WG7HoWGrrGXnnP+b5PItczA0U7022C3HK1jGk54TF9SG0XFqnROldN2XuIyLc/ZjPqgW8IMNPhZjLC7Msz2OA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782973200; c=relaxed/simple; bh=6asIS1kdosYI3hJjie83OOnmP5nV/dvRv9ZKme0rVCE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=aWrBpSJrZ+tpyJfT0iUGu6BccjzQhJF/UtOwOP5ray1UO9HgTZzUwDoWSUWnTPQIs+pAHbb6RwcPvam1t/729iKBB/L4zLqeJ6e6e4YyE3dK1As0TQwkZJXlaPmuT5fvifqaaNzuI6vUzaj5ah2rcRAcKzyCWNflIyk6xdaMUeQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=RSAtWAnR; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="RSAtWAnR" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4921eed3fa2so9517205e9.0 for ; Wed, 01 Jul 2026 23:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1782973194; x=1783577994; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=N9Kk/Q1G7DG2Lf8I5bwAQLC8TgAuIECL4GsJF+QZ+WE=; b=RSAtWAnRIL2mziYfBBWnjHUjzp3lT1Sejys4chMzQ1Yi/HoCqvj/xbJ6H9R/Hm9brs SmTIemlHuOrbkT28KqCtN3Z6jOh+g6xAtK/lMEvVQUjIOOn4PUK2m5QWr/noEj9cOkN8 waP8s1BPSROxmrWR6Truo35kYMejZoMhKX7SpqGdLkMDGRWgo/6rOhB+h/nkCjND6nI3 9AxX1dK5p80pUIik0m3rK0drKh1so5jbzZgT+1GUvm/riv8HWRdAG16cWp+Qfy5Je0EL 15LxiukjTLxNoBNSMj+G2OiR3YG1xVqde1S8aDI0xUwIdnnYWiJWLKbmcvoHzuiKv1Rt Uz3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782973194; x=1783577994; h=content-transfer-encoding:in-reply-to:autocrypt: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=N9Kk/Q1G7DG2Lf8I5bwAQLC8TgAuIECL4GsJF+QZ+WE=; b=mx6MTi7tSmDpe/vdGneHBNSVihPOeJOngPYywe1tl2xxu9kqpr18nLAS/sMOxwZoIh vQbqzEYQKEDB/4dNfhAn3paOhGQICwZeMR6C/kHET7P8UlrM2/TWTUjcGBg5OEzeh/Yo xbW6kNfiUdruUyCWZXfjWFcbz6TSx+0wzaXJHoXuZOGK4FJqI4A99ULl8LL+6INyqyBu r7UQUyNXqxEATiPSR2SyHg88ayXWy6XVoZJ1rpusLP5WqpipBKR6uJGth8gLaY2pJtVB scuYktLqK8hl4UnNiJqPE/nea9K3+OD1WaFMuvNaktLihMjqVfS1jplNFwQv0kgq5XXF I74Q== X-Forwarded-Encrypted: i=1; AFNElJ/Wh9vLjypfluXGwckZkAQTH/M8SrwK5HoSh9M7g+2R1bu76jEM4LZadPjCtrHglhB9Zsbp3aFGpMWF0Ow=@vger.kernel.org X-Gm-Message-State: AOJu0YzEEd7iP4vo3WzJ0YfvkwdJdYJ+SuJxG/93/XGFpjlCV1HJtCGS RRYbgORnvnPDaowMc4ByDC+eW8EH4YFWHVvIrIoEQofm7VqvoxzzvdeW2FjjUWvw9xk= X-Gm-Gg: AfdE7ckGc6pXLGChk6cY8FBMMPXCN7dj8UBcsibawOcoLP4UrKZzMOLyrPKJIQOgBbN faNF7CKTUSJqlvgmydTbpNiDm7/9Zw4M/qNPyQmXggf502DGlZJukoQ6BbkIlnlRL7F3dUFsA9S FlNHr/c9lEBgt1wmqsl4WCCcwmnqMTJWOzSPd5clDtVnCWCL/AnMWCiPzmS+kMXVwfC/y4SDVTh O/O7BNuDCfE3fT0WYo1uXlyhzyoZB1LzhoWw019xZWaF2E7z/wby2y2Argl7O/4nWLhjieFEEMN AiSIkcWENGu5Qs/OFZ4fU7ApLo1MF9Dt9ghmJqDByRoPSXKzKvT9WLv2kRBBO34hwEj2dS5gJdL gEws3VAPrw5RBMaHw4t9gqRmEMxI5WRXAULU+M8vW6ZfMvpwJOaxnGkWuoZH8yLobyR5ddn7eJo wqBT2jfPUJyOsQk6zQ0Lki2LdbKdQXQkf0v3y2oVA= X-Received: by 2002:a05:600c:8590:b0:493:b7a6:3dac with SMTP id 5b1f17b1804b1-493c2ba5810mr49868055e9.33.1782973194021; Wed, 01 Jul 2026 23:19:54 -0700 (PDT) Received: from ?IPV6:2403:580d:fda1::299? (2403-580d-fda1--299.ip6.aussiebb.net. [2403:580d:fda1::299]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13b3c7fa33asm5650050c88.5.2026.07.01.23.19.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jul 2026 23:19:51 -0700 (PDT) Message-ID: <5a8f027b-420e-41be-b852-a27fb084c32f@suse.com> Date: Thu, 2 Jul 2026 15:49:46 +0930 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 5/8] btrfs-progs: print encryptin type field of file extents To: Daniel Vacek , Qu Wenruo Cc: David Sterba , linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, Sweet Tea Dorminy References: <20260624165144.556908-1-neelx@suse.com> <20260624165144.556908-6-neelx@suse.com> <867a944d-3a26-4248-b0aa-f10247196502@suse.com> <589e24f3-e3a3-4a41-86a6-5f99ad5487f8@gmx.com> Content-Language: en-US From: Qu Wenruo Autocrypt: addr=wqu@suse.com; keydata= xsBNBFnVga8BCACyhFP3ExcTIuB73jDIBA/vSoYcTyysFQzPvez64TUSCv1SgXEByR7fju3o 8RfaWuHCnkkea5luuTZMqfgTXrun2dqNVYDNOV6RIVrc4YuG20yhC1epnV55fJCThqij0MRL 1NxPKXIlEdHvN0Kov3CtWA+R1iNN0RCeVun7rmOrrjBK573aWC5sgP7YsBOLK79H3tmUtz6b 9Imuj0ZyEsa76Xg9PX9Hn2myKj1hfWGS+5og9Va4hrwQC8ipjXik6NKR5GDV+hOZkktU81G5 gkQtGB9jOAYRs86QG/b7PtIlbd3+pppT0gaS+wvwMs8cuNG+Pu6KO1oC4jgdseFLu7NpABEB AAHNGFF1IFdlbnJ1byA8d3F1QHN1c2UuY29tPsLAlAQTAQgAPgIbAwULCQgHAgYVCAkKCwIE FgIDAQIeAQIXgBYhBC3fcuWlpVuonapC4cI9kfOhJf6oBQJnEXVgBQkQ/lqxAAoJEMI9kfOh Jf6o+jIH/2KhFmyOw4XWAYbnnijuYqb/obGae8HhcJO2KIGcxbsinK+KQFTSZnkFxnbsQ+VY fvtWBHGt8WfHcNmfjdejmy9si2jyy8smQV2jiB60a8iqQXGmsrkuR+AM2V360oEbMF3gVvim 2VSX2IiW9KERuhifjseNV1HLk0SHw5NnXiWh1THTqtvFFY+CwnLN2GqiMaSLF6gATW05/sEd V17MdI1z4+WSk7D57FlLjp50F3ow2WJtXwG8yG8d6S40dytZpH9iFuk12Sbg7lrtQxPPOIEU rpmZLfCNJJoZj603613w/M8EiZw6MohzikTWcFc55RLYJPBWQ+9puZtx1DopW2jOwE0EWdWB rwEIAKpT62HgSzL9zwGe+WIUCMB+nOEjXAfvoUPUwk+YCEDcOdfkkM5FyBoJs8TCEuPXGXBO Cl5P5B8OYYnkHkGWutAVlUTV8KESOIm/KJIA7jJA+Ss9VhMjtePfgWexw+P8itFRSRrrwyUf E+0WcAevblUi45LjWWZgpg3A80tHP0iToOZ5MbdYk7YFBE29cDSleskfV80ZKxFv6koQocq0 vXzTfHvXNDELAuH7Ms/WJcdUzmPyBf3Oq6mKBBH8J6XZc9LjjNZwNbyvsHSrV5bgmu/THX2n g/3be+iqf6OggCiy3I1NSMJ5KtR0q2H2Nx2Vqb1fYPOID8McMV9Ll6rh8S8AEQEAAcLAfAQY AQgAJgIbDBYhBC3fcuWlpVuonapC4cI9kfOhJf6oBQJnEXWBBQkQ/lrSAAoJEMI9kfOhJf6o cakH+QHwDszsoYvmrNq36MFGgvAHRjdlrHRBa4A1V1kzd4kOUokongcrOOgHY9yfglcvZqlJ qfa4l+1oxs1BvCi29psteQTtw+memmcGruKi+YHD7793zNCMtAtYidDmQ2pWaLfqSaryjlzR /3tBWMyvIeWZKURnZbBzWRREB7iWxEbZ014B3gICqZPDRwwitHpH8Om3eZr7ygZck6bBa4MU o1XgbZcspyCGqu1xF/bMAY2iCDcq6ULKQceuKkbeQ8qxvt9hVxJC2W3lHq8dlK1pkHPDg9wO JoAXek8MF37R8gpLoGWl41FIUb3hFiu3zhDDvslYM4BmzI18QgQTQnotJH8= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 在 2026/7/2 15:10, Daniel Vacek 写道: > On Thu, 2 Jul 2026 at 00:26, Qu Wenruo wrote: >> 在 2026/7/2 01:29, Daniel Vacek 写道: >>> On Fri, 26 Jun 2026 at 01:50, Qu Wenruo wrote: >>>> 在 2026/6/25 02:21, Daniel Vacek 写道: >>>>> From: Sweet Tea Dorminy >>>>> >>>>> Encrypted file extents now have the 'encryption' field set to an >>>>> encryption type. Let's print it. >>>>> >>>>> Signed-off-by: Sweet Tea Dorminy >>>>> Signed-off-by: Daniel Vacek >>>>> --- >>>>> check/main.c | 1 - >>>>> kernel-shared/print-tree.c | 2 ++ >>>>> 2 files changed, 2 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/check/main.c b/check/main.c >>>>> index dedb4db4..a32247b3 100644 >>>>> --- a/check/main.c >>>>> +++ b/check/main.c >>>>> @@ -1778,7 +1778,6 @@ static int process_file_extent(struct btrfs_root *root, >>>>> rec->errors |= I_ERR_BAD_FILE_EXTENT; >>>>> if (extent_type == BTRFS_FILE_EXTENT_PREALLOC && >>>>> (btrfs_file_extent_compression(eb, fi) || >>>>> - btrfs_file_extent_encryption(eb, fi) || >>>> >>>> May I ask why preallocated file extent would have encryption value set? >>>> >>>> My common sense says that encryption policy should only be set for >>>> regular file extents. >>> >>> There's nothing wrong with pre-allocating encrypted files. Unlike >>> compression, the exact size is known beforehand. >> >> IN that case, does it mean even a hole will have encryption value set? >> >> This looks weird. Is there any special reason for setting encryption >> value for hole/preallocated range? >> >> Can't we only set the encryption value only for regular, >> non-preallocated extents? > > What's so weird about it? Since the inode is encrypted, related parts are too. Inodes can have PREALLOC flags, but the file extents are not all preallocated. Inode can also have COMPRESS flag, but the file extents are not all compressed either. Inode flags are independent from file extent flags from the very beginning. > > --nX > >> Thanks, >> Qu >> >>> >>> Simillar to NOCOW, the encrypted data will be stored with the next write. >>> >>> --nX >>> >>>> Thanks, >>>> Qu >>>> >>>>> btrfs_file_extent_other_encoding(eb, fi))) >>>>> rec->errors |= I_ERR_BAD_FILE_EXTENT; >>>>> if (compression && rec->nodatasum) >>>>> diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c >>>>> index 0afa3696..159f0825 100644 >>>>> --- a/kernel-shared/print-tree.c >>>>> +++ b/kernel-shared/print-tree.c >>>>> @@ -471,6 +471,8 @@ static void print_file_extent_item(struct extent_buffer *eb, >>>>> printf("\t\textent compression %hhu (%s)\n", >>>>> btrfs_file_extent_compression(eb, fi), >>>>> compress_str); >>>>> + printf("\t\textent encryption %hhu\n", >>>>> + btrfs_file_extent_encryption(eb, fi)); >>>>> } >>>>> >>>>> /* Caller should ensure sizeof(*ret) >= 16("DATA|TREE_BLOCK") */ >>>> >>> >>