linux-kernel - Re: [PATCH v5 7/8] fat (exportfs): rebuild directory-inode if fat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKYAXd9OhKDh5r6O=ACyDez1B2S=DB0Eo2-cSNuM1vaURmFNoQ@mail.gmail.com>
Date:	Fri, 21 Dec 2012 14:08:22 +0900
From:	Namjae Jeon <linkinjeon@...il.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Namjae Jeon <namjae.jeon@...sung.com>,
	Ravishankar N <ravi.n1@...sung.com>,
	Amit Sahrawat <a.sahrawat@...sung.com>
Subject: Re: [PATCH v5 7/8] fat (exportfs): rebuild directory-inode if
 fat_dget() fails

2012/12/21, Namjae Jeon <linkinjeon@...il.com>:
> 2012/12/20, OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>:
>> Namjae Jeon <linkinjeon@...il.com> writes:
>>
>>>> Okay, We will check how we can consolidate the 2 paths to avoid any
>>>> issue.
>>> Hi OGAWA.
>>>
>>> On checking fat_search_long() logic, it is observed that it performs
>>> name based lookup of the entries in a given directory.
>>> In fat_get_parent(), we do not have such information to use the
>>> existing API to reconstruct the  parent inode.
>>> Could you give me some hint or guide to consolidate smoothly
>>> fat_search_long and current traverse_logic ?
>>
>> Hm, start with copy of fat_search_long() and refactoring it. With it, we
>> will be able to avoid the fixed bugs.
>>
>> After that, we might be able to merge those somehow. Well, I'm not
>> pretty sure without doing it actually though.
Hi OGAWA.

When we checked to merge it with fat_search_long, we really did not
find any possibility of code reusing for fat_traverse_cluster.
It will not be proper. In case of fat_search_long()-> it is performing
a name based lookup in a particular directory.
While for reconnection with parent from NFS, we do not have the name
of the parent directory. We are relying on ‘i_pos’ on disk position of
directory entry.
So, on first request for lookup for “..” (i.e if we call
fat_search_long(child_dir->d_inode, MSDOS_DOTDOT,2,slot_info) it will
return the directory entry for “..” itself.  From this entry we can
read the “log start” which is the starting cluster of the parent
directory, but instead we need the “directory entry” where this is
stored.
So, from this level we need to go further one level up and read the
parent ->parent-> cluster. After reading that cluster, we need to do a
lookup of the “required ipos” in this directory block.
i.e., if the path is A/B/C and we call the get_parent() from ‘C’. We
need to read the directory block contents of ‘A’ and from those
‘directory entries' compare the log_start with the log_start value of
B, which was obtained by doing a lookup “..” in C.
So, Instead of it, we suggest we fix the “infinite-loop” condition in
fat_traverse_logic and retain the code.
of course, we will test it with corrupted FATfs.
Please share your thoughts on this.

Thanks.
>>
>> Thanks.
>> --
>> OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/