[Review] Fixes to the VFS layer

Francois Tigeot ftigeot at wolfpond.org
Tue Aug 30 02:09:32 PDT 2011


Thanks for the remarks Alex,

Alex Hornung wrote:
as I said previously on IRC I disagree with this approach to statfs and
hence to your first two patches. You should be using the statfs entry
point and not inspect the statfs structure in the mount point.
For that, you need to simply fix the right thing, which would be the
VOP_STATFS entry of nullfs and make it populate the fields you need as
you expect.
To be honest, I had forgotten about this conversation; I'll try to 
replace the direct struct mount accesses by the use of VOP_STATFS.

That the stat field in the mount point is not populated as you would
like it is *not* a bug and doesn't really need fixing, you should be
using the right approach instead, one that is using the API instead of
raw accesses.
When I tried to use the STATFS function API, it didn't work as expected 
and caused kernel panics.
I now see that this function was not completely implemented for tmpfs.

What is the rationale for not using the statfs information present in 
struct mount ? It was in a very convenient location...

Regarding the other patch, please make sure that you don't break the
initrd infrastructure in the process. Haven't looked in detail at your
patch, but it looks relatively dangerous in assuming where the root
mount is in the mount list.
This is the part where I'm the less sure of what I should be doing. The 
code was copied verbatim from the start_init() function; I assumed it 
was correct in the first place.
I didn't remove it from there; when I tried to I once again got problems 
with an unitialized namecache layer, but this time later in the boot 
process.

Best Regards,

While working on the vfs-quota branch, I found some problems in the existing
kernel VFS code.
The attached patches correspond to local commits I have created to fix them.
I'm not too sure if what I've done is ideal, and I'd like these patches
to be reviewed before pushing them to master (or not).
--
Francois Tigeot




More information about the Submit mailing list