information about kernel locking issue - some other detail

information about kernel locking issue - some other detail

[Giacomo S.]

Sorry, i did not specify an important detail:

this function is invoked by a series of other functions, the first of those
 is hooked
tol the netfilter hooks.

So, depending on the 'direction' of the flow (input, output, fwd), we are
in user context (for output) or soft interrupt (in, fwd).

>>

Sorry, i forgot to explain better the reason why i used _bh version:

in output hook the function should be running in user context.
So it might be interrupted by softirq.

I thought about using _irq version because hardware interrupts, such as
those who could appear when disconnecting an ethernet cable, could
interrupt my routine, which could be in softirq context or user context
(output). Then they would change the data and when my routine restarted 
execution, it would look for an empty pointer.
I thought that read_lock() was enough, but could read_lock() protect about
writings in hard irq context?

Am i wrong?
Any suggestions?

Subject: information about kernel locking issue
Date: 13:55, sabato 1 luglio 2006
From: "Giacomo S." <delleceste@gmail.com>
To: netfilter-devel@lists.netfilter.org

Good morning.

Some time ago i wrote a module in kernel space which does some filtering.

While running `dhclient eth0'  and plugging/unplugging the ethernet cable
from the network card, kernel freezed saying the culprit was the following
function (EIP is at get_ifaddr_by_name() ) :

/* returns in *addr the internet address having the name ifname */
int get_ifaddr_by_name(const char *ifname, __u32 * addr)
{
       struct net_device *pnet_device;
       struct in_device *pin_device;

       read_lock_bh(&dev_base_lock);
       pnet_device = dev_base;
       while (pnet_device != NULL)
         {
                 if ((netif_running(pnet_device))
                     && (pnet_device->ip_ptr != NULL)
                     && (strcmp(pnet_device->name, ifname) == 0))
                   {
                           pin_device =
                               (struct in_device *) pnet_device->ip_ptr;
                           /* ifa_local: ifa_address is the remote point in
ppp */
                           *addr = (pin_device->ifa_list->ifa_local);
                           read_unlock_bh(&dev_base_lock);
                           return 1;
                   }
                pnet_device = pnet_device->next;
         }
         read_unlock_bh(&dev_base_lock);
       return -1;              /* address not found! */
}

What could be wrong?
I think the problem is that read_lock_bh is not correct, perhaps
i would need read_lock_irq instead??

Can anyone suggest if i am right.

Thanks a lot

Giacomo.
--
Giacomo S.

www.giacomos.it

Re: information about kernel locking issue - some other detail

[Patrick McHardy]

Giacomo S. wrote:
> 
> 
> Sorry, i did not specify an important detail:
> 
> this function is invoked by a series of other functions, the first of those
>  is hooked
> tol the netfilter hooks.

Please, once is enough :) But you still missed the most important
information, what happens _exactly_? Crash because of invalid memory
reference, deadlock, ... ?