On Wed, Apr 25, 2007 at 11:31:21PM -0700, David Miller wrote:
> From: Chris Wright <[EMAIL PROTECTED]>
> Date: Wed, 25 Apr 2007 23:26:01 -0700
>
> > Working fine here. Any chance you booted a stale kernel?
> > If not, what's your nl_fib_input+0xe4. Any chance that's
> > actually in nl_fib_lookup
On Wednesday 25 April 2007 23:03, Vlad Yasevich wrote:
> It looks like someone is stepping all over the inet_sock.
> We'll continue looking, but if anyone has any ideas of what might
> be going on, I'd appreciate it.
This could be a socket in TIME_WAIT. A socket entering
TIME_WAIT will be replaced
From: Chris Wright <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 23:26:01 -0700
> Working fine here. Any chance you booted a stale kernel?
> If not, what's your nl_fib_input+0xe4. Any chance that's
> actually in nl_fib_lookup?
I'm seriously hoping it's a stale kernel or similar,
because I can't ac
* Chris Wright ([EMAIL PROTECTED]) wrote:
> * Greg KH ([EMAIL PROTECTED]) wrote:
> > fyi, here's the patch that I applied, perhaps 2.6.20 needed something
> > else too?
>
> > @@ -809,7 +815,7 @@ static void nl_fib_input(struct sock *sk
> >
> > nl_fib_lookup(frn, tb);
> >
> > - pid = n
* Greg KH ([EMAIL PROTECTED]) wrote:
> fyi, here's the patch that I applied, perhaps 2.6.20 needed something
> else too?
> @@ -809,7 +815,7 @@ static void nl_fib_input(struct sock *sk
>
> nl_fib_lookup(frn, tb);
>
> - pid = nlh->nlmsg_pid; /*pid of sending process */
>
On Wed, Apr 25, 2007 at 10:44:20PM -0700, Greg KH wrote:
> On Wed, Apr 25, 2007 at 10:32:01PM -0700, David Miller wrote:
> > From: Greg KH <[EMAIL PROTECTED]>
> > Date: Wed, 25 Apr 2007 22:29:12 -0700
> >
> > > On Wed, Apr 25, 2007 at 01:15:12PM -0700, Linus Torvalds wrote:
> > > >
> > > >
> > >
On Wed, Apr 25, 2007 at 10:32:01PM -0700, David Miller wrote:
> From: Greg KH <[EMAIL PROTECTED]>
> Date: Wed, 25 Apr 2007 22:29:12 -0700
>
> > On Wed, Apr 25, 2007 at 01:15:12PM -0700, Linus Torvalds wrote:
> > >
> > >
> > > On Wed, 25 Apr 2007, Alexey Kuznetsov wrote:
> > > >
> > > > Reply to
* Greg KH ([EMAIL PROTECTED]) wrote:
> On Wed, Apr 25, 2007 at 01:15:12PM -0700, Linus Torvalds wrote:
> >
> >
> > On Wed, 25 Apr 2007, Alexey Kuznetsov wrote:
> > >
> > > Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
> > > which resulted in infinite recursion and stack ove
From: Greg KH <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 22:29:12 -0700
> On Wed, Apr 25, 2007 at 01:15:12PM -0700, Linus Torvalds wrote:
> >
> >
> > On Wed, 25 Apr 2007, Alexey Kuznetsov wrote:
> > >
> > > Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
> > > which resulted
On Wed, Apr 25, 2007 at 01:15:12PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 25 Apr 2007, Alexey Kuznetsov wrote:
> >
> > Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
> > which resulted in infinite recursion and stack overflow.
Wait, I just had the bright idea of actuall
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 16:47:41 -0700
> Writing to /sys/class/net/brX/bridge/stp_state causes a warning because
> RTNL is not held when call br_stp_if.c
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, thanks Stephen.
-
To unsubscribe
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 16:47:39 -0700
> Pause frames should never make it out of the network device into
> the stack. But if a device was misconfigured, it might happen.
> So drop pause frames in bridge.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROT
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 16:47:38 -0700
> The change to forward STP bpdu's (for usermode STP) through normal path,
> changed the packet type in the process. Since link local stuff is multicast,
> it
> should stay pkt_type = PACKET_MULTICAST. The code was
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Mon, 23 Apr 2007 13:43:35 -0400
> [PATCH] [SCTP] Fix sctp_getsockopt_local_addrs_old() to use local storage
>
> sctp_getsockopt_local_addrs_old() in net/sctp/socket.c calls copy_to_user()
> while the spinlock addr_lock is held. this should not be done
From: Keiichi KII <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 13:02:04 +0900
> Stephen Hemminger said "The configuration of netconsole's looks like the
> configuration of routes".
> I think so too.
> So I think ioctl commands for adding/removing port and the following userland
> application like
Well.. before you can finish this work we need to decide upon what the
interface to userspace will be.
- The miscdev isn't appropriate
Why isn't miscdev appropriate?
We just shouldn't use miscdev for networking conventionally?
Yes it's rather odd, especially for networking.
What does the m
Simplify pegasus carrier detection; rely only on the periodic MII
polling. Reverts pieces of c43c49bd61fdb9bb085ddafcaadb17d06f95ec43.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
--- a/drivers/usb/net/pegasus.h 2007-04-25 21:21:00.0 -0400
+++ b/drivers/usb/net/pegasus.h 2007-04-25 21
Writing to /sys/class/net/brX/bridge/stp_state causes a warning because
RTNL is not held when call br_stp_if.c
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/bridge/br_sysfs_br.c |2 ++
1 file changed, 2 insertions(+)
--- bridge-2.6.22.orig/net/bridge/br_sysfs_br.c
+++ bridge-
If a bridge is not running STP, then it has no way to detect a cycle
in the network. But if it is not running STP and some other machine
or device is running STP, then if STP BPDU's get forwarded to it can
detect the cycle.
This is how the old 2.4 and early 2.6 code worked.
Signed-off-by: Stephen
The change to forward STP bpdu's (for usermode STP) through normal path,
changed the packet type in the process. Since link local stuff is multicast, it
should stay pkt_type = PACKET_MULTICAST. The code was probably copy/pasted
incorrectly from the bridge pseudo-device receive path.
Signed-off-by
Here are some patches for bridge code in 2.6.22. The user mode RSTP
from Aji is working. Anyone who wants to test it can get it from:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/rstp.git
Thanks
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of
Pause frames should never make it out of the network device into
the stack. But if a device was misconfigured, it might happen.
So drop pause frames in bridge.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- bridge-2.6.22.orig/include/linux/if_ether.h
+++ bridge-2.6.22/include/linux/if_e
On Wed, 25 Apr 2007 22:51:43 +0200 Patrick McHardy <[EMAIL PROTECTED]> wrote:
> I think I found the problem, the rtnl_mutex was reinitialized on every
> rtnetlink socket creation. This is most likely responsible for both
> warnings.
Yup, no warnings any more, thanks.
-
To unsubscribe from this li
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 14:50:18 -0700
> On Wed, 25 Apr 2007 15:53:19 -0400
> Neil Horman <[EMAIL PROTECTED]> wrote:
>
> > I did the optimistic dad sysctl, and have no strict use for numbered
> > sysctls (I
> > was just unaware of the policy). I'll work up
Hi Dave,
> > I have two last minute patches before the final 2.6.21 kernel hits the
> > streets. One is a kernel memory leak that has been classified as
> > security issue. The second one is a sysfs fix to correct a wrong use of
> > class and bus devices.
>
> I don't think this one will make it a
Hi Dave,
I have two last minute patches before the final 2.6.21 kernel hits the
streets. One is a kernel memory leak that has been classified as
security issue. The second one is a sysfs fix to correct a wrong use of
class and bus devices.
Regards
Marcel
Please pull from
git://git.ker
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Thu, 26 Apr 2007 01:05:55 +0200
> I have two last minute patches before the final 2.6.21 kernel hits the
> streets. One is a kernel memory leak that has been classified as
> security issue. The second one is a sysfs fix to correct a wrong use of
> cl
Greg KH wrote:
On Wed, Apr 25, 2007 at 10:38:56PM +0400, Alexey Kuznetsov wrote:
Hello!
Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
which resulted in infinite recursion and stack overflow.
The bug is present in all kernel versions since the feature appeared.
Any hint
Ristuccia, Brian <[EMAIL PROTECTED]> wrote:
>
> 08:39:55.649689 IP 10.2.10.254.22 > 12.33.234.69.35026: .
> 5906:10250(4344) ack 1
> 794 win 674
> 08:39:55.650532 IP 10.2.10.1 > 10.2.10.254: icmp 92: 12.33.234.69
> unreachable -
> need to frag (mtu 1500)
Where was this dump taken, on 10.2.10.254
On Wed, 2007-04-25 at 17:03 -0400, Vlad Yasevich wrote:
> Hi All
>
> To support a piece of custom functionality, we needed to add
> 2 member to the struct inet_sock. During testing, we started
> seeing an interesting corruption. Following a hunch, we've
> completely ripped out all of our code wi
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 21:55:21 +0900 (JST)
> Please consider pulling following commits available on
> net-2.6.22-20070425a-inet6-cleanup-20070425
> branch at
> .
>
> HEADLINES
> -
>
> [
On Wed, 25 Apr 2007 15:53:19 -0400
Neil Horman <[EMAIL PROTECTED]> wrote:
> I did the optimistic dad sysctl, and have no strict use for numbered sysctls
> (I
> was just unaware of the policy). I'll work up a patch to use
> register_sysclt_table with CTL_UNNUMBERED in the next few days.
I don't
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 22:51:43 +0200
> [NETLINK]: don't reinitialize callback mutex
>
> Don't reinitialize the callback mutex the netlink_kernel_create caller
> handed in, it is supposed to already be initialized and could already
> be held by someone.
>
Hi All
To support a piece of custom functionality, we needed to add
2 member to the struct inet_sock. During testing, we started
seeing an interesting corruption. Following a hunch, we've
completely ripped out all of our code with the exception of
5 lines that do this:
diff --git a/include/net/
Andrew Morton wrote:
> I just retested bare net-2.6.22, pulled 30 minutes ago. I got just one
> warning:
>
> BUG: at kernel/mutex-debug.c:82 debug_mutex_unlock()
> [] debug_mutex_unlock+0x5a/0x134
> [] __mutex_unlock_slowpath+0x9d/0xcf
> [] ipw_wx_set_encode+0x0/0x82 [ipw2200]
> [] rtnl_unloc
On Wed, 25 Apr 2007, Alexey Kuznetsov wrote:
>
> Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
> which resulted in infinite recursion and stack overflow.
So I assume it's this line that actually _fixes_ it:
> - pid = nlh->nlmsg_pid; /*pid of sending process
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 13:15:12 -0700 (PDT)
> If so, shouldn't we also have some safety-net to make sure it doesn't
> still get routed back forever, ie adding something like
>
> if (!pid) {
> skb_free(skb);
> return -EINV
From: "Ristuccia, Brian" <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 16:11:51 -0400
> > I'm seeing a
> > problem where the kernel attempts to send packets with a MSS
> > larger than the one negotiated when the TCP connection is
> > established. Even after ICMP "can't fragment" messages
> > arri
David Miller <[EMAIL PROTECTED]> writes:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Wed, 25 Apr 2007 14:06:34 -0600
>
>> David for clarity do you happen to know of anyone using binary
>> sysctl values?
>
> None at all.
>
>> In particular is there any reason not to use CTL_UNNUMBERED
>>
> I'm seeing a
> problem where the kernel attempts to send packets with a MSS
> larger than the one negotiated when the TCP connection is
> established. Even after ICMP "can't fragment" messages
> arrive, the kernel still attempts to increase the MSS rather
> aggressively. The end result is e
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 22:38:56 +0400
> Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
> which resulted in infinite recursion and stack overflow.
>
> The bug is present in all kernel versions since the feature appeared.
>
> The patc
I had previously posted this message to linux-kernel, but David Miller
asked me to post here instead. Some replies to my message on l-k have
already been copied here. I'm seeing a problem where the kernel attempts
to send packets with a MSS larger than the one negotiated when the TCP
connection is
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 25 Apr 2007 14:06:34 -0600
> David for clarity do you happen to know of anyone using binary
> sysctl values?
None at all.
> In particular is there any reason not to use CTL_UNNUMBERED
> for new networking sysctls?
Neil said he would send me
David Miller <[EMAIL PROTECTED]> writes:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Wed, 25 Apr 2007 12:29:24 -0700
>
>>
>> I note that the networking tree is adding new sysctls:
>>
>> <<< HEAD/include/linux/sysctl.h
>> NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
>> ===
>> NE
On Wed, Apr 25, 2007 at 10:38:56PM +0400, Alexey Kuznetsov wrote:
> Hello!
>
> Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
> which resulted in infinite recursion and stack overflow.
>
> The bug is present in all kernel versions since the feature appeared.
Any hint on when
From: Greg KH <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 12:59:41 -0700
> On Wed, Apr 25, 2007 at 10:38:56PM +0400, Alexey Kuznetsov wrote:
> > Hello!
> >
> > Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
> > which resulted in infinite recursion and stack overflow.
> >
> >
From: David Howells <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 20:56:47 +0100
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > Then please generate your patches against my net-2.6.21 GIT
> > tree. Most of your initial patches in the series (the SKB
> > routine one for example) are already in my t
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 12:29:24 -0700
>
> I note that the networking tree is adding new sysctls:
>
> <<< HEAD/include/linux/sysctl.h
> NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
> ===
> NET_IPV6_OPTIMISTIC_DAD=24,
> NET_IPV6_ACCEPT_SO
David Miller <[EMAIL PROTECTED]> wrote:
> Then please generate your patches against my net-2.6.21 GIT
> tree. Most of your initial patches in the series (the SKB
> routine one for example) are already in my tree.
Do you mean your net-2.6.22 GIT tree?
Do you want me to make it available as a GIT
On Wed, Apr 25, 2007 at 01:45:19PM -0600, Eric W. Biederman wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > I note that the networking tree is adding new sysctls:
> >
> > <<< HEAD/include/linux/sysctl.h
> > NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
> > ===
> > NET_IPV6_OPTI
Andrew Morton <[EMAIL PROTECTED]> writes:
> I note that the networking tree is adding new sysctls:
>
> <<< HEAD/include/linux/sysctl.h
> NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
> ===
> NET_IPV6_OPTIMISTIC_DAD=24,
> NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
/include/linux/s
I just retested bare net-2.6.22, pulled 30 minutes ago. I got just one
warning:
PM: Removing info for No Bus::06:0b.0
eth0: no IPv6 routers present
ipw2200: Radio Frequency Kill Switch is On:
Kill switch must be turned off for wireless networking to work.
PM: Adding info for No Bus:eth1
ipw
From: David Howells <[EMAIL PROTECTED]>
Date: Wed, 25 Apr 2007 14:38:32 +0100
> I think the idea is for them (or at least some of them) to go
> through one of DaveM's net git trees anyway.
Then please generate your patches against my net-2.6.21 GIT
tree. Most of your initial patches in the serie
I note that the networking tree is adding new sysctls:
<<< HEAD/include/linux/sysctl.h
NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
===
NET_IPV6_OPTIMISTIC_DAD=24,
NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
>>> /include/linux/sysctl.h
(Well, it's trying to - there are some git reje
Hello!
Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
which resulted in infinite recursion and stack overflow.
The bug is present in all kernel versions since the feature appeared.
The patch also makes some minimal cleanup:
1. Return something consistent (-ENOENT) when fib
> -Original Message-
> From: J Hadi Salim [mailto:[EMAIL PROTECTED] On Behalf Of jamal
> Sent: Wednesday, April 25, 2007 4:37 AM
> To: Stephen Hemminger
> Cc: Waskiewicz Jr, Peter P; netdev@vger.kernel.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; cramerj;
> Kok, Auke-jan H; Leech, Christo
Hi Jon,
Jon Paul Maloy schrieb:
> 2) The code has been optimized to minimize the number of run-time
>endianness conversion operations by leveraging the fact that the
>mask (and, in some cases, the value as well) is constant and the
>necessary conversion can be performed by the compiler
Hi there,
John W. Linville schrieb:
> From: Johannes Berg <[EMAIL PROTECTED]>
> --- /dev/null
> +++ b/net/wireless/core.c
> @@ -0,0 +1,209 @@
> +/*
> + * This is the linux wireless configuration interface.
> + *
> + * Copyright 2006, 2007 Johannes Berg <[EMAIL PROTECTED]>
> + */
> +
>
The patch went upstream ~24 hours ago:
c43c49bd61fdb9bb085ddafcaadb17d06f95ec43
Upstream is the base for any new patches.
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.o
Export try_to_del_timer_sync() for use by the AF_RXRPC module.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
kernel/timer.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/timer.c b/kernel/timer.c
index dd6c2c1..b22bd39 100644
--- a/kernel/timer.c
+++ b/ke
On Wed, 2007-04-25 at 18:09 +0300, Petko Manolov wrote:
> On Wed, 25 Apr 2007, Dan Williams wrote:
>
> > On Wed, 2007-04-25 at 17:58 +0300, Petko Manolov wrote:
> >> In general i agree with the reasoning below. However, isn't it better to
> >> remove the code that sets carrier on/off in intr_call
Update the AFS fs documentation.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
Documentation/filesystems/afs.txt | 214 +++--
1 files changed, 154 insertions(+), 60 deletions(-)
diff --git a/Documentation/filesystems/afs.txt
b/Documentation/filesystems/a
[NETLINK]: Mirror UDP MSG_TRUNC semantics.
If the user passes MSG_TRUNC in via msg_flags, return
the full packet size not the truncated size.
Idea from Herbert Xu and Thomas Graf.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
net/netlink/af_netlink.c |3 +++
1 file
Add support for the CB.GetCapabilities operation with which the fileserver can
ask the client for the following information:
(1) The list of network interfaces it has available as IPv4 address + netmask
plus the MTUs.
(2) The client's UUID.
(3) The extended capabilities of the client, fo
That patch has xfrm_state_num being mucked with; just ignore that bit.
I need to send a patch against net-2.6.22 and i will clean that up -
just need some feedback.
Would it make sense to have those vars as u32 instead of unsigned int?
cheers,
jamal
-
To unsubscribe from this list: send the lin
Implement the CB.InitCallBackState3 operation for the fileserver to call.
This reduces the amount of network traffic because if this op is aborted, the
fileserver will then attempt an CB.InitCallBackState operation.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
fs/afs/afs_cm.h|1 +
Handle multiple mounts of an AFS superblock correctly, checking to see whether
the superblock is already initialised after calling sget() rather than just
unconditionally stamping all over it.
Also delete the "silent" parameter to afs_fill_super() as it's not used and
can, in any case, be obtained
Move generic skbuff stuff from XFRM code to generic code so that AF_RXRPC can
use it too.
The kdoc comments I've attached to the functions needs to be checked by whoever
wrote them as I had to make some guesses about the workings of these functions.
Signed-Off-By: David Howells <[EMAIL PROTECTED]
Export the keyring key type definition and document its availability.
Add alternative types into the key's type_data union to make it more useful.
Not all users necessarily want to use it as a list_head (AF_RXRPC doesn't, for
example), so make it clear that it can be used in other ways.
Signed-Of
del_timer_sync() buys nothing for cancel_delayed_work(), but it is less
efficient since it locks the timer unconditionally, and may wait for the
completion of the delayed_work_timer_fn().
cancel_delayed_work() == 0 means:
before this patch:
work->func may still be running
The first of these patches together provide secure client-side RxRPC
connectivity as a Linux kernel socket family. Only the RxRPC transport/session
side is supplied - the presentation side (marshalling the data) is left to the
client. Copies of the patches can be found here:
http://peop
Dave,
Something ive been meaning to do since you made the hash changes. I will
be doing one also for policy. Against latest Linus tree because i am
having strange challenges syncing net-2.6.22.
cheers,
jamal
[XFRM] export SAD info
On a system with a lot of SAs, counting SAD entries chews useful
On Wed, 25 Apr 2007, Dan Williams wrote:
On Wed, 2007-04-25 at 17:58 +0300, Petko Manolov wrote:
In general i agree with the reasoning below. However, isn't it better to
remove the code that sets carrier on/off in intr_callback()?
I'm fine with this; whatever makes carrier status work makes
On Wed, 2007-04-25 at 17:58 +0300, Petko Manolov wrote:
> In general i agree with the reasoning below. However, isn't it better to
> remove the code that sets carrier on/off in intr_callback()?
I'm fine with this; whatever makes carrier status work makes me happy :)
Dan
> There's a reliable wa
In general i agree with the reasoning below. However, isn't it better to
remove the code that sets carrier on/off in intr_callback()?
There's a reliable way of getting the link status by reading the MII.
After correct checking of the return value from read_mii_word(),
set_carrier() is what is
> > 08:39:55.493029 IP 12.33.234.69.35026 > 10.2.10.254.22: S
> > 2768979373:2768979373(
> > 0) win 5840
> > 08:39:55.493119 IP 10.2.10.254.22 > 12.33.234.69.35026: S
> > 963242385:963242385(0)
> > ack 2768979374 win 17896
> The MSS clamp for sending to 10.2.10.254.22 is 8960. MSS is
> only
"Ristuccia, Brian" <[EMAIL PROTECTED]> writes:
> I'm seeing a problem where the kernel attempts to send packets with a
> MSS larger than the one negotiated when the TCP connection is
> established. Even after ICMP "can't fragment" messages arrive, the
> kernel still attempts to increase the MSS ra
On Wednesday 25 April 2007 11:52:52 Ismail Dönmez wrote:
> Hi,
>
> On Tuesday 24 April 2007 00:23:13 Ismail Dönmez wrote:
> > On Tuesday 24 April 2007 00:17:40 Thomas Graf wrote:
> > > * Ismail D?nmez <[EMAIL PROTECTED]> 2007-04-23 22:09
> > >
> > > > Yes I know the fix is in but I wondered why its
David Miller <[EMAIL PROTECTED]> wrote:
> Is it possible for your changes to be purely networking
> and not need those changes outside of the networking?
See my latest patchset release. I've reduced the dependencies on
non-networking changes to:
(1) Oleg Nesterov's patch to change cancel_dela
Andrew Morton <[EMAIL PROTECTED]> wrote:
> I'm ducking all feature and cleanup patches now, and probably shall
> continue to do so for some weeks. The priority (which I believe to be
> increasingly urgent) is to fix the 2.6.21 regressions and to stabilise
> the things which we presently have queu
Herbert Xu wrote:
> David Miller <[EMAIL PROTECTED]> wrote:
>
>>I think I see what might be the problem, nlk->cb_mutex is set
>>to "rtnl_mutex" and this is used for other purposes in various
>>code paths here, maybe there is a double mutex_unlock() or
>>similar due to that?
>
>
> Indeed, the RTN
David Miller wrote:
> I think I see what might be the problem, nlk->cb_mutex is set
> to "rtnl_mutex" and this is used for other purposes in various
> code paths here, maybe there is a double mutex_unlock() or
> similar due to that?
Nothing in the callbacks should be touching the rtnl, that would
Dave,
Please consider pulling following commits available on
net-2.6.22-20070425a-inet6-cleanup-20070425
branch at
.
HEADLINES
-
[IPV6] SIT: Unify code path to get hash array index.
[IPV4] IPIP: Unify code path to get hash array index.
[IPV4] IP_GRE: Unify
On Wed, Apr 25, 2007 at 10:27:59AM +0200, Eric Sesterhenn / Snakebyte wrote:
> * Herbert Xu ([EMAIL PROTECTED]) wrote:
> > Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > >
> > > My proposal is: maybe Eric could change this in
> > > xfrm6_tunnel_rcv() from xfrm6_tunnel.c e.g. like this:
> > >
> > >
On Tue, 2007-24-04 at 21:05 -0700, Stephen Hemminger wrote:
> Peter P Waskiewicz Jr wrote:
> Only if this binary compatiable with older kernels.
It is not. But i think that is a lesser problem, the bigger question is:
Why would you need to change a qdisc just so you can support egress
multiqueues
Add support for the CB.GetCapabilities operation with which the fileserver can
ask the client for the following information:
(1) The list of network interfaces it has available as IPv4 address + netmask
plus the MTUs.
(2) The client's UUID.
(3) The extended capabilities of the client, fo
Update the AFS fs documentation.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
Documentation/filesystems/afs.txt | 214 +++--
1 files changed, 154 insertions(+), 60 deletions(-)
diff --git a/Documentation/filesystems/afs.txt
b/Documentation/filesystems/a
Implement the CB.InitCallBackState3 operation for the fileserver to call.
This reduces the amount of network traffic because if this op is aborted, the
fileserver will then attempt an CB.InitCallBackState operation.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
fs/afs/AFS_CM.h|1 +
[NETLINK]: Mirror UDP MSG_TRUNC semantics.
If the user passes MSG_TRUNC in via msg_flags, return
the full packet size not the truncated size.
Idea from Herbert Xu and Thomas Graf.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
net/netlink/af_netlink.c |3 +++
1 file
Handle multiple mounts of an AFS superblock correctly, checking to see whether
the superblock is already initialised after calling sget() rather than just
unconditionally stamping all over it.
Also delete the "silent" parameter to afs_fill_super() as it's not used and
can, in any case, be obtained
Export try_to_del_timer_sync() for use by the AF_RXRPC module.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
kernel/timer.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/timer.c b/kernel/timer.c
index dd6c2c1..b22bd39 100644
--- a/kernel/timer.c
+++ b/ke
del_timer_sync() buys nothing for cancel_delayed_work(), but it is less
efficient since it locks the timer unconditionally, and may wait for the
completion of the delayed_work_timer_fn().
cancel_delayed_work() == 0 means:
before this patch:
work->func may still be running
Move generic skbuff stuff from XFRM code to generic code so that AF_RXRPC can
use it too.
The kdoc comments I've attached to the functions needs to be checked by whoever
wrote them as I had to make some guesses about the workings of these functions.
Signed-Off-By: David Howells <[EMAIL PROTECTED]
Export the keyring key type definition and document its availability.
Add alternative types into the key's type_data union to make it more useful.
Not all users necessarily want to use it as a list_head (AF_RXRPC doesn't, for
example), so make it clear that it can be used in other ways.
Signed-Of
The first of these patches together provide secure client-side RxRPC
connectivity as a Linux kernel socket family. Only the RxRPC transport/session
side is supplied - the presentation side (marshalling the data) is left to the
client. Copies of the patches can be found here:
http://peop
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Ah yes, it says nothing about what the returned value means...
Yeah... If you could amend that as part of your patch, that'd be great.
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTE
On 04/25, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Yes sure. Note that this is documented:
> >
> > /*
> > * Kill off a pending schedule_delayed_work(). Note that the work
> > callback
> > * function may still be running on return from cancel_delayed_
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 nee
Hi,
On Tuesday 24 April 2007 00:23:13 Ismail Dönmez wrote:
> On Tuesday 24 April 2007 00:17:40 Thomas Graf wrote:
> > * Ismail D?nmez <[EMAIL PROTECTED]> 2007-04-23 22:09
> >
> > > Yes I know the fix is in but I wondered why its creating such problems
> > > with 2.6.18 kernel, guess it depends on s
* Herbert Xu ([EMAIL PROTECTED]) wrote:
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> >
> > My proposal is: maybe Eric could change this in
> > xfrm6_tunnel_rcv() from xfrm6_tunnel.c e.g. like this:
> >
> > return xfrm6_rcv_spi(skb, spi) > 0 ? : 0;
> >
> > and, if no errors in testing, he could
1 - 100 of 104 matches
Mail list logo
