* [PATCH 3/5] IPVS: Remove unused variables
From: Simon Horman @ 2011-02-01 10:07 UTC (permalink / raw)
To: netdev, linux-next, linux-kernel, lvs-devel
Cc: Randy Dunlap, Stephen Rothwell, Hans Schillstrom, Patrick McHardy,
Simon Horman
In-Reply-To: <1296554868-17002-1-git-send-email-horms@verge.net.au>
These variables are unused as a result of the recent netns work.
Cc: Hans Schillstrom <hans@schillstrom.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index b23bea6..5d75fea 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1109,8 +1109,6 @@ extern int ip_vs_icmp_xmit_v6
* we are loaded. Just set ip_vs_drop_rate to 'n' and
* we start to drop 1/rate of the packets
*/
-extern int ip_vs_drop_rate;
-extern int ip_vs_drop_counter;
static inline int ip_vs_todrop(struct netns_ipvs *ipvs)
{
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/5] IPVS: Allow compilation with CONFIG_SYSCTL disabled
From: Simon Horman @ 2011-02-01 10:07 UTC (permalink / raw)
To: netdev, linux-next, linux-kernel, lvs-devel
Cc: Randy Dunlap, Stephen Rothwell, Hans Schillstrom, Patrick McHardy,
Simon Horman
In-Reply-To: <1296554868-17002-1-git-send-email-horms@verge.net.au>
This is a rather naieve approach to allowing PVS to compile with
CONFIG_SYSCTL disabled. I am working on a more comprehensive patch which
will remove compilation of all sysctl-related IPVS code when CONFIG_SYSCTL
is disabled.
Cc: Hans Schillstrom <hans@schillstrom.com>
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_ctl.c | 14 +++++++++-----
net/netfilter/ipvs/ip_vs_lblc.c | 20 ++++++++++----------
net/netfilter/ipvs/ip_vs_lblcr.c | 20 ++++++++++----------
3 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index d7c2fa8..c73b0c8 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -3552,10 +3552,15 @@ int __net_init __ip_vs_control_init(struct net *net)
tbl[idx++].data = &ipvs->sysctl_nat_icmp_send;
+#ifdef CONFIG_SYSCTL
ipvs->sysctl_hdr = register_net_sysctl_table(net, net_vs_ctl_path,
tbl);
- if (ipvs->sysctl_hdr == NULL)
- goto err_reg;
+ if (ipvs->sysctl_hdr == NULL) {
+ if (!net_eq(net, &init_net))
+ kfree(tbl);
+ goto err_dup;
+ }
+#endif
ip_vs_new_estimator(net, ipvs->tot_stats);
ipvs->sysctl_tbl = tbl;
/* Schedule defense work */
@@ -3563,9 +3568,6 @@ int __net_init __ip_vs_control_init(struct net *net)
schedule_delayed_work(&ipvs->defense_work, DEFENSE_TIMER_PERIOD);
return 0;
-err_reg:
- if (!net_eq(net, &init_net))
- kfree(tbl);
err_dup:
free_percpu(ipvs->cpustats);
err_alloc:
@@ -3581,7 +3583,9 @@ static void __net_exit __ip_vs_control_cleanup(struct net *net)
ip_vs_kill_estimator(net, ipvs->tot_stats);
cancel_delayed_work_sync(&ipvs->defense_work);
cancel_work_sync(&ipvs->defense_work.work);
+#ifdef CONFIG_SYSCTL
unregister_net_sysctl_table(ipvs->sysctl_hdr);
+#endif
proc_net_remove(net, "ip_vs_stats_percpu");
proc_net_remove(net, "ip_vs_stats");
proc_net_remove(net, "ip_vs");
diff --git a/net/netfilter/ipvs/ip_vs_lblc.c b/net/netfilter/ipvs/ip_vs_lblc.c
index d5bec33..00b5ffa 100644
--- a/net/netfilter/ipvs/ip_vs_lblc.c
+++ b/net/netfilter/ipvs/ip_vs_lblc.c
@@ -554,33 +554,33 @@ static int __net_init __ip_vs_lblc_init(struct net *net)
sizeof(vs_vars_table),
GFP_KERNEL);
if (ipvs->lblc_ctl_table == NULL)
- goto err_dup;
+ return -ENOMEM;
} else
ipvs->lblc_ctl_table = vs_vars_table;
ipvs->sysctl_lblc_expiration = 24*60*60*HZ;
ipvs->lblc_ctl_table[0].data = &ipvs->sysctl_lblc_expiration;
+#ifdef CONFIG_SYSCTL
ipvs->lblc_ctl_header =
register_net_sysctl_table(net, net_vs_ctl_path,
ipvs->lblc_ctl_table);
- if (!ipvs->lblc_ctl_header)
- goto err_reg;
+ if (!ipvs->lblc_ctl_header) {
+ if (!net_eq(net, &init_net))
+ kfree(ipvs->lblc_ctl_table);
+ return -ENOMEM;
+ }
+#endif
return 0;
-
-err_reg:
- if (!net_eq(net, &init_net))
- kfree(ipvs->lblc_ctl_table);
-
-err_dup:
- return -ENOMEM;
}
static void __net_exit __ip_vs_lblc_exit(struct net *net)
{
struct netns_ipvs *ipvs = net_ipvs(net);
+#ifdef CONFIG_SYSCTL
unregister_net_sysctl_table(ipvs->lblc_ctl_header);
+#endif
if (!net_eq(net, &init_net))
kfree(ipvs->lblc_ctl_table);
diff --git a/net/netfilter/ipvs/ip_vs_lblcr.c b/net/netfilter/ipvs/ip_vs_lblcr.c
index 61ae8cf..bfa25f1 100644
--- a/net/netfilter/ipvs/ip_vs_lblcr.c
+++ b/net/netfilter/ipvs/ip_vs_lblcr.c
@@ -754,33 +754,33 @@ static int __net_init __ip_vs_lblcr_init(struct net *net)
sizeof(vs_vars_table),
GFP_KERNEL);
if (ipvs->lblcr_ctl_table == NULL)
- goto err_dup;
+ return -ENOMEM;
} else
ipvs->lblcr_ctl_table = vs_vars_table;
ipvs->sysctl_lblcr_expiration = 24*60*60*HZ;
ipvs->lblcr_ctl_table[0].data = &ipvs->sysctl_lblcr_expiration;
+#ifdef CONFIG_SYSCTL
ipvs->lblcr_ctl_header =
register_net_sysctl_table(net, net_vs_ctl_path,
ipvs->lblcr_ctl_table);
- if (!ipvs->lblcr_ctl_header)
- goto err_reg;
+ if (!ipvs->lblcr_ctl_header) {
+ if (!net_eq(net, &init_net))
+ kfree(ipvs->lblcr_ctl_table);
+ return -ENOMEM;
+ }
+#endif
return 0;
-
-err_reg:
- if (!net_eq(net, &init_net))
- kfree(ipvs->lblcr_ctl_table);
^ permalink raw reply related
* [PATCH 5/5] IPVS: Remove ip_vs_sync_cleanup from section __exit
From: Simon Horman @ 2011-02-01 10:07 UTC (permalink / raw)
To: netdev, linux-next, linux-kernel, lvs-devel
Cc: Randy Dunlap, Stephen Rothwell, Hans Schillstrom, Patrick McHardy,
Simon Horman
In-Reply-To: <1296554868-17002-1-git-send-email-horms@verge.net.au>
ip_vs_sync_cleanup() may be called from ip_vs_init() on error
and thus needs to be accesible from section __init
Reporte-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_sync.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index d5a6e64..2a2a836 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -1686,7 +1686,7 @@ int __init ip_vs_sync_init(void)
return register_pernet_subsys(&ipvs_sync_ops);
}
-void __exit ip_vs_sync_cleanup(void)
+void ip_vs_sync_cleanup(void)
{
unregister_pernet_subsys(&ipvs_sync_ops);
}
--
1.7.2.3
^ permalink raw reply related
* Re: Realtek r8168C / r8169 driver VLAN TAG stripping
From: Francois Romieu @ 2011-02-01 10:12 UTC (permalink / raw)
To: Ivan Vecera; +Cc: Anand Raj Manickam, netdev, Hayes
In-Reply-To: <1296479698.8750.55.camel@ceranb.intra.cera.cz>
Ivan Vecera <ivecera@redhat.com> :
[...]
> Unfortunately I have no local access (it's placed in China) or remote
> serial console to the system with this 8168c. The second problem is that
> the system is connected to the switch that does not pass the packets
> with VLAN tags -> it seems that at least Tx packets have the VLAN tag.
>
> I'm sorry I'm not able to help more.
Thanks a lot for the information, it is both welcome and helpful.
I'll freeze Anand's report for now as "8168c + unspecified glue hardware
bug with unknown product manufactured by Arkino on unidentified motherboard
with unknown number of processors".
--
Ueimor
^ permalink raw reply
* Re: [PATCH] r8169: use RxFIFO overflow workaround for 8168c chipset
From: Ivan Vecera @ 2011-02-01 10:30 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, Hayes
In-Reply-To: <20110128172854.GA8151@electric-eye.fr.zoreil.com>
On Fri, 2011-01-28 at 18:28 +0100, Francois Romieu wrote:
> Ivan Vecera <ivecera@redhat.com> :
> [...]
> > The test case was: Migration of the several kvm guests at the same time
> > between two hosts.
>
> :o(
>
> Could you check if simply leaving the irq handler when status == RxFIFOOver
> works by any chance ?
It does not help, I tried two versions:
1) Simply leave the loop (only "break;") when status == RxFIFOOver
...
if (unlikely(status & RxFIFOOver)) {
static int rxfifo_count = 0;
printk("r8169: Rx FIFO overflows detected: %d\n",
++rxfifo_count);
break;
}
...
2) the same but with interrupt confirmation before leave
...
if (unlikely(status & RxFIFOOver)) {
static int rxfifo_count = 0;
printk("r8169: Rx FIFO overflows detected: %d\n",
++rxfifo_count);
RTL_W16(IntrStatus,
(status & RxFIFOOver) ?
(status | RxOverflow) : status);
break;
}
...
In both cases the NIC continues in generating Rx FIFO overflows.
Ivan
>
> Faced with pktgen, RTL_GIGA_MAC_VER_26 spits RxFIFO overflow errors quite
> fast (10000 packets kill it, reliably). The same fix as your avoids the crash.
>
> As is, RTL_GIGA_MAC_VER_12 seems to survive at 900kpps. It signals RXFIFO
> overflow, loses half the packets and sends pause control frames but it does
> not crash. I have made it leave the irq handler when status == RxFIFOOver.
> I'll see if it can stand a few hours like that.
>
^ permalink raw reply
* Re: Realtek r8168C / r8169 driver VLAN TAG stripping
From: Anand Raj Manickam @ 2011-02-01 10:38 UTC (permalink / raw)
To: Francois Romieu; +Cc: Ivan Vecera, netdev, Hayes
In-Reply-To: <20110201101253.GA8681@electric-eye.fr.zoreil.com>
On Tue, Feb 1, 2011 at 3:42 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Ivan Vecera <ivecera@redhat.com> :
> [...]
>> Unfortunately I have no local access (it's placed in China) or remote
>> serial console to the system with this 8168c. The second problem is that
>> the system is connected to the switch that does not pass the packets
>> with VLAN tags -> it seems that at least Tx packets have the VLAN tag.
>>
>> I'm sorry I'm not able to help more.
>
> Thanks a lot for the information, it is both welcome and helpful.
>
> I'll freeze Anand's report for now as "8168c + unspecified glue hardware
> bug with unknown product manufactured by Arkino on unidentified motherboard
> with unknown number of processors".
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 6
model name : AMD Sempron(tm) 140 Processor
stepping : 2
cpu MHz : 2700.641
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm 3dnowext 3dnow constant_tsc up nonstop_tsc extd_apicid pni
monitor cx16 popcnt lahf_lm svm extapic cr8_legacy abm sse4a
misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock
nrip_save
bogomips : 5401.28
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
>
> --
> Ueimor
>
^ permalink raw reply
* [PATCH] usb:smsc: preserve MAC address when resetting device
From: Sergiy Kibrik @ 2011-02-01 10:34 UTC (permalink / raw)
To: Steve Glendinning; +Cc: netdev, linux-usb, Sergiy Kibrik
Initialize MAC address only once, when device opened first time
to avoid generation random addresses when failed to read one from ROM.
Some hardware hasn't hw address in ROM, e.g. Pandaboard (http://pandaboard.org),
so every time device is up, its address is regenerated again.
It makeis impossible to set custom hw address and also makes DHCP servers and switches crazy.
Signed-off-by: Sergiy Kibrik <sakib@meta.ua>
---
drivers/net/usb/smsc75xx.c | 6 +++++-
drivers/net/usb/smsc95xx.c | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 753ee6e..a45dfa2 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -77,6 +77,7 @@ struct usb_context {
};
static int turbo_mode = true;
+static int first_reset = true;
module_param(turbo_mode, bool, 0644);
MODULE_PARM_DESC(turbo_mode, "Enable multiple frames per Rx transaction");
@@ -836,7 +837,10 @@ static int smsc75xx_reset(struct usbnet *dev)
netif_dbg(dev, ifup, dev->net, "PHY reset complete");
- smsc75xx_init_mac_address(dev);
+ if (first_reset){
+ smsc75xx_init_mac_address(dev);
+ first_reset = false;
+ }
ret = smsc75xx_set_mac_address(dev);
check_warn_return(ret, "Failed to set mac address");
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index bc86f4b..83008c1 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -59,6 +59,7 @@ struct usb_context {
struct usbnet *dev;
};
+static int first_reset = true;
static int turbo_mode = true;
module_param(turbo_mode, bool, 0644);
MODULE_PARM_DESC(turbo_mode, "Enable multiple frames per Rx transaction");
@@ -1045,7 +1046,10 @@ static int smsc95xx_bind(struct usbnet *dev, struct usb_interface *intf)
pdata->use_tx_csum = DEFAULT_TX_CSUM_ENABLE;
pdata->use_rx_csum = DEFAULT_RX_CSUM_ENABLE;
- smsc95xx_init_mac_address(dev);
+ if (first_reset){
+ smsc95xx_init_mac_address(dev);
+ first_reset = false;
+ }
/* Init all registers */
ret = smsc95xx_reset(dev);
--
1.7.1
^ permalink raw reply related
* [PATCH net-2.6] bnx2x: multicasts in NPAR mode
From: Vlad Zolotarov @ 2011-02-01 10:57 UTC (permalink / raw)
To: davem@davemloft.net, netdev@vger.kernel.org, Eilon Greenstein
The chip was erroneously configured to accept all multicast frames
in a normal (none-promisc) rx mode both on the RSS and on the FCoE L2 rings
when in an NPAR mode. This caused packet duplication for every received multicast
frame in this mode.
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 404d93e..f40740e 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -2301,15 +2301,10 @@ static void bnx2x_rxq_set_mac_filters(struct bnx2x *bp, u16 cl_id, u32 filters)
/* accept matched ucast */
drop_all_ucast = 0;
}
- if (filters & BNX2X_ACCEPT_MULTICAST) {
+ if (filters & BNX2X_ACCEPT_MULTICAST)
/* accept matched mcast */
drop_all_mcast = 0;
- if (IS_MF_SI(bp))
- /* since mcast addresses won't arrive with ovlan,
- * fw needs to accept all of them in
- * switch-independent mode */
- accp_all_mcast = 1;
- }
+
if (filters & BNX2X_ACCEPT_ALL_UNICAST) {
/* accept all mcast */
drop_all_ucast = 0;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v5 0/4] Adding HID Feature Report Support to hidraw
From: Antonio Ospite @ 2011-02-01 11:47 UTC (permalink / raw)
To: Alan Ott
Cc: Jiri Kosina, Marcel Holtmann, Gustavo F. Padovan, David S. Miller,
Michael Poole, Eric Dumazet, linux-input, linux-kernel, linux-usb,
linux-bluetooth, netdev, Bastien Nocera
In-Reply-To: <1295337880-12452-1-git-send-email-alan@signal11.us>
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
On Tue, 18 Jan 2011 03:04:36 -0500
Alan Ott <alan@signal11.us> wrote:
> This patch adds Feature Report support for USB and Bluetooth HID devices
> through hidraw.
>
> The first two patches prepare the bluetooth side for the change.
> a. Make sure the hidp_session() thread is started before
> device's probe() functions are called.
> b. Wait for ACK/NAK on sent reports, and return proper
> error codes.
> The third patch is the hidraw core and USB changes.
In particular, this third patch is a prerequisite for the bluez
sixaxis-cable plugin, originally written by Bastien Nocera (added to
CC) which I plan to submit when these changes are merged in mainline
linux.
[...]
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] usb:smsc: preserve MAC address when resetting device
From: David Lamparter @ 2011-02-01 11:24 UTC (permalink / raw)
To: Sergiy Kibrik; +Cc: Steve Glendinning, netdev, linux-usb
In-Reply-To: <1296556457-4969-1-git-send-email-sakib@meta.ua>
[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]
On Tue, Feb 01, 2011 at 12:34:17PM +0200, Sergiy Kibrik wrote:
> Initialize MAC address only once, when device opened first time
> to avoid generation random addresses when failed to read one from ROM.
>
> Some hardware hasn't hw address in ROM, e.g. Pandaboard (http://pandaboard.org),
> so every time device is up, its address is regenerated again.
> It makeis impossible to set custom hw address and also makes DHCP servers and switches crazy.
[snip]
> +++ b/drivers/net/usb/smsc75xx.c
> @@ -77,6 +77,7 @@ struct usb_context {
> };
>
> static int turbo_mode = true;
> +static int first_reset = true;
> module_param(turbo_mode, bool, 0644);
> MODULE_PARM_DESC(turbo_mode, "Enable multiple frames per Rx transaction");
>
> @@ -836,7 +837,10 @@ static int smsc75xx_reset(struct usbnet *dev)
>
> netif_dbg(dev, ifup, dev->net, "PHY reset complete");
>
> - smsc75xx_init_mac_address(dev);
> + if (first_reset){
> + smsc75xx_init_mac_address(dev);
> + first_reset = false;
> + }
[snip]
You cannot do that. Imagine if I plug in two devices. Only the first one
will get a MAC properly. Or imagine if i plug a device, unplug it and
plug it back. It will have an uninitialized mac address.
You need to move the init_mac_address call to happen on device plug-in.
-David
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: x25: possible skb leak on bad facilities
From: Andrew Hendry @ 2011-02-01 11:55 UTC (permalink / raw)
To: Andy Whitcroft
Cc: David S. Miller, John Hughes, linux-x25, netdev, linux-kernel,
Tim Gardner
In-Reply-To: <20110131130826.GC16804@shadowen.org>
There are two callers, when I was crashing it I don't remember it
using the backlog path.
x25_process_rx_frame is called from both x25_backlog_rcv and also
x25_receive_data (via x25_lapb_receive_frame)
But reviewing that second path now it looks like it will also leak, -1
would make it skip the kfree_skb there as well.
So patch looks good to me, when I have some time I'll run it through
the environment I had setup originally to confirm.
On Tue, Feb 1, 2011 at 12:08 AM, Andy Whitcroft <apw@canonical.com> wrote:
> Looking at the changes introduced in the commit below, we seem to
> introduce an skb leak when a packet with bad facilities are present:
>
> commit a6331d6f9a4298173b413cf99a40cc86a9d92c37
> Author: andrew hendry <andrew.hendry@gmail.com>
> Date: Wed Nov 3 12:54:53 2010 +0000
>
> memory corruption in X.25 facilities parsing
>
> If I am understanding things correctly then we trigger a -1 return to
> the main packet dispatch loop, this being non-zero implies that we have
> requeued the skb and it should not be freed. As it was not requeued,
> I believe the skb is no longer referenced and then is leaked.
>
> Perhaps someone better aquainted with this code could review my analysis
> in the patch leader below. If accurate I believe we need the patch below
> to resolve this. If it is not then I suspect a comment is required on
> the -1 return.
>
> Thoughts?
>
> -apw
>
> From 5728c05fb669e8ee1e6d20fb7a71916362039411 Mon Sep 17 00:00:00 2001
> From: Andy Whitcroft <apw@canonical.com>
> Date: Mon, 31 Jan 2011 10:37:36 +0000
> Subject: [PATCH] x25: drop packet on invalid facility headers
>
> The commit below introduced additional checks for invalid facilities,
> and a new return path when these were detected:
>
> commit a6331d6f9a4298173b413cf99a40cc86a9d92c37
> Author: andrew hendry <andrew.hendry@gmail.com>
> Date: Wed Nov 3 12:54:53 2010 +0000
>
> memory corruption in X.25 facilities parsing
>
> This new return path short circuits packet handling, the new return -1
> below:
>
> static int x25_state1_machine(struct sock *sk, struct sk_buff *skb,
> int frametype)
> {
> [...]
> len = x25_parse_facilities(skb, &x25->facilities,
> &x25->dte_facilities,
> &x25->vc_facil_mask);
> if (len > 0)
> skb_pull(skb, len);
> else
> return -1;
> [...]
>
> This return code is passed back up the chain (via x25_process_rx_frame)
> and is interpreted as below by the caller:
>
> int x25_backlog_rcv(struct sock *sk, struct sk_buff *skb)
> {
> int queued = x25_process_rx_frame(sk, skb);
>
> if (!queued)
> kfree_skb(skb);
>
> return 0;
> }
>
> Here we interpret the non-zero status as indicating the skb has been
> requeued and should be preserved. As we have not actually done so it
> will be leaked.
>
> Fix this up by indicating that the packet should be dropped.
>
> Signed-off-by: Andy Whitcroft <apw@canonical.com>
> ---
> net/x25/x25_in.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/x25/x25_in.c b/net/x25/x25_in.c
> index f729f02..213b93a 100644
> --- a/net/x25/x25_in.c
> +++ b/net/x25/x25_in.c
> @@ -120,7 +120,7 @@ static int x25_state1_machine(struct sock *sk, struct sk_buff *skb, int frametyp
> if (len > 0)
> skb_pull(skb, len);
> else
> - return -1;
> + return 0;
> /*
> * Copy any Call User Data.
> */
> --
> 1.7.1
>
>
^ permalink raw reply
* [PATCH] depca: Fix warnings
From: Alan Cox @ 2011-02-01 11:32 UTC (permalink / raw)
To: netdev
From: Alan Cox <alan@linux.intel.com>
Replace the rather weird use of ++ with + 1 as the value is being assigned
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/net/depca.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/depca.c b/drivers/net/depca.c
index 1b48b68..8b0084d 100644
--- a/drivers/net/depca.c
+++ b/drivers/net/depca.c
@@ -1094,7 +1094,7 @@ static int depca_rx(struct net_device *dev)
}
}
/* Change buffer ownership for this last frame, back to the adapter */
- for (; lp->rx_old != entry; lp->rx_old = (++lp->rx_old) & lp->rxRingMask) {
+ for (; lp->rx_old != entry; lp->rx_old = (lp->rx_old + 1) & lp->rxRingMask) {
writel(readl(&lp->rx_ring[lp->rx_old].base) | R_OWN, &lp->rx_ring[lp->rx_old].base);
}
writel(readl(&lp->rx_ring[entry].base) | R_OWN, &lp->rx_ring[entry].base);
@@ -1103,7 +1103,7 @@ static int depca_rx(struct net_device *dev)
/*
** Update entry information
*/
- lp->rx_new = (++lp->rx_new) & lp->rxRingMask;
+ lp->rx_new = (lp->rx_new + 1) & lp->rxRingMask;
}
return 0;
@@ -1148,7 +1148,7 @@ static int depca_tx(struct net_device *dev)
}
/* Update all the pointers */
- lp->tx_old = (++lp->tx_old) & lp->txRingMask;
+ lp->tx_old = (lp->tx_old + 1) & lp->txRingMask;
}
return 0;
^ permalink raw reply related
* Re: [GIT PULL nf-next-2.6 v2] IPVS build fixes and clean-ups
From: Patrick McHardy @ 2011-02-01 13:24 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, linux-next, linux-kernel, lvs-devel, Randy Dunlap,
Stephen Rothwell, Hans Schillstrom
In-Reply-To: <1296554868-17002-1-git-send-email-horms@verge.net.au>
On 01.02.2011 11:07, Simon Horman wrote:
> This short patch series addresses two linux-next build problems
> raised by Randy Dunlap:
>
> * net/netfilter/ipvs/ip_vs_core.c:1891: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'unsigned int'
> * ERROR: "unregister_net_sysctl_table" [net/netfilter/ipvs/ip_vs.ko]
> ERROR: "register_net_sysctl_table" [net/netfilter/ipvs/ip_vs.ko] undefined!
> * WARNING: net/netfilter/ipvs/ip_vs.o(.init.text+0x161): Section mismatch in reference from the function init_module() to the function .exit.text:ip_vs_sync_cleanup()
>
> The remainder of the changsets are cleanups that I noticed along the way.
>
> The changes are available at
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git master
>
> They are currently compile-tested only.
Just to avoid any confusion, do you want me to pull these patches
already?
^ permalink raw reply
* Re: [PATCH 1/1] compat-wireless: Fix ath9k debug log issue.
From: Senthil Balasubramanian @ 2011-02-01 13:33 UTC (permalink / raw)
To: Joe Perches
Cc: Senthilkumar Balasubramanian, Luis Rodriguez,
mcgrof-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1296500296.4131.175.camel@Joe-Laptop>
On Tue, Feb 01, 2011 at 12:28:16AM +0530, Joe Perches wrote:
> On Mon, 2011-01-31 at 17:07 +0530, Senthil Balasubramanian wrote:
> > ath9k debug logs are not shown as we are using recursive vsnprintf
> > which are supported in kernel 2.6.36 and above. use vprintk for older
> > kernels.
>
> #ifdefs spread around the tree for this sort of
> change are not very nice.
#if LINUX_VERSION is unavoidable in compat wireless and compat is actually
meant for that.
>
> Perhaps wireless-compat should not be an impediment to
> mainline progress and these sorts of changes should be
> minimized.
>
> If this is really necessary for backward compatibility,
> I think the %pV could just be removed.
May be this can be done if we are really worried about the no.of patches
in compat folder.
>
> If not, because this style would be used in several
> places, perhaps another macro could be used to hide the
> use of %pV.
>
> Maybe something like:
you mean use this in wireless-testing ??. We should not
add if kernel version checks in wireless-testing code and
I don't prefer that either.
>
> #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
> #define PRINTK_VA_LIST(level, prefix, fmt, __va_list) \
> ({ \
> struct va_format vaf; \
> \
> vaf.fmt = fmt; \
> vaf.va = &__va_list; \
> \
> printk("%s" prefix "%pV", level, &vaf); \
> })
> #else
> #define PRINTK_VA_LIST(level, prefix, fmt, __va_list) \
> ({ \
> printk("%s" prefix, level); \
> vprintk(fmt, __va_list); \
> })
> #endif
>
> > +diff --git a/drivers/net/wireless/ath/main.c b/drivers/net/wireless/ath/main.c
> > +index c325202..e3e60d4 100644
> > +--- a/drivers/net/wireless/ath/main.c
> > ++++ b/drivers/net/wireless/ath/main.c
> > +@@ -60,16 +60,23 @@ EXPORT_SYMBOL(ath_rxbuf_alloc);
> > + int ath_printk(const char *level, struct ath_common *common,
> > + const char *fmt, ...)
> > + {
> > ++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
> > + struct va_format vaf;
> > ++#endif
> > + va_list args;
> > + int rtn;
> > +
> > + va_start(args, fmt);
> > +
> > ++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
> > + vaf.fmt = fmt;
> > + vaf.va = &args;
> > +
> > + rtn = printk("%sath: %pV", level, &vaf);
> > ++#else
> > ++ printk("%sath: ", level);
> > ++ rtn = vprintk(fmt, args);
> > ++#endif
> > +
> > + va_end(args);
> > +
>
> So this would become something like:
>
> int ath_printk(const char *level, struct ath_common *common,
> const char *fmt, ...)
> {
> va_list args;
> int rtn;
>
> va_start(args, fmt);
>
> rtn = PRINTK_VA_LIST(level, "ath: ", fmt, args);
>
> va_end(args);
>
> return rtn;
> }
>
>
--
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] IPv6 configurable default value for the privacy extension flag
From: Julien Aube @ 2011-02-01 12:57 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev
In-Reply-To: <4D478655.6040706@linux-ipv6.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le Tue, 01 Feb 2011 13:04:37 +0900,
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> a écrit :
> Hello.
>
> (2011/02/01 0:49), Julien Aube wrote:
>
> >+ } else {
> >+ printk(KERN_WARNING "IPv6 Privacy Extension "
> >+ "is disabled by default (invalid value %d)\n", ipv6_default_privacy);
> >+ }
>
> I think WARNING is too high.
I did put KERN_WARNING because this code is used when someone explicitly set
an invalid value, e.g.
ipv6.privacy_default=-1
But you're right, I'll set KERN_NOTICE instead.
What do you think of the idea by itself anyhow ?
Thanks for the feedback.
Julien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk1IAyYACgkQHiz1mD2sU8g39QCg6FY8LFCBwyX310cAZYdyVHJA
a4wAoOSDXBZGgayReuZ5wvzE7iZRiHZr
=7i5B
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6 v2] IPVS build fixes and clean-ups
From: Hans Schillstrom @ 2011-02-01 13:36 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, linux-next, linux-kernel, lvs-devel, Randy Dunlap,
Stephen Rothwell, Patrick McHardy
>---- Original Message ----
>From: Simon Horman <horms@verge.net.au>
>To: netdev@vger.kernel.org, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, lvs-devel@vger.kernel.org
>Cc: "Randy Dunlap" <randy.dunlap@oracle.com>, "Stephen Rothwell" <sfr@canb.auug.org.au>, "Hans Schillstrom" <hans@schillstrom.com>, "Patrick McHardy" <kaber@trash.net>
>Sent: Tue, Feb 1, 2011, 11:11 AM
>Subject: [GIT PULL nf-next-2.6 v2] IPVS build fixes and clean-ups
>
>This short patch series addresses two linux-next build problems
>raised by Randy Dunlap:
>
>* net/netfilter/ipvs/ip_vs_core.c:1891: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'unsigned int'
>* ERROR: "unregister_net_sysctl_table" [net/netfilter/ipvs/ip_vs.ko]
> ERROR: "register_net_sysctl_table" [net/netfilter/ipvs/ip_vs.ko] undefined!
>* WARNING: net/netfilter/ipvs/ip_vs.o(.init.text+0x161): Section mismatch in reference from the function init_module() to the function .exit.text:ip_vs_sync_cleanup()
>
>The remainder of the changsets are cleanups that I noticed along the way.
>
>The changes are available at
>git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git master
>
>They are currently compile-tested only.
>
I will try to test this today
Regards
Hans Schillstrom <hans@schillstrom.com>
^ permalink raw reply
* Re: Re: [GIT PULL nf-next-2.6 v2] IPVS build fixes and clean-ups
From: Hans Schillstrom @ 2011-02-01 13:58 UTC (permalink / raw)
To: Patrick McHardy
Cc: Simon Horman, netdev, linux-next, linux-kernel, lvs-devel,
Randy Dunlap, Stephen Rothwell
>---- Original Message ----
>From: Patrick McHardy <kaber@trash.net>
>To: "Simon Horman" <horms@verge.net.au>
>Cc: netdev@vger.kernel.org, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, lvs-devel@vger.kernel.org, "Randy Dunlap" <randy.dunlap@oracle.com>, "Stephen Rothwell" <sfr@canb.auug.org.au>, "Hans Schillstrom" <hans@schillstrom.com>
>Sent: Tue, Feb 1, 2011, 14:25 PM
>Subject: Re: [GIT PULL nf-next-2.6 v2] IPVS build fixes and clean-ups
>
>On 01.02.2011 11:07, Simon Horman wrote:
>> This short patch series addresses two linux-next build problems
>> raised by Randy Dunlap:
>>
>> * net/netfilter/ipvs/ip_vs_core.c:1891: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'unsigned int'
>> * ERROR: "unregister_net_sysctl_table" [net/netfilter/ipvs/ip_vs.ko]
>> ERROR: "register_net_sysctl_table" [net/netfilter/ipvs/ip_vs.ko] undefined!
>> * WARNING: net/netfilter/ipvs/ip_vs.o(.init.text+0x161): Section mismatch in reference from the function init_module() to the function .exit.text:ip_vs_sync_cleanup()
>>
>> The remainder of the changsets are cleanups that I noticed along the way.
>>
>> The changes are available at
>> git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git master
>>
>> They are currently compile-tested only.
>
>Just to avoid any confusion, do you want me to pull these patches
>already?
Let me do a sanity check of this,
It takes a couple of hours
/Hans Schillstrom
^ permalink raw reply
* How To Temporarily Suspend Network Traffic
From: Volkan YAZICI @ 2011-02-01 14:28 UTC (permalink / raw)
To: netdev
Hi,
I want to temporarily suspend the network traffic on a particular
interface -- if possible, in microsecond granularity. For this purpose,
ifup/ifdown ioctl() calls doesn't work. That is, for wireless
interfaces, connection isn't get recovered; for wired interfaces, it
takes at least 2 seconds to recover. I tried using tc, but it doesn't
accept "rate 0" parameter. Neither "iwconfig wlan0 rate 0" has any
effect. (Moreover, in iwconfig manual it is told that values below 1000
are card specific and are usually an index in the bit-rate list.) Do you
have any suggestions? Can you recommend me to check any code piece in
the kernel or some other tool?
Regards.
^ permalink raw reply
* Re: AR-M0898A and tg3 driver Kernel Corruption/Panic
From: Stephen Clark @ 2011-02-01 15:30 UTC (permalink / raw)
To: Matt Carlson; +Cc: Scott Sullivan, Linux Kernel Network Developers
In-Reply-To: <20110131220425.GA3540@mcarlson.broadcom.com>
On 01/31/2011 05:04 PM, Matt Carlson wrote:
> On Mon, Jan 31, 2011 at 01:40:58PM -0800, Scott Sullivan wrote:
>
>> Stephen Clark,
>>
>> I've been fighting with Installing CentOS 5.5 on the Acrosser AR-M0898B. After finally Narrowing down the issue to the tg3 driver I stumbled upon your thread with Matt Carlson (CC'd).
>>
>> First up, what is the canonical location to follow the thread from? (It's mirrored to all ends of the Internet making it hard to find the most update copy of it.)
>>
>> As for my experiences with the device:
>> Getting the appliance to run right for me required the kernel arguments:
>> "apci=off nolapic"
>>
>> CentOS installs with tg3 Version 3.106
>> - w/o args system outright reboot when trying to start networking
>> - w/ args system would try to get DHCP and corrupt the kernel resulting in "cannot execute binary file" errors
>>
>> After installing tg3 Version 3.110g from src rpm:
>> - w/ args, gives a proper kernel panic and dump when trying to get a DHCP address.
>>
>> An old vague email from Acrosser suggest something stopped working between Fedora 8 and Fedora 10. I've yet to dig deeper into that lead.
>>
>> I have 2 of these devices on my desk. Please let me know if there is any information or tests I can preform to assist in resolving this bug.
>>
> Thanks Scott. Both you and Stephen seem to be running newer kernels and
> running into problems. It doesn't look like the hardware is all that
> new though. To see if there is a lower bound, have you tried running
> older distros to see if any one of them clears up the problem?
>
> Another approach is to do a kernel git bisection. Is anyone comfortable
> with that?
>
>
Hi Matt & Scott,
Actually I started out with the current kernel from Centos 5.5 and
tried later kernels to see if the problem was fixed, which it wasn't.
I haven't gotten around to testing a boot with the nomsi option yet.
Also I couldn't get freebsd 6.3 to run either.
Regards,
Steve
^ permalink raw reply
* [PULL] vhost-net: 2.6.38 - warning fix
From: Michael S. Tsirkin @ 2011-02-01 15:44 UTC (permalink / raw)
To: David Miller; +Cc: kvm, virtualization, netdev, linux-kernel
Please merge for 2.6.38. Not the most elegant fix,
but it does fix the noise in dmesg that interferes with
kvm debugging, and probably the best we can do for 2.6.38.
The following changes since commit fca540ab5f4718c6133f71f7be1793066008bf89:
enc28j60: Fix reading of transmit status vector (2011-01-31 20:56:54 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net
Michael S. Tsirkin (1):
vhost: rcu annotation fixup
drivers/vhost/net.c | 9 +++++----
drivers/vhost/vhost.h | 6 +++---
2 files changed, 8 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCHv2 dontapply] vhost-net tx tuning
From: Michael S. Tsirkin @ 2011-02-01 15:52 UTC (permalink / raw)
To: Steve Dobbelstein; +Cc: mashirle, kvm, netdev
In-Reply-To: <OF381CCA86.B82857CC-ON86257826.00629F88-86257826.006596F5@us.ibm.com>
OK, so thinking about it more, maybe the issue is this:
tx becomes full. We process one request and interrupt the guest,
then it adds one request and the queue is full again.
Maybe the following will help it stabilize? By default with it we will
only interrupt when we see an empty ring.
Which is liklely too much: pls try other values
in the middle: e.g. make bufs half the ring,
or bytes some small value like half ring * 200, or packets some
small value etc.
Set any one parameter to 0 to get current
behaviour (interrupt immediately when enabled).
Warning: completely untested.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index aac05bc..6769cdc 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -32,6 +32,13 @@
* Using this limit prevents one virtqueue from starving others. */
#define VHOST_NET_WEIGHT 0x80000
+int tx_bytes_coalesce = 1000000000;
+module_param(tx_bytes_coalesce, int, 0644);
+int tx_bufs_coalesce = 1000000000;
+module_param(tx_bufs_coalesce, int, 0644);
+int tx_packets_coalesce = 1000000000;
+module_param(tx_packets_coalesce, int, 0644);
+
enum {
VHOST_NET_VQ_RX = 0,
VHOST_NET_VQ_TX = 1,
@@ -127,6 +134,9 @@ static void handle_tx(struct vhost_net *net)
int err, wmem;
size_t hdr_size;
struct socket *sock;
+ int bytes_coalesced = 0;
+ int bufs_coalesced = 0;
+ int packets_coalesced = 0;
/* TODO: check that we are running from vhost_worker? */
sock = rcu_dereference_check(vq->private_data, 1);
@@ -196,14 +206,26 @@ static void handle_tx(struct vhost_net *net)
if (err != len)
pr_debug("Truncated TX packet: "
" len %d != %zd\n", err, len);
- vhost_add_used_and_signal(&net->dev, vq, head, 0);
total_len += len;
+ packets_coalesced += 1;
+ bytes_coalesced += len;
+ bufs_coalesced += out;
+ if (unlikely(packets_coalesced > tx_packets_coalesce ||
+ bytes_coalesced > tx_bytes_coalesce ||
+ bufs_coalesced > tx_bufs_coalesce))
+ vhost_add_used_and_signal(&net->dev, vq, head, 0);
+ else
+ vhost_add_used(vq, head, 0);
if (unlikely(total_len >= VHOST_NET_WEIGHT)) {
vhost_poll_queue(&vq->poll);
break;
}
}
+ if (likely(packets_coalesced &&
+ bytes_coalesced &&
+ bufs_coalesced))
+ vhost_signal(&net->dev, vq);
mutex_unlock(&vq->mutex);
}
^ permalink raw reply related
* Re: [PATCH] bonding: added 802.3ad round-robin hashing policy for single TCP session balancing
From: Oleg V. Ukhno @ 2011-02-01 16:25 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Nicolas de Pesloüan, John Fastabend, netdev@vger.kernel.org
In-Reply-To: <19551.1296268113@death>
On 01/29/2011 05:28 AM, Jay Vosburgh wrote:
> Oleg V. Ukhno<olegu@yandex-team.ru> wrote:
>
> I've thought about this whole thing, and here's what I view as
> the proper way to do this.
>
> In my mind, this proposal is two separate pieces:
>
> First, a piece to make round-robin a selectable hash for
> xmit_hash_policy. The documentation for this should follow the pattern
> of the "layer3+4" hash policy, in particular noting that the new
> algorithm violates the 802.3ad standard in exciting ways, will result in
> out of order delivery, and that other 802.3ad implementations may or may
> not tolerate this.
>
> Second, a piece to make certain transmitted packets use the
> source MAC of the sending slave instead of the bond's MAC. This should
> be a separate option from the round-robin hash policy. I'd call it
> something like "mac_select" with two values: "default" (what we do now)
> and "slave_src_mac" to use the slave's real MAC for certain types of
> traffic (I'm open to better names; that's just what I came up with while
> writing this). I believe that "certain types" means "everything but
> ARP," but might be "only IP and IPv6." Structuring the option in this
> manner leaves the option open for additional selections in the future,
> which a simple "on/off" option wouldn't. This option should probably
> only affect a subset of modes; I'm thinking anything except balance-tlb
> or -alb (because they do funky MAC things already) and active-backup (it
> doesn't balance traffic, and already uses fail_over_mac to control
> this). I think this option also needs a whole new section down in the
> bottom explaining how to exploit it (the "pick special MACs on slaves to
> trick switch hash" business).
>
> Comments?
>
> -J
>
Jay,
As for me splitting my initial proposal into two logically diffent
pieces is ok, this will provide more flexible configuration.
Do I understand correctly, that after I rewrite patch in splitted form,
as you described above, and enhance documentation it will be /can be
applied to kernel?
Then what should I do: rewrite patch and resubmit it as a new one?
Oleg.
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>
--
Best regards,
Oleg Ukhno.
^ permalink raw reply
* Re: [PATCH 1/5] IPVS: use z modifier for sizeof() argument
From: Hans Schillstrom @ 2011-02-01 17:06 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, linux-next, linux-kernel, lvs-devel, Randy Dunlap,
Stephen Rothwell, Patrick McHardy
>---- Original Message ----
>From: Simon Horman <horms@verge.net.au>
>To: netdev@vger.kernel.org, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, lvs-devel@vger.kernel.org
>Cc: "Randy Dunlap" <randy.dunlap@oracle.com>, "Stephen Rothwell" <sfr@canb.auug.org.au>, "Hans Schillstrom" <hans@schillstrom.com>, "Patrick McHardy" <kaber@trash.net>, "Simon Horman" <horms@verge.net.au>
>Sent: Tue, Feb 1, 2011, 11:08 AM
>Subject: [PATCH 1/5] IPVS: use z modifier for sizeof() argument
>
>Cc: Hans Schillstrom <hans@schillstrom.com>
>Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
>Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
Tested-by: Hans Schillstrom <hans@schillstrom.com>
>---
> net/netfilter/ipvs/ip_vs_core.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
>index d889f4f..4d06617 100644
>--- a/net/netfilter/ipvs/ip_vs_core.c
>+++ b/net/netfilter/ipvs/ip_vs_core.c
>@@ -1887,7 +1887,7 @@ static int __net_init __ip_vs_init(struct net *net)
> ipvs->gen = atomic_read(&ipvs_netns_cnt);
> atomic_inc(&ipvs_netns_cnt);
> net->ipvs = ipvs;
>- printk(KERN_INFO "IPVS: Creating netns size=%lu id=%d\n",
>+ printk(KERN_INFO "IPVS: Creating netns size=%zu id=%d\n",
> sizeof(struct netns_ipvs), ipvs->gen);
> return 0;
> }
>--
>1.7.2.3
>
>--
>To unsubscribe from this list: send the line "unsubscribe lvs-devel" 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
* Re: [GIT PULL nf-next-2.6] IPVS build fixes and clean-ups
From: Randy Dunlap @ 2011-02-01 17:05 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, linux-next, linux-kernel, lvs-devel, Stephen Rothwell,
Hans Schillstrom, Patrick McHardy
In-Reply-To: <20110201100421.GA13325@verge.net.au>
On 02/01/11 02:04, Simon Horman wrote:
> On Tue, Feb 01, 2011 at 03:06:37PM +1100, Simon Horman wrote:
>> On Mon, Jan 31, 2011 at 04:50:09PM -0800, Randy Dunlap wrote:
>>> On Tue, 1 Feb 2011 11:14:11 +1100 Simon Horman wrote:
>>>
>>>> Hi,
>>>>
>>>> This short patch series addresses two linux-next build problems
>>>> raised by Randy Dunlap:
>>>>
>>>> * net/netfilter/ipvs/ip_vs_core.c:1891: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'unsigned int'
>>>> * ERROR: "unregister_net_sysctl_table" [net/netfilter/ipvs/ip_vs.ko]
>>>> ERROR: "register_net_sysctl_table" [net/netfilter/ipvs/ip_vs.ko] undefined!
>>>>
>>>> The remainder of the changset is cleanups that I noticed along the way.
>>>
>>> These 4 patches build successfully for me.
>>> However, I do see these warnings (sorry I missed them earlier):
>>>
>>> WARNING: net/netfilter/ipvs/ip_vs.o(.init.text+0x161): Section mismatch in reference from the function init_module() to the function .exit.text:ip_vs_sync_cleanup()
>>> WARNING: net/netfilter/ipvs/ip_vs.o(.init.text+0x161): Section mismatch in reference from the function init_module() to the function .exit.text:ip_vs_sync_cleanup()
>>
>> Thanks, I'll look into that. I will be travelling for a good portion of the
>> next day and a bit so I apologise in advance if that delays my next patch.
>
> Hi,
>
> I the following patch seems to be the right fix for this to me.
> I will send an amended pull request.
>
> IPVS: Remove ip_vs_sync_cleanup from section __exit
>
> ip_vs_sync_cleanup() may be called from ip_vs_init() on error
> and thus needs to be accesible from section __init
>
> Reporte-by: Randy Dunlap <randy.dunlap@oracle.com>
Reported-by:
> Signed-off-by: Simon Horman <horms@verge.net.au>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Thanks.
> ---
> net/netfilter/ipvs/ip_vs_sync.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
> index d5a6e64..2a2a836 100644
> --- a/net/netfilter/ipvs/ip_vs_sync.c
> +++ b/net/netfilter/ipvs/ip_vs_sync.c
> @@ -1686,7 +1686,7 @@ int __init ip_vs_sync_init(void)
> return register_pernet_subsys(&ipvs_sync_ops);
> }
>
> -void __exit ip_vs_sync_cleanup(void)
> +void ip_vs_sync_cleanup(void)
> {
> unregister_pernet_subsys(&ipvs_sync_ops);
> }
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 2/5] IPVS: remove duplicate initialisation or rs_table
From: Hans Schillstrom @ 2011-02-01 17:06 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, linux-next, linux-kernel, lvs-devel, Randy Dunlap,
Stephen Rothwell, Patrick McHardy
>---- Original Message ----
>From: Simon Horman <horms@verge.net.au>
>To: netdev@vger.kernel.org, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, lvs-devel@vger.kernel.org
>Cc: "Randy Dunlap" <randy.dunlap@oracle.com>, "Stephen Rothwell" <sfr@canb.auug.org.au>, "Hans Schillstrom" <hans@schillstrom.com>, "Patrick McHardy" <kaber@trash.net>, "Simon Horman" <horms@verge.net.au>
>Sent: Tue, Feb 1, 2011, 11:11 AM
>Subject: [PATCH 2/5] IPVS: remove duplicate initialisation or rs_table
>
>Cc: Hans Schillstrom <hans@schillstrom.com>
>Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
Tested-by: Hans Schillstrom <hans@schillstrom.com>
>---
> net/netfilter/ipvs/ip_vs_ctl.c | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
>diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
>index 98df59a..d7c2fa8 100644
>--- a/net/netfilter/ipvs/ip_vs_ctl.c
>+++ b/net/netfilter/ipvs/ip_vs_ctl.c
>@@ -3515,9 +3515,6 @@ int __net_init __ip_vs_control_init(struct net *net)
> }
> spin_lock_init(&ipvs->tot_stats->lock);
>
>- for (idx = 0; idx < IP_VS_RTAB_SIZE; idx++)
>- INIT_LIST_HEAD(&ipvs->rs_table[idx]);
>-
> proc_net_fops_create(net, "ip_vs", 0, &ip_vs_info_fops);
> proc_net_fops_create(net, "ip_vs_stats", 0, &ip_vs_stats_fops);
> proc_net_fops_create(net, "ip_vs_stats_percpu", 0,
>--
>1.7.2.3
>
>--
>To unsubscribe from this list: send the line "unsubscribe lvs-devel" 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
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