Netdev List
 help / color / mirror / Atom feed
* [patch -next] mac80211: handle allocation failures in mesh_pathtbl_init()
From: Dan Carpenter @ 2011-08-30 19:16 UTC (permalink / raw)
  To: javier
  Cc: Johannes Berg, John W. Linville, David S. Miller,
	open list:MAC80211, open list:NETWORKING [GENERAL],
	kernel-janitors

The calls to kzalloc() weren't checked here and it upsets the static
checkers.  Obviously they're not super likely to fail, but we might
as well add some error handling.

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 1f91bce..96092e8 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -1075,6 +1075,7 @@ static int mesh_path_node_copy(struct hlist_node *p, struct mesh_table *newtbl)
 int mesh_pathtbl_init(void)
 {
 	struct mesh_table *tbl_path, *tbl_mpp;
+	int ret;
 
 	tbl_path = mesh_table_alloc(INIT_PATHS_SIZE_ORDER);
 	if (!tbl_path)
@@ -1083,19 +1084,27 @@ int mesh_pathtbl_init(void)
 	tbl_path->copy_node = &mesh_path_node_copy;
 	tbl_path->mean_chain_len = MEAN_CHAIN_LEN;
 	tbl_path->known_gates = kzalloc(sizeof(struct hlist_head), GFP_ATOMIC);
+	if (!tbl_path->known_gates) {
+		ret = -ENOMEM;
+		goto free_path;
+	}
 	INIT_HLIST_HEAD(tbl_path->known_gates);
 
 
 	tbl_mpp = mesh_table_alloc(INIT_PATHS_SIZE_ORDER);
 	if (!tbl_mpp) {
-		mesh_table_free(tbl_path, true);
-		return -ENOMEM;
+		ret = -ENOMEM;
+		goto free_path;
 	}
 	tbl_mpp->free_node = &mesh_path_node_free;
 	tbl_mpp->copy_node = &mesh_path_node_copy;
 	tbl_mpp->mean_chain_len = MEAN_CHAIN_LEN;
 	/* XXX: not needed */
 	tbl_mpp->known_gates = kzalloc(sizeof(struct hlist_head), GFP_ATOMIC);
+	if (!tbl_mpp->known_gates) {
+		ret = -ENOMEM;
+		goto free_mpp;
+	}
 	INIT_HLIST_HEAD(tbl_mpp->known_gates);
 
 	/* Need no locking since this is during init */
@@ -1103,6 +1112,12 @@ int mesh_pathtbl_init(void)
 	RCU_INIT_POINTER(mpp_paths, tbl_mpp);
 
 	return 0;
+
+free_mpp:
+	mesh_table_free(tbl_mpp, true);
+free_path:
+	mesh_table_free(tbl_path, true);
+	return ret;
 }
 
 void mesh_path_expire(struct ieee80211_sub_if_data *sdata)

^ permalink raw reply related

* Re: [Bug 42012] New: regression on 2.6.39.3 with socket/bind; still there in 3.0.4
From: Eric Dumazet @ 2011-08-30 19:16 UTC (permalink / raw)
  To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20110830.140733.146208373221522199.davem@davemloft.net>

Le mardi 30 août 2011 à 14:07 -0400, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 30 Aug 2011 18:11:48 +0200
> 
> > Yep, we should relax the check and accept AF_UNSPEC.
> 
> I guess we'll have to do this, but I just can't bring myself to accept
> that we can just do zero validation of what the user is passing us,
> see an AF_UNSPEC, and say "yeah it's fine to assume there's an ipv4
> address in there."

I couldnt accept it either ;)

By the way, if we accept it, strace() will probably still print binary
blob instead of the IP address (not necessarily ANY address ?)

connect ( AF_UNSPEC ) has special semantic, but AFAIK, bind (AF_UNSPEC)
only brings some mixed results : FreeBSD was accepting it in old
versions it seems. I guess I should try current FreeBSD versions.

^ permalink raw reply

* Re: [PATCH] net: relax PKTINFO non local ipv6 udp xmit check
From: Maciej Żenczykowski @ 2011-08-30 18:51 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20110828.210633.783157755808327582.davem@davemloft.net>

On Sun, Aug 28, 2011 at 6:06 PM, David Miller <davem@davemloft.net> wrote:
> > Allow transparent sockets to be less restrictive about
> > the source ip of ipv6 udp packets being sent.
>
> Applied, thanks a lot.

FYI, I don't see this in either git repository:

http://git.kernel.org/?p=linux/kernel/git/davem/net.git;a=shortlog
http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=shortlog

I'd expect it to have shown up in net-next by now.

I'm also curious whether anyone knows of any good reason why
transparent sockets require CAP_NET_ADMIN instead of CAP_NET_RAW (or
either one of CAP_NET_{RAW|ADMIN}).

Maciej

^ permalink raw reply

* Re: [PATCH 7/7] bnx2x: expose HW RX VLAN stripping toggle
From: Michał Mirosław @ 2011-08-30 18:27 UTC (permalink / raw)
  To: Michal Schmidt; +Cc: netdev, vladz, dmitry, eilong
In-Reply-To: <1314714646-3642-8-git-send-email-mschmidt@redhat.com>

2011/8/30 Michal Schmidt <mschmidt@redhat.com>:
> Allow disabling of HW RX VLAN stripping with ethtool.
>
> [v2: Store the flag in the fp to ensure that pending packets are
>     handled correctly during a switch.]
[...]
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> @@ -66,6 +66,9 @@ static inline void bnx2x_bz_fp(struct bnx2x *bp, int index)
>         */
>        if ((bp->flags & TPA_ENABLE_FLAG) && !IS_FCOE_FP(fp))
>                fp->flags = FP_TPA;
> +
> +       if (bp->flags & RX_VLAN_STRIP_FLAG)
> +               fp->flags |= FP_VLAN_STRIP;
>  }
[...]
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> @@ -2719,9 +2719,8 @@ static unsigned long bnx2x_get_q_flags(struct bnx2x *bp,
>                __set_bit(BNX2X_Q_FLG_MCAST, &flags);
>        }
>
> -       /* Always set HW VLAN stripping */
> -       __set_bit(BNX2X_Q_FLG_VLAN, &flags);
> -
> +       if (fp->flags & FP_VLAN_STRIP)
> +               __set_bit(BNX2X_Q_FLG_VLAN, &flags);
>
>        return flags | bnx2x_get_common_flags(bp, fp, true);
>  }


It seems rather convoluted and unnecessary that you mirror
NETIF_F_HW_VLAN_RX in bp->flags and then also in fp->flags. Are the
fp->flags strictly mirroring hardware state (as in: there is no way
the states can differ in any point in time where the flags are
tested)? For this to be true, the two functions above need to be
called only without releasing a lock between them that is also taken
by receive handler. Isn't there a flag in the rx descriptor of a
packet that says if VLAN was stripped? (All that flag keeping would be
unnecessary then.)

Best Regards,
Michał Mirosław

^ permalink raw reply

* Re: [patch net-next-2.6 1/2] net: allow to change carrier via sysfs
From: Stephen Hemminger @ 2011-08-30 18:25 UTC (permalink / raw)
  To: Michał Mirosław
  Cc: Jiri Pirko, netdev, davem, eric.dumazet, bhutchings
In-Reply-To: <CAHXqBFJh0xjRYv_-2AzwAvpHOUfQ+pD_153qVtNA3Ybo9r3b=w@mail.gmail.com>

On Tue, 30 Aug 2011 20:11:37 +0200
Michał Mirosław <mirqus@gmail.com> wrote:

> 2011/8/30 Jiri Pirko <jpirko@redhat.com>:
> > Allow to write to "carrier" attribute. Devices may implement ndo_change_carrier
> > callback to allow changing carrier from userspace.
> 
> Do you expect drivers using implementation different than just calling
> netif_carrier_on/off? Or is it supposed to also e.g. power down PHYs?
> 
> BTW, I like this feature!

Ok for virtual devices, but please don't implement it in real hardware.
There is already enough breakage in carrier management in applications.
It also overlaps with operstate perhaps that is a more more complete
solution.

^ permalink raw reply

* Re: [patch net-next-2.6 1/2] net: allow to change carrier via sysfs
From: Michał Mirosław @ 2011-08-30 18:11 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: netdev, davem, eric.dumazet, bhutchings, shemminger
In-Reply-To: <1314715608-978-2-git-send-email-jpirko@redhat.com>

2011/8/30 Jiri Pirko <jpirko@redhat.com>:
> Allow to write to "carrier" attribute. Devices may implement ndo_change_carrier
> callback to allow changing carrier from userspace.

Do you expect drivers using implementation different than just calling
netif_carrier_on/off? Or is it supposed to also e.g. power down PHYs?

BTW, I like this feature!

Best Regards,
Michał Mirosław

^ permalink raw reply

* Re: [Bug 42012] New: regression on 2.6.39.3 with socket/bind; still there in 3.0.4
From: David Miller @ 2011-08-30 18:07 UTC (permalink / raw)
  To: eric.dumazet; +Cc: shemminger, netdev
In-Reply-To: <1314720708.2935.29.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 30 Aug 2011 18:11:48 +0200

> Yep, we should relax the check and accept AF_UNSPEC.

I guess we'll have to do this, but I just can't bring myself to accept
that we can just do zero validation of what the user is passing us,
see an AF_UNSPEC, and say "yeah it's fine to assume there's an ipv4
address in there."

^ permalink raw reply

* Re: [PATCH 06/24] netfilter: Remove unnecessary OOM logging messages
From: David Miller @ 2011-08-30 17:55 UTC (permalink / raw)
  To: kaber
  Cc: joe, bart.de.schuymer, wensong, horms, ja, shemminger, kuznet,
	jmorris, yoshfuji, netfilter-devel, netfilter, coreteam, bridge,
	netdev, linux-kernel, lvs-devel
In-Reply-To: <4E5CDBAA.6040001@trash.net>

From: Patrick McHardy <kaber@trash.net>
Date: Tue, 30 Aug 2011 14:46:34 +0200

> On 29.08.2011 23:17, Joe Perches wrote:
>> Removing unnecessary messages saves code and text.
>> 
>> Site specific OOM messages are duplications of a generic MM
>> out of memory message and aren't really useful, so just
>> delete them.
> 
> Looks good to me. Do you want me to apply this patch or are you
> intending to have the entire series go through Dave?

I'm happy with subsystem folks taking things in if they want, the
B.A.T.M.A.N. guys did this earlier today for example.

^ permalink raw reply

* Re: [PATCH] net/mac80211/debugfs: Convert to kstrou8_from_user
From: John W. Linville @ 2011-08-30 17:50 UTC (permalink / raw)
  To: Peter Hüwe
  Cc: Johannes Berg, David S. Miller,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201108282152.32180.PeterHuewe-Mmb7MZpHnFY@public.gmane.org>

On Sun, Aug 28, 2011 at 09:52:31PM +0200, Peter Hüwe wrote:
> Am Dienstag 07 Juni 2011, 22:36:14 schrieb Peter Huewe:
> > This patch replaces the code for getting an number from a
> > userspace buffer by a simple call to kstrou8_from_user.
> > This makes it easier to read and less error prone.
> > 
> > Since the old buffer was only 10 bytes long and the value is masked by a
> > nibble-mask anyway, we don't need to use kstrtoul but rather kstrtou8.
> > 
> > Kernel Version: v3.0-rc2
> > 
> > Signed-off-by: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org>
> 
> Any updates on this one?
> Still applies to the latest linus' tree

I merged it to wireless-next yesterday.

Thanks for the reminder!

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org			might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 5/7] bnx2x: do not set TPA flags and features in bnx2x_init_bp
From: Michal Schmidt @ 2011-08-30 17:15 UTC (permalink / raw)
  To: Vlad Zolotarov; +Cc: netdev@vger.kernel.org, Dmitry Kravkov, Eilon Greenstein
In-Reply-To: <201108301921.22838.vladz@broadcom.com>

On 08/30/2011 06:21 PM, Vlad Zolotarov wrote:
> NACK
>
> This patch will cause the bnx2x to initialize HW with LRO disabled on the
> first ifup because our code considers the TPA_ENABLE_FLAG when desiding on
> whether LRO is enabled or not. ethtool would still report the LRO on though!

I see. I thought register_netdevice() would always call 
bnx2x_set_features(), but this is not the case.

Patch 7/7 has a similar problem with RX_VLAN_STRIP_FLAG then.

Michal

^ permalink raw reply

* Re: [PATCH 5/7] bnx2x: do not set TPA flags and features in bnx2x_init_bp
From: Vlad Zolotarov @ 2011-08-30 16:21 UTC (permalink / raw)
  To: Michal Schmidt; +Cc: netdev@vger.kernel.org, Dmitry Kravkov, Eilon Greenstein
In-Reply-To: <1314714646-3642-6-git-send-email-mschmidt@redhat.com>

On Tuesday 30 August 2011 17:30:44 Michal Schmidt wrote:
> The .ndo_{set,fix}_features callbacks are sufficient.
> 
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> ---
>  drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |    9 ---------
>  1 files changed, 0 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c index 64314f7..617a072
> 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> @@ -9752,15 +9752,6 @@ static int __devinit bnx2x_init_bp(struct bnx2x *bp)
>  					"must load devices in order!\n");
> 
>  	bp->multi_mode = multi_mode;
> -
> -	/* Set TPA flags */
> -	if (disable_tpa) {
> -		bp->flags &= ~TPA_ENABLE_FLAG;
> -		bp->dev->features &= ~NETIF_F_LRO;
> -	} else {
> -		bp->flags |= TPA_ENABLE_FLAG;
> -		bp->dev->features |= NETIF_F_LRO;
> -	}
>  	bp->disable_tpa = disable_tpa;
> 
>  	if (CHIP_IS_E1(bp))

NACK

This patch will cause the bnx2x to initialize HW with LRO disabled on the 
first ifup because our code considers the TPA_ENABLE_FLAG when desiding on 
whether LRO is enabled or not. ethtool would still report the LRO on though!

thanks,
vlad

^ permalink raw reply

* Re: [PATCH 06/24] netfilter: Remove unnecessary OOM logging messages
From: Joe Perches @ 2011-08-30 16:13 UTC (permalink / raw)
  To: Patrick McHardy
  Cc: Bart De Schuymer, Wensong Zhang, Simon Horman, Julian Anastasov,
	Stephen Hemminger, David S. Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, netfilter-devel, netfilter,
	coreteam, bridge, netdev, linux-kernel, lvs-devel
In-Reply-To: <4E5CDBAA.6040001@trash.net>

On Tue, 2011-08-30 at 14:46 +0200, Patrick McHardy wrote:
> On 29.08.2011 23:17, Joe Perches wrote:
> > Removing unnecessary messages saves code and text.
> > Site specific OOM messages are duplications of a generic MM
> > out of memory message and aren't really useful, so just
> > delete them.
> Looks good to me. Do you want me to apply this patch or are you
> intending to have the entire series go through Dave?

It doesn't matter to me one way or another.

If you pick this one up, when I redo these
to separate vmalloc from the the other alloc
cases, I'll won't send netfilter again.

cheers, Joe


^ permalink raw reply

* Re: Fw: [Bug 42012] New: regression on 2.6.39.3 with socket/bind; still there in 3.0.4
From: Eric Dumazet @ 2011-08-30 16:11 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110830084742.26c72c20@nehalam.ftrdhcpuser.net>

Le mardi 30 août 2011 à 08:47 -0700, Stephen Hemminger a écrit :
> Interesting? Does the kernel ABI include supporting buggy old proprietary
> programs?
> 
> Begin forwarded message:
> 
> Date: Tue, 30 Aug 2011 02:59:32 GMT
> From: bugzilla-daemon@bugzilla.kernel.org
> To: shemminger@linux-foundation.org
> Subject: [Bug 42012] New: regression on 2.6.39.3 with socket/bind; still there in 3.0.4
> 
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=42012
> 
>            Summary: regression on 2.6.39.3 with socket/bind; still there
>                     in 3.0.4
>            Product: Networking
>            Version: 2.5
>     Kernel Version: 2.6.39.3 - 3.0.4
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: IPV4
>         AssignedTo: shemminger@linux-foundation.org
>         ReportedBy: r_meier@freenet.de
>         Regression: Yes
> 
> 
> Hi,
> 
> the regression has been introduced in 2.6.39.3 with commit
> d0733d2e29b652b2e7b1438ececa732e4eed98eb. I experience this with a proprietary
> binary program. So I cant give you the source code which fails. This program
> used to work before but fails after applying this patch. As far as I understand
> the programm is using this code for ipc communication. I have recorded the
> strace output of the relevant part of the program.
> strace without d0733d2e29b652b2e7b1438ececa732e4eed98eb on kernel 2.6.39.2
> ---------------
> 2056  socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
> 2056  bind(4, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"},
> 16) = 0
> 2056  getsockname(4, {sa_family=AF_INET, sin_port=htons(33537),
> sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
> 2056  listen(4, 5)                      = 0
> 2056  setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> ---------------
> 
> strace with d0733d2e29b652b2e7b1438ececa732e4eed98eb on kernel 2.6.39.2
> ---------------
> 6190  socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
> 6190  bind(4, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"},
> 16) = -1 EINVAL (Invalid argument)
> 6190  dup(2)                            = 11
> 6190  fcntl64(11, F_GETFL)              = 0x8002 (flags O_RDWR|O_LARGEFILE)
> 6190  fstat64(11, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 3), ...}) = 0
> 6190  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0x576ac000
> 6190  _llseek(11, 0, 0xffa03de4, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> 6190  write(11, "ERROR: Failed to bind to interne"..., 66) = 66
> 6190  close(11)                         = 0
> ---------------
> 
> Btw, i have not enough knowledge on this topic to decide whether its the
> programs fault or the kernels fault. The binary program is sybyl8.1 from
> tripos.
> 
> Best regards, Rene
> 

Yep, we should relax the check and accept AF_UNSPEC.

diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 1b745d4..60fd64e 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -465,7 +465,7 @@ int inet_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
 	if (addr_len < sizeof(struct sockaddr_in))
 		goto out;
 
-	if (addr->sin_family != AF_INET) {
+	if (addr->sin_family != AF_INET && addr->sin_family != AF_UNSPEC) {
 		err = -EAFNOSUPPORT;
 		goto out;
 	}

^ permalink raw reply related

* interface information for recvd packet
From: Viral Mehta @ 2011-08-30 15:55 UTC (permalink / raw)
  To: netdev

Hi,

I was trying to implement following thing,

1. I wanted to know whenever packet received for particular socket, I
want to know which network interface actually received it ?
2. I was looking at net/ipv4/tcp.c and in function tcp_recvmsg(); I am
trying to get interface name by accessing sk_buff->dev->name
    However, it gives me (null). I have made sure that in my ethernet
(NIC) driver, I filled up that information before doing netif_rx().

So, the question is,
Is this information Trimmed out at some upper layer ??

Thanks,




-- 
Thanks,
Viral Mehta

^ permalink raw reply

* Fw: [Bug 42012] New: regression on 2.6.39.3 with socket/bind; still there in 3.0.4
From: Stephen Hemminger @ 2011-08-30 15:47 UTC (permalink / raw)
  To: netdev

Interesting? Does the kernel ABI include supporting buggy old proprietary
programs?

Begin forwarded message:

Date: Tue, 30 Aug 2011 02:59:32 GMT
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 42012] New: regression on 2.6.39.3 with socket/bind; still there in 3.0.4


https://bugzilla.kernel.org/show_bug.cgi?id=42012

           Summary: regression on 2.6.39.3 with socket/bind; still there
                    in 3.0.4
           Product: Networking
           Version: 2.5
    Kernel Version: 2.6.39.3 - 3.0.4
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
        AssignedTo: shemminger@linux-foundation.org
        ReportedBy: r_meier@freenet.de
        Regression: Yes


Hi,

the regression has been introduced in 2.6.39.3 with commit
d0733d2e29b652b2e7b1438ececa732e4eed98eb. I experience this with a proprietary
binary program. So I cant give you the source code which fails. This program
used to work before but fails after applying this patch. As far as I understand
the programm is using this code for ipc communication. I have recorded the
strace output of the relevant part of the program.
strace without d0733d2e29b652b2e7b1438ececa732e4eed98eb on kernel 2.6.39.2
---------------
2056  socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
2056  bind(4, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"},
16) = 0
2056  getsockname(4, {sa_family=AF_INET, sin_port=htons(33537),
sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
2056  listen(4, 5)                      = 0
2056  setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
---------------

strace with d0733d2e29b652b2e7b1438ececa732e4eed98eb on kernel 2.6.39.2
---------------
6190  socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
6190  bind(4, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"},
16) = -1 EINVAL (Invalid argument)
6190  dup(2)                            = 11
6190  fcntl64(11, F_GETFL)              = 0x8002 (flags O_RDWR|O_LARGEFILE)
6190  fstat64(11, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 3), ...}) = 0
6190  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x576ac000
6190  _llseek(11, 0, 0xffa03de4, SEEK_CUR) = -1 ESPIPE (Illegal seek)
6190  write(11, "ERROR: Failed to bind to interne"..., 66) = 66
6190  close(11)                         = 0
---------------

Btw, i have not enough knowledge on this topic to decide whether its the
programs fault or the kernels fault. The binary program is sybyl8.1 from
tripos.

Best regards, Rene

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

^ permalink raw reply

* [PATCH] Documentation: networking: dmfe.txt: Remove the maintainer of orphan filesystem
From: Marcos Paulo de Souza @ 2011-08-30 15:33 UTC (permalink / raw)
  To: rdunlap; +Cc: netdev, linux-doc, Marcos Paulo de Souza

The dmfe module is a orphan driver, and with this was removed the maintainer
of the documentation.

Signed-off-by: Marcos Paulo de Souza <marcos.mage@gmail.com>
---
 Documentation/networking/dmfe.txt |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Documentation/networking/dmfe.txt b/Documentation/networking/dmfe.txt
index 8006c22..25320bf 100644
--- a/Documentation/networking/dmfe.txt
+++ b/Documentation/networking/dmfe.txt
@@ -1,3 +1,5 @@
+Note: This driver doesn't have a maintainer.
+
 Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux.
 
 This program is free software; you can redistribute it and/or
@@ -55,7 +57,6 @@ Test and make sure PCI latency is now correct for all cases.
 Authors:
 
 Sten Wang <sten_wang@davicom.com.tw >   : Original Author
-Tobias Ringstrom <tori@unhappy.mine.nu> : Current Maintainer
 
 Contributors:
 
-- 
1.7.4.1

^ permalink raw reply related

* Re: [PATCH 4/9] stmmac: add MMC support exported via ethtool (v2)
From: Ben Hutchings @ 2011-08-30 15:26 UTC (permalink / raw)
  To: Giuseppe CAVALLARO; +Cc: netdev
In-Reply-To: <1314714064-29101-5-git-send-email-peppe.cavallaro@st.com>

On Tue, 2011-08-30 at 16:20 +0200, Giuseppe CAVALLARO wrote:
> This patch adds the MMC management counters support.
> MMC module is an extension of the register address
> space and all the hardware counters can be accessed
> via ethtoo -S ethX.
> 
> Note that, the MMC interrupts remain masked and the logic
> to handle this kind of interrupt will be added later (if
> actually useful).
[...]
>  static void stmmac_ethtool_getdrvinfo(struct net_device *dev,
>  				      struct ethtool_drvinfo *info)
>  {
>  	struct stmmac_priv *priv = netdev_priv(dev);
>  
> -	if (!priv->plat->has_gmac)
> -		strcpy(info->driver, MAC100_ETHTOOL_NAME);
> -	else
> +	info->n_stats = STMMAC_STATS_LEN;
> +
> +	if (likely(priv->plat->has_gmac)) {

Using likely() and unlikely() in ethtool operations seems like a
pointless optimisation.

>  		strcpy(info->driver, GMAC_ETHTOOL_NAME);
> +		info->n_stats += STMMAC_MMC_STATS_LEN;
> +	} else
> +		strcpy(info->driver, MAC100_ETHTOOL_NAME);
>  
>  	strcpy(info->version, DRV_MODULE_VERSION);
>  	info->fw_version[0] = '\0';
> -	info->n_stats = STMMAC_STATS_LEN;
>  }
[...]

Don't bother initialising ethtool_drvinfo::n_stats.  The ethtool core
will do it by calling your get_sset_count implementation.

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

* Re: [patch net-next-2.6 1/2] net: allow to change carrier via sysfs
From: Jiri Pirko @ 2011-08-30 15:19 UTC (permalink / raw)
  To: Ben Hutchings; +Cc: netdev, davem, eric.dumazet, shemminger
In-Reply-To: <1314717262.2752.11.camel@bwh-desktop>

Tue, Aug 30, 2011 at 05:14:22PM CEST, bhutchings@solarflare.com wrote:
>On Tue, 2011-08-30 at 16:46 +0200, Jiri Pirko wrote:
>> Allow to write to "carrier" attribute. Devices may implement ndo_change_carrier
>> callback to allow changing carrier from userspace.
>[...]
>> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
>> index 56e42ab..c8f2ca4 100644
>> --- a/net/core/net-sysfs.c
>> +++ b/net/core/net-sysfs.c
>> @@ -126,6 +126,30 @@ static ssize_t show_broadcast(struct device *dev,
>>  	return -EINVAL;
>>  }
>>  
>> +static ssize_t store_carrier(struct device *dev, struct device_attribute *attr,
>> +			     const char *buf, size_t len)
>> +{
>> +	struct net_device *netdev = to_net_dev(dev);
>> +	ssize_t ret;
>> +	int new_value;
>> +
>> +	if (!capable(CAP_NET_ADMIN))
>> +		return -EPERM;
>> +
>> +	if (!netif_running(netdev))
>> +		return -EINVAL;
>
>Not sure that's the right error code.

I stayed consistent with show_carrier in this.

>
>> +	if (sscanf(buf, "%d", &new_value) != 1)
>> +		return -EINVAL;
>
>kstrtoint()

Okay.

>
>(Or maybe we should have kstrobool().)
>
>> +	if (!rtnl_trylock())
>> +		return restart_syscall();
>[...]
>
>This is consistent with other attributes, but it seems like a really bad
>practice as it will generally result in the process busy-waiting on the
>RTNL lock!  I think it would be better to add and use an
>rtnl_lock_interruptible().

Right. But as you said, this is the same as with others. I would replace
this in another patch.

>
>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

* Re: [patch net-next-2.6 1/2] net: allow to change carrier via sysfs
From: Ben Hutchings @ 2011-08-30 15:14 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: netdev, davem, eric.dumazet, shemminger
In-Reply-To: <1314715608-978-2-git-send-email-jpirko@redhat.com>

On Tue, 2011-08-30 at 16:46 +0200, Jiri Pirko wrote:
> Allow to write to "carrier" attribute. Devices may implement ndo_change_carrier
> callback to allow changing carrier from userspace.
[...]
> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> index 56e42ab..c8f2ca4 100644
> --- a/net/core/net-sysfs.c
> +++ b/net/core/net-sysfs.c
> @@ -126,6 +126,30 @@ static ssize_t show_broadcast(struct device *dev,
>  	return -EINVAL;
>  }
>  
> +static ssize_t store_carrier(struct device *dev, struct device_attribute *attr,
> +			     const char *buf, size_t len)
> +{
> +	struct net_device *netdev = to_net_dev(dev);
> +	ssize_t ret;
> +	int new_value;
> +
> +	if (!capable(CAP_NET_ADMIN))
> +		return -EPERM;
> +
> +	if (!netif_running(netdev))
> +		return -EINVAL;

Not sure that's the right error code.

> +	if (sscanf(buf, "%d", &new_value) != 1)
> +		return -EINVAL;

kstrtoint()

(Or maybe we should have kstrobool().)

> +	if (!rtnl_trylock())
> +		return restart_syscall();
[...]

This is consistent with other attributes, but it seems like a really bad
practice as it will generally result in the process busy-waiting on the
RTNL lock!  I think it would be better to add and use an
rtnl_lock_interruptible().

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 net-next-2.6 2/2] dummy: implement carrier change
From: Jiri Pirko @ 2011-08-30 14:46 UTC (permalink / raw)
  To: netdev; +Cc: davem, eric.dumazet, bhutchings, shemminger
In-Reply-To: <1314715608-978-1-git-send-email-jpirko@redhat.com>

Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
 drivers/net/dummy.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index a7c5e88..1e32e14 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -112,6 +112,15 @@ static void dummy_dev_free(struct net_device *dev)
 	free_netdev(dev);
 }
 
+static int dummy_change_carrier(struct net_device *dev, bool new_carrier)
+{
+	if (new_carrier)
+		netif_carrier_on(dev);
+	else
+		netif_carrier_off(dev);
+	return 0;
+}
+
 static const struct net_device_ops dummy_netdev_ops = {
 	.ndo_init		= dummy_dev_init,
 	.ndo_start_xmit		= dummy_xmit,
@@ -119,6 +128,7 @@ static const struct net_device_ops dummy_netdev_ops = {
 	.ndo_set_rx_mode	= set_multicast_list,
 	.ndo_set_mac_address	= dummy_set_address,
 	.ndo_get_stats64	= dummy_get_stats64,
+	.ndo_change_carrier	= dummy_change_carrier,
 };
 
 static void dummy_setup(struct net_device *dev)
-- 
1.7.6

^ permalink raw reply related

* [patch net-next-2.6 1/2] net: allow to change carrier via sysfs
From: Jiri Pirko @ 2011-08-30 14:46 UTC (permalink / raw)
  To: netdev; +Cc: davem, eric.dumazet, bhutchings, shemminger
In-Reply-To: <1314715608-978-1-git-send-email-jpirko@redhat.com>

Allow to write to "carrier" attribute. Devices may implement ndo_change_carrier
callback to allow changing carrier from userspace.

Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
 include/linux/netdevice.h |    4 ++++
 net/core/dev.c            |   19 +++++++++++++++++++
 net/core/net-sysfs.c      |   26 +++++++++++++++++++++++++-
 3 files changed, 48 insertions(+), 1 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 0a7f619..6bca5b7 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -945,6 +945,8 @@ struct net_device_ops {
 						    u32 features);
 	int			(*ndo_set_features)(struct net_device *dev,
 						    u32 features);
+	int			(*ndo_change_carrier)(struct net_device *dev,
+						      bool new_carrier);
 };
 
 /*
@@ -2093,6 +2095,8 @@ extern int		dev_set_mtu(struct net_device *, int);
 extern void		dev_set_group(struct net_device *, int);
 extern int		dev_set_mac_address(struct net_device *,
 					    struct sockaddr *);
+extern int		dev_change_carrier(struct net_device *,
+					   bool new_carrier);
 extern int		dev_hard_start_xmit(struct sk_buff *skb,
 					    struct net_device *dev,
 					    struct netdev_queue *txq);
diff --git a/net/core/dev.c b/net/core/dev.c
index b2e262e..11b0fc7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4793,6 +4793,25 @@ int dev_set_mac_address(struct net_device *dev, struct sockaddr *sa)
 }
 EXPORT_SYMBOL(dev_set_mac_address);
 
+/**
+ *	dev_change_carrier - Change device carrier
+ *	@dev: device
+ *	@new_carries: new value
+ *
+ *	Change device carrier
+ */
+int dev_change_carrier(struct net_device *dev, bool new_carrier)
+{
+	const struct net_device_ops *ops = dev->netdev_ops;
+
+	if (!ops->ndo_change_carrier)
+		return -EOPNOTSUPP;
+	if (!netif_device_present(dev))
+		return -ENODEV;
+	return ops->ndo_change_carrier(dev, new_carrier);
+}
+EXPORT_SYMBOL(dev_change_carrier);
+
 /*
  *	Perform the SIOCxIFxxx calls, inside rcu_read_lock()
  */
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 56e42ab..c8f2ca4 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -126,6 +126,30 @@ static ssize_t show_broadcast(struct device *dev,
 	return -EINVAL;
 }
 
+static ssize_t store_carrier(struct device *dev, struct device_attribute *attr,
+			     const char *buf, size_t len)
+{
+	struct net_device *netdev = to_net_dev(dev);
+	ssize_t ret;
+	int new_value;
+
+	if (!capable(CAP_NET_ADMIN))
+		return -EPERM;
+
+	if (!netif_running(netdev))
+		return -EINVAL;
+
+	if (sscanf(buf, "%d", &new_value) != 1)
+		return -EINVAL;
+
+	if (!rtnl_trylock())
+		return restart_syscall();
+	ret = dev_change_carrier(netdev, new_value ? true: false);
+	rtnl_unlock();
+
+	return ret < 0 ? ret : len;
+}
+
 static ssize_t show_carrier(struct device *dev,
 			    struct device_attribute *attr, char *buf)
 {
@@ -315,7 +339,7 @@ static struct device_attribute net_class_attributes[] = {
 	__ATTR(link_mode, S_IRUGO, show_link_mode, NULL),
 	__ATTR(address, S_IRUGO, show_address, NULL),
 	__ATTR(broadcast, S_IRUGO, show_broadcast, NULL),
-	__ATTR(carrier, S_IRUGO, show_carrier, NULL),
+	__ATTR(carrier, S_IRUGO | S_IWUSR, show_carrier, store_carrier),
 	__ATTR(speed, S_IRUGO, show_speed, NULL),
 	__ATTR(duplex, S_IRUGO, show_duplex, NULL),
 	__ATTR(dormant, S_IRUGO, show_dormant, NULL),
-- 
1.7.6

^ permalink raw reply related

* [patch net-next-2.6 0/2] net: allow to change carrier via sysfs
From: Jiri Pirko @ 2011-08-30 14:46 UTC (permalink / raw)
  To: netdev; +Cc: davem, eric.dumazet, bhutchings, shemminger

As suggested by Ben Hutchings I made "carrier" attribute writeable.
With this patchset one can set carrier on/off on dummy. Might by also handy
to implement this for other devices.

Jiri Pirko (2):
  net: allow to change carrier via sysfs
  dummy: implement carrier change

 drivers/net/dummy.c       |   10 ++++++++++
 include/linux/netdevice.h |    4 ++++
 net/core/dev.c            |   19 +++++++++++++++++++
 net/core/net-sysfs.c      |   26 +++++++++++++++++++++++++-
 4 files changed, 58 insertions(+), 1 deletions(-)

-- 
1.7.6

^ permalink raw reply

* Re: 802.1Q VLAN random tag injected when vlan configured on forcedeth interface
From: Eric Dumazet @ 2011-08-30 14:42 UTC (permalink / raw)
  To: Ruslan N. Marchenko; +Cc: netdev
In-Reply-To: <20110830142310.GC28341@ruff.mobi>

Le mardi 30 août 2011 à 16:23 +0200, Ruslan N. Marchenko a écrit :
> On Tue, Aug 30, 2011 at 03:46:24PM +0200, Ruslan N. Marchenko wrote:
> > On Tue, Aug 30, 2011 at 03:23:48PM +0200, Eric Dumazet wrote:
> > > 
> > > What kernel version are you using ?
> > > 
> > Oh, sorry for missing it, it runs on 
> > Linux ruff.mobi 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:05:14 UTC 2011 i686 i686 i386 GNU/Linux
> > 
> > Just fyi - the openwrt box to which it is connected is 
> > Linux OpenWrt 2.6.39.2 #2 Fri Aug 12 09:36:23 EEST 2011 mips GNU/Linux
> > although packet drop happens even if there're no vlans configured on remote side.
> > 
> Here is double-tag sample:
> 16:20:31.151268 e0:46:9a:4e:88:1d > 00:26:18:40:21:62, ethertype 802.1Q (0x8100), length 106: vlan 2112, p 7, ethertype 802.1Q, vlan 6, p 0, ethertype IPv4, [|ip]
>         0x0000:  0026 1840 2162 e046 9a4e 881d 8100 e840
>         0x0010:  8100 0006 0800 4500 0054 abec 0000
> 
> 

Latest kernel should be fine. Some patches need to be backported by
Ubuntu team, if you can test them.

commit 9331db4f00cfee8a79d2147ac83723ef436b9759
Author: Jiri Pirko <jpirko@redhat.com>
Date:   Wed Aug 17 23:50:37 2011 -0700

    forcedeth: call vlan_mode only if hw supports vlans
    
    If hw does not support vlans, dont call nv_vlan_mode because it has no point.
    I believe that this should fix issues on older non-vlan supportive
    chips (like Ingo has).
    
    Reported-ty: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Jiri Pirko <jpirko@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 0891b0e08937aaec2c4734acb94c5ff8042313bb
Author: Jiri Pirko <jpirko@redhat.com>
Date:   Tue Jul 26 10:19:28 2011 +0000

    forcedeth: fix vlans
    
    For some reason, when rxaccel is disabled, NV_RX3_VLAN_TAG_PRESENT is
    still set and some pseudorandom vids appear. So check for
    NETIF_F_HW_VLAN_RX as well. Also set correctly hw_features and set vlan
    mode on probe.
    
    Signed-off-by: Jiri Pirko <jpirko@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 3326c784c9f492e988617d93f647ae0cfd4c8d09
Author: Jiri Pirko <jpirko@redhat.com>
Date:   Wed Jul 20 04:54:38 2011 +0000

    forcedeth: do vlan cleanup
    
    - unify vlan and nonvlan rx path
    - kill np->vlangrp and nv_vlan_rx_register
    - allow to turn on/off rx vlan accel via ethtool (set_features)
    
    Signed-off-by: Jiri Pirko <jpirko@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

^ permalink raw reply

* [PATCH 6/8] netfilter: nf_ct_tcp: fix incorrect handling of invalid TCP option
From: kaber @ 2011-08-30 14:41 UTC (permalink / raw)
  To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1314715281-26233-1-git-send-email-kaber@trash.net>

From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>

Michael M. Builov reported that in the tcp_options and tcp_sack functions
of netfilter TCP conntrack the incorrect handling of invalid TCP option
with too big opsize may lead to read access beyond tcp-packet or buffer
allocated on stack (netfilter bugzilla #738). The fix is to stop parsing
the options at detecting the broken option.

Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
 net/netfilter/nf_conntrack_proto_tcp.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 37bf943..afc4ab7 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -409,7 +409,7 @@ static void tcp_options(const struct sk_buff *skb,
 			if (opsize < 2) /* "silly options" */
 				return;
 			if (opsize > length)
-				break;	/* don't parse partial options */
+				return;	/* don't parse partial options */
 
 			if (opcode == TCPOPT_SACK_PERM
 			    && opsize == TCPOLEN_SACK_PERM)
@@ -469,7 +469,7 @@ static void tcp_sack(const struct sk_buff *skb, unsigned int dataoff,
 			if (opsize < 2) /* "silly options" */
 				return;
 			if (opsize > length)
-				break;	/* don't parse partial options */
+				return;	/* don't parse partial options */
 
 			if (opcode == TCPOPT_SACK
 			    && opsize >= (TCPOLEN_SACK_BASE
-- 
1.7.2.3

^ permalink raw reply related

* [PATCH 2/8] netfilter: ip_queue: Fix small leak in ipq_build_packet_message()
From: kaber @ 2011-08-30 14:41 UTC (permalink / raw)
  To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1314715281-26233-1-git-send-email-kaber@trash.net>

From: Jesper Juhl <jj@chaosbits.net>

ipq_build_packet_message() in net/ipv4/netfilter/ip_queue.c and
net/ipv6/netfilter/ip6_queue.c contain a small potential mem leak as
far as I can tell.

We allocate memory for 'skb' with alloc_skb() annd then call
 nlh = NLMSG_PUT(skb, 0, 0, IPQM_PACKET, size - sizeof(*nlh));

NLMSG_PUT is a macro
 NLMSG_PUT(skb, pid, seq, type, len) \
  		NLMSG_NEW(skb, pid, seq, type, len, 0)

that expands to NLMSG_NEW, which is also a macro which expands to:
 NLMSG_NEW(skb, pid, seq, type, len, flags) \
  	({	if (unlikely(skb_tailroom(skb) < (int)NLMSG_SPACE(len))) \
  			goto nlmsg_failure; \
  		__nlmsg_put(skb, pid, seq, type, len, flags); })

If we take the true branch of the 'if' statement and 'goto
nlmsg_failure', then we'll, at that point, return from
ipq_build_packet_message() without having assigned 'skb' to anything
and we'll leak the memory we allocated for it when it goes out of
scope.

Fix this by placing a 'kfree(skb)' at 'nlmsg_failure'.

I admit that I do not know how likely this to actually happen or even
if there's something that guarantees that it will never happen - I'm
not that familiar with this code, but if that is so, I've not been
able to spot it.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
 net/ipv4/netfilter/ip_queue.c  |    1 +
 net/ipv6/netfilter/ip6_queue.c |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/net/ipv4/netfilter/ip_queue.c b/net/ipv4/netfilter/ip_queue.c
index 5c9b9d9..48f7d5b 100644
--- a/net/ipv4/netfilter/ip_queue.c
+++ b/net/ipv4/netfilter/ip_queue.c
@@ -218,6 +218,7 @@ ipq_build_packet_message(struct nf_queue_entry *entry, int *errp)
 	return skb;
 
 nlmsg_failure:
+	kfree_skb(skb);
 	*errp = -EINVAL;
 	printk(KERN_ERR "ip_queue: error creating packet message\n");
 	return NULL;
diff --git a/net/ipv6/netfilter/ip6_queue.c b/net/ipv6/netfilter/ip6_queue.c
index 2493948..87b243a 100644
--- a/net/ipv6/netfilter/ip6_queue.c
+++ b/net/ipv6/netfilter/ip6_queue.c
@@ -218,6 +218,7 @@ ipq_build_packet_message(struct nf_queue_entry *entry, int *errp)
 	return skb;
 
 nlmsg_failure:
+	kfree_skb(skb);
 	*errp = -EINVAL;
 	printk(KERN_ERR "ip6_queue: error creating packet message\n");
 	return NULL;
-- 
1.7.2.3

^ 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