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.129.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 B349F1C84D7 for ; Wed, 1 Apr 2026 00:42:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775004122; cv=none; b=XBYHvoHpIjyndeoiKOigTDE+R/xm42H0EqUAHawH9dEM1hgzIyuRUU3um4PLmrbgVkPz0UqGiZyv+y1T/NPjdp8lTYqKTCAU3ZhFffBrwX7RJYoU5nXWcDx2F2QI3De4Tb9yDS4oPBW10fp0Rat9Vf0LyE6vX38G3mU00aRNxQo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775004122; c=relaxed/simple; bh=0f6H66EJ8FTtE0mIr6/FwIXLfnsShtG/M3I5Q65svMM=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=DUZEuxUHIMMhhMYZov+kTqZoO/3wOBVanoyXGa8wj7IvMRGeRRZHsSQLi+/zeUSfvv91jJ44rSW/ijCROjaLuQ3ig+yvZ6Tx6BHCfX8Z+cNUDAZAAei9nVYb+tKALWqtq3SkLeGcmqmwm1xmUJmEkH31cVqAgMOxX139pTWLR6c= 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=EcZburC4; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=n/Ox2uzl; arc=none smtp.client-ip=170.10.129.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="EcZburC4"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="n/Ox2uzl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775004119; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YkdBOKp8ur+t6DO8tDb2WCjkiRXdOFttzTuv0DcNlaM=; b=EcZburC4J9Xu22PdFC7ZBKzaA4uQP/JYpdFQlnB5WVeRvMLsQLU90YABELG0sjUXj/QuSW HyO4o+eOKa+ojYldmfRy9N7luEuecSlYxgrv8DGkRL6YUxprxPijWjwgbwjJPDBPxi5wB3 OGQc/7e6gUPquNuSoDIECo3jP/1m6HI= Received: from mail-yw1-f199.google.com (mail-yw1-f199.google.com [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-685-uAQ8kKYcOC2Vx1FmfWUKfQ-1; Tue, 31 Mar 2026 20:41:58 -0400 X-MC-Unique: uAQ8kKYcOC2Vx1FmfWUKfQ-1 X-Mimecast-MFC-AGG-ID: uAQ8kKYcOC2Vx1FmfWUKfQ_1775004118 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-799001d7289so65409297b3.1 for ; Tue, 31 Mar 2026 17:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1775004118; x=1775608918; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=YkdBOKp8ur+t6DO8tDb2WCjkiRXdOFttzTuv0DcNlaM=; b=n/Ox2uzlSfA1Ez2yJ5eo9lGv/OeROqRAnn78caHk5WqwNGP9qejZj1lq8oxHVAWzdx F6KYSJeSIQEfk/YjCE1xUMg/s0oXZG91D1hcxJ6umP9E8Sc8IcCpGl0KJdT3apkprW3t QLpiO/Ydk/2hEcEhc5MD08obfNWNLrORqw0UJIRSgr+GsUn62XVGLosUj0IGPK6Z+9qF iJPTP1bo8xpvg4v3mFDA9UXg4bIN1vEnMdCzI38CTLhSA50tOqrBUqg9ZnQR/1JziwNU CRLs2xcAvwSVqJPmcvUsx3mVoZXqnVuBrXwkzRT4+3dcE86avt/NufyUlIu4Nk01LF1F eM6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775004118; x=1775608918; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YkdBOKp8ur+t6DO8tDb2WCjkiRXdOFttzTuv0DcNlaM=; b=AYEZkrKBA/q9MDAFH3U8p07kAsUpPvVQMhYymuVdNZolDyOsB52frdgwDwfzvhEq// RrrY447u/ocdPNNP3rSR7Sb7xtypEv2ILY+E539iJOzRQ9c2M0i1V/iM1+PJFKgmYuU4 arZNWwODlD9oqus5nzKez4a9gxIgDqe3hnGjJipmmtfLIDwcMogIpu2XwujK+VCotQoV 7z9qweGtq+W8Q3kPF6TX7r9gs15APCB7Kt2QbQsb/vXpc7+7I4FYKEtsjXq4S60W91QR lKBToHTodJPB96bXOVZxv5k+OzNQGTEgRnEQrgbeJKY+Cp26UOFsk8PzR95/7I1nDFEb OZow== X-Forwarded-Encrypted: i=1; AJvYcCWWCs401PRuQLdP20p7bg5va/L3PL1PY96ldM27h05eDDhfsV+WzwH/sJnhRTtIhBmc3h7/nj5qnwBGwM8=@vger.kernel.org X-Gm-Message-State: AOJu0YzyPF0Xg4d3BU4AK7GF+CpP14XRUZj38s9Ol1dBsv7hxSuEzJfU JjLdP7BJOEzwmB15sdqjuTeroBCIZ9tmfxbfrkl1ez0JeLbTPUzRP0eZiWh300hUj/StjURZmTK e5U3uBLuo25bnbYGmzqdAbtsZERQTccLtCxvmmO1CRfX5u17kn8DJ/uRke+JXumIhVQ== X-Gm-Gg: ATEYQzxA1QPY9T/QGQY/rvLstEzR9RJbIwuslr9euQODjWDPJbFA263h2n1nQHevAhD PTOfCvf+85q95hCE/yWQjS5UCteJPnV/KziVOAkdglFtuP5gp1u+75Jd5AfxrH6w1AtrraJqYna vfAs6hzXkj0p+9m6GW8iwg6NIz/rwVJINR9TdPvbUOywHlaJCJM3RD09OlzoVKNFAI0P53f1SBl AzBMjbsdzq4U3BRXXLUstb5Dfbuon5WWOb94mJEQFAIGVFRAmHhCU4YJiQecOUFlEpo155zWB9y Vxla04CxoliDw8t7RWZBoCWp9c0nSniTrse6jV3YYus6/34lYbnO2oeSB+KqNy2gw8TJw0oGDUk 8BCAJG3mXyddeg1MlJg+9TagJf+ZAwLsk0QBuc2y2JwtrPL0QU/lS X-Received: by 2002:a05:690c:e08f:b0:79a:cc64:8869 with SMTP id 00721157ae682-7a21310426amr15686307b3.56.1775004117760; Tue, 31 Mar 2026 17:41:57 -0700 (PDT) X-Received: by 2002:a05:690c:e08f:b0:79a:cc64:8869 with SMTP id 00721157ae682-7a21310426amr15686017b3.56.1775004117117; Tue, 31 Mar 2026 17:41:57 -0700 (PDT) Received: from li-4c4c4544-0032-4210-804c-c3c04f423534.ibm.com ([2600:1700:6476:1430::29]) by smtp.gmail.com with ESMTPSA id 00721157ae682-79cb7910e7fsm56542097b3.18.2026.03.31.17.41.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2026 17:41:56 -0700 (PDT) Message-ID: Subject: Re: [EXTERNAL] Re: [PATCH v5] hfs: update sanity check of the root record From: Viacheslav Dubeyko To: Tetsuo Handa , Viacheslav Dubeyko Cc: Andrew Morton , Linus Torvalds , Jan Kara , Leo Stone , Christian Brauner , John Paul Adrian Glaubitz , George Anthony Vernon , Yangtao Li , linux-fsdevel , LKML Date: Tue, 31 Mar 2026 17:41:55 -0700 In-Reply-To: <5257abf7-6746-4719-9c5a-e1186883c608@I-love.SAKURA.ne.jp> References: <21e7ebfd-d35d-4682-b553-6996cc8c3a8e@I-love.SAKURA.ne.jp> <5257abf7-6746-4719-9c5a-e1186883c608@I-love.SAKURA.ne.jp> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43app2) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-03-31 at 10:12 +0900, Tetsuo Handa wrote: > On 2026/03/31 6:45, Viacheslav Dubeyko wrote: > > I've already reviewed this patch. And I am not agree with this suggesti= on. > >=20 > > We prepare the key with HFSPLUS_ROOT_CNID [1]: > >=20 > > err =3D hfsplus_cat_build_key(sb, fd.search_key, HFSPLUS_ROOT_CNID, &st= r); >=20 > What we are talking about is not hfsplus but hfs. > I can't catch why you are talking about hfsplus function. There are a lot of similarity between HFS and HFS+ b-trees functionality. E= ven we can have a common code in the form of library shared between HFS and HFS= + code. HFS and HFS+ have pretty the same function names in b-tree implementations. >=20 > >=20 > > The hfs_brec_read() executes the search of the record [2]: > >=20 > > res =3D hfs_brec_find(fd); > > if (res) > > return res; > >=20 > > The hfs_brec_find() should found the record for requested key. And if t= he found > > thread record contains not correct CNID, then we can check the found th= read > > record and return error as the result of the search. >=20 > hfs_brec_read() indeed calls hfs_brec_find(). But I can't interpret how t= o extract > CNID as of returning from hfs_brec_find(). /* The catalog record for a file */ struct hfs_cat_file { s8 type; /* The type of entry */ u8 reserved; u8 Flags; /* Flags such as read-only */ s8 Typ; /* file version number =3D 0 */ struct hfs_finfo UsrWds; /* data used by the Finder */ __be32 FlNum; /* The CNID */ __be16 StBlk; /* obsolete */ __be32 LgLen; /* The logical EOF of the data fork*/ __be32 PyLen; /* The physical EOF of the data fork */ __be16 RStBlk; /* obsolete */ __be32 RLgLen; /* The logical EOF of the rsrc fork */ __be32 RPyLen; /* The physical EOF of the rsrc fork */ __be32 CrDat; /* The creation date */ __be32 MdDat; /* The modified date */ __be32 BkDat; /* The last backup date */ struct hfs_fxinfo FndrInfo; /* more data for the Finder */ __be16 ClpSize; /* number of bytes to allocate when extending files */ hfs_extent_rec ExtRec; /* first extent record for the data fork */ hfs_extent_rec RExtRec; /* first extent record for the resource fork */ u32 Resrv; /* reserved by Apple */ } __packed; /* the catalog record for a directory */ struct hfs_cat_dir { s8 type; /* The type of entry */ u8 reserved; __be16 Flags; /* flags */ __be16 Val; /* Valence: number of files and dirs in the directory */ __be32 DirID; /* The CNID */ __be32 CrDat; /* The creation date */ __be32 MdDat; /* The modification date */ __be32 BkDat; /* The last backup date */ struct hfs_dinfo UsrInfo; /* data used by the Finder */ struct hfs_dxinfo FndrInfo; /* more data used by Finder */ u8 Resrv[16]; /* reserved by Apple */ } __packed; /* the catalog record for a thread */ struct hfs_cat_thread { s8 type; /* The type of entry */ u8 reserved[9]; /* reserved by Apple */ __be32 ParID; /* CNID of parent directory */ struct hfs_name CName; /* The name of this entry */ } __packed; /* A catalog tree record */ typedef union hfs_cat_rec { s8 type; /* The type of entry */ struct hfs_cat_file file; struct hfs_cat_dir dir; struct hfs_cat_thread thread; } hfs_cat_rec; Every record starts with type. And anyone can easily retrieve the type of record. And, then, you can extract the CNID. >=20 > int hfs_brec_read(struct hfs_find_data *fd, void *rec, u32 rec_len) > { > int res; > =20 > res =3D hfs_brec_find(fd); > if (res) > return res; > if (fd->entrylength > rec_len) > return -EINVAL; > hfs_bnode_read(fd->bnode, rec, fd->entryoffset, fd->entrylength); > return 0; > } >=20 > Since hfs_brec_read() doesn't know which type of struct (one of "struct h= fs_cat_file", > "struct hfs_cat_dir" or "struct hfs_cat_thread") does the caller of hfs_b= rec_read() > want to read, I don't think hfs_brec_read() can tell whether the CNID is = correct. Please, check the HFS's on-disk layout. >=20 > I am waiting for your response on > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__lkml.kernel.org_r_= 9f66743b-2D70e0-2D4886-2D884e-2D5203f5c02ed8-40I-2Dlove.SAKURA.ne.jp&d=3DDw= ICaQ&c=3DBSDicqBQBDjDI9RkVyTcHQ&r=3Dq5bIm4AXMzc8NJu1_RGmnQ2fMWKq4Y4RAkElvUg= Ss00&m=3DV9I6gMC1If2D6irQzVVC1M0wKQW-kbErffC9npM7z-fyjkutPS0YOARfqxRsyUdc&s= =3DMAn71bGJ4-F3OEEhjru0azzQc62bUcvfCsk1VndcjC4&e=3D=20 > where the caller of hfs_brec_read() can tell whether the CNID is correct.= But such > change is a matter of preference. >=20 > You can respond with your patch which will be much faster. >=20 Sorry, I am busy with other HFS/HFS+ issues. Thanks, Slava.