From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.parknet.co.jp (mail.parknet.co.jp [210.171.160.6]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A5BB03EA7B; Wed, 13 Mar 2024 11:06:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.171.160.6 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710328012; cv=none; b=QwcIrrWg46KQeU8grUJMDqGF9+amZUEOFvAwbdgEI44Z/oS+sLO+/SgM4IH+q0x4ZDz3l8WBIcA/L6bzocHcBNG8a+m46O9Qq7eEhLophGTvCe/EDsQMuwy/QcqwDtCAXUhbosdylQeYQ649FjOeQQ863nJJdUXbgV4yMzvd7XY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710328012; c=relaxed/simple; bh=QUK/mXJR9TF8U4K49/iweWEftEMp+8kuzVs1kUkVfQ0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=cGelar/KQbuQ9Yhch2BtPOplFzGLp/c2Lf1b4JNjPDUekxxU5Fg5k0MXGUl8qk4xSWtRucigKLeysTbMV18rAOm5D/hXElz8oGfdlWWfEFnIiJtQLihRk7lkYPDiw/c4+Ssb+s4Sjkhfl9cSgOmNM89rgWb3pUey3Nf7KGKlnKU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=mail.parknet.co.jp; spf=pass smtp.mailfrom=parknet.co.jp; arc=none smtp.client-ip=210.171.160.6 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=mail.parknet.co.jp Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=parknet.co.jp Received: from ibmpc.myhome.or.jp (server.parknet.ne.jp [210.171.168.39]) by mail.parknet.co.jp (Postfix) with ESMTPSA id 6A780205DB9A; Wed, 13 Mar 2024 20:06:48 +0900 (JST) Received: from devron.myhome.or.jp (foobar@devron.myhome.or.jp [192.168.0.3]) by ibmpc.myhome.or.jp (8.18.1/8.18.1/Debian-1) with ESMTPS id 42DB6gvD219176 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 13 Mar 2024 20:06:43 +0900 Received: from devron.myhome.or.jp (foobar@localhost [127.0.0.1]) by devron.myhome.or.jp (8.18.1/8.18.1/Debian-1) with ESMTPS id 42DB6gQj1312073 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 13 Mar 2024 20:06:42 +0900 Received: (from hirofumi@localhost) by devron.myhome.or.jp (8.18.1/8.18.1/Submit) id 42DB6fSW1312070; Wed, 13 Mar 2024 20:06:41 +0900 From: OGAWA Hirofumi To: Thadeu Lima de Souza Cascardo Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Gwendal Grignou , dlunev@chromium.org Subject: Re: [PATCH] fat: ignore .. subdir and always add a link to dirs In-Reply-To: (Thadeu Lima de Souza Cascardo's message of "Wed, 13 Mar 2024 05:41:32 -0300") References: <87v86fnz2o.fsf@mail.parknet.co.jp> <87le75s1fg.fsf@mail.parknet.co.jp> <87h6hek50l.fsf@mail.parknet.co.jp> <87cys2jfop.fsf@mail.parknet.co.jp> <878r2mk14a.fsf@mail.parknet.co.jp> Date: Wed, 13 Mar 2024 20:06:41 +0900 Message-ID: <874jdajsqm.fsf@mail.parknet.co.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Thadeu Lima de Souza Cascardo writes: >> So you break the mkdir/rmdir link counting, isn't it? >> > > It is off by one on those images with directories without ".." subdir. > Otherwise, everything else works fine. mkdir/rmdir inside such directories work > without any issues as rmdir that same directory. mkdir() increase link count, rmdir decrease link count. Your change set a dir link count always 2? So if there are 3 normal subdirs, and rmdir all those normal dirs, link count underflow. Thanks. > If, on the other hand, we left everything as is and only skipped the > validation, such directories would be created with a link count of 0. Then, > doing a mkdir inside them would crash the kernel with a BUG as we cannot > increment the link count of an inode with 0 links. > > So the idea of the fix here is that, independently of the existence of "..", > the link count will always be at least 1. -- OGAWA Hirofumi