From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) (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 23EEA3EFFA5 for ; Fri, 5 Jun 2026 18:56:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780685820; cv=none; b=YFncDD1wNj2flTIM90ZZIQ740e7+vGTw14X9BqK/zgyB3GVjFE0u3puFXVp6lNOUBlHdfscm7JmpEqZNNSx/cSlV1I5H/l9/+o7kDi8RKS1L6fDiaLFrM7NPfTAOn3i4A2QSeobigSgLu7VV1ZNlbPgJYji1pGQra+2jKpgvWnQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780685820; c=relaxed/simple; bh=cWOgdHgnWoXFmAf0rQrIS7t4vDecNJPqnyI1dCrh5Hc=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=u/C64hbWo9SCDAc9eNSzH1EM7XrdVRFMdr+onSpsSjYhDDl2VjJOo0yDWxSPtyy3QuTI/hu2UZVtJ6m9kNlVAecYaZrZxaHqqVCIObkD/oPaEoU+xVoOlkm5O/QQL70SNJwpSXe7vpgjMhBpZ/jXZpZkqy4qpTcDzoQ+T949xzI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=dubeyko.com; spf=pass smtp.mailfrom=dubeyko.com; dkim=pass (2048-bit key) header.d=dubeyko-com.20251104.gappssmtp.com header.i=@dubeyko-com.20251104.gappssmtp.com header.b=yezrXtQg; arc=none smtp.client-ip=209.85.128.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=dubeyko.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=dubeyko.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=dubeyko-com.20251104.gappssmtp.com header.i=@dubeyko-com.20251104.gappssmtp.com header.b="yezrXtQg" Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-7e2f3646c10so27811197b3.0 for ; Fri, 05 Jun 2026 11:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dubeyko-com.20251104.gappssmtp.com; s=20251104; t=1780685818; x=1781290618; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to; bh=cWOgdHgnWoXFmAf0rQrIS7t4vDecNJPqnyI1dCrh5Hc=; b=yezrXtQge00tDPeIPS2hDyxfzQ4KrhXhBrkqXr967z6XFpUiyUMY3CyVplhFWiuhc4 3fy6T331slvaeL3rFMCT+xVWkS6pXmdyTNWy5fsnAZt3ktjyPhUEFEPMhlfyalw1PyOl xg5uQkSPMvAPRPDOnPWD/p2fo2hN7lRNjK/twlLHhdvu6NB+Z0vDGvVXtuoAxgn5BD9Y E+ijqa+8IMZb888Rtx4CQSU+5ZanaXeS8JUzo22aUiTTNrUMcQHTj1YZkJfiAM2Oln9Q +LQB0PWLLVPW3Dr5i3EKclQKC/9QrICVFCg38GQRV9CRHE0GzlFw25UIZuTLSW3/Za42 EXMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780685818; x=1781290618; h=mime-version:user-agent:content-transfer-encoding:autocrypt :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=cWOgdHgnWoXFmAf0rQrIS7t4vDecNJPqnyI1dCrh5Hc=; b=iR+8l7WNf5UEMohiAS8H37grMHv4IqfJXndo3OTEcswhLAq3r/CCqP7DSlR7Mp7ux1 npjSM0+C5SIv/kwZbbDUOl9MrNBLfbKbVZ50NGWDL2oh3QCHhie1UsngUzaO1/3bVE13 NyZNmfKU+U9rmALE4xoeKEAGzm6+2gcNhx+ZaQfH0qxaHSKQEeZnfmLl+iGOgRuwLwO1 7Zqe1e/aN8tZWAtZ224mZeaAwICQshWAJd8nzoo2rqSiUakrPIRCHyXhL7gmcsT/ha9J GvVk3gQrun7CEpBfCt8wzTYtmqvW0016NNZFtfbKNRlVZ+1r+D+SJZJVx5uKA1dV1gsm THJQ== X-Forwarded-Encrypted: i=1; AFNElJ+NBgGvhLvb/OMYDAPn600HmnJr3dmE6Pdhk3ZmVBfBfza/WQGcAoV2EK+vDvHf3q1sH+wjSZddqJVNlOY=@vger.kernel.org X-Gm-Message-State: AOJu0YxbsJxW08Z19YDTdIEl4ft3Vnx0cDPqyNZ6X2C/LBDbxOwiayj/ Fb4qFHl808fdYqOPSV4MKWQU/ozgEBvAPrrv8xUoEoLhs4bf5+2wW1zDv98HGBejePI= X-Gm-Gg: Acq92OFwWQqwRts6twykB1q7ObRp3XCpreZLH8KoZsfCX/7apFGaIdy23c3GnNzUoIf P9+LMcmwQyefdDBzDihjhwNSPgQoYrheSmq/JZ9DNUEDkl+RN/yriKUe180T6PEw/PlC6z5nDXP 97oD95hlfORBSASm9NkrhRw6ZPt1X+Np0iXsBoPvSyB28eAZypCZBYT1aOUB7h4yXULWZASGGNh j+dYKxzhfsi0En3bpMnIBl5LVQnUlc3BfVg1jUV8IqgRe4fIOlFfdPHA8zbyy+RxRzg4j3/9lvr 5BfTJ2HJ923ssW6kOkKF0wM/a0l47dRvIZZnYgTj0SDIvs/4VZg0TzX3VrOrmgN/ypocCMwqwBA IWvMxrTb8DDthdzBXUgAZw5ATn2u9vuzobRrlRZWaAMjUEwc+6oTS1mlsQE697Dizuc5m+2CVUC UcTOP5aCCSXxRT2Rnf8hyVTzqiJzWbjx+9YoKzOEaudTQ8FCt/iiFXCJGVBV3f5YwahHoNEe3RE n9hqDqoFe4rPOdghkewj3yqkYKRo+Q1GyDsIKNSYOmNnKwcLLxXEFrA8EzD9VfiWlzz X-Received: by 2002:a05:690c:6706:b0:7db:bff4:f086 with SMTP id 00721157ae682-7ed0c32cd8amr49940327b3.12.1780685818073; Fri, 05 Jun 2026 11:56:58 -0700 (PDT) Received: from ?IPv6:2600:1700:6476:1430:80ee:99ae:6c1:509d? ([2600:1700:6476:1430:80ee:99ae:6c1:509d]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7ea2167b40bsm53470807b3.17.2026.06.05.11.56.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2026 11:56:57 -0700 (PDT) Message-ID: Subject: Re: [PATCH v2] hfs: prevent MDB and bitmap buffer_head aliasing From: Viacheslav Dubeyko To: Sam Sun Cc: glaubitz@physik.fu-berlin.de, frank.li@vivo.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Fri, 05 Jun 2026 11:56:56 -0700 In-Reply-To: References: <19becc5c5ccd8f22215eb2a1fbc832bed73933f3.camel@dubeyko.com> <20260604180306.18672-1-samsun1006219@gmail.com> <8e4f04261421e7c904eabbf702e5eb66c9e20bd1.camel@dubeyko.com> Autocrypt: addr=slava@dubeyko.com; prefer-encrypt=mutual; keydata=mQINBGgaTLYBEADaJc/WqWTeunGetXyyGJ5Za7b23M/ozuDCWCp+yWUa2GqQKH40dxRIR zshgOmAue7t9RQJU9lxZ4ZHWbi1Hzz85+0omefEdAKFmxTO6+CYV0g/sapU0wPJws3sC2Pbda9/eJ ZcvScAX2n/PlhpTnzJKf3JkHh3nM1ACO3jzSe2/muSQJvqMLG2D71ccekr1RyUh8V+OZdrPtfkDam V6GOT6IvyE+d+55fzmo20nJKecvbyvdikWwZvjjCENsG9qOf3TcCJ9DDYwjyYe1To8b+mQM9nHcxp jUsUuH074BhISFwt99/htZdSgp4csiGeXr8f9BEotRB6+kjMBHaiJ6B7BIlDmlffyR4f3oR/5hxgy dvIxMocqyc03xVyM6tA4ZrshKkwDgZIFEKkx37ec22ZJczNwGywKQW2TGXUTZVbdooiG4tXbRBLxe ga/NTZ52ZdEkSxAUGw/l0y0InTtdDIWvfUT+WXtQcEPRBE6HHhoeFehLzWL/o7w5Hog+0hXhNjqte fzKpI2fWmYzoIb6ueNmE/8sP9fWXo6Av9m8B5hRvF/hVWfEysr/2LSqN+xjt9NEbg8WNRMLy/Y0MS p5fgf9pmGF78waFiBvgZIQNuQnHrM+0BmYOhR0JKoHjt7r5wLyNiKFc8b7xXndyCDYfniO3ljbr0j tXWRGxx4to6FwARAQABtCZWaWFjaGVzbGF2IER1YmV5a28gPHNsYXZhQGR1YmV5a28uY29tPokCVw QTAQoAQQIbAQUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBFXDC2tnzsoLQtrbBDlc2cL fhEB1BQJoGl5PAhkBAAoJEDlc2cLfhEB17DsP/jy/Dx19MtxWOniPqpQf2s65enkDZuMIQ94jSg7B F2qTKIbNR9SmsczjyjC+/J7m7WZRmcqnwFYMOyNfh12aF2WhjT7p5xEAbvfGVYwUpUrg/lcacdT0D Yk61GGc5ZB89OAWHLr0FJjI54bd7kn7E/JRQF4dqNsxU8qcPXQ0wLHxTHUPZu/w5Zu/cO+lQ3H0Pj pSEGaTAh+tBYGSvQ4YPYBcV8+qjTxzeNwkw4ARza8EjTwWKP2jWAfA/ay4VobRfqNQ2zLoo84qDtN Uxe0zPE2wobIXELWkbuW/6hoQFPpMlJWz+mbvVms57NAA1HO8F5c1SLFaJ6dN0AQbxrHi45/cQXla 9hSEOJjxcEnJG/ZmcomYHFneM9K1p1K6HcGajiY2BFWkVet9vuHygkLWXVYZ0lr1paLFR52S7T+cf 6dkxOqu1ZiRegvFoyzBUzlLh/elgp3tWUfG2VmJD3lGpB3m5ZhwQ3rFpK8A7cKzgKjwPp61Me0o9z HX53THoG+QG+o0nnIKK7M8+coToTSyznYoq9C3eKeM/J97x9+h9tbizaeUQvWzQOgG8myUJ5u5Dr4 6tv9KXrOJy0iy/dcyreMYV5lwODaFfOeA4Lbnn5vRn9OjuMg1PFhCi3yMI4lA4umXFw0V2/OI5rgW BQELhfvW6mxkihkl6KLZX8m1zcHitCpWaWFjaGVzbGF2IER1YmV5a28gPFNsYXZhLkR1YmV5a29Aa WJtLmNvbT6JAlQEEwEKAD4WIQRVwwtrZ87KC0La2wQ5XNnC34RAdQUCaBpd7AIbAQUJA8JnAAULCQ gHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRA5XNnC34RAdYjFEACiWBEybMt1xjRbEgaZ3UP5i2bSway DwYDvgWW5EbRP7JcqOcZ2vkJwrK3gsqC3FKpjOPh7ecE0I4vrabH1Qobe2N8B2Y396z24mGnkTBbb 16Uz3PC93nFN1BA0wuOjlr1/oOTy5gBY563vybhnXPfSEUcXRd28jI7z8tRyzXh2tL8ZLdv1u4vQ8 E0O7lVJ55p9yGxbwgb5vXU4T2irqRKLxRvU80rZIXoEM7zLf5r7RaRxgwjTKdu6rYMUOfoyEQQZTD 4Xg9YE/X8pZzcbYFs4IlscyK6cXU0pjwr2ssjearOLLDJ7ygvfOiOuCZL+6zHRunLwq2JH/RmwuLV mWWSbgosZD6c5+wu6DxV15y7zZaR3NFPOR5ErpCFUorKzBO1nA4dwOAbNym9OGkhRgLAyxwpea0V0 ZlStfp0kfVaSZYo7PXd8Bbtyjali0niBjPpEVZdgtVUpBlPr97jBYZ+L5GF3hd6WJFbEYgj+5Af7C UjbX9DHweGQ/tdXWRnJHRzorxzjOS3003ddRnPtQDDN3Z/XzdAZwQAs0RqqXrTeeJrLppFUbAP+HZ TyOLVJcAAlVQROoq8PbM3ZKIaOygjj6Yw0emJi1D9OsN2UKjoe4W185vamFWX4Ba41jmCPrYJWAWH fAMjjkInIPg7RLGs8FiwxfcpkILP0YbVWHiNAabQoVmlhY2hlc2xhdiBEdWJleWtvIDx2ZHViZXlr b0BrZXJuZWwub3JnPokCVAQTAQoAPhYhBFXDC2tnzsoLQtrbBDlc2cLfhEB1BQJoVemuAhsBBQkDw mcABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEDlc2cLfhEB1GRwP/1scX5HO9Sk7dRicLD/fxo ipwEs+UbeA0/TM8OQfdRI4C/tFBYbQCR7lD05dfq8VsYLEyrgeLqP/iRhabLky8LTaEdwoAqPDc/O 9HRffx/faJZqkKc1dZryjqS6b8NExhKOVWmDqN357+Cl/H4hT9wnvjCj1YEqXIxSd/2Pc8+yw/KRC AP7jtRzXHcc/49Lpz/NU5irScusxy2GLKa5o/13jFK3F1fWX1wsOJF8NlTx3rLtBy4GWHITwkBmu8 zI4qcJGp7eudI0l4xmIKKQWanEhVdzBm5UnfyLIa7gQ2T48UbxJlWnMhLxMPrxgtC4Kos1G3zovEy Ep+fJN7D1pwN9aR36jVKvRsX7V4leIDWGzCdfw1FGWkMUfrRwgIl6i3wgqcCP6r9YSWVQYXdmwdMu 1RFLC44iF9340S0hw9+30yGP8TWwd1mm8V/+zsdDAFAoAwisi5QLLkQnEsJSgLzJ9daAsE8KjMthv hUWHdpiUSjyCpigT+KPl9YunZhyrC1jZXERCDPCQVYgaPt+Xbhdjcem/ykv8UVIDAGVXjuk4OW8la nf8SP+uxkTTDKcPHOa5rYRaeNj7T/NClRSd4z6aV3F6pKEJnEGvv/DFMXtSHlbylhyiGKN2Amd0b4 9jg+DW85oNN7q2UYzYuPwkHsFFq5iyF1QggiwYYTpoVXsw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.1 (by Flathub.org) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Fri, 2026-06-05 at 12:00 +0800, Sam Sun wrote: > On Fri, Jun 5, 2026 at 7:52=E2=80=AFAM Viacheslav Dubeyko > wrote: > >=20 > > On Thu, 2026-06-04 at 14:25 -0700, Viacheslav Dubeyko wrote: > > > On Fri, 2026-06-05 at 02:02 +0800, Yue Sun wrote: > > > > On Thu, Jun 4, 2026 at 12:25 AM wrote: > > > > >=20 > > > > > Could you please take a deeper look into my diff that I've > > > > > shared > > > > > with > > > > > you before? I don't see the point to review your suggestion > > > > > if > > > > > you > > > > > completely ignored my diff. From my point of view you > > > > > suggested > > > > > completely the same approach but in more complicated manner. > > > >=20 > > > > You are right. I am sorry for the confusion. > > > >=20 > > > > I should have looked more carefully at your diff and based my > > > > reply > > > > on > > > > it. Adding an HFS-level MDB mutex and avoiding holding mdb_bh > > > > across > > > > the > > > > whole hfs_mdb_commit() path is the right direction. My previous > > > > reply > > > > mixed that with extra cleanups and a separate corrupted-layout > > > > check, > > > > which made it look like I was proposing a different approach. > > > > That > > > > was > > > > my mistake. > > > >=20 > > > > I am not very familiar with HFS internals, so please treat the > > > > following > > > > only as a small suggestion. After re-reading your diff, the > > > > only > > > > detail > > > > I am still unsure about is the HFS_FLG_ALT_MDB_DIRTY path. In > > > > that > > > > path, > > > > hfs_inode_write_fork() gets MDB fields as output buffers: > > > >=20 > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hfs_inode_write_fork(...= , mdb->drXTExtRec, > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 &mdb->drXTFlSize, NULL); > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hfs_inode_write_fork(...= , mdb->drCTExtRec, > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 &mdb->drCTFlSize, NULL); > > >=20 > > >=20 > > > I've started to think that, maybe, the location of these > > > hfs_inode_write_fork() calls is not correct. We are trying to > > > save > > > the > > > current size of Catalog File and Extents Overflow File. OK, we > > > need > > > to > > > update this if size is changed. But we can save the sizes during > > > every > > > call of hfs_mdb_commit(). It's logically incorrect to call these > > > methods in the alternative MDB section because it is the content > > > of > > > primary MDB. I suggest to move these two hfs_inode_write_fork() > > > to > > > primary MDB writing section: > > >=20 > > > lock_buffer(HFS_SB(sb)->mdb_bh); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 /* These parameters may have been modified, so > > > write > > > them back */ > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 mdb->drLsMod =3D hfs_mtime(); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 mdb->drFreeBks =3D cpu_to_be16(HFS_SB(sb)- > > > > free_ablocks); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 mdb->drNxtCNID =3D > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cpu_to_be32((u32)= atomic64_read(&HFS_SB(sb)- > > > > next_id)); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 mdb->drNmFls =3D cpu_to_be16(HFS_SB(sb)->root_files); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 mdb->drNmRtDirs =3D cpu_to_be16(HFS_SB(sb)- > > > > root_dirs); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 mdb->drFilCnt =3D > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cpu_to_be32((u32)= atomic64_read(&HFS_SB(sb)- > > > > file_count)); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 mdb->drDirCnt =3D > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cpu_to_be32((u32)= atomic64_read(&HFS_SB(sb)- > > > > folder_count)); > > >=20 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 hfs_inode_write_fork(HFS_SB(sb)->ext_tree->inode, > > > mdb- > > > > drXTExtRec, > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &mdb->drXTFlSi= ze, NULL); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 hfs_inode_write_fork(HFS_SB(sb)->cat_tree->inode, > > > mdb- > > > > drCTExtRec, > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &mdb->drCTFlSi= ze, NULL); > > >=20 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 /* write MDB to disk */ > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 mark_buffer_dirty(HFS_SB(sb)->mdb_bh); > > > unlock_buffer(HFS_SB(sb)->mdb_bh); > > >=20 > > > In this case, we don;'t need to overlap the locks. What do you > > > think? > > > Sounds like reasonable solution? > > >=20 > > >=20 > >=20 > > Frankly speaking, I don't like this approach of assigning the > > pointer > > on bh->b_data to HFS_SB(sb)->mdb: > >=20 > > data =3D (void *)(__bh->b_data + __offset); > >=20 > > We manipulate by various fields of HFS_SB(sb)->mdb throughout of > > the > > hfs_mdb_commit(). I think that we need to allocate buffer for > > struct > > hfs_mdb *mdb during hfs_mdb_get() (and destroy in hfs_mdb_put()) > > and > > synchronize its content with struct buffer_head *mdb_bh. Otherwise, > > we > > never can resolve the problem of proper locking in > > hfs_mdb_commit(). > > What do you think? > >=20 > > Thanks, > > Slava. > >=20 >=20 > Yes, I agree. Keeping HFS_SB(sb)->mdb as a separate in-memory copy > sounds > cleaner than pointing it directly into mdb_bh->b_data. >=20 > For the immediate deadlock fix, I think moving hfs_inode_write_fork() > into the > primary MDB update section as you suggested sounds like a good > minimal step. The > separate in-memory MDB copy sounds like a larger cleanup that could > follow if > you think that is the right direction. >=20 I don't expect that in-memory MDB copy will require significant cleanup. We already have mdb and alt_mdb pointer that are used in the HFS code. We simply need to change the initialization phase, freeing phase and hfs_mdb_commit() logic. It doesn't sound like a big cleanup. But it will be great to get rid of using the buffer heads for primary and alternative MDB records. This is the more complicated change. But it should be not the part of this patch.=20 Thanks, Slava.