Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] net: qmi_wwan: add Telekom Speedstick LTE II
From: David Miller @ 2012-12-28 23:28 UTC (permalink / raw)
  To: bjorn; +Cc: netdev, linux-usb, tschaefer
In-Reply-To: <1356712255-9488-1-git-send-email-bjorn@mork.no>

From: Bjørn Mork <bjorn@mork.no>
Date: Fri, 28 Dec 2012 17:30:55 +0100

> also known as Alcatel One Touch L100V LTE
> 
> The driver description files gives these names to the vendor specific
> functions on this modem:
> 
>  Application1: VID_1BBB&PID_011E&MI_00
>  Application2: VID_1BBB&PID_011E&MI_01
>  Modem:        VID_1BBB&PID_011E&MI_03
>  Ethernet:     VID_1BBB&PID_011E&MI_04
> 
> Reported-by: Thomas Schäfer <tschaefer@t-online.de>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next] bridge: respect RFC2863 operational state
From: David Miller @ 2012-12-28 23:27 UTC (permalink / raw)
  To: shemminger; +Cc: netdev
In-Reply-To: <20121227222854.6ec132dd@nehalam.linuxnetplumber.net>

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 27 Dec 2012 22:28:54 -0800

>  	spin_lock_bh(&br->lock);
> -	if (netif_running(dev) && netif_carrier_ok(dev)) {
> +	if (netif_running(dev) && netif_oper_up(dev))
>  		if (p->state == BR_STATE_DISABLED)
>  			br_stp_enable_port(p);
>  	} else {

You didn't even try to compile this.

^ permalink raw reply

* Re: [RFC PATCH 0/3] Make rfc3686 template work with asynchronous block ciphers
From: David Miller @ 2012-12-28 23:23 UTC (permalink / raw)
  To: herbert; +Cc: jussi.kivilinna, linux-crypto, steffen.klassert, netdev
In-Reply-To: <20121228224248.GA29448@gondor.apana.org.au>

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 29 Dec 2012 09:42:49 +1100

> On Fri, Dec 28, 2012 at 12:04:48PM +0200, Jussi Kivilinna wrote:
>> I'm not sure how this patchset should be dealt with (should 1st patch go
>> through different tree than 2nd and 3rd?), so therefore it's RFC.
>> 
>> Second patch makes rfc3686 template work with asynchronous block ciphers and
>> third patch changes aesni-intel to use this template. First patch fixed problem
>> in xfrm_algo found with help of 2nd and 3rd patches and without 1st patch
>> 2nd patch breaks aes-ctr with IPSEC.
> 
> I think the easiest way is to have these patches go through Dave's
> tree.

Better yet, Steffen's IPSEC tree :-)

^ permalink raw reply

* Re: [RFC PATCH] ah4/esp4: set transport header correctly for IPsec tunnel mode.
From: David Miller @ 2012-12-28 23:22 UTC (permalink / raw)
  To: roy.qing.li; +Cc: netdev, steffen.klassert
In-Reply-To: <1356682036-25642-1-git-send-email-roy.qing.li@gmail.com>

From: roy.qing.li@gmail.com
Date: Fri, 28 Dec 2012 16:07:16 +0800

> From: Li RongQing <roy.qing.li@gmail.com>
> 
> IPsec tunnel does not set ECN field to CE in inner header when
> the ECN field in the outer header is CE, and the ECN field in
> the inner header is ECT(0) or ECT(1).
> 
> The cause is ipip_hdr() does not return the correct address of
> inner header since skb->transport-header is not the inner header
> after esp_input_done2(), or ah_input().
> 
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>

Likewise I'll leave this to Steffen.

^ permalink raw reply

* Re: [PATCH net-next] xfrm: removes a superfluous check and add a statistic
From: David Miller @ 2012-12-28 23:22 UTC (permalink / raw)
  To: roy.qing.li; +Cc: netdev, steffen.klassert
In-Reply-To: <1356681988-7985-1-git-send-email-roy.qing.li@gmail.com>

From: roy.qing.li@gmail.com
Date: Fri, 28 Dec 2012 16:06:28 +0800

> From: Li RongQing <roy.qing.li@gmail.com>
> 
> Remove the check if x->km.state equal to XFRM_STATE_VALID in
> xfrm_state_check_expire(), which will be done before call
> xfrm_state_check_expire().
> 
> add a LINUX_MIB_XFRMOUTSTATEINVALID statistic to record the
> outbound error due to invalid xfrm state.
> 
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>

I'll let Steffen pick this up when he returns from his holiday
break.

Please CC: him on all IPSEC changes since he is the primary
IPSEC maintainer and is the one who will integrate your IPSEC
patches into his ipsec GIT tree.

^ permalink raw reply

* Re: [patch net-next V3,repost 0/4] net: allow to change carrier from userspace
From: David Miller @ 2012-12-28 23:21 UTC (permalink / raw)
  To: jiri
  Cc: netdev, edumazet, bhutchings, mirqus, shemminger, greearb, fbl,
	john.r.fastabend
In-Reply-To: <1356688180-3549-1-git-send-email-jiri@resnulli.us>

From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 28 Dec 2012 10:49:36 +0100

> This is basically a V3 of a repost of my previous patchset:
> "[patch net-next-2.6 0/2] net: allow to change carrier via sysfs" from Aug 30
> 
> The way net-sysfs stores values changed and this patchset reflects it.
> Also, I exposed carrier via rtnetlink iface.
> 
> So far, only dummy driver uses carrier change ndo. In very near future
> team driver will use that as well.

Series applied, thanks.

^ permalink raw reply

* Re: [RFC PATCH 0/3] Make rfc3686 template work with asynchronous block ciphers
From: Herbert Xu @ 2012-12-28 22:42 UTC (permalink / raw)
  To: Jussi Kivilinna; +Cc: linux-crypto, Steffen Klassert, netdev, David S. Miller
In-Reply-To: <20121228100448.11073.25546.stgit@localhost6.localdomain6>

On Fri, Dec 28, 2012 at 12:04:48PM +0200, Jussi Kivilinna wrote:
> I'm not sure how this patchset should be dealt with (should 1st patch go
> through different tree than 2nd and 3rd?), so therefore it's RFC.
> 
> Second patch makes rfc3686 template work with asynchronous block ciphers and
> third patch changes aesni-intel to use this template. First patch fixed problem
> in xfrm_algo found with help of 2nd and 3rd patches and without 1st patch
> 2nd patch breaks aes-ctr with IPSEC.

I think the easiest way is to have these patches go through Dave's
tree.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* Re: [PATCH 00/12] netfilter fixes for 3.8-rc1
From: David Miller @ 2012-12-28 22:31 UTC (permalink / raw)
  To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1356695571-3305-1-git-send-email-pablo@netfilter.org>

From: pablo@netfilter.org
Date: Fri, 28 Dec 2012 12:52:39 +0100

> git://1984.lsi.us.es/nf master

Pulled, thanks Pablo.

> Have a nice entrance for the new year. Thanks.

Thanks, you too.

^ permalink raw reply

* Re: [PATCH 03/25] sja1000: don't use [delayed_]work_pending()
From: Tejun Heo @ 2012-12-28 21:40 UTC (permalink / raw)
  To: David Miller; +Cc: linux-kernel, wg, netdev
In-Reply-To: <20121222.000111.1132195626602429566.davem@davemloft.net>

On Sat, Dec 22, 2012 at 12:01:11AM -0800, David Miller wrote:
> From: Tejun Heo <tj@kernel.org>
> Date: Fri, 21 Dec 2012 17:56:53 -0800
> 
> > There's no need to test whether a (delayed) work item in pending
> > before queueing, flushing or cancelling it.  Most uses are unnecessary
> > and quite a few of them are buggy.
> > 
> > Remove unnecessary pending tests from sja1000.  Only compile tested.
> > 
> > Signed-off-by: Tejun Heo <tj@kernel.org>
> > Cc: Wolfgang Grandegger <wg@grandegger.com>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: netdev@vger.kernel.org
> > ---
> > Please let me know how this patch should be routed.  I can take it
> > through the workqueue tree if necessary.
> 
> I would suggest just taking it via the workqueue tree, thanks Tejun.

Applied to wq/for-3.9-cleanups w/ your Acked-by added.

Thanks.

-- 
tejun

^ permalink raw reply

* [PATCH net-next] net: filter: return -EINVAL if BPF_S_ANC* operation is not supported
From: Daniel Borkmann @ 2012-12-28 20:50 UTC (permalink / raw)
  To: davem; +Cc: ani, netdev, Daniel Borkmann, Eric Dumazet

Currently, we return -EINVAL for malformed or wrong BPF filters.
However, this is not done for BPF_S_ANC* operations, which makes it
more difficult to detect if it's actually supported or not by the
BPF machine. Therefore, we should also return -EINVAL if K is within
the SKF_AD_OFF universe and the ancillary operation did not match.

Why exactly is it needed? If tools such as libpcap/tcpdump want to
make use of new ancillary operations (like filtering VLAN in kernel
space), there is currently no sane way to test if this feature /
BPF_S_ANC* op is present or not, since no error is returned. This
patch will make life easier for that and allow for a proper usage
for user space applications.

There was concern, if this patch will break userland. Short answer: Yes
and no. Long answer: It will "break" only for code that calls ...

  { BPF_LD | BPF_(W|H|B) | BPF_ABS, 0, 0, <K> },

... where <K> is in [0xfffff000, 0xffffffff] _and_ <K> is *not* an
ancillary. And here comes the BUT: assuming some *old* code will have
such an instruction where <K> is between [0xfffff000, 0xffffffff] and
it doesn't know ancillary operations, then this will give a
non-expected / unwanted behavior as well (since we do not return the
BPF machine with 0 after a failed load_pointer(), which was the case
before introducing ancillary operations, but load sth. into the
accumulator instead, and continue with the next instruction, for
instance). Thus, user space code would already have been broken by
introducing ancillary operations into the BPF machine per se. Code
that does such a direct load, e.g. "load word at packet offset
0xffffffff into accumulator" ("ld [0xffffffff]") is quite broken,
isn't it? The whole assumption of ancillary operations is that no-one
intentionally calls things like "ld [0xffffffff]" and expect this
word to be loaded from such a packet offset. Hence, we can also safely
make use of this feature testing patch and facilitate application
development. Therefore, at least from this patch onwards, we have
*for sure* a check whether current or in future implemented BPF_S_ANC*
ops are supported in the kernel. Patch was tested on x86_64.

(Thanks to Eric for the previous review.)

Cc: Eric Dumazet <eric.dumazet@gmail.com>
Reported-by: Ani Sinha <ani@aristanetworks.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
 net/core/filter.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/net/core/filter.c b/net/core/filter.c
index c23543c..2ead2a9 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -532,6 +532,7 @@ int sk_chk_filter(struct sock_filter *filter, unsigned int flen)
 		[BPF_JMP|BPF_JSET|BPF_X] = BPF_S_JMP_JSET_X,
 	};
 	int pc;
+	bool anc_found;
 
 	if (flen == 0 || flen > BPF_MAXINSNS)
 		return -EINVAL;
@@ -592,8 +593,10 @@ int sk_chk_filter(struct sock_filter *filter, unsigned int flen)
 		case BPF_S_LD_W_ABS:
 		case BPF_S_LD_H_ABS:
 		case BPF_S_LD_B_ABS:
+			anc_found = false;
 #define ANCILLARY(CODE) case SKF_AD_OFF + SKF_AD_##CODE:	\
 				code = BPF_S_ANC_##CODE;	\
+				anc_found = true;		\
 				break
 			switch (ftest->k) {
 			ANCILLARY(PROTOCOL);
@@ -610,6 +613,10 @@ int sk_chk_filter(struct sock_filter *filter, unsigned int flen)
 			ANCILLARY(VLAN_TAG);
 			ANCILLARY(VLAN_TAG_PRESENT);
 			}
+
+			/* ancillary operation unknown or unsupported */
+			if (anc_found == false && ftest->k >= SKF_AD_OFF)
+				return -EINVAL;
 		}
 		ftest->code = code;
 	}
-- 
1.7.11.7

^ permalink raw reply related

* Re: Panic: dma_map_area overflow 66 bytes on 3.7+
From: Eric Dumazet @ 2012-12-28 19:53 UTC (permalink / raw)
  To: Martin Nybo Andersen
  Cc: David S. Miller, Michal Schmidt, linux-kernel, netdev
In-Reply-To: <201212282005.10812.tweek@tweek.dk>

On Fri, 2012-12-28 at 20:05 +0100, Martin Nybo Andersen wrote:
> Hi list,
> 
> Since the release of 3.7 my main computer has been panicking a couple of
> times on both 3.7.0 and 3.7.1 because of a 'dma_map_area overflow xx bytes'.
> 
> Example screen shot:
> http://www.tweek.dk/panic.jpg
> 
> I can reproduce it somewhat easily by visiting http://www.openstreetmap.org/
> and zoom erratically with the scroll-button on the mouse.
> 
> The panic seems to occur on line 229 of arch/x86/kernel/amd_gart_64.c, and
> reverting commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd (r8169: use
> unlimited DMA burst for TX) seems to fix the problem for me (at least I've
> not been able to make it panic as before (yet)).
> 
> 
> lspci -v:
> 00:00.0 Host bridge: Advanced Micro Devices [AMD] nee ATI RS480 Host Bridge (rev 01)
> 00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RS480 PCI-X Root Port
> 00:05.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RS480 PCI Bridge
> 00:12.0 SATA controller: Advanced Micro Devices [AMD] nee ATI SB600 Non-Raid-5 SATA
> 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI0)
> 00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI1)
> 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI2)
> 00:13.3 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI3)
> 00:13.4 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI4)
> 00:13.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB600 USB Controller (EHCI)
> 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller (rev 13)
> 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB600 IDE
> 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA)
> 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB600 PCI to LPC Bridge
> 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> 02:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1)
> 03:07.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01)
> 
> 
> Please tell, if more info is needed.

Seems you have CONFIG_IOMMU_DEBUG, is it really what you want ?

It seems a bit strange we panic in this case
( panic_on_overflow = 1;)

You could try to add iommu=nopanic to your boot command : packet should
be dropped, instead of panic.

config IOMMU_DEBUG
        bool "Enable IOMMU debugging"
        depends on GART_IOMMU && DEBUG_KERNEL
        depends on X86_64
        ---help---
          Force the IOMMU to on even when you have less than 4GB of
          memory and add debugging code. On overflow always panic. And
          allow to enable IOMMU leak tracing. Can be disabled at boot
          time with iommu=noforce. This will also enable scatter gather
          list merging.  Currently not recommended for production
          code. When you use it make sure you have a big enough
          IOMMU/AGP aperture.  Most of the options enabled by this can
          be set more finegrained using the iommu= command line
          options. See Documentation/x86/x86_64/boot-options.txt for more
          details.

^ permalink raw reply

* Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application
From: Eric Dumazet @ 2012-12-28 18:11 UTC (permalink / raw)
  To: Andrew Savchenko; +Cc: netdev
In-Reply-To: <20121223150627.d7ebcf6a.bircoph@gmail.com>

On Sun, 2012-12-23 at 15:06 +0400, Andrew Savchenko wrote:
> Hello,
> 
> the bug has struck again on 3.7.0, see details below.
> 
> On Wed, 12 Dec 2012 12:27:16 +0400 Andrew Savchenko wrote:
> > [...]
> > > > Some driver or protocol stack is messing with skb->truesize, as
> > > > your /proc/net/udp file contains anomalies :
> > > > 
> > > > $ cat /proc/net/udp
> > > >   sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops
> > > > ...
> > > >   323: 074A070A:007B 00000000:0000 07 FFFDF700:00000000 00:00000000 00000000   123        0 254469 2 ffff88003d581880 0
> > > > ...
> > > >   323: 00FCA8C0:007B 00000000:0000 07 FFFFF900:00000000 00:00000000 00000000     0        0 5187 2 ffff880039993880 0
> > > > 
> > > > Its clearly not possible to get tx_queue = 0xFFFDF700 or 0xFFFFF900
> > > > 
> > > > So what drivers handle following IP addresses : 192.168.252.0 , 10.7.74.7  ?
> > > 
> > > 192.168.252.0 is handled by eth0 interface running on Realtek
> > > Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (10ec:8139) NIC.
> > > Kernel driver 8139too. This interface handles multiple subnetworks:
> > > 
> > > # ip addr show eth0
> > > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 
> > > link/ether 00:80:48:30:ca:f3 brd ff:ff:ff:ff:ff:ff
> > > inet 10.51.15.126/25 brd 10.51.15.127 scope global eth0
> > > inet 192.168.252.0/31 scope global eth0
> > > 
> > > 10.7.74.7 is an l2tp connection handled by ppp over l2tp:
> > > CONFIG_PPPOL2TP=y
> > > It is running on top of eth0 described above.
> > > 
> > > # ip addr show ppp0
> > > 65: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 3
> > > link/ppp 
> > > inet 10.7.74.7 peer 10.7.2.18/32 scope global ppp0
> > 
> > I updated kernel on this system to 3.7.0 and udp anomaly is still
> > present:
> > 
> > $ cat /proc/net/udp
> >   sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops             
> >     0: 00000000:06A5 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5326 2 ffff88003dbf0a80 0          
> >     8: 00000000:7EAD 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5157 2 ffff8800398c2000 0          
> >    89: 00000000:90FE 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5101 2 ffff88003dbd3500 0          
> >   160: 0100007F:2745 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4598 2 ffff88003d612700 0          
> >   184: 0100007F:035D 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4774 2 ffff88003d612a80 0          
> >   217: 00000000:857E 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5195 2 ffff8800398c2700 0          
> >   318: 00000000:A9E3 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4782 2 ffff88003d612e00 0          
> >   335: 7E0F330A:01F4 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5303 2 ffff8800398c2e00 0          
> >   348: 00000000:0801 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5186 2 ffff8800398c2380 0          
> >   387: 7E0F330A:DE28 1400320A:06A5 01 00000000:00000000 00:00000000 00000000     0        0 5332 4 ffff88003dbf0e00 0          
> >   400: 010013AC:0035 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4842 2 ffff88003d613880 0          
> >   400: 0100007F:0035 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4841 2 ffff88003d613500 0          
> >   414: 00000000:0043 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5273 2 ffff8800398c2a80 0          
> >   458: 00000000:006F 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4483 2 ffff88003d612000 0          
> >   459: 00000000:0270 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4507 2 ffff88003d612380 0          
> >   466: 00000000:0277 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4802 2 ffff88003d613180 0          
> >   470: 076A070A:007B 00000000:0000 07 FFFF4600:00000000 00:00000000 00000000   123        0 5552 2 ffff880039974380 0          
> >   470: 010213AC:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4986 2 ffff88003dbd3180 0          
> >   470: 010013AC:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4985 2 ffff88003dbd2e00 0          
> >   470: 00FCA8C0:007B 00000000:0000 07 FFFFFB00:00000000 00:00000000 00000000     0        0 4984 2 ffff88003dbd2a80 0          
> >   470: 7E0F330A:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4983 2 ffff88003dbd2700 0          
> >   470: 0100007F:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4982 2 ffff88003dbd2380 0          
> >   470: 00000000:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 4975 2 ffff88003d613c00 0          
> >   484: FF0013AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5316 2 ffff88003dbf0000 0          
> >   484: 010013AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5315 2 ffff88003dbd3880 0          
> >   484: FF0213AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5312 2 ffff8800398c3c00 0          
> >   484: 010213AC:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5311 2 ffff8800398c3880 0          
> >   484: 00000000:0089 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5308 2 ffff8800398c3180 0          
> >   485: FF0013AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5318 2 ffff88003dbf0700 0          
> >   485: 010013AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5317 2 ffff88003dbf0380 0          
> >   485: FF0213AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5314 2 ffff88003dbd3c00 0          
> >   485: 010213AC:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5313 2 ffff88003dbd2000 0          
> >   485: 00000000:008A 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 5309 2 ffff8800398c3500 0
> > 
> > The bug hasn't shown up yet, I'll need to wait for about a week to see
> > if it is reproducible.
> 
> I hit this bug again on uptime 11 days on 3.7.0 vanilla kernel.
> See kernel config, /prot/net/upd, netstat -s and dropwatch logs
> attached to this mail. This bug happens on UDP DNS requests only,
> TCP requests work fine, see dig.log attached.
> 
> Increasing of net.ipv4.udp_mem from
> 24150        32201   48300
> to
> 100000       150000  200000
> helps, but I'm afraid only temporary again.
> 
> Dropwatch data was collected in the following way:
> - dropwatch.bug.* files contain data obtained after bug occurred;
> - dropwatch.*.background files contain background data when no
>   host or dig test was running; this system has active firewall
>   and complicated routing, ipv6 disabled via sysctl, etc, so some
>   drops are normal;
> - dropwatch.*.host.request shows dropped packets recorded during
>   host ya.ru request; of course, during this time some background
>   packets were recorded as well (dropwatch doesn't support filtering
>   at this moment);
> - dropwatch.nobug.* data was collected after the bug was
>   workarounded via net.ipv4.upd_mem as described above.
> 
> As can be seen from dropwatch logs, drop in __udp_queue_rcv_skb+61
> happens only on host request on bug conditions, thus something is
> wrong there.
> 
> Best regards,
> Andrew Savchenko

Thanks a lot !

I see strange drops in dev_hard_start_xmit()

l2tp needs some care.

Please try the following patch, as skb_cow_head() API
doesnt really ease skb->truesize exact tracking anyway, better not mess
with it. 

 net/l2tp/l2tp_core.c |    6 ------
 net/l2tp/l2tp_ppp.c  |    6 ------
 2 files changed, 12 deletions(-)

diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 1a9f372..d77e655 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1123,8 +1123,6 @@ int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb, int hdr_len
 	struct udphdr *uh;
 	struct inet_sock *inet;
 	__wsum csum;
-	int old_headroom;
-	int new_headroom;
 	int headroom;
 	int uhlen = (tunnel->encap == L2TP_ENCAPTYPE_UDP) ? sizeof(struct udphdr) : 0;
 	int udp_len;
@@ -1136,16 +1134,12 @@ int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb, int hdr_len
 	 */
 	headroom = NET_SKB_PAD + sizeof(struct iphdr) +
 		uhlen + hdr_len;
-	old_headroom = skb_headroom(skb);
 	if (skb_cow_head(skb, headroom)) {
 		kfree_skb(skb);
 		return NET_XMIT_DROP;
 	}
 
-	new_headroom = skb_headroom(skb);
 	skb_orphan(skb);
-	skb->truesize += new_headroom - old_headroom;
-
 	/* Setup L2TP header */
 	session->build_header(session, __skb_push(skb, hdr_len));
 
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 286366e..716605c 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -388,8 +388,6 @@ static int pppol2tp_xmit(struct ppp_channel *chan, struct sk_buff *skb)
 	struct l2tp_session *session;
 	struct l2tp_tunnel *tunnel;
 	struct pppol2tp_session *ps;
-	int old_headroom;
-	int new_headroom;
 	int uhlen, headroom;
 
 	if (sock_flag(sk, SOCK_DEAD) || !(sk->sk_state & PPPOX_CONNECTED))
@@ -408,7 +406,6 @@ static int pppol2tp_xmit(struct ppp_channel *chan, struct sk_buff *skb)
 	if (tunnel == NULL)
 		goto abort_put_sess;
 
-	old_headroom = skb_headroom(skb);
 	uhlen = (tunnel->encap == L2TP_ENCAPTYPE_UDP) ? sizeof(struct udphdr) : 0;
 	headroom = NET_SKB_PAD +
 		   sizeof(struct iphdr) + /* IP header */
@@ -418,9 +415,6 @@ static int pppol2tp_xmit(struct ppp_channel *chan, struct sk_buff *skb)
 	if (skb_cow_head(skb, headroom))
 		goto abort_put_sess_tun;
 
-	new_headroom = skb_headroom(skb);
-	skb->truesize += new_headroom - old_headroom;
-
 	/* Setup PPP header */
 	__skb_push(skb, sizeof(ppph));
 	skb->data[0] = ppph[0];

^ permalink raw reply related

* Re: Linux kernel handling of IPv6 temporary addresses
From: Eric Dumazet @ 2012-12-28 17:19 UTC (permalink / raw)
  To: George Kargiotakis; +Cc: netdev
In-Reply-To: <1356627241.30414.1079.camel@edumazet-glaptop>

On Thu, 2012-12-27 at 08:54 -0800, Eric Dumazet wrote:

> We should only rate limit, and not disable forever.
> 

Something like :

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index dd52d51..32d51e2 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1282,7 +1282,7 @@ max_desync_factor - INTEGER
 	Default: 600
 
 regen_max_retry - INTEGER
-	Number of attempts before give up attempting to generate
+	Number of attempts per second before give up attempting to generate
 	valid temporary addresses.
 	Default: 5
 
diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h
index 9356322..8f206cf 100644
--- a/include/net/if_inet6.h
+++ b/include/net/if_inet6.h
@@ -70,6 +70,7 @@ struct inet6_ifaddr {
 	struct list_head	tmp_list;
 	struct inet6_ifaddr	*ifpub;
 	int			regen_count;
+	u32			regen_stamp;
 #endif
 	struct rcu_head		rcu;
 };
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 408cac4a..c41925c 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -980,6 +980,7 @@ static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, struct inet6_ifaddr *i
 	int max_addresses;
 	u32 addr_flags;
 	unsigned long now = jiffies;
+	u32 stamp;
 
 	write_lock(&idev->lock);
 	if (ift) {
@@ -994,18 +995,22 @@ retry:
 	in6_dev_hold(idev);
 	if (idev->cnf.use_tempaddr <= 0) {
 		write_unlock(&idev->lock);
-		pr_info("%s: use_tempaddr is disabled\n", __func__);
+		pr_info_ratelimited("%s: use_tempaddr is disabled\n", __func__);
 		in6_dev_put(idev);
 		ret = -1;
 		goto out;
 	}
 	spin_lock_bh(&ifp->lock);
+	stamp = jiffies / HZ;
+	if (stamp != ifp->regen_stamp) {
+		ifp->regen_stamp = stamp;
+		ifp->regen_count = 0;
+	}
 	if (ifp->regen_count++ >= idev->cnf.regen_max_retry) {
-		idev->cnf.use_tempaddr = -1;	/*XXX*/
 		spin_unlock_bh(&ifp->lock);
 		write_unlock(&idev->lock);
-		pr_warn("%s: regeneration time exceeded - disabled temporary address support\n",
-			__func__);
+		pr_warn_ratelimited("%s: regeneration time exceeded - disabled temporary address support\n",
+				    __func__);
 		in6_dev_put(idev);
 		ret = -1;
 		goto out;

^ permalink raw reply related

* [PATCH] net: qmi_wwan: add Telekom Speedstick LTE II
From: Bjørn Mork @ 2012-12-28 16:30 UTC (permalink / raw)
  To: netdev; +Cc: linux-usb, Thomas Schäfer, Bjørn Mork
In-Reply-To: <50D6CF0A.9020300@t-online.de>

also known as Alcatel One Touch L100V LTE

The driver description files gives these names to the vendor specific
functions on this modem:

 Application1: VID_1BBB&PID_011E&MI_00
 Application2: VID_1BBB&PID_011E&MI_01
 Modem:        VID_1BBB&PID_011E&MI_03
 Ethernet:     VID_1BBB&PID_011E&MI_04

Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
 drivers/net/usb/qmi_wwan.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 91d7cb9..6a1ca50 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -458,6 +458,7 @@ static const struct usb_device_id products[] = {
 	{QMI_FIXED_INTF(0x1199, 0x68a2, 8)},	/* Sierra Wireless MC7710 in QMI mode */
 	{QMI_FIXED_INTF(0x1199, 0x68a2, 19)},	/* Sierra Wireless MC7710 in QMI mode */
 	{QMI_FIXED_INTF(0x1199, 0x901c, 8)},    /* Sierra Wireless EM7700 */
+	{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},	/* Telekom Speedstick LTE II (Alcatel One Touch L100V LTE) */
 
 	/* 4. Gobi 1000 devices */
 	{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},	/* Acer Gobi Modem Device */
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH net-next] net: use per task frag allocator in skb_append_datato_frags
From: Eric Dumazet @ 2012-12-28 16:06 UTC (permalink / raw)
  To: David Miller; +Cc: netdev

From: Eric Dumazet <edumazet@google.com>

Use the new per task frag allocator in skb_append_datato_frags(),
to reduce number of frags and page allocator overhead.

Tested:
 ifconfig lo mtu 16436
 perf record netperf -t UDP_STREAM ; perf report 

before :
 Throughput: 32928 Mbit/s
    51.79%  netperf  [kernel.kallsyms]  [k] copy_user_generic_string
     5.98%  netperf  [kernel.kallsyms]  [k] __alloc_pages_nodemask
     5.58%  netperf  [kernel.kallsyms]  [k] get_page_from_freelist
     5.01%  netperf  [kernel.kallsyms]  [k] __rmqueue
     3.74%  netperf  [kernel.kallsyms]  [k] skb_append_datato_frags
     1.87%  netperf  [kernel.kallsyms]  [k] prep_new_page
     1.42%  netperf  [kernel.kallsyms]  [k] next_zones_zonelist
     1.28%  netperf  [kernel.kallsyms]  [k] __inc_zone_state
     1.26%  netperf  [kernel.kallsyms]  [k] alloc_pages_current
     0.78%  netperf  [kernel.kallsyms]  [k] sock_alloc_send_pskb
     0.74%  netperf  [kernel.kallsyms]  [k] udp_sendmsg
     0.72%  netperf  [kernel.kallsyms]  [k] zone_watermark_ok
     0.68%  netperf  [kernel.kallsyms]  [k] __cpuset_node_allowed_softwall
     0.67%  netperf  [kernel.kallsyms]  [k] fib_table_lookup
     0.60%  netperf  [kernel.kallsyms]  [k] memcpy_fromiovecend
     0.55%  netperf  [kernel.kallsyms]  [k] __udp4_lib_lookup

 after:
  Throughput: 47185 Mbit/s
	61.74%	netperf  [kernel.kallsyms]	[k] copy_user_generic_string
	 2.07%	netperf  [kernel.kallsyms]	[k] prep_new_page
	 1.98%	netperf  [kernel.kallsyms]	[k] skb_append_datato_frags
	 1.02%	netperf  [kernel.kallsyms]	[k] sock_alloc_send_pskb
	 0.97%	netperf  [kernel.kallsyms]	[k] enqueue_task_fair
	 0.97%	netperf  [kernel.kallsyms]	[k] udp_sendmsg
	 0.91%	netperf  [kernel.kallsyms]	[k] __ip_route_output_key
	 0.88%	netperf  [kernel.kallsyms]	[k] __netif_receive_skb
	 0.87%	netperf  [kernel.kallsyms]	[k] fib_table_lookup
	 0.85%	netperf  [kernel.kallsyms]	[k] resched_task
	 0.78%	netperf  [kernel.kallsyms]	[k] __udp4_lib_lookup
	 0.77%	netperf  [kernel.kallsyms]	[k] _raw_spin_lock_irqsave

Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/core/skbuff.c |   43 ++++++++++++++++---------------------------
 1 file changed, 16 insertions(+), 27 deletions(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 3ab989b..ec8737e 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2686,48 +2686,37 @@ int skb_append_datato_frags(struct sock *sk, struct sk_buff *skb,
 					int len, int odd, struct sk_buff *skb),
 			void *from, int length)
 {
-	int frg_cnt = 0;
-	skb_frag_t *frag = NULL;
-	struct page *page = NULL;
-	int copy, left;
+	int frg_cnt = skb_shinfo(skb)->nr_frags;
+	int copy;
 	int offset = 0;
 	int ret;
+	struct page_frag *pfrag = &current->task_frag;
 
 	do {
 		/* Return error if we don't have space for new frag */
-		frg_cnt = skb_shinfo(skb)->nr_frags;
 		if (frg_cnt >= MAX_SKB_FRAGS)
-			return -EFAULT;
-
-		/* allocate a new page for next frag */
-		page = alloc_pages(sk->sk_allocation, 0);
+			return -EMSGSIZE;
 
-		/* If alloc_page fails just return failure and caller will
-		 * free previous allocated pages by doing kfree_skb()
-		 */
-		if (page == NULL)
+		if (!sk_page_frag_refill(sk, pfrag))
 			return -ENOMEM;
 
-		/* initialize the next frag */
-		skb_fill_page_desc(skb, frg_cnt, page, 0, 0);
-		skb->truesize += PAGE_SIZE;
-		atomic_add(PAGE_SIZE, &sk->sk_wmem_alloc);
-
-		/* get the new initialized frag */
-		frg_cnt = skb_shinfo(skb)->nr_frags;
-		frag = &skb_shinfo(skb)->frags[frg_cnt - 1];
-
 		/* copy the user data to page */
-		left = PAGE_SIZE - frag->page_offset;
-		copy = (length > left)? left : length;
+		copy = min_t(int, length, pfrag->size - pfrag->offset);
 
-		ret = getfrag(from, skb_frag_address(frag) + skb_frag_size(frag),
-			    offset, copy, 0, skb);
+		ret = getfrag(from, page_address(pfrag->page) + pfrag->offset,
+			      offset, copy, 0, skb);
 		if (ret < 0)
 			return -EFAULT;
 
 		/* copy was successful so update the size parameters */
-		skb_frag_size_add(frag, copy);
+		skb_fill_page_desc(skb, frg_cnt, pfrag->page, pfrag->offset,
+				   copy);
+		frg_cnt++;
+		pfrag->offset += copy;
+		get_page(pfrag->page);
+
+		skb->truesize += copy;
+		atomic_add(copy, &sk->sk_wmem_alloc);
 		skb->len += copy;
 		skb->data_len += copy;
 		offset += copy;

^ permalink raw reply related

* Re: [PATCH v2 1/1 net-next] NET: FEC: dynamtic check DMA desc buff type
From: Lothar Waßmann @ 2012-12-28 14:45 UTC (permalink / raw)
  To: Frank Li; +Cc: lznuaa, davem, s.hauer, netdev, shawn.guo, linux-arm-kernel
In-Reply-To: <1356676164-10910-1-git-send-email-Frank.Li@freescale.com>

Frank Li writes:
> MX6 and mx28 support enhanced DMA descript buff to support 1588
> ptp. But MX25, MX3x, MX5x can't support enhanced DMA descript buff.
> Check fec type and choose correct DAM descript buff type.
                                    ^^^
s/DAM/DMA/
s/descript/descriptor/g

[...]
> diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> index 0704bca..290f91c 100644
> --- a/drivers/net/ethernet/freescale/fec.c
> +++ b/drivers/net/ethernet/freescale/fec.c
> @@ -76,6 +76,8 @@
>  #define FEC_QUIRK_USE_GASKET		(1 << 2)
>  /* Controller has GBIT support */
>  #define FEC_QUIRK_HAS_GBIT		(1 << 3)
> +/* Controller has extend desc buffer */
> +#define FEC_QUICK_HAS_BUFDESC_EX	(1 << 4)
               ^^^^^
As Sascha has already pointed out, this should be 'QUIRK' rather than
'QUICK' (like in the preceeding lines)!

>  static struct platform_device_id fec_devtype[] = {
>  	{
> @@ -93,7 +95,8 @@ static struct platform_device_id fec_devtype[] = {
>  		.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME,
>  	}, {
>  		.name = "imx6q-fec",
> -		.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT,
> +		.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
> +				FEC_QUICK_HAS_BUFDESC_EX,
                                    ^^^^^
same as above.

[...]
> @@ -1574,6 +1617,8 @@ fec_probe(struct platform_device *pdev)
>  	fep->pdev = pdev;
>  	fep->dev_id = dev_id++;
>  
> +	fep->bufdesc_ex = 0;
> +
>  	if (!fep->hwp) {
>  		ret = -ENOMEM;
>  		goto failed_ioremap;
> @@ -1628,19 +1673,19 @@ fec_probe(struct platform_device *pdev)
>  		goto failed_clk;
>  	}
>  
> -#ifdef CONFIG_FEC_PTP
>  	fep->clk_ptp = devm_clk_get(&pdev->dev, "ptp");
> +	fep->bufdesc_ex =
> +		pdev->id_entry->driver_data & FEC_QUICK_HAS_BUFDESC_EX;
                                                  ^^^^^
same as above.


Lothar Waßmann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________

^ permalink raw reply

* [Patch RFC] ndisc: Fix skb allocation size for link layer options.
From: Stephan Gatzka @ 2012-12-28 13:46 UTC (permalink / raw)
  To: netdev; +Cc: yoshfuji, Stephan Gatzka

Signed-off-by: Stephan Gatzka <stephan.gatzka@gmail.com>
---
 net/ipv6/ndisc.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 6574175..b12b94c 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -392,7 +392,7 @@ static struct sk_buff *ndisc_build_skb(struct net_device *dev,
 
 	len = sizeof(struct icmp6hdr) + (target ? sizeof(*target) : 0);
 	if (llinfo)
-		len += ndisc_opt_addr_space(dev);
+		len += sizeof(struct nd_opt_hdr) + ndisc_opt_addr_space(dev);
 
 	skb = sock_alloc_send_skb(sk,
 				  (MAX_HEADER + sizeof(struct ipv6hdr) +
@@ -1424,7 +1424,8 @@ void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
 			memcpy(ha_buf, neigh->ha, dev->addr_len);
 			read_unlock_bh(&neigh->lock);
 			ha = ha_buf;
-			len += ndisc_opt_addr_space(dev);
+			len += sizeof(struct nd_opt_hdr) +
+				ndisc_opt_addr_space(dev);
 		} else
 			read_unlock_bh(&neigh->lock);
 
-- 
1.7.9.5

^ permalink raw reply related

* Re: [patch net-next V3,repost 0/4] net: allow to change carrier from userspace
From: Flavio Leitner @ 2012-12-28 13:18 UTC (permalink / raw)
  To: Jiri Pirko
  Cc: netdev, davem, edumazet, bhutchings, mirqus, shemminger, greearb,
	john.r.fastabend
In-Reply-To: <1356688180-3549-1-git-send-email-jiri@resnulli.us>

On Fri, Dec 28, 2012 at 10:49:36AM +0100, Jiri Pirko wrote:
> This is basically a V3 of a repost of my previous patchset:
> "[patch net-next-2.6 0/2] net: allow to change carrier via sysfs" from Aug 30
> 
> The way net-sysfs stores values changed and this patchset reflects it.
> Also, I exposed carrier via rtnetlink iface.
> 
> So far, only dummy driver uses carrier change ndo. In very near future
> team driver will use that as well.
> 
> V2->V3:
>  - updated ndo_change_carrier comment by Dan Williams
> 
> V1->v2:
>  - added bigger comment to ndo and also note to operstate.txt documentation
>    stating the clear purpose of this iface
> 
> Jiri Pirko (4):
>   net: add change_carrier netdev op
>   net: allow to change carrier via sysfs
>   rtnl: expose carrier value with possibility to set it
>   dummy: implement carrier change
> 
>  Documentation/networking/operstates.txt |  4 ++++
>  drivers/net/dummy.c                     | 10 ++++++++++
>  include/linux/netdevice.h               | 12 ++++++++++++
>  include/uapi/linux/if_link.h            |  1 +
>  net/core/dev.c                          | 19 +++++++++++++++++++
>  net/core/net-sysfs.c                    | 15 ++++++++++++++-
>  net/core/rtnetlink.c                    | 10 ++++++++++
>  7 files changed, 70 insertions(+), 1 deletion(-)

I am using this patch series already with team.

Acked-by: Flavio Leitner <fbl@redhat.com>

^ permalink raw reply

* Re: [PATCH net-next] bridge: respect RFC2863 operational state
From: Flavio Leitner @ 2012-12-28 13:03 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20121227222854.6ec132dd@nehalam.linuxnetplumber.net>

On Thu, Dec 27, 2012 at 10:28:54PM -0800, Stephen Hemminger wrote:
> The bridge link detection should follow the operational state
> of the lower device, rather than the carrier bit. This allows devices
> like tunnels that are controlled by userspace control plane to work
> with bridge STP link management.
> 
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> 
> 
> --- a/net/bridge/br_if.c	2012-10-25 09:11:15.627272524 -0700
> +++ b/net/bridge/br_if.c	2012-12-14 08:58:14.329847361 -0800
> @@ -66,14 +66,14 @@ void br_port_carrier_check(struct net_br
>  	struct net_device *dev = p->dev;
>  	struct net_bridge *br = p->br;
>  
> -	if (netif_running(dev) && netif_carrier_ok(dev))
> +	if (netif_running(dev) && netif_oper_up(dev))
>  		p->path_cost = port_cost(dev);
>  
>  	if (!netif_running(br->dev))
>  		return;
>  
>  	spin_lock_bh(&br->lock);
> -	if (netif_running(dev) && netif_carrier_ok(dev)) {
> +	if (netif_running(dev) && netif_oper_up(dev))
>  		if (p->state == BR_STATE_DISABLED)
>  			br_stp_enable_port(p);

I found this piece still using netif_carrier_ok():
321 int br_add_if(struct net_bridge *br, struct net_device *dev)
322 {
...
385 
386         if ((dev->flags & IFF_UP) && netif_carrier_ok(dev) &&
387             (br->dev->flags & IFF_UP))
388                 br_stp_enable_port(p);
389         spin_unlock_bh(&br->lock);
390 

Is there any reason for enabling stp on a port using operstate
in br_port_carrier_check() but not in br_add_if() ?

The same thing happens with br_stp_enable_bridge():

 56   list_for_each_entry(p, &br->port_list, list) {
 57          if ((p->dev->flags & IFF_UP) && netif_carrier_ok(p->dev))
 58                  br_stp_enable_port(p);

Also, as operstate UP means that packets are flowing, there is no need to
check if the device is opened, so checking only for operstate should be
enough, right? I.e.

-           if ((p->dev->flags & IFF_UP) && netif_carrier_ok(p->dev))
+           if (netif_oper_up(dev))


>  	} else {
> --- a/net/bridge/br_notify.c	2012-10-25 09:11:15.631272484 -0700
> +++ b/net/bridge/br_notify.c	2012-12-14 08:57:36.954222724 -0800
> @@ -82,7 +82,7 @@ static int br_device_event(struct notifi
>  		break;
>  
>  	case NETDEV_UP:
> -		if (netif_carrier_ok(dev) && (br->dev->flags & IFF_UP)) {
> +		if (netif_running(br->dev) && netif_oper_up(dev)) {
>  			spin_lock_bh(&br->lock);
>  			br_stp_enable_port(p);
>  			spin_unlock_bh(&br->lock);

You are not just changing to use operstate, but also to check another
flag - before it was IFF_UP and now __LINK_STATE_START. Any reason
for that besides being consistent with other checks?

thanks!
-- 
fbl

^ permalink raw reply

* Re: [PATCH 01/19] netfilter: move nf_conntrack initialize out of pernet operations
From: Pablo Neira Ayuso @ 2012-12-28 11:58 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: canqun zhang, Gao feng, netfilter-devel, netdev@vger.kernel.org,
	Patrick McHardy
In-Reply-To: <87ip7mlr2r.fsf@xmission.com>

On Thu, Dec 27, 2012 at 08:48:44PM -0800, Eric W. Biederman wrote:
[...]
> Does anyone know why Alexy decided to do this only for init_net?

Not myself.

[...]
> My inclination is that Gao Feng is on the rigt path by just removing
> the strange init_net special case and performing the work once
> per module load, and once per module unload.

That makes sense to me, I'll check Gao's patchset asap to come back to
him with some feedback. Thanks.

^ permalink raw reply

* Re: [RFC/RFT] forcedeth: Fix 'device driver failed to check map error' warnings
From: Ben Hutchings @ 2012-12-28 11:57 UTC (permalink / raw)
  To: Larry Finger; +Cc: davem, netdev, linux-kernel
In-Reply-To: <50db61fe.u8zB6nsB1I7ajQXN%Larry.Finger@lwfinger.net>

On Wed, 2012-12-26 at 14:45 -0600, Larry Finger wrote:
> With 3.8-rc1, there are WARNINGS that the driver is not checking for
> DMA mapping errors. The warnings start with
> 
> ------------[ cut here ]------------
> WARNING: at lib/dma-debug.c:933 check_unmap+0x480/0x950()
> Hardware name: HP Pavilion dv2700 Notebook PC
> forcedeth 0000:00:0a.0: DMA-API: device driver failed to check
>  map error[device address=0x00000000b176e002] [size=90 bytes] [mapped as single]
> 
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> 
> Please check that the error returns are correctly done.
[...]
> @@ -2217,6 +2229,9 @@ static netdev_tx_t nv_start_xmit(struct
>  		bcnt = (size > NV_TX2_TSO_MAX_SIZE) ? NV_TX2_TSO_MAX_SIZE : size;
>  		np->put_tx_ctx->dma = pci_map_single(np->pci_dev, skb->data + offset, bcnt,
>  						PCI_DMA_TODEVICE);
> +		if (pci_dma_mapping_error(np->pci_dev,
> +					  np->put_tx_ctx->dma))
> +			return NETDEV_TX_BUSY;
>  		np->put_tx_ctx->dma_len = bcnt;
>  		np->put_tx_ctx->dma_single = 1;
>  		put_tx->buf = cpu_to_le32(np->put_tx_ctx->dma);
> @@ -2337,6 +2352,9 @@ static netdev_tx_t nv_start_xmit_optimiz
>  		bcnt = (size > NV_TX2_TSO_MAX_SIZE) ? NV_TX2_TSO_MAX_SIZE : size;
>  		np->put_tx_ctx->dma = pci_map_single(np->pci_dev, skb->data + offset, bcnt,
>  						PCI_DMA_TODEVICE);
> +		if (pci_dma_mapping_error(np->pci_dev,
> +					  np->put_tx_ctx->dma))
> +			return NETDEV_TX_BUSY;
>  		np->put_tx_ctx->dma_len = bcnt;
>  		np->put_tx_ctx->dma_single = 1;
>  		put_tx->bufhigh = cpu_to_le32(dma_high(np->put_tx_ctx->dma));
[...]

In these cases the skb should be freed and the return value should be
NETDEV_TX_OK.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply

* [PATCH 12/12] netfilter: ctnetlink: fix leak in error path of ctnetlink_create_expect
From: pablo @ 2012-12-28 11:52 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1356695571-3305-1-git-send-email-pablo@netfilter.org>

From: Jesper Juhl <jj@chaosbits.net>

This patch fixes a leak in one of the error paths of
ctnetlink_create_expect if no helper and no timeout is specified.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/netfilter/nf_conntrack_netlink.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index 4e078cd..627b0e5 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -2624,7 +2624,7 @@ ctnetlink_create_expect(struct net *net, u16 zone,
 	if (!help) {
 		if (!cda[CTA_EXPECT_TIMEOUT]) {
 			err = -EINVAL;
-			goto out;
+			goto err_out;
 		}
 		exp->timeout.expires =
 		  jiffies + ntohl(nla_get_be32(cda[CTA_EXPECT_TIMEOUT])) * HZ;
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 08/12] netfilter: xt_CT: recover NOTRACK target support
From: pablo @ 2012-12-28 11:52 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1356695571-3305-1-git-send-email-pablo@netfilter.org>

From: Pablo Neira Ayuso <pablo@netfilter.org>

Florian Westphal reported that the removal of the NOTRACK target
(9655050 netfilter: remove xt_NOTRACK) is breaking some existing
setups.

That removal was scheduled for removal since long time ago as
described in Documentation/feature-removal-schedule.txt

What:  xt_NOTRACK
Files: net/netfilter/xt_NOTRACK.c
When:  April 2011
Why:   Superseded by xt_CT

Still, people may have not notice / may have decided to stick to an
old iptables version. I agree with him in that some more conservative
approach by spotting some printk to warn users for some time is less
agressive.

Current iptables 1.4.16.3 already contains the aliasing support
that makes it point to the CT target, so upgrading would fix it.
Still, the policy so far has been to avoid pushing our users to
upgrade.

As a solution, this patch recovers the NOTRACK target inside the CT
target and it now spots a warning.

Reported-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 include/net/netns/x_tables.h |    1 +
 net/netfilter/Kconfig        |    4 ++++
 net/netfilter/xt_CT.c        |   50 +++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/include/net/netns/x_tables.h b/include/net/netns/x_tables.h
index 591db7d..c24060e 100644
--- a/include/net/netns/x_tables.h
+++ b/include/net/netns/x_tables.h
@@ -8,6 +8,7 @@ struct ebt_table;
 
 struct netns_xt {
 	struct list_head tables[NFPROTO_NUMPROTO];
+	bool notrack_deprecated_warning;
 #if defined(CONFIG_BRIDGE_NF_EBTABLES) || \
     defined(CONFIG_BRIDGE_NF_EBTABLES_MODULE)
 	struct ebt_table *broute_table;
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index fefa514..390f96c 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -680,6 +680,10 @@ config NETFILTER_XT_TARGET_NFQUEUE
 
 	  To compile it as a module, choose M here.  If unsure, say N.
 
+config NETFILTER_XT_TARGET_NOTRACK
+	tristate  '"NOTRACK" target support (DEPRECATED)'
+	select NETFILTER_XT_TARGET_CT
+
 config NETFILTER_XT_TARGET_RATEEST
 	tristate '"RATEEST" target support'
 	depends on NETFILTER_ADVANCED
diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c
index 1668f41..2a08430 100644
--- a/net/netfilter/xt_CT.c
+++ b/net/netfilter/xt_CT.c
@@ -385,14 +385,60 @@ static struct xt_target xt_ct_tg_reg[] __read_mostly = {
 	},
 };
 
+static unsigned int
+notrack_tg(struct sk_buff *skb, const struct xt_action_param *par)
+{
+	/* Previously seen (loopback)? Ignore. */
+	if (skb->nfct != NULL)
+		return XT_CONTINUE;
+
+	skb->nfct = &nf_ct_untracked_get()->ct_general;
+	skb->nfctinfo = IP_CT_NEW;
+	nf_conntrack_get(skb->nfct);
+
+	return XT_CONTINUE;
+}
+
+static int notrack_chk(const struct xt_tgchk_param *par)
+{
+	if (!par->net->xt.notrack_deprecated_warning) {
+		pr_info("netfilter: NOTRACK target is deprecated, "
+			"use CT instead or upgrade iptables\n");
+		par->net->xt.notrack_deprecated_warning = true;
+	}
+	return 0;
+}
+
+static struct xt_target notrack_tg_reg __read_mostly = {
+	.name		= "NOTRACK",
+	.revision	= 0,
+	.family		= NFPROTO_UNSPEC,
+	.checkentry	= notrack_chk,
+	.target		= notrack_tg,
+	.table		= "raw",
+	.me		= THIS_MODULE,
+};
+
 static int __init xt_ct_tg_init(void)
 {
-	return xt_register_targets(xt_ct_tg_reg, ARRAY_SIZE(xt_ct_tg_reg));
+	int ret;
+
+	ret = xt_register_target(&notrack_tg_reg);
+	if (ret < 0)
+		return ret;
+
+	ret = xt_register_targets(xt_ct_tg_reg, ARRAY_SIZE(xt_ct_tg_reg));
+	if (ret < 0) {
+		xt_unregister_target(&notrack_tg_reg);
+		return ret;
+	}
+	return 0;
 }
 
 static void __exit xt_ct_tg_exit(void)
 {
 	xt_unregister_targets(xt_ct_tg_reg, ARRAY_SIZE(xt_ct_tg_reg));
+	xt_unregister_target(&notrack_tg_reg);
 }
 
 module_init(xt_ct_tg_init);
@@ -402,3 +448,5 @@ MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Xtables: connection tracking target");
 MODULE_ALIAS("ipt_CT");
 MODULE_ALIAS("ip6t_CT");
+MODULE_ALIAS("ipt_NOTRACK");
+MODULE_ALIAS("ip6t_NOTRACK");
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 07/12] netfilter: nfnetlink_log: fix possible compilation issue due to missing include
From: pablo @ 2012-12-28 11:52 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1356695571-3305-1-git-send-email-pablo@netfilter.org>

From: Pablo Neira Ayuso <pablo@netfilter.org>

In (0c36b48 netfilter: nfnetlink_log: fix mac address for 6in4 tunnels)
the include file that defines ARPD_SIT was missing. This passed unnoticed
during my tests (I did not hit this problem here).

net/netfilter/nfnetlink_log.c: In function '__build_packet_message':
net/netfilter/nfnetlink_log.c:494:25: error: 'ARPHRD_SIT' undeclared (first use in this function)
net/netfilter/nfnetlink_log.c:494:25: note: each undeclared identifier is reported only once for
+each function it appears in

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/netfilter/nfnetlink_log.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
index 4e210e0..92fd8ec 100644
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -13,6 +13,7 @@
  */
 #include <linux/module.h>
 #include <linux/skbuff.h>
+#include <linux/if_arp.h>
 #include <linux/init.h>
 #include <linux/ip.h>
 #include <linux/ipv6.h>
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 04/12] netfilter: nf_ct_reasm: fix conntrack reassembly expire code
From: pablo @ 2012-12-28 11:52 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1356695571-3305-1-git-send-email-pablo@netfilter.org>

From: Haibo Xi <haibbo@gmail.com>

Commit b836c99fd6c9 (ipv6: unify conntrack reassembly expire
code with standard one) use the standard IPv6 reassembly
code(ip6_expire_frag_queue) to handle conntrack reassembly expire.

In ip6_expire_frag_queue, it invoke dev_get_by_index_rcu to get
which device received this expired packet.so we must save ifindex
when NF_conntrack get this packet.

With this patch applied, I can see ICMP Time Exceeded sent
from the receiver when the sender sent out 1/2 fragmented
IPv6 packet.

Signed-off-by: Haibo Xi <haibbo@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/ipv6/netfilter/nf_conntrack_reasm.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 22c8ea9..3dacecc 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -311,7 +311,10 @@ found:
 	else
 		fq->q.fragments = skb;
 
-	skb->dev = NULL;
+	if (skb->dev) {
+		fq->iif = skb->dev->ifindex;
+		skb->dev = NULL;
+	}
 	fq->q.stamp = skb->tstamp;
 	fq->q.meat += skb->len;
 	if (payload_len > fq->q.max_size)
-- 
1.7.10.4

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox