[OpenAFS] tasklist_lock undefined Linux 2.6.18, OpenAFS 1.4.2

[Peter N. Schweitzer]

Jeffrey Hutzelman wrote:
> On Friday, October 27, 2006 08:02:07 PM +0200 Stefaan 
> <stefaan.deroeck@gmail.com> wrote:
> 
>> On 10/24/06, Peter N. Schweitzer <pschweitzer@usgs.gov> wrote:
>>>
>>> Yes, I didn't mean to be unclear.  The problem I'm having is with a
>>> 2.6.18 system building 1.4.2.
>>
>> I can confirm this.  amd64 box, linux vanilla 2.6.18, openafs 1.4.2,
>> both from their original sources
>> It does build perfectly, but afterwards
>> bubbles ~ # depmod -e -a -F /usr/src/linux-2.6.18/System.map 2.6.18
>> WARNING: /lib/modules/2.6.18/fs/openafs/libafs.ko needs unknown symbol
>> tasklist_lock
>> it seems that the module has an unresolved symbol.
>>
>> I have the impression that the developers believe this is fixed. Can
>> there be something both Peter and I are doing wrong such that the fix
>> is ineffective? Or is something else missing?
> 
> Well, the patch I sent to the list should have made the problem go away 
> for the original poster, but was incomplete and never meant to be 
> applied in that form.  The gatekeepers cleaned it up before committing, 
> but there is one case that was missed, which only affects amd64.
> 
> What I'm about to suggest isn't the "right" fix; in particular, it will 
> probably break syscall table scanning on older kernel versions.  But it 
> should make your module load and work.
> 
> Go into src/afs/LINUX/osi_probe.c, and look for a line like this:
> 
>    (unsigned long)(&tasklist_lock) - 0x30000,
> 
> Remove the "- 0x30000" and the unresolved symbol reference should go away.

I don't mean to be a pain, but this cannot possibly solve an unresolved
external reference.  The key point is that tasklist_lock is defined as
extern rwlock_t and it isn't present in the vanilla 2.6.18 kernel as
I've compiled it.  I can believe that there's some kernel config switch
that I need to set in order to make the symbol public, but I don't see
what that is; I've tried a variety of kernel config changes to no avail.

I do also wish to emphasize that this is not an AMD64 system, it's an x86-32.

Peter
-- 
Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192)
(703) 648-6533  FAX: (703) 648-6252  email: pschweitzer@usgs.gov
<http://geology.usgs.gov/peter/>