[OpenAFS-devel] Fully Functional Client on Linux 2.6

[Jeffrey Hutzelman]

On Saturday, July 03, 2004 19:02:24 -0400 Jack Neely 
<jjneely@pams.ncsu.edu> wrote:

> 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.

Fair enough.  You've told us what you did to make it work for you, which is 
useful.  More work needs to be done, by someone, before these changes can 
be committed.  We don't often get patches in that state, and when we do, 
the authors don't always realize it.


>> 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,

> 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.

Actually, at present, they do very little that we don't already do.  One 
thing they do is look for an array of pointers which has the correct 
pattern of entries that all point the same place (not-implemented 
syscalls).  It would probably be somewhat useful for us to do that.

The other thing they do is know that in 2.6, kallsyms_address_to_symbol() 
has been renamed to kallsyms_lookup().  Of course, that's not very 
interesting, since it seems that several vendors have started unexporting 
that, and the stock kernels may follow suit very soon.  After all, it is 
the mission of the Linux kernel developers to make life as hard as possible 
for anyone who maintains code not in the kernel tree.

>> 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.

No, it's not a typo.  If you read the CVS history, you'll see that the 
include was there already, and the configure test was added to deal with 
kernels that didn't have the file.

It would likely not be difficult to duplicate the existing test, and modify 
the copy.



> 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.

I don't have an FC2 machine handy, so I can't say.

But it seems to me that a problem we care about has been at least partially 
solved, and it saying "it's not yet completely solved, so lets rip out and 
throw away the work that's been done so far" is not productive.

Again, it should be pretty easy to do this test correctly.  In fact, I 
suspect there may already be such a patch in the openafs-bugs queue.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA