All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Giacomo S." <delleceste@gmail.com>
To: netfilter-devel@lists.netfilter.org
Subject: information about kernel locking issue - some other detail
Date: Sun, 2 Jul 2006 10:22:22 +0200	[thread overview]
Message-ID: <200607021022.22822.delleceste@gmail.com> (raw)




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

             reply	other threads:[~2006-07-02  8:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-02  8:22 Giacomo S. [this message]
2006-07-03 18:12 ` information about kernel locking issue - some other detail Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200607021022.22822.delleceste@gmail.com \
    --to=delleceste@gmail.com \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.