On Wed, Mar 13, 2024 at 08:06:41PM +0900, OGAWA Hirofumi wrote:
> Thadeu Lima de Souza Cascardo <cascardo@xxxxxxxxxx> 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.
>
No. The main change is as follows:
int fat_subdirs(struct inode *dir)
{
[...]
int count = 0;
[...]
- if (de->attr & ATTR_DIR)
+ if (de->attr & ATTR_DIR &&
+ strncmp(de->name, MSDOS_DOTDOT, MSDOS_NAME))
count++;
[...]
return count;
}
int fat_fill_inode(struct inode *inode, struct msdos_dir_entry *de)
{
[...]
if ((de->attr & ATTR_DIR) && !IS_FREE(de->name)) {
[...]
- set_nlink(inode, fat_subdirs(inode));
+ set_nlink(inode, fat_subdirs(inode) + 1);
[...]
}
That is, when first instatiating a directory inode, its link count was set to
the number of subdirs it had, including "." and "..". Now it is set to 1 + the
number of subdirs it has ignoring "..".
mkdir and rmdir still increment and decrement the parent directory link count.
Cascardo.
> > 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 <hirofumi@xxxxxxxxxxxxxxxxxx>
