On Monday 18 September 2006 23:22, David Miller wrote:
> Ok, ok, but don't we have queueing disciplines that need the timestamp
> even on ingress?
I grepped and I can't find any. The only non SIOCGTSTAMP users of the
time stamp seem to be sunrpc and conntrack and I bet both can be converted
over
On Monday 18 September 2006 23:03, Alexey Kuznetsov wrote:
>
> > And do you have some other prefered way to solve this? Even if the timer
> > was fast it would be still good to avoid it in the fast path when DHCPD
> > is running.
>
> No. The way, which you suggested, seems to be the best.
Ok. I
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/ipv4/Kconfig | 39 +--
net/ipv4/sysctl_net_ipv4.c |7 +++
net/ipv4/tcp_cong.c|2 +-
3 files changed, 45 insertions(+), 3 deletions(-)
Nice solution.
Signed-off-by: I
Amy Fong wrote:
[PATCH] Add Broadcom PHY support
This patch adds a driver to support the bcm5421s and bcm5461s PHY
Kernel version: linux-2.6.18-rc6
Signed-off-by: Amy Fong <[EMAIL PROTECTED]>
And... where are the users of this phy driver?
Jeff
-
To unsubscribe from this list: se
Bert's attempt was noble
It showed your desire for the truth
A simple path exists
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/ipv4/Kconfig | 39 +--
net/ipv4/sysctl_net_ipv4.c |7 +++
net/ipv4/tcp_cong.c|2 +-
3
On powerpc and ppc, insl_ns and insl are identical as are outsl_ns and
outsl, so remove the conditional use of insl_ns and outsl_ns.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/net/3c509.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
This is in anticipat
sparse "defined twice" warning
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
net/netfilter/xt_policy.c |2 --
1 file changed, 2 deletions(-)
--- a/net/netfilter/xt_policy.c
+++ b/net/netfilter/xt_policy.c
@@ -171,7 +171,6 @@ static struct xt_match policy_match = {
.match
Regardless, kudos for running the test. The only thing missing is the
-c and -C options to enable the CPU utilization measurements which will
then give the service demand on a CPU time per transaction basis. Or
was this a UP system that was taken to CPU saturation?
It is my notebook. :-) Of
On Sun, 17 Sep 2006 16:51:50 +0200
bert hubert <[EMAIL PROTECTED]> wrote:
> The original message Stephen reacts to below apparently never made it to the
> list, it can be found here: http://ds9a.nl/tmp/module-policy.txt
>
> > Any body who builds in random stuff without thinking is being foolish.
Hello!
> There isn't any sort of clever short-circuiting in loopback is there?
No, from all that I know.
> I
> do like the convenience of testing things over loopback, but always fret
> about not including drivers and actua
On Friday 08 September 2006 12:50 pm, Venkat Yekkirala wrote:
> This defines SELinux enforcement of the 2 new LSM hooks.
{snip}
> +static int selinux_skb_policy_check(struct sk_buff *skb, unsigned short
> family) +{
> + u32 xfrm_sid, trans_sid;
> + int err;
> +
> + if (selinux_compat_
On Tue, 19 Sep 2006, Alexey Kuznetsov wrote:
Hello!
Please think about it this way:
suppose you haave a heavily loaded router and some network problem is to
be diagnosed. You run tcpdump and suddenly router becomes overloaded (by
switching to timestamp-it-all mode
I am sorry. I cannot think
On Tue, Sep 19, 2006 at 02:00:38AM +0400, Alexey Kuznetsov wrote:
> Hello!
>
> > Please think about it this way:
> > suppose you haave a heavily loaded router and some network problem is to
> > be diagnosed. You run tcpdump and suddenly router becomes overloaded (by
> > switching to timestamp-it-a
Hello!
> Please think about it this way:
> suppose you haave a heavily loaded router and some network problem is to
> be diagnosed. You run tcpdump and suddenly router becomes overloaded (by
> switching to timestamp-it-all mode
I am sorry. I cannot think that way. :-)
Instead of attempts to scar
Hello!
> Ok, ok, but don't we have queueing disciplines that need the timestamp
> even on ingress?
I cannot find.
ip_queue does. But it is just another user, not different of sockets.
BTW in any case, any user of timestamp who sees 0, because skb was received
before timestamping was enabled, ha
Alexey Kuznetsov wrote:
Hello!
Of course, number of ACK increases. It is the goal. :-)
unpleasant increase in service demands on something like a "burst
enabled" (./configure --enable-burst) netperf TCP_RR test:
netperf -t TCP_RR -H foo -- -b N # N > 1
foo=localhost
There isn't any sor
On Friday 08 September 2006 12:50 pm, Venkat Yekkirala wrote:
> UPCOMING WORK:
>
> The following per the discussion at:
> http://marc.theaimsgroup.com/?l=selinux&m=115755980516072&w=2
>
> - Create IPSec SAs to be acquired with the creating sock's context as
> opposed to that of the matching SPD r
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Tue, 19 Sep 2006 01:03:21 +0400
> 1. It even does not disable possibility to record timestamp inside
>driver, which Alan was afraid of. The sequence is:
>
> if (!skb->tstamp.off_sec)
> net_timestamp(skb);
>
> 2. Maybe, ne
On Mon, Sep 18, 2006 at 06:50:22PM +0200, Andi Kleen wrote:
>
> I suppose in the worst case a sysctl like Vladimir asked for could be added,
> but it would seem somewhat lame.
>
Please think about it this way:
suppose you haave a heavily loaded router and some network problem is to
be diagnosed.
It seems our mails crossed.
On Mon, Sep 18, 2006 at 01:21:02PM -0700, Andrew Morton wrote:
>
> hm. I don't have this patch queued, but I _do_ have an equivalent patch
> for e1000 queued; what's up with that? Nobody seems to have paid much
> attention to the e1000 fix.
I spotted the e100 patch
On Mon, Sep 18, 2006 at 01:27:57PM +0200, Andi Kleen wrote:
> The codebase for timing (and lots of other things) is quite different
> between 32bit and 64bit. You're really surprised it doesn't work if you do
> such things?
>
It works, and after your remark above, I'm surprised.
Dunno about slow
Hello!
> But that never happens right?
Right.
Well, not right. It happens. Simply because you get packet
with newer timestamp after previous handler saw this packet
and did some actions. I just do not see any bad consequences.
> And do you have some other prefered way to solve this? Even if t
On Mon, Sep 11, 2006 at 10:41:29PM +0200, Joerg Roedel wrote:
> This driver implements the tunneling of Ethernet packets over IPv4
> networks for Linux. It uses the protocol defined in RFC 3378.
Check out the thread "[PATCH][RFC] etherip: Ethernet-in-IPv4 tunneling"
that was on netdev in January
Andrew Morton wrote:
On Mon, 18 Sep 2006 15:01:22 -0500
[EMAIL PROTECTED] (Linas Vepstas) wrote:
Hi,
Please apply the following one-liner patch to
what will become the stable 2.6.18. This patch is
low-risk because it affects only the PCI error
recovery code, which dosn't run on most platf
Hello!
Of course, number of ACK increases. It is the goal. :-)
> unpleasant increase in service demands on something like a "burst
> enabled" (./configure --enable-burst) netperf TCP_RR test:
>
> netperf -t TCP_RR -H foo -- -b N # N > 1
foo=localhost
b patched orig
2 10
On Mon, 18 Sep 2006 15:01:22 -0500
[EMAIL PROTECTED] (Linas Vepstas) wrote:
>
> Hi,
>
> Please apply the following one-liner patch to
> what will become the stable 2.6.18. This patch is
> low-risk because it affects only the PCI error
> recovery code, which dosn't run on most platforms
> (i
Hi,
Please apply the following one-liner patch to
what will become the stable 2.6.18. This patch is
low-risk because it affects only the PCI error
recovery code, which dosn't run on most platforms
(in particular, isn't invoked on current x86/ia64).
This patch was originally sent on 29 June
On Mon, Sep 18, 2006 at 11:53:09AM -0700, David Miller wrote:
> > What would the desired default be, 'BIC' in all cases?
>
> And if BIC is not enabled in the configuration, then what?
As the source notes "/* we'll always have reno */ ". This would make the
policy: the default is "bic" if availabl
On Fri, 8 Sep 2006, Venkat Yekkirala wrote:
> -static void secmark_restore(struct sk_buff *skb)
> +static unsigned int secmark_restore(struct sk_buff *skb, unsigned int
> hooknum,
> +const struct xt_target *target)
> {
> - if (!skb->secmark) {
> - u32 *conns
> On Fri, 8 Sep 2006, Venkat Yekkirala wrote:
>
> > + if (selinux_compat_net) {
> > + err = selinux_xfrm_decode_session(skb, &peersid, 0);
> > + BUG_ON(err);
>
> I'm pretty sure this should not be a BUG_ON. IIUC, you want
> to panic the
> kernel because one of the nested
> On Fri, 8 Sep 2006, Venkat Yekkirala wrote:
>
> > @@ -114,6 +128,9 @@ static struct xt_target xt_connsecmark_t
> > .target = target,
> > .targetsize = sizeof(struct
> xt_connsecmark_target_info),
> > .table = "mangle",
> > + .ho
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2006-09-19 00:08
> [NET]: Move netlink interface bits to linux/if_link.h.
>
> Moving netlink interface bits to linux/if.h is rather troublesome for
> applications including both linux/if.h (which was changed to be included
>
On Fri, 8 Sep 2006, Venkat Yekkirala wrote:
> This defines SELinux enforcement of the 2 new LSM hooks.
>
I think this looks ok in general (I have a couple more technical issues),
athough I believe that Stephen has some question about policy
construction.
Please rename these hooks:
+
From: bert hubert <[EMAIL PROTECTED]>
Date: Mon, 18 Sep 2006 17:40:48 +0200
> What would the desired default be, 'BIC' in all cases?
And if BIC is not enabled in the configuration, then what?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PR
On Fri, 8 Sep 2006, Venkat Yekkirala wrote:
> + if (selinux_compat_net) {
> + err = selinux_xfrm_decode_session(skb, &peersid, 0);
> + BUG_ON(err);
I'm pretty sure this should not be a BUG_ON. IIUC, you want to panic the
kernel because one of the nested SAs has a dif
On Fri, 8 Sep 2006, Venkat Yekkirala wrote:
> @@ -114,6 +128,9 @@ static struct xt_target xt_connsecmark_t
> .target = target,
> .targetsize = sizeof(struct xt_connsecmark_target_info),
> .table = "mangle",
> + .hooks
On Fri, 8 Sep 2006, Venkat Yekkirala wrote:
> diff --git a/include/net/ip.h b/include/net/ip.h
> index 98f9084..4646c13 100644
> --- a/include/net/ip.h
> +++ b/include/net/ip.h
> @@ -48,6 +48,9 @@ struct ipcm_cookie
> u32 addr;
> int oif;
>
On Fri, 8 Sep 2006, Venkat Yekkirala wrote:
> -static inline int xfrm6_policy_check(struct sock *sk, int dir, struct sk_buff
> *skb)
> -{
> - return xfrm_policy_check(sk, dir, skb, AF_INET6);
> + if (sk && sk->sk_policy[XFRM_POLICY_IN])
> + ret = __xfrm_policy_check(sk, dir, sk
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 05 Sep 2006 10:55:16 -0700
Is this really necessary? I thought that the problems with ABC were in
trying to apply byte-based heuristics from the RFC(s) to a
packet-oritented cwnd in the stack?
This is receiver side, and h
Philippe De Muyter <[EMAIL PROTECTED]> :
[...]
> On Mon, Sep 18, 2006 at 07:11:29PM +0800, Jesse Huang wrote:
> > Dear Philippe:
> > (1)Because this is a patent issue, we are not allow to use it again, even it
> > is in Data Sheet.
>
> I surmise this is only a concern for icplus as a hardware comp
On Monday 18 September 2006 18:28, Alexey Kuznetsov wrote:
> Hello!
>
> > Hmm, not sure how that could happen. Also is it a real problem
> > even if it could?
>
> As I said, the problem is _occasionally_ theoretical.
>
> This would happen f.e. if packet socket handler was installed
> after IP ha
Hello!
> Hmm, not sure how that could happen. Also is it a real problem
> even if it could?
As I said, the problem is _occasionally_ theoretical.
This would happen f.e. if packet socket handler was installed
after IP handler. Then tcpdump would get packet after it is processed
(acked/replied/for
On Monday 18 September 2006 17:38, Alexey Kuznetsov wrote:
> Hello!
>
> > For netdev: I'm more and more thinking we should just avoid the problem
> > completely and switch to "true end2end" timestamps. This means don't
> > time stamp when a packet is received, but only when it is delivered
> > to
On Mon, Sep 18, 2006 at 07:06:00AM -0700, David Miller wrote:
> Any ordering scheme is wrong or unexpected for _somebody_. Look how
I agree violently. Would you agree that it would be best to have a mechanism
that explicitly sets a sane default, and does not rely on ordering?
My implementation
Hello!
> For netdev: I'm more and more thinking we should just avoid the problem
> completely and switch to "true end2end" timestamps. This means don't
> time stamp when a packet is received, but only when it is delivered
> to a socket.
This will work.
>From viewpoint of existing uses of timesta
On Monday 18 September 2006 17:19, Alan Cox wrote:
> Ar Llu, 2006-09-18 am 16:29 +0200, ysgrifennodd Andi Kleen:
> > The only delay this would add would be the queueing time from the NIC
> > to the softirq. Do you really think that is that bad?
>
> If you are trying to do things like network recor
Andrey Savochkin wrote:
Socket hash lookups are made within namespace.
Hash tables are common for all namespaces, with
additional permutation of indexes.
Hi Andrey,
why is the hash table common and not instanciated multiple times for
each namespace like the routes ?
-
To unsubscribe from th
Hi David,
> > although HIDP mouse movement doesn't seem to be appearing
> > in /dev/input/mice on my G5, while the 'hcidump' output looks sane
> > enough while I move it.
>
> Ew, that's because struct hidp_connadd_req is similarly buggered for
> compat. Replacement HIDP patch to fix both at once
Hello.
Please pull the following changesets available at:
git://git.skbuff.net/gitroot/yoshfuji/net-2.6.19-20060918-net/
HEADLINES
-
[XFRM]: Do not add a state whose SPI is zero to the SPI hash.
[NET]: Move netlink interface bits to linux/if_link.h.
[NET]: Include
Hello.
Please pull the following changesets available at:
git://git.skbuff.net/gitroot/yoshfuji/net-2.6.19-20060918-inet6/
HEADLINES
-
[IPV6] NDISC: Handle NDP messages to proxied addresses.
[IPV6]: Don't forward packets to proxied link-local address.
[IPV6]
Ar Llu, 2006-09-18 am 16:29 +0200, ysgrifennodd Andi Kleen:
> The only delay this would add would be the queueing time from the NIC
> to the softirq. Do you really think that is that bad?
If you are trying to do things like network record/playback then you
want the minimal delay. There's a reason
>
> People who run tcpdump want "wire" timestamps as close as possible.
> Yes, things get delayed with the IRQ path, DMA delays, IRQ
> mitigation and whatnot, but it's an order of magnitude worse if
> you delay to user read() since that introduces also the delay of
> the packet copies to userspac
On Mon, 2006-09-18 at 12:38 +0200, Marcel Holtmann wrote:
> it seems that HIDP and CMTP will have the same problem.
Finally, the CMTP version... this one is untested.
[CMTP] Fix compat CMTPGETCONNLIST ioctl
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/net/bluetooth/cmtp/
On Mon, 2006-09-18 at 14:25 +0100, David Woodhouse wrote:
> although HIDP mouse movement doesn't seem to be appearing
> in /dev/input/mice on my G5, while the 'hcidump' output looks sane
> enough while I move it.
Ew, that's because struct hidp_connadd_req is similarly buggered for
compat. Replace
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 18 Sep 2006 11:58:21 +0200
> For netdev: I'm more and more thinking we should just avoid the
> problem completely and switch to "true end2end" timestamps. This
> means don't time stamp when a packet is received, but only when it
> is delivered to a socket
From: bert hubert <[EMAIL PROTECTED]>
Date: Mon, 18 Sep 2006 11:59:36 +0200
> I've tested this patch and it does the job for me, reno is now the default,
> even when more advanced options are compiled in, but the rest is still
> available.
This breaks our intention that when TCP_CONG_ADVANCED is
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Mon, 18 Sep 2006 14:37:05 +0400
> > It looks perfectly fine to me, would you like me to apply it
> > Alexey?
>
> Yes, I think it is safe.
Ok, I'll put this into net-2.6.19 for now. Thanks.
-
To unsubscribe from this list: send the line "unsubscri
On Mon, 2006-09-18 at 12:38 +0200, Marcel Holtmann wrote:
> Hi David,
>
> > We were making no attempt to deal with the fact that a structure with a
> > uint32_t followed by a pointer is going to be _different_ for 32-bit and
> > 64-bit userspace. Any 32-bit process trying to use BNEPGETCONNLIST wi
Hi Jesse,
On Mon, Sep 18, 2006 at 07:11:29PM +0800, Jesse Huang wrote:
> Dear Philippe:
> (1)Because this is a patent issue, we are not allow to use it again, even it
> is in Data Sheet.
I surmise this is only a concern for icplus as a hardware company.
The sundance driver in Linux is meant to w
"Vladimir B. Savkin" <[EMAIL PROTECTED]> writes:
[you seem to send your emails in a strange way that doesn't keep me in cc.
Please stop doing that.]
> On Mon, Sep 18, 2006 at 11:58:21AM +0200, Andi Kleen wrote:
> > > > The x86-64 timer subsystems currently doesn't have clocksources
> > > > at all
Dear Philippe:
(1)Because this is a patent issue, we are not allow to use it again, even it
is in Data Sheet.
(2)Ok, sorry for this, I will add it back.
Should I resent those 4 patches? Or generate this as a new patch?
Thanks very much!
Best Regards,
Jesse Huang.
- Original Message -
Hello!
> It looks perfectly fine to me, would you like me to apply it
> Alexey?
Yes, I think it is safe.
Theoretically, there is one place where it can be not so good.
Good nagling tcp connection, which makes lots of small write()s,
will send MSS sized frames due to delayed ACKs. But if we ACK
Hi David,
> We were making no attempt to deal with the fact that a structure with a
> uint32_t followed by a pointer is going to be _different_ for 32-bit and
> 64-bit userspace. Any 32-bit process trying to use BNEPGETCONNLIST will
> be failing with -EFAULT if it's lucky; suffering from having th
On Mon, Sep 18, 2006 at 11:58:21AM +0200, Andi Kleen wrote:
> > > The x86-64 timer subsystems currently doesn't have clocksources
> > > at all, but it supports TSC and some other timers.
> >
>
> > until I hacked arch/i386/kernel/tsc.c
>
> Then you don't use x86-64.
>
Oh. I mean I made arch/i38
We were making no attempt to deal with the fact that a structure with a
uint32_t followed by a pointer is going to be _different_ for 32-bit and
64-bit userspace. Any 32-bit process trying to use BNEPGETCONNLIST will
be failing with -EFAULT if it's lucky; suffering from having the
connection list d
On Mon, Sep 18, 2006 at 01:51:30AM -0700, David Miller wrote:
> We created TCP_CONG_ADVANCED for a purpose. If you turn that
> thing on, you get full control but if something breaks you get
> to keep the pieces.
But we should not try to break stuff on purpose, no matter how advanced. It
makes zer
"Vladimir B. Savkin" <[EMAIL PROTECTED]> writes:
> On Mon, Sep 18, 2006 at 10:35:38AM +0200, Andi Kleen wrote:
> > > I just found out that TSC clocksource is not implemented on x86-64.
> > > Kernel version 2.6.18-rc7, is it true?
> >
> > The x86-64 timer subsystems currently doesn't have clocksou
Only authors of proprietary modules you loaded can debug this.
Please, redirect this and all futher oopses to them.
On 9/18/06, Joe Jin <[EMAIL PROTECTED]> wrote:
while I try to transmit a 8k data by send() on my laptap T60, kernel
panic occured:
Modules linked in: rds cisco_ipsec parport_pc
Patrick McHardy wrote:
> [XFRM]: Fix wildcard as tunnel source
>
> Hashing SAs by source address breaks templates with wildcards as tunnel
> source since the source address used for hashing/lookup is still 0/0.
> Move source address lookup to xfrm_tmpl_resolve_one() so we can use the
> real addres
Patrick McHardy wrote:
> David Miller wrote:
>
>>I really don't want to remove this as it's fairly critical performance
>>wise for the scalability problems all my changes were meant to address.
>>I hope I really don't have to do something like what was needed for
>>the policy layer, having a linke
On Mon, Sep 18, 2006 at 11:41:09AM +0800, Jesse Huang wrote:
> Dear Philippe:
>
> (1) We are not allow to support register TxStartThresh and, RxEarlyThresh,
> so
> we remove it.
Could you develop ?
- What do you mean by `We are not allow'
- Is it specific to the IP100A chip ?
Those register are
On Mon, Sep 18, 2006 at 10:35:38AM +0200, Andi Kleen wrote:
> > I just found out that TSC clocksource is not implemented on x86-64.
> > Kernel version 2.6.18-rc7, is it true?
>
> The x86-64 timer subsystems currently doesn't have clocksources
> at all, but it supports TSC and some other timers.
H
From: bert hubert <[EMAIL PROTECTED]>
Date: Sun, 17 Sep 2006 14:21:53 +0200
> Operators, distributors and even people who've been doing kernel stuff for
> more than a decade expect to be able to compile in (experimental) policies,
> and not have a *random* one of them enabled by default!
We creat
"Vladimir B. Savkin" <[EMAIL PROTECTED]> writes:
> On Mon, Jun 19, 2006 at 05:24:31PM +0200, Andi Kleen wrote:
> >
> > > If you use "pmtmr" try to reboot with kernel option "clock=tsc".
> >
> > That's dangerous advice - when the system choses not to use
> > TSC it often has a reason.
>
> I just
David Miller wrote:
> Unfortunately, this break scalability of the xfrm state layer when the
> source is equally as varying as the destination. In such setups you
> have an enormous number of entries with destination being the local
> system and only the source address changing.
>
> BTW, how can
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Tue, 05 Sep 2006 16:44:21 -0700
> On Tue, 2006-09-05 at 23:57 +0200, Adrian Bunk wrote:
> > This patch contains the following cleanups:
> > - make the following needlessly global function static:
> > - socket.c: sctp_apply_peer_addr_params()
> >
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 05 Sep 2006 10:55:16 -0700
> Is this really necessary? I thought that the problems with ABC were in
> trying to apply byte-based heuristics from the RFC(s) to a
> packet-oritented cwnd in the stack?
This is receiver side, and helps a sender who d
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Mon, 4 Sep 2006 20:00:45 +0400
> Try enclosed patch. I have no idea why 9.997 sec is so magic, but I
> get exactly this number on my notebook. :-)
>
> =
>
> This patch enables sending ACKs each 2d received segment.
> It does not af
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sun, 3 Sep 2006 21:15:07 +1000
> So here is a simple patch to remove the tx lock from dev_watchdog_up.
> In 2.6.19 we can eliminate the unnecessary __dev_watchdog_up and
> replace it with dev_watchdog_up.
>
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Sat, 02 Sep 2006 16:46:44 +0200
> [XFRM]: Fix wildcard as tunnel source
>
> Hashing SAs by source address breaks templates with wildcards as tunnel
> source. Remove saddr from the hash key.
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Un
On Sat, 16 Sep 2006, Diego Beltrami wrote:
The patch which introduces the BEET mode and which previously was sent to this
mailing list is valid also for
http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.19.git;a=summary
branch.
However there are probably some errors in attaching inlin
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 23:40:05 +0200
> iproute2 doesn't provide the NLM_F_CREATE flag when adding addresses,
> it is assumed to be implied. The existing code issues a check on
> said flag when the modify operation fails (likely due to ENOENT)
> before continu
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 23:40:04 +0200
> Same behaviour as IPv4, using IFF_UP is a no-no anyway.
>
> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 23:40:03 +0200
> Replaces INET6_IFADDR_RTA_SPACE with a new function calculating
> the total required message size for all address messages.
>
> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: s
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 23:40:02 +0200
> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/ma
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 23:40:01 +0200
> Signed-off-by: Thomas Graf <[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.kerne
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 23:40:00 +0200
> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/m
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 23:39:59 +0200
> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/ma
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 23:39:58 +0200
> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/ma
From: Brian Haley <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 11:32:06 -0400
> Change some netfilter tunables to __read_mostly. Also fixed some
> incorrect file reference comments while I was in there.
>
> (this will be my last __read_mostly patch unless someone points out
> something else that
From: Brian Haley <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 11:31:52 -0400
> Change sctp globals to __read_mostly.
>
> Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED
From: Brian Haley <[EMAIL PROTECTED]>
Date: Fri, 01 Sep 2006 11:31:43 -0400
> Change some bridge sysctl tunables to __read_mostly.
>
> Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Thu, 31 Aug 2006 23:21:29 +0200
> Additionaly exports the following information when providing
> the list of registered generic netlink families:
> - protocol version
> - header size
> - maximum number of attributes
> - list of available operatio
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Fri, 15 Sep 2006 22:16:17 +0200
> bert hubert wrote:
> >>It appears to be intentionally, but I don't see a reason for it.
> >>Can you try if this patch makes it work as expected?
> >
> >
> >>[PACKET]: Don't truncate non-linear skbs with mmaped IO
>
94 matches
Mail list logo
