On Fri, Sep 02, 2011 at 11:09:48PM +0200, Michael Büsch wrote:
> On Fri, 2 Sep 2011 00:55:54 +0200 Luka Perkov wrote:
> > Also in linux-2.6.39.4/kernel/Kconfig.preempt you will see for
> > CONFIG_PREEMPT:
> >
> > Select this if you are building a kernel for a desktop or
> > embedded system with latency requirements in the milliseconds
> > range
> >
> > Because of that I made changes to all kernel config files.
> >
> > Signed-off-by: Luka Perkov < openwrt ->-to->- lukaperkov.net >
>
> Uhm, wait a second.
> What are you actually trying to fix with enabling preemption? I didn't
> really get it by reading your mail.
Kernel oops that I described.
> Some random text in a kernel config file is _not_ a reason to make
> a change with a scope like this one.
> Enabling preemption _does_ have negative effects. For one it increases
> the kernel size. And it also increases the runtime overhead (especially on
> UP).
That is what Florian pointed out also. I rather have those side
effects instead of occasional kernel oops, you?
> And finally, I'm not really convinced that any of the routers/APs
> that OpenWRT supports have "latency requirements in the milliseconds range".
> I'd rather say throughput matters a _lot_ more than a millisecond of latency
> for these devices.
I guess everybody pointed out this part "latency requirements in the
milliseconds range". But nobody reported their results from nmap scan
and said if they see any kind of kernel oops without the changes I
proposed... Come on, all of you have routers with OpenWrt ;)
Florian poited out that "code should be able to work fine with PREEMPT
enabled or not" so I looked what can be fixed/improved. I'll do some
more testing and I'll probaby send upstream patch bellow (inside the
lock we don't need two lines I removed).
CONFIG_PREEMPT must be enabled; don't know what more I can do.
Luka
--- a/net/ipv4/netfilter/nf_nat_core.c
+++ b/net/ipv4/netfilter/nf_nat_core.c
@@ -276,9 +276,9 @@ nf_nat_setup_info(struct nf_conn *ct,
/* nat helper or nfctnetlink also setup binding */
nat = nfct_nat(ct);
- if (!nat) {
+ if (unlikely(!nat)) {
nat = nf_ct_ext_add(ct, NF_CT_EXT_NAT, GFP_ATOMIC);
- if (nat == NULL) {
+ if (unlikely(nat == NULL)) {
pr_debug("failed to add NAT extension\n");
return NF_ACCEPT;
}
@@ -313,16 +313,17 @@ nf_nat_setup_info(struct nf_conn *ct,
}
if (maniptype == IP_NAT_MANIP_SRC) {
- unsigned int srchash;
+ unsigned int h;
- srchash = hash_by_src(net, nf_ct_zone(ct),
- &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
- spin_lock_bh(&nf_nat_lock);
- /* nf_conntrack_alter_reply might re-allocate exntension aera */
+ h = hash_by_src(net, nf_ct_zone(ct),
+ &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
+
+ /* nf_conntrack_alter_reply might re-allocate extension area */
nat = nfct_nat(ct);
nat->ct = ct;
- hlist_add_head_rcu(&nat->bysource,
- &net->ipv4.nat_bysource[srchash]);
+
+ spin_lock_bh(&nf_nat_lock);
+ hlist_add_head_rcu(&nat->bysource, &net->ipv4.nat_bysource[h]);
spin_unlock_bh(&nf_nat_lock);
}
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
