[patch] skbuff: spelling and formatting fixes
--- a/include/linux/skbuff.h2007-12-25
08:24:51.032348500 +0200
+++ b/include/linux/skbuff.h2007-12-25
08:38:31.067753500 +0200
@@ -127,7 +127,7 @@ struct sk_buff_head {
struct sk_buff;
/* To allow 64K frame to be packed as single skb
without frag_list */
-#define MAX_SKB_FRAGS (65536/PAGE_SIZE + 2)
+#define MAX_SKB_FRAGS ((65536 / PAGE_SIZE) + 2)
typedef struct skb_frag_struct skb_frag_t;
@@ -394,7 +394,7 @@ static inline void
skb_truesize_check(st
extern int skb_append_datato_frags(struct sock *sk,
struct sk_buff *skb,
int getfrag(void *from, char *to, int offset,
- int len,int odd, struct sk_buff *skb),
+ int len, int odd, struct sk_buff *skb),
void *from, int length);
struct skb_seq_state
@@ -1346,7 +1346,7 @@ static inline struct sk_buff
*netdev_all
* @len: length up to which to write
*
* Returns true if modifying the header part of the
cloned buffer
- * does not requires the data to be copied.
+ * does not require the data to be copied.
*/
static inline int skb_clone_writable(struct sk_buff
*skb, unsigned int len)
{
__ Ihr erstes Fernweh? Wo gibt es den
schönsten Strand? www.yahoo.de/clever
--
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-davem' branch of wireless-2.6
From: "John W. Linville" <[EMAIL PROTECTED]> Date: Thu, 20 Dec 2007 10:52:27 -0500 > A few more stragglers for 2.6.24...let me know if there are any > problems! ... > The following changes since commit 82d29bf6dc7317aeb0a3a13c2348ca8591965875: > Linus Torvalds (1): > Linux 2.6.24-rc5 > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git > fixes-davem > > Johannes Berg (2): > mac80211: round station cleanup timer > mac80211: warn when receiving frames with unaligned data Pulled and pushed back out to net-2.6, thanks John. -- 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: santize headers for iproute2
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 21 Dec 2007 09:43:36 -0800 > iproute2 source uses headers that result from "make headers_install". > The header files net/tcp_states.h and net/veth.h are both being used > but are not processed. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> The convention is to place user visible interfaces in header files under include/linux/ and purely kernel internal bits in header files under include/net/ Therefore exporting net/*.h headers is not right. net/veth.h only defines user visible interfaces, so it belongs under include/linux and added to include/linux/Kbuild, and I would happily take a patch implementing that. net/tcp_states.h is not movable to include/linux/ and thus to userspace, it defines things that are present already in existing userland header files. If you look, defines these state values, as an enumeration. If you need the TCPF_* flag bit versions, sorry... you'll need to find some other way to get those into userspace. -- 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] [TCP]: Remove seq_rtt ptr from clean_rtx_queue args
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Fri, 21 Dec 2007 16:19:19 +0200 (EET) > While checking Gavin's patch I noticed that the returned seq_rtt > is not used by the caller. > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Good catch, applied to net-2.6.25 The history of this is that way back when, Vegas used to use it for RTT calculations, bit it handles that now via the ->pkts_acked() cong-control method. -- 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] [TCP]: Force TSO splits to MSS boundaries
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Fri, 21 Dec 2007 20:55:28 +0200 (EET) > [PATCH] [TCP]: Force TSO splits to MSS boundaries > > If snd_wnd - snd_nxt wasn't multiple of MSS, skb was split on > odd boundary by the callers of tcp_window_allows. > > We try really hard to avoid unnecessary modulos. Therefore the > old caller side check "if (skb->len < limit)" was too wide as > well because limit is not bound in any way to skb->len and can > cause spurious testing for trimming in the middle of the queue > while we only wanted that to happen at the tail of the queue. > A simple additional caller side check for tcp_write_queue_tail > would likely have resulted 2 x modulos because the limit would > have to be first calculated from window, however, doing that > unnecessary modulo is not mandatory. After a minor change to > the algorithm, simply determine first if the modulo is needed > at all and at that point immediately decide also from which > value it should be calculated from. > > This approach also kills some duplicated code. > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Looks good, patch applied, thanks. With respect to code duplicateion, tcp_push_one() is essentially the inner loop of tcp_write_xmit() :-) -- 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] TUNTAP: Fix wrong debug message
From: Toyo Abe <[EMAIL PROTECTED]> Date: Tue, 25 Dec 2007 12:27:56 +0900 (JST) > --- Original Messsage --- > From: Joe Perches <[EMAIL PROTECTED]> > Subject: Re: [PATCH] TUNTAP: Fix wrong debug message > Date: Mon, 24 Dec 2007 18:48:48 -0800 > Message-ID: <[EMAIL PROTECTED]> > > > More readable to reverse the strings > > > > tun->dev->name, arg ? "enabled" : "disabled"); > > > > Hello Joe, > Thanks for your advice. > > This is the more readable version. Applied, thanks Toyo. Joe, please don't provide patch feedback in private emails as it appears you did here. When you do this, it cheapens the value of the feedback because other people reading the list cannot benefit nor comment on it. You've done this to me in the past too, and I told you back then to please stop doing it. 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: [ETH]: Combine format_addr() with print_mac().
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Sun, 23 Dec 2007 16:20:35 -0800 > Here's the revised patch: > > [ETH]: Combine format_addr() with print_mac(). > > print_mac() used many most net drivers and format_addr() used by > net-sysfs.c are very similar and they can be intergrated. > > format_addr() is also identically redefined in the qla4xxx iscsi > driver. > > Export a new function sysfs_format_mac() to be used by net-sysfs, > qla4xxx and others in the future. Both print_mac() and > sysfs_format_mac() call _format_mac_addr() to do the formatting. > > Changed print_mac() to use unsigned char * to be consistent with > net_device struct's dev_addr. Added buffer length overrun checking > as suggested by Joe Perches. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Applied to net-2.6.25, thanks Michael. -- 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: [WEXT 3/12]: Extract standard call iw_point handling into seperate function.
From: Joe Perches <[EMAIL PROTECTED]> Date: Fri, 21 Dec 2007 23:22:52 -0800 > On Fri, 2007-12-21 at 20:54 -0800, David Miller wrote: > > [WEXT]: Extract standard call iw_point handling into seperate function. > > This potentially does copy_from_user twice, > first to the stack, second to a kmalloc'ed area. > Perhaps it's better to kmalloc first and copy once? I'm preserving existing behavior in these changes, feel free to make these kinds of improvements as a follow-on changeset. -- 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: [SOCK] Avoid divides in sk_stream_pages() and __sk_stream_mem_reclaim()
From: Eric Dumazet <[EMAIL PROTECTED]> Date: Fri, 21 Dec 2007 15:45:08 +0100 > [SOCK] Avoid divides in sk_stream_pages() and __sk_stream_mem_reclaim() > > sk_forward_alloc being signed, we should take care of divides by > SK_STREAM_MEM_QUANTUM we do in sk_stream_pages() and > __sk_stream_mem_reclaim() > > This patchs introduces SK_STREAM_MEM_QUANTUM_SHIFT, defined > as ilog2(SK_STREAM_MEM_QUANTUM), to be able to use right > shifts instead of plain divides. > > This should help compiler to choose right shifts instead of > expensive divides (as seen with CONFIG_CC_OPTIMIZE_FOR_SIZE=y on x86) > > Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> Applied, thanks Eric. -- 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: (2nd attempt) Please pull 'upstream-davem' branch of wireless-2.6
From: "John W. Linville" <[EMAIL PROTECTED]> Date: Fri, 21 Dec 2007 09:05:27 -0500 > These are destined for 2.6.25. The patches fall mostly into two > categories: a new rate control algorithm for mac80211, and some > cfg80211 enhancements (including mac80211 patches to use them). > > Also there are some small hits in the iwlwifi drivers related to > rate control. I'll CC Jeff since his tree has a lot of iwlwifi symbol > renames and those patches will conflict (or break the build, or both) > when your tree and his finally come together. > > Let me know if there are any problems! Pulled, thanks a lot! -- 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] TUNTAP: Fix wrong debug message
--- Original Messsage --- From: Joe Perches <[EMAIL PROTECTED]> Subject: Re: [PATCH] TUNTAP: Fix wrong debug message Date: Mon, 24 Dec 2007 18:48:48 -0800 Message-ID: <[EMAIL PROTECTED]> > More readable to reverse the strings > > tun->dev->name, arg ? "enabled" : "disabled"); > Hello Joe, Thanks for your advice. This is the more readable version. Best Regards, -toyo This is a trivial fix of debug message. When a persist flag is set, the message should say "enabled". Signed-off-by: Toyo Abe <[EMAIL PROTECTED]> --- drivers/net/tun.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 1f76446..f8b8c71 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -610,7 +610,7 @@ static int tun_chr_ioctl(struct inode *inode, struct file *file, tun->flags &= ~TUN_PERSIST; DBG(KERN_INFO "%s: persist %s\n", - tun->dev->name, arg ? "disabled" : "enabled"); + tun->dev->name, arg ? "enabled" : "disabled"); break; case TUNSETOWNER: -- 1.5.3.6
[PATCH] TUNTAP: Fix wrong debug message
This is a trivial fix of debug message. When a persist flag is set, the message should say "enabled". Signed-off-by: Toyo Abe <[EMAIL PROTECTED]> --- drivers/net/tun.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 1f76446..e5a3f5d 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -610,7 +610,7 @@ static int tun_chr_ioctl(struct inode *inode, struct file *file, tun->flags &= ~TUN_PERSIST; DBG(KERN_INFO "%s: persist %s\n", - tun->dev->name, arg ? "disabled" : "enabled"); + tun->dev->name, (!arg) ? "disabled" : "enabled"); break; case TUNSETOWNER: -- 1.5.3.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 3/6] netxen: improve MSI interrupt handling
Supposedly I had 2.6.24-rc2 as base for the patchset, but looks like it had some stale code. I'll regenrate series on a fresh checkout. -Dhananjay On Sat, 22 Dec 2007, Jeff Garzik wrote: > Patch does not apply to 2.6.24-rc. > > Was this "bug fix" series meant for 2.6.25? > > Jeff > > > > > -- 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: "ip neigh show" not showing arp cache entries?
On Wed, Dec 19, 2007 at 08:28:49AM -0600, Chris Friesen wrote:
>
> I've included the traces below, they're pretty long. I don't know
> enough about the netlink format to trace the responses, but I did notice
> one interesting thing.
>
> In the "ip neigh show" case the "bond2" entry isn't printed out, but I
> can see the string "bond2" in the recvmsg() call so it looks like the
Actually bond2 isn't in the recvmsg, it's just that strace is
printing out the complete content of the buffer which happenes
to include bond2.
I've verified that the first recvmsg indeed does not contain the
bond2 address at all. Instead of the first 3 IPv4 records it has
3 IPv6 records. So we seem to have a kernel problem here.
However, too many changes have been made in this area since 2.6.14
for it to be worthwhile for me to debug this any further until you
manage to reproduce it with the current kernel.
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: [RFC] potential bugs in nexten
Probably I need to clean up much more junk like that from days before I took over. I recently cleaned up a bit of rx and tx code, which is more frequently executed. The last one (byte swapping) is serious and I am gonna take care of that in next patch. Thanks, -Dhananjay On Sun, 23 Dec 2007, Al Viro wrote: > > * what are default: doing in netxen_nic_hw_write_wx()/netxen_nic_hw_read_wx()? > Unlike all other cases they do iomem->iomem copying and AFAICS they are never > actually triggered. > > * netxen_nic_flash_print() reads the entire user_info from card *in* > *host-endian*, > then uses user_info.serial_number[]. > a) do we need to read the rest? > b) more interesting question, don't we need cpu_to_le32() here? After > all, that sucker is an array of char, so we want it in the same order > regardless > of the host... > > * in netxen_nic_xmit_frame() we do > hw->cmd_desc_head[saved_producer].flags_opcode = > cpu_to_le16(hw->cmd_desc_head[saved_producer].flags_opcode); > hw->cmd_desc_head[saved_producer].num_of_buffers_total_length = > cpu_to_le32(hw->cmd_desc_head[saved_producer]. > num_of_buffers_total_length); > Huh? Everything that modifies either of those does so in little-endian > already. > This code appeared in commit 6c80b18df3537d1221ab34555c150bccbfd90260 (NetXen: > Port swap feature for multi port cards); what's going on there? > > -- 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][NEIGH] Updating affected neighbours when about MAC address change
On Mon, Dec 24, 2007 at 09:50:59AM -0500, jamal wrote:
>
> Herbert, i agree with you that userspace is the best spot for this[1];
> we unfortunately have precedence already on the kernel sending arps with
> bonding when link status changes (that was added recently).
> So it sounds reasonable to have this patch in the kernel as well.
Well just because we've made a mistake in the past does not mean
that we should repeat it over and over again. If we keep doing
this the kernel will soon end up as a whole heap of junk.
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
[RFC] old stuff - Kernel Bug Tracker Bug 7398
Hello!
While looking over the old remaining bugs reported against iproute in
Debian I came across http://bugs.debian.org/394780 which has also been
reported as http://bugzilla.kernel.org/show_bug.cgi?id=7398 (please see
the old comments here).
As there seems to be a question remaining which still hasn't been
answered (read: shot down), I thought I'd try to give this a push a last
time.
The bugs last comment was from Pierre asking about a patch he provided:
> I am sorry, I didn't mean to break anything... What about a sysctl option, to
> give the user the possibility to disable the hack? See attached patch. I can't
> really see any drawback to that. Please review and consider re-opening the
> bug.
The patch (which probably doesn't even apply anymore) is available from
http://andrea.via.ecp.fr/mc-src-strict.patch but also quoted below for
your convenience...
It would be nice to have some comments on this so we can put this issue
to rest without leaving any loose ends.
(Btw, I'm a bit surprised by the comment about backwards compatability
before proper functionality. If this hack has been in the kernel for 11
years, isn't it soon time to say that the applications has been given
enough time to fix their problems and remove it? I thought thats how it
usually worked around here I guess I was wrong.)
diff -urNp linux-2.6.18/Documentation/filesystems/proc.txt
linux-2.6.18/Documentation/filesystems/proc.txt
--- linux-2.6.18/Documentation/filesystems/proc.txt 2006-09-19
20:42:06.0 -0700
+++ linux-2.6.18/Documentation/filesystems/proc.txt 2006-10-26
05:13:15.0 -0700
@@ -1758,6 +1758,15 @@ max_delay, min_delay
Delays for flushing the routing cache.
+mc_src_strict
+-
+
+There is a hack in the kernel router which provides compatibility for old
+multicast applications such as vic, vat and friends. Unfortunately, this
+hack also breaks normal behavior of preferred source address selection
+(iproute2 "src" field) with multicast and limited broadcast. Enabling this
+option disables this hack and restores normal (strict) behavior.
+
redirect_load, redirect_number
--
diff -urNp linux-2.6.18/include/linux/sysctl.h
linux-2.6.18/include/linux/sysctl.h
--- linux-2.6.18/include/linux/sysctl.h 2006-09-19 20:42:06.0 -0700
+++ linux-2.6.18/include/linux/sysctl.h 2006-10-26 04:25:00.0 -0700
@@ -433,6 +433,7 @@ enum {
NET_IPV4_ROUTE_MIN_ADVMSS=17,
NET_IPV4_ROUTE_SECRET_INTERVAL=18,
NET_IPV4_ROUTE_GC_MIN_INTERVAL_MS=19,
+ NET_IPV4_ROUTE_MC_SRC_STRICT=20,
};
enum
diff -urNp linux-2.6.18/net/ipv4/route.c linux-2.6.18/net/ipv4/route.c
--- linux-2.6.18/net/ipv4/route.c 2006-09-19 20:42:06.0 -0700
+++ linux-2.6.18/net/ipv4/route.c 2006-10-26 05:11:00.0 -0700
@@ -132,6 +132,7 @@ static int ip_rt_mtu_expires= 10 * 60
static int ip_rt_min_pmtu = 512 + 20 + 20;
static int ip_rt_min_advmss= 256;
static int ip_rt_secret_interval = 10 * 60 * HZ;
+static int ip_rt_mc_src_strict = 0;
static unsigned long rt_deadline;
#define RTprint(a...) printk(KERN_DEBUG a)
@@ -2416,7 +2417,7 @@ static int ip_route_output_slow(struct r
of another iface. --ANK
*/
- if (oldflp->oif == 0
+ if (!ip_rt_mc_src_strict && oldflp->oif == 0
&& (MULTICAST(oldflp->fl4_dst) || oldflp->fl4_dst ==
0x)) {
/* Special hack: user can direct multicasts
and limited broadcast via necessary interface
@@ -2431,6 +2432,12 @@ static int ip_route_output_slow(struct r
cannot know, that ttl is zero, so that packet
will not leave this host and route is valid).
Luckily, this hack is good workaround.
+
+ Unfortunately, it also breaks normal behavior of
+ source address preference, so I added a sysctl option
+ to let the user disable this hack and restore normal
+ behavior. By default, the hack is still enabled (old
+ compatibility behavior). -- PY
*/
fl.oif = dev_out->ifindex;
@@ -3057,6 +3064,15 @@ ctl_table ipv4_route_table[] = {
.proc_handler = &proc_dointvec_jiffies,
.strategy = &sysctl_jiffies,
},
+ {
+ .ctl_name = NET_IPV4_ROUTE_MC_SRC_STRICT,
+ .procname = "mc_src_strict",
+ .data = &ip_rt_mc_src_strict,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &ipv4_doint_and_flush,
+ .strategy = &ipv4_doint_and_flush_strategy,
+ },
{ .ctl_name = 0
Re: [XFRM]: Fix outbound statistics.
From: Masahide NAKAMURA <[EMAIL PROTECTED]> Date: Fri, 21 Dec 2007 23:25:00 +0900 > Hello David, > > I'm sorry, the previous mail contains wrong code: ... > Please apply the below patch instead of the previous. > > Signed-off-by: Masahide NAKAMURA <[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 net-2.6.25 2/2][NETNS] net: Add a helper function neigh_param_default_alloc
From: Eric.W.Biederman" <[EMAIL PROTECTED]>"@fr.ibm.com Date: Fri, 21 Dec 2007 14:02:25 +0100 > In the presence of multiple network namespaces the logic needed > to allocate the a default parameter table is just barely non-trivial. > So add a function to automate it to make everyone's life easier. > > Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> > Signed-off-by: Daniel Lezcano <[EMAIL PROTECTED]> Please submit this patch with the patch set that starts to use the new interface. There is no need to add it now, 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 net-2.6.25 1/2][NETNS] net: Modify the neighbour table code so it handles multiple network namespaces
From: Eric.W.Biederman" <[EMAIL PROTECTED]>"@fr.ibm.com Date: Fri, 21 Dec 2007 14:02:24 +0100 > I'm actually surprised at how much was involved. At first glance it appears > that the neighbour table data structures are already split by network device > so all that should be needed is to modify the user interface commands > to filter the set of neighbours by the network namespace of their devices. > > However a couple things turned up while I was reading through the code. > The proxy neighbour table allows entries with no network device, and > the neighbour parms are per network device (except for the defaults) > so they now need a per network namespace default. > > So I updated the two structures (which surprised me) with their very > own network namespace parameter. Updated the relevant lookup and > destroy routines with a network namespace parameter and modified > the code that interacts with users to filter out neighbour > table entries for devices of other namespaces. > > I'm a little concerned that we can modify and display the global > table configuration and from all network namespaces. But > this appears good enough for now. > > I keep thinking modifying the neighbour table to have per network > namespace instances of each table type would should be cleaner. The > hash table is already dynamically sized so there are it is not a limiter. > The default parameter would be straight forward to take care of. However > when I look at the how the network table is built and used I still find > some assumptions that there is only a single neighbour table for each > type of table in the kernel. The netlink operations, neigh_seq_start, > the non-core network users that call neigh_lookup. So while it might > be doable it would require more refactoring than my current approach > of just doing a little extra filtering in the code. > > Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> > Signed-off-by: Daniel Lezcano <[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: Strange Panic (Deadlock)
[EMAIL PROTECTED] wrote, On 12/24/2007 07:18 PM: > Hello again. > Its bug depend to > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4aae07025265151e3f7041dfbf0f529e122de1d8 > ? Hello Vyacheslav! I wonder why do you think there is such a dependency, and why do you report timer.c bug to netdev after all? I added some CCs here, but IMHO you would better open a new bug at bugzilla.kernel.org, adding some more details like .config, and reply back to this thread with the bug's number. BTW, if it's patched by Gentoo or otherwise, you should try and report on 'vanilla' one only. Regards, Jarek P. > Its very critical bug to us. This PC must be HA. Server place so far > for me to go and reboot server. I go to it 1-3 times in week =( > Please help to fix it =) > >> Hello all. Some time machine freeze. No information on monitor. No >> rebooting on sysctl "kernel.panic". >> Any idea? >> >> Catched by netconsole: >> [91922.085864] [ cut here ] >> [91922.085975] kernel BUG at kernel/timer.c:606! >> [91922.086058] invalid opcode: [#1] >> [91922.086127] SMP >> [91922.086201] Modules linked in: netconsole cls_u32 sch_sfq sch_htb >> xt_tcpudp iptable_filter ip_tables x_tables i2c_i801 i2c_core >> [91922.086386] CPU:1 >> [91922.086387] EIP:0060:[]Not tainted VLI >> [91922.086389] EFLAGS: 00010087 (2.6.23-gentoo-r4-fw #4) >> [91922.086600] EIP is at cascade+0x34/0x4f >> [91922.086669] eax: c0452200 ebx: f450408c ecx: 0022 edx: f3c6e08c >> [91922.086740] esi: 0022 edi: c21ce000 ebp: 0001 esp: c21c3ef8 >> [91922.086815] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 >> [91922.086885] Process swapper (pid: 0, ti=c21c2000 task=c21af000 >> task.ti=c21c2000) >> [91922.086954] Stack: f3c6e08c c21bfb74 c21ce000 000a >> c012767a c21af000 0001 >> [91922.087119]c21c3f18 c0106963 c21c3f68 0001 0021 >> c03c0b08 000a c0124556 >> [91922.087285]0046 c21c2008 c01245ec >> c2015120 c0114a11 0046 >> [91922.087451] Call Trace: >> [91922.087586] [] run_timer_softirq+0x51/0x154 >> [91922.087669] [] profile_pc+0x21/0x46 >> [91922.087752] [] __do_softirq+0x5d/0xc1 >> [91922.087833] [] do_softirq+0x32/0x36 >> [91922.087915] [] smp_apic_timer_interrupt+0x74/0x80 >> [91922.087997] [] apic_timer_interrupt+0x28/0x30 >> [91922.088076] [] mwait_idle_with_hints+0x3b/0x3f >> [91922.088162] [] mwait_idle+0x0/0xa >> [91922.088237] [] cpu_idle+0x91/0xaa >> [91922.088319] === >> [91922.088390] Code: 08 8d 04 ca 8b 10 89 62 04 89 14 24 8b 50 04 89 22 >> 89 00 89 54 24 04 8b 14 24 89 40 04 8b 1a eb 19 8b 42 14 83 e0 fe 39 f8 >> 74 04 <0f> 0b eb fe 89 f8 e8 d8 fe ff ff 89 da 8b 1b 39 e2 75 e3 59 89 >> [91922.088864] EIP: [] cascade+0x34/0x4f SS:ESP 0068:c21c3ef8 >> >> -- >> 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 >> >> > > > > > This message was sent using IMP, the Internet Messaging Program. > > -- > 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 > -- 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] skge csum problems
On Mon, 24 Dec 2007 18:39:50 +
Al Viro <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 24, 2007 at 02:15:40PM +0100, Andi Kleen wrote:
> > Al Viro <[EMAIL PROTECTED]> writes:
> > >
> > > Checksum is fixed-endian and we want it that way; IOW, what we end up
> > > storing in skb->csum should be fixed-endian as well.
> >
> > AFAIK skb->csum is always native endian because it normally
> > needs to be manipulated further even for RX.
>
> No. It needs to be manipulated, but that's exactly why it can't be
> (and isn't) kept host-endian. Large part of the reason why checksums are
> done the way they are done (operations mod 0x, etc.) is that
> they can be implemented via native arithmetics without any conversions;
> e.g. if you do
>
> add(u8 a[2], u8 b[2], u8 sum[2])
> {
> u32 x = *(u16 *)a + *(u16 *)b;
> if (x > 0x)
> x -= 0x;
> *(u16 *)sum = x;
> }
>
> you will get the same behaviour on big- and little-endian boxen, even though
> the intermediate integer values will be of course different.
>
> skb->csum *must* be stored in the same order on l-e and b-e boxen; that
> way you don't need to convert it or raw data when updating the sucker [*].
>
> [*] it's slightly more complicated since skb->csum is 4-byte, not 2-byte
> and the real invariant is "checksum of 4-octet array at &skb->csum must
> not depend on host" (so e.g XX YY 00 00 and 00 00 XX YY are equivalent -
> checksum doesn't change from reordering octet pairs; XX YY 00 00 and
> 00 00 YY XX are very definitely *NOT* equivalent; odd and even bytes
> can't be exchanged).
Did you test this on real hardware?
--
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] skge csum problems
On Mon, Dec 24, 2007 at 11:36:38AM -0800, Stephen Hemminger wrote: > > you will get the same behaviour on big- and little-endian boxen, even though > > the intermediate integer values will be of course different. > > > > skb->csum *must* be stored in the same order on l-e and b-e boxen; that > > way you don't need to convert it or raw data when updating the sucker [*]. > > > > [*] it's slightly more complicated since skb->csum is 4-byte, not 2-byte > > and the real invariant is "checksum of 4-octet array at &skb->csum must > > not depend on host" (so e.g XX YY 00 00 and 00 00 XX YY are equivalent - > > checksum doesn't change from reordering octet pairs; XX YY 00 00 and > > 00 00 YY XX are very definitely *NOT* equivalent; odd and even bytes > > can't be exchanged). > > Did you test this on real hardware? Test _what_ on real hardware? That kernel expects skb->csum fixed-endian? That csum_add() and friends work? Yes to both. If you are asking whether I'd tested what skge does to csum in its rx descriptors when asked to byteswap - as I've said, all skge-handled stuff I have is on-board in little-endian boxen. Thus asking for folks who could test it on big-endian and see what does that sucker actually do... -- 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] skge csum problems
On Mon, Dec 24, 2007 at 02:15:40PM +0100, Andi Kleen wrote:
> Al Viro <[EMAIL PROTECTED]> writes:
> >
> > Checksum is fixed-endian and we want it that way; IOW, what we end up
> > storing in skb->csum should be fixed-endian as well.
>
> AFAIK skb->csum is always native endian because it normally
> needs to be manipulated further even for RX.
No. It needs to be manipulated, but that's exactly why it can't be
(and isn't) kept host-endian. Large part of the reason why checksums are
done the way they are done (operations mod 0x, etc.) is that
they can be implemented via native arithmetics without any conversions;
e.g. if you do
add(u8 a[2], u8 b[2], u8 sum[2])
{
u32 x = *(u16 *)a + *(u16 *)b;
if (x > 0x)
x -= 0x;
*(u16 *)sum = x;
}
you will get the same behaviour on big- and little-endian boxen, even though
the intermediate integer values will be of course different.
skb->csum *must* be stored in the same order on l-e and b-e boxen; that
way you don't need to convert it or raw data when updating the sucker [*].
[*] it's slightly more complicated since skb->csum is 4-byte, not 2-byte
and the real invariant is "checksum of 4-octet array at &skb->csum must
not depend on host" (so e.g XX YY 00 00 and 00 00 XX YY are equivalent -
checksum doesn't change from reordering octet pairs; XX YY 00 00 and
00 00 YY XX are very definitely *NOT* equivalent; odd and even bytes
can't be exchanged).
--
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: Strange Panic (Deadlock)
Hello again. Its bug depend to http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4aae07025265151e3f7041dfbf0f529e122de1d8 ? Its very critical bug to us. This PC must be HA. Server place so far for me to go and reboot server. I go to it 1-3 times in week =( Please help to fix it =) Hello all. Some time machine freeze. No information on monitor. No rebooting on sysctl "kernel.panic". Any idea? Catched by netconsole: [91922.085864] [ cut here ] [91922.085975] kernel BUG at kernel/timer.c:606! [91922.086058] invalid opcode: [#1] [91922.086127] SMP [91922.086201] Modules linked in: netconsole cls_u32 sch_sfq sch_htb xt_tcpudp iptable_filter ip_tables x_tables i2c_i801 i2c_core [91922.086386] CPU:1 [91922.086387] EIP:0060:[]Not tainted VLI [91922.086389] EFLAGS: 00010087 (2.6.23-gentoo-r4-fw #4) [91922.086600] EIP is at cascade+0x34/0x4f [91922.086669] eax: c0452200 ebx: f450408c ecx: 0022 edx: f3c6e08c [91922.086740] esi: 0022 edi: c21ce000 ebp: 0001 esp: c21c3ef8 [91922.086815] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 [91922.086885] Process swapper (pid: 0, ti=c21c2000 task=c21af000 task.ti=c21c2000) [91922.086954] Stack: f3c6e08c c21bfb74 c21ce000 000a c012767a c21af000 0001 [91922.087119]c21c3f18 c0106963 c21c3f68 0001 0021 c03c0b08 000a c0124556 [91922.087285]0046 c21c2008 c01245ec c2015120 c0114a11 0046 [91922.087451] Call Trace: [91922.087586] [] run_timer_softirq+0x51/0x154 [91922.087669] [] profile_pc+0x21/0x46 [91922.087752] [] __do_softirq+0x5d/0xc1 [91922.087833] [] do_softirq+0x32/0x36 [91922.087915] [] smp_apic_timer_interrupt+0x74/0x80 [91922.087997] [] apic_timer_interrupt+0x28/0x30 [91922.088076] [] mwait_idle_with_hints+0x3b/0x3f [91922.088162] [] mwait_idle+0x0/0xa [91922.088237] [] cpu_idle+0x91/0xaa [91922.088319] === [91922.088390] Code: 08 8d 04 ca 8b 10 89 62 04 89 14 24 8b 50 04 89 22 89 00 89 54 24 04 8b 14 24 89 40 04 8b 1a eb 19 8b 42 14 83 e0 fe 39 f8 74 04 <0f> 0b eb fe 89 f8 e8 d8 fe ff ff 89 da 8b 1b 39 e2 75 e3 59 89 [91922.088864] EIP: [] cascade+0x34/0x4f SS:ESP 0068:c21c3ef8 -- 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 This message was sent using IMP, the Internet Messaging Program. -- 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] [IPROUTE2] IPT action compatibility with iptables 1.4.0
On Mon, 2007-24-12 at 09:48 -0800, Stephen Hemminger wrote: > On Mon, 24 Dec 2007 11:55:05 -0500 > Is this backwards compatible with older kernels? Yes. Denys change adds forward compat (although iptables in 1.4 is not fully backward compatible). cheers, jamal -- 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] [IPROUTE2] IPT action compatibility with iptables 1.4.0
On Mon, 24 Dec 2007 11:55:05 -0500 jamal <[EMAIL PROTECTED]> wrote: > > Stephen, > > Please apply this patch from Denys Fedoryshchenko to make the ipt action > work with latest iptables. > > cheers, > jamal > Is this backwards compatible with older kernels? -- 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] [IPROUTE2] Compatibility with iptables 1.4.0
I just submitted a tested, slightly reduced patch (example we dont need to register matches) and it works as expected now. Thanks for the excellent work Denys. Pablo, below looks an oversight. I think there are some libraries like the mark target need also to be backward compatible. cheers, jamal On Mon, 2007-24-12 at 11:30 -0500, jamal wrote: > Grr. I tested with a different iptables target and thought the rest work > in the same manner. iptables needs to be consistent. > > - > lilsol:~# export IPTABLES_LIB_DIR=/root/iptables-1.4.0/extensions/ > lilsol:~# tc actions add action ipt -j TOS --set-tos > Maximize-Reliability > tablename: mangle hook: NF_IP_POST_ROUTING > target: TOS set Maximize-Reliability index 0 > lilsol:~# tc actions ls action ipt > > action order 0: tablename: mangle hook: NF_IP_POST_ROUTING > target TOS set Maximize-Reliability > index 2 ref 1 bind 0 > // the above is what i tested > // below is what you did > lilsol:~# tc actions add action ipt -j mark --set-mark 3 > /root/iptables-1.4.0/extensions/: cannot read file data: Is a directory > failed to find target mark > > bad action parsing > parse_action: bad value (5:ipt)! > Illegal "action" > Command "add" is unknown, try "tc actions help". > lilsol:~# > > > Applying your patch > Seems corrupt; let me fix it up, test it and resend it to Stephen. > > cheers, > jamal > -- 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] [IPROUTE2] IPT action compatibility with iptables 1.4.0
Stephen,
Please apply this patch from Denys Fedoryshchenko to make the ipt action
work with latest iptables.
cheers,
jamal
New iptables 1.4.0 has some library names changed from libipt to libxt.
It is prefferable also to open libxt_ first, as newer "style".
Signed-off-by: Denys Fedoryshchenko <[EMAIL PROTECTED]>
Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>
---
commit fe7b0dd9c19451019494d834c631c045e75e2b05
tree 452a75a6ec17d63832b03972ec9059b5cf9d8cfe
parent 235ac6a41d9d0439cce4eca8acdd31cac28605fc
author Denys Fedoryshchenko <[EMAIL PROTECTED]> Mon, 24 Dec 2007 11:51:11 -0500
committer Jamal Hadi Salim <[EMAIL PROTECTED]> Mon, 24 Dec 2007 11:51:11 -0500
tc/m_ipt.c | 24 ++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/tc/m_ipt.c b/tc/m_ipt.c
index acbb8d2..f2a9305 100644
--- a/tc/m_ipt.c
+++ b/tc/m_ipt.c
@@ -69,6 +69,13 @@ register_target(struct iptables_target *me)
}
void
+xtables_register_target(struct iptables_target *me)
+{
+ me->next = t_list;
+ t_list = me;
+}
+
+void
exit_tryhelp(int status)
{
fprintf(stderr, "Try `%s -h' or '%s --help' for more information.\n",
@@ -248,11 +255,24 @@ get_target_name(const char *name)
}
}
- sprintf(path, "%s/libipt_%s.so",lib_dir, new_name);
+ /* try libxt_xx first */
+ sprintf(path, "%s/libxt_%s.so", lib_dir, new_name);
handle = dlopen(path, RTLD_LAZY);
if (!handle) {
- sprintf(path, lib_dir, "/libipt_%s.so", lname);
+ /* try libipt_xx next */
+ sprintf(path, "%s/libipt_%s.so", lib_dir, new_name);
handle = dlopen(path, RTLD_LAZY);
+
+ if (!handle) {
+ sprintf(path, "%s/libxt_%s.so", lib_dir , lname);
+ handle = dlopen(path, RTLD_LAZY);
+ }
+
+ if (!handle) {
+ sprintf(path, "%s/libipt_%s.so", lib_dir , lname);
+ handle = dlopen(path, RTLD_LAZY);
+ }
+ /* ok, lets give up .. */
if (!handle) {
fputs(dlerror(), stderr);
printf("\n");
Re: [PATCH] [IPROUTE2] Compatibility with iptables 1.4.0
On Mon, 2007-24-12 at 18:07 +0200, Denys Fedoryshchenko wrote: > Hi, probably like this will be better? > Previous patch was not backward compatible. > > Btw i checked twice, name is changed from libipt_MARK to libxt_MARK. So > probably when you have tested this, your iproute2 was looking to old > libipt_MARK (iptables is not deleting old libraries on make install). > Grr. I tested with a different iptables target and thought the rest work in the same manner. iptables needs to be consistent. - lilsol:~# export IPTABLES_LIB_DIR=/root/iptables-1.4.0/extensions/ lilsol:~# tc actions add action ipt -j TOS --set-tos Maximize-Reliability tablename: mangle hook: NF_IP_POST_ROUTING target: TOS set Maximize-Reliability index 0 lilsol:~# tc actions ls action ipt action order 0: tablename: mangle hook: NF_IP_POST_ROUTING target TOS set Maximize-Reliability index 2 ref 1 bind 0 // the above is what i tested // below is what you did lilsol:~# tc actions add action ipt -j mark --set-mark 3 /root/iptables-1.4.0/extensions/: cannot read file data: Is a directory failed to find target mark bad action parsing parse_action: bad value (5:ipt)! Illegal "action" Command "add" is unknown, try "tc actions help". lilsol:~# Applying your patch Seems corrupt; let me fix it up, test it and resend it to Stephen. cheers, jamal -- 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] [IPROUTE2] Compatibility with iptables 1.4.0
Hi, probably like this will be better?
Previous patch was not backward compatible.
Btw i checked twice, name is changed from libipt_MARK to libxt_MARK. So
probably when you have tested this, your iproute2 was looking to old
libipt_MARK (iptables is not deleting old libraries on make install).
-
New iptables 1.4.0 need additional dummy functions, and some library names is
changed from libipt to libxt.
It is prefferable also to open libxt_ first, as newer "style".
Signed-off-by: Denys Fedoryshchenko <[EMAIL PROTECTED]>
---
drivers/watchdog/w83697hf_wdt.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff -Naur iproute2/tc/m_ipt.c iproute2-new/tc/m_ipt.c
--- iproute2/tc/m_ipt.c 2007-12-24 16:59:19.0 +0200
+++ iproute2-new/tc/m_ipt.c 2007-12-24 17:46:14.0 +0200
@@ -69,6 +69,27 @@
}
void
+xtables_register_target(struct iptables_target *me)
+{
+ me->next = t_list;
+ t_list = me;
+}
+
+
+void
+xtables_register_match(struct iptables_target *me)
+{
+ me->next = t_list;
+ t_list = me;
+}
+
+void
exit_tryhelp(int status)
{
fprintf(stderr, "Try `%s -h' or '%s --help' for more information.\n",
@@ -248,16 +269,25 @@
}
}
- sprintf(path, "%s/libipt_%s.so",lib_dir, new_name);
+ sprintf(path, "%s/libxt_%s.so",lib_dir, new_name);
handle = dlopen(path, RTLD_LAZY);
if (!handle) {
- sprintf(path, lib_dir, "/libipt_%s.so", lname);
+ sprintf(path, "%s/libipt_%s.so", lib_dir , new_name);
handle = dlopen(path, RTLD_LAZY);
- if (!handle) {
- fputs(dlerror(), stderr);
- printf("\n");
- return NULL;
- }
+ }
+ if (!handle) {
+ sprintf(path, "%s/libxt_%s.so", lib_dir , lname);
+ handle = dlopen(path, RTLD_LAZY);
+ }
+ if (!handle) {
+ sprintf(path, "%s/libipt_%s.so", lib_dir , lname);
+ handle = dlopen(path, RTLD_LAZY);
+ }
+ if (!handle) {
+ sprintf(path, "%s/libipt_%s.so", lib_dir , lname);
+ fputs(dlerror(), stderr);
+ printf("\n");
+ return NULL;
}
m = dlsym(handle, new_name);
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
--
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: iproute2 action ipt + iptables 1.4.0
Denys,
Looks reasonable to check for libxt as well.
Please add a signed-off and append mine as well then send to Stephen.
BTW, I just finished compiling iptables 1.4.0 and _it is_ backward
compatible - you just have to point to the correct
environment variable IPTABLES_LIB_DIR; it seems to work.
In any case, your patch is better.
cheers,
jamal
On Mon, 2007-24-12 at 17:11 +0200, Denys Fedoryshchenko wrote:
> Hi again :-)
>
> Happy holidays :-)
>
> It seems there is serious break in compatibility, but can be fixed by ugly
> way. Maybe just to add patch below, and to search libipt AND libxt (for my
> case i just edit and change libipt to libxt, but it can be handled in more
> smart way.
> After i apply all this - it seems working fine.
>
> iff -Naur iproute2-git/tc/m_ipt.c iproute2-new/tc/m_ipt.c
> --- iproute2-git/tc/m_ipt.c 2007-12-24 16:59:19.0 +0200
> +++ iproute2-new/tc/m_ipt.c 2007-12-24 17:07:11.0 +0200
> @@ -69,6 +69,27 @@
> }
>
> void
> +xtables_register_target(struct iptables_target *me)
> +{
> +/* fprintf(stderr, "\nDummy register_target %s \n", me->name);
> +*/
> + me->next = t_list;
> + t_list = me;
> +
> +}
> +
> +
> +void
> +xtables_register_match(struct iptables_target *me)
> +{
> +/* fprintf(stderr, "\nDummy register_target %s \n", me->name);
> +*/
> + me->next = t_list;
> + t_list = me;
> +
> +}
> +
> +void
> exit_tryhelp(int status)
> {
> fprintf(stderr, "Try `%s -h' or '%s --help' for more information.\n",
>
> There is trivial patch also, for bug (IMHO bug) in searching lowercased
> library. If patch not applied - second time it will try to open lib_dir by
> dlopen:-)
>
> --- iproute2-git/tc/m_ipt.c 2007-12-24 16:59:19.0 +0200
> +++ iproute2/tc/m_ipt.c 2007-12-24 17:00:41.0 +0200
> @@ -251,7 +251,7 @@
> sprintf(path, "%s/libipt_%s.so",lib_dir, new_name);
> handle = dlopen(path, RTLD_LAZY);
> if (!handle) {
> - sprintf(path, lib_dir, "/libipt_%s.so", lname);
> + sprintf(path, "%s/libipt_%s.so", lib_dir , lname);
> handle = dlopen(path, RTLD_LAZY);
> if (!handle) {
> fputs(dlerror(), stderr);
>
> Sorry for probably bad style/code, i am not programmer at all.
>
>
> --
> Denys Fedoryshchenko
> Technical Manager
> Virtual ISP S.A.L.
>
> --
> 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
--
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
iproute2 action ipt + iptables 1.4.0
Hi again :-)
Happy holidays :-)
It seems there is serious break in compatibility, but can be fixed by ugly
way. Maybe just to add patch below, and to search libipt AND libxt (for my
case i just edit and change libipt to libxt, but it can be handled in more
smart way.
After i apply all this - it seems working fine.
iff -Naur iproute2-git/tc/m_ipt.c iproute2-new/tc/m_ipt.c
--- iproute2-git/tc/m_ipt.c 2007-12-24 16:59:19.0 +0200
+++ iproute2-new/tc/m_ipt.c 2007-12-24 17:07:11.0 +0200
@@ -69,6 +69,27 @@
}
void
+xtables_register_target(struct iptables_target *me)
+{
+/* fprintf(stderr, "\nDummy register_target %s \n", me->name);
+*/
+ me->next = t_list;
+ t_list = me;
+
+}
+
+
+void
+xtables_register_match(struct iptables_target *me)
+{
+/* fprintf(stderr, "\nDummy register_target %s \n", me->name);
+*/
+ me->next = t_list;
+ t_list = me;
+
+}
+
+void
exit_tryhelp(int status)
{
fprintf(stderr, "Try `%s -h' or '%s --help' for more information.\n",
There is trivial patch also, for bug (IMHO bug) in searching lowercased
library. If patch not applied - second time it will try to open lib_dir by
dlopen:-)
--- iproute2-git/tc/m_ipt.c 2007-12-24 16:59:19.0 +0200
+++ iproute2/tc/m_ipt.c 2007-12-24 17:00:41.0 +0200
@@ -251,7 +251,7 @@
sprintf(path, "%s/libipt_%s.so",lib_dir, new_name);
handle = dlopen(path, RTLD_LAZY);
if (!handle) {
- sprintf(path, lib_dir, "/libipt_%s.so", lname);
+ sprintf(path, "%s/libipt_%s.so", lib_dir , lname);
handle = dlopen(path, RTLD_LAZY);
if (!handle) {
fputs(dlerror(), stderr);
Sorry for probably bad style/code, i am not programmer at all.
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
--
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
Strange Panic (Deadlock)
Hello all. Some time machine freeze. No information on monitor. No rebooting on sysctl "kernel.panic". Any idea? Catched by netconsole: [91922.085864] [ cut here ] [91922.085975] kernel BUG at kernel/timer.c:606! [91922.086058] invalid opcode: [#1] [91922.086127] SMP [91922.086201] Modules linked in: netconsole cls_u32 sch_sfq sch_htb xt_tcpudp iptable_filter ip_tables x_tables i2c_i801 i2c_core [91922.086386] CPU:1 [91922.086387] EIP:0060:[]Not tainted VLI [91922.086389] EFLAGS: 00010087 (2.6.23-gentoo-r4-fw #4) [91922.086600] EIP is at cascade+0x34/0x4f [91922.086669] eax: c0452200 ebx: f450408c ecx: 0022 edx: f3c6e08c [91922.086740] esi: 0022 edi: c21ce000 ebp: 0001 esp: c21c3ef8 [91922.086815] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 [91922.086885] Process swapper (pid: 0, ti=c21c2000 task=c21af000 task.ti=c21c2000) [91922.086954] Stack: f3c6e08c c21bfb74 c21ce000 000a c012767a c21af000 0001 [91922.087119]c21c3f18 c0106963 c21c3f68 0001 0021 c03c0b08 000a c0124556 [91922.087285]0046 c21c2008 c01245ec c2015120 c0114a11 0046 [91922.087451] Call Trace: [91922.087586] [] run_timer_softirq+0x51/0x154 [91922.087669] [] profile_pc+0x21/0x46 [91922.087752] [] __do_softirq+0x5d/0xc1 [91922.087833] [] do_softirq+0x32/0x36 [91922.087915] [] smp_apic_timer_interrupt+0x74/0x80 [91922.087997] [] apic_timer_interrupt+0x28/0x30 [91922.088076] [] mwait_idle_with_hints+0x3b/0x3f [91922.088162] [] mwait_idle+0x0/0xa [91922.088237] [] cpu_idle+0x91/0xaa [91922.088319] === [91922.088390] Code: 08 8d 04 ca 8b 10 89 62 04 89 14 24 8b 50 04 89 22 89 00 89 54 24 04 8b 14 24 89 40 04 8b 1a eb 19 8b 42 14 83 e0 fe 39 f8 74 04 <0f> 0b eb fe 89 f8 e8 d8 fe ff ff 89 da 8b 1b 39 e2 75 e3 59 89 [91922.088864] EIP: [] cascade+0x34/0x4f SS:ESP 0068:c21c3ef8 -- 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][NEIGH] Updating affected neighbours when about MAC address change
On Mon, 2007-24-12 at 15:38 +0200, David Shwatrz wrote: > Hello, > > First, it indeed can be handled by user space. (even though it should > be done twice, once for ifconig of net-tools and once for ip of > iproute2) it needs to be done once only: reacting to netlink events when MAC address changes. > / However, we have already > methods which deal with bringing down an interface - neigh_ifdown(), > and changing MAC address of an interface (neigh_changeaddr). So why > not do it from the kernel ? Herbert, i agree with you that userspace is the best spot for this[1]; we unfortunately have precedence already on the kernel sending arps with bonding when link status changes (that was added recently). So it sounds reasonable to have this patch in the kernel as well. cheers, jamal [1] Things like these tend to be very policy rich and thats why user space is the best spot for them. I have infact implemented this feature in user space in some random box i have where i failover MACs for HA reasons. Depending on how much traffic there is on the wire, arps do get dropped. One of the hardest things to decide on was how many times to retry the grat arp sending and what the timeout would be between each sent gratarp. The earlier patch posted didnt consider this but would be nice to have a couple of sysctls to add the two parameters if this makes it in. -- 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][NEIGH] Updating affected neighbours when about MAC address change
On Sun, 2007-23-12 at 08:17 -0500, jamal wrote: > On Sun, 2007-23-12 at 22:04 +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: > > > If the secondary MACs are used with ARP/NDP, we should take care of > > that, but I think we use the primary MAC for ARP/NDP, no? > > (In other words, we always use primary MAC for ARP reply / NA, no?) > > I think it maybe a policy decision; Never mind, that was my body being in a different time zone. I went back and looked at a little chat i had with Patrick when he posted with the macvlan driver. At the moment we are still maintaining the model that a NIC can _only_ appear to have a single MAC to the upper layers. IOW, you have to instantiate a macvlan device for each of the 16 MAC addresses on the e1000 if you need to expose them. This means that the ip layer - even with multiple ip addresses will only ever see one MAC address. Note also: The name macvlan is a little misleading since it allows for the above without need for vlans. cheers, jamal -- 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: iproute2 action ipt + iptables 1.4.0
On Mon, 2007-24-12 at 11:31 +0200, Denys Fedoryshchenko wrote: > Seems latest iproute2(even from GIT) searching for libipt_MARK (for example), > while it is libxt_MARK. It seems that iptables broke backward compatibility. > Even if i correct names it will be still not functional > "undefined symbol: xtables_register_target" > > Probably some other issues actual with new version of iptables libraries? Yes. We do depend on libipt and expect the libraries to be in some environment variable IPTABLES_LIB_DIR/libipt_%s by default (if environment variable IPTABLES_LIB_DIR is not defined) we look in /usr/local/lib/iptables in iproute2 we also need to copy over headers into include/libiptc Pablo - can we not have a backward compat mode to avoid these hassles? cheers, jamal -- 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: ipv4_devconf.arp_accept mystery
Hello,
>As the name suggests you should use
> /proc/sys/net/ipv4/conf/all/arp_accept
Thanks. This is indeed true.
I first tried with ipv4_devconf.arp_accept, where the name probably
does **not** suggest it; I agree
that for PV4_DEVCONF_ALL() the name indeed suggests it . It just
skipped my eye. I suppose this is true also to
ipv4_devconf.arp_accept.
Rgs,
Ian
On Dec 24, 2007 2:51 PM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> Ian Brown <[EMAIL PROTECTED]> wrote:
> >
> > BTW, in newer kernel version we have IPV4_DEVCONF_ALL(ARP_ACCEPT)
> > instead. So if anybody knows how to set this macro (instead)to be 1, it
> > will be
> > also fine.
>
> As the name suggests you should use
>
> /proc/sys/net/ipv4/conf/all/arp_accept
>
> 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 net-2.6][NEIGH] Updating affected neighbours when about MAC address change
Hello,
First, it indeed can be handled by user space. (even though it should
be done twice, once for ifconig of net-tools and once for ip of
iproute2) / However, we have already
methods which deal with bringing down an interface - neigh_ifdown(),
and changing MAC address of an interface (neigh_changeaddr). So why
not do it from
the kernel ?
DS
On Dec 23, 2007 4:02 PM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> David Shwatrz <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> > Oop, I am TWICE sorry ! I wrongly attached a wrong, empty file.
> > Attached here is the patch.
> >
> > Regarding your answer; I accept it and I will soon send a revised
> > version of this patch (making changes to
> > arp_netdev_event() and ndisc_netdev_event().)
> > I had IPv4 in mind, there is no reason that it will no be also in IPv6.
>
> Hmm, why can't you do this from user-space?
>
> 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: [RFC] skge csum problems
Al Viro <[EMAIL PROTECTED]> writes: > > Checksum is fixed-endian and we want it that way; IOW, what we end up > storing in skb->csum should be fixed-endian as well. AFAIK skb->csum is always native endian because it normally needs to be manipulated further even for RX. -Andi -- 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: ipv4_devconf.arp_accept mystery
Ian Brown <[EMAIL PROTECTED]> wrote:
>
> BTW, in newer kernel version we have IPV4_DEVCONF_ALL(ARP_ACCEPT)
> instead. So if anybody knows how to set this macro (instead)to be 1, it will
> be
> also fine.
As the name suggests you should use
/proc/sys/net/ipv4/conf/all/arp_accept
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
Simple question about network stack
Hi all. Sorry for offtopic. Have problems with balance CPU load in networking. Have 2 Ethernet adapters e1000. Have 8 CPU (4 real). Computer work as Shaper. Use only TC rules to shape and IPTABLES to drop. rx on eth0 go to CPU0. traffic above 400mbs do 90% SI. rx on eth1 go to CPU1. traffic above 400mbs do 90% SI. All other CPUS 100%idle. question: 1. I may balance load to other cpu? I understand that i can't balance polling place, but find in TC and IPTABLES hash may do different cpu? 2. If SI on 1 cpu more then 100% (600mbs traffic) i see strange. SOFTIRQ process do 100%. Traffic bandwidth go from 400mbs to 100 mbs. pings trough computer go from 0.5ms to 100ms. 1 cpu use 100%. All other cpu 100%idle. If traffic down - after some time cpu load again go to different cpu. P.S. Very strange that computer with 4(8) CPU and 1 CPU HT do some network performance. P.P.S Sorry for my English Thanks for answers. Slavon -- 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] skge csum problems
Both variants of skge (drivers/net and drivers/net/sk98lin/ resp.) have the same problem with rx checksums. They pick checksum from rx descriptor and use it as-is. Normally that would be the right thing to do. However, skge is told to byteswap descriptors on big-endian boxen. Checksum is fixed-endian and we want it that way; IOW, what we end up storing in skb->csum should be fixed-endian as well. Unless the card is smart enough to byteswap everything in rx descriptor _except_ the checksum, we have a trouble - we get a value converted to host-endian by the general byteswap in descriptor and we must convert it to fixed-endian ourselves. FWIW, FreeBSD sk_if sidesteps that mess by not telling the card to byteswap, so that's not too informative. Datasheet on http://people.freebsd.org/~wpaul/SysKonnect/xmacii_datasheet_rev_c_9-29.pdf is not clear on what's going on with checksum in byteswapping mode either... Could somebody with that sucker on a card (all instances I have here are on-board ones in little-endian boxen) test what's really going on for big-endian hosts with either driver? -- 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
iproute2 action ipt + iptables 1.4.0
Seems latest iproute2(even from GIT) searching for libipt_MARK (for example), while it is libxt_MARK. Even if i correct names it will be still not functional "undefined symbol: xtables_register_target" Probably some other issues actual with new version of iptables libraries? -- Denys Fedoryshchenko Technical Manager Virtual ISP S.A.L. -- 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
