On Thu, May 17, 2007 at 09:58:03AM -0500, Wen Xiong wrote:
It really shouldn't be there at all because something in either the
intel
or pseries hardware is totally buggy and we should disable features in
the buggy one completely.
Hi,
Here there are not hardware issue on both Intel or
Eric, thanks for looking at this.
There are races involving the garbage collector, that can throw away
perfectly good packets with AF_UNIX sockets in them.
The problems arise when a socket goes from installed to in-flight or
vice versa during garbage collection. Since gc is done
On Sat, Jun 23, 2007, David Miller wrote:
From: David Stevens [EMAIL PROTECTED]
Auto-configured addresses are used by the kernel. It has to
have those addresses. But the kernel doesn't do DNS look-ups, or
write resolv.conf; that's the difference, for me.
I totally agree with
Add support for the nested compat attribute type to netlink.
Thomas, I forgot to CC you on the related rtnetlink/iproute
patches, please have a look on netdev.
[NETLINK]: attr: add nested compat attribute type
Add a nested compat attribute type that can be used to convert
attributes that
On Saturday 23 June 2007 02:09:18 C. Scott Ananian wrote:
diff -ruHpN -X dontdiff linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h
linux-2.6.22-rc5/include/net/ip6_rdnss.h
--- linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h1969-12-31
19:00:00.0 -0500
+++
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per network namespace.
One of those per network namespace global variables will be the
loopback device. Which
[SKBUFF]: Fix incorrect config #ifdef around skb_copy_secmark
secmark doesn't depend on CONFIG_NET_SCHED.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7c6a34e..8d43ae6 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -434,8
Patrick McHardy wrote:
Urs Thuermann wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Is there a reason why you're still doing the allocate n devices
on init thing instead of using the rtnl_link API?
Sorry, it's simply a matter of time. We have been extremely busy with
Hello,
Le samedi 23 juin 2007, David Stevens a écrit :
Why not make the application that writes resolv.conf
also listen on a raw ICMPv6 socket? I don't believe you'd need
any kernel changes, then, and it seems pretty simple and
straightforward.
Unfortunately, ICMPv6 raw
Oliver Hartkopp wrote:
Patrick McHardy wrote:
Sorry, it's simply a matter of time. We have been extremely busy with
other projects and two presentations (mgmt, customers, and press) the
last two weeks and have worked on the other changes this week. I'm
sorry I haven't yet been able to look
Patrick McHardy wrote:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per network namespace.
One of those per network namespace global variables will be the
Thanks.
Acked-by: James Morris [EMAIL PROTECTED]
--
James Morris
[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
Le samedi 23 juin 2007, David Stevens a écrit :
No, in fact! I didn't hear anyone suggesting that all of
neighbor discovery be pushed out of the kernel. All I suggested is
that you read a raw ICMPv6 socket for RA's that have the RDNS header
and the app _process_the_RDNS_header. The
On Fri, 22 Jun 2007 21:53:58 +0200 [EMAIL PROTECTED] (Thomas Bogendoerfer)
wrote:
Hi,
This is new ethernet driver, which use the code taken out of lasi_82596
(done by the other patch I just sent).
Thomas.
Ethernet driver for EISA only SNI RM200/RM400 machines
...
+static char
[EMAIL PROTECTED] wrote on 06/23/2007 07:47:06 AM:
Rémi and Simon give my responses very eloquently. Although you could
have yet-another-network-daemon redundantly process RA messages, the
kernel is doing it already and it makes sense to just push this
It would be two pieces looking
Miklos Szeredi [EMAIL PROTECTED] writes:
Right. But the devil is in the details, and (as you correctly point
out later) to implement this, the whole locking scheme needs to be
overhauled. Problems:
- Using the queue lock to make the dequeue and the fd detach atomic
wrt the GC is
On 23/06/07 15:47, C. Scott Ananian wrote:
Advertisements it received. I considered storing the *complete*
Router Advertisement messages received and pushing them unparsed to
userland, just to get around the bogus DNS in the kernel politics
(hint: it's not a resolver in the kernel, it's just
Patrick McHardy wrote:
Oliver Hartkopp wrote:
i was just looking through the mailings regarding your suggested changes
(e.g. in VLAN, DUMMY and IFB) an none of them currently went into the
kernel (..)
They are all in the net-2.6.23 tree.
Ah, ok - that wasn't on my radar as i
Rémi and Simon give my responses very eloquently. Although you could
have yet-another-network-daemon redundantly process RA messages, the
kernel is doing it already and it makes sense to just push this
information to userland using /proc and/or netlink. Although parsing
RA messages and
Oliver Hartkopp wrote:
@Patrick: The changes in dummy.c and ifb.c for the netlink support do
not look very complicated (not even for me ;-))
I have a patch to make it even simpler, it basically needs only
the rtnl_link_ops structures initialized with one or two members
for devices like dummy
Patrick McHardy [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per network namespace.
One of those per network namespace global
Oliver Hartkopp wrote:
Patrick McHardy wrote:
BTW, in case the loopback device is required for normal
operation it might make sense to create *one* device by
default, but four identical devices seems a bit extreme.
As i wrote before CAN addressing consists of CAN-Identifiers and the
used
Christoph Hellwig wrote:
On Thu, May 17, 2007 at 09:58:03AM -0500, Wen Xiong wrote:
It really shouldn't be there at all because something in either the
intel
or pseries hardware is totally buggy and we should disable features in
the buggy one completely.
Hi,
Here there are not hardware
Stephen Hemminger [EMAIL PROTECTED] writes:
On Sat, 23 Jun 2007 08:20:40 -0700
Ben Greear [EMAIL PROTECTED] wrote:
Patrick McHardy wrote:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network
MOKUNO Masakazu wrote:
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2920,6 +2920,12 @@ M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
S: Maintained
+PS3 NETWORK SUPPORT
+P: Masakazu Mokuno
+M: [EMAIL PROTECTED]
+L: netdev@vger.kernel.org
I think you should put [EMAIL PROTECTED]
Rémi Denis-Courmont [EMAIL PROTECTED] wrote on 06/23/2007 09:51:55
AM:
How do I authenticate SeND RA? How do I deal with the link going down
before the expiration? How do I know this interface is doing autoconf
at all?
The kernel should do the authentication, as it will for other
Ben Greear [EMAIL PROTECTED] writes:
Patrick McHardy wrote:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per network namespace.
One of those per network
On Sat, 23 Jun 2007 08:20:40 -0700
Ben Greear [EMAIL PROTECTED] wrote:
Patrick McHardy wrote:
Eric W. Biederman wrote:
-- The basic design
There will be a network namespace structure that holds the global
variables for a network namespace, making those global variables
per
From: Florian Westphal [EMAIL PROTECTED]
The tipc netlink config handler uses the nlmsg_pid from the
request header as destination for its reply. If the application
initialized nlmsg_pid to 0, the reply is looped back to the kernel,
causing hangup. Fix: use nlmsg_pid of the skb that triggered the
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
I believe OpenVZ stores the current namespace somewhere global,
which avoids passing the namespace around. Couldn't you do this
as well?
It sucks. Especially in the corner cases. Think macvlan
with the real network
On Thu, 21 Jun 2007 18:48:30 +0530 pradeep singh [EMAIL PROTECTED] wrote:
Hi,
My mistake.
Resending after reformatting the patch by hand.
Looks like gmail messes the plain text patches.
That's still mangled so I typed it in again.
Please always include a full changlog with each version of
Rémi Denis-Courmont [EMAIL PROTECTED] wrote on 06/23/2007 11:13:01
AM:
An implementation might perform additional validity checks on the
ICMPv6 message content and discard malformed packets. However, a
portable application must not assume that such validity checks have
been
Le samedi 23 juin 2007, David Stevens a écrit :
This doesn't say that unauthenticated packets must be
delivered, and I don't think the portability of an RDNS daemon is an
issue. But even if you really wanted to run the same code on a
non-Linux machine, it just means that your daemon
Patrick McHardy [EMAIL PROTECTED] writes:
Depending upon the data structure it will either be modified to hold
a per entry network namespace pointer or it there will be a separate
copy per network namespace. For large global data structures like
the ipv4 routing cache hash table adding an
Le samedi 23 juin 2007, David Stevens a écrit :
The kernel should do the authentication, as it will for other
RA's,
and should not deliver (IMAO) unauthenticated packets. If it is, I
would consider that a bug (for all cases, not just this), and that
would be a good thing to fix. :-)
Patrick McHardy wrote:
BTW, in case the loopback device is required for normal
operation it might make sense to create *one* device by
default, but four identical devices seems a bit extreme.
As i wrote before CAN addressing consists of CAN-Identifiers and the
used interface. The use of
On 23.06.2007 19:19, Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Depending upon the data structure it will either be modified to hold
a per entry network namespace pointer or it there will be a separate
copy per network namespace. For large
On Sat, Jun 23, 2007, David Stevens wrote:
There certainly may be complications I haven't thought of, since
I haven't implemented it. But I still don't see a good case for using the
kernel as a DNS database.
Excuse me for being a bit confused by the approach that you suggest, as
so far
Eric W. Biederman wrote:
Ben Greear [EMAIL PROTECTED] writes:
Will we be able to have a single application be in multiple name-spaces?
A single application certainly. But then an application can be composed
of multiple processes which can be composed of multiple threads.
In my
Stephen Hemminger wrote:
Will we be able to have a single application be in multiple name-spaces?
That would break the whole point of namespaces...
I was hoping that I could open a socket in one name-space and another in
another name
space, and send traffic between them, within a
Carl-Daniel Hailfinger [EMAIL PROTECTED] writes:
Can one namespace DoS other namespaces' access to the routing cache?
Two scenarios come to mind:
* provoking hash collisions
* lock contention (sorry, haven't checked whether/how we do locking)
My initial expectation is that the protections we
Ben Greear [EMAIL PROTECTED] writes:
Any chance it could allow one to use a single threaded, single process and do
something like
int fd1 = socket(, namespace1);
int fd2 = socket(, namespace2);
Or, maybe a sockopt or similar call to move a socket into a particular
namespace?
I
From: Michael Buesch [EMAIL PROTECTED]
Date: Sat, 23 Jun 2007 11:07:14 +0200
Yeah, it might work. But I think the compiler doesn't guarantee
you anything about it.
The compiler actually does guarentee these things, and that's why we
have the endian bitfield macros. You're overreacting, we've
Eric W. Biederman wrote:
So it may be that we can cover your scenario. However it is just
enough off of the beaten path that I'm not going to worry about it
the first time through. It looks like it is a very small step from
where I am at to where you want to be. So you may be able to cook
up
From: Florian Westphal [EMAIL PROTECTED]
Date: Sat, 23 Jun 2007 20:25:46 +0200
From: Florian Westphal [EMAIL PROTECTED]
The tipc netlink config handler uses the nlmsg_pid from the
request header as destination for its reply. If the application
initialized nlmsg_pid to 0, the reply is looped
DM == David Miller [EMAIL PROTECTED] writes:
DM To be honest I think this form of virtualization is a complete
DM waste of time, even the openvz approach.
You are only considering the security values of OpenVZ. Where I work,
OpenVZ and Linux-vserver are used for their ability to cleanly
Please consider these patches for 2.6.23 inclusion.
These patches are built against Patrick McHardy's recently submitted
RTNETLINK nested compat attribute patches. They're needed to preserve
ABI between sch_{rr|prio} and iproute2.
Updates since the last submission:
1. Added checks for
Updated: Added checks for netif_subqueue_stopped() to netpoll,
pktgen, and software device dev_queue_xmit(). This will ensure
external events to these subsystems will be handled correctly if
a subqueue is shut down.
Add the multiqueue hardware device support API to the core network
stack. Allow
Updated: This patch applies on top of Patrick McHardy's RTNETLINK
nested compat attribute patches. These are required to preserve
ABI for iproute2 when working with the multiqueue qdiscs.
Add the new sch_rr qdisc for multiqueue network device support.
Allow sch_prio and sch_rr to be compiled
Add a brief howto to Documentation/networking for multiqueue. It
explains how to use the multiqueue API in a driver to support
multiqueue paths from the stack, as well as the qdiscs to use for
feeding a multiqueue device.
Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
---
Updated: This patch applies on top of Patrick McHardy's RTNETLINK
patches to add nested compat attributes. This is needed to maintain
ABI for sch_{rr|prio} in the kernel with respect to tc. A new option,
namely multiqueue, was added to sch_prio and sch_rr. This will allow
a user to turn
David Miller [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 11:19:34 -0600
Further and fundamentally all a global achieves is removing the need
for the noise patches where you pass the pointer into the various
functions. For long term
David Miller wrote:
I don't accept that we have to add another function argument
to a bunch of core routines just to support this crap,
especially since you give no way to turn it off and get
that function argument slot back.
To be honest I think this form of virtualization is a complete
waste
Jeff Garzik [EMAIL PROTECTED] writes:
David Miller wrote:
I don't accept that we have to add another function argument
to a bunch of core routines just to support this crap,
especially since you give no way to turn it off and get
that function argument slot back.
To be honest I think this
Eric W. Biederman wrote:
Jeff Garzik [EMAIL PROTECTED] writes:
David Miller wrote:
I don't accept that we have to add another function argument
to a bunch of core routines just to support this crap,
especially since you give no way to turn it off and get
that function argument slot back.
To
From: Benny Amorsen [EMAIL PROTECTED]
Date: 23 Jun 2007 23:22:38 +0200
Policy routing just doesn't cut it; it's cumbersome to set up, limited
to 256 tables
False.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo
(Applogies for not maintaining thread id, I'm not subscribed.)
We don't have any clean interfaces by which to do this MAC
programming, and we do need something for it soon.
Yep, that's been on my long term wish list for a while, as well.
Overall I would like to see a more flexible way of
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 15:41:16 -0600
If you want the argument to compile out. That is not a problem at all.
I dropped that part from my patch because it makes infrastructure more
complicated and there appeared to be no gain. However having a type
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sat, 23 Jun 2007 16:56:49 -0600
If the only use was strong isolation which Dave complains about I would
concur that the namespace approach is inappropriate. However there are
a lot other uses.
By your very admission the only appropriate use
59 matches
Mail list logo
