Eric Dumazet | 1 Oct 01:03 2009
Picon

[PATCH] pktgen: Avoid dirtying skb->users when txq is full

Stephen Hemminger a écrit :
> On Tue, 22 Sep 2009 22:49:02 -0700
> Stephen Hemminger <shemminger <at> vyatta.com> wrote:
> 
>> I thought others want to know how to get maximum speed of pktgen.
>>
>> 1. Run nothing else (even X11), just a command line
>> 2. Make sure ethernet flow control is disabled
>>    ethtool -A eth0 autoneg off rx off tx off
>> 3. Make sure clocksource is TSC.  On my old SMP Opteron's
>>    needed to get patch since in 2.6.30 or later, the clock guru's
>>    decided to remove it on all non Intel machines.  Look for patch
>>    than enables "tsc=reliable"
>> 4. Compile Ethernet drivers in, the overhead of the indirect
>>    function call required for modules (or cache footprint),
>>    slows things down.
>> 5. Increase transmit ring size to 1000
>>    ethtool -G eth0 tx 1000
>>

Thanks a lot Stephen.

I did some pktgen session tonight and found one contention on skb->users field
that following patch avoids.

Before patch :
------------------------------------------------------------------------------
   PerfTop:    5187 irqs/sec  kernel:100.0% [100000 cycles],  (all, cpu: 0)
------------------------------------------------------------------------------

(Continue reading)

Joe Perches | 1 Oct 01:09 2009

Re: [PATCH 1/2] net/netfilter/ipvs: Move #define KMSG_COMPONENT to Makefile

On Thu, 2009-10-01 at 00:46 +0200, Jan Engelhardt wrote:
> On Thursday 2009-10-01 00:37, Joe Perches wrote:
> >This centralizes the definition and removes the
> >replicated #defines from all files
> And increases the length of the command line. Not that Linux does not
> support long command lines (in fact, configure often determines huge
> possible values on the max length test), but sometimes, developers
> have to inspect the command lines anyway for bugs, or something. It
> is already pretty long due to all the compiler flags.

Hi Jan.

I think this increased command line length hardly matters.

I think a reasonable complaint might be that it separates
the definition of a macro from the code.  I think it's
similar to the already used KBUILD_MODNAME macro though.

> How about an #include file for the ipvs private things?

It's not just IPVS, this style could be used treewide
without requiring extra #includes.

cheers, Joe

--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Tilman Schmidt | 1 Oct 01:15 2009

capi.c calls receive_buf with interrupts disabled (was: N_PPP_SYNC ldisc BUG: sleeping function called from invalid context)

Jarek Poplawski schrieb:
> Tilman Schmidt wrote, On 09/30/2009 08:55 PM:
[...]
>> - ppp_sync_receive() was called, as the LD's receive_buf method,
>>   via handle_recv_skb() [drivers/isdn/capi/capi.c line 504, inlined]
>>   from handle_minor_recv() [drivers/isdn/capi/capi.c line 519]
>>
>> - handle_minor_recv() was called from capi_recv_message()
>>   [drivers/isdn/capi/capi.c line 656]
>>
>> - capi_recv_message() was called, as the CAPI application's
>>   recv_message method, from recv_handler()
>>   [drivers/isdn/capi/kcapi.c line 268]
>>
>> - recv_handler() is never called directly. It's only scheduled
>>   via the work queue ap->recv_work from capi_ctr_handle_message()
>>   [drivers/isdn/capi/kcapi.c line 349]
>>
>> Even if we don't trust the backtraces, there's not much room for
>> another activation path. So for all I know, the expectation of the
>> tty logic should have been met. The call was indeed processed from
>> a work queue.
>>
>> Why then does mutex_lock() complain?
> 
> Hmm... capi_recv_message() calls handle_minor_recv() under
> spin_lock_irqsave(), doesn't it?

Well spotted. Indeed it does. That explains it, of course.

(Continue reading)

Andrew Morton | 1 Oct 01:19 2009

Re: [PATCH,TRIVIAL] Fix csum_ipv6_magic asm memory clobber

On Thu, 1 Oct 2009 01:01:38 +0200
Samuel Thibault <samuel.thibault <at> ens-lyon.org> wrote:

> Actually it hit Hurd's pfinetv4 when we tried to compile it with
> gcc-4.3 (bogus checksums).

That's important information!  I updated the changelog and added the
Cc:stable, thanks.

Full patch for netdev benefit:

From: Samuel Thibault <samuel.thibault <at> ens-lyon.org>

Just like ip_fast_csum, the assembly snippet in csum_ipv6_magic needs a
memory clobber, as it is only passed the address of the buffer, not a
memory reference to the buffer itself.

This caused failures in Hurd's pfinetv4 when we tried to compile it with
gcc-4.3 (bogus checksums).

Signed-off-by: Samuel Thibault <samuel.thibault <at> ens-lyon.org>
Cc: Ingo Molnar <mingo <at> elte.hu>
Cc: Thomas Gleixner <tglx <at> linutronix.de>
Cc: "H. Peter Anvin" <hpa <at> zytor.com>
Cc: "David S. Miller" <davem <at> davemloft.net>
Cc: Andi Kleen <andi <at> firstfloor.org>
Cc: <stable <at> kernel.org>
Signed-off-by: Andrew Morton <akpm <at> linux-foundation.org>
---

(Continue reading)

David Miller | 1 Oct 01:22 2009
Picon

Re: [PATCH,TRIVIAL] Fix csum_ipv6_magic asm memory clobber

From: Andrew Morton <akpm <at> linux-foundation.org>
Date: Wed, 30 Sep 2009 16:19:39 -0700

> From: Samuel Thibault <samuel.thibault <at> ens-lyon.org>
> 
> Just like ip_fast_csum, the assembly snippet in csum_ipv6_magic needs a
> memory clobber, as it is only passed the address of the buffer, not a
> memory reference to the buffer itself.
> 
> This caused failures in Hurd's pfinetv4 when we tried to compile it with
> gcc-4.3 (bogus checksums).
> 
> Signed-off-by: Samuel Thibault <samuel.thibault <at> ens-lyon.org>
> Signed-off-by: Andrew Morton <akpm <at> linux-foundation.org>

I'm happy to see this go in via the x86 tree, and thus:

Acked-by: David S. Miller <davem <at> davemloft.net>
David Miller | 1 Oct 01:23 2009
Picon

Re: [PATCH] net: Fix sock_wfree() race

From: Eric Dumazet <eric.dumazet <at> gmail.com>
Date: Thu, 24 Sep 2009 22:49:24 +0200

> [PATCH] net: Fix sock_wfree() race
> 
> Commit 2b85a34e911bf483c27cfdd124aeb1605145dc80
> (net: No more expensive sock_hold()/sock_put() on each tx)
> opens a window in sock_wfree() where another cpu
> might free the socket we are working on.
> 
> A fix is to call sk->sk_write_space(sk) while still
> holding a reference on sk.
> 
> 
> Reported-by: Jike Song <albcamus <at> gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet <at> gmail.com>

Applied to net-2.6 and I'll queue this up for -stable.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

David Miller | 1 Oct 01:33 2009
Picon

Re: [PATCH] net: fix NOHZ: local_softirq_pending 08

From: Oliver Hartkopp <oliver@...>
Date: Wed, 30 Sep 2009 20:18:25 +0200

> Socket buffers that are generated and received inside softirqs or from process
> context must not use netif_rx() that's intended to be used from irq context only.
> 
> This patch introduces a new helper function netif_rx_ti(skb) that tests for
> in_interrupt() before invoking netif_rx() or netif_rx_ni().
> 
> It fixes the ratelimited kernel warning
> 
>         NOHZ: local_softirq_pending 08
> 
> in the mac80211 and can subsystems.
> 
> Signed-off-by: Oliver Hartkopp <oliver@...>

I bet all of these code paths can use netif_receive_skb() or
don't need this conditional blob at all.

Looking at some specific cases in this patch:

1) VCAN:  This RX routine is only invoked from the drivers
   ->ndo_start_xmit() handler, and therefore like the loopback
   driver we know that BH's are already disabled and therefore
   it can always use netif_rx() safely.

   Why did you convert this case?

   And if this needs to be converted, why doesn't loopback need
(Continue reading)

David Miller | 1 Oct 01:37 2009
Picon

Re: [PATCH net-next-2.6] be2net: Workaround to fix a bug in Rx Completion processing.

From: Ajit Khaparde <ajitk <at> serverengines.com>
Date: Wed, 30 Sep 2009 14:37:06 +0530

> vtp bit in RX completion descriptor could be wrongly set in
> some skews of BladEngine.  Ignore this  bit if vtm is not set.
> This patch is against the net-next-2.6 tree.
> 
> Signed-off-by: Ajit Khaparde <ajitk <at> serverengines.com>

This doesn't apply.

Until I start taking new feature patches, net-next-2.6 is just
going to be a stale GIT tree based upon Linus's tree at some
point in time long ago.

net-2.6 is far in front of that, and actually since this is a bug
fix you really should be sending me this patch against that.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

David Miller | 1 Oct 01:40 2009
Picon

Re: [PATCH] sit: fix off-by-one in ipip6_tunnel_get_prl

From: Sascha Hlusiak <contact <at> saschahlusiak.de>
Date: Tue, 29 Sep 2009 23:27:05 +0200

> When requesting all prl entries (kprl.addr == INADDR_ANY) and there are
> more prl entries than there is space passed from userspace, the existing
> code would always copy cmax+1 entries, which is more than can be handled.
> 
> This patch makes the kernel copy only exactly cmax entries.
> 
> Signed-off-by: Sascha Hlusiak <contact <at> saschahlusiak.de>
> Acked-By: Fred L. Templin <Fred.L.Templin <at> boeing.com>

Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

David Miller | 1 Oct 01:41 2009
Picon

Re: [PATCH] Phonet: fix mutex imbalance

From: Rémi Denis-Courmont <remi <at> remlab.net>
Date: Tue, 29 Sep 2009 10:16:39 +0300

> From: Rémi Denis-Courmont <remi.denis-courmont <at> nokia.com>
> 
> port_mutex was unlocked twice.
> 
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont <at> nokia.com>

Applied, thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane