From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 BA0A03603D3 for ; Wed, 1 Jul 2026 15:47:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.221.51 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782920853; cv=pass; b=dJNUpZQDd9bGQ8a5E7G0u/oS34Kvn6fre7ipicQvSuEy6qUQi3rDEtnV4tBvxst32SlyQu417BUlNMFENaC9GE0Ig3h/J/N97uEBZL7T8J3W4rJojfhj2JyDYdTbvaV/M74IsIxrhCbqCGtR+n6CwhLo80t73lrndDE0+eyGzcQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782920853; c=relaxed/simple; bh=ZayiJGGDGLIh792t6ySSC3WVRP3ob4FSzMOllOM6HdI=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=W53nBGzDHVHJ/c3mODl+fjJaZBvFWi3Zr/hOa0REg6Qu+ccYMNm6iRIxjy65UFLRRm+tWUme2PPd7aIA5ojPf+rqIMfVzFAbpz7Uhrl9/bhDWJBmAL3IH8tAGQVWdBJw6gc8WoCs+otjQJQnTxzVPs4HrlL0f7ZZEphMMotAc0s= ARC-Authentication-Results:i=2; 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=dkBMw1p6; arc=pass smtp.client-ip=209.85.221.51 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="dkBMw1p6" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-47640541585so517062f8f.1 for ; Wed, 01 Jul 2026 08:47:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782920850; cv=none; d=google.com; s=arc-20260327; b=biNNSRIDM89R6qI7XukoM3uO06JwRcJyDaPbBWaoyyHeizNa65BBtGSgIaRuyeB7WH N1g0cThnRtwhFLWZANDK5flYAsl63FYZsysEHM08jpvDMudOlh3iv61hcvnYPpo9y2ej Kml6+8ilEsbuunsxwD/Tmj1TNreRqHmTV3KdJP5igErqei0J0DKcvPaCc+aHcFSzMnJU gEDpNBQnfnZ6+5/xiiX6aevFyhMMRz7GY1KusMr+N30Qwhp/n9WaApgQL7UbkS1DOIhN fmjn/ZDB7TnMshmg3tj4BSO+Bw9AvtUMXG9G4CgcdBilwP3sjejOwx/vDbFieziqlkKH yh+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=3u/rPeftjMRMwQ9b5uvwxw83sWJlfLit/lDQul6EARM=; fh=fZdxAsQxpJnuDXReIymkK/vegetnhrz4+s+iWy9Ym54=; b=iQGjBDnY2eGr1tJyuIbxPBjDeG7V+u5fbSmrKSQkr9iJmgvXk8Kggq9x2TlB6GzG59 qfbP5C4/nfoJRaQL3I4sAVW56YGq0bygY6nDxI4RHMr3MRoLGlSPo72qkFgeJ0tMCCwX XJg5he8vEWWSSkNf8SE2AHDUBQH9HGqPX2ZwDKUIX3yfBstcaNAWvtRph0tJ/aDX1TrA vCOczi5mOHRmTU3+K1p92IQjyx0r0gN95lqySWuTyH53JSzrqU7Nycckx+qJTe/i4i4N hozL8Zn7JxHbzEKkysD9bX66MfWSyLTwt3sGOhSSRIiJbwiqaib6etsXGWepMgQjsFDC iSfA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1782920850; x=1783525650; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3u/rPeftjMRMwQ9b5uvwxw83sWJlfLit/lDQul6EARM=; b=dkBMw1p6skgcQ2ZRazuuTc+Aev5k4AOwCNpNvbieuGnlhD1TELmtNULGyBIWomzOQ2 ipNl7JWgh6C3piifWFipqmjja4cHaTSgy9dmVmR61uIf1yxr4LBSuAcmLJ6tlOnbJ5t+ W6azQrfReuyutyPiAU3LnLRFoPibCliF3iwXWvePEninlqjgaKtoqLc39eMbjMHNil4K mPSCooTZvzWDfSZsLPpopE54U1PbO1mUQLI8RELY9kG0MbJcOs91AeXH6wejXiZ4kWiu oXoweJvwiPMKKJlamQqpkcI06aY24cjW/dQIX8bBSEJrpbenzsb/pdQrXfVF8FFUl1iw 0Iwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782920850; x=1783525650; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3u/rPeftjMRMwQ9b5uvwxw83sWJlfLit/lDQul6EARM=; b=k9WIwphG6+ZcZlmZeCpaicJMJBN+q+HyVbziKRJsjMt41lLXxS+xFrRhmaihpTVfsR c2xvszmsp0XO6IVboZm57/kOkZFmr+SYEgRDrp6N9OcZ3ns/WF+1WjQWlrbvGiVKJ+9p emPGcE/EEclPgCczxmNGsURd9vsF+QVXn6+2pO70OiMjrUqf0+DPuQaEtMtSZifZ0rDJ pX2Rw3jIoY/cebsl2HXrTMG8bTv0nEPAlMli0R15yUKBHN/uZ/EKaqp7ySlqOG0T+Bqx ADAT2/BtC3w8umXWvu93Z+0uF98/obEJzn05vxJ7wN1Xki/xWif+y94jRpeDVP6Ejn3j k8Ag== X-Forwarded-Encrypted: i=1; AHgh+RoL9ufJp658pKP0xnRH5JWUZSRVdxyxVl1HvXTrEBymE92p4k4pe5qdZrKCfXBDna7Pft64td28ftiR77Q=@vger.kernel.org X-Gm-Message-State: AOJu0YwGqC+IezKx65t4Od4ZubnzH9YqB8UnxSSqAfroKpiqDdInTzq4 ro7+aWChT3B3kGiwK2TCvrKyowVsogfXR20xUib+Qe+YXcXMhlAXlVdMyKO2dBKFwYWoBfGq6dz +qctJVXbqyGrUE9rZd0tTFjrWO/bh47MZqPUNFFEp7Q== X-Gm-Gg: AfdE7cnbInRyGuuET7XaIh9lt3yxC17WTLv5dTu1lunak3KyW0MKVvXkrVcD+5LikGn 9WzyXiGnxaoC97xa2tRWQCyU/SOOP3fRP5DnOexaI+zCot0mpbUzf8NgVLWOY0D06ybXRAF8ywG /Kea2XrXADT9Z8WyzFDfHUabRxOaZGhyLaDG6Eoz/7N3/T3G+YhjnBLwbBfeSJnq5Dk7piqEIN9 Q8dsRuImOkmvyHL7JZxpVplcWk5JzNv18Bl0SvDZcZCzYcItx82M8CcpZ3DELAgge5fg+50ZTjo NEzrQU0OV4PQlTY1OsC/Pg5KxufhzBLfgAIDCul29PL//Ldm2lHha7JaT0azIuPPMG9Tng== X-Received: by 2002:a5d:5f82:0:b0:470:258b:b20a with SMTP id ffacd0b85a97d-477571cb896mr3856098f8f.10.1782920850225; Wed, 01 Jul 2026 08:47:30 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260624165144.556908-1-neelx@suse.com> <20260624165144.556908-2-neelx@suse.com> <7d4ab06d-6cd0-4eb6-a355-d2b51d132713@suse.com> In-Reply-To: <7d4ab06d-6cd0-4eb6-a355-d2b51d132713@suse.com> From: Daniel Vacek Date: Wed, 1 Jul 2026 17:47:18 +0200 X-Gm-Features: AVVi8Cd_RK7AMtLvO_coxJa_GY90chqP4rpiM_IRla7w7nRmF5pUhXw0QeBOrFI Message-ID: Subject: Re: [PATCH v2 1/8] btrfs-progs: check: fix max inline extent size To: Qu Wenruo Cc: David Sterba , linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, Josef Bacik Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 26 Jun 2026 at 01:41, Qu Wenruo wrote: > =E5=9C=A8 2026/6/25 02:21, Daniel Vacek =E5=86=99=E9=81=93: > > From: Josef Bacik > > > > Fscrypt will use our entire inline extent range for symlinks, which > > uncovered a bug in btrfs check where we set the maximum inline extent > > size to > > > > min(sectorsize - 1, BTRFS_MAX_INLINE_DATA_SIZE) > > > > which isn't correct, we have always allowed sectorsize sized inline > > extents, so fix check to use the correct maximum inline extent size. > > No, we only allow sector sized inline extent when it is compressed. > The de-compressed size can be sector sized, but the compressed size > still can not reach sector size. > > So this doesn't seems correct to me. With encryption it's the other way around. Even shorter data (symlink path) is always padded to multiple of the cipher block size (16 bytes with AES). Inlining a full sector size is perfectly valid. The dump from my test looks like this: ~~~ item 45 key (290 DIR_ITEM 3363472967) itemoff 11425 itemsize 62 location key (300 INODE_ITEM 0) type SYMLINK transid 14 data_len 0 name_len 32 name: \243\365@;\312\321\240\367\377\234_{\245\vW\ \035\rS\222ryN\323\031g\243\nt3\321+ item 58 key (290 DIR_INDEX 11) itemoff 10077 itemsize 62 location key (300 INODE_ITEM 0) type SYMLINK transid 14 data_len 0 name_len 32 name: \243\365@;\312\321\240\367\377\234_{\245\vW\ \035\rS\222ryN\323\031g\243\nt3\321+ item 86 key (300 INODE_ITEM 0) itemoff 7197 itemsize 160 generation 14 transid 14 size 4096 nbytes 4096 block group 0 mode 120777 links 1 uid 0 gid 0 rdev 0 sequence 1829 flags 0x1000(ENCRYPT) atime 1782916271.8000000 (2026-07-01 16:31:11) ctime 1782916271.8000000 (2026-07-01 16:31:11) mtime 1782916271.8000000 (2026-07-01 16:31:11) otime 1782916271.8000000 (2026-07-01 16:31:11) item 87 key (300 INODE_REF 290) itemoff 7155 itemsize 42 index 11 namelen 32 name: \243\365@;\312\321\240\367\377\234_{\245\vW\ \035\rS\222ryN\323\031g\243\nt3\321+ item 88 key (300 FSCRYPT_INODE_CTX 0) itemoff 7115 itemsize 40 value: 02010403000000005f0642cd89f66ce3ed930fe3ac518b7381bcd7600f7a= e1f08195bda44461ed5d item 89 key (300 EXTENT_DATA 0) itemoff 2998 itemsize 4117 generation 14 type 0 (inline) inline extent data size 4096 ram_bytes 4096 compression 0 (none) ~~~ Perhaps this would better be folded into patch 7? Or do you rather mean special-casing for compression (with the limits as you mentioned) and encryption (with full sector size allowed)? --nX > > Signed-off-by: Josef Bacik > > Signed-off-by: Daniel Vacek > > --- > > check/main.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/check/main.c b/check/main.c > > index 5e29e2c5..dedb4db4 100644 > > --- a/check/main.c > > +++ b/check/main.c > > @@ -1720,7 +1720,7 @@ static int process_file_extent(struct btrfs_root = *root, > > u64 disk_bytenr =3D 0; > > u64 extent_offset =3D 0; > > u64 mask =3D gfs_info->sectorsize - 1; > > - u32 max_inline_size =3D min_t(u32, mask, > > + u32 max_inline_size =3D min_t(u32, gfs_info->sectorsize, > > BTRFS_MAX_INLINE_DATA_SIZE(gfs_info)); > > u8 compression; > > int extent_type; >