[Click] Linux 2.6.24.7 patch in

[springbo at cs.wisc.edu]

Hi Eddie,

I've attached a workaround to the issue. Unmounting the click filesystem
before rmmoding click does the trick.

I'm not exactly sure what was going on in the failure case. Watching the
use counts showed some wildly unexpected values (when running with 1
thread), such as:
proclikefs: killing dentries
proclikefs: use count 1

proclikefs: done killing super
proclikefs: use count 0

click: stopping router thread pid 2305
click module exiting
proclikefs: use count 18446744073709551615


and:
proclikefs: killing dentries
proclikefs: use count 4

proclikefs: done killing super
proclikefs: use count 3

click: stopping router thread pid 2327
click module exiting
proclikefs: use count 2


Hope this helps,
Kevin



> Hi Eddie,
>
> Thanks for the fixes.
>
> I ran with the previous version of proclikefs.c and still had the same
> problem.
>
> I did a little poking into what is going on:
> *proclikefs_put_super(struct super_block *sb) is returning cleanly.
> *local_dec(&module->ref[cpu].count) in kernel/module.c::module_put is what
> is causing the fault
> *It seems like http://lkml.org/lkml/2007/3/21/332 might have had the same
> problem.
>
> When powering off after the click-uninstall GPF I got a 'Poison
> overwritten' message. I'm not sure if this has to do with the GPF or if
> this is simply a reincarnation of the list_del corruption from a while
> back (https://pdos.csail.mit.edu/pipermail/click/2007-March/005746.html)
>
> Sorry I can't be of more help,
> Kevin
>
>
>
>
>
>> Hi Kevin, thanks very much for checking this out!
>>
>> springbo at cs.wisc.edu wrote:
>>> Thanks Eddie!
>>>
>>> I've run into a couple complications:
>>> 1) It looks like there is a logic error in
>>> Packet::has_network_header().
>>> I've attached a patch.
>>
>> Yep, oops.  has_transport_header() was also wrong; both are fixed.
>>
>>> 2) click-uninstall'ing the kernel module results in a general
>>> protection
>>> fault. My configure string is  "./configure --enable-multithread
>>> --enable-user-multithread --enable-adaptive --enable-intel-cpu
>>> CFLAGS=-g
>>> CXXFLAGS=-g". I am building on an x86_64 machine. The click
>>> configuration
>>> used or the number of threads doesn't seem to affect the problem. See
>>> gpf.log for more information.
>>
>> This is a little worrisome.  I wonder if the problem here was related to
>>
>> http://read.cs.ucla.edu/gitweb?p=click;a=commit;h=f72c997281d970ef6fc1cf94feefc23125c31e20
>>
>> Do you have a version of proclikefs.c as created by the prior patch?  If
>> so,
>> does unloading work with that proclikefs?
>>
>>> 3) I'm getting warnings when click descends into the kernel source
>>> directory to build the module. See warning.log. My guess is that this
>>> is
>>> due to the improved linuxmodule build process.
>>
>> I reenabled the relevant part of Joonwoo's patch.
>>
>>> Polling seems to be working with the e1000-7.6.15.5 driver.
>>
>> Cool!
>>
>> Eddie
>>
>>
>>> Thanks again,
>>> Kevin Springborn
>>>
>>>
>>>
>>>
>>>> Hi all,
>>>>
>>>> Click has been updated with the patch for Linux 2.6.24.7 support; and
>>>> the
>>>> Linux 2.6.24.7 patch has been checked into the Click repository.
>>>> Please
>>>> let
>>>> us know if all of this works.  I would love to hear working or not
>>>> working
>>>> reports from users.
>>>>
>>>> Thanks very much to, especially, Adam Greenhalgh, Joonwoo Park, and
>>>> Nemean
>>>> Networks for putting together this patch.
>>>>
>>>> Thanks,
>>>> Eddie
>>>> _______________________________________________
>>>> click mailing list
>>>> click at amsterdam.lcs.mit.edu
>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unload.patch
Type: text/x-patch
Size: 1164 bytes
Desc: not available
Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20081030/8db8e45a/attachment.bin