Mailing List Archive: iptables: Devel

Locking issue

Index | Next | Previous | View Threaded

abhinavs_iitkgp at yahoo

Aug 16, 2007, 10:54 AM

Post #1 of 4 (731 views)
Permalink

Locking issue

Hi there,

This email is regarding ebtables code i.e. bridge
level filtering framework of netfilter. I have sent
this email to ebtables mailing list also but have not
heard from anyone. Hence, am sending this here too. I
hope i will receive some favorable response.

I am new to ebtables code and looking for some help
related to locking and atomicity. I am interested in
looking into the packets intercepted by ebtables,
extract some information, pass this information to
userspace, wait for userspace response and then pass
the result back to ebtable code.

Everything seemed to be working fine until i
encountered locking issues. In the ebt_do_table code
there is a "read_lock_bh" is used. When i try to wait
inside this code path after sending info to my
userspace tool and before returning NF_ACCEPT or
NF_DROP, either the CPU hangs or i get an error
"schedule while atomic". I tried out different methods
for waiting like "wait_event_timeout" or busy while
loop etc. The problem that I understood is that since
read_lock_bh disables CPU preemption and do
local_bh_disable, if i wait with something that try to
call schedule() I get "schedule while atomic". And, if
i do busy waiting it means am stuck for ever as
preemption is disabled anyways.

It is like chicken and egg problem. I want to wait and
let my userspace process schedule so that I could get
response from it but the code path is atomic so i
cannot schedule my process. After trying out
everything I am clueless as what to do.

Any help in this regard would be appreciated.

Thanks,
Abhinav

Bollywood, fun, friendship, sports and more. You name it, we have it on http://in.groups.yahoo.com

bdschuym at pandora

Aug 16, 2007, 11:11 AM

Post #2 of 4 (677 views)
Permalink

Re: Locking issue [In reply to]

Op do, 16-08-2007 te 18:54 +0100, schreef Abhinav Srivastava:
>
> Hi there,
>
> This email is regarding ebtables code i.e. bridge
> level filtering framework of netfilter. I have sent
> this email to ebtables mailing list also but have not
> heard from anyone. Hence, am sending this here too. I
> hope i will receive some favorable response.
>
> I am new to ebtables code and looking for some help
> related to locking and atomicity. I am interested in
> looking into the packets intercepted by ebtables,
> extract some information, pass this information to
> userspace, wait for userspace response and then pass
> the result back to ebtable code.

What you seek is a QUEUE target as it exists for iptables. Unfortunately
this doesn't yet exist for ebtables. Maybe you can get away with it by
using the ebtables ulog watcher.

cheers,
Bart

abhinavs_iitkgp at yahoo

Aug 16, 2007, 11:27 AM

Post #3 of 4 (675 views)
Permalink

Re: Locking issue [In reply to]

--- Bart De Schuymer <bdschuym [at] pandora> wrote:

> Op do, 16-08-2007 te 18:54 +0100, schreef Abhinav
> Srivastava:
> >
> > Hi there,
> >
> > This email is regarding ebtables code i.e. bridge
> > level filtering framework of netfilter. I have
> sent
> > this email to ebtables mailing list also but have
> not
> > heard from anyone. Hence, am sending this here
> too. I
> > hope i will receive some favorable response.
> >
> > I am new to ebtables code and looking for some
> help
> > related to locking and atomicity. I am interested
> in
> > looking into the packets intercepted by ebtables,
> > extract some information, pass this information to
> > userspace, wait for userspace response and then
> pass
> > the result back to ebtable code.
>
> What you seek is a QUEUE target as it exists for
> iptables. Unfortunately
> this doesn't yet exist for ebtables. Maybe you can
> get away with it by
> using the ebtables ulog watcher.
>
> cheers,
> Bart

Hi Bart,

Thanks a lot for your quick reply. I really
appreciate.

As far as I know about ulog, it just sends the packet
to userspace logging deamon and do not wait for its
reply. Does ulog provide waiting/blocking feature also
that i can use in my code?

In my case, my requirement is to pass some packet
header information to userspace tool and wait for its
reply. During this process kernel code should block
and wait for user response. Once it receives user
response, it can go ahead. Like ulog, I am also using
netlink socket for communication between kernel and
userspace.

Is there anyway I can wait inside that code and let me
userspace tool run so that i could receive response
from it?

Once again thanks for your reply.

Thanks,
Abhinav

5, 50, 500, 5000 - Store N number of mails in your inbox. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html

bdschuym at pandora

Aug 16, 2007, 11:53 AM

Post #4 of 4 (675 views)
Permalink

Re: Locking issue [In reply to]

Op do, 16-08-2007 te 19:27 +0100, schreef Abhinav Srivastava:
> As far as I know about ulog, it just sends the packet
> to userspace logging deamon and do not wait for its
> reply. Does ulog provide waiting/blocking feature also
> that i can use in my code?
>
> In my case, my requirement is to pass some packet
> header information to userspace tool and wait for its
> reply. During this process kernel code should block
> and wait for user response. Once it receives user
> response, it can go ahead. Like ulog, I am also using
> netlink socket for communication between kernel and
> userspace.
>
> Is there anyway I can wait inside that code and let me
> userspace tool run so that i could receive response
> from it?

The kernel code has to process the packets as fast as possible. Ebtables
is executed in a softirq and waiting for userspace isn't something you
should do then (and you can't, as you've noticed). As I already
mentioned, a scheme like iptables' QUEUE target should be what you need.
It queues the packets to userspace and userspace is then responsible for
injecting them back into the stack.
What you currently should be able to do with ebtables is use ulog to
send the packets to userspace and then let userspace send the packets to
the right interface (drop the packet in the ebtables rule).

cheers,
Bart

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads