From: Thomas Graf <tgraf@suug.ch>
To: jamal <hadi@cyberus.ca>
Cc: Patrick McHardy <kaber@trash.net>,
"David S. Miller" <davem@davemloft.net>,
Herbert Xu <herbert@gondor.apana.org.au>,
netdev@oss.sgi.com
Subject: Re: [RFC] tcf_bind_filter failure handling
Date: Mon, 13 Dec 2004 20:32:28 +0100 [thread overview]
Message-ID: <20041213193228.GG8493@postel.suug.ch> (raw)
In-Reply-To: <1102965823.1075.14.camel@jzny.localdomain>
* jamal <1102965823.1075.14.camel@jzny.localdomain> 2004-12-13 14:23
>
> When/why would binding fail? tcindex is an exception.
> I dont see binding as having any contribution to the error path.
> Additional locking is not advisable. The binding could happen while
> traffic is running.
The binding fails if the class does not exist at the time the classifier
is loaded. The original implementation regarded binding optional to do
the classid -> class lookup only once while loading instead of everytime
classify() returns. tcindex does not do so because it uses the class
field to determine whether a perfect hash bucket is used or not. I
changed it to check classid || police || action because one of them is
definitely defined and enforced as a requirement during validation.
The locking i mentioned was not a spinlock but rather a refcnt++ in the
class intended to be bound later during change, i.e. to ensure a qdisc
destroy rcu callback can't destroy the class while we're about to bind
to it. But since we agree on changing tcindex this is not an issue and
nothing will change.
Sorry for the confusion, my word choice was rather bad for such a
simple issue and produced more confusion than results.
next prev parent reply other threads:[~2004-12-13 19:32 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-04 3:11 request_module while holding rtnl semaphore Patrick McHardy
2004-11-05 23:35 ` Herbert Xu
2004-11-10 0:11 ` David S. Miller
2004-11-10 0:38 ` Patrick McHardy
2004-11-10 1:01 ` Thomas Graf
2004-11-10 1:10 ` Patrick McHardy
2004-11-10 1:22 ` Thomas Graf
2004-11-10 1:29 ` Patrick McHardy
2004-11-10 1:39 ` Thomas Graf
2004-11-10 1:41 ` Herbert Xu
2004-11-10 11:32 ` Thomas Graf
2004-11-10 11:42 ` Herbert Xu
2004-11-10 11:56 ` Thomas Graf
2004-11-10 1:47 ` Patrick McHardy
2004-12-12 17:57 ` Thomas Graf
2004-12-12 18:04 ` Patrick McHardy
2004-12-13 16:53 ` [RFC] tcf_bind_filter failure handling Thomas Graf
2004-12-13 18:11 ` Patrick McHardy
2004-12-13 18:52 ` Thomas Graf
2004-12-13 19:12 ` Patrick McHardy
2004-12-13 19:23 ` jamal
2004-12-13 19:32 ` Thomas Graf [this message]
2004-11-10 1:15 ` request_module while holding rtnl semaphore Herbert Xu
2005-01-11 3:04 ` Patrick McHardy
2005-01-11 9:47 ` Thomas Graf
2005-01-11 21:05 ` Patrick McHardy
2005-01-11 21:47 ` Thomas Graf
2005-01-11 21:50 ` Thomas Graf
2005-01-11 22:18 ` 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=20041213193228.GG8493@postel.suug.ch \
--to=tgraf@suug.ch \
--cc=davem@davemloft.net \
--cc=hadi@cyberus.ca \
--cc=herbert@gondor.apana.org.au \
--cc=kaber@trash.net \
--cc=netdev@oss.sgi.com \
/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).