On Thu, Sep 29, 2005 at 12:44:05PM -0600, Patrick Walsh wrote:
> 	I finally made some time to upgrade coda from 6.0.11 to 6.0.12 and the
> kernel module from 6.1 to 6.2.   
> 
> 	I'm building the 6.2 version of the coda module against a Redhat AS3
> kernel (a patched 2.4.21 kernel).  upcall.c has some new functions:
> block_signals and unblock_signals.  These make use of
> &current->sigmask_lock.  For some reason that I can't make out, redhat
> has patched sigmask_lock out of the kernel.  It is replaced with
> sighand->siglock.  Patching upcall.c to change each occurrence got me to
> the next stumbling block.

Interesting, I've just checked the closest copies I have locally (2.4.20
and 2.4.22-pre5) and both use current->sigmask_lock.

I've seen the sighand->siglock before, maybe it is a 2.6 patch they
backported. Right, the code in the linux2.6 kernel module is using
sighand->siglock and calls recalc_sigpending without arguments.

> 	upcall.c:672: structure has no member named `uc_posttime'
> 
> 	This line refers to the upc_req structure, which doesn't have
> uc_posttime.  
>
> 	It seemed to me (and please check me on this) that uc_posttime was only
> ever used in a debug function.  So I deleted all references to it.  And
> that got me to the next problem.
 
Oops, yeah that one is gone. Not sure how it sneaked in there, I must
have done my test build on tree that still had some uncommmitted
changes. I'll try to find out which tree it is, maybe there are some
other things missing as well.

> upcall.c: In function `block_signals':
> upcall.c:642: too many arguments to function
> `recalc_sigpending_Rfb6af58d'
> upcall.c: In function `unblock_signals':
> upcall.c:650: too many arguments to function
> `recalc_sigpending_Rfb6af58d'

Those are related to the signal handling changes as well.

> upcall.c: In function `coda_upcall':
> upcall.c:791: too many arguments to function `coda_waitfor_upcall'

And this seems to again indicate that I did my test build from a 'dirty
tree'.

> 	To fix the second error I changed this line:
> 
> runtime = coda_waitfor_upcall(req, vcommp);
> 
> 	to
> 
> runtime = coda_waitfor_upcall(req);

That is the correct change.

> 	I've attached the patch file that I needed to get everything to build.
> I've also attached the spec file I used to create an rpm.  I haven't
> installed or tested the rpm yet pending word on the my patches.

I have tried a build and got a lot of gcc4 errors/warnings. A pretty big
one is in linux2.4/psdev.c, attached the patch. If I can find the
development tree that might have some uncommitted changes I will have a
better idea of how correct this linux2.4 kernel module is.

Ok, it seems to be all centered around the following merge,

    http://www.coda.cs.cmu.edu/cgi-bin/gitweb.cgi?p=linux-coda.git;a=commit;h=b0a1776525006dcce6b291c083ad8418450df95b

It looks like this merged some 'pending 2.4' changes into the CVS tree,
but the couple of commits after that show that I only did some 2.6
stuff. I guess I merged it from a tree that I assumed to be correct.

Looking at the merged changes, it includes the bad list_del calls, the
partial uc_posttime removal, and the introduction of the signal blocking
code. Now I'm getting a bit suspicious of that fput(host_file) change
that was added to file.c. If there was an error, it should be a NULL. I
think this fix really needs to move to another place.

Jan


diff --git a/linux2.4/psdev.c b/linux2.4/psdev.c
--- a/linux2.4/psdev.c
+++ b/linux2.4/psdev.c
@@ -347,7 +347,7 @@ static int coda_psdev_release(struct ino
 	next = lh->next;
 	while ( (lh = next) != &vcp->vc_pending) {
 		next = lh->next;
-		list_del(&lh);
+		list_del(lh);
 		req = list_entry(lh, struct upc_req, uc_chain);
 		/* Async requests need to be freed here */
 		if (req->uc_flags & REQ_ASYNC) {
@@ -364,7 +364,7 @@ static int coda_psdev_release(struct ino
 	CDEBUG(D_PSDEV, "wake up processing clients\n");
 	while ( (lh = next) != &vcp->vc_processing) {
 		next = lh->next;
-		list_del(&lh);
+		list_del(lh);
 		req = list_entry(lh, struct upc_req, uc_chain);
 		req->uc_flags |= REQ_ABORT;
 	        wake_up(&req->uc_sleep);