* RE: ixgbe: compilation failed if CONFIG_PCI_IOV isn't set
From: Rose, Gregory V @ 2011-11-07 16:47 UTC (permalink / raw)
To: Alexander Kolesen, Or Gerlitz
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, Li, Sibai
In-Reply-To: <20111107124641.GB28044@vaio>
> -----Original Message-----
> From: Alexander Kolesen [mailto:kolesen.a@gmail.com]
> Sent: Monday, November 07, 2011 4:47 AM
> To: Or Gerlitz
> Cc: Kirsher, Jeffrey T; netdev@vger.kernel.org; Rose, Gregory V; Li, Sibai
> Subject: Re: ixgbe: compilation failed if CONFIG_PCI_IOV isn't set
>
> > On Sun, Nov 6, 2011 at 5:18 AM, Jeff Kirsher
> > <jeffrey.t.kirsher@intel.com> wrote:
> > > Was with the latest kernel from David Miller's net.gt tree? I just
> ask
> > > because I just pushed a patch (a couple of days ago) to resolve
> > > compilation errors when CONFIG_PCI_IOV is not enabled by Greg Rose.
> >
> > In my case it was with Linus tree from github
> >
> > Or.
> It was with Linus tree, but David Miller's net.gt alsa has this issue.
Yeah, I'll have it fixed soon. My apologies.
- Greg
^ permalink raw reply
* Re: Bug? GRE tunnel periodically won't transmit some packets
From: Eric Dumazet @ 2011-11-07 16:55 UTC (permalink / raw)
To: Chris Siebenmann; +Cc: netdev
In-Reply-To: <20111107162117.5330236221@apps0.cs.toronto.edu>
Le lundi 07 novembre 2011 à 11:21 -0500, Chris Siebenmann a écrit :
> I have a weird problem where a GRE tunnel periodically won't transmit
> some (TCP) packets, while at the same time it will transmit others just
> fine. This is happening in the current kernel.org git head kernel as
> well as earlier ones.
>
> The networking environment is a GRE tunnel over IPSec in tunnel mode
> ('esp/tunnel/...') over a DSL PPPoE link. What I observe is that
> periodically outbound SSH connections stall early in the protocol
> negociation, and other TCP connections can similarly stall. Sometimes
> they recover and sometimes they time out. The problem is pretty
> reproducable and regular, although not constant (sometimes the affected
> packets get through right away).
>
> I have tcpdump'd both the GRE tunnel device and the underlying DSL
> PPPoE device and during a stall, the GRE tcpdump will show packets being
> sent that do not appear on the DSL PPPoE link. All of the packets that
> I've seen stalling have had 500 data octets.
>
> Typical packets are:
> IP 128.100.3.52.52063 > 128.100.3.51.ssh: Flags [.], seq 22:522, ack 22, win 91, options [nop,nop,TS val 143020 ecr 966040433], length 500
>
> (here 128.100.3.52 is the GRE tunnel IP address of the machine
> experiencing problems)
>
> or ttcp:
> IP 128.100.3.52.46585 > 128.100.3.51.5001: Flags [.], seq 1:501, ack 1, win 91, options [nop,nop,TS val 729200 ecr 979199256], length 500
>
> Ttcp had a whole run of 'length 500' packets fail to go through. SSH
> will actually successfully transmit later (different-length) packets,
> eg:
> 128.100.3.52.52063 > 128.100.3.51.ssh: Flags [P.], seq 522:926, ack 22, win 91, options [nop,nop,TS val 143037 ecr 966040450], length 404
>
> The DSL PPPoE link has an MTU of 1492 and the GRE tunnel has an MTU of
> 1200 (on both ends). As far as I can tell they do pass packets of this
> size. *However*, on kernels that display this problem tracepath and 'ip
> route show table cache' both report that the GRE tunnel has a path MTU
> of 854 going from 128.100.3.52 to 128.100.3.51; however, 128.100.3.51
> sees a pmtu of 1200 for the path to 128.100.3.52.
>
> The machine experiencing these problems is a 64-bit x86_64 Fedora 15
> machine with various kernels. The problem does not happen with the
> current Fedora 14 kernel (nominally 2.6.35.14); it does happen with the
> Fedora 15 kernel ('2.6.40.6' aka some version of 3.0.0), the Fedora 16
> kernel (some version of 3.1.0) and on the current kernel.org git head
> as of last night. I am not running NetworkManager; all networking is
> statically configured and not changing during operation, and my IPSec
> setup is statically keyed[*].
>
> I would be happy to run any debugging tests or give any further
> information that people want. Should I try a different kernel git
> repo than Linus's kernel.org one?
>
> Thanks in advance.
>
> (While I'm reading the mailing list I'm not directly subscribed to it,
> so copying me on replies will make sure that I see them immediately.)
>
Do you have any errors on :
ip -s -d link show dev greXXXX
^ permalink raw reply
* Re: [PATCH] rtl8192e: Don't copy huge struct by value (and make it const).
From: Larry Finger @ 2011-11-07 16:55 UTC (permalink / raw)
To: Jesper Juhl
Cc: devel, linux-kernel, Andrea Merello, Mike McCormack,
Greg Kroah-Hartman, netdev
In-Reply-To: <alpine.LNX.2.00.1111070017220.5763@swampdragon.chaosbits.net>
On 11/06/2011 05:21 PM, Jesper Juhl wrote:
> rtllib_is_shortslot() takes one argument - a struct that's more than a
> kilobyte large. It should take a pointer instead of copying such a
> huge struct - and the argument might as well be declared 'const' now
> that we are at it, since it is not modified. This patch makes these
> changes.
>
> Signed-off-by: Jesper Juhl<jj@chaosbits.net>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
^ permalink raw reply
* Re: commit 0bdb0bd0 breaks shutdown/reboot
From: Dominik Brodowski @ 2011-11-07 17:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20111107084540.7ffc913f@nehalam.linuxnetplumber.net>
On Mon, Nov 07, 2011 at 08:45:40AM -0800, Stephen Hemminger wrote:
> On Mon, 7 Nov 2011 17:32:27 +0100
> Dominik Brodowski <linux@dominikbrodowski.net> wrote:
>
> > On Mon, Nov 07, 2011 at 08:13:16AM -0800, Stephen Hemminger wrote:
> > > Does this help?
> >
> > Unfortunately, no. Reboots still fail.
> >
> > >
> > > Subject: sky2: block irq's on down
> > >
> > > Need to block IRQ's from phy changes to prevent stray IRQ's when
> > > device is down.
> > >
> > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > Thanks anyway,
> > Dominik
>
> Are you using Wake On Lan?
Not that I'm aware of. Explicitly disabling WOL by
$ ethtool -s eth0 wol d
does not help, though.
Best,
Dominik
^ permalink raw reply
* Re: data corruption in skge hardware
From: Stephen Hemminger @ 2011-11-07 17:13 UTC (permalink / raw)
To: Mikulas Patocka; +Cc: Stephen Hemminger, netdev
In-Reply-To: <Pine.LNX.4.64.1111071109410.18030@hs20-bc2-1.build.redhat.com>
On Mon, 7 Nov 2011 11:42:11 -0500 (EST)
Mikulas Patocka <mpatocka@redhat.com> wrote:
> Hi
>
> I found a data corruption in skge network card.
>
> The card is this: "03:06.0 Ethernet controller: 3Com Corporation 3c940
> 10/100/1000Base-T [Marvell] (rev 10)"
>
> The machine is two quad core Opterons with HT2000 north bridge and HT1000
> south bridge.
>
> When "scatter-gather" and "generic-segmentation-offload" are enabled, the
> card sends out corrupted packets.
>
> It normally manifests as a ssh connection drop once per few days, but I
> found a workload that triggers this bug quickly.
>
> I ran tcpdump on both sending and receiving machine and caught the packet
> corruption:
>
> correct packet (on the sending machine):
> 19:03:21.131836 IP hydra.ssh > phoebe.58913: Flags [P.], seq 53712:53808,
> ack 1, win 193, options [nop,nop,TS val 8677173 ecr 1211608], length 96
> 0x0000: 4510 0094 c7bf 4000 4006 f12d c0a8 8007
> 0x0010: c0a8 800e 0016 e621 2d64 84e6 1fc2 3f5b
> 0x0020: 8018 00c1 81ed 0000 0101 080a 0084 6735
> 0x0030: 0012 7cd8 4301 4af9 87c9 d2b4 8ba6 aedb
> 0x0040: 0572 1738 93db 789c 634b 4386 d013 db27
> 0x0050: 258b 6fa6 743c d429 a5e1 162f 2721 19bf
> 0x0060: 6669 a5c3 6bea 89ec a635 b8b4 8727 38c1
> 0x0070: 139f 5989 781b 49dd 79f5 4dfe 78ac ecb0
> 0x0080: 546c 33e0 0953 04bc 0647 a9d4 2fc4 cba0
> 0x0090: 44b2 3b01
>
> incorrect packet (on the receiving machine):
> 19:03:21.133174 IP hydra.ssh > phoebe.58913: Flags [P.], seq 53712:53808,
> ack 1, win 193, options [nop,nop,TS val 8677173 ecr 1211608], length 96
> 0x0000: 4510 0094 c7bf 4000 4006 f12d c0a8 8007
> 0x0010: c0a8 800e 0016 e621 2d64 84e6 1fc2 3f5b
> 0x0020: 8018 00c1 6aa4 0000 0101 080a 0084 6735
> 0x0030: 0012 7cd8 0000 0000 0000 0000 0010 0000
> 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000
> 0x0050: 0000 0000 0000 0000 0000 00c0 dc92 4702
> 0x0060: 88ff ff00 0000 0000 0000 0000 0000 0000
> 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000
> 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000
> 0x0090: 0000 00e0
>
> Obviously, scatter-gather doesn't work, the header is correct, but the
> packet body was likely read from random memory.
>
> I tried to use "clflush" instruction on the transmit descriptor and the
> packet body to test if it is a cache-coherency issue, but the corruption
> was still there.
>
> I tried to limit memory to 2G to test if it was a problem with high
> memory, but the corruption was still there.
>
> I tries olded kernels (as far as 2.6.34), the corruption was still there,
> but it took much more time to trigger it with old kernels.
>
>
> Do you have other reports of data corruption with skge hardware? Shouldn't
> the driver set "scatter-gather" off by default because it is unreliable?
No reports, of problems.
Scatter-gather is used all the time by normal TCP connections.
I suspect something different because of the IOMMU and separate sockets.
^ permalink raw reply
* RE: [PATCH v5 04/10] per-cgroup tcp buffers control
From: Glauber Costa @ 2011-11-07 17:28 UTC (permalink / raw)
To: Glauber Costa, linux-kernel@vger.kernel.org
Cc: paul@paulmenage.org, lizf@cn.fujitsu.com,
kamezawa.hiroyu@jp.fujitsu.com, ebiederm@xmission.com,
davem@davemloft.net, gthelen@google.com, netdev@vger.kernel.org,
linux-mm@kvack.org, kirill@shutemov.name, Andrey Vagin,
devel@openvz.org, eric.dumazet@gmail.com, Glauber Costa,
kamezawa.hiroyu@jp.fujtisu.com
Ok, I forgot to change the temporary name I was using for the jump label. Shame on me :)
--- Mensagem Original ---
De: Glauber Costa <glommer@parallels.com>
Enviado: 7 de novembro de 2011 07/11/11
Para: linux-kernel@vger.kernel.org
Cc: paul@paulmenage.org, lizf@cn.fujitsu.com, kamezawa.hiroyu@jp.fujitsu.com, ebiederm@xmission.com, davem@davemloft.net, gthelen@google.com, netdev@vger.kernel.org, linux-mm@kvack.org, kirill@shutemov.name, Andrey Vagin <avagin@parallels.com>, devel@openvz.org, eric.dumazet@gmail.com, Glauber Costa <glommer@parallels.com>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujtisu.com>
Assunto: [PATCH v5 04/10] per-cgroup tcp buffers control
With all the infrastructure in place, this patch implements
per-cgroup control for tcp memory pressure handling.
A resource conter is used to control allocated memory, except
for the root cgroup, that will keep using global counters.
This patch is the one that actually enables/disables the
jump labels controlling cgroup. To this point, they were always
disabled.
Signed-off-by: Glauber Costa <glommer@parallels.com>
CC: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujtisu.com>
CC: David S. Miller <davem@davemloft.net>
CC: Eric W. Biederman <ebiederm@xmission.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/tcp.h | 18 +++++++
include/net/transp_v6.h | 1 +
mm/memcontrol.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++-
net/core/sock.c | 46 +++++++++++++++--
net/ipv4/af_inet.c | 3 +
net/ipv4/tcp_ipv4.c | 12 +++++
net/ipv6/af_inet6.c | 3 +
net/ipv6/tcp_ipv6.c | 10 ++++
8 files changed, 211 insertions(+), 7 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index ccaa3b6..7301ca8 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -253,6 +253,22 @@ extern int sysctl_tcp_cookie_size;
extern int sysctl_tcp_thin_linear_timeouts;
extern int sysctl_tcp_thin_dupack;
+struct tcp_memcontrol {
+ /* per-cgroup tcp memory pressure knobs */
+ struct res_counter tcp_memory_allocated;
+ struct percpu_counter tcp_sockets_allocated;
+ /* those two are read-mostly, leave them at the end */
+ long tcp_prot_mem[3];
+ int tcp_memory_pressure;
+};
+
+long *sysctl_mem_tcp(struct mem_cgroup *memcg);
+struct percpu_counter *sockets_allocated_tcp(struct mem_cgroup *memcg);
+int *memory_pressure_tcp(struct mem_cgroup *memcg);
+struct res_counter *memory_allocated_tcp(struct mem_cgroup *memcg);
+int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss);
+void tcp_destroy_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss);
+
extern atomic_long_t tcp_memory_allocated;
extern struct percpu_counter tcp_sockets_allocated;
extern int tcp_memory_pressure;
@@ -305,6 +321,7 @@ static inline int tcp_synq_no_recent_overflow(const struct sock *sk)
}
extern struct proto tcp_prot;
+extern struct cg_proto tcp_cg_prot;
#define TCP_INC_STATS(net, field) SNMP_INC_STATS((net)->mib.tcp_statistics, field)
#define TCP_INC_STATS_BH(net, field) SNMP_INC_STATS_BH((net)->mib.tcp_statistics, field)
@@ -1022,6 +1039,7 @@ static inline void tcp_openreq_init(struct request_sock *req,
ireq->loc_port = tcp_hdr(skb)->dest;
}
+extern void tcp_enter_memory_pressure_cg(struct sock *sk);
extern void tcp_enter_memory_pressure(struct sock *sk);
static inline int keepalive_intvl_when(const struct tcp_sock *tp)
diff --git a/include/net/transp_v6.h b/include/net/transp_v6.h
index 498433d..1e18849 100644
--- a/include/net/transp_v6.h
+++ b/include/net/transp_v6.h
@@ -11,6 +11,7 @@ extern struct proto rawv6_prot;
extern struct proto udpv6_prot;
extern struct proto udplitev6_prot;
extern struct proto tcpv6_prot;
+extern struct cg_proto tcpv6_cg_prot;
struct flowi6;
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 7d684d0..f14d7d2 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -49,6 +49,9 @@
#include <linux/cpu.h>
#include <linux/oom.h>
#include "internal.h"
+#ifdef CONFIG_INET
+#include <net/tcp.h>
+#endif
#include <asm/uaccess.h>
@@ -294,6 +297,10 @@ struct mem_cgroup {
*/
struct mem_cgroup_stat_cpu nocpu_base;
spinlock_t pcp_counter_lock;
+
+#ifdef CONFIG_INET
+ struct tcp_memcontrol tcp;
+#endif
};
/* Stuffs for move charges at task migration. */
@@ -377,7 +384,7 @@ enum mem_type {
#define MEM_CGROUP_RECLAIM_SOFT (1 << MEM_CGROUP_RECLAIM_SOFT_BIT)
static struct mem_cgroup *parent_mem_cgroup(struct mem_cgroup *memcg);
-
+static struct mem_cgroup *mem_cgroup_from_cont(struct cgroup *cont);
static inline bool mem_cgroup_is_root(struct mem_cgroup *mem)
{
return (mem == root_mem_cgroup);
@@ -387,6 +394,7 @@ static inline bool mem_cgroup_is_root(struct mem_cgroup *mem)
#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
#ifdef CONFIG_INET
#include <net/sock.h>
+#include <net/ip.h>
void sock_update_memcg(struct sock *sk)
{
@@ -451,6 +459,93 @@ u64 memcg_memory_allocated_read(struct mem_cgroup *memcg, struct cg_proto *prot)
RES_USAGE) >> PAGE_SHIFT ;
}
EXPORT_SYMBOL(memcg_memory_allocated_read);
+/*
+ * Pressure flag: try to collapse.
+ * Technical note: it is used by multiple contexts non atomically.
+ * All the __sk_mem_schedule() is of this nature: accounting
+ * is strict, actions are advisory and have some latency.
+ */
+void tcp_enter_memory_pressure_cg(struct sock *sk)
+{
+ struct mem_cgroup *memcg = sk->sk_cgrp;
+ if (!memcg->tcp.tcp_memory_pressure) {
+ NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPMEMORYPRESSURES);
+ memcg->tcp.tcp_memory_pressure = 1;
+ }
+}
+EXPORT_SYMBOL(tcp_enter_memory_pressure_cg);
+
+long *sysctl_mem_tcp(struct mem_cgroup *memcg)
+{
+ return memcg
^ permalink raw reply related
* Re: data corruption in skge hardware
From: Mikulas Patocka @ 2011-11-07 17:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20111107091327.79a8c6da@nehalam.linuxnetplumber.net>
On Mon, 7 Nov 2011, Stephen Hemminger wrote:
> On Mon, 7 Nov 2011 11:42:11 -0500 (EST)
> Mikulas Patocka <mpatocka@redhat.com> wrote:
>
> > Hi
> >
> > I found a data corruption in skge network card.
> >
> > The card is this: "03:06.0 Ethernet controller: 3Com Corporation 3c940
> > 10/100/1000Base-T [Marvell] (rev 10)"
> >
> > The machine is two quad core Opterons with HT2000 north bridge and HT1000
> > south bridge.
> >
> > When "scatter-gather" and "generic-segmentation-offload" are enabled, the
> > card sends out corrupted packets.
> >
> > It normally manifests as a ssh connection drop once per few days, but I
> > found a workload that triggers this bug quickly.
> >
> > I ran tcpdump on both sending and receiving machine and caught the packet
> > corruption:
> >
> > correct packet (on the sending machine):
> > 19:03:21.131836 IP hydra.ssh > phoebe.58913: Flags [P.], seq 53712:53808,
> > ack 1, win 193, options [nop,nop,TS val 8677173 ecr 1211608], length 96
> > 0x0000: 4510 0094 c7bf 4000 4006 f12d c0a8 8007
> > 0x0010: c0a8 800e 0016 e621 2d64 84e6 1fc2 3f5b
> > 0x0020: 8018 00c1 81ed 0000 0101 080a 0084 6735
> > 0x0030: 0012 7cd8 4301 4af9 87c9 d2b4 8ba6 aedb
> > 0x0040: 0572 1738 93db 789c 634b 4386 d013 db27
> > 0x0050: 258b 6fa6 743c d429 a5e1 162f 2721 19bf
> > 0x0060: 6669 a5c3 6bea 89ec a635 b8b4 8727 38c1
> > 0x0070: 139f 5989 781b 49dd 79f5 4dfe 78ac ecb0
> > 0x0080: 546c 33e0 0953 04bc 0647 a9d4 2fc4 cba0
> > 0x0090: 44b2 3b01
> >
> > incorrect packet (on the receiving machine):
> > 19:03:21.133174 IP hydra.ssh > phoebe.58913: Flags [P.], seq 53712:53808,
> > ack 1, win 193, options [nop,nop,TS val 8677173 ecr 1211608], length 96
> > 0x0000: 4510 0094 c7bf 4000 4006 f12d c0a8 8007
> > 0x0010: c0a8 800e 0016 e621 2d64 84e6 1fc2 3f5b
> > 0x0020: 8018 00c1 6aa4 0000 0101 080a 0084 6735
> > 0x0030: 0012 7cd8 0000 0000 0000 0000 0010 0000
> > 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000
> > 0x0050: 0000 0000 0000 0000 0000 00c0 dc92 4702
> > 0x0060: 88ff ff00 0000 0000 0000 0000 0000 0000
> > 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000
> > 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000
> > 0x0090: 0000 00e0
> >
> > Obviously, scatter-gather doesn't work, the header is correct, but the
> > packet body was likely read from random memory.
> >
> > I tried to use "clflush" instruction on the transmit descriptor and the
> > packet body to test if it is a cache-coherency issue, but the corruption
> > was still there.
> >
> > I tried to limit memory to 2G to test if it was a problem with high
> > memory, but the corruption was still there.
> >
> > I tries olded kernels (as far as 2.6.34), the corruption was still there,
> > but it took much more time to trigger it with old kernels.
> >
> >
> > Do you have other reports of data corruption with skge hardware? Shouldn't
> > the driver set "scatter-gather" off by default because it is unreliable?
>
> No reports, of problems.
> Scatter-gather is used all the time by normal TCP connections.
> I suspect something different because of the IOMMU and separate sockets.
This card has 64-bit addressing, so it doesn't use IOMMU. Or does it?
Anyway, if I booted with 2G RAM, IOMMU was disabled and the corruption was
still there.
Mikulas
^ permalink raw reply
* Re: [PATCH v2] usbnet: fix oops in usbnet_start_xmit
From: Richard Cochran @ 2011-11-07 17:39 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: Oliver Neukum, Michael Riesch, Alexey Orishko, netdev,
David S. Miller, devel
In-Reply-To: <20111107145458.29997.79829.stgit@zurg>
On Mon, Nov 07, 2011 at 06:54:58PM +0300, Konstantin Khlebnikov wrote:
> This patch fixes the bug added in commit v3.1-rc7-1055-gf9b491e
> SKB can be NULL at this point, at least for cdc-ncm.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Acked-by: Richard Cochran <richardcochran@gmail.com>
> ---
> drivers/net/usb/usbnet.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 7d60821..fae0fbd 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -1057,7 +1057,8 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
> unsigned long flags;
> int retval;
>
> - skb_tx_timestamp(skb);
> + if (skb)
> + skb_tx_timestamp(skb);
>
> // some devices want funky USB-level framing, for
> // win32 driver (usually) and/or hardware quirks
>
^ permalink raw reply
* [net-ext PATCH] ixgbe: Fix compile for kernel without CONFIG_PCI_IOV defined
From: Greg Rose @ 2011-11-07 17:44 UTC (permalink / raw)
To: netdev; +Cc: davem
Fix compiler errors and warnings with CONFIG_PCI_IOV defined and not
defined.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index db95731..00fcd39 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -442,12 +442,14 @@ static int ixgbe_set_vf_macvlan(struct ixgbe_adapter *adapter,
int ixgbe_check_vf_assignment(struct ixgbe_adapter *adapter)
{
+#ifdef CONFIG_PCI_IOV
int i;
for (i = 0; i < adapter->num_vfs; i++) {
if (adapter->vfinfo[i].vfdev->dev_flags &
PCI_DEV_FLAGS_ASSIGNED)
return true;
}
+#endif
return false;
}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
index 4a5d889..df04f1a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
@@ -42,11 +42,11 @@ int ixgbe_ndo_set_vf_spoofchk(struct net_device *netdev, int vf, bool setting);
int ixgbe_ndo_get_vf_config(struct net_device *netdev,
int vf, struct ifla_vf_info *ivi);
void ixgbe_check_vf_rate_limit(struct ixgbe_adapter *adapter);
-#ifdef CONFIG_PCI_IOV
void ixgbe_disable_sriov(struct ixgbe_adapter *adapter);
+int ixgbe_check_vf_assignment(struct ixgbe_adapter *adapter);
+#ifdef CONFIG_PCI_IOV
void ixgbe_enable_sriov(struct ixgbe_adapter *adapter,
const struct ixgbe_info *ii);
-int ixgbe_check_vf_assignment(struct ixgbe_adapter *adapter);
#endif
^ permalink raw reply related
* RE: linux-next: build failure after merge of the origin tree
From: Rose, Gregory V @ 2011-11-07 17:46 UTC (permalink / raw)
To: Rose, Gregory V, Kirsher, Jeffrey T, David Miller
Cc: sfr@canb.auug.org.au, torvalds@linux-foundation.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <43F901BD926A4E43B106BF17856F075501A1CCA399@orsmsx508.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Rose, Gregory V
> Sent: Monday, November 07, 2011 8:47 AM
> To: Kirsher, Jeffrey T; David Miller
> Cc: sfr@canb.auug.org.au; torvalds@linux-foundation.org; linux-
> next@vger.kernel.org; linux-kernel@vger.kernel.org; netdev@vger.kernel.org
> Subject: RE: linux-next: build failure after merge of the origin tree
>
>
>
> > -----Original Message-----
> > From: Kirsher, Jeffrey T
> > Sent: Sunday, November 06, 2011 9:30 PM
> > To: David Miller
> > Cc: sfr@canb.auug.org.au; torvalds@linux-foundation.org; linux-
> > next@vger.kernel.org; linux-kernel@vger.kernel.org; Rose, Gregory V;
> > netdev@vger.kernel.org
> > Subject: Re: linux-next: build failure after merge of the origin tree
> >
> >
> >
> > Cheers,
> > Jeff
> >
> > On Nov 6, 2011, at 19:38, "David Miller" <davem@davemloft.net> wrote:
> >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Mon, 7 Nov 2011 13:47:06 +1100
> > >
> > >>> If you just revert the commit in origin from -next, then you will
> get
> > >>> conflicts with you pull the net.git tree in.
> > >>
> > >> I got no conflicts when I merged in the net tree and can see no fix
> for
> > >> this problem in the net tree. My current head of the net tree is
> > 1a6422f
> > >> "etherh: Add MAINTAINERS entry for etherh".
> > >
> > > Ok, Jeff please take a look at this and send me a fix soon.
> > >
> > > Thanks.
> >
> > Ok Dave, at this point, I am puttying together a patch to revert this
> fix
> > since it appears that more trouble comes with this fix. I will take a
> > look at it quickly before sending out a patch to fix the issue.
>
> My bad... I fixed a compiler warning that occurred with CONFIG_PCI_IOV
> turned on and didn't realize that my patch would cause an error when
> turning it back off.
>
> I'll have it fixed ASAP.
>
> - Greg
I have posted a fix for this problem to netdev and attached it to this email.
Again, my apologies for the mix up.
- Greg
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Type: message/rfc822, Size: 5342 bytes --]
From: "Rose, Gregory V" <gregory.v.rose@intel.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "davem@davemloft.net" <davem@davemloft.net>
Subject: [net-ext PATCH] ixgbe: Fix compile for kernel without CONFIG_PCI_IOV defined
Date: Mon, 7 Nov 2011 09:44:17 -0800
Message-ID: <20111107174417.8638.87569.stgit@gitlad.jf.intel.com>
Fix compiler errors and warnings with CONFIG_PCI_IOV defined and not
defined.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index db95731..00fcd39 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -442,12 +442,14 @@ static int ixgbe_set_vf_macvlan(struct ixgbe_adapter *adapter,
int ixgbe_check_vf_assignment(struct ixgbe_adapter *adapter)
{
+#ifdef CONFIG_PCI_IOV
int i;
for (i = 0; i < adapter->num_vfs; i++) {
if (adapter->vfinfo[i].vfdev->dev_flags &
PCI_DEV_FLAGS_ASSIGNED)
return true;
}
+#endif
return false;
}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
index 4a5d889..df04f1a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
@@ -42,11 +42,11 @@ int ixgbe_ndo_set_vf_spoofchk(struct net_device *netdev, int vf, bool setting);
int ixgbe_ndo_get_vf_config(struct net_device *netdev,
int vf, struct ifla_vf_info *ivi);
void ixgbe_check_vf_rate_limit(struct ixgbe_adapter *adapter);
-#ifdef CONFIG_PCI_IOV
void ixgbe_disable_sriov(struct ixgbe_adapter *adapter);
+int ixgbe_check_vf_assignment(struct ixgbe_adapter *adapter);
+#ifdef CONFIG_PCI_IOV
void ixgbe_enable_sriov(struct ixgbe_adapter *adapter,
const struct ixgbe_info *ii);
-int ixgbe_check_vf_assignment(struct ixgbe_adapter *adapter);
#endif
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [net-ext PATCH] ixgbe: Fix compile for kernel without CONFIG_PCI_IOV defined
From: David Miller @ 2011-11-07 18:23 UTC (permalink / raw)
To: gregory.v.rose; +Cc: netdev
In-Reply-To: <20111107174417.8638.87569.stgit@gitlad.jf.intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
Date: Mon, 07 Nov 2011 09:44:17 -0800
> Fix compiler errors and warnings with CONFIG_PCI_IOV defined and not
> defined.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
It's "net-next" not "net-ext" :-)
Applied, thanks.
^ permalink raw reply
* RE: [net-ext PATCH] ixgbe: Fix compile for kernel without CONFIG_PCI_IOV defined
From: Rose, Gregory V @ 2011-11-07 18:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20111107.132340.124929090969671336.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, November 07, 2011 10:24 AM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org
> Subject: Re: [net-ext PATCH] ixgbe: Fix compile for kernel without
> CONFIG_PCI_IOV defined
>
> From: Greg Rose <gregory.v.rose@intel.com>
> Date: Mon, 07 Nov 2011 09:44:17 -0800
>
> > Fix compiler errors and warnings with CONFIG_PCI_IOV defined and not
> > defined.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
>
> It's "net-next" not "net-ext" :-)
>
> Applied, thanks.
Ugh... I'm really stepping in it deep.
Thanks Dave,
- Greg
^ permalink raw reply
* Re: [PATCH v2] usbnet: fix oops in usbnet_start_xmit
From: David Miller @ 2011-11-07 18:26 UTC (permalink / raw)
To: richardcochran
Cc: khlebnikov, oneukum, michael, alexey.orishko, netdev, devel
In-Reply-To: <20111107173919.GA2730@netboy.at.omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Mon, 7 Nov 2011 18:39:19 +0100
> On Mon, Nov 07, 2011 at 06:54:58PM +0300, Konstantin Khlebnikov wrote:
>> This patch fixes the bug added in commit v3.1-rc7-1055-gf9b491e
>> SKB can be NULL at this point, at least for cdc-ncm.
>>
>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
>
> Acked-by: Richard Cochran <richardcochran@gmail.com>
Applied, but the overall logic in the usbnet transmit path definitely
could use a good reconsideration and cleanup.
I'm even open to having generic support at the generic net device TX
level to fixup the segmentation layout of the SKB so that it meets
the device's requirements. We can do it more efficiently there too.
^ permalink raw reply
* Re: [PATCH 3/3] wanrouter: Remove kernel_lock annotations
From: David Miller @ 2011-11-07 18:27 UTC (permalink / raw)
To: richard; +Cc: netdev, linux-kernel
In-Reply-To: <1320654261-4473-1-git-send-email-richard@nod.at>
From: Richard Weinberger <richard@nod.at>
Date: Mon, 7 Nov 2011 09:24:21 +0100
> The BKL is gone, these annotations are useless.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
Applied, thanks Richard.
^ permalink raw reply
* Re: [PATCH resend] MAINTAINERS/rds: update maintainer
From: David Miller @ 2011-11-07 18:28 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev
In-Reply-To: <alpine.LRH.2.00.1111071114280.20919@ogerlitz.voltaire.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Mon, 7 Nov 2011 11:39:49 +0200
> update for the actual maintainer
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH] route: fix ICMP secure_redirects
From: David Miller @ 2011-11-07 18:35 UTC (permalink / raw)
To: fbl; +Cc: netdev
In-Reply-To: <1320680505-26367-1-git-send-email-fbl@redhat.com>
From: Flavio Leitner <fbl@redhat.com>
Date: Mon, 7 Nov 2011 13:41:45 -0200
> It should accept ICMP redirects from any host and not
> just from gateways when secure_redirects is disabled.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
This is changing the default behavior, and could break things for people.
We have sort-of discussed this already, and agreed that the tests made in
this code before my inetpeer reworking had to be reinstated exactly as it
was.
^ permalink raw reply
* Re: [PATCH 6/7] fsl_pmc: Add API to enable device as wakeup event source
From: Scott Wood @ 2011-11-07 18:41 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Zhao Chenhui-B35336, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <CAOZdJXXB9zJWqC+kPq7ZDdzePtp8XNBnWcf5UmE8Ye50U-G7Dg@mail.gmail.com>
On 11/04/2011 07:08 PM, Tabi Timur-B04825 wrote:
> On Fri, Nov 4, 2011 at 7:39 AM, Zhao Chenhui <chenhui.zhao@freescale.com> wrote:
>> + /* clear to enable clock in low power mode */
>> + if (enable)
>> + clrbits32(&pmc_regs->pmcdr, *pmcdr_mask);
>> + else
>> + setbits32(&pmc_regs->pmcdr, *pmcdr_mask);
>
> You need to use be32_to_cpup() when dereferencing a pointer to a
> device tree property.
Or just use of_property_read_u32().
-Scott
^ permalink raw reply
* Re: [PATCH net v5 0/5] forcedeth: minor fixes for stats, rmmod, sparse
From: David Miller @ 2011-11-07 18:44 UTC (permalink / raw)
To: david.decotigny
Cc: netdev, linux-kernel, ian.campbell, eric.dumazet,
jeffrey.t.kirsher, jpirko, joe, szymon
In-Reply-To: <cover.1320539724.git.david.decotigny@google.com>
From: David Decotigny <david.decotigny@google.com>
Date: Sat, 5 Nov 2011 17:38:19 -0700
> This is a minor update over v4, re-adding a patch I left aside to
> study it.
All applied, thanks.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-11-07 18:45 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) The IXGBE build fix wrt. CONFIG_PCI_IOV from Gregory Rose.
2) Fixes for module unload races and statistic problems in forcedeth from
david decotigny, Mike Ditto, and Mandeep Baines.
3) Kill stray BKL references from wanrouter code, from Richard Weinberger.
4) usbnet oopses due to unguarded skb_tx_timestamp() check, fix from
Konstantin Khlebnikov.
5) tg3 driver bug fixes from Matt Carlson.
6) Fix bogus compare of u8 with -1 in bonding, from Dan Carpenter.
7) Netlink message validation fix from Johannes Berg.
8) Fix sky2 driver regression on Yukon Optima chips, from Stephen Hemminger.
Please pull, thanks a lot!
The following changes since commit 83dbb15e9cd78a3619e3db36777e2f81d09b2914:
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux (2011-11-07 10:01:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
Andres Salomon (1):
libertas: ensure we clean up a scan request properly
Christian Lamparter (1):
carl9170: fix AMPDU TX_CTL_REQ_TX_STATUS handling
Dan Carpenter (1):
bonding: comparing a u8 with -1 is always false
David Herrmann (4):
Bluetooth: ath3k: Use GFP_KERNEL instead of GFP_ATOMIC
Bluetooth: bcm203x: Fix race condition on disconnect
Bluetooth: bcm203x: Use GFP_KERNEL in workqueue
Bluetooth: bfusb: Fix error path on firmware load
David S. Miller (1):
Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless
Eliad Peller (2):
mac80211: fix remain_off_channel regression
mac80211: config hw when going back on-channel
Emmanuel Grumbach (1):
iwlagn: fix the race in the unmapping of the HCMD
Jeff Kirsher (2):
i825xx:xscale:8390:freescale: Fix Kconfig dependancies
etherh: Add MAINTAINERS entry for etherh
Johan Hedberg (1):
Bluetooth: Set HCI_MGMT flag only in read_controller_info
Johannes Berg (4):
mac80211: disable powersave for broken APs
mac80211: warn only once about not finding a rate
netlink: validate NLA_MSECS length
netlink: clarify attribute length check documentation
John W. Linville (2):
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Jouni Malinen (1):
mac80211: Fix TDLS support validation in add_station handler
Konstantin Khlebnikov (1):
usbnet: fix oops in usbnet_start_xmit
Larry Finger (1):
b43: Remove unneeded message
Mandeep Baines (1):
forcedeth: Improve stats counters
Matt Carlson (8):
tg3: Fix APE mutex init and use
tg3: Fix 4k tx bd segmentation code
tg3: Fix 4k skb error recovery path
tg3: Fix irq alloc error cleanup path
tg3: Obtain PCI function number from device
tg3: Schedule at most one tg3_reset_task run
tg3: Eliminate timer race with reset_task
tg3: Update version to 3.121
Mike Ditto (1):
forcedeth: Acknowledge only interrupts that are being processed
Or Gerlitz (1):
MAINTAINERS/rds: update maintainer
Rajkumar Manoharan (5):
ath9k_hw: Fix regression of register offset for AR9003 chips
ath9k_hw: Fix radio retention for AR9462
ath9k_hw: Fix regression of register offset of AR9330/AR9340
ath9k_hw: Update AR9485 initvals to fix system hang issue
ath9k_hw: Fix noise floor calibration timeout on fast channel change
Richard Weinberger (1):
wanrouter: Remove kernel_lock annotations
Rose, Gregory V (1):
ixgbe: Fix compile for kernel without CONFIG_PCI_IOV defined
Szymon Janc (2):
Bluetooth: rfcomm: Fix sleep in invalid context in rfcomm_security_cfm
Bluetooth: Increase HCI reset timeout in hci_dev_do_close
Wey-Yi Guy (2):
iwlwifi: allow pci_enable_msi fail
iwlwifi: don't perform "echo test" when cmd queue stuck
david decotigny (3):
forcedeth: fix race when unloading module
forcedeth: remove unneeded stats updates
forcedeth: fix a few sparse warnings (variable shadowing)
stephen hemminger (2):
macvlan: receive multicast with local address
sky2: fix regression on Yukon Optima
MAINTAINERS | 3 +-
drivers/bluetooth/ath3k.c | 4 +-
drivers/bluetooth/bcm203x.c | 12 ++-
drivers/bluetooth/bfusb.c | 13 +-
drivers/net/bonding/bond_main.c | 4 +-
drivers/net/bonding/bond_procfs.c | 4 +-
drivers/net/ethernet/broadcom/tg3.c | 195 ++++++++++++----------
drivers/net/ethernet/broadcom/tg3.h | 21 ++-
drivers/net/ethernet/freescale/Kconfig | 3 +-
drivers/net/ethernet/intel/Kconfig | 6 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 4 +-
drivers/net/ethernet/marvell/sky2.c | 11 --
drivers/net/ethernet/natsemi/Kconfig | 5 +-
drivers/net/ethernet/nvidia/forcedeth.c | 88 ++++-------
drivers/net/macvlan.c | 7 +
drivers/net/usb/usbnet.c | 3 +-
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 4 -
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 11 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 34 ++--
drivers/net/wireless/ath/ath9k/ar9485_initvals.h | 10 +-
drivers/net/wireless/ath/ath9k/hw.c | 3 +
drivers/net/wireless/ath/carl9170/tx.c | 11 +-
drivers/net/wireless/b43/xmit.c | 1 -
drivers/net/wireless/iwlwifi/iwl-core.c | 10 -
drivers/net/wireless/iwlwifi/iwl-pci.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c | 12 +-
drivers/net/wireless/libertas/cfg.c | 25 ++-
drivers/net/wireless/libertas/cfg.h | 1 +
drivers/net/wireless/libertas/main.c | 6 +-
include/linux/ethtool.h | 2 +
include/net/bluetooth/rfcomm.h | 1 +
include/net/mac80211.h | 3 +-
include/net/netlink.h | 11 +-
lib/nlattr.c | 1 +
net/bluetooth/hci_core.c | 2 +-
net/bluetooth/mgmt.c | 2 -
net/bluetooth/rfcomm/core.c | 9 +-
net/mac80211/cfg.c | 12 +-
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/mlme.c | 18 ++-
net/mac80211/work.c | 7 +-
net/wanrouter/wanproc.c | 2 -
43 files changed, 325 insertions(+), 267 deletions(-)
^ permalink raw reply
* patch "workflow" - what deferred state means?
From: Maz The Northener @ 2011-11-07 19:07 UTC (permalink / raw)
To: netdev
Hi!
I sent a few versions of a patch to the netdev some days ago. I
recently stumbled upon patchwork website, and noticed that the latest
versions of my patches had "deferred" state. I tried searching for
what that means, but only thing I managed to find was Uboot project's
explanation. They used deferred state to mean that patch in question
depends on something not currently in source tree. I doubt that's the
case here though. Maybe it is because my patch was created against rc4
kernel.
I was just wondering if I could do some conclusion based on the state.
I naturally am keen to know if patch is rejected, or if it stil may
end up in kernel, or if there is something I could still do in order
to improve the situation? Maybe creating the patch against new 3.1
kernel would help you?
So is the different states of patches explained somewhere?
--Matti Vaittinen
^ permalink raw reply
* Re: [PATCH] route: fix ICMP secure_redirects
From: Flavio Leitner @ 2011-11-07 19:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111107.133541.808346933690781560.davem@davemloft.net>
On Mon, 07 Nov 2011 13:35:41 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> From: Flavio Leitner <fbl@redhat.com>
> Date: Mon, 7 Nov 2011 13:41:45 -0200
>
> > It should accept ICMP redirects from any host and not
> > just from gateways when secure_redirects is disabled.
> >
> > Signed-off-by: Flavio Leitner <fbl@redhat.com>
>
> This is changing the default behavior, and could break things for
> people.
>
> We have sort-of discussed this already, and agreed that the tests
> made in this code before my inetpeer reworking had to be reinstated
> exactly as it was.
Right, so I cannot change either values 0 or 1 then. For some
reason I thought I couldn't change only the default behavior.
I will think on something else then.
thanks,
fbl
^ permalink raw reply
* Re: patch "workflow" - what deferred state means?
From: David Miller @ 2011-11-07 19:14 UTC (permalink / raw)
To: mazziesaccount; +Cc: netdev
In-Reply-To: <CANhJrGNsyD1vsRA4xhgD3KrY9ZcdNOyM4JsM+kf71Pt9KTqh-Q@mail.gmail.com>
From: Maz The Northener <mazziesaccount@gmail.com>
Date: Mon, 7 Nov 2011 21:07:45 +0200
> So is the different states of patches explained somewhere?
Tell us what specific patch you're talking about and maybe we
can give you an answer.
^ permalink raw reply
* RE: [PATCH] net, wireless, mwifiex: Fix mem leak in mwifiex_update_curr_bss_params()
From: Bing Zhao @ 2011-11-07 19:27 UTC (permalink / raw)
To: Srivatsa S. Bhat, Jesper Juhl
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, John W. Linville
In-Reply-To: <4EB70920.80905@linux.vnet.ibm.com>
> On 11/07/2011 03:28 AM, Jesper Juhl wrote:
> > If kmemdup() fails we leak the memory allocated to bss_desc.
> > This patch fixes the leak.
> > I also removed the pointless default assignment of 'NULL' to 'bss_desc'
> > while I was there anyway.
> >
> > Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Hi Jesper,
Thanks for the patch.
>
> Looks good to me.
> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Hi Srivatsa,
Thanks for your review.
Acked-by: Bing Zhao <bzhao@marvell.com>
Thanks,
Bing
>
> Thanks,
> Srivatsa S. Bhat
>
> > ---
> > drivers/net/wireless/mwifiex/scan.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > note: patch is compile tested only since I don't have the hardware.
> >
> > diff --git a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
> > index dae8dbb..8a3f959 100644
> > --- a/drivers/net/wireless/mwifiex/scan.c
> > +++ b/drivers/net/wireless/mwifiex/scan.c
> > @@ -1469,7 +1469,7 @@ mwifiex_update_curr_bss_params(struct mwifiex_private *priv, u8 *bssid,
> > s32 rssi, const u8 *ie_buf, size_t ie_len,
> > u16 beacon_period, u16 cap_info_bitmap, u8 band)
> > {
> > - struct mwifiex_bssdescriptor *bss_desc = NULL;
> > + struct mwifiex_bssdescriptor *bss_desc;
> > int ret;
> > unsigned long flags;
> > u8 *beacon_ie;
> > @@ -1484,6 +1484,7 @@ mwifiex_update_curr_bss_params(struct mwifiex_private *priv, u8 *bssid,
> >
> > beacon_ie = kmemdup(ie_buf, ie_len, GFP_KERNEL);
> > if (!beacon_ie) {
> > + kfree(bss_desc);
> > dev_err(priv->adapter->dev, " failed to alloc beacon_ie\n");
> > return -ENOMEM;
> > }
^ permalink raw reply
* Re: patch "workflow" - what deferred state means?
From: Maz The Northener @ 2011-11-07 20:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111107.141421.1710547287569203789.davem@davemloft.net>
I was talking about http://patchwork.ozlabs.org/patch/123407/ and
patchwork.ozlabs.org/patch/123406/
On 11/7/11, David Miller <davem@davemloft.net> wrote:
> From: Maz The Northener <mazziesaccount@gmail.com>
> Date: Mon, 7 Nov 2011 21:07:45 +0200
>
>> So is the different states of patches explained somewhere?
>
> Tell us what specific patch you're talking about and maybe we
> can give you an answer.
>
--
-Matti "Maz" Vaittinen
CWF coding team leader
http://www.curlysworldoffreeware.com/
BrakesAreForCowards!!!
When you feel blue, no one sees your tears... When your down, no one
understands your struggle...
When you feel happy, no one notices your smile...
But fart just once...
I would love to create a freeware game with C - unless I was working at NSN.
^ permalink raw reply
* Re: patch "workflow" - what deferred state means?
From: David Miller @ 2011-11-07 20:19 UTC (permalink / raw)
To: mazziesaccount; +Cc: netdev
In-Reply-To: <CANhJrGMsM7Pc9j0SB4G4Xxym0LLYmtaUq--vyPgt+7HWNz7H0Q@mail.gmail.com>
From: Maz The Northener <mazziesaccount@gmail.com>
Date: Mon, 7 Nov 2011 22:08:00 +0200
> I was talking about http://patchwork.ozlabs.org/patch/123407/ and
> patchwork.ozlabs.org/patch/123406/
Those are deferred because now is not an appropriate time to submit
new feature patches.
This kind of work should be resubmitted when net-next opens back up.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox