Hi,
David Miller wrote:
> Developer momentum means that the kernel is likely to get fixed
> whereas the userland component will more likely rot and not get
> fixed.
>
> So in this sense resiliency does depend upon something being in
> the kernel or not.
I can only agree here. Lots of users use t
From: Hugo Santos <[EMAIL PROTECTED]>
Date: Tue, 1 Aug 2006 13:00:03 +0100
> Resiliency to failure is not something that depends on the
> kernel. If the code in question is in the kernel, and it crashes,
> how will you recover?
Developer momentum means that the kernel is likely to get fixed
wh
From: Hugo Santos <[EMAIL PROTECTED]>
Date: Tue, 1 Aug 2006 12:50:02 +0100
>I might have some cycles during the month to code up something in
> this direction, at least for an initial review, i'll try to do so.
Great. I prefer to talk about code anyways :)
>Also, the reliability of a s
Jamal,
> nice to know ;-> At least you can protect some apps if you need to.
> Only racoon and quagga are important for me.
> But what happens then if you have a beast that just chews memory
> forever? I suppose other poor apps will just get shot.
You should push QoS and differentiation into t
David,
> To drive this home even more, I do not believe that the people who
> advocate pushing NDISC and ARP policy into userspace would be very
> happy if something like the RAID transformations were moved into
> userspace and they were not able to access their disks if the RAID
> transformer pro
David,
> So all of you userland control-plane fanatics, how will you handle
> things like NFS root with these daemon-required variants of NDISC and
> ARP?
Do it in the initial ramdisk, we only need the daemon to setup the
NDISC entries to talk to the NFS server. :-)
There is obviously a c
On Tue, 2006-01-08 at 11:30 +1000, Herbert Xu wrote:
>
> You can now disable the OOM killer on a per-process basis by
>
> echo -17 > /proc//oom_adj
>
nice to know ;-> At least you can protect some apps if you need to.
Only racoon and quagga are important for me.
But what happens then if you ha
On Mon, Jul 31, 2006 at 09:24:27PM -0400, Jamal Hadi Salim wrote:
>
> In regards to reliability: The thing that really fscks people using
> daemons from what i have seen is the oom killer policies and the lack of
> correlation by apps. I just watched quagga die horribly on a 256M
> machine on fri
On Mon, 2006-31-07 at 17:49 -0700, Roland Dreier wrote:
> David> Why is this a relevant analogy? Well, you have physical
> David> hard-disks in your computer today, but at some point that
> David> device becomes largely superfluous. It makes more sense to
> David> have just a cpu
David> Why is this a relevant analogy? Well, you have physical
David> hard-disks in your computer today, but at some point that
David> device becomes largely superfluous. It makes more sense to
David> have just a cpu with a 10-gigabit ethernet interface
David> incorporated ont
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 1 Aug 2006 02:31:58 +0200
> Playing devil's advocate here: if the packets are processed on
> two different CPUs then this could also happen and break the test
> case.
>
> So the test is probably a bit fragile.
Good point.
> I generally agree it's
> If we process these in sequence in software interrupt, everything
> is fine. Processing of "A" will add the address, and the test
> ping packet "B" will respond properly.
>
> If you defer "A", everything breaks and the test packet "B" will
> get processed first and not work.
Playing devil's a
Hello Hugo,
Hugo Santos wrote:
> Hi,
>
>> On the other hand, if a ND daemon loose the synchronization, it is
>> unpredicable, I guess.
>
>What do you mean by synchronization in this context? My idea was to
> keep the ND state machine inside the kernel, and instead have the
> daemon be reac
So all of you userland control-plane fanatics, how will you handle
things like NFS root with these daemon-required variants of NDISC and
ARP?
I know the devils' advocate responses already, so don't bother with
responses saying things like 1) "do it in the initial ramdisk, we only
need the daemon
Hi,
> On the other hand, if a ND daemon loose the synchronization, it is
> unpredicable, I guess.
What do you mean by synchronization in this context? My idea was to
keep the ND state machine inside the kernel, and instead have the
daemon be reactive. That means it would send messages on beh
Hi Hugo,
I think it is not correct to refer the IPSec architecture in the context.
It is originally desigened to separete the packet processing and the
management. They are loosely coupled and are not always synchronized.
For example if the daemon installs a pair of SAs which override the
SAs in S
Hi Jamal,
Through this discussion i've identified three points: one is that
some believe control and data should be kept synchronized; the other is
how some (including all of the first :-) think control should remain
inside the kernel; and finally you and me so far who believe they
should b
On Fri, 2006-28-07 at 09:34 +0100, Hugo Santos wrote:
> > 2. What if user process dies? or gets overwhelmed?
> >One of the assumptions of the any well designed kernel is that the
> > system should never
> >hang because some user application died or waited for ever.
>
>Of course that
> A couple of basic questions:
> 1. Can we just proceed assuming it is non-secure until a later time when
>the certificate path is established?
This is not something which is described in the standard. In fact,
processing the RA without a certificate path to the router already
assumes the
On Fri, 28 Jul 2006 04:31:32 +0100
Hugo Santos <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 27, 2006 at 08:20:44PM -0700, David Miller wrote:
> >
> > Now, if you're saying that, in response to a NDISC packet, we might
> > have to go out and obtain the certificate, before we can process
> > the NDISC
On Thu, Jul 27, 2006 at 08:20:44PM -0700, David Miller wrote:
>
> Now, if you're saying that, in response to a NDISC packet, we might
> have to go out and obtain the certificate, before we can process
> the NDISC packet. This is a different issue. Is that how this
> secure NDISC works? Or does
From: Hugo Santos <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 04:13:22 +0100
>Certainly, control packets cause state transitions. TCP is a mixed
> bag. I think the question here is whether we can afford a stack where
> the data path is fully synchronous with the control path -- considering
>
Hi,
On Thu, Jul 27, 2006 at 07:27:43PM -0700, David Miller wrote:
>
> Just like a TCP connection, packets cause state transitions.
> And it is reasonable to expect that after a state transition,
> the effects can be visible by subsequent packets.
Certainly, control packets cause state transit
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 12:22:29 +1000
> I suppose another case in point is IPv4 autoconf which
> is *still* in the kernel after all these years.
At least in that case, H. Peter Anvin has put together a
klibc equivalent.
Klibc is one possible way out of this q
From: Hugo Santos <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 02:45:28 +0100
> Is it reasonable to consider that control packet processing needs to
> be serialized with data packet processing? In this particular case, is
> it not the tests that are broken if not giving enough time to the host
> t
On Thu, Jul 27, 2006 at 06:34:15PM -0700, David Miller wrote:
>
> I have severe doubts actually in this area. And I have practical
> experience to back up these doubts in this specific case.
OK.
> Just moving the ipv6 address add/delete out of software interrupt
> context broke the TAHI and oth
Hi David,
> If we process these in sequence in software interrupt, everything
> is fine. Processing of "A" will add the address, and the test
> ping packet "B" will respond properly.
>
> If you defer "A", everything breaks and the test packet "B" will
> get processed first and not work.
Is i
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 09:56:42 +1000
> Kazunori Miyazawa <[EMAIL PROTECTED]> wrote:
> >
> > I'm interested in the approach. And I have a couple of comments.
> > I think DAD and ND are time critical operations.
> > Can the daemons process with confirming to th
Kazunori Miyazawa <[EMAIL PROTECTED]> wrote:
>
> I'm interested in the approach. And I have a couple of comments.
> I think DAD and ND are time critical operations.
> Can the daemons process with confirming to the specs.
> even if it were swapped out?
> Can we prevent the oom killer from killing t
Hi,
> I'm interested in the approach. And I have a couple of comments.
> I think DAD and ND are time critical operations.
> Can the daemons process with confirming to the specs.
My tests indicate that yes, even when considering mobility scenarios
where expected times are reduced. There is alw
Hi,
I'm interested in the approach. And I have a couple of comments.
I think DAD and ND are time critical operations.
Can the daemons process with confirming to the specs.
even if it were swapped out?
Can we prevent the oom killer from killing the daemons?
Anyway, we have to consider Pros. and Co
Hi all,
In the same line as some of the recent IPv6 patches being submited
for comments, and taking into consideration RFCs such as 'SEcure
Neighbor Discovery (SEND)' (RFC 3971) and 'Cryptographically Generated
Addresses (CGA)' (RFC 3972) where the complexity associated with
maintaining add
32 matches
Mail list logo
