[OpenAFS-devel] Fully Functional Client on Linux 2.6

[Jack Neely]

On Sat, Jul 03, 2004 at 05:08:30PM -0400, Jeffrey Hutzelman wrote:
> 
> 
> On Friday, July 02, 2004 15:33:27 -0400 Jack Neely <jjneely@pams.ncsu.edu> 
> wrote:
> 
> >Folks,
> >
> >I have a fully functional OpenAFS client on Linux 2.6, well, at least
> >the current Fedora Core 2 kernels.  I decided to document NCSU's OpenAFS
> >packages a bit.  That includes this information and is at:
> >
> >    http://linux.ncsu.edu/projects/openafs-rpms/
> >
> >You'll need to have both kernel and kernel-smp packages installed to
> >build the RPM from there.
> >
> >The current set of patches against yesterday's CVS (pretty much 1.3.65)
> >are attached.
> 
> Ew Ew Ew.
> This smacks of "this is what I did to get it to compile for me, and never 
> mind if it is stable, correct, or will work for anyone else."

Did I say it was "stable" or "correct?"  Did I proclaim this production
code that should work for everyone?  No.  In fact, yes this is what I
did to get it to compile for me.

I was attempting to be helpful by sharing what I did.  I was hoping that
this might spur development, ideas, and maybe be useful in some limited
way to some one else.

> 
> 
> No, it's not OK to assume any chunk of memory containing 222 kernel-text 
> addresses is the system call table.  That's prone to both false positives 
> (finding a chunk of memory that happens to meet that but is not the syscall 
> table) and false negatives (some other module is evil like us and has 
> hooked a syscall).  The technique presented by haba and jimmy at the 
> workshop last week is much more palatable.
> 

No more OK than some of the other methods I've seen to hook the
sys_call_table.  If you will allow,

    WARNING: THIS CODE IS EVIL AND BROKEN.  IT IS GARUNTEED TO EAT
    YOUR BRANE AND YOUR KERNEL!  IT CRASHES MY MACHINES.  IT WRECKS
    MY KERNEL!

:-)

Seriously, the Arla codebase has quite an extensive routine for checking
to see if the pointer found is valid.  Some of its techniques are on my
todo list to make it into this patch.

> 
> No, it's not OK to rip out configure tests because they don't do the right 
> thing for you.  If your kernel has syscalls.h and you want to add a test 
> for that and include it if it's there, fine.  But add a _new_ test, don't 
> rip out the test for syscall.h which was put there for a reason.
> 
> And yes, sock_create having 5 arguments doesn't correlate with 
> LINUX_KERNEL_IS_SELINUX.  But the solution is not to rip out the 
> conditional, but to replace it with something that uses the correct test. 
> Like it or not, there are a lot of FC2 users out there with kernels that 
> _do_ have this "feature", and we need to support them.
> 

Honestly, I don't know autoconf.  Its not something I've put much effort
into learning.  Mostly because its not trivial and I'm a busy person.

As far as the "syscall.h" issue.  I don't have that file in my 2.4
kernel includes.  I do have "syscalls.h" in my 2.6 sources.  I thought
that it might be a typo.

Also, I do believe its been stated that the only FC2 kernels that have
the sock_create() function with to many arguments are the kernels in FC2
that OpenAFS wont compile for anyway.  I'd vote for its removal in that
case.

> 
> IMHO none of these patches are in any condition to be incorporated into the 
> openafs head without reworking to prevent breaking it in cases where it 
> works correctly now.
> 

I was more interested in the feedback.  

Jack Neely


> -- Jeff
> 

-- 
Jack Neely <slack@quackmaster.net>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89