On Mon, 26 Mar 2007, Jay Vosburgh wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 26 Mar 2007 21:50:01 -0800 [EMAIL PROTECTED] wrote:
Replace system timer with work queue in monitor functions. The reason for
this change is that bonding handlers calls various sleeping functions
Hi David
Please find this patch against net-2.6.22
Thank you
[PATCH] NET : inet_ehash_secret should be __read_mostly and set only once
There is a very tiny probability that build_ehash_secret() is called at the
same time by different CPUS.
Also, using __read_mostly is a must for
David Miller wrote:
this is a small patch by Janusz Krzysztofik to ip_route_output_slow()
that allows VIP-less LVS linux director to generate packets originating
From VIP if sysctl_ip_nonlocal_bind is set.
Applied to net-2.6.22, thanks Simon.
Thank you,
Janusz
-
To unsubscribe from this
(Let's take it off linux-kernel; I've subscribed to netdev)
YOSHIFUJI Hideaki / 吉藤英明 wrote:
Would you test with latest kernel, if possible, please?
I'll give it a try; however, this might take a couple of days (I have no auth
to replace the kernel on the box :( ).
Cheers,
Agoston
-
To
Hello,
I'm trying to add ipv6 support to the RIPE whois-server. I'm going with the
dual-stack address familiy independent solution (/proc/sys/net/ipv6/bindv6only
is set to 0).
I've written a small piece of code which tests how the server behaves under
heavy load. It basically creates a
Hi James,
James Chapman schrieb:
I thought seq_printf handled large output (multiple pages)? I am aware
of the page size limitation of raw proc handlers.
No. It does detect the limitation, discards your output an lets you try again,
when the next invocation of *_show() has enough buffer
Hello.
(CC: netdev added.)
In article [EMAIL PROTECTED] (at Tue, 27 Mar 2007 11:45:46 +0200), Agoston
Horvath [EMAIL PROTECTED] says:
I'm using kernel 2.6.16.29, libc is 2.3.2.ds1-22sarge5. However, same result
was achieved using kernel version 2.6.13 on the same box.
I'm out of further
Hi Mr. David
I have modified my patch according to you advice. I think -EHOSTUNREACH
is only for input path. In output path, we can just simply check
-ENETUNREACH (^_^), the patch is shown in the end of this mail.
BTW: my E-mail has been changed to [EMAIL PROTECTED]
Function need to
On Mon, Mar 26, 2007 at 11:25:07PM -0700, Jay Vosburgh wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 26 Mar 2007 21:50:01 -0800 [EMAIL PROTECTED] wrote:
Replace system timer with work queue in monitor functions. The reason for
this change is that bonding handlers calls various
Nikolaos D. Bougalis [EMAIL PROTECTED] writes:
I will be more than happy to provide a patch for this, but I figured I
would solicit some input first.
To truly defend against this you would likely need a cryptographic
hash, which would be likely too slow.
If it's a real problem the
On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero ([EMAIL
PROTECTED]) wrote:
I had two python programs, server.py and client.py(attached)
With server.py in a kernel 2.6.21-rc5 x86_64 and client.py in the same
machine, server.py get the message.
With server.py in a kerner
John Heffner [EMAIL PROTECTED] writes:
Add IP(V6)_PMTUDISC_PROBE value for IP(V6)_MTU_DISCOVER. This option forces
us not to fragment, but does not make use of the kernel path MTU discovery.
That is, it allows for user-mode MTU probing (or, packetization-layer path
MTU discovery). This is
The results of FIB rules lookups are cached in the routing cache
except for IPv6 as no such cache exists. So far, it was the
responsibility of the user to flush the cache after modifying any
rules. This lead to many false bug reports due to misunderstanding
of this concept.
This patch
David Miller [EMAIL PROTECTED] writes:
2) An extra list insert/delete to give list of all sockets
That is currently limited by readlock on the hash buckets. I suspect
any change to a trie with less atomic operations will make it faster.
-Andi
-
To unsubscribe from this list: send the line
Hi,
Jean Tourrilhes schrieb:
diff -u -p linux/include/net/iw_handler.j1.h linux/include/net/iw_handler.h
--- linux/include/net/iw_handler.j1.h 2007-03-16 17:36:22.0 -0700
+++ linux/include/net/iw_handler.h2007-03-21 11:01:09.0 -0700
@@ -500,7 +504,11 @@
tcp_memory_pressure and tcp_socket currently share a cache line with
tcp_memory_allocated, tcp_sockets_allocated.
(Very hot cache line)
It makes sense to declare these variables as __read_mostly, to avoid false
sharing on SMP.
8081d9c0 B tcp_orphan_count
8081d9c4 B
On Tue, Mar 27, 2007 at 03:21:59PM +0200, Thomas Graf wrote:
The results of FIB rules lookups are cached in the routing cache
except for IPv6 as no such cache exists. So far, it was the
responsibility of the user to flush the cache after modifying any
rules. This lead to many false bug
On Mon, Mar 26, 2007 at 09:47:25PM -0800, [EMAIL PROTECTED] wrote:
From: Grant Grundler [EMAIL PROTECTED]
IRQs are racing with tulip_down(). DMA can be restarted by the interrupt
handler _after_ we call tulip_stop_rxtx() and the DMA buffers are unmapped.
The result is an MCA (hard crash on
* Muli Ben-Yehuda [EMAIL PROTECTED] 2007-03-27 15:30
That looks like a bug - shouldn't we flush the cache first, then do
the rules_ops_put()?
Good catch, it's unlikely to happen but it is a bug.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Tue, Mar 27, 2007 at 04:23:49PM +0200, Andi Kleen ([EMAIL PROTECTED]) wrote:
2) An extra list insert/delete to give list of all sockets
That is currently limited by readlock on the hash buckets. I suspect
any change to a trie with less atomic operations will make it faster.
The best case
The results of FIB rules lookups are cached in the routing cache
except for IPv6 as no such cache exists. So far, it was the
responsibility of the user to flush the cache after modifying any
rules. This lead to many false bug reports due to misunderstanding
of this concept.
This patch
As IPPROTO_TCP is 6, it makes sense to make sure inet_protos[] array is
properly cache line aligned to avoid false sharing on SMP.
c0680540 b peer_total
c0680544 b inet_peer_unused_head
c0680560 B inet_protos
On i386 this example, we can see that inet_protos[IPPROTO_TCP] shares a
potentially
When looking up route for destination with rules with
source address restrictions, we may need to find a source
address for the traffic if not given.
Based on patch from Noriaki TAKAMIYA [EMAIL PROTECTED].
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
include/linux/fib_rules.h |7
On Thu, 2007-03-08 at 03:59 +, Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c7ababbdc647e67e953d153ddf62cbdc9fe3297e
Commit: c7ababbdc647e67e953d153ddf62cbdc9fe3297e
Parent:
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ [EMAIL PROTECTED] 2007-03-27 22:45
When looking up route for destination with rules with
source address restrictions, we may need to find a source
address for the traffic if not given.
Out of curiosity, what sort of rules would have this flag set?
The majority
El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero
([EMAIL PROTECTED]) wrote:
I had two python programs, server.py and client.py(attached)
With server.py in a kernel 2.6.21-rc5 x86_64 and client.py in the same
James Chapman wrote:
Wouldn't that effectively duplicate the code in udp_sendmsg()? If I
don't use a socket, I'd also have to build an IP header and feed the
frame into the IP stack for outbound routing. It doesn't feel like the
right thing to do.
Thats what other tunnel drivers do. Sending
On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero ([EMAIL
PROTECTED]) wrote:
El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero
([EMAIL PROTECTED]) wrote:
I had two python programs, server.py and
Denys wrote:
Mar 26 21:20:04 ROUTER-75 [ 551.481081] BUG: unable to handle kernel NULL
pointer dereference
Mar 26 21:20:04 ROUTER-75 at virtual address 0074
Mar 26 21:20:04 ROUTER-75 [ 551.481187] printing eip:
Mar 26 21:20:04 ROUTER-75 [ 551.481236] f8a11df1
Mar 26 21:20:04
Yes, correct, i am able to reproduce problem, i was scared i will be not able.
Just when i am killing pppd on server side, flooding interface, it's
happens.
I will try patch in next 30 minutes max.
I have also bug, related to mirred to ifb0 and ethernet checksum offloading,
but maybe it is
Greetings,
I am new to this list. I have a very special question.
I am currently working on a new l2/l3 protocol (just for
research reasons) and i would like to make a test implementation
in the linux kernel.
For this i need to modify the ethernet header and replace it
with my header. The
El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero
([EMAIL PROTECTED]) wrote:
El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero
([EMAIL
On Tue, Mar 27, 2007 at 05:27:42PM +0200, Simba ([EMAIL PROTECTED]) wrote:
I am currently working on a new l2/l3 protocol (just for
research reasons) and i would like to make a test implementation
in the linux kernel.
For this i need to modify the ethernet header and replace it
with my
Hi again
Looks like everything is fine, i will deploy at few NAS today night and will
see if there any issues. Both oops what i gave, is it related to this bug?
No need to dig anything else?
On Tue, 27 Mar 2007 17:10:36 +0200, Patrick McHardy wrote
Denys wrote:
Mar 26 21:20:04 ROUTER-75 [
Denys wrote:
Hi again
Looks like everything is fine, i will deploy at few NAS today night and will
see if there any issues.
Thanks for testing.
Both oops what i gave, is it related to this bug?
Yes, they were both because of the same bug.
-
To unsubscribe from this list: send the line
Fix fallout from my qdisc endless loop fixes. I've checked
all qdiscs, these two should be the only broken ones.
The patch applies to current -git and the last -stable.
[NET_SCHED]: sch_htb/sch_hfsc: fix oops in qlen_notify
During both HTB and HFSC class deletion the class is removed from the
El Martes, 27 de Marzo de 2007, Jose Alberto Reguero escribió:
El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero
([EMAIL PROTECTED]) wrote:
El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
On Mon, Mar
I have some 10gig nics and ethtool is reporting unknown for the speed.
Is there already a patch, or have I found an opportunity? FWIW, the
version five bits from sourceforge still report unknown - are they the
latest or are there later bits somewhere?
thanks,
rick jones
-
To unsubscribe from
Hi David,
Reworked the patches to not use skb_copy_bits, but some new accessors,
namely skb_copy_from_linear_data{_offset}().
Please consider pulling from the usual place:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
Best Regards,
- Arnaldo
-
To unsubscribe from
For consistency with other skb data accessors, reducing the number of direct
accesses to skb-data.
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
drivers/bluetooth/bluecard_cs.c |6 +++---
drivers/bluetooth/bt3c_cs.c |6 +++---
drivers/bluetooth/btuart_cs.c |6
Rick Jones wrote:
I have some 10gig nics and ethtool is reporting unknown for the speed.
Is there already a patch, or have I found an opportunity? FWIW, the
version five bits from sourceforge still report unknown - are they the
latest or are there later bits somewhere?
Nope, patches welcome.
Document new IP_PMTUDISC_PROBE value for IP_MTU_DISCOVERY. (Going into
2.6.22).
Thanks,
-John
diff -rU3 man-pages-2.43-a/man7/ip.7 man-pages-2.43-b/man7/ip.7
--- man-pages-2.43-a/man7/ip.7 2006-09-26 09:54:29.0 -0400
+++ man-pages-2.43-b/man7/ip.7 2007-03-27 15:46:18.0
Hi Jeff,
Here's a last minute fix for myri10ge in 2.6.21. Please apply.
Thanks,
Brice
-
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
Correctly detect when TSO should be used on transmit by looking at the
skb-gso_size rather than seeing if the frame was larger than our MTU.
The old method causes problems when a host with a large (jumbo) MTU is
sending to a host with a small (standard) MTU.
---
drivers/net/myri10ge/myri10ge.c |
Correctly detect when TSO should be used on transmit by looking at the
skb-gso_size rather than seeing if the frame was larger than our MTU.
The old method causes problems when a host with a large (jumbo) MTU is
sending to a host with a small (standard) MTU.
Signed-off-by: Brice Goglin [EMAIL
Jay Cliburn [EMAIL PROTECTED] writes:
We're trying to track down the source of a problem that occurs whenever
the atl1 network driver is activated on a 32-bit 2.6.21-rc4 kernel. We
need help from netdev.
We can load the driver just fine, but whenever we activate the
network, we see APIC
Herbert Xu wrote:
Hi Dave:
[NET]: Allow forwarding of ip_summed except CHECKSUM_COMPLETE
Right now Xen has a horrible hack that lets it forward packets with
partial checksums. One of the reasons that CHECKSUM_PARTIAL and
CHECKSUM_COMPLETE were added is so that we can get rid of this hack
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 12:13:43 +0200
Hi David
Please find this patch against net-2.6.22
Thank you
[PATCH] NET : inet_ehash_secret should be __read_mostly and set only once
There is a very tiny probability that build_ehash_secret() is called at
From: Thomas Graf [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 15:38:45 +0200
The results of FIB rules lookups are cached in the routing cache
except for IPv6 as no such cache exists. So far, it was the
responsibility of the user to flush the cache after modifying any
rules. This lead to many
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 15:25:13 +0200
tcp_memory_pressure and tcp_socket currently share a cache line with
tcp_memory_allocated, tcp_sockets_allocated.
(Very hot cache line)
It makes sense to declare these variables as __read_mostly, to avoid false
David Miller a écrit :
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 12:13:43 +0200
Hi David
Please find this patch against net-2.6.22
Thank you
[PATCH] NET : inet_ehash_secret should be __read_mostly and set only once
There is a very tiny probability that
From: Patrick McHardy [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 18:28:48 +0200
Fix fallout from my qdisc endless loop fixes. I've checked
all qdiscs, these two should be the only broken ones.
The patch applies to current -git and the last -stable.
Applied, thanks Patrick.
-
To unsubscribe from
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 16:41:48 -0300
+static inline void skb_move_linear_data(const struct sk_buff *skb,
+ const int from_offset,
+ const int to_offset,
+
On Tue, Mar 27, 2007 at 10:51:53PM +0200, Patrick McHardy wrote:
Just wondering, how does Xen know whether a packet will be forwarded?
It's up to Linux to handle it correctly.
The input path doesn't seem to deal with CHECKSUM_PARTIAL correctly,
ip_defrag for example resets them to
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 15:47:04 +0200
As IPPROTO_TCP is 6, it makes sense to make sure inet_protos[] array is
properly cache line aligned to avoid false sharing on SMP.
c0680540 b peer_total
c0680544 b inet_peer_unused_head
c0680560 B inet_protos
On
On 3/27/07, David Miller [EMAIL PROTECTED] wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 16:41:48 -0300
+static inline void skb_move_linear_data(const struct sk_buff *skb,
+ const int from_offset,
+
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 18:22:14 -0300
I don't want to intend anything with this, was just a brain fart, a
failed attempt to convince me that this was needed, I apologise for
letting this sleep thru, will remove and resubmit, ok?
Perfect.
-
To
Arnaldo Carvalho de Melo wrote:
On 3/27/07, David Miller [EMAIL PROTECTED] wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 16:41:48 -0300
+static inline void skb_move_linear_data(const struct sk_buff *skb,
+ const int
On 3/27/07, Arnaldo Carvalho de Melo [EMAIL PROTECTED] wrote:
On 3/27/07, David Miller [EMAIL PROTECTED] wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 16:41:48 -0300
+static inline void skb_move_linear_data(const struct sk_buff *skb,
+
On Tue, Mar 27, 2007 at 02:57:18PM +0100, David Woodhouse wrote:
[IPV6]: Do not set IF_READY if device is down
Now that we add the IPv6 device at registration time we don't need
to set IF_READY in ipv6_add_dev anymore because we will always get
a NETDEV_UP event
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 28 Mar 2007 07:30:32 +1000
On Tue, Mar 27, 2007 at 02:57:18PM +0100, David Woodhouse wrote:
[IPV6]: Do not set IF_READY if device is down
Now that we add the IPv6 device at registration time we don't need
to set
On 3/27/07, Patrick McHardy [EMAIL PROTECTED] wrote:
Arnaldo Carvalho de Melo wrote:
On 3/27/07, David Miller [EMAIL PROTECTED] wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 16:41:48 -0300
+static inline void skb_move_linear_data(const struct sk_buff *skb,
Arnaldo Carvalho de Melo wrote:
On 3/27/07, Patrick McHardy [EMAIL PROTECTED] wrote:
nf_nat_helper.c:mangle_content() could make use of this, but it
would need memmove. Something to do this with non-linear packets
would be even cooler :)
Damn, that was so fast man! For the qeth case
Adds an IOCTL for aborting established TCP connections, and is
designed to be an HA performance improvement for cleaning up, failure
notification, and application termination.
Signed-off-by: David Griego [EMAIL PROTECTED]
---
include/linux/ipv6.h |8
include/linux/socket.h
On 3/27/07, David Miller [EMAIL PROTECTED] wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 16:41:48 -0300
+static inline void skb_move_linear_data(const struct sk_buff *skb,
+ const int from_offset,
+
Hi,
I did some benchmarking on the existing L2 network namespaces.
These patches are included in the lxc patchset at:
http://lxc.sourceforge.net/patches/2.6.20
The lxc7 patchset series contains Dmitry's patchset
The lxc8 patchset series contains Eric's patchset
Here are the following
El Martes, 27 de Marzo de 2007, Jose Alberto Reguero escribió:
El Martes, 27 de Marzo de 2007, Jose Alberto Reguero escribió:
El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero
([EMAIL PROTECTED]) wrote:
El
From: [EMAIL PROTECTED] (David Griego)
Date: Tue, 27 Mar 2007 14:47:54 -0700
Adds an IOCTL for aborting established TCP connections, and is
designed to be an HA performance improvement for cleaning up, failure
notification, and application termination.
Signed-off-by: David Griego [EMAIL
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 18:56:11 -0300
On 3/27/07, David Miller [EMAIL PROTECTED] wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 16:41:48 -0300
+static inline void skb_move_linear_data(const struct sk_buff
On Tue, 27 Mar 2007 14:42:20 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
Thanks for replying, Eric. I've added atl1-devel to the cc list.
Do you have msi's working in 2.6.21-rc4 in the x86_64 kernel?
I can't personally verify it anymore because I removed x86_64 to
duplicate the MSI
On 3/27/07, David Miller [EMAIL PROTECTED] wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 18:56:11 -0300
On 3/27/07, David Miller [EMAIL PROTECTED] wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 16:41:48 -0300
+static
David Miller wrote:
From: [EMAIL PROTECTED] (David Griego)
Date: Tue, 27 Mar 2007 14:47:54 -0700
Adds an IOCTL for aborting established TCP connections, and is
designed to be an HA performance improvement for cleaning up, failure
notification, and application termination.
On 3/28/07, Jay Cliburn [EMAIL PROTECTED] wrote:
On Tue, 27 Mar 2007 14:42:20 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
Thanks for replying, Eric. I've added atl1-devel to the cc list.
Do you have msi's working in 2.6.21-rc4 in the x86_64 kernel?
I can't personally verify it
On Wed, Mar 28, 2007 at 12:16:34AM +0200, Daniel Lezcano wrote:
Hi,
I did some benchmarking on the existing L2 network namespaces.
These patches are included in the lxc patchset at:
http://lxc.sourceforge.net/patches/2.6.20
The lxc7 patchset series contains Dmitry's patchset
The
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Wed, 21 Mar 2007 13:58:47 +0300
On Wed, Mar 21, 2007 at 11:54:45AM +0100, Patrick McHardy ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
We would already do that on init.
Some things become very confused, when nl_table is not used to
From: Patrick McHardy [EMAIL PROTECTED]
Date: Thu, 22 Mar 2007 12:36:17 +0100
jamal wrote:
The mutex is certainly a cleaner approach;
and a lot of the RCU protection would go away. I like it.
Not as much as I initially thought, but at least we would have
consistent locking for the dump
There is no reason for this ioctl at all. Either existing
facilities provide what you need or what you want is a
protocol violation we can't do.
I agree that 99 times out of ten such a mechanism serves only as a
massive KLUDGE to paper-over application bugs. I'll also sadly
point-out that
Mark Huth wrote:
David Miller wrote:
From: [EMAIL PROTECTED] (David Griego)
Date: Tue, 27 Mar 2007 14:47:54 -0700
Adds an IOCTL for aborting established TCP connections, and is
designed to be an HA performance improvement for cleaning up, failure
notification, and application
On Wed, 2007-03-28 at 07:30 +1000, Herbert Xu wrote:
Sorry, that patch is indeed broken. We do need to set IF_READY in
the case where all addresses were deleted (including the link-local)
and then recreated. The IPv6 device will be destroyed and recreated
too in that case.
Your new patch
John Heffner wrote:
I also believe this is a useful thing to have. I'm not 100% sure this
ioctl is the way to go, but it seems reasonable. This directly
corresponds to writing deleteTcb to the tcpConnectionState variable in
the TCP MIB (RFC 4022). I don't think it constitutes a protocol
Jay Cliburn [EMAIL PROTECTED] writes:
On Tue, 27 Mar 2007 14:42:20 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
Thanks for replying, Eric. I've added atl1-devel to the cc list.
Do you have msi's working in 2.6.21-rc4 in the x86_64 kernel?
I can't personally verify it anymore
Hi Mr. David
I have modified my patch according to you advice. I think -
EHOSTUNREACH
is only for input path. In output path, we can just simply check
-ENETUNREACH (^_^), the patch is shown in the end of this mail.
BTW: my E-mail has been changed to [EMAIL PROTECTED]
Function need to
From: Mark Huth [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 16:09:30 -0700
Actually, there are legitimate uses for this sort of API. The patch
allows an administrator to kill specific connections that are in use by
other applications, where the close is not available, since the socket
is
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 20:07:50 -0300
Okay, Hairaru is this way:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
Pulled, thanks a lot.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
From: John Heffner [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 20:27:44 -0400
As a concrete example of a way I've used this type of feature is to
defend against a netkill [1] style attack, where the defense involves
making decisions about which connections to kill when memory gets
scarce. It
Daniel Lezcano [EMAIL PROTECTED] writes:
3. General observations
---
The objective to have no performances degrations, when the network
namespace is off in the kernel, is reached in both solutions.
When the network is used outside the container and the network
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 20 Mar 2007 14:12:51 -0700
Change the bridging hook to be simple function with return value
rather than modifying the skb argument. This could generate better
code and is cleaner.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 20 Mar 2007 14:17:09 -0700
Instead of hashing the whole Ethernet address, it should be faster
to just use the last 4 bytes. Add a random salt value to the hash
to make it more difficult to construct worst case DoS hash chains.
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 20 Mar 2007 14:15:52 -0700
While in the STP learning state, don't route packets; wait until
forwarding delay has expired. The purpose of the forwarding delay
is to detect loops in the network, and if a brouter started up
and started
It doesn't build with bridging disabled, and I can't see
exactly how to work out the 'ret' assignment in the way
the new code works so I'm reverting.
Please resubmit a version that builds and works properly
with bridging enabled and disabled, thanks :-)
-
To unsubscribe from this list: send the
From: David Miller [EMAIL PROTECTED]
Date: Tue, 27 Mar 2007 19:38:09 -0700 (PDT)
It doesn't build with bridging disabled, and I can't see
exactly how to work out the 'ret' assignment in the way
the new code works so I'm reverting.
Please resubmit a version that builds and works properly
John Heffner [EMAIL PROTECTED] wrote:
Responding to myself in good form :P I'll add that there are other ways
to do this currently but all I know of are hackish, f.e. using a raw
socket to send RST packets to yourself.
While not pretty, it is easy enough to ptrace a process using gdb and
David Miller wrote:
It doesn't build with bridging disabled, and I can't see
exactly how to work out the 'ret' assignment in the way
the new code works so I'm reverting.
Please resubmit a version that builds and works properly
with bridging enabled and disabled, thanks :-)
okay, i'll fix it
In article [EMAIL PROTECTED] (at Tue, 27 Mar 2007 16:25:19 +0200), Thomas
Graf [EMAIL PROTECTED] says:
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ [EMAIL PROTECTED] 2007-03-27 22:45
When looking up route for destination with rules with
source address restrictions, we may need to find a source
When looking up route for destination with rules with
source address restrictions, we may need to find a source
address for the traffic if not given.
Based on patch from Noriaki TAKAMIYA [EMAIL PROTECTED].
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
include/linux/fib_rules.h | 11
Hi,
Wed, 28 Mar 2007 12:49:40 +0900 (JST)
[Subject: Re: [PATCH net-2.6.22] [IPV6] FIB6RULE: Find source address during
looking up route.]
YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] wrote...
Out of curiosity, what sort of rules would have this flag set?
The majority of lookups don't
Andi Kleen ([EMAIL PROTECTED]) wrote:
To truly defend against this you would likely need a cryptographic
hash, which would be likely too slow.
I do not think that a cryptographically secure hash is necessary for
this. Using a better hash function (i.e. one which does a good job of
Ayaz Abdulla wrote:
The nic poll routine was missing the call to the optimized irq routine.
This patch adds the missing call for the optimized path.
See http://bugzilla.kernel.org/show_bug.cgi?id=7950 for more information.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
applied 1-2
-
To
Dale Farnsworth wrote:
From: Gabriel Paubert [EMAIL PROTECTED]
In this driver, the default ethernet address is first set by by calling
eth_port_uc_addr_get() which reads the relevant registers of the
corresponding port as initially set by firmware. However that function
used the port_num field
Ron Mercer wrote:
This was removed in a previous patch to increase performance, but
caused a transmit error for the 4032 chip.
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applied 1-4 to #upstream-fixes
-
1 - 100 of 110 matches
Mail list logo
