Re: e1000_clean_tx_irq: Detected Tx Unit Hang - it's bug?
Hello all. Some time in dmesg i see this: [16121.400422] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang [16121.400426] Tx Queue <0> [16121.400427] TDH <28> [16121.400429] TDT <28> [16121.400430] next_to_use <28> [16121.400431] next_to_clean <7d> [16121.400433] buffer_info[next_to_clean] [16121.400434] time_stamp <17b949> [16121.400435] next_to_watch <7d> [16121.400437] jiffies <17ba57> [16121.400438] next_to_watch.status <1> might be a bug. What kernel version are you using? Hello. Now i try 2.6.24-rc7-git2 - its have NAPI patches that work GREAT! Have many messages like up in dmeseg. Also more info for You fw ~ # ethtool -S eth0 NIC statistics: rx_packets: 1048831452 tx_packets: 28418 rx_bytes: 644208597062 tx_bytes: 3458632 rx_broadcast: 1840 tx_broadcast: 5 rx_multicast: 0 tx_multicast: 0 rx_errors: 1663 tx_errors: 0 tx_dropped: 0 multicast: 0 collisions: 0 rx_length_errors: 0 rx_over_errors: 0 rx_crc_errors: 5172 rx_frame_errors: 0 rx_no_buffer_count: 153305 rx_missed_errors: 883176 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 tx_restart_queue: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 10 tx_tcp_seg_failed: 0 rx_flow_control_xon: 0 rx_flow_control_xoff: 0 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_long_byte_count: 644208597062 rx_csum_offload_good: 1030747822 rx_csum_offload_errors: 7086 rx_header_split: 0 alloc_rx_buff_failed: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 That my dmesg: [ 5280.282257] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang [ 5280.282264] Tx Queue <0> [ 5280.282265] TDH <67> [ 5280.282265] TDT [ 5280.282266] next_to_use [ 5280.282267] next_to_clean [ 5280.282268] buffer_info[next_to_clean] [ 5280.282269] time_stamp <76c86> [ 5280.282270] next_to_watch [ 5280.282271] jiffies <76d33> [ 5280.282272] next_to_watch.status <1> [ 272.396662] opreport[5752]: segfault at b7be1010 eip 080b396e esp bfba9480 error 4 [ 2264.085353] htb: too many events ! [ 3376.658037] htb: too many events ! [ 5724.766531] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang [ 5724.766533] Tx Queue <0> [ 5724.766534] TDH <23> [ 5724.766535] TDT <23> [ 5724.766536] next_to_use <23> [ 5724.766537] next_to_clean [ 5724.766537] buffer_info[next_to_clean] [ 5724.766538] time_stamp <50db81> [ 5724.766539] next_to_watch [ 5724.766540] jiffies <50e3ab> [ 5724.766541] next_to_watch.status <1> [ 5724.767771] htb: too many events ! [10527.197125] htb: too many events ! [11744.405451] htb: too many events ! [12925.662880] htb: too many events ! [14123.186443] htb: too many events ! [15333.652189] htb: too many events ! [16522.524045] htb: too many events ! [17722.572386] htb: too many events ! [18925.121034] htb: too many events ! [20117.689133] htb: too many events ! [20117.690436] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang [20117.690438] Tx Queue <0> [20117.690439] TDH <8> [20117.690440] TDT <4b> [20117.690441] next_to_use <4b> [20117.690442] next_to_clean [20117.690443] buffer_info[next_to_clean] [20117.690443] time_stamp <128b414> [20117.690444] next_to_watch [20117.690445] jiffies <128bc3f> [20117.690446] next_to_watch.status <1> [21314.498859] htb: too many events ! [22192.855455] htb: too many events ! [22520.640345] htb: too many events ! [23712.083687] htb: too many events ! [24912.407418] htb: too many events ! [26128.954774] htb: too many events ! [27314.726708] htb: too many events ! [28517.307859] htb: too many events ! [28517.309179] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang [28517.309181] Tx Queue <0> [28517.309182] TDH <1a> [28517.309183] TDT <4f> [28517.309184] next_to_use <4f> [28517.309185] next_to_clean [28517.309186] buffer_info[next_to_clean] [28517.309187] time_stamp <1a5c7c3> [28517.309187] next_to_watch [28517.309188] jiffies <1a5cf20> [28517.309189] next_to_watch.status <1> [30922.659736] htb: too many events ! [30922.661064] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang [30922.661066] Tx Queue <0> [30922.661067] TDH <51> [30922.661068] TDT <76> [30922.661069] next_to_use <76> [30922.661070] next_to_clean [30922.661071] buffer_info[next_to_clean] [30922.661071] time_stamp <1c9ad65> [30922.661072] next_to_watch [30922.661073] jiffies <1c9b459> [30922.661074] next_to_watch.status <1> [32124.687849] htb: too many events ! [33345.636940] htb: too many events ! [34528.356531] htb: too many events ! [34528.358024] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang [34528.358027] Tx Queue <0> [34528.358028] TDH [34528.358029] TDT <3> [34528.358029] next_to_use <3> [34528.358030] next_to_clean <58> [34528.358031] buffer_info[next_to_clean] [34528.358032] time_stamp <1ff85ab> [34528.358033] next_to_watch <58> [34528.358034] jiffies <1ff8d27> [34528.358035] next_to_watch.status <1> [35734.669698] e1000: eth0: e1000
What is XFRM_POLICY_LOCALOK for?
Hello, I tried to understand what XFRM_POLICY_LOCALOK is for. (include/linux/xfrm.h) It is defined thus: #define XFRM_POLICY_LOCALOK1 /* Allow user to override global policy */ is it part of flags of xfrm_userpolicy_info?? I doubt this, since we have above flags two defines: #define XFRM_POLICY_ALLOW 0 #define XFRM_POLICY_BLOCK 1 Moreover, both XFRM_POLICY_BLOCK and XFRM_POLICY_LOCALOK has a vlaue of 1. I could not see any usage for XFRM_POLICY_LOCALOK in kernel code. Regards, Ian B -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000_clean_tx_irq: Detected Tx Unit Hang - it's bug?
Wow! Now at another PC have this messages in dmesg: [83646.646305] NETDEV WATCHDOG: eth0: transmit timed out [83646.646391] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang [83646.646392] Tx Queue <0> [83646.646393] TDH [83646.646394] TDT [83646.646395] next_to_use [83646.646396] next_to_clean <41> [83646.646397] buffer_info[next_to_clean] [83646.646398] time_stamp <4e0919c> [83646.646399] next_to_watch <41> [83646.646400] jiffies <4e0ab8e> [83646.646400] next_to_watch.status <1> [83651.683460] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [84849.372924] htb: too many events ! [86047.797913] htb: too many events ! PC not response some time to all packets! After [83651.683460] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Its work again! Strange fw2 ~ # uname -a Linux fw2 2.6.24-rc7-git2-fw #6 Fri Jan 11 11:07:42 MSK 2008 i686 Intel(R) Pentium(R) 4 CPU 3.40GHz GenuineIntel GNU/Linux fw2 ~ # lspci 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 01:09.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02) 01:0a.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02) 01:0b.0 SCSI storage controller: Adaptec ASC-39320 U320 (rev 03) 01:0b.1 SCSI storage controller: Adaptec ASC-39320 U320 (rev 03) Hello all. Some time in dmesg i see this: [16121.400422] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang [16121.400426] Tx Queue <0> [16121.400427] TDH <28> [16121.400429] TDT <28> [16121.400430] next_to_use <28> [16121.400431] next_to_clean <7d> [16121.400433] buffer_info[next_to_clean] [16121.400434] time_stamp <17b949> [16121.400435] next_to_watch <7d> [16121.400437] jiffies <17ba57> [16121.400438] next_to_watch.status <1> might be a bug. What kernel version are you using? Hello. Now i try 2.6.24-rc7-git2 - its have NAPI patches that work GREAT! Have many messages like up in dmeseg. Also more info for You fw ~ # ethtool -S eth0 NIC statistics: rx_packets: 1048831452 tx_packets: 28418 rx_bytes: 644208597062 tx_bytes: 3458632 rx_broadcast: 1840 tx_broadcast: 5 rx_multicast: 0 tx_multicast: 0 rx_errors: 1663 tx_errors: 0 tx_dropped: 0 multicast: 0 collisions: 0 rx_length_errors: 0 rx_over_errors: 0 rx_crc_errors: 5172 rx_frame_errors: 0 rx_no_buffer_count: 153305 rx_missed_errors: 883176 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 tx_restart_queue: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 10 tx_tcp_seg_failed: 0 rx_flow_control_xon: 0 rx_flow_control_xoff: 0 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_long_byte_count: 644208597062 rx_csum_offload_good: 1030747822 rx_csum_offload_errors: 7086 rx_header_split: 0 alloc_rx_buff_failed: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 That my dmesg: [ 5280.282257] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang [ 5280.282264] Tx Queue <0> [ 5280.282265] TDH <67> [ 5280.282265] TDT [ 5280.282266] next_to_use [ 5280.282267] next_to_clean [ 5280.282268] buffer_info[next_to_clean] [ 5280.282269] time_stamp <76c86> [ 5280.282270] next_to_watch [ 5280.282271] jiffies <76d33> [ 5280.282272] next_to_watch.status <1> [ 272.396662] opreport[5752]: segfault at b7be1010 eip 080b396e esp bfba9480 error 4 [ 2264.085353] htb: too many events ! [ 3376.658037] htb: too many events ! [ 5724.766531] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang [ 5724.766533] Tx Queue <0> [ 5724.766534] TDH <23> [ 5724.766535] TDT <23> [ 5724.766536] next_to_use <23> [ 5724.766537] next_to_clean [ 5724.766537] buffer_info[next_to_clean] [ 5724.766538] time_stamp <50db81> [ 5724.766539] next_to_watch [ 5724.766540] jiffies <50e3ab> [ 5724.766541] next_to_watch.status <1> [ 5724.767771] htb: too many events ! [10527.197125] htb: too many e
Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
On Sat, Jan 12, 2008 at 06:57:24PM +1100, Benjamin Herrenschmidt wrote: > > On Sat, 2008-01-12 at 08:26 +0100, Stefan Roese wrote: > > > > We shouldn't make it too complicated. We can always select different > > settings > > in the defconfig file. My thinking here is to better wast a little > > memory > > with a potential performance improvement. Just me 0.02$ > > If it gets really critical, then we can move those settings to the > device-tree. Come on guys, it's not that critical. I guess I just don't trust a certain company :) -- Eugene -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25 0/8] [NET]: More uninlining & related
Hi Dave, First of all, I changed output encoding of git to utf-8, so I guess the encoding should not cause the same trouble for you. Here are couple of more to uninline things. Pretty straightforward except the EXPORT_SYMBOLs, I've no idea which is the right variant (feel free to fix them while applying :-)). Also pktgen uninlining is somewhat questionable because it's just a testing tool so feel free to drop it if it feels unnecessary (I could have asked first but it's just as easy to do it this way if not easier)... There were more dead static inlines found after inlines removed (gcc didn't report them otherwise) than in pktgen now included, but I'm not sure if I should send "by default" patches removing or #if 0'ing them? -- i. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25 0/8] [NET]: More uninlining & related
Hi Dave, First of all, I changed output encoding to utf-8, so I guess the encoding should not cause trouble for you. Here are couple of more to uninline things. Pretty straightforward except the EXPORT_SYMBOLs, I've no idea which is the right variant (feel free to fix them while applying :-)). Also pktgen uninlining is somewhat questionable because it's just a testing tool so feel free to drop it if it feels unnecessary (I could have asked first but it's just as easy to do it this way if not easier)... There were more dead static inlines found after inlines removed (gcc didn't report them otherwise) than in pktgen now included, but I'm not sure if I should send "by default" patches removing or #if 0'ing them? -- i. ps. I apologize that I must resend to get them to netdev as well because git-send-email of this system (not sure if later could) still seems to be lacking proper encoding of my name when it decides to add it to Cc list all by itself and those 8-bit chars in address got rejected. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] [TCP]: Uninline tcp_is_cwnd_limited
net/ipv4/tcp_cong.c:
tcp_reno_cong_avoid | -65
1 function changed, 65 bytes removed, diff: -65
net/ipv4/arp.c:
arp_ignore | -5
1 function changed, 5 bytes removed, diff: -5
net/ipv4/tcp_bic.c:
bictcp_cong_avoid | -57
1 function changed, 57 bytes removed, diff: -57
net/ipv4/tcp_cubic.c:
bictcp_cong_avoid | -61
1 function changed, 61 bytes removed, diff: -61
net/ipv4/tcp_highspeed.c:
hstcp_cong_avoid | -63
1 function changed, 63 bytes removed, diff: -63
net/ipv4/tcp_hybla.c:
hybla_cong_avoid | -85
1 function changed, 85 bytes removed, diff: -85
net/ipv4/tcp_htcp.c:
htcp_cong_avoid | -57
1 function changed, 57 bytes removed, diff: -57
net/ipv4/tcp_veno.c:
tcp_veno_cong_avoid | -52
1 function changed, 52 bytes removed, diff: -52
net/ipv4/tcp_scalable.c:
tcp_scalable_cong_avoid | -61
1 function changed, 61 bytes removed, diff: -61
net/ipv4/tcp_yeah.c:
tcp_yeah_cong_avoid | -75
1 function changed, 75 bytes removed, diff: -75
net/ipv4/tcp_illinois.c:
tcp_illinois_cong_avoid | -54
1 function changed, 54 bytes removed, diff: -54
net/dccp/ccids/ccid3.c:
ccid3_update_send_interval | -7
ccid3_hc_tx_packet_recv| +7
2 functions changed, 7 bytes added, 7 bytes removed, diff: +0
net/ipv4/tcp_cong.c:
tcp_is_cwnd_limited | +88
1 function changed, 88 bytes added, diff: +88
built-in.o:
14 functions changed, 95 bytes added, 642 bytes removed, diff: -547
...Again some gcc artifacts visible as well.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/net/tcp.h | 22 +-
net/ipv4/tcp_cong.c | 21 +
2 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 306580c..7de4ea3 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -786,27 +786,7 @@ static inline u32 tcp_wnd_end(const struct tcp_sock *tp)
{
return tp->snd_una + tp->snd_wnd;
}
-
-/* RFC2861 Check whether we are limited by application or congestion window
- * This is the inverse of cwnd check in tcp_tso_should_defer
- */
-static inline int tcp_is_cwnd_limited(const struct sock *sk, u32 in_flight)
-{
- const struct tcp_sock *tp = tcp_sk(sk);
- u32 left;
-
- if (in_flight >= tp->snd_cwnd)
- return 1;
-
- if (!sk_can_gso(sk))
- return 0;
-
- left = tp->snd_cwnd - in_flight;
- if (sysctl_tcp_tso_win_divisor)
- return left * sysctl_tcp_tso_win_divisor < tp->snd_cwnd;
- else
- return left <= tcp_max_burst(tp);
-}
+extern int tcp_is_cwnd_limited(const struct sock *sk, u32 in_flight);
static inline void tcp_minshall_update(struct tcp_sock *tp, unsigned int mss,
const struct sk_buff *skb)
diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
index 4451750..3a6be23 100644
--- a/net/ipv4/tcp_cong.c
+++ b/net/ipv4/tcp_cong.c
@@ -274,6 +274,27 @@ int tcp_set_congestion_control(struct sock *sk, const char
*name)
return err;
}
+/* RFC2861 Check whether we are limited by application or congestion window
+ * This is the inverse of cwnd check in tcp_tso_should_defer
+ */
+int tcp_is_cwnd_limited(const struct sock *sk, u32 in_flight)
+{
+ const struct tcp_sock *tp = tcp_sk(sk);
+ u32 left;
+
+ if (in_flight >= tp->snd_cwnd)
+ return 1;
+
+ if (!sk_can_gso(sk))
+ return 0;
+
+ left = tp->snd_cwnd - in_flight;
+ if (sysctl_tcp_tso_win_divisor)
+ return left * sysctl_tcp_tso_win_divisor < tp->snd_cwnd;
+ else
+ return left <= tcp_max_burst(tp);
+}
+EXPORT_SYMBOL_GPL(tcp_is_cwnd_limited);
/*
* Slow start is used when congestion window is less than slow start
--
1.5.0.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
net/core/pktgen.c:
pktgen_stop_device | -50
pktgen_run | -105
pktgen_if_show | -37
pktgen_thread_worker | -702
4 functions changed, 894 bytes removed, diff: -894
net/core/pktgen.c:
getCurUs | +36
1 function changed, 36 bytes added, diff: +36
net/core/pktgen.o:
5 functions changed, 36 bytes added, 894 bytes removed, diff: -858
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/core/pktgen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index ebfb126..d18fdb1 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -405,7 +405,7 @@ static inline __u64 tv_to_us(const struct timeval *tv)
return us;
}
-static inline __u64 getCurUs(void)
+static __u64 getCurUs(void)
{
struct timeval tv;
do_gettimeofday(&tv);
--
1.5.0.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] [TCP]: Uninline tcp_set_state
net/ipv4/tcp.c:
tcp_close_state | -226
tcp_done| -145
tcp_close | -564
tcp_disconnect | -141
4 functions changed, 1076 bytes removed, diff: -1076
net/ipv4/tcp_input.c:
tcp_fin | -86
tcp_rcv_state_process | -164
2 functions changed, 250 bytes removed, diff: -250
net/ipv4/tcp_ipv4.c:
tcp_v4_connect | -209
1 function changed, 209 bytes removed, diff: -209
net/ipv4/arp.c:
arp_ignore | +5
1 function changed, 5 bytes added, diff: +5
net/ipv6/tcp_ipv6.c:
tcp_v6_connect | -158
1 function changed, 158 bytes removed, diff: -158
net/sunrpc/xprtsock.c:
xs_sendpages | -2
1 function changed, 2 bytes removed, diff: -2
net/dccp/ccids/ccid3.c:
ccid3_update_send_interval | +7
1 function changed, 7 bytes added, diff: +7
net/ipv4/tcp.c:
tcp_set_state | +238
1 function changed, 238 bytes added, diff: +238
built-in.o:
12 functions changed, 250 bytes added, 1695 bytes removed, diff: -1445
I've no explanation why some unrelated changes seem to occur
consistently as well (arp_ignore, ccid3_update_send_interval;
I checked the arp_ignore asm and it seems to be due to some
reordered of operation order causing some extra opcodes to be
generated). Still, the benefits are pretty obvious from the
codiff's results.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
---
include/net/tcp.h | 35 +--
net/ipv4/tcp.c| 35 +++
2 files changed, 36 insertions(+), 34 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 48081ad..306580c 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -926,40 +926,7 @@ static const char *statename[]={
"Close Wait","Last ACK","Listen","Closing"
};
#endif
-
-static inline void tcp_set_state(struct sock *sk, int state)
-{
- int oldstate = sk->sk_state;
-
- switch (state) {
- case TCP_ESTABLISHED:
- if (oldstate != TCP_ESTABLISHED)
- TCP_INC_STATS(TCP_MIB_CURRESTAB);
- break;
-
- case TCP_CLOSE:
- if (oldstate == TCP_CLOSE_WAIT || oldstate == TCP_ESTABLISHED)
- TCP_INC_STATS(TCP_MIB_ESTABRESETS);
-
- sk->sk_prot->unhash(sk);
- if (inet_csk(sk)->icsk_bind_hash &&
- !(sk->sk_userlocks & SOCK_BINDPORT_LOCK))
- inet_put_port(&tcp_hashinfo, sk);
- /* fall through */
- default:
- if (oldstate==TCP_ESTABLISHED)
- TCP_DEC_STATS(TCP_MIB_CURRESTAB);
- }
-
- /* Change state AFTER socket is unhashed to avoid closed
-* socket sitting in hash tables.
-*/
- sk->sk_state = state;
-
-#ifdef STATE_TRACE
- SOCK_DEBUG(sk, "TCP sk=%p, State %s -> %s\n",sk,
statename[oldstate],statename[state]);
-#endif
-}
+extern void tcp_set_state(struct sock *sk, int state);
extern void tcp_done(struct sock *sk);
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 34085e3..7d7b958 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1652,6 +1652,41 @@ recv_urg:
goto out;
}
+void tcp_set_state(struct sock *sk, int state)
+{
+ int oldstate = sk->sk_state;
+
+ switch (state) {
+ case TCP_ESTABLISHED:
+ if (oldstate != TCP_ESTABLISHED)
+ TCP_INC_STATS(TCP_MIB_CURRESTAB);
+ break;
+
+ case TCP_CLOSE:
+ if (oldstate == TCP_CLOSE_WAIT || oldstate == TCP_ESTABLISHED)
+ TCP_INC_STATS(TCP_MIB_ESTABRESETS);
+
+ sk->sk_prot->unhash(sk);
+ if (inet_csk(sk)->icsk_bind_hash &&
+ !(sk->sk_userlocks & SOCK_BINDPORT_LOCK))
+ inet_put_port(&tcp_hashinfo, sk);
+ /* fall through */
+ default:
+ if (oldstate==TCP_ESTABLISHED)
+ TCP_DEC_STATS(TCP_MIB_CURRESTAB);
+ }
+
+ /* Change state AFTER socket is unhashed to avoid closed
+* socket sitting in hash tables.
+*/
+ sk->sk_state = state;
+
+#ifdef STATE_TRACE
+ SOCK_DEBUG(sk, "TCP sk=%p, State %s -> %s\n",sk,
statename[oldstate],statename[state]);
+#endif
+}
+EXPORT_SYMBOL_GPL(tcp_set_state);
+
/*
* State processing on a close. This implements the state shift for
* sending our FIN frame. Note that we only send a FIN for some
--
1.5.0.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] [IPV6] route: kill some bloat
net/ipv6/route.c:
ip6_pkt_prohibit_out | -130
ip6_pkt_discard | -261
ip6_pkt_discard_out | -130
ip6_pkt_prohibit | -261
4 functions changed, 782 bytes removed, diff: -782
net/ipv6/route.c:
ip6_pkt_drop | +300
1 function changed, 300 bytes added, diff: +300
net/ipv6/route.o:
5 functions changed, 300 bytes added, 782 bytes removed, diff: -482
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv6/route.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 02354a7..d3b5811 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1762,8 +1762,7 @@ int ipv6_route_ioctl(unsigned int cmd, void __user *arg)
* Drop the packet on the floor
*/
-static inline int ip6_pkt_drop(struct sk_buff *skb, int code,
- int ipstats_mib_noroutes)
+static int ip6_pkt_drop(struct sk_buff *skb, int code, int
ipstats_mib_noroutes)
{
int type;
switch (ipstats_mib_noroutes) {
--
1.5.0.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] [NETLINK] af_netlink: kill some bloat
net/netlink/af_netlink.c:
netlink_realloc_groups| -46
netlink_insert| -49
netlink_autobind | -94
netlink_clear_multicast_users | -48
netlink_bind | -55
netlink_setsockopt| -54
netlink_release | -86
netlink_kernel_create | -47
netlink_change_ngroups| -56
9 functions changed, 535 bytes removed, diff: -535
net/netlink/af_netlink.c:
netlink_table_ungrab | +53
1 function changed, 53 bytes added, diff: +53
net/netlink/af_netlink.o:
10 functions changed, 53 bytes added, 535 bytes removed, diff: -482
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/netlink/af_netlink.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index be07f1b..21f9e30 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -193,7 +193,7 @@ static void netlink_table_grab(void)
}
}
-static inline void netlink_table_ungrab(void)
+static void netlink_table_ungrab(void)
__releases(nl_table_lock)
{
write_unlock_irq(&nl_table_lock);
--
1.5.0.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] [PKTGEN]: Kill dead static inlines
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/core/pktgen.c | 94 -
1 files changed, 0 insertions(+), 94 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index ede1fea..ebfb126 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -397,62 +397,6 @@ struct pktgen_thread {
#define REMOVE 1
#define FIND 0
-/* This code works around the fact that do_div cannot handle two 64-bit
-numbers, and regular 64-bit division doesn't work on x86 kernels.
---Ben
-*/
-
-#define PG_DIV 0
-
-/* This was emailed to LMKL by: Chris Caputo <[EMAIL PROTECTED]>
- * Function copied/adapted/optimized from:
- *
- * nemesis.sourceforge.net/browse/lib/static/intmath/ix86/intmath.c.html
- *
- * Copyright 1994, University of Cambridge Computer Laboratory
- * All Rights Reserved.
- *
- */
-static inline s64 divremdi3(s64 x, s64 y, int type)
-{
- u64 a = (x < 0) ? -x : x;
- u64 b = (y < 0) ? -y : y;
- u64 res = 0, d = 1;
-
- if (b > 0) {
- while (b < a) {
- b <<= 1;
- d <<= 1;
- }
- }
-
- do {
- if (a >= b) {
- a -= b;
- res += d;
- }
- b >>= 1;
- d >>= 1;
- }
- while (d);
-
- if (PG_DIV == type) {
- return (((x ^ y) & (1ll << 63)) == 0) ? res : -(s64) res;
- } else {
- return ((x & (1ll << 63)) == 0) ? a : -(s64) a;
- }
-}
-
-/* End of hacks to deal with 64-bit math on x86 */
-
-/** Convert to milliseconds */
-static inline __u64 tv_to_ms(const struct timeval *tv)
-{
- __u64 ms = tv->tv_usec / 1000;
- ms += (__u64) tv->tv_sec * (__u64) 1000;
- return ms;
-}
-
/** Convert to micro-seconds */
static inline __u64 tv_to_us(const struct timeval *tv)
{
@@ -461,39 +405,6 @@ static inline __u64 tv_to_us(const struct timeval *tv)
return us;
}
-static inline __u64 pg_div(__u64 n, __u32 base)
-{
- __u64 tmp = n;
- do_div(tmp, base);
- /* printk("pktgen: pg_div, n: %llu base: %d rv: %llu\n",
- n, base, tmp); */
- return tmp;
-}
-
-static inline __u64 pg_div64(__u64 n, __u64 base)
-{
- __u64 tmp = n;
-/*
- * How do we know if the architecture we are running on
- * supports division with 64 bit base?
- *
- */
-#if defined(__sparc_v9__) || defined(__powerpc64__) || defined(__alpha__) ||
defined(__x86_64__) || defined(__ia64__)
-
- do_div(tmp, base);
-#else
- tmp = divremdi3(n, base, PG_DIV);
-#endif
- return tmp;
-}
-
-static inline __u64 getCurMs(void)
-{
- struct timeval tv;
- do_gettimeofday(&tv);
- return tv_to_ms(&tv);
-}
-
static inline __u64 getCurUs(void)
{
struct timeval tv;
@@ -501,11 +412,6 @@ static inline __u64 getCurUs(void)
return tv_to_us(&tv);
}
-static inline __u64 tv_diff(const struct timeval *a, const struct timeval *b)
-{
- return tv_to_us(a) - tv_to_us(b);
-}
-
/* old include end */
static char version[] __initdata = VERSION;
--
1.5.0.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] [NETFILTER] xt_policy.c: kill some bloat
net/netfilter/xt_policy.c:
policy_mt | -906
1 function changed, 906 bytes removed, diff: -906
net/netfilter/xt_policy.c:
match_xfrm_state | +427
1 function changed, 427 bytes added, diff: +427
net/netfilter/xt_policy.o:
2 functions changed, 427 bytes added, 906 bytes removed, diff: -479
Alternatively, this could be done by combining identical
parts of the match_policy_in/out()
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/netfilter/xt_policy.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/xt_policy.c b/net/netfilter/xt_policy.c
index 46ee7e8..45731ca 100644
--- a/net/netfilter/xt_policy.c
+++ b/net/netfilter/xt_policy.c
@@ -33,7 +33,7 @@ xt_addr_cmp(const union xt_policy_addr *a1, const union
xt_policy_addr *m,
return false;
}
-static inline bool
+static bool
match_xfrm_state(const struct xfrm_state *x, const struct xt_policy_elem *e,
unsigned short family)
{
--
1.5.0.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] [XFRM] xfrm_policy: kill some bloat
net/xfrm/xfrm_policy.c:
xfrm_audit_policy_delete | -692
xfrm_audit_policy_add| -692
2 functions changed, 1384 bytes removed, diff: -1384
net/xfrm/xfrm_policy.c:
xfrm_audit_common_policyinfo | +704
1 function changed, 704 bytes added, diff: +704
net/xfrm/xfrm_policy.o:
3 functions changed, 704 bytes added, 1384 bytes removed, diff: -680
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/xfrm/xfrm_policy.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 534b29e..47219f9 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2367,8 +2367,8 @@ void __init xfrm_init(void)
}
#ifdef CONFIG_AUDITSYSCALL
-static inline void xfrm_audit_common_policyinfo(struct xfrm_policy *xp,
- struct audit_buffer *audit_buf)
+static void xfrm_audit_common_policyinfo(struct xfrm_policy *xp,
+struct audit_buffer *audit_buf)
{
struct xfrm_sec_ctx *ctx = xp->security;
struct xfrm_selector *sel = &xp->selector;
--
1.5.0.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
On Wed, 9 Jan 2008, Andy Gospodarek wrote: On Wed, Jan 09, 2008 at 09:54:56AM -0800, Jay Vosburgh wrote: This should silence the lockdep (if I'm understanding what everybody's saying), and keep the change set to a minimum. This might The lockdep problem is easy to trigger. The lockdep code does a good job of noticing problems quickly regardless of how easy the deadlocks are to create. Exactly. All I need to do is to reboot my server, I have 100% probability to get the warning. not even be worth pushing for 2.6.24; I'm not exactly sure how difficult the lockdep problem would be to trigger. I'd like to see it go in there (for correct-ness) and to avoid hearing about these lockdep issues for the next few months until it makes it into 2.4.25. Right. So, what is the final patch? I would like to test it if that's possible. ;) Best regards, Krzysztof Olędzki
Re: [PATCH net-2.6.25 0/8] [NET]: More uninlining & related
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 11:34:21 +0200 > First of all, I changed output encoding of git to utf-8, so I > guess the encoding should not cause the same trouble for you. I worked on a rebase of net-2.6.25 today and was able to use emacs to fixup the encoding for all existing net-2.6.25 commits. I've also put some things in place to avoid this problem in the future. Thanks. > Here are couple of more to uninline things. Pretty > straightforward except the EXPORT_SYMBOLs, I've no idea which > is the right variant (feel free to fix them while applying :-)). > Also pktgen uninlining is somewhat questionable because it's > just a testing tool so feel free to drop it if it feels > unnecessary (I could have asked first but it's just as easy to > do it this way if not easier)... > > There were more dead static inlines found after inlines removed > (gcc didn't report them otherwise) than in pktgen now included, > but I'm not sure if I should send "by default" patches removing > or #if 0'ing them? Unless there is some pressing reason to keep the code around it should be removed. Anyways, I'll take a look. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] fix sparse warnings
Stephen Hemminger a écrit :
Make FIB TRIE go through sparse checker without warnings.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Hi Stephen
While reviewing your patches (and fib code) I had some questions :
1) I was wondering isn't trie_collect_stats() a potential cpu hog
(big latency) ?
2) struct tnode layout
If tnode->bits is large enough, we allocate a big area
of memory but roughly use only first half of it.
We could use a better scheme with an extra indirection. For small
nodes, we use space right after tnode, but for big nodes, we allocate
a power of two set of pages, to exactly match the memory need.
3) 'pos' and 'bits' fields of 'struct tnode' might be converted to
plain uchar, instead of 5-bits fields, to reduce complexity for
generated code.
4) full_children & empty_children being 'unsigned short',
we probably are limited to 2^15 elements, but I could not
find this limit enforced somewhere.
[FIB]: Reduce text size of net/ipv4/fib_trie.o
In struct tnode, we use two fields of 5 bits for 'pos' and 'bits'.
Switching to plain 'unsigned char' (8 bits) take the same space
because of compiler alignments, and reduce text size by 435 bytes
on i386.
On i386 :
$ size net/ipv4/fib_trie.o.before_patch net/ipv4/fib_trie.o
textdata bss dec hex filename
13714 4 64 1378235d6 net/ipv4/fib_trie.o.before
13279 4 64 133473423 net/ipv4/fib_trie.o
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 2832610..4e91532 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -119,8 +119,8 @@ struct leaf_info {
struct tnode {
t_key key;
unsigned long parent;
- unsigned short pos:5; /* 2log(KEYLENGTH) bits needed */
- unsigned short bits:5; /* 2log(KEYLENGTH) bits needed */
+ unsigned char pos; /* 2log(KEYLENGTH) bits needed */
+ unsigned char bits; /* 2log(KEYLENGTH) bits needed */
unsigned short full_children; /* KEYLENGTH bits needed */
unsigned short empty_children; /* KEYLENGTH bits needed */
struct rcu_head rcu;
Re: What is XFRM_POLICY_LOCALOK for?
Ian Brown <[EMAIL PROTECTED]> wrote:
>
> I tried to understand what XFRM_POLICY_LOCALOK is for. (include/linux/xfrm.h)
> It is defined thus:
> #define XFRM_POLICY_LOCALOK1 /* Allow user to override global
> policy */
It isn't used anywhere.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] [TCP]: Uninline tcp_set_state
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 11:34:22 +0200 > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Applied, thanks. > +#endif > +} > +EXPORT_SYMBOL_GPL(tcp_set_state); I fixed up the trailing whitespace on the "#endif" line. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] [TCP]: Uninline tcp_is_cwnd_limited
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 11:34:23 +0200 > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] [XFRM] xfrm_policy: kill some bloat
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 11:34:24 +0200 > net/xfrm/xfrm_policy.c: > xfrm_audit_policy_delete | -692 > xfrm_audit_policy_add| -692 > 2 functions changed, 1384 bytes removed, diff: -1384 > > net/xfrm/xfrm_policy.c: > xfrm_audit_common_policyinfo | +704 > 1 function changed, 704 bytes added, diff: +704 > > net/xfrm/xfrm_policy.o: > 3 functions changed, 704 bytes added, 1384 bytes removed, diff: -680 > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] [IPV6] route: kill some bloat
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 11:34:25 +0200 > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] [NETLINK] af_netlink: kill some bloat
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 11:34:26 +0200 > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] [NETFILTER] xt_policy.c: kill some bloat
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Sat, 12 Jan 2008 11:34:27 +0200
Ilpo, please post netfilter patches to netfilter-devel,
CC:'ing Patrick McHardy.
Patrick, please review, thanks.
> net/netfilter/xt_policy.c:
> policy_mt | -906
> 1 function changed, 906 bytes removed, diff: -906
>
> net/netfilter/xt_policy.c:
> match_xfrm_state | +427
> 1 function changed, 427 bytes added, diff: +427
>
> net/netfilter/xt_policy.o:
> 2 functions changed, 427 bytes added, 906 bytes removed, diff: -479
>
> Alternatively, this could be done by combining identical
> parts of the match_policy_in/out()
>
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
> ---
> net/netfilter/xt_policy.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/netfilter/xt_policy.c b/net/netfilter/xt_policy.c
> index 46ee7e8..45731ca 100644
> --- a/net/netfilter/xt_policy.c
> +++ b/net/netfilter/xt_policy.c
> @@ -33,7 +33,7 @@ xt_addr_cmp(const union xt_policy_addr *a1, const union
> xt_policy_addr *m,
> return false;
> }
>
> -static inline bool
> +static bool
> match_xfrm_state(const struct xfrm_state *x, const struct xt_policy_elem *e,
>unsigned short family)
> {
> --
> 1.5.0.6
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 001/001] ipv4: enable use of 240/4 address space
On Jan 11 2008 17:49, David Miller wrote: >From: Vince Fuller <[EMAIL PROTECTED]> >Date: Fri, 11 Jan 2008 09:29:15 -0800 > >> I leave it up to you, the developers, to decide if you want to use these >> patches. > >Vince, please just ignore these turkeys who are dismissing >your patch and respin it against current sources as I asked >of you. > >I'll apply it, immediately, because it is the only correct >course of action. I strongly agree. Linux should set standards, or at least help them become one. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] [PKTGEN]: Kill dead static inlines
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 11:34:28 +0200 > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> These were leftovers from the ktime_t conversion of pktgen. Applied, th anks! -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 11:34:29 +0200 > net/core/pktgen.c: > pktgen_stop_device | -50 > pktgen_run | -105 > pktgen_if_show | -37 > pktgen_thread_worker | -702 > 4 functions changed, 894 bytes removed, diff: -894 > > net/core/pktgen.c: > getCurUs | +36 > 1 function changed, 36 bytes added, diff: +36 > > net/core/pktgen.o: > 5 functions changed, 36 bytes added, 894 bytes removed, diff: -858 > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> I think this is the right thing to do, applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] fix sparse warnings
From: Eric Dumazet <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 12:16:13 +0100 > We could use a better scheme with an extra indirection. Unfortunately, indirection will likely have a negative impact upon performance. We go only as fast as the number of memory references made by this code. > 3) 'pos' and 'bits' fields of 'struct tnode' might be converted to > plain uchar, instead of 5-bits fields, to reduce complexity for > generated code. This seems reasonable, I'll likely apply this. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
net-2.6.25 rebased...
I fixed up some utf-8 encoding issues in changelog messages,
got rid of superfluous patches ("X" then "revert X" cases)
and combined bug fixes into the patches which introduced
them.
We are just over 700 patches, keep them coming :-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25] [XFRM] Remove unused XFRM_STATE_VOID and typos (net/xfrm.h)
Hi,
In net/xfrm.h:
- remove XFRM_STATE_VOID (not in use)
- correct 3 typos
Regards,
Rami Rosen
Signed-off-by: Rami Rosen <[EMAIL PROTECTED]>
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 860fe4a..432c5c8 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -84,10 +84,10 @@ extern struct mutex xfrm_cfg_mutex;
|---. child .-> dst -. xfrm .-> xfrm_state #3
|---. child .-> NULL
- Bundles are cached at xrfm_policy struct (field ->bundles).
+ Bundles are cached at xfrm_policy struct (field ->bundles).
- Resolution of xrfm_tmpl
+ Resolution of xfrm_tmpl
---
Template contains:
1. ->mode Mode: transport or tunnel
@@ -133,7 +133,7 @@ struct xfrm_state
u32 genid;
- /* Key manger bits */
+ /* Key manager bits */
struct {
u8 state;
u8 dying;
@@ -217,7 +217,6 @@ struct xfrm_state
#define XFRM_TIME_DEFER1
enum {
- XFRM_STATE_VOID,
XFRM_STATE_ACQ,
XFRM_STATE_VALID,
XFRM_STATE_ERROR,
[PATCH 2/2] [HTB]: htb_classid is dead static inline
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/sched/sch_htb.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index 72beb66..6a2352c 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -214,10 +214,6 @@ static inline struct htb_class *htb_find(u32 handle,
struct Qdisc *sch)
* then finish and return direct queue.
*/
#define HTB_DIRECT (struct htb_class*)-1
-static inline u32 htb_classid(struct htb_class *cl)
-{
- return (cl && cl != HTB_DIRECT) ? cl->classid : TC_H_UNSPEC;
-}
static struct htb_class *htb_classify(struct sk_buff *skb, struct Qdisc *sch,
int *qerr)
--
1.5.0.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [NET] core/utils.c: digit2bin is dead static inline
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/core/utils.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/net/core/utils.c b/net/core/utils.c
index 34459c4..8031eb5 100644
--- a/net/core/utils.c
+++ b/net/core/utils.c
@@ -91,17 +91,6 @@ EXPORT_SYMBOL(in_aton);
#define IN6PTON_NULL 0x2000 /* first/tail */
#define IN6PTON_UNKNOWN0x4000
-static inline int digit2bin(char c, int delim)
-{
- if (c == delim || c == '\0')
- return IN6PTON_DELIM;
- if (c == '.')
- return IN6PTON_DOT;
- if (c >= '0' && c <= '9')
- return (IN6PTON_DIGIT | (c - '0'));
- return IN6PTON_UNKNOWN;
-}
-
static inline int xdigit2bin(char c, int delim)
{
if (c == delim || c == '\0')
--
1.5.0.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9719] New: when a system is configured as a bridge, and at the same time configured to have multipath weighted route, with one leg goes thru NAT and another without NAT, the nat
Patrick McHardy wrote: Andrew Morton wrote: Distribution: iptables 1.4.0 was used with kernel 2.6.23 and iptables 1.3.8 with 2.6.22.15 Hardware Environment: 3 interfaces, 2 interfaces bridged to form br0, and another connects to internet using pppoe. Software Environment: bridge, multipath routing Problem Description: when a system is configured as a bridge with IP assigned to br0 interface, and at the same time it is configured to have multipath weighted default route, and one of the default route is NAT-ed and another of the default route is not NAT-ed, then it is NAT-ed interface will occasionally get packets leaking out to it with packets with private IPs. That is most likely because the route changes over time (when the cache is flushed) and the NAT mappings for the connection have been set up on a different interface. The way to properly do this is to add routing rules based on fwmark and use CONNMARK to bind a connection to one of the interfaces after the initial multipath routing decision. First of all, I would like to say a big thank you to all of you takes interest in replying my post/email. I have altered the distribution slightly and the kernel bug list is removed. It seems from your reply, what is implied is that I cannot change route within a connection, and whatever things I do, I must make sure that the route remains the same for a particular netfilter connection ? Regards. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
Rafael J. Wysocki wrote: On Friday, 11 of January 2008, supersud501 wrote: Rafael J. Wysocki wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9721 allright, didn't see that before, sorry, here are the results: kernel 2.6.23.12 acpi=off: when shutting down the system doesn't poweroff (of course), but pressing the powerbutton does the trick. and wake on lan: WORKS kernel 2.6.24-rc7 acpi=off: computer doesn't power off, either (so acpi=off works), but wol still DOESN'T work :( so no acpi-problem? No, I don't think it's an ACPI problem. Since it seems to be 100% reproducible, it would be very helpful if you could use git-bisect to identify the offending commit. I'll do the git-bisect (just downloading linux-2.6.git), but i forgot to mention one little thing: i'm using x64 version of kernel - does this play an important role? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
Hi Ilpo:
On Sat, Jan 12, 2008 at 09:40:17AM +, Ilpo Järvinen wrote:
Your emails are now using UTF-8 encoding but it's still declaring
ISO-8859-1 as the charset. So you probably want to fix that up or
your name may show up as Jävinen on the reader's screen.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
On Sat, 12 Jan 2008, Herbert Xu wrote: > On Sat, Jan 12, 2008 at 09:40:17AM +, Ilpo Järvinen wrote: > > Your emails are now using UTF-8 encoding but it's still declaring > ISO-8859-1 as the charset. Thanks for trying to help but my situation is such that I think it got also you confused (this kind of mixed encoding is beoynd my skills really)... :-) Besides, I wouldn't mind of having incorrect characters in my name, I'm just used to that but somebody else wasn't that happy about it. Here's one example... From: "=?utf-8?q?Ilpo_J=C3=A4rvinen?=" <[EMAIL PROTECTED]> ... Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Something still needed besides these to declare email utf-8? > So you probably want to fix that up or your name may show up as Jävinen > on the reader's screen. Did you actually see this? I'd expect to see that as well but no, From is correctly decoded by my ISO-8859-1'ish MUA, aha, seems that I still have something to do to deal with the Signed-off line. ...Maybe I just fall-back to changing my last name, it's the only full-proof solution... ;-) -- i.
Re: [PATCH 2.6.23+] ingress classify to [nf]mark
I in doubts only about "action continue". To "and/or" behaviour one of best usage are (example): # set bit 2 of mark to 0 (mark&0xfd|0) and continue tc filter add ... prio 1 ... flowid fd:0 action continue # continue tc filter add ... prio 2 ... - in current ingress_enqueue() code IMHO "case TC_ACT_OK:" will not reached for action continue. I use old (mark=...) solution only by this. I think, "skb->mark = (skb->mark&(res.classid>>16))|TC_H_MIN(res.classid);" must be in the end of ingress_enqueue() before "return result". And not depended to "NET_CLS_ACT". But while not test it. Or this: --- #ifdef CONFIG_NET_SCH_INGRESS_TC2MARK #ifdef CONFIG_NET_CLS_ACT skb->mark = (skb->mark&(res.classid>>16))|TC_H_MIN(res.classid); #else skb->mark = res.classid; #endif #endif return result; } jamal wrote: While I compose filter, I check flag ($TC_INDEX2MARK), tells me are patch applied or no. If no - I use usual "-j MARK --set-mark", else I use classid to change mark. All in ingress only. For example: tc filter add dev eth0 parent : protocol ip u32 ... action ipt -j MARK 0x10 are cname to: tc filter add dev eth0 parent : protocol ip u32 ... flowid :10 I thought you were doing something like this (to achieve your policy): -- major=1 minor=12 mark=`expr $major + $minor` # tc qdisc add dev XXX ingress tc filter add dev XXX parent : protocol ip prio 5 \ u32 blah bleh \ flowid $major:$minor action \ ipt -j mark --set-mark $mark --- - it use less code/modules and, in many cases, may be single/main goal to ingress usage - pre-marking packets. That is true and you would also have one less line in your policy; as an example in above the line "ipt -j mark --set-mark $mark" would be unnecessary; however, all the other lines in the policy setting _will be necessary_. And this + the fact there are many other values/shapes the default policy could take is essentially whats bothering me. In any case, scanning the current code it seems mark is no longer considered a netfilter-only metadatum - so it may not be semantically as obscene as i felt earlier; Can you pick something simpler for policy? example set the mark to whatever tc_index gets set? If you still could write the metadata action, we could use it to override mark, tc_index etc in addition. cheers, jamal -- WBR, Denis Kaganovich, [EMAIL PROTECTED] http://mahatma.bspu.unibel.by -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[XFRM]: alg_key_len should be unsigned to avoid integer divides
alg_key_len is currently defined as 'signed int'. This unfortunatly leads
to integer divides in several paths.
Converting it to unsigned is safe and saves 208 bytes of text on i386.
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index 1131eab..f8507ee 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -92,7 +92,7 @@ struct xfrm_replay_state
struct xfrm_algo {
charalg_name[64];
- int alg_key_len;/* in bits */
+ unsigned intalg_key_len;/* in bits */
charalg_key[0];
};
Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
Krzysztof Oledzki <[EMAIL PROTECTED]> wrote: [...] >Exactly. All I need to do is to reboot my server, I have 100% probability >to get the warning. I wish it were that easy for me; I'm not sure what magic thing you've got on your server or network that I don't, but I haven't been able to make this lockdep warning happen at all. >Right. So, what is the final patch? I would like to test it if that's >possible. ;) Can you test the following and let me know if it triggers the warning? I believe this is the minimum locking needed, and based on input from Herbert, we shouldn't need to hold the lock at _bh. If this one works, and nobody sees any other issues with it, then it's the final patch for this lockdep problem. I'll add some deep, meaningful comments to explain the locking a bit (i.e., we're called with rtnl for the allmulti and promisc cases, so we're ok there without additional locks, but the later code could be called from anywhere, so it needs locks to prevent the slave list from changing, but the mc_lists themselves are covered by the netif_tx_lock that all callers will hold), but this would be the actual code change. diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 77d004d..6906dbc 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -3937,8 +3937,6 @@ static void bond_set_multicast_list(struct net_device *bond_dev) struct bonding *bond = bond_dev->priv; struct dev_mc_list *dmi; - write_lock_bh(&bond->lock); - /* * Do promisc before checking multicast_mode */ @@ -3959,6 +3957,8 @@ static void bond_set_multicast_list(struct net_device *bond_dev) bond_set_allmulti(bond, -1); } + read_lock(&bond->lock); + bond->flags = bond_dev->flags; /* looking for addresses to add to slaves' mc list */ @@ -3979,7 +3979,7 @@ static void bond_set_multicast_list(struct net_device *bond_dev) bond_mc_list_destroy(bond); bond_mc_list_copy(bond_dev->mc_list, bond, GFP_ATOMIC); - write_unlock_bh(&bond->lock); + read_unlock(&bond->lock); } /* -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fib_semantics: prevent long hash chains in access server config
This is a patch from a while ago that I'm resending. Basically, in access
server configurations, a lot of routes have the same local ip address but on
different devices. This fixes the long chains that result from not including
the device index in the hash.
-ben
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 1351a26..5375824 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -196,11 +196,21 @@ static __inline__ int nh_comp(const struct fib_info *fi,
const struct fib_info *
return 0;
}
+static inline unsigned int fib_devindex_hashfn(unsigned int val)
+{
+ unsigned int mask = DEVINDEX_HASHSIZE - 1;
+
+ return (val ^
+ (val >> DEVINDEX_HASHBITS) ^
+ (val >> (DEVINDEX_HASHBITS * 2))) & mask;
+}
+
static inline unsigned int fib_info_hashfn(const struct fib_info *fi)
{
unsigned int mask = (fib_hash_size - 1);
unsigned int val = fi->fib_nhs;
+ val ^= fib_devindex_hashfn(fi->fib_dev->ifindex);
val ^= fi->fib_protocol;
val ^= (__force u32)fi->fib_prefsrc;
val ^= fi->fib_priority;
@@ -234,15 +244,6 @@ static struct fib_info *fib_find_info(const struct
fib_info *nfi)
return NULL;
}
-static inline unsigned int fib_devindex_hashfn(unsigned int val)
-{
- unsigned int mask = DEVINDEX_HASHSIZE - 1;
-
- return (val ^
- (val >> DEVINDEX_HASHBITS) ^
- (val >> (DEVINDEX_HASHBITS * 2))) & mask;
-}
-
/* Check, that the gateway is already configured.
Used only by redirect accept routine.
*/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] [NETFILTER] xt_policy.c: kill some bloat
David Miller wrote: From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 11:34:27 +0200 Ilpo, please post netfilter patches to netfilter-devel, CC:'ing Patrick McHardy. Patrick, please review, thanks. This looks fine to me, thanks Ilpo. net/netfilter/xt_policy.c: policy_mt | -906 1 function changed, 906 bytes removed, diff: -906 net/netfilter/xt_policy.c: match_xfrm_state | +427 1 function changed, 427 bytes added, diff: +427 net/netfilter/xt_policy.o: 2 functions changed, 427 bytes added, 906 bytes removed, diff: -479 Alternatively, this could be done by combining identical parts of the match_policy_in/out() That would probably end up rather ugly because they walk over different structures and have some minor differences. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
> http://bugzilla.kernel.org/show_bug.cgi?id=9721 On Saturday, 12 of January 2008, supersud501 wrote: > I'll do the git-bisect (just downloading linux-2.6.git), but i forgot to > mention one little thing: i'm using x64 version of kernel - does this > play an important role? No, it doesn't. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][ROSE][AX25] af_ax25: possible circular locking
Jarek Poplawski wrote: On Thu, Jan 10, 2008 at 09:22:42PM -0800, David Miller wrote: From: Jarek Poplawski <[EMAIL PROTECTED]> Date: Sun, 30 Dec 2007 15:13:23 +0100 On Sat, Dec 29, 2007 at 07:14:43PM -0800, David Miller wrote: ... I've removed the warning and made the branch back to 'again' unconditional as I think this is the safest version of the change. I'll push this upstream, thanks for fixing this Jarek. Thanks for checking this and making safer! Regards, Jarek P. I would also like to thank both Jarek and David for this patch. It is very helpful and probably safe for after killing kissattach we don't want to use attached ax25 devices. Regards, Bernard Pidoux -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [ROSE] finding a connected ROSE neighbor node
Hi,
I propose to drop the previously submitted patch for I performed more
investigations on ROSE frame routing and found that it was not
completely satisfactory.
Please find here another commit to net-2.6.25 with explanations.
From fd66cc115e058b2fc63a0e26aa73f1d27113105a Mon Sep 17 00:00:00 2001
From: Bernard Pidoux <[EMAIL PROTECTED]>
Date: Thu, 10 Jan 2008 23:10:44 +0100
Subject: [PATCH 1/4] [ROSE] new rose_get_route() function
rose_get_neigh() was called by two different functions.
Firstly, by rose_connect() in order to establish connections to
adjacent rose nodes. This worked correctly.
Secondly, it was called by rose_route_frame() to find a route
via an adjacent node. This was not working efficiently, for the
proper test was not performed in order to check if the node was
already connected.
A new function rose_get_route() is devoted to frame routing.
It returns a ROSE node address for sending a frame to the
specified destination via a connected node.
Signed-off-by: Bernard Pidoux <[EMAIL PROTECTED]>
---
net/rose/rose_route.c | 34 +-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 540c0f2..ec79567 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -662,6 +662,38 @@ struct rose_route *rose_route_free_lci(unsigned int
lci, struct rose_neigh *neig
}
/*
+ * Find an opened route given a ROSE address.
+ */
+struct rose_neigh *rose_get_route(rose_address *addr, unsigned char *cause,
+ unsigned char *diagnostic)
+{
+ struct rose_node *node;
+ int failed = 0;
+ int i;
+
+ for (node = rose_node_list; node != NULL; node = node->next) {
+ if (rosecmpm(addr, &node->address, node->mask) == 0) {
+ for (i = 0; i < node->count; i++) {
+ if (node->neighbour[i]->restarted)
+ return node->neighbour[i];
+ failed = 1;
+ }
+ }
+ }
+
+ if (failed) {
+ *cause = ROSE_OUT_OF_ORDER;
+ *diagnostic = 0;
+ } else {
+ *cause = ROSE_NOT_OBTAINABLE;
+ *diagnostic = 0;
+ }
+
+ return NULL;
+}
+
+
+/*
* Find a neighbour given a ROSE address.
*/
struct rose_neigh *rose_get_neigh(rose_address *addr, unsigned char
*cause,
@@ -1019,7 +1051,7 @@ int rose_route_frame(struct sk_buff *skb, ax25_cb
*ax25)
rose_route = rose_route->next;
}
- if ((new_neigh = rose_get_neigh(dest_addr, &cause, &diagnostic))
== NULL) {
+ if ((new_neigh = rose_get_route(dest_addr, &cause, &diagnostic))
== NULL) {
rose_transmit_clear_request(rose_neigh, lci, cause,
diagnostic);
goto out;
}
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] [ROSE] rose_get_route() template
From 46bccce1e660a39bcc8f8cf87d4c17de33f4ba48 Mon Sep 17 00:00:00 2001 From: Bernard Pidoux <[EMAIL PROTECTED]> Date: Thu, 10 Jan 2008 23:01:46 +0100 Subject: [PATCH 2/4] [ROSE] template declaration for rose_get_route() Signed-off-by: Bernard Pidoux <[EMAIL PROTECTED]> --- include/net/rose.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/net/rose.h b/include/net/rose.h index e5bb084..d3ab453 100644 --- a/include/net/rose.h +++ b/include/net/rose.h @@ -202,6 +202,7 @@ extern struct net_device *rose_dev_first(void); extern struct net_device *rose_dev_get(rose_address *); extern struct rose_route *rose_route_free_lci(unsigned int, struct rose_neigh *); extern struct rose_neigh *rose_get_neigh(rose_address *, unsigned char *, unsigned char *); +extern struct rose_neigh *rose_get_route(rose_address *, unsigned char *, unsigned char *); extern int rose_rt_ioctl(unsigned int, void __user *); extern void rose_link_failed(ax25_cb *, int); extern int rose_route_frame(struct sk_buff *, ax25_cb *); -- 1.5.3.7 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] [ROSE] return with lock held
From bc108e5ee0b0353c3707df25e12e40038da0160a Mon Sep 17 00:00:00 2001
From: Bernard Pidoux <[EMAIL PROTECTED]>
Date: Fri, 11 Jan 2008 10:23:55 +0100
Subject: [PATCH 3/4] [ROSE] return with lock held
Signed-off-by: Bernard Pidoux <[EMAIL PROTECTED]>
[ BUG: lock held when returning to user space! ]
fpacwpd/3057 is leaving the kernel with locks still held!
1 lock held by fpacwpd/3057:
#0: (sk_lock-AF_ROSE){--..}, at: [] rose_connect+0x6c/0x357
[rose]
---
net/rose/af_rose.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
index 8f70ad8..9419946 100644
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -752,7 +752,8 @@ static int rose_connect(struct socket *sock, struct
sockaddr *uaddr, int addr_le
rose->neighbour = rose_get_neigh(&addr->srose_addr, &cause,
&diagnostic);
if (!rose->neighbour)
- return -ENETUNREACH;
+ err = -ENETUNREACH;
+ goto out_release;
rose->lci = rose_new_lci(rose->neighbour);
if (!rose->lci) {
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] [ROSE] ENETUNREACH held rose_connect()
From 5c50971c6088f380eafdb1a6a7de5a5d3686c8c7 Mon Sep 17 00:00:00 2001 From: Bernard Pidoux <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 20:19:34 +0100 Subject: [PATCH 4/4] [ROSE] ENETUNREACH held rose_connect() Initial connection to rose neighbour nodes was unusually, t0 timer was blocked and application program could not use socket. I performed a number of trials in order to find what was slowing rose_connect() and blocking ROSE t0 timer. Replacing the type of error returned did not cure the problem. Finally removing the error returned when rose->neighbour is NULL is the solution. Without err = -ENETUNREACH rose_connect() returns default err = 0. Doing that, t0 timer is running, rose_connect() performs adjacent rose node connections as needed and rose frames are well routed. Also, application programs can access rose connect socket. Signed-off-by: Bernard Pidoux <[EMAIL PROTECTED]> --- net/rose/af_rose.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c index 9419946..5a8c886 100644 --- a/net/rose/af_rose.c +++ b/net/rose/af_rose.c @@ -752,7 +752,6 @@ static int rose_connect(struct socket *sock, struct sockaddr *uaddr, int addr_le rose->neighbour = rose_get_neigh(&addr->srose_addr, &cause, &diagnostic); if (!rose->neighbour) - err = -ENETUNREACH; goto out_release; rose->lci = rose_new_lci(rose->neighbour); -- 1.5.3.7 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] [ROSE] rose_get_route() template
Bernard Pidoux a écrit : From 46bccce1e660a39bcc8f8cf87d4c17de33f4ba48 Mon Sep 17 00:00:00 2001 From: Bernard Pidoux <[EMAIL PROTECTED]> Date: Thu, 10 Jan 2008 23:01:46 +0100 Subject: [PATCH 2/4] [ROSE] template declaration for rose_get_route() Signed-off-by: Bernard Pidoux <[EMAIL PROTECTED]> --- include/net/rose.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/net/rose.h b/include/net/rose.h index e5bb084..d3ab453 100644 --- a/include/net/rose.h +++ b/include/net/rose.h @@ -202,6 +202,7 @@ extern struct net_device *rose_dev_first(void); extern struct net_device *rose_dev_get(rose_address *); extern struct rose_route *rose_route_free_lci(unsigned int, struct rose_neigh *); extern struct rose_neigh *rose_get_neigh(rose_address *, unsigned char *, unsigned char *); +extern struct rose_neigh *rose_get_route(rose_address *, unsigned char *, unsigned char *); extern int rose_rt_ioctl(unsigned int, void __user *); extern void rose_link_failed(ax25_cb *, int); extern int rose_route_frame(struct sk_buff *, ax25_cb *); -- Strange... if rose_get_route() is used only in net/rose/rose_route.c, why dont you define it static, and not extern in include/net/rose.h ? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] [TCP]: Uninline tcp_set_state
On Sat, 12 Jan 2008 11:40:10 +0200
"Ilpo Järvinen" <[EMAIL PROTECTED]> wrote:
> net/ipv4/tcp.c:
> tcp_close_state | -226
> tcp_done| -145
> tcp_close | -564
> tcp_disconnect | -141
> 4 functions changed, 1076 bytes removed, diff: -1076
>
> net/ipv4/tcp_input.c:
> tcp_fin | -86
> tcp_rcv_state_process | -164
> 2 functions changed, 250 bytes removed, diff: -250
>
> net/ipv4/tcp_ipv4.c:
> tcp_v4_connect | -209
> 1 function changed, 209 bytes removed, diff: -209
>
> net/ipv4/arp.c:
> arp_ignore | +5
> 1 function changed, 5 bytes added, diff: +5
>
> net/ipv6/tcp_ipv6.c:
> tcp_v6_connect | -158
> 1 function changed, 158 bytes removed, diff: -158
>
> net/sunrpc/xprtsock.c:
> xs_sendpages | -2
> 1 function changed, 2 bytes removed, diff: -2
>
> net/dccp/ccids/ccid3.c:
> ccid3_update_send_interval | +7
> 1 function changed, 7 bytes added, diff: +7
>
> net/ipv4/tcp.c:
> tcp_set_state | +238
> 1 function changed, 238 bytes added, diff: +238
>
> built-in.o:
> 12 functions changed, 250 bytes added, 1695 bytes removed, diff: -1445
>
> I've no explanation why some unrelated changes seem to occur
> consistently as well (arp_ignore, ccid3_update_send_interval;
> I checked the arp_ignore asm and it seems to be due to some
> reordered of operation order causing some extra opcodes to be
> generated). Still, the benefits are pretty obvious from the
> codiff's results.
>
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EMAIL PROTECTED]>
> ---
> include/net/tcp.h | 35 +--
> net/ipv4/tcp.c| 35 +++
> 2 files changed, 36 insertions(+), 34 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 48081ad..306580c 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -926,40 +926,7 @@ static const char *statename[]={
> "Close Wait","Last ACK","Listen","Closing"
> };
> #endif
> -
> -static inline void tcp_set_state(struct sock *sk, int state)
> -{
> - int oldstate = sk->sk_state;
> -
> - switch (state) {
> - case TCP_ESTABLISHED:
> - if (oldstate != TCP_ESTABLISHED)
> - TCP_INC_STATS(TCP_MIB_CURRESTAB);
> - break;
> -
> - case TCP_CLOSE:
> - if (oldstate == TCP_CLOSE_WAIT || oldstate == TCP_ESTABLISHED)
> - TCP_INC_STATS(TCP_MIB_ESTABRESETS);
> -
> - sk->sk_prot->unhash(sk);
> - if (inet_csk(sk)->icsk_bind_hash &&
> - !(sk->sk_userlocks & SOCK_BINDPORT_LOCK))
> - inet_put_port(&tcp_hashinfo, sk);
> - /* fall through */
> - default:
> - if (oldstate==TCP_ESTABLISHED)
> - TCP_DEC_STATS(TCP_MIB_CURRESTAB);
> - }
> -
> - /* Change state AFTER socket is unhashed to avoid closed
> - * socket sitting in hash tables.
> - */
> - sk->sk_state = state;
> -
> -#ifdef STATE_TRACE
> - SOCK_DEBUG(sk, "TCP sk=%p, State %s -> %s\n",sk,
> statename[oldstate],statename[state]);
> -#endif
> -}
>
Since the function is called with a constant state, I guess the assumption
was that gcc would be smart enough to only include the code needed, it looks
like
either code was bigger or the compiler was dumber than expected
--
Stephen Hemminger <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] fix sparse warnings
On Sat, 12 Jan 2008 12:16:13 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote: > Stephen Hemminger a écrit : > > Make FIB TRIE go through sparse checker without warnings. > > > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> > > Hi Stephen > > While reviewing your patches (and fib code) I had some questions : > > 1) I was wondering isn't trie_collect_stats() a potential cpu hog > (big latency) ? > > 2) struct tnode layout > If tnode->bits is large enough, we allocate a big area > of memory but roughly use only first half of it. > We could use a better scheme with an extra indirection. For small > nodes, we use space right after tnode, but for big nodes, we allocate > a power of two set of pages, to exactly match the memory need. > > 3) 'pos' and 'bits' fields of 'struct tnode' might be converted to > plain uchar, instead of 5-bits fields, to reduce complexity for > generated code. > > 4) full_children & empty_children being 'unsigned short', > we probably are limited to 2^15 elements, but I could not > find this limit enforced somewhere. Remember that the code should be optimized for lookup, not management operations. We ran into this during testing (the test suite was looking for number of routes), thats why I put in the size field. The existing dump code is really slow: 1) FIB_TRIE Under KVM: load 164393 routes 12.436 sec ip route | wc -l 12.569 sec grep /proc/net/route 25.357 sec 99% of the cpu time is spent in nextleaf() during these dump operations. 2) FIB_HASH Under KVM: load 164393 routes 10.833 sec ip route | wc -l 1.981 sec grep /proc/net/route 0.204 sec -- Stephen Hemminger <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
On Sat, Jan 12, 2008 at 02:59:50PM +0200, Ilpo Järvinen wrote:
>
> Here's one example...
>
> From: "=?utf-8?q?Ilpo_J=C3=A4rvinen?=" <[EMAIL PROTECTED]>
> ...
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 8bit
>
> Something still needed besides these to declare email utf-8?
If that's what it said then it'd be perfect. However, quoting from this
very email that I'm replying to:
Content-Type: text/plain; charset=iso-8859-1
> > So you probably want to fix that up or your name may show up as Jävinen
> > on the reader's screen.
>
> Did you actually see this? I'd expect to see that as well but no, From is
> correctly decoded by my ISO-8859-1'ish MUA, aha, seems that I still have
> something to do to deal with the Signed-off line.
Yeah I did see that. Otherwise I wouldn't have noticed :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] [TCP]: Uninline tcp_set_state
Em Sat, Jan 12, 2008 at 01:03:55PM -0800, Stephen Hemminger escreveu: > On Sat, 12 Jan 2008 11:40:10 +0200 > "Ilpo Järvinen" <[EMAIL PROTECTED]> wrote: > > - > > -#ifdef STATE_TRACE > > - SOCK_DEBUG(sk, "TCP sk=%p, State %s -> %s\n",sk, > > statename[oldstate],statename[state]); > > -#endif > > -} > > > > > Since the function is called with a constant state, I guess the assumption > was that gcc would be smart enough to only include the code needed, it looks > like > either code was bigger or the compiler was dumber than expected Yup, that is one more instance where having proper tools to check if our assumptions are right proves fruitful. I'm very happy for Ilpo to be doing this work and making the case for us to work even harder on having such tools to check if our assumptions are right. - Arnaldo P.S. subscribe to [EMAIL PROTECTED] and help us produce even more such compiler watchdogs, right now changes to the dwarves are being made such that we can check if the layout we think is optimal really holds to that promise :-) Soon I'll be looking at Ulrich's promising new disasm stuff :-) Archives: http://news.gmane.org/gmane.comp.debugging.dwarves - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] [ROSE] rose_get_route() template
Eric Dumazet wrote: Bernard Pidoux a écrit : From 46bccce1e660a39bcc8f8cf87d4c17de33f4ba48 Mon Sep 17 00:00:00 2001 From: Bernard Pidoux <[EMAIL PROTECTED]> Date: Thu, 10 Jan 2008 23:01:46 +0100 Subject: [PATCH 2/4] [ROSE] template declaration for rose_get_route() Signed-off-by: Bernard Pidoux <[EMAIL PROTECTED]> --- include/net/rose.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/net/rose.h b/include/net/rose.h index e5bb084..d3ab453 100644 --- a/include/net/rose.h +++ b/include/net/rose.h @@ -202,6 +202,7 @@ extern struct net_device *rose_dev_first(void); extern struct net_device *rose_dev_get(rose_address *); extern struct rose_route *rose_route_free_lci(unsigned int, struct rose_neigh *); extern struct rose_neigh *rose_get_neigh(rose_address *, unsigned char *, unsigned char *); +extern struct rose_neigh *rose_get_route(rose_address *, unsigned char *, unsigned char *); extern int rose_rt_ioctl(unsigned int, void __user *); extern void rose_link_failed(ax25_cb *, int); extern int rose_route_frame(struct sk_buff *, ax25_cb *); -- Strange... if rose_get_route() is used only in net/rose/rose_route.c, why dont you define it static, and not extern in include/net/rose.h ? I agree. You are perfectly right. There is no need to declare rose_get_route() external. I stupidly copied rose_get_neigh()definition from which I derived rose_get_route(); Also I am not sure that setting cause and diagnostic is necessary, as they are not used by the calling function. By the way. I made a typo in [PATCH 4/4]. Instead of "Initial connection to rose neighbour nodes was unusually, t0 timer was blocked and application program could not use socket." One should read "Initial connection to rose neighbour nodes was unusually, long, t0 timer was blocked and application program could not use socket." Bernard P. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] fix sparse warnings
On Sat, 12 Jan 2008 12:16:13 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote: > Stephen Hemminger a écrit : > > Make FIB TRIE go through sparse checker without warnings. > > > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> > > Hi Stephen > > While reviewing your patches (and fib code) I had some questions : > > 1) I was wondering isn't trie_collect_stats() a potential cpu hog > (big latency) ? > > 2) struct tnode layout > If tnode->bits is large enough, we allocate a big area > of memory but roughly use only first half of it. > We could use a better scheme with an extra indirection. For small > nodes, we use space right after tnode, but for big nodes, we allocate > a power of two set of pages, to exactly match the memory need. > > 3) 'pos' and 'bits' fields of 'struct tnode' might be converted to > plain uchar, instead of 5-bits fields, to reduce complexity for > generated code. > > 4) full_children & empty_children being 'unsigned short', > we probably are limited to 2^15 elements, but I could not > find this limit enforced somewhere. > > [FIB]: Reduce text size of net/ipv4/fib_trie.o > > In struct tnode, we use two fields of 5 bits for 'pos' and 'bits'. > Switching to plain 'unsigned char' (8 bits) take the same space > because of compiler alignments, and reduce text size by 435 bytes > on i386. > > On i386 : > $ size net/ipv4/fib_trie.o.before_patch net/ipv4/fib_trie.o > textdata bss dec hex filename >13714 4 64 1378235d6 net/ipv4/fib_trie.o.before >13279 4 64 133473423 net/ipv4/fib_trie.o > > Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> > I agree they should not have been bitfields in the first place. -- Stephen Hemminger <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] r6040 various cleanups
Florian Fainelli wrote: The following patch applies to Jeff's netdev-2.6 tree with Francois's r6040 recent changes pulled to this tree. - remove unused private structure members - functions to allocate/free TX and RX buffers - recover from transmit timeout - use netdev_alloc_skb instead of dev_alloc_skb - do not use a private stats structure to store statistics - break each TX/RX error to a separate line for better reading - better control of the timer - clean the IRQ handler - fix typos and spelling mistakes in the driver Signed-off-by: Florian Fainelli <[EMAIL PROTECTED]> ack, but the patch was corrupted... -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add me as maintainer of the RDC r6040 driver
Florian Fainelli wrote: This patch adds me as maintainer of the RDC R6040 Fast Ethernet driver. Signed-off-by: Florian Fainelli <[EMAIL PROTECTED]> applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28
Thomas Bogendoerfer wrote: - Use inline functions for dma_sync_* instead of macros - added Kconfig change to make selection for similair SGI boxes easier Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]> --- drivers/net/Kconfig |2 +- drivers/net/sgiseeq.c | 64 ++--- 2 files changed, 35 insertions(+), 31 deletions(-) applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: add a guideline for hard_start_xmit method not to modify SKB
Matti Linnanvuori wrote: From: Matti Linnanvuori <[EMAIL PROTECTED]> Add a guideline for hard_start_xmit method not to modify SKB. Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]> --- --- a/Documentation/networking/driver.txt 2007-12-22 18:50:28.062169500 +0200 +++ b/Documentation/networking/driver.txt 2007-12-22 19:10:58.726566000 +0200 @@ -74,6 +74,9 @@ Transmit path guidelines: If you return 1 from the hard_start_xmit method, you must not keep any reference to that SKB and you must not attempt to free it up. +4) A hard_start_xmit method must not modify the cloned parts of the + SKB. + Probing guidelines: 1) Any hardware layer address you obtain for your device should patch is word-wrapped -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/7] netxen: update MAINTAINERS
applied 1-2 to #upstream-fixes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/7] netxen: improve MSI interrupt handling
patch failed to apply (possibly because of recent NAPI updates) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/7] netxen: stop second phy correctly
applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 5/7] netxen: fix race in interrupt / napi
patch conflicted with commit 1706287f6eb58726a9a0e5cbbde87f49757615e3 Author: David S. Miller <[EMAIL PROTECTED]> Date: Mon Jan 7 20:51:29 2008 -0800 [NETXEN]: Fix ->poll() done logic. If work_done >= budget we should always elide the NAPI completion. Signed-off-by: David S. Miller <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 6/7] netxen: optimize tx handling
applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] Fixed a small typo in the loopback driver
Emil Medve wrote: This is probably a result of the changes from commit 854d836 - [NET]: Dynamically allocate the loopback device, part 2 Signed-off-by: Emil Medve <[EMAIL PROTECTED]> --- linux-2.6> scripts/checkpatch.pl 0001-NET-Fixed-a-small-typo-in-the-loopback-driver.patch total: 0 errors, 0 warnings, 8 lines checked Your patch has no obvious style problems and is ready for submission. drivers/net/loopback.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] r8169: fix missing loop variable increment
Francois Romieu wrote:
Spotted-by: Citizen Lee <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 5863190..6ee9db1 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2002,7 +2002,7 @@ static void rtl8169_set_magic_reg(void __iomem *ioaddr,
unsigned mac_version)
u32 clk;
clk = RTL_R8(Config2) & PCI_Clock_66MHz;
- for (i = 0; i < ARRAY_SIZE(cfg2_info); i++) {
+ for (i = 0; i < ARRAY_SIZE(cfg2_info); i++, p++) {
if ((p->mac_version == mac_version) && (p->clk == clk)) {
RTL_W32(0x7c, p->val);
applied
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ip1000: menu location change
Stephen Hemminger wrote: Move the ip1000 driver into the expected place for gigabit cards in the configuration menu structure. It should be under the gigabit cards, not at the top level. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- a/drivers/net/Kconfig 2007-12-26 20:17:31.0 -0800 +++ b/drivers/net/Kconfig 2007-12-26 20:18:36.0 -0800 @@ -166,16 +166,6 @@ config NET_SB1000 If you don't have this card, of course say N. -config IP1000 - tristate "IP1000 Gigabit Ethernet support" - depends on PCI && EXPERIMENTAL - select MII - ---help--- - This driver supports IP1000 gigabit Ethernet cards. - - To compile this driver as a module, choose M here: the module - will be called ipg. This is recommended. - source "drivers/net/arcnet/Kconfig" source "drivers/net/phy/Kconfig" @@ -2004,6 +1994,16 @@ config E1000E To compile this driver as a module, choose M here. The module will be called e1000e. +config IP1000 + tristate "IP1000 Gigabit Ethernet support" + depends on PCI && EXPERIMENTAL + select MII + ---help--- + This driver supports IP1000 gigabit Ethernet cards. + + To compile this driver as a module, choose M here: the module + will be called ipg. This is recommended. + source "drivers/net/ixp2000/Kconfig" applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
Anton Vorontsov wrote: Otherwise oops will happen if ethernet device has not been opened: Unable to handle kernel paging request for data at address 0x014c Faulting instruction address: 0xc016f7f0 Oops: Kernel access of bad area, sig: 11 [#1] MPC85xx NIP: c016f7f0 LR: c01722a0 CTR: REGS: c79ddc70 TRAP: 0300 Not tainted (2.6.24-rc3-g820a386b) MSR: 00029000 CR: 20004428 XER: 2000 DEAR: 014c, ESR: TASK = c789f5e0[999] 'snmpd' THREAD: c79dc000 GPR00: c01aceb8 c79ddd20 c789f5e0 c79ddd3c c79ddd64 GPR08: c7845b60 c79dde3c c01ace80 20004422 200249fc 02a0 100da728 GPR16: 100c 20022078 0009 200220e0 bfc85558 GPR24: c79ddd3c c02e0e70 c022fc64 c7845800 bfc85498 NIP [c016f7f0] phy_ethtool_gset+0x0/0x4c LR [c01722a0] fs_get_settings+0x18/0x28 Call Trace: [c79ddd20] [c79dde38] 0xc79dde38 (unreliable) [c79ddd30] [c01aceb8] dev_ethtool+0x294/0x11ec [c79dde30] [c01aaa44] dev_ioctl+0x454/0x6a8 [c79ddeb0] [c019b9d4] sock_ioctl+0x84/0x230 [c79dded0] [c007ded8] do_ioctl+0x34/0x8c [c79ddee0] [c007dfbc] vfs_ioctl+0x8c/0x41c [c79ddf10] [c007e38c] sys_ioctl+0x40/0x74 [c79ddf40] [c000d4c0] ret_from_syscall+0x0/0x3c Instruction dump: 8163 800b0030 2f80 419e0010 7c0803a6 4e800021 7c691b78 80010014 7d234b78 38210010 7c0803a6 4e800020 <8003014c> 7c6b1b78 3860 90040004 Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Acked-by: Vitaly Bordug <[EMAIL PROTECTED]> --- Just resending it, it feels like it got lost during holidays. drivers/net/fs_enet/fs_enet-main.c | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Pull request for 'ipg-fixes' branch
Francois Romieu wrote: Please pull from branch 'ipg-fixes' in repository git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git ipg-fixes to get the changes below. I have tested the driver with a PIV HT based motherboard. The network controller is connected to a fast ethernet switch (yeah, I'm cheap). A second host is performing two loop of scp in both direction for a 400Mb file. The files are sha1sumed after each scp. I have added a 'ping -q -f -l16' from the computer under test after some time. After 35 copies from the computer under test and 28 copies to it (the ping eats a bit): total used free sharedbuffers cached Mem: 10190401003860 15180 0 20556 936792 -/+ buffers/cache: 46512 972528 Swap: 2031608 02031608 Before: total used free sharedbuffers cached Mem: 1019040 572036 447004 0 14988 525924 -/+ buffers/cache: 31124 987916 Swap: 2031608 02031608 /proc/slabinfo before and after the test are attached. The driver is still a POMS but it seems better now. I will not be available to work further on this issue before sunday. I'd appreciate being Cced though. Distance from 'net-2.6/master' (27d1cba21fcc50c37eef5042c6be9fa7135e88fc) - 286c83ce6e8263a5c4c55a57b4c1040800de0171 d42f3afc953f9c99ffe84667a3ecf0d3b69f3d64 358bf4b8e8cbde5d6411b219e93a61728c892685 a58cceed4464ba8ae94294184c15f43e92a5de89 Diffstat drivers/net/ipg.c | 36 1 files changed, 12 insertions(+), 24 deletions(-) hrm... tried to pull this, but received non-ipg stuff too -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] spidernet: add missing initialization
applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'fixes-jgarzik' branch of wireless-2.6 (use this one)
John W. Linville wrote: [2nd try -- turns-out the Mattis Nissler patch needed an extra tweak. It will probably also cause build breakage when you rebase since rt2x00lib_txdone(...) becomes rt2x00pci_txdone(rt2x00dev,...) in 2.6.25, so FYI... :-) This also includes another patch (the "4 byte boundary" one) which is already in your upstream branch. So, beware of that one too. :-)] Jeff, Three more fixes for 2.6.24. The one from Mattias Nissler is already in your upstream tree...FYI. Let me know if there are problems! Thanks, John --- Individual patches available here: http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/ --- The following changes since commit 3ce54450461bad18bbe1f9f5aa3ecd2f8e8d1235: Linus Torvalds (1): Linux 2.6.24-rc7 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik Ivo van Doorn (2): rt2x00: Corectly initialize rt2500usb MAC rt2x00: Put 802.11 data on 4 byte boundary Mattias Nissler (1): rt2x00: Allow rt61 to catch up after a missing tx report drivers/net/wireless/rt2x00/rt2500usb.c |2 +- drivers/net/wireless/rt2x00/rt2x00pci.c | 20 drivers/net/wireless/rt2x00/rt2x00usb.c | 17 +++-- drivers/net/wireless/rt2x00/rt61pci.c | 12 4 files changed, 44 insertions(+), 7 deletions(-) pulled -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 7/7] netxen: fix byte-swapping in tx and rx
applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ethtool: fix typo on setting speed 10000
Auke Kok wrote: From: Jesse Brandeburg <[EMAIL PROTECTED]> fix the typo in speed 1 setting. Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- ethtool.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) patches 1 and 2 failed to apply. applied #3 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] sky2: large memory workaround.
applied 1-2 to #upstream-fixes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] SGISEEQ: fix oops when doing ifconfig down; ifconfig up
When doing init_ring checking whether a new skb needs to be allocated
was wrong.
Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---
This is a bug fix for the 2.6.25 driver.
drivers/net/sgiseeq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sgiseeq.c b/drivers/net/sgiseeq.c
index c69bb8b..78994ed 100644
--- a/drivers/net/sgiseeq.c
+++ b/drivers/net/sgiseeq.c
@@ -193,7 +193,7 @@ static int seeq_init_ring(struct net_device *dev)
/* And now the rx ring. */
for (i = 0; i < SEEQ_RX_BUFFERS; i++) {
- if (!sp->rx_desc[i].rdma.pbuf) {
+ if (!sp->rx_desc[i].skb) {
dma_addr_t dma_addr;
struct sk_buff *skb = netdev_alloc_skb(dev, PKT_BUF_SZ);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus to receive the following updates: MAINTAINERS | 10 ++- drivers/net/3c509.c |4 + drivers/net/Kconfig | 20 +++--- drivers/net/fs_enet/fs_enet-main.c | 11 ++- drivers/net/loopback.c |2 +- drivers/net/netxen/netxen_nic.h | 69 + drivers/net/netxen/netxen_nic_init.c| 20 ++--- drivers/net/netxen/netxen_nic_main.c| 70 ++--- drivers/net/netxen/netxen_nic_niu.c |8 +- drivers/net/r8169.c |2 +- drivers/net/sky2.c | 48 +++- drivers/net/sky2.h |4 +- drivers/net/tulip/de4x5.c | 127 +++ drivers/net/tulip/tulip_core.c |3 +- drivers/net/tulip/xircom_cb.c | 54 ++--- drivers/net/usb/asix.c |6 +- drivers/net/wireless/rt2x00/rt2500usb.c |2 +- drivers/net/wireless/rt2x00/rt2x00pci.c | 20 - drivers/net/wireless/rt2x00/rt2x00usb.c | 17 - drivers/net/wireless/rt2x00/rt61pci.c | 12 +++ 20 files changed, 238 insertions(+), 271 deletions(-) Al Viro (3): xircom_cb endianness fixes de4x5 fixes endianness noise in tulip_core Anton Vorontsov (1): fs_enet: check for phydev existence in the ethtool handlers Dhananjay Phadke (1): netxen: fix byte-swapping in tx and rx Emil Medve (1): Fixed a small typo in the loopback driver Francois Romieu (1): r8169: fix missing loop variable increment Ivo van Doorn (2): rt2x00: Corectly initialize rt2500usb MAC rt2x00: Put 802.11 data on 4 byte boundary Jens Osterkamp (1): spidernet MAINTAINERship update Krzysztof Helt (1): 3c509: PnP resource management fix Mattias Nissler (1): rt2x00: Allow rt61 to catch up after a missing tx report Russ Dill (1): [usb netdev] asix: fix regression Stephen Hemminger (3): ip1000: menu location change sky2: large memory workaround. sky2: remove check for PCI wakeup setting from BIOS [EMAIL PROTECTED] (4): netxen: update MAINTAINERS netxen: update driver version netxen: stop second phy correctly netxen: optimize tx handling diff --git a/MAINTAINERS b/MAINTAINERS index b4f611c..92aa0a7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2739,8 +2739,8 @@ T:git kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git S: Maintained NETXEN (1/10) GbE SUPPORT -P: Amit S. Kale -M: [EMAIL PROTECTED] +P: Dhananjay Phadke +M: [EMAIL PROTECTED] L: netdev@vger.kernel.org W: http://www.netxen.com S: Supported @@ -3611,8 +3611,10 @@ L: [EMAIL PROTECTED] ? S: Supported SPIDERNET NETWORK DRIVER for CELL -P: Linas Vepstas -M: [EMAIL PROTECTED] +P: Ishizaki Kou +M: [EMAIL PROTECTED] +P: Jens Osterkamp +M: [EMAIL PROTECTED] L: netdev@vger.kernel.org S: Supported diff --git a/drivers/net/3c509.c b/drivers/net/3c509.c index edda6e1..8fafac9 100644 --- a/drivers/net/3c509.c +++ b/drivers/net/3c509.c @@ -385,6 +385,7 @@ static int __init el3_probe(int card_idx) #if defined(__ISAPNP__) static int pnp_cards; struct pnp_dev *idev = NULL; + int pnp_found = 0; if (nopnp == 1) goto no_pnp; @@ -430,6 +431,7 @@ __again: pnp_cards++; netdev_boot_setup_check(dev); + pnp_found = 1; goto found; } } @@ -560,6 +562,8 @@ no_pnp: lp = netdev_priv(dev); #if defined(__ISAPNP__) lp->dev = &idev->dev; + if (pnp_found) + lp->type = EL3_PNP; #endif err = el3_common_init(dev); diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index d9107e5..114771a 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -166,16 +166,6 @@ config NET_SB1000 If you don't have this card, of course say N. -config IP1000 - tristate "IP1000 Gigabit Ethernet support" - depends on PCI && EXPERIMENTAL - select MII - ---help--- - This driver supports IP1000 gigabit Ethernet cards. - - To compile this driver as a module, choose M here: the module - will be called ipg. This is recommended. - source "drivers/net/arcnet/Kconfig" source "drivers/net/phy/Kconfig" @@ -1992,6 +1982,16 @@ config E1000E To compile this driver as a module, choose M here. The module will be called e1000e. +config IP1000 + tristate "IP1000 Gigabit Ethernet support" + depends on PCI && EXPERIMENTAL + select MII + ---help--- + This driver supports IP1000 gigabit Ethernet cards. + + To compile this d
Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
Jay Vosburgh <[EMAIL PROTECTED]> wrote:
>
>Can you test the following and let me know if it triggers the
> warning? I believe this is the minimum locking needed, and based on
> input from Herbert, we shouldn't need to hold the lock at _bh. If this
> one works, and nobody sees any other issues with it, then it's the final
> patch for this lockdep problem. I'll add some deep, meaningful comments
> to explain the locking a bit (i.e., we're called with rtnl for the
> allmulti and promisc cases, so we're ok there without additional locks,
> but the later code could be called from anywhere, so it needs locks to
> prevent the slave list from changing, but the mc_lists themselves are
> covered by the netif_tx_lock that all callers will hold), but this would
> be the actual code change.
I just had a look at the bonding code and while I didn't find anything
wrong with the change of the write lock to a read lock, the mc_list
itself does not seem to have adequete protection. In particular, there
doesn't seem to be anything protecting the walking of mc_list in
bond_enslave.
This could be a problem if we have an IGMP6 event triggering the change
in the master's mc_list.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] irda: return -ENOMEM upon failure to allocate new ias_obj
irias_new_object() can fail its memory allocation and will return NULL in
that case. I believe the proper thing to do is to catch this, free the
ias_opt that was allocated earlier but won't be used and then return
-ENOMEM.
There are assertions further on that check for a NULL ias_obj, but I think
it's a lot nicer to simply return -ENOMEM to the caller here where we know
a memory allocation failed, rather than hitting an assertion later.
note: I don't have any means of actually testing this, so it has been
compile tested only.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
af_irda.c |4
1 file changed, 4 insertions(+)
diff --git a/net/irda/af_irda.c b/net/irda/af_irda.c
index d5e4dd7..e33f0a5 100644
--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -1881,6 +1881,10 @@ static int irda_setsockopt(struct socket *sock, int
level, int optname,
/* Create a new object */
ias_obj = irias_new_object(ias_opt->irda_class_name,
jiffies);
+ if (!ias_obj) {
+ kfree(ias_opt);
+ return -ENOMEM;
+ }
}
/* Do we have the attribute already ? */
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] irda: avoid potential memory leak in irda_setsockopt()
There are paths through the irda_setsockopt() function where we return and
may or may not have allocated a new ias_obj but in any case have not used
it for anything yet and we end up leaking memory.
As far as I can tell, in the case where we didn't allocate a new ias_ob
but simply were planning to use one already available then we should not
free it before returning. But when we have allocated a brand new ias_obj
but have not yet used it or put it on any lists etc and then return,
that's a memory leak.
There are two cases:
1)
switch (optname) {
case IRLMP_IAS_SET:
...
if(ias_obj == (struct ias_object *) NULL) {
/* Create a new object */
--[alloc]--> ias_obj = irias_new_object(ias_opt->irda_class_name,
jiffies);
...
switch(ias_opt->irda_attrib_type) {
case IAS_OCT_SEQ:
/* Check length */
if(ias_opt->attribute.irda_attrib_octet_seq.len >
IAS_MAX_OCTET_STRING) {
kfree(ias_opt);
--[leak]-->return -EINVAL;
...
}
irias_insert_object(ias_obj);
The allocated object isn't referenced at all until we get outside the
inner switch, so clearly we leak it (if we took the path that allocated it
that is).
2)
The second case is the same as the above, except it's the default: case in
the inner switch instead of case IAS_OCT_SEQ:
default :
kfree(ias_opt);
return -EINVAL;
The way I propose to fix this is with a new variable that keeps track of
whether or not we found an existing ias_obj to use or if we took the
allocation path, then use that variable to determine if we should free
ias_obj before returning from the function.
I'm not very intimate with this code, so if there's a better solution I'd
very much like to hear it. It's also entirely possible that someone with
more knowledge of this code can prove that these cases can't actually ever
happen - if that's the case then please let me know.
This patch is meant to be applied on top of
[PATCH 1/2] irda: return -ENOMEM upon failure to allocate new ias_obj
The Coverity checker gets credit for pointing its finger towards this.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
af_irda.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/irda/af_irda.c b/net/irda/af_irda.c
index e33f0a5..352e8a7 100644
--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -1824,7 +1824,8 @@ static int irda_setsockopt(struct socket *sock, int
level, int optname,
struct irda_sock *self = irda_sk(sk);
struct irda_ias_set*ias_opt;
struct ias_object *ias_obj;
- struct ias_attrib * ias_attr; /* Attribute in IAS object */
+ struct ias_attrib *ias_attr; /* Attribute in IAS object */
+ int alloc_new_obj = 0;
int opt;
IRDA_DEBUG(2, "%s(%p)\n", __FUNCTION__, self);
@@ -1885,6 +1886,7 @@ static int irda_setsockopt(struct socket *sock, int
level, int optname,
kfree(ias_opt);
return -ENOMEM;
}
+ alloc_new_obj = 1;
}
/* Do we have the attribute already ? */
@@ -1908,6 +1910,8 @@ static int irda_setsockopt(struct socket *sock, int
level, int optname,
if(ias_opt->attribute.irda_attrib_octet_seq.len >
IAS_MAX_OCTET_STRING) {
kfree(ias_opt);
+ if (alloc_new_obj)
+ kfree(ias_obj);
return -EINVAL;
}
/* Add an octet sequence attribute */
@@ -1936,6 +1940,8 @@ static int irda_setsockopt(struct socket *sock, int
level, int optname,
break;
default :
kfree(ias_opt);
+ if (alloc_new_obj)
+ kfree(ias_obj);
return -EINVAL;
}
irias_insert_object(ias_obj);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] synchronize_rcu(): high latency on idle system
On Sat, 12 Jan 2008 19:35:58 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > On Saturday 12 January 2008 18:51:35 Benjamin LaHaise wrote: > > On Sat, Jan 12, 2008 at 03:37:59AM +0100, Andi Kleen wrote: > > > > And yes, the > > > > network stack shouldn't call synchronize_rcu() quite so much, but > > > > fixing that > > > > is a little more involved. > > > > > > ... but the correct solution. > > > > There has to be at least 1 synchronize_rcu() or equivalent in the > > unregister_netdev() path. I suspect the easiest way to fix it might be to > > use call_rcu() to actually free the network device, as anything else will > > limit performance of single threaded teardown (ie, when an l2tp daemon > > gets terminated via kill -9). This means an API change that exposes > > rcu for unregister_netdev(). > > The call_rcu() could be in free_netdev() couldn't it? I think it should be in netdev_unregister_kobject(). But that would only get rid of one of the two calls to synchronize_rcu() in the unregister_netdev. The other synchronize_rcu() is for qdisc's and not sure if that one can be removed? -- Stephen Hemminger <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25] [XFRM] Remove unused XFRM_STATE_VOID and typos (net/xfrm.h)
From: "Rami Rosen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 13:37:34 +0200 > In net/xfrm.h: > - remove XFRM_STATE_VOID (not in use) > - correct 3 typos > > Signed-off-by: Rami Rosen <[EMAIL PROTECTED]> XFRM_STATE_VOID is there so that a freshly initialized object does not have a valid state. So we should not remove this. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: Herbert Xu <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 23:17:40 +1100 > Your emails are now using UTF-8 encoding but it's still declaring > ISO-8859-1 as the charset. So you probably want to fix that up or > your name may show up as Jävinen on the reader's screen. Yes, for people using the GIT email patch applying tools, it might do that. However I believe there are options to git-am and friends to force it to put things into UTF-8. I ran into some problems with encoding because I apply stuff by hand using scripts I wrote. But those problem won't happen any more for me. I'm now saving the commit message and patch into files explicitly in emacs, and verifying the coding (with "C-h C RET") and if it's wrong I fix it before saving with "C-x RET f mule-utf-8" Then I feed those into my patch applying scripts. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 14:59:50 +0200 (EET) > ...Maybe I just fall-back to changing my last name, it's the only > full-proof solution... ;-) Don't do this! Otherwise I won't have a frequent test case to make sure my patch applying scripts are working properly. :- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] get rid of trie_init
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 22:45:14 -0800 > trie_init is worthless it is just zeroing stuff that is already > zero! Move the memset() down to make it obvious. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] get rid of unused revision element
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 22:45:15 -0800 > The revision element must of been part of an earlier design, > because currently it is set but never used. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied. I suspect Robert wanted to play around with some generation ID optimizations but never got around to it. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] move size information to pr_debug()
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 22:45:16 -0800 > The size of structures is a debug thing, not something that needs to > be part of a /proc api. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> I don't necessarily agree with this one, the size of the structures is an important inherent attribute contributing directly to memory usage and performance of the algorithms. So knowing those values are necessary to diagnose problems. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] statistics improvements
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 22:45:17 -0800 > Turn the unused size field into a useful counter for the number > of routes. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> It's not useful if nothing reports it's value. I'm dropping this. Unless you add code to provide this information via procfs or similar, better to just remove it. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] use %u for unsigned printfs
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 22:45:18 -0800 > Use %u instead of %d when printing unsigned values. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] : fib_insert_node cleanup
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 22:45:19 -0800 > The only error from fib_insert_node is if memory allocation fails, > so instead of passing by reference, just use the convention of returning > NULL. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> I'd be a hypocrite if I didn't apply this one :-) Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] printk related cleanups
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 22:45:20 -0800 > printk related cleanups: > * Get rid of unused printk wrappers. > * Make bug checks into KERN_WARNING because KERN_DEBUG gets ignored > * Turn one cryptic old message into something real > * Make sure all messages have KERN_XXX Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] add statistics
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 22:45:21 -0800 > The FIB TRIE code has a bunch of statistics, but the code is hidden > behind an ifdef that was never implemented. Since it was dead code, > it was broken as well. > > This patch fixes that by making it a config option. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] fix sparse warnings
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 22:45:22 -0800 > Make FIB TRIE go through sparse checker without warnings. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Also applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] [NETFILTER] xt_policy.c: kill some bloat
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 20:03:31 +0100 > David Miller wrote: > > From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> > > Date: Sat, 12 Jan 2008 11:34:27 +0200 > > > > Ilpo, please post netfilter patches to netfilter-devel, > > CC:'ing Patrick McHardy. > > > > Patrick, please review, thanks. > > This looks fine to me, thanks Ilpo. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] fix sparse warnings
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 13:09:46 -0800 > On Sat, 12 Jan 2008 12:16:13 +0100 > Eric Dumazet <[EMAIL PROTECTED]> wrote: > > > [FIB]: Reduce text size of net/ipv4/fib_trie.o > > > > In struct tnode, we use two fields of 5 bits for 'pos' and 'bits'. > > Switching to plain 'unsigned char' (8 bits) take the same space > > because of compiler alignments, and reduce text size by 435 bytes > > on i386. > > > > On i386 : > > $ size net/ipv4/fib_trie.o.before_patch net/ipv4/fib_trie.o > > textdata bss dec hex filename > >13714 4 64 1378235d6 net/ipv4/fib_trie.o.before > >13279 4 64 133473423 net/ipv4/fib_trie.o > > > > Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> > > > > I agree they should not have been bitfields in the first place. Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [NET] core/utils.c: digit2bin is dead static inline
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 13:53:35 +0200 > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [HTB]: htb_classid is dead static inline
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 13:53:36 +0200 > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [XFRM]: alg_key_len should be unsigned to avoid integer divides
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Sat, 12 Jan 2008 18:29:32 +0100
> alg_key_len is currently defined as 'signed int'. This unfortunatly leads
> to integer divides in several paths.
>
> Converting it to unsigned is safe and saves 208 bytes of text on i386.
>
> Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
Applied.
I realigned the struct members in a follow-on changeset.
commit 7305e737926be49e09718df53f4285bf69cc3755
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Sat Jan 12 21:31:29 2008 -0800
[XFRM]: Fix struct xfrm_algo code formatting.
Realign struct members.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index f8507ee..9b5b00c 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -91,9 +91,9 @@ struct xfrm_replay_state
};
struct xfrm_algo {
- charalg_name[64];
+ charalg_name[64];
unsigned intalg_key_len;/* in bits */
- charalg_key[0];
+ charalg_key[0];
};
struct xfrm_stats {
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Documentation: add a guideline for hard_start_xmit method
From: Matti Linnanvuori <[EMAIL PROTECTED]> Add a guideline for hard_start_xmit method not to modify SKB. Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]> --- --- a/Documentation/networking/driver.txt 2008-01-13 07:14:01.608291500 +0200 +++ b/Documentation/networking/driver.txt 2008-01-13 07:13:40.535421500 +0200 @@ -61,7 +61,9 @@ 2) Do not forget to update netdev->trans_start to jiffies after each new tx packet is given to the hardware. -3) Do not forget that once you return 0 from your hard_start_xmit +3) A hard_start_xmit method must not modify the shared parts of the SKB. + +4) Do not forget that once you return 0 from your hard_start_xmit method, it is your driver's responsibility to free up the SKB and in some finite amount of time. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] statistics improvements
David Miller wrote: From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 22:45:17 -0800 Turn the unused size field into a useful counter for the number of routes. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> It's not useful if nothing reports it's value. I'm dropping this. Unless you add code to provide this information via procfs or similar, better to just remove it. The size field is added to /proc/net/fib_triestat that was the point. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fib_semantics: prevent long hash chains in access server config
From: Benjamin LaHaise <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 13:58:19 -0500 > This is a patch from a while ago that I'm resending. Basically, in > access server configurations, a lot of routes have the same local ip > address but on different devices. This fixes the long chains that > result from not including the device index in the hash. I'm not applying this for the same reason I didn't apply it last time. Please listen to the reason this time, and do not resubmit this until the problem with this patch is resolved. The fib_dev is an attribute of the first nexthop, ie. the fib_info->fib_nh[0] member. There can be multiple nexthops. It is pointless to salt the hash with one of the nexthop device indexes if you do not also compare the index in the hash lookup comparisons. And guess why we don't do this? Because it's not part of the key. Other aspects of the base fib_info and nexthops provide the uniqueness, not the devindex of the first hop. So you'll need to find another way to do this. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] statistics improvements
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Sat, 12 Jan 2008 21:33:16 -0800 > The size field is added to /proc/net/fib_triestat that was the point. Not from what I can see. [EMAIL PROTECTED]:~/src/GIT/net-2.6.25$ git grep -e "->size" net/ipv4/fib_trie.c net/ipv4/fib_trie.c:t->size++; net/ipv4/fib_trie.c:t->size--; [EMAIL PROTECTED]:~/src/GIT/net-2.6.25$ git grep -e "\.size" net/ipv4/fib_trie.c [EMAIL PROTECTED]:~/src/GIT/net-2.6.25$ Nothing uses the field, it is merely incremented and decremented. trie_show_stats() and trie_show_usage() do not access this field. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
