From: <abirvalg@lavabit.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>, netfilter-devel@vger.kernel.org
Subject: Re: conntrack EILSEQ followed by ENOBUFS
Date: Thu, 13 Oct 2011 14:19:12 +0000 [thread overview]
Message-ID: <20111013141912.60febfa8@wwwwww-701SD> (raw)
In-Reply-To: <20111013110210.GA20533@1984>
On Thu, 13 Oct 2011 13:02:10 +0200
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Thu, Oct 13, 2011 at 12:50:55PM +0000, abirvalg@lavabit.com wrote:
> > Sorry for not being sufficiently specific. Since you showed more interest, I feel empowered to go into further detail.
>
> You're reporting problems, I'm not a wizard, if you don't provide
> details, it's way harder for me to guess what's wrong ;-)
>
> > My app uses libnetfilter_queue. When it NF_ACCEPTs a packet, it immediately goes on to set a mark on the connection of which the ACCEPTed packet is part of. But in order to set the mark on the connection, it first NFCT_Q_GETs that conntrack (because it knows srcIP, destIP, srcPort, destPort, L4proto, L3proto). Once it got the conntrack, it can proceed to set a mark on it using NFCT_Q_UPDATE.
> >
> > I'm hitting EBUSY with NFCT_Q_GET.
> > My impression was that it was ok to hit EBUSY, since I'm making such a heavy use of conntrack table, contantly updating in. Besides I have watch -n 1 'conntrack -L' running in another console. So it's double pressure.
> > It may be beside the point, but apart from this GETing and UPDATEing, I have another thread (that uses a different handle) which every minute or so does NFCT_Q_DUMP (that's 1000+ entries) and the handle's callback then NFCT_Q_DESTROYS (based on the nfmark) approx. 80% of the dump.
>
> There are different situations in which you may hit EBUSY:
>
> For example, if you call NFCT_Q_DUMP after some unconcluded dumping
> (one previous NFCT_Q_DUMP operation that is still on the way).
>
> Regarding threads, it's a bad idea to share conntrack handlers between
> different threads.
>
> As said, I need some code to look at for better helping.
Sorry for not being forthcoming with the code, I forgot that my project has gitweb enabled,
Here is the offending line: (line 1541)
http://leopardflower.git.sourceforge.net/git/gitweb.cgi?p=leopardflower/leopardflower;a=blob;f=lpfw.c;h=a95e80359b5b3c00657d1e695ff273e84e8288d1;hb=8e787ce7e0800c1541b9427e517d14d8ae55e756#l1541
Cheers.
prev parent reply other threads:[~2011-10-13 11:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-10 21:17 conntrack EILSEQ followed by ENOBUFS abirvalg
2011-10-12 16:16 ` Pablo Neira Ayuso
2011-10-13 11:11 ` abirvalg
[not found] ` <20111013111020.60e09065@wwwwww-701SD>
[not found] ` <20111013093014.GB19706@1984>
2011-10-13 12:50 ` abirvalg
2011-10-13 11:02 ` Pablo Neira Ayuso
2011-10-13 14:19 ` abirvalg [this message]
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=20111013141912.60febfa8@wwwwww-701SD \
--to=abirvalg@lavabit.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).