Re: Slow DOWN, please!!!
From: david
Date: Thu May 01 2008 - 01:17:59 EST
On Thu, 1 May 2008, Al Viro wrote:
FWIW, after the last month's flamefests I decided to actually do something
about review density of code in the areas I'm theoretically responsible
for. Namely, do systematic review of core data structure handling (starting
with the place where most of the codepaths get into VFS - descriptor tables
and struct file), doing both blow-by-blow writeup on how that sort of things
is done and documentation of the life cycle/locking rules/assertions made
by code/etc. I made one bad mistake that held the things back for quite
a while - sending heads-up for one of the worse bugs found in process to
never-sufficiently-damned vendor-sec. The last time I'm doing that, TYVM...
Anyway, I'm going to get the notes on that stuff in order and put them in
the open. I really hope that other folks will join the fun afterwards.
The goal is to get a coherent braindump that would be sufficient for
people new to the area wanting to understand and review VFS-related code -
both in the tree and in new patches.
thank you, the lack of good documentation on the intent of the code has
been a significant barrier for new people. it's (relativly) easy for a
good programmer to look at the code and figure out how it does things, a
bit harder to figure out what it does, but why it does it (and what it was
actually _intended_ to do) is very hard to track down
files_struct/fdtable handling is mostly dealt with, struct file is only
partially done - unfortunately, struct file_lock has to be dealt with
before that and it's a (predictable) nightmare. On the other end of
things, fs_struct is not really started, vfsmount review is partially
done, dentry/superblock/inode not even touched.
Even with what little had been covered... well, let's just say that it
caught quite a few fun turds. With typical age around 3-4 years. And
VFS is not the messiest part of the tree...
it may not be the messiest part of the tree, but it's definantly one of
the hardest to figure out the intent of.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/