* Re: [patch] pktgen: bug when calling ndelay in x86 architectures
From: Eric Dumazet @ 2011-10-19 10:13 UTC (permalink / raw)
To: Daniel Turull
Cc: Ben Hutchings, David Miller, netdev, Robert Olsson,
Voravit Tanyingyong, Jens Laas
In-Reply-To: <4E9E9963.7090209@gmail.com>
Le mercredi 19 octobre 2011 à 11:33 +0200, Daniel Turull a écrit :
> Hi,
> then if we want to use the spin more often.
> maybe we can increase the constant from 100000 (0.1ms) to 1000000 (1ms)?
> How was the current value chosen?
>
Based on user needs ;)
> I did some measurements of the inter-arrival time between packets
> and with bigger values the maximal is reduced in the rates between
> 2kpps and 20kpps.
>
ndelay()/udelay() have some inaccuracies, for 'long' values, because of
rounding errors.
If we spin, just call ktime_now() in a loop until spin_until is
reached...
That way you get max possible resolution, given kernel time service
constraints.
Untested patch :
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 38d6577..5c7e900 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2145,9 +2145,11 @@ static void spin(struct pktgen_dev *pkt_dev, ktime_t spin_until)
}
start_time = ktime_now();
- if (remaining < 100000)
- ndelay(remaining); /* really small just spin */
- else {
+ if (remaining < 100000) {
+ do {
+ end_time = ktime_now();
+ } while (ktime_lt(end_time, spin_until));
+ } else {
/* see do_nanosleep */
hrtimer_init_sleeper(&t, current);
do {
@@ -2162,8 +2164,8 @@ static void spin(struct pktgen_dev *pkt_dev, ktime_t spin_until)
hrtimer_cancel(&t.timer);
} while (t.task && pkt_dev->running && !signal_pending(current));
__set_current_state(TASK_RUNNING);
+ end_time = ktime_now();
}
- end_time = ktime_now();
pkt_dev->idle_acc += ktime_to_ns(ktime_sub(end_time, start_time));
pkt_dev->next_tx = ktime_add_ns(spin_until, pkt_dev->delay);
^ permalink raw reply related
* RE: [PATCH] ipvs: Remove unused variable "cs" from ip_vs_leave function.
From: Hans Schillström @ 2011-10-19 9:23 UTC (permalink / raw)
To: Krzysztof Wilczynski, Simon Horman
Cc: Patrick McHardy, netdev@vger.kernel.org
In-Reply-To: <1318967989-14076-1-git-send-email-krzysztof.wilczynski@linux.com>
Hello
>This is to address the following warning during compilation time:
>
> net/netfilter/ipvs/ip_vs_core.c: In function ‘ip_vs_leave’:
> net/netfilter/ipvs/ip_vs_core.c:532: warning: unused variable ‘cs’
>
>This variable is indeed no longer in use.
>
>Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
In my code there is another fix needed as well (todays net-next)
i.e. usage od cs "cs = ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd)"
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 4f77bb1..a4ef9c6 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -530,7 +530,7 @@ int ip_vs_leave(struct ip_vs_service *svc, struct sk_buff *skb,
a cache_bypass connection entry */
ipvs = net_ipvs(net);
if (ipvs->sysctl_cache_bypass && svc->fwmark && unicast) {
- int ret, cs;
+ int ret;
struct ip_vs_conn *cp;
unsigned int flags = (svc->flags & IP_VS_SVC_F_ONEPACKET &&
iph.protocol == IPPROTO_UDP)?
@@ -557,7 +557,7 @@ int ip_vs_leave(struct ip_vs_service *svc, struct sk_buff *skb,
ip_vs_in_stats(cp, skb);
/* set state */
- cs = ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd);
+ ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd);
/* transmit the first SYN packet */
ret = cp->packet_xmit(skb, cp, pd->pp);
>---
> 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 00ea1ad..4f7d89d 100644
>--- a/net/netfilter/ipvs/ip_vs_core.c
>+++ b/net/netfilter/ipvs/ip_vs_core.c
>@@ -529,7 +529,7 @@ int ip_vs_leave(struct ip_vs_service *svc, struct sk_buff *skb,
> a cache_bypass connection entry */
> ipvs = net_ipvs(net);
> if (ipvs->sysctl_cache_bypass && svc->fwmark && unicast) {
>- int ret, cs;
>+ int ret;
> struct ip_vs_conn *cp;
> unsigned int flags = (svc->flags & IP_VS_SVC_F_ONEPACKET &&
> iph.protocol == IPPROTO_UDP)?
>--
>1.7.7
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>
^ permalink raw reply related
* [PATCH] smsc911x: Enable flow control advertisement
From: Kazunori Kobayashi @ 2011-10-19 9:21 UTC (permalink / raw)
To: netdev; +Cc: steve.glendinning, dhobsong, Kazunori Kobayashi
Enable the advertisement of both symmetric pause and asymmetric pause
flow control capability.
Signed-off-by: Kazunori Kobayashi <kkobayas@igel.co.jp>
---
drivers/net/smsc911x.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index b9016a3..60c3bc2 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -800,8 +800,13 @@ static void smsc911x_phy_update_flowcontrol(struct smsc911x_data *pdata)
struct phy_device *phy_dev = pdata->phy_dev;
u32 afc = smsc911x_reg_read(pdata, AFC_CFG);
u32 flow;
+ u16 miiadv = smsc911x_mii_read(phy_dev->bus, phy_dev->addr,
+ MII_ADVERTISE);
unsigned long flags;
+ miiadv |= (ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM);
+ smsc911x_mii_write(phy_dev->bus, phy_dev->addr, MII_ADVERTISE, miiadv);
+
if (phy_dev->duplex == DUPLEX_FULL) {
u16 lcladv = phy_read(phy_dev, MII_ADVERTISE);
u16 rmtadv = phy_read(phy_dev, MII_LPA);
--
1.7.0.4
^ permalink raw reply related
* Re: Problem with ixgbe and TX locked on one cpu
From: Paweł Staszewski @ 2011-10-19 9:21 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: Linux Network Development list, e1000-devel
In-Reply-To: <CAEuXFEy89F_=J_PJMSbQ1fDcOEkkpz2vucq3LcToi7rTcZHcDA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5739 bytes --]
W dniu 2011-10-18 20:57, Jesse Brandeburg pisze:
> CC: e1000-devel
>
> 2011/10/14 Paweł Staszewski<pstaszewski@itcare.pl>:
>> Hello
>>
>> I have weird problem with ixgbe and irq affinity / rx-tx queue assignment
> what application are you running, how are you using ixgbe? looks like
> a router. is something changing the skb->rx_queue entry (like
> netfilter) or is there a layered device above ixgbe (bonding or ...) ?
Yes it is a router. - Quagga - BGP
There is few (10rules) iptables rules in INPUT - and nothing more
There are also namespaces running - and traffic is processed in namespaces.
no bonding
> why do your interrupts move after a long period? did you do it by
> hand? we recommend disabling irqbalance and hand tuning interrupts
> possibly with the set_irq_affinity.sh script.
Yes it was changed by hand to check why TX is processed on one interrupt.
Also now it is impossible to move this TX traffic to other interrupt.
All configuration for affinity is made by hand - no irqbalance running.
>> Statistics for my ethernet - ixgbe driver:
>> ethtool -S eth4
>> NIC statistics:
>> rx_packets: 5815535848808
>> tx_packets: 5811202378421
>> rx_bytes: 4791001750842200
>> tx_bytes: 4781190419358301
>> rx_pkts_nic: 5815535848827
>> tx_pkts_nic: 5811202378510
>> rx_bytes_nic: 4837563124411799
>> tx_bytes_nic: 4829987507084013
>> lsc_int: 8
>> tx_busy: 0
>> non_eop_descs: 0
>> rx_errors: 0
>> tx_errors: 0
>> rx_dropped: 0
>> tx_dropped: 0
>> multicast: 92494273
>> broadcast: 268718206
>> rx_no_buffer_count: 28829
>> collisions: 0
>> rx_over_errors: 0
>> rx_crc_errors: 0
>> rx_frame_errors: 0
>> hw_rsc_aggregated: 0
>> hw_rsc_flushed: 0
>> fdir_match: 0
>> fdir_miss: 0
>> rx_fifo_errors: 0
>> rx_missed_errors: 307051074
>> tx_aborted_errors: 0
>> tx_carrier_errors: 0
>> tx_fifo_errors: 0
>> tx_heartbeat_errors: 0
>> tx_timeout_count: 0
>> tx_restart_queue: 15926219
>> rx_long_length_errors: 298
>> rx_short_length_errors: 0
>> tx_flow_control_xon: 0
>> rx_flow_control_xon: 0
>> tx_flow_control_xoff: 0
>> rx_flow_control_xoff: 0
>> rx_csum_offload_errors: 54173917
>> alloc_rx_page_failed: 0
>> alloc_rx_buff_failed: 0
>> rx_no_dma_resources: 0
>> tx_queue_0_packets: 68694825
>> tx_queue_0_bytes: 9443750332
>> tx_queue_1_packets: 8410961
>> tx_queue_1_bytes: 2527763233
>> tx_queue_2_packets: 14411252
>> tx_queue_2_bytes: 1317132394
>> tx_queue_3_packets: 15013508147
>> tx_queue_3_bytes: 17364767277348
>> tx_queue_4_packets: 62779891
>> tx_queue_4_bytes: 63476596221
>> tx_queue_5_packets: 11176001
>> tx_queue_5_bytes: 2763600253
>> tx_queue_6_packets: 4416357
>> tx_queue_6_bytes: 611874984
>> tx_queue_7_packets: 8933405
>> tx_queue_7_bytes: 1837198524
>> tx_queue_8_packets: 13292669
>> tx_queue_8_bytes: 3241333510
>> tx_queue_9_packets: 10747236
>> tx_queue_9_bytes: 1805109931
>> tx_queue_10_packets: 5795935258380
>> tx_queue_10_bytes: 4763725304722245
>> tx_queue_11_packets: 12073934
>> tx_queue_11_bytes: 2982743045
>> tx_queue_12_packets: 10523764
>> tx_queue_12_bytes: 2637451199
>> tx_queue_13_packets: 12480552
>> tx_queue_13_bytes: 2434827407
>> tx_queue_14_packets: 7401777
>> tx_queue_14_bytes: 2413618099
>> tx_queue_15_packets: 8269270
>> tx_queue_15_bytes: 2854359576
>> rx_queue_0_packets: 361373769507
>> rx_queue_0_bytes: 298565751248279
>> rx_queue_1_packets: 369901571908
>> rx_queue_1_bytes: 303414679798160
>> rx_queue_2_packets: 362508961738
>> rx_queue_2_bytes: 299852439447157
>> rx_queue_3_packets: 363449272013
>> rx_queue_3_bytes: 299738390792515
>> rx_queue_4_packets: 361876234461
>> rx_queue_4_bytes: 297483366939732
>> rx_queue_5_packets: 361402926316
>> rx_queue_5_bytes: 297633876486533
>> rx_queue_6_packets: 362261522767
>> rx_queue_6_bytes: 298026696344647
>> rx_queue_7_packets: 361248593301
>> rx_queue_7_bytes: 296756459279986
>> rx_queue_8_packets: 361654143416
>> rx_queue_8_bytes: 298272433659520
>> rx_queue_9_packets: 362781764710
>> rx_queue_9_bytes: 298804803191595
>> rx_queue_10_packets: 361386593064
>> rx_queue_10_bytes: 297434987797644
>> rx_queue_11_packets: 369886597895
>> rx_queue_11_bytes: 302353350171712
>> rx_queue_12_packets: 361582732276
>> rx_queue_12_bytes: 298670408005971
>> rx_queue_13_packets: 365248093536
>> rx_queue_13_bytes: 302573023878287
>> rx_queue_14_packets: 366571142073
>> rx_queue_14_bytes: 302396739276514
>> rx_queue_15_packets: 362401929830
>> rx_queue_15_bytes: 299024344526029
>>
>> The problem is with queue 10
>> tx_queue_10_packets: 5795935258380
>> tx_queue_10_bytes: 4763725304722245
>>
>> as you can see most of the queue processing is used in queue 10
>> Average difference is 1,854271229903958e-6 - compared to other queues
>>
>> and the problem is that almost all TX packet processing is on one CPU
>> cat /proc/interrupts - in attached file
>>
>> Is this driver or kernel problem ?
>>
>> Kernel is: 2.6.38.2
>>
>> ixgbe driver is:
>> ethtool -i eth4
>> driver: ixgbe
>> version: 3.2.9-k2
>> firmware-version: 1.12-2
>> bus-info: 0000:04:00.0
> --
> 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: pstaszewski.vcf --]
[-- Type: text/x-vcard, Size: 336 bytes --]
begin:vcard
fn;quoted-printable:Pawe=C5=82 Staszewski
n;quoted-printable:Staszewski;Pawe=C5=82
org:ITCare
adr;quoted-printable;quoted-printable;dom:;;Sikorskiego 22;Libi=C4=85=C5=BC;Ma=C5=82opolskie;32-590
title:IT Manager
tel;work:+48 32 7203681
tel;fax:+48 32 7203682
tel;cell:+48 0 609911040
url:www.itcare.pl
version:2.1
end:vcard
^ permalink raw reply
* Re: Problem with ixgbe and TX locked on one cpu
From: Paweł Staszewski @ 2011-10-19 9:21 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: e1000-devel, Linux Network Development list
In-Reply-To: <CAEuXFEy89F_=J_PJMSbQ1fDcOEkkpz2vucq3LcToi7rTcZHcDA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5738 bytes --]
W dniu 2011-10-18 20:57, Jesse Brandeburg pisze:
> CC: e1000-devel
>
> 2011/10/14 Paweł Staszewski<pstaszewski@itcare.pl>:
>> Hello
>>
>> I have weird problem with ixgbe and irq affinity / rx-tx queue assignment
> what application are you running, how are you using ixgbe? looks like
> a router. is something changing the skb->rx_queue entry (like
> netfilter) or is there a layered device above ixgbe (bonding or ...) ?
Yes it is a router. - Quagga - BGP
There is few (10rules) iptables rules in INPUT - and nothing more
There are also namespaces running - and traffic is processed in namespaces.
no bonding
> why do your interrupts move after a long period? did you do it by
> hand? we recommend disabling irqbalance and hand tuning interrupts
> possibly with the set_irq_affinity.sh script.
Yes it was changed by hand to check why TX is processed on one interrupt.
Also now it is impossible to move this TX traffic to other interrupt.
All configuration for affinity is made by hand - no irqbalance running.
>> Statistics for my ethernet - ixgbe driver:
>> ethtool -S eth4
>> NIC statistics:
>> rx_packets: 5815535848808
>> tx_packets: 5811202378421
>> rx_bytes: 4791001750842200
>> tx_bytes: 4781190419358301
>> rx_pkts_nic: 5815535848827
>> tx_pkts_nic: 5811202378510
>> rx_bytes_nic: 4837563124411799
>> tx_bytes_nic: 4829987507084013
>> lsc_int: 8
>> tx_busy: 0
>> non_eop_descs: 0
>> rx_errors: 0
>> tx_errors: 0
>> rx_dropped: 0
>> tx_dropped: 0
>> multicast: 92494273
>> broadcast: 268718206
>> rx_no_buffer_count: 28829
>> collisions: 0
>> rx_over_errors: 0
>> rx_crc_errors: 0
>> rx_frame_errors: 0
>> hw_rsc_aggregated: 0
>> hw_rsc_flushed: 0
>> fdir_match: 0
>> fdir_miss: 0
>> rx_fifo_errors: 0
>> rx_missed_errors: 307051074
>> tx_aborted_errors: 0
>> tx_carrier_errors: 0
>> tx_fifo_errors: 0
>> tx_heartbeat_errors: 0
>> tx_timeout_count: 0
>> tx_restart_queue: 15926219
>> rx_long_length_errors: 298
>> rx_short_length_errors: 0
>> tx_flow_control_xon: 0
>> rx_flow_control_xon: 0
>> tx_flow_control_xoff: 0
>> rx_flow_control_xoff: 0
>> rx_csum_offload_errors: 54173917
>> alloc_rx_page_failed: 0
>> alloc_rx_buff_failed: 0
>> rx_no_dma_resources: 0
>> tx_queue_0_packets: 68694825
>> tx_queue_0_bytes: 9443750332
>> tx_queue_1_packets: 8410961
>> tx_queue_1_bytes: 2527763233
>> tx_queue_2_packets: 14411252
>> tx_queue_2_bytes: 1317132394
>> tx_queue_3_packets: 15013508147
>> tx_queue_3_bytes: 17364767277348
>> tx_queue_4_packets: 62779891
>> tx_queue_4_bytes: 63476596221
>> tx_queue_5_packets: 11176001
>> tx_queue_5_bytes: 2763600253
>> tx_queue_6_packets: 4416357
>> tx_queue_6_bytes: 611874984
>> tx_queue_7_packets: 8933405
>> tx_queue_7_bytes: 1837198524
>> tx_queue_8_packets: 13292669
>> tx_queue_8_bytes: 3241333510
>> tx_queue_9_packets: 10747236
>> tx_queue_9_bytes: 1805109931
>> tx_queue_10_packets: 5795935258380
>> tx_queue_10_bytes: 4763725304722245
>> tx_queue_11_packets: 12073934
>> tx_queue_11_bytes: 2982743045
>> tx_queue_12_packets: 10523764
>> tx_queue_12_bytes: 2637451199
>> tx_queue_13_packets: 12480552
>> tx_queue_13_bytes: 2434827407
>> tx_queue_14_packets: 7401777
>> tx_queue_14_bytes: 2413618099
>> tx_queue_15_packets: 8269270
>> tx_queue_15_bytes: 2854359576
>> rx_queue_0_packets: 361373769507
>> rx_queue_0_bytes: 298565751248279
>> rx_queue_1_packets: 369901571908
>> rx_queue_1_bytes: 303414679798160
>> rx_queue_2_packets: 362508961738
>> rx_queue_2_bytes: 299852439447157
>> rx_queue_3_packets: 363449272013
>> rx_queue_3_bytes: 299738390792515
>> rx_queue_4_packets: 361876234461
>> rx_queue_4_bytes: 297483366939732
>> rx_queue_5_packets: 361402926316
>> rx_queue_5_bytes: 297633876486533
>> rx_queue_6_packets: 362261522767
>> rx_queue_6_bytes: 298026696344647
>> rx_queue_7_packets: 361248593301
>> rx_queue_7_bytes: 296756459279986
>> rx_queue_8_packets: 361654143416
>> rx_queue_8_bytes: 298272433659520
>> rx_queue_9_packets: 362781764710
>> rx_queue_9_bytes: 298804803191595
>> rx_queue_10_packets: 361386593064
>> rx_queue_10_bytes: 297434987797644
>> rx_queue_11_packets: 369886597895
>> rx_queue_11_bytes: 302353350171712
>> rx_queue_12_packets: 361582732276
>> rx_queue_12_bytes: 298670408005971
>> rx_queue_13_packets: 365248093536
>> rx_queue_13_bytes: 302573023878287
>> rx_queue_14_packets: 366571142073
>> rx_queue_14_bytes: 302396739276514
>> rx_queue_15_packets: 362401929830
>> rx_queue_15_bytes: 299024344526029
>>
>> The problem is with queue 10
>> tx_queue_10_packets: 5795935258380
>> tx_queue_10_bytes: 4763725304722245
>>
>> as you can see most of the queue processing is used in queue 10
>> Average difference is 1,854271229903958e-6 - compared to other queues
>>
>> and the problem is that almost all TX packet processing is on one CPU
>> cat /proc/interrupts - in attached file
>>
>> Is this driver or kernel problem ?
>>
>> Kernel is: 2.6.38.2
>>
>> ixgbe driver is:
>> ethtool -i eth4
>> driver: ixgbe
>> version: 3.2.9-k2
>> firmware-version: 1.12-2
>> bus-info: 0000:04:00.0
> --
> 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: text/plain, Size: 377 bytes --]
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] iproute2: Conforming to -D_FORTIFY_SOURCE=2 restrictions
From: Bin Li @ 2011-10-19 9:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20111017082307.46a994a8@nehalam.linuxnetplumber.net>
Stephen,
You can reproduce this issue in 2.6.37 like below. And the previous
gdb log is after the install the debuginfo package in SUSE.
# ip -6 xfrm state add src 3ffe:501:ffff:ff03:21a:64ff:fe12:e4c1 dst
3ffe:501:ffff:ff05:200:ff:fe00:c1c1 proto ah spi 0x1000 mode transport
auth md5 "TAHITEST89ABCDEF"
*** buffer overflow detected ***: ip terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x40)[0xb76d0070]
/lib/libc.so.6(+0xe8e27)[0xb76cde27]
/lib/libc.so.6(+0xe8317)[0xb76cd317]
ip[0x806d6c4]
ip(do_xfrm_state+0x120)[0x806dc70]
ip(do_xfrm+0x81)[0x806ad51]
ip[0x804c355]
ip(main+0x476)[0x804caa6]
/lib/libc.so.6(__libc_start_main+0xfe)[0xb75fbc2e]
ip[0x804c261]
======= Memory map: ========
08048000-08087000 r-xp 00000000 08:01 4465 /sbin/ip
08087000-08088000 r--p 0003e000 08:01 4465 /sbin/ip
08088000-0808a000 rw-p 0003f000 08:01 4465 /sbin/ip
0808a000-080ad000 rw-p 00000000 00:00 0 [heap]
b75c6000-b75e2000 r-xp 00000000 08:01 131084 /lib/libgcc_s.so.1
b75e2000-b75e3000 r--p 0001b000 08:01 131084 /lib/libgcc_s.so.1
b75e3000-b75e4000 rw-p 0001c000 08:01 131084 /lib/libgcc_s.so.1
b75e4000-b75e5000 rw-p 00000000 00:00 0
b75e5000-b774b000 r-xp 00000000 08:01 131375 /lib/libc-2.11.3.so
b774b000-b774c000 ---p 00166000 08:01 131375 /lib/libc-2.11.3.so
b774c000-b774e000 r--p 00166000 08:01 131375 /lib/libc-2.11.3.so
b774e000-b774f000 rw-p 00168000 08:01 131375 /lib/libc-2.11.3.so
b774f000-b7752000 rw-p 00000000 00:00 0
b7752000-b7755000 r-xp 00000000 08:01 131428 /lib/libdl-2.11.3.so
b7755000-b7756000 r--p 00002000 08:01 131428 /lib/libdl-2.11.3.so
b7756000-b7757000 rw-p 00003000 08:01 131428 /lib/libdl-2.11.3.so
b7774000-b7775000 rw-p 00000000 00:00 0
b7775000-b7794000 r-xp 00000000 08:01 154467 /lib/ld-2.11.3.so
b7794000-b7795000 r--p 0001e000 08:01 154467 /lib/ld-2.11.3.so
b7795000-b7796000 rw-p 0001f000 08:01 154467 /lib/ld-2.11.3.so
bfa02000-bfa23000 rw-p 00000000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
Aborted
And If without -D_FORTIFY_SOURCE=2 in gcc, it works fine, so It's a
bug in iproute2 which is not conforming to -D_FORTIFY_SOURCE=2
restrictions.
Thanks!
On Mon, Oct 17, 2011 at 11:23 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Mon, 17 Oct 2011 15:35:35 +0800
> Bin Li <libin.charles@gmail.com> wrote:
>
>> (gdb) l
>> 161 len = slen;
>> 162 if (len > 0) {
>> 163 if (len > max)
>> 164 invarg("\"ALGOKEY\" makes buffer
>> overflow\n", key);
>> 165
>> 166 strncpy(buf, key, len);
>> 167 }
>> 168 }
>> 169
>> 170 alg->alg_key_len = len * 8;
>> (gdb) up
>> #8 xfrm_state_modify (cmd=<optimized out>, flags=<optimized out>, argc=1,
>> argv=0x7fffffffe370) at xfrm_state.c:406
>> 406 xfrm_algo_parse((void *)&alg, type,
>> name, key,
>>
>> the compiler passes zero to __builtin___strncpy_chk as the buffer size.
>> xfrm_algo_parse is inlined into xfrm_state_modify.
>
> I don't understand, looks like a compiler bug. Call strncpy with
> 0 length should not be possible since the check was 3 lines
> before for len > 0.
>
^ permalink raw reply
* Re: [PATCH] Fix guest memory leak and panic
From: Eric Dumazet @ 2011-10-19 9:07 UTC (permalink / raw)
To: Ian Campbell
Cc: Krishna Kumar, rusty@rustcorp.com.au, mst@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, davem@davemloft.net
In-Reply-To: <1319014511.3385.72.camel@zakaz.uk.xensource.com>
Le mercredi 19 octobre 2011 à 09:55 +0100, Ian Campbell a écrit :
> On Tue, 2011-10-18 at 14:20 +0100, Eric Dumazet wrote:
> > But I suggest using get_page(pkt_dev->page), this seems more obvious to
> > me [ This was how I wrote the thing ;) ]
>
> I guess it depends on whether you consider the reference to be on the
> page or to be on the frag (which contains the page). The distinction
> would only matter if pktgen were to transition to using the forthcoming
> destructors though.
>
Yes, but get_page() is now a clear sign we dirty a cache line, and I am
trying to explain to driver authors this is a contention point they
should address to get best performance from sub-page frags devices.
The hidden __skb_frag_ref() in skb_frag_set_page() was misleading
them ;)
> Here's a version like you describe:
>
> 8<---------------------------------------------------------------
>
> From 369022220db31efb9c261cbabcb890a4d216a176 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Tue, 18 Oct 2011 09:59:37 +0100
> Subject: [PATCH] net: do not take an additional reference in skb_frag_set_page
>
> I audited all of the callers in the tree and only one of them (pktgen) expects
> it to do so. Taking this reference is pretty obviously confusing and error
> prone.
>
> In particular I looked at the following commits which switched callers of
> (__)skb_frag_set_page to the skb paged fragment api:
>
> 6a930b9f163d7e6d9ef692e05616c4ede65038ec cxgb3: convert to SKB paged frag API.
> 5dc3e196ea21e833128d51eb5b788a070fea1f28 myri10ge: convert to SKB paged frag API.
> 0e0634d20dd670a89af19af2a686a6cce943ac14 vmxnet3: convert to SKB paged frag API.
> 86ee8130a46769f73f8f423f99dbf782a09f9233 virtionet: convert to SKB paged frag API.
> 4a22c4c919c201c2a7f4ee09e672435a3072d875 sfc: convert to SKB paged frag API.
> 18324d690d6a5028e3c174fc1921447aedead2b8 cassini: convert to SKB paged frag API.
> b061b39e3ae18ad75466258cf2116e18fa5bbd80 benet: convert to SKB paged frag API.
> b7b6a688d217936459ff5cf1087b2361db952509 bnx2: convert to SKB paged frag API.
> 804cf14ea5ceca46554d5801e2817bba8116b7e5 net: xfrm: convert to SKB frag APIs
> ea2ab69379a941c6f8884e290fdd28c93936a778 net: convert core to skb paged frag APIs
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> include/linux/skbuff.h | 1 -
> net/core/pktgen.c | 1 +
> 2 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 64f8695..78741da 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1765,7 +1765,6 @@ static inline void *skb_frag_address_safe(const skb_frag_t *frag)
> static inline void __skb_frag_set_page(skb_frag_t *frag, struct page *page)
> {
> frag->page = page;
> - __skb_frag_ref(frag);
> }
>
> /**
> diff --git a/net/core/pktgen.c b/net/core/pktgen.c
> index 796044a..e81f5d0 100644
> --- a/net/core/pktgen.c
> +++ b/net/core/pktgen.c
> @@ -2602,6 +2602,7 @@ static void pktgen_finalize_skb(struct pktgen_dev *pkt_dev, struct sk_buff *skb,
> if (!pkt_dev->page)
> break;
> }
> + get_page(pkt_dev->page);
> skb_frag_set_page(skb, i, pkt_dev->page);
> skb_shinfo(skb)->frags[i].page_offset = 0;
> /*last fragment, fill rest of data*/
Thanks !
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/4] ipv4: Fix pmtu propagating
From: Gao feng @ 2011-10-19 9:07 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20111017121805.GR1830@secunet.com>
2011.10.17 20:18, Steffen Klassert wrote:
> On Fri, Oct 14, 2011 at 07:54:06AM +0200, Steffen Klassert wrote:
>> On Thu, Oct 13, 2011 at 01:58:08PM -0400, David Miller wrote:
>>>
>>> Please find out exactly why dst->obsolete is non-zero on a freshly
>>> looked up route. It's unexpected.
>>
>> Hm, on a slow path route lookup e.g. __mkroute_output() calls
>> rt_dst_alloc() which initializes dst->obsolete to -1.
>
> Just a follow up:
> git commit d11a4dc18 (ipv4: check rt_genid in dst_check)
> changed the initialization value of dst->obsolete from
> 0 to -1.
> --
Anybody give any suggestion?
Actually,we can't suppose the dst->obsolete is non-zero.
maybe we should use both dst->obsolete and rt->rt_peer_genid to decide whether to do dst_check or not?
^ permalink raw reply
* Re: [PATCH] route:ip_rt_frag_needed always return unzero
From: Gao feng @ 2011-10-19 8:59 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Eric Dumazet, davem, kuznet, jmorris, netdev
In-Reply-To: <20111019083832.GT1830@secunet.com>
2011.10.19 16:38, Steffen Klassert wrote:
> On Wed, Oct 19, 2011 at 04:07:46PM +0800, Gao feng wrote:
>> 2011.10.19 15:26, Steffen Klassert wrote:
>>
>>>
>>> It is valid in the sense that we should not provide the user
>>> with a mtu information if we know that the value we got from
>>> the icmp packet ist bogus. But perhaps we can think about
>>> making the check for a valid mtu unconditionally and let
>>> ip_rt_frag_needed return a valid mtu in any case.
>>>
>>>
>>
>> I think we should return the pmtu in icmp packet to the raw socket,
>> and the valid mtu to tcp_v4_err or something else.
>>
>
> Why you want to handle raw sockets different here?
>
Return the pmtu in icmp packet to the raw socket,
let user space program to decide what to do.
BUT this is not important.
^ permalink raw reply
* Re: [PATCH] Fix guest memory leak and panic
From: Ian Campbell @ 2011-10-19 8:55 UTC (permalink / raw)
To: Eric Dumazet
Cc: Krishna Kumar, rusty@rustcorp.com.au, mst@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, davem@davemloft.net
In-Reply-To: <1318944002.2657.76.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Tue, 2011-10-18 at 14:20 +0100, Eric Dumazet wrote:
> But I suggest using get_page(pkt_dev->page), this seems more obvious to
> me [ This was how I wrote the thing ;) ]
I guess it depends on whether you consider the reference to be on the
page or to be on the frag (which contains the page). The distinction
would only matter if pktgen were to transition to using the forthcoming
destructors though.
Here's a version like you describe:
8<---------------------------------------------------------------
>From 369022220db31efb9c261cbabcb890a4d216a176 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Tue, 18 Oct 2011 09:59:37 +0100
Subject: [PATCH] net: do not take an additional reference in skb_frag_set_page
I audited all of the callers in the tree and only one of them (pktgen) expects
it to do so. Taking this reference is pretty obviously confusing and error
prone.
In particular I looked at the following commits which switched callers of
(__)skb_frag_set_page to the skb paged fragment api:
6a930b9f163d7e6d9ef692e05616c4ede65038ec cxgb3: convert to SKB paged frag API.
5dc3e196ea21e833128d51eb5b788a070fea1f28 myri10ge: convert to SKB paged frag API.
0e0634d20dd670a89af19af2a686a6cce943ac14 vmxnet3: convert to SKB paged frag API.
86ee8130a46769f73f8f423f99dbf782a09f9233 virtionet: convert to SKB paged frag API.
4a22c4c919c201c2a7f4ee09e672435a3072d875 sfc: convert to SKB paged frag API.
18324d690d6a5028e3c174fc1921447aedead2b8 cassini: convert to SKB paged frag API.
b061b39e3ae18ad75466258cf2116e18fa5bbd80 benet: convert to SKB paged frag API.
b7b6a688d217936459ff5cf1087b2361db952509 bnx2: convert to SKB paged frag API.
804cf14ea5ceca46554d5801e2817bba8116b7e5 net: xfrm: convert to SKB frag APIs
ea2ab69379a941c6f8884e290fdd28c93936a778 net: convert core to skb paged frag APIs
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
include/linux/skbuff.h | 1 -
net/core/pktgen.c | 1 +
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 64f8695..78741da 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1765,7 +1765,6 @@ static inline void *skb_frag_address_safe(const skb_frag_t *frag)
static inline void __skb_frag_set_page(skb_frag_t *frag, struct page *page)
{
frag->page = page;
- __skb_frag_ref(frag);
}
/**
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 796044a..e81f5d0 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2602,6 +2602,7 @@ static void pktgen_finalize_skb(struct pktgen_dev *pkt_dev, struct sk_buff *skb,
if (!pkt_dev->page)
break;
}
+ get_page(pkt_dev->page);
skb_frag_set_page(skb, i, pkt_dev->page);
skb_shinfo(skb)->frags[i].page_offset = 0;
/*last fragment, fill rest of data*/
--
1.7.2.5
^ permalink raw reply related
* Re: kenel level packet capturing
From: Ajith Adapa @ 2011-10-19 8:52 UTC (permalink / raw)
To: David Miller; +Cc: raviraj.j1991, netdev, netfilter-devel, netfilter
In-Reply-To: <20111019.031314.1383303852454510720.davem@davemloft.net>
Yeah you are right David. But ..
For a newbie who just know more about linux userspace level need to
know starting steps like where to start from and flow of packet might
be confusing because of the level of abstraction being used. I guess
it might take some time until you are really serious about making
hands dirty :)
Regards,
Ajith
On Wed, Oct 19, 2011 at 12:43 PM, David Miller <davem@davemloft.net> wrote:
>
> From: raviraj joshi <raviraj.j1991@gmail.com>
> Date: Wed, 19 Oct 2011 12:24:01 +0530
>
> > We are finding it difficult to understand kenel networking code.
>
> That's surprising, because the Linux networking stack is the cleanest
> real world networking implementation on the planet.
>
> Perhaps you should think about re-evaluating your project choice?
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-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
* [PATCH net-next] igb: fix a compile warning
From: roy.qing.li @ 2011-10-19 8:52 UTC (permalink / raw)
To: netdev
From: RongQing Li <roy.qing.li@gmail.com>
control these three function declarations and
definitions with same macro CONFIG_PCI_IOV
drivers/net/ethernet/intel/igb/igb_main.c:165:
warning: ‘igb_vf_configure’ declared ‘static’ but never defined
drivers/net/ethernet/intel/igb/igb_main.c:166:
warning: ‘igb_find_enabled_vfs’ declared ‘static’ but never defined
drivers/net/ethernet/intel/igb/igb_main.c:167:
warning: ‘igb_check_vf_assignment’ declared ‘static’ but never defined
Signed-off-by: RongQing Li <roy.qing.li@gmail.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 837adbb..5d16cdc 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -162,9 +162,12 @@ static int igb_ndo_set_vf_bw(struct net_device *netdev, int vf, int tx_rate);
static int igb_ndo_get_vf_config(struct net_device *netdev, int vf,
struct ifla_vf_info *ivi);
static void igb_check_vf_rate_limit(struct igb_adapter *);
+
+#ifdef CONFIG_PCI_IOV
static int igb_vf_configure(struct igb_adapter *adapter, int vf);
static int igb_find_enabled_vfs(struct igb_adapter *adapter);
static int igb_check_vf_assignment(struct igb_adapter *adapter);
+#endif
#ifdef CONFIG_PM
static int igb_suspend(struct pci_dev *, pm_message_t);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] route:ip_rt_frag_needed always return unzero
From: Steffen Klassert @ 2011-10-19 8:38 UTC (permalink / raw)
To: Gao feng; +Cc: Eric Dumazet, davem, kuznet, jmorris, netdev
In-Reply-To: <4E9E8552.1050405@cn.fujitsu.com>
On Wed, Oct 19, 2011 at 04:07:46PM +0800, Gao feng wrote:
> 2011.10.19 15:26, Steffen Klassert wrote:
>
> >
> > It is valid in the sense that we should not provide the user
> > with a mtu information if we know that the value we got from
> > the icmp packet ist bogus. But perhaps we can think about
> > making the check for a valid mtu unconditionally and let
> > ip_rt_frag_needed return a valid mtu in any case.
> >
> >
>
> I think we should return the pmtu in icmp packet to the raw socket,
> and the valid mtu to tcp_v4_err or something else.
>
Why you want to handle raw sockets different here?
^ permalink raw reply
* [PATCH net -v2] [BUGFIX] bonding: use flush_delayed_work_sync in bond_close
From: Mitsuo Hayasaka @ 2011-10-19 8:17 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek
Cc: netdev, linux-kernel, yrl.pp-manager.tt, Mitsuo Hayasaka,
Jay Vosburgh, Andy Gospodarek, WANG Cong
The bond_close() calls cancel_delayed_work() to cancel delayed works.
It, however, cannot cancel works that were already queued in workqueue.
The bond_open() initializes work->data, and proccess_one_work() refers
get_work_cwq(work)->wq->flags. The get_work_cwq() returns NULL when
work->data has been initialized. Thus, a panic occurs.
This patch uses flush_delayed_work_sync() instead of cancel_delayed_work()
in bond_close(). It cancels delayed timer and waits for work to finish
execution. So, it can avoid the null pointer dereference due to the
parallel executions of proccess_one_work() and initializing proccess
of bond_open().
Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>
Cc: Jay Vosburgh <fubar@us.ibm.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
Cc: WANG Cong <xiyou.wangcong@gmail.com>
---
drivers/net/bonding/bond_main.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index de3d351..a4353f9 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3504,27 +3504,27 @@ static int bond_close(struct net_device *bond_dev)
write_unlock_bh(&bond->lock);
if (bond->params.miimon) { /* link check interval, in milliseconds. */
- cancel_delayed_work(&bond->mii_work);
+ flush_delayed_work_sync(&bond->mii_work);
}
if (bond->params.arp_interval) { /* arp interval, in milliseconds. */
- cancel_delayed_work(&bond->arp_work);
+ flush_delayed_work_sync(&bond->arp_work);
}
switch (bond->params.mode) {
case BOND_MODE_8023AD:
- cancel_delayed_work(&bond->ad_work);
+ flush_delayed_work_sync(&bond->ad_work);
break;
case BOND_MODE_TLB:
case BOND_MODE_ALB:
- cancel_delayed_work(&bond->alb_work);
+ flush_delayed_work_sync(&bond->alb_work);
break;
default:
break;
}
if (delayed_work_pending(&bond->mcast_work))
- cancel_delayed_work(&bond->mcast_work);
+ flush_delayed_work_sync(&bond->mcast_work);
if (bond_is_lb(bond)) {
/* Must be called only after all
^ permalink raw reply related
* Re: PROBLEM: System call 'sendmsg' of process ospfd (quagga) causes kernel oops
From: Herbert Xu @ 2011-10-19 8:08 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, evonlanthen, linux-kernel, netdev, timo.teras
In-Reply-To: <20111019.033052.851679720607111734.davem@davemloft.net>
On Wed, Oct 19, 2011 at 03:30:52AM -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 19 Oct 2011 09:18:33 +0200
>
> > Seems fine (Maybe do the +15 in caller site ?), but we also have other
> > problematic cases, using alloc_skb() only...
>
> Ok, which ones operate over these problematic GRE tunnels?
Potentially all of them since we now support Ethernet-over-GRE.
I think Eric's initial patch is probably the safest bet for rc10.
We can then work on the proper fix for the next release.
As to the latter, I've just done a grep over net and it seems that
all users of LL_ALLOCATED_SPACE fall into two cases, alloc_skb users
or sock_alloc_send_skb (including pskb) users.
For alloc_skb we could add a new helper. While for the other
case we could either create a new helper or just add an extra
dev argument that may be NULL for those that don't care about
LL_ALLOCATED_SPACE.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] route:ip_rt_frag_needed always return unzero
From: Gao feng @ 2011-10-19 8:07 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Eric Dumazet, davem, kuznet, jmorris, netdev
In-Reply-To: <20111019072628.GS1830@secunet.com>
2011.10.19 15:26, Steffen Klassert wrote:
>
> On udp and raw sockets, the user is responsible to adjust the packet
> size according to the mtu value he may find in the socket's error queue.
> So we shoud provide the user with this information, even in the unlikely
> case where we could not create an inet_peer.
>
Agree.Maybe we should modify mtu immediately when create inet_peer failed
>
> It is valid in the sense that we should not provide the user
> with a mtu information if we know that the value we got from
> the icmp packet ist bogus. But perhaps we can think about
> making the check for a valid mtu unconditionally and let
> ip_rt_frag_needed return a valid mtu in any case.
>
>
I think we should return the pmtu in icmp packet to the raw socket,
and the valid mtu to tcp_v4_err or something else.
thanks Steffen.
^ permalink raw reply
* Re: PROBLEM: System call 'sendmsg' of process ospfd (quagga) causes kernel oops
From: David Miller @ 2011-10-19 8:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: herbert, evonlanthen, linux-kernel, netdev, timo.teras
In-Reply-To: <1319010739.18562.6.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 19 Oct 2011 09:52:19 +0200
> For GRE tunnels, I dont think IPv6 fragmentation could be relevant,
> but maybe IGMP could trigger a problem ?
Funny... icmpv6 uses ip6_append_data() which uses hh_len in a
local variable, which seems to suggest that it's immune to
this problem.
IPV4 side seems identical in this regard.
So, as far as I can see, my patch is sufficient to cover IP_GRE
reasonably in the 'net' tree.
Agreed?
If so, someone please test this thing :-)
^ permalink raw reply
* RE: [patch net-next]alx: Atheros AR8131/AR8151/AR8152/AR8161 Ethernet driver
From: Joe Perches @ 2011-10-19 7:56 UTC (permalink / raw)
To: Ren, Cloud
Cc: David Miller, Rodriguez, Luis, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <6349D7A510622448B1BA0967850A8438011CBA5D@nasanexd02d.na.qualcomm.com>
> ----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> From: <cloud.ren@Atheros.com>
> Date: Wed, 19 Oct 2011 15:26:53 +0800
> > +#define HW_PRINT(_klv, _fmt, _args...) \
> > + if (ALX_HW_MSG_LV_##_klv || ALX_HW_MSG_LV_ALL) {\
> > + printk(KERN_##_klv ALX_HW_MSG_PFX_NAME "%s: " _fmt, \
> > + __func__, ## _args); \
> > + }
> Do not create your own network driver debugging facilities and macros
> for logging messages, we have rich debugging and logging level
> interfaces that network drivers can use exactly for this purpose.
On Wed, 2011-10-19 at 07:44 +0000, Ren, Cloud wrote:
> Ok. What logging interfaces can I use? Are they dev_err, dev_info and
dev_warn ? thanks
Add and use #define pr_fmt
Logging functions/macros are:
pr_<level>(fmt, ...)
dev_<level>(struct device *, fmt, ...)
netdev_<level>(struct net_device *, fmt, ...)
netif_<level>(priv, type, struct net_device *, fmt, ...)
You chose to add __func__ to all of this output.
I don't think that's particularly valuable.
^ permalink raw reply
* Re: [PATCH net-next] bonding: fix wrong port enabling in 802.3ad
From: David Miller @ 2011-10-19 7:53 UTC (permalink / raw)
To: fbl; +Cc: netdev, fubar, andy
In-Reply-To: <1318526483-16073-1-git-send-email-fbl@redhat.com>
From: Flavio Leitner <fbl@redhat.com>
Date: Thu, 13 Oct 2011 14:21:23 -0300
> The port shouldn't be enabled unless its current MUX
> state is DISTRIBUTING which is correctly handled by
> ad_mux_machine(), otherwise the packet sent can be
> lost because the other end may not be ready.
>
> The issue happens on every port initialization, but
> as the ports are expected to move quickly to DISTRIBUTING,
> it doesn't cause much problem. However, it does cause
> constant packet loss if the other peer has the port
> configured to stay in STANDBY (i.e. SYNC set to OFF).
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
Applied, thanks.
^ permalink raw reply
* RE: [patch net-next]alx: Atheros AR8131/AR8151/AR8152/AR8161 Ethernet driver
From: Ren, Cloud @ 2011-10-19 7:53 UTC (permalink / raw)
To: David Miller
Cc: Rodriguez, Luis, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20111019.035000.931404890148181821.davem@davemloft.net>
I got it. Thanks.
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Wednesday, October 19, 2011 3:50 PM
To: Ren, Cloud
Cc: Rodriguez, Luis; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [patch net-next]alx: Atheros AR8131/AR8151/AR8152/AR8161 Ethernet driver
From: "Ren, Cloud" <cjren@qca.qualcomm.com>
Date: Wed, 19 Oct 2011 07:44:02 +0000
> Ok. What logging interfaces can I use? Are they dev_err, dev_info and
> dev_warn ? thanks
netif_*(), they check netif_msg_*() to see if the particular kind of logging message is enabled or not, and this can be set dynamically if you code your driver to properly set netdev->msg_enable.
Use other drivers as examples.
^ permalink raw reply
* Re: PROBLEM: System call 'sendmsg' of process ospfd (quagga) causes kernel oops
From: Eric Dumazet @ 2011-10-19 7:52 UTC (permalink / raw)
To: David Miller; +Cc: herbert, evonlanthen, linux-kernel, netdev, timo.teras
In-Reply-To: <20111019.033052.851679720607111734.davem@davemloft.net>
Le mercredi 19 octobre 2011 à 03:30 -0400, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 19 Oct 2011 09:18:33 +0200
>
> > Seems fine (Maybe do the +15 in caller site ?), but we also have other
> > problematic cases, using alloc_skb() only...
>
> Ok, which ones operate over these problematic GRE tunnels?
>
I was more thinking of general idea to allow any device to change its
needed headroom.
For GRE tunnels, I dont think IPv6 fragmentation could be relevant,
but maybe IGMP could trigger a problem ?
^ permalink raw reply
* Re: BUG in skb_pull with e1000e, PPTP, and L2TP
From: David Miller @ 2011-10-19 7:51 UTC (permalink / raw)
To: eric.dumazet
Cc: e1000-devel, netdev, bruce.w.allan, jesse.brandeburg,
john.ronciak, despite
In-Reply-To: <1319010435.18562.3.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 19 Oct 2011 09:47:15 +0200
> I incorrectly thought this driver was at the same location in net &
> net-next, and I my net-next tree was more convenient to compile this.
>
> I can respin patch on net tree if you prefer.
No need, I took care of adjusting the paths.
Thanks!
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [patch net-next]alx: Atheros AR8131/AR8151/AR8152/AR8161 Ethernet driver
From: David Miller @ 2011-10-19 7:50 UTC (permalink / raw)
To: cjren; +Cc: rodrigue, netdev, linux-kernel
In-Reply-To: <6349D7A510622448B1BA0967850A8438011CBA5D@nasanexd02d.na.qualcomm.com>
From: "Ren, Cloud" <cjren@qca.qualcomm.com>
Date: Wed, 19 Oct 2011 07:44:02 +0000
> Ok. What logging interfaces can I use? Are they dev_err, dev_info and dev_warn ? thanks
netif_*(), they check netif_msg_*() to see if the particular kind
of logging message is enabled or not, and this can be set dynamically
if you code your driver to properly set netdev->msg_enable.
Use other drivers as examples.
^ permalink raw reply
* Re: [PATCH 0/6 V2] mlx4_en: Data path optimizations and bug fix
From: David Miller @ 2011-10-19 7:47 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <4E9D67FC.7000902@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Tue, 18 Oct 2011 13:50:20 +0200
> This is V2 of the patches sent yesterday.
> The differences comparing to V1 are:
> 1. Remove patch 3/7 : "Incoming traffic alignment optimizations" following Eric's comments for a rework.
> 2. Using static seed value for Toeplitz function, rather then randomizing the value each time
Applied, thanks.
^ permalink raw reply
* Re: BUG in skb_pull with e1000e, PPTP, and L2TP
From: Eric Dumazet @ 2011-10-19 7:47 UTC (permalink / raw)
To: David Miller
Cc: e1000-devel, netdev, bruce.w.allan, jesse.brandeburg,
john.ronciak, despite
In-Reply-To: <20111019.033154.371626230759904957.davem@davemloft.net>
Le mercredi 19 octobre 2011 à 03:31 -0400, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 18 Oct 2011 05:59:53 +0200
>
> > [PATCH v2] pptp: pptp_rcv_core() misses pskb_may_pull() call
> >
> > e1000e uses paged frags, so any layer incorrectly pulling bytes from skb
> > can trigger a BUG in skb_pull()
> >
> > [951.142737] [<ffffffff813d2f36>] skb_pull+0x15/0x17
> > [951.142737] [<ffffffffa0286824>] pptp_rcv_core+0x126/0x19a [pptp]
> > [951.152725] [<ffffffff813d17c4>] sk_receive_skb+0x69/0x105
> > [951.163558] [<ffffffffa0286993>] pptp_rcv+0xc8/0xdc [pptp]
> > [951.165092] [<ffffffffa02800a3>] gre_rcv+0x62/0x75 [gre]
> > [951.165092] [<ffffffff81410784>] ip_local_deliver_finish+0x150/0x1c1
> > [951.177599] [<ffffffff81410634>] ? ip_local_deliver_finish+0x0/0x1c1
> > [951.177599] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
> > [951.177599] [<ffffffff81410996>] ip_local_deliver+0x51/0x55
> > [951.177599] [<ffffffff814105b9>] ip_rcv_finish+0x31a/0x33e
> > [951.177599] [<ffffffff8141029f>] ? ip_rcv_finish+0x0/0x33e
> > [951.204898] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
> > [951.214651] [<ffffffff81410bb5>] ip_rcv+0x21b/0x246
> >
> > pptp_rcv_core() is a nice example of a function assuming everything it
> > needs is available in skb head.
> >
> > Reported-by: Bradley Peterson <despite@gmail.com>
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> I assume by the driver paths in the patch that you think this
> is 'net-next' material and not suitable for plain 'net', right?
I incorrectly thought this driver was at the same location in net &
net-next, and I my net-next tree was more convenient to compile this.
I can respin patch on net tree if you prefer.
Thanks
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ 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