* [PATCH] add HAVE_UNREGISTER_NETDEV_QUEUE define for out-of-tree modules
From: Benjamin LaHaise @ 2009-11-10 22:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Hello,
I have an out of tree network driver (GPL'd) that would like to make use of
the unregister_netdevice_queue interface for bulk unregister of devices.
Add a #define HAVE_UNREGISTER_NETDEV_QUEUE to allow the source to detect
that the kernel supports this.
-ben
Signed-off-by: Benjamin LaHaise <bcrl@lhnet.ca
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 465add6..f9e8e0e 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1117,6 +1117,7 @@ extern int dev_close(struct net_device *dev);
extern void dev_disable_lro(struct net_device *dev);
extern int dev_queue_xmit(struct sk_buff *skb);
extern int register_netdevice(struct net_device *dev);
+#define HAVE_UNREGISTER_NETDEV_QUEUE
extern void unregister_netdevice_queue(struct net_device *dev,
struct list_head *head);
extern void unregister_netdevice_many(struct list_head *head);
^ permalink raw reply related
* Re: sunrpc port allocation and IANA reserved list
From: Trond Myklebust @ 2009-11-10 21:58 UTC (permalink / raw)
To: Chris Friesen; +Cc: Ben Hutchings, netdev, Linux kernel
In-Reply-To: <1257887844.3044.24.camel@heimdal.trondhjem.org>
On Wed, 2009-11-11 at 06:17 +0900, Trond Myklebust wrote:
> The people who are trying to run absolutely all IANA registered services
> on a single Linux machine that is also trying to run as an NFS client
> may have a problem, but then again, how many setups do you know who are
> trying to do that?
BTW: Even these setups can be fixed. One way to extend the available
port ranges is to allocate more than one IP address; either through the
use of multiple NICs, or through address aliasing. You can set up the
services to listen on one interface, while setting up your routing
tables to ensure that any outgoing connections to your NFS servers go
through through a different interface.
You could also use virtualised machines to host the services, etc...
Trond
^ permalink raw reply
* Re: sunrpc port allocation and IANA reserved list
From: Chris Friesen @ 2009-11-10 21:54 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Trond Myklebust, netdev, Linux kernel
In-Reply-To: <1257888720.2834.30.camel@achroite.uk.solarflarecom.com>
On 11/10/2009 03:32 PM, Ben Hutchings wrote:
> I'm sure we could afford 128 bytes for a blacklist of privileged ports.
> However, the problem is that there is no API for userland to request
> 'any free privileged port' - it has to just try binding to different
> ports until it finds one available. This means that the kernel can't
> tell whether a process is trying to allocate a specifically assigned
> port or whether the blacklist should be applied.
That's unfortunate. Maybe a bindresvport syscall would make sense, but
that's starting to get bloated. At least for userspace apps netstat
will show who the owner is and it might be possible to clean it up
without rebooting.
For the ports allocated in the kernel via xs_get_random_port() and
xprt_bindresvport() it would be fairly easy to check a blacklist.
Interestingly, the current kernel range starts at 665 because IPMI is
known to use 664. The current glibc range to be tried in bindresvport()
starts at 600, which seems to be a bug waiting to happen.
Chris
^ permalink raw reply
* Re: sunrpc port allocation and IANA reserved list
From: Ben Hutchings @ 2009-11-10 21:42 UTC (permalink / raw)
To: Chuck Lever; +Cc: Chris Friesen, Trond Myklebust, netdev, Linux kernel
In-Reply-To: <212D08D7-AC22-4857-837A-E72B0A11E8DE@oracle.com>
On Tue, 2009-11-10 at 16:34 -0500, Chuck Lever wrote:
> On Nov 10, 2009, at 4:32 PM, Ben Hutchings wrote:
>
> > On Tue, 2009-11-10 at 15:06 -0600, Chris Friesen wrote:
> >> On 11/10/2009 02:26 PM, Trond Myklebust wrote:
[...]
> >>> Just use /proc/sys/sunrpc/{max,min}_resvport interface to restrict
> >>> the
> >>> range used to a safer one. That's what it is for...
> >
> > Unless I'm much mistaken, that only affects in-kernel SunRPC users.
> >
> >> What constitutes a "safer range"? IANA has ports assigned
> >> intermittently all the way through the default RPC range. The
> >> largest
> >> unassigned range is 922-988 (since 921 is used by lwresd). If
> >> someone
> >> needs more than 66 ports, how are they supposed to handle it?
> >
> > I'm sure we could afford 128 bytes for a blacklist of privileged
> > ports.
> > However, the problem is that there is no API for userland to request
> > 'any free privileged port' - it has to just try binding to different
> > ports until it finds one available.
>
> bindresvport(3) and bindresvport_sa(3t) ?
These are library calls; they are not an API between userland the
kernel.
> > This means that the kernel can't
> > tell whether a process is trying to allocate a specifically assigned
> > port or whether the blacklist should be applied.
>
> Such a blacklist would have to be managed by glibc or libtirpc.
Right.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [RFC PATCH] net: add dataref destructor to sk_buff
From: Evgeniy Polyakov @ 2009-11-10 21:40 UTC (permalink / raw)
To: Gregory Haskins
Cc: Michael S. Tsirkin, alacrityvm-devel, herbert.xu, linux-kernel,
netdev
In-Reply-To: <4AF9B2A7.3050802@novell.com>
On Tue, Nov 10, 2009 at 01:36:23PM -0500, Gregory Haskins (ghaskins@novell.com) wrote:
> What about things like sendfile()? There has to be *some* way to
> synchronize with the io-completion event, I would think. Whatever that
> is, I'd like to tap into it.
All skb manipulation functions properly maintain data reference
counters, so pages will not be freed until all data is consumed.
But there is no guarantee that data placed in given page will not be
overwritten while page is being held somewhere in the stack.
Putting shared info destructor will allow to get notification, that
given shared info processing is over, i.e. that network stack does not
use data placed in shared info for given skb, but if it was copied or
VFS hold those pages, they may or may not be freed.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: sunrpc port allocation and IANA reserved list
From: Chuck Lever @ 2009-11-10 21:34 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Chris Friesen, Trond Myklebust, netdev, Linux kernel
In-Reply-To: <1257888720.2834.30.camel@achroite.uk.solarflarecom.com>
On Nov 10, 2009, at 4:32 PM, Ben Hutchings wrote:
> On Tue, 2009-11-10 at 15:06 -0600, Chris Friesen wrote:
>> On 11/10/2009 02:26 PM, Trond Myklebust wrote:
>>> On Tue, 2009-11-10 at 12:37 -0600, Chris Friesen wrote:
>>>> On 11/10/2009 11:53 AM, Ben Hutchings wrote:
>>>>> On Tue, 2009-11-10 at 11:43 -0600, Chris Friesen wrote:
>>>>
>>>>>> Given that a userspace application can be stopped and restarted
>>>>>> at any
>>>>>> time, and a sunrpc registration can happen at any time, what is
>>>>>> the
>>>>>> expected mechanism to prevent the kernel from allocating a port
>>>>>> for use
>>>>>> by sunrpc that reserved or well-known?
>>>>>>
>>>>>> Apparently Redhat and Debian have distro-specific ways of
>>>>>> dealing with
>>>>>> this, but is there a standard solution? Should there be?
>>>>>>
>>>>>> The current setup seems suboptimal.
>>>>>
>>>>> I believe both RH and Debian are using the same implementation:
>>>>> <http://cyberelk.net/tim/software/portreserve/>.
>>>>
>>>> That helps with the startup case, but still leaves a possible
>>>> hole if an
>>>> app using a fixed port number is restarted at runtime. During the
>>>> window where nobody is bound to the port, the kernel could randomly
>>>> assign it to someone else.
>>>
>>> Just use /proc/sys/sunrpc/{max,min}_resvport interface to restrict
>>> the
>>> range used to a safer one. That's what it is for...
>
> Unless I'm much mistaken, that only affects in-kernel SunRPC users.
>
>> What constitutes a "safer range"? IANA has ports assigned
>> intermittently all the way through the default RPC range. The
>> largest
>> unassigned range is 922-988 (since 921 is used by lwresd). If
>> someone
>> needs more than 66 ports, how are they supposed to handle it?
>
> I'm sure we could afford 128 bytes for a blacklist of privileged
> ports.
> However, the problem is that there is no API for userland to request
> 'any free privileged port' - it has to just try binding to different
> ports until it finds one available.
bindresvport(3) and bindresvport_sa(3t) ?
> This means that the kernel can't
> tell whether a process is trying to allocate a specifically assigned
> port or whether the blacklist should be applied.
Such a blacklist would have to be managed by glibc or libtirpc.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* Re: sunrpc port allocation and IANA reserved list
From: Ben Hutchings @ 2009-11-10 21:32 UTC (permalink / raw)
To: Chris Friesen; +Cc: Trond Myklebust, netdev, Linux kernel
In-Reply-To: <4AF9D5D1.9040501@nortel.com>
On Tue, 2009-11-10 at 15:06 -0600, Chris Friesen wrote:
> On 11/10/2009 02:26 PM, Trond Myklebust wrote:
> > On Tue, 2009-11-10 at 12:37 -0600, Chris Friesen wrote:
> >> On 11/10/2009 11:53 AM, Ben Hutchings wrote:
> >>> On Tue, 2009-11-10 at 11:43 -0600, Chris Friesen wrote:
> >>
> >>>> Given that a userspace application can be stopped and restarted at any
> >>>> time, and a sunrpc registration can happen at any time, what is the
> >>>> expected mechanism to prevent the kernel from allocating a port for use
> >>>> by sunrpc that reserved or well-known?
> >>>>
> >>>> Apparently Redhat and Debian have distro-specific ways of dealing with
> >>>> this, but is there a standard solution? Should there be?
> >>>>
> >>>> The current setup seems suboptimal.
> >>>
> >>> I believe both RH and Debian are using the same implementation:
> >>> <http://cyberelk.net/tim/software/portreserve/>.
> >>
> >> That helps with the startup case, but still leaves a possible hole if an
> >> app using a fixed port number is restarted at runtime. During the
> >> window where nobody is bound to the port, the kernel could randomly
> >> assign it to someone else.
> >
> > Just use /proc/sys/sunrpc/{max,min}_resvport interface to restrict the
> > range used to a safer one. That's what it is for...
Unless I'm much mistaken, that only affects in-kernel SunRPC users.
> What constitutes a "safer range"? IANA has ports assigned
> intermittently all the way through the default RPC range. The largest
> unassigned range is 922-988 (since 921 is used by lwresd). If someone
> needs more than 66 ports, how are they supposed to handle it?
I'm sure we could afford 128 bytes for a blacklist of privileged ports.
However, the problem is that there is no API for userland to request
'any free privileged port' - it has to just try binding to different
ports until it finds one available. This means that the kernel can't
tell whether a process is trying to allocate a specifically assigned
port or whether the blacklist should be applied.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH resent] Documentation: rw_lock lessons learned
From: Paul E. McKenney @ 2009-11-10 21:22 UTC (permalink / raw)
To: William Allen Simpson
Cc: Linux Kernel Developers, Linux Kernel Network Developers,
Eric Dumazet
In-Reply-To: <4AF9C540.5090403@gmail.com>
On Tue, Nov 10, 2009 at 02:55:44PM -0500, William Allen Simpson wrote:
> In recent weeks, two different network projects erroneously
> strayed down the rw_lock path. Update the Documentation
> based upon comments in those threads.
>
> Signed-off-by: William.Allen.Simpson@gmail.com
> ---
> Documentation/spinlocks.txt | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt
> index 619699d..c112052 100644
> --- a/Documentation/spinlocks.txt
> +++ b/Documentation/spinlocks.txt
> @@ -233,4 +233,18 @@ indeed), while write-locks need to protect themselves against interrupts.
>
> Linus
As you might guess, works for me!!!
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> +----
> +
> +The implications of spin_locks on memory are further described in:
> +
> + Documentation/memory-barriers.txt
> + (5) LOCK operations.
> + (6) UNLOCK operations.
> +
> +----
> +
> +We are working hard to remove reader-writer spinlocks (rw_lock) from the
> +network stack, so please don't add a new one. Instead, see:
> +
> + Documentation/RCU/rcu.txt
>
> --
> 1.6.3.3
>
>
^ permalink raw reply
* Re: sunrpc port allocation and IANA reserved list
From: Trond Myklebust @ 2009-11-10 21:17 UTC (permalink / raw)
To: Chris Friesen; +Cc: Ben Hutchings, netdev, Linux kernel
In-Reply-To: <4AF9D5D1.9040501@nortel.com>
On Tue, 2009-11-10 at 15:06 -0600, Chris Friesen wrote:
> On 11/10/2009 02:26 PM, Trond Myklebust wrote:
> > On Tue, 2009-11-10 at 12:37 -0600, Chris Friesen wrote:
> >> On 11/10/2009 11:53 AM, Ben Hutchings wrote:
> >>> On Tue, 2009-11-10 at 11:43 -0600, Chris Friesen wrote:
> >>
> >>>> Given that a userspace application can be stopped and restarted at any
> >>>> time, and a sunrpc registration can happen at any time, what is the
> >>>> expected mechanism to prevent the kernel from allocating a port for use
> >>>> by sunrpc that reserved or well-known?
> >>>>
> >>>> Apparently Redhat and Debian have distro-specific ways of dealing with
> >>>> this, but is there a standard solution? Should there be?
> >>>>
> >>>> The current setup seems suboptimal.
> >>>
> >>> I believe both RH and Debian are using the same implementation:
> >>> <http://cyberelk.net/tim/software/portreserve/>.
> >>
> >> That helps with the startup case, but still leaves a possible hole if an
> >> app using a fixed port number is restarted at runtime. During the
> >> window where nobody is bound to the port, the kernel could randomly
> >> assign it to someone else.
> >
> > Just use /proc/sys/sunrpc/{max,min}_resvport interface to restrict the
> > range used to a safer one. That's what it is for...
>
> What constitutes a "safer range"? IANA has ports assigned
> intermittently all the way through the default RPC range. The largest
> unassigned range is 922-988 (since 921 is used by lwresd). If someone
> needs more than 66 ports, how are they supposed to handle it?
Distributions can, and should, set the default to whatever range that
constitutes a broad percentile of their customers, and then leave
instructions on how to change that default for the people who run the
funky setups.
The people who are trying to run absolutely all IANA registered services
on a single Linux machine that is also trying to run as an NFS client
may have a problem, but then again, how many setups do you know who are
trying to do that?
Trond
^ permalink raw reply
* Re: sunrpc port allocation and IANA reserved list
From: Chris Friesen @ 2009-11-10 21:06 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Ben Hutchings, netdev, Linux kernel
In-Reply-To: <1257884799.3044.7.camel@heimdal.trondhjem.org>
On 11/10/2009 02:26 PM, Trond Myklebust wrote:
> On Tue, 2009-11-10 at 12:37 -0600, Chris Friesen wrote:
>> On 11/10/2009 11:53 AM, Ben Hutchings wrote:
>>> On Tue, 2009-11-10 at 11:43 -0600, Chris Friesen wrote:
>>
>>>> Given that a userspace application can be stopped and restarted at any
>>>> time, and a sunrpc registration can happen at any time, what is the
>>>> expected mechanism to prevent the kernel from allocating a port for use
>>>> by sunrpc that reserved or well-known?
>>>>
>>>> Apparently Redhat and Debian have distro-specific ways of dealing with
>>>> this, but is there a standard solution? Should there be?
>>>>
>>>> The current setup seems suboptimal.
>>>
>>> I believe both RH and Debian are using the same implementation:
>>> <http://cyberelk.net/tim/software/portreserve/>.
>>
>> That helps with the startup case, but still leaves a possible hole if an
>> app using a fixed port number is restarted at runtime. During the
>> window where nobody is bound to the port, the kernel could randomly
>> assign it to someone else.
>
> Just use /proc/sys/sunrpc/{max,min}_resvport interface to restrict the
> range used to a safer one. That's what it is for...
What constitutes a "safer range"? IANA has ports assigned
intermittently all the way through the default RPC range. The largest
unassigned range is 922-988 (since 921 is used by lwresd). If someone
needs more than 66 ports, how are they supposed to handle it?
Chris
^ permalink raw reply
* Re: sunrpc port allocation and IANA reserved list
From: Trond Myklebust @ 2009-11-10 20:26 UTC (permalink / raw)
To: Chris Friesen; +Cc: Ben Hutchings, netdev, Linux kernel
In-Reply-To: <4AF9B2CF.6050305@nortel.com>
On Tue, 2009-11-10 at 12:37 -0600, Chris Friesen wrote:
> On 11/10/2009 11:53 AM, Ben Hutchings wrote:
> > On Tue, 2009-11-10 at 11:43 -0600, Chris Friesen wrote:
>
> >> Given that a userspace application can be stopped and restarted at any
> >> time, and a sunrpc registration can happen at any time, what is the
> >> expected mechanism to prevent the kernel from allocating a port for use
> >> by sunrpc that reserved or well-known?
> >>
> >> Apparently Redhat and Debian have distro-specific ways of dealing with
> >> this, but is there a standard solution? Should there be?
> >>
> >> The current setup seems suboptimal.
> >
> > I believe both RH and Debian are using the same implementation:
> > <http://cyberelk.net/tim/software/portreserve/>.
>
> That helps with the startup case, but still leaves a possible hole if an
> app using a fixed port number is restarted at runtime. During the
> window where nobody is bound to the port, the kernel could randomly
> assign it to someone else.
Just use /proc/sys/sunrpc/{max,min}_resvport interface to restrict the
range used to a safer one. That's what it is for...
Trond
^ permalink raw reply
* Re: [PATCH 04/10] AOE: use rcu to find network device
From: Ed Cashin @ 2009-11-10 20:01 UTC (permalink / raw)
To: shemminger, davem, ecashin, harvey.harrison, bzolnier, netdev
In-Reply-To: <20091110175647.409162953@vyatta.com>
On Tue Nov 10 13:07:37 EST 2009, shemminger@vyatta.com wrote:
> This gets rid of another use of read_lock(&dev_base_lock) by using
> RCU. Also, it only increments the reference count of the device actually
> used rather than holding and releasing every device
>
> Compile tested only.
This function runs once a minute when the aoe driver is loaded,
if you'd like to test it a bit more.
It looks like there's no dev_put corresponding to the dev_hold
after the changes.
--
Ed
^ permalink raw reply
* [PATCH resent] Documentation: rw_lock lessons learned
From: William Allen Simpson @ 2009-11-10 19:55 UTC (permalink / raw)
To: Linux Kernel Developers, Linux Kernel Network Developers
Cc: Eric Dumazet, Paul E. McKenney
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
In recent weeks, two different network projects erroneously
strayed down the rw_lock path. Update the Documentation
based upon comments in those threads.
Signed-off-by: William.Allen.Simpson@gmail.com
---
Documentation/spinlocks.txt | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
[-- Attachment #2: spinlocks.txt.patch --]
[-- Type: text/plain, Size: 639 bytes --]
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt
index 619699d..c112052 100644
--- a/Documentation/spinlocks.txt
+++ b/Documentation/spinlocks.txt
@@ -233,4 +233,18 @@ indeed), while write-locks need to protect themselves against interrupts.
Linus
+----
+
+The implications of spin_locks on memory are further described in:
+
+ Documentation/memory-barriers.txt
+ (5) LOCK operations.
+ (6) UNLOCK operations.
+
+----
+
+We are working hard to remove reader-writer spinlocks (rw_lock) from the
+network stack, so please don't add a new one. Instead, see:
+
+ Documentation/RCU/rcu.txt
--
1.6.3.3
^ permalink raw reply related
* [PATCH] net: TCP_MSS_DEFAULT, TCP_MSS_DESIRED
From: William Allen Simpson @ 2009-11-10 19:51 UTC (permalink / raw)
To: Linux Kernel Network Developers
[-- Attachment #1: Type: text/plain, Size: 686 bytes --]
Define two symbols needed in both kernel and user space.
Remove old (somewhat incorrect) kernel variant that wasn't used in
most cases. Default should apply to both RMSS and SMSS (RFC2581).
Replace numeric constants with defined symbols.
Stand-alone patch, originally developed for TCPCT.
Signed-off-by: William.Allen.Simpson@gmail.com
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/tcp.h | 6 ++++++
include/net/tcp.h | 3 ---
net/ipv4/tcp_input.c | 4 ++--
net/ipv4/tcp_ipv4.c | 6 +++---
net/ipv4/tcp_minisocks.c | 2 +-
net/ipv6/tcp_ipv6.c | 2 +-
6 files changed, 13 insertions(+), 10 deletions(-)
[-- Attachment #2: TCP_MSSv1.patch --]
[-- Type: text/plain, Size: 4017 bytes --]
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index eeecb85..32d7d77 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -81,6 +81,12 @@ enum {
TCP_DATA_OFFSET = __cpu_to_be32(0xF0000000)
};
+/*
+ * TCP general constants
+ */
+#define TCP_MSS_DEFAULT 536U /* IPv4 (RFC1122, RFC2581) */
+#define TCP_MSS_DESIRED 1220U /* IPv6 (tunneled), EDNS0 (RFC3226) */
+
/* TCP socket options */
#define TCP_NODELAY 1 /* Turn off Nagle's algorithm. */
#define TCP_MAXSEG 2 /* Limit MSS */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 25bf3ba..a413e9f 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -62,9 +62,6 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
/* Minimal accepted MSS. It is (60+60+8) - (20+20). */
#define TCP_MIN_MSS 88U
-/* Minimal RCV_MSS. */
-#define TCP_MIN_RCVMSS 536U
-
/* The least MTU to use for probing */
#define TCP_BASE_MSS 512
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index be0c5bf..cc306ac 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -140,7 +140,7 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb)
* "len" is invariant segment length, including TCP header.
*/
len += skb->data - skb_transport_header(skb);
- if (len >= TCP_MIN_RCVMSS + sizeof(struct tcphdr) ||
+ if (len >= TCP_MSS_DEFAULT + sizeof(struct tcphdr) ||
/* If PSH is not set, packet should be
* full sized, provided peer TCP is not badly broken.
* This observation (if it is correct 8)) allows
@@ -411,7 +411,7 @@ void tcp_initialize_rcv_mss(struct sock *sk)
unsigned int hint = min_t(unsigned int, tp->advmss, tp->mss_cache);
hint = min(hint, tp->rcv_wnd / 2);
- hint = min(hint, TCP_MIN_RCVMSS);
+ hint = min(hint, TCP_MSS_DEFAULT);
hint = max(hint, TCP_MIN_MSS);
inet_csk(sk)->icsk_ack.rcv_mss = hint;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index f83ac91..0718fde 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -217,7 +217,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
if (inet->opt)
inet_csk(sk)->icsk_ext_hdr_len = inet->opt->optlen;
- tp->rx_opt.mss_clamp = 536;
+ tp->rx_opt.mss_clamp = TCP_MSS_DEFAULT;
/* Socket identity is still unknown (sport may be zero).
* However we set state to SYN-SENT and not releasing socket
@@ -1270,7 +1270,7 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
goto drop_and_free;
tcp_clear_options(&tmp_opt);
- tmp_opt.mss_clamp = 536;
+ tmp_opt.mss_clamp = TCP_MSS_DEFAULT;
tmp_opt.user_mss = tcp_sk(sk)->rx_opt.user_mss;
tcp_parse_options(skb, &tmp_opt, 0, dst);
@@ -1818,7 +1818,7 @@ static int tcp_v4_init_sock(struct sock *sk)
*/
tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
tp->snd_cwnd_clamp = ~0;
- tp->mss_cache = 536;
+ tp->mss_cache = TCP_MSS_DEFAULT;
tp->reordering = sysctl_tcp_reordering;
icsk->icsk_ca_ops = &tcp_init_congestion_ops;
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index fb68bab..7a42990 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -476,7 +476,7 @@ struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req,
if (newtp->af_specific->md5_lookup(sk, newsk))
newtp->tcp_header_len += TCPOLEN_MD5SIG_ALIGNED;
#endif
- if (skb->len >= TCP_MIN_RCVMSS+newtp->tcp_header_len)
+ if (skb->len >= TCP_MSS_DEFAULT + newtp->tcp_header_len)
newicsk->icsk_ack.last_seg_size = skb->len - newtp->tcp_header_len;
newtp->rx_opt.mss_clamp = req->mss;
TCP_ECN_openreq_child(newtp, req);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 6951827..b528f75 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1849,7 +1849,7 @@ static int tcp_v6_init_sock(struct sock *sk)
*/
tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
tp->snd_cwnd_clamp = ~0;
- tp->mss_cache = 536;
+ tp->mss_cache = TCP_MSS_DEFAULT;
tp->reordering = sysctl_tcp_reordering;
--
1.6.3.3
^ permalink raw reply related
* [PATCH] s2io: fixing a ethtool test that is broken
From: leitao @ 2009-11-10 19:44 UTC (permalink / raw)
To: netdev; +Cc: sreenivasa.honnur, Breno Leitao
Due commit 4b77b0a2ba27d64f58f16d8d4d48d8319dda36ff, it is not more
possible to pci_restore_state() more than once without calling
pci_save_state() in the middle.
Actually running a ethtool test on s2io makes the card inactive,
and it needs to unload/reload the module to fix.
This patch just save the state just after it restore in order to
keep the old behaviour
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
---
drivers/net/s2io.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index ddccf5f..0dd7839 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -3494,6 +3494,7 @@ static void s2io_reset(struct s2io_nic *sp)
/* Restore the PCI state saved during initialization. */
pci_restore_state(sp->pdev);
+ pci_save_state(sp->pdev);
pci_read_config_word(sp->pdev, 0x2, &val16);
if (check_pci_device_id(val16) != (u16)PCI_ANY_ID)
break;
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo()
From: Wolfgang Grandegger @ 2009-11-10 19:45 UTC (permalink / raw)
To: Patrick McHardy
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <4AF94D74.4040606-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
Patrick McHardy wrote:
> Wolfgang Grandegger wrote:
>> David Miller wrote:
>>> From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>>> Date: Sat, 07 Nov 2009 10:53:13 +0100
>>>
>>>> On older kernels, e.g. 2.6.27, a WARN_ON dump in rtmsg_ifinfo()
>>>> is thrown when the CAN device is registered due to insufficient
>>>> skb space, as reported by various users. This patch adds the
>>>> rtnl_link_ops "get_size" to fix the problem. I think this patch
>>>> is required for more recent kernels as well, even if no WARN_ON
>>>> dumps are triggered. Maybe we also need "get_xstats_size" for
>>>> the CAN xstats.
>>>>
>>>> Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>>> Applied to net-2.6, thanks Wolfgang.
>> Thanks, the commit message included some questions. What is the rule
>> using the rtnl_link_ops "get_size" or "get_xstats_size". Are these
>> mandatory if the corresponding fill functions are used?
>
> Yes. You also need a get_xstats_size() function.
Thanks for clarification. I will provide a patch a.s.a.p.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 01/10] netdev: add netdev_continue_rcu
From: Paul E. McKenney @ 2009-11-10 19:39 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20091110175647.200655064@vyatta.com>
On Tue, Nov 10, 2009 at 09:54:47AM -0800, Stephen Hemminger wrote:
> This adds an RCU macro for continuing search, useful for some
> network devices like vlan.
Looks good!!!
Of course, you need to either have a single RCU read-side critical section
cover all the chained list_for_each_entry_continue_rcu() invocations, or
you need to do something (e.g., reference count) to make sure that the
element in question doesn't disappear in the meantime, right?
Thanx, Paul
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> --- a/include/linux/netdevice.h 2009-11-09 22:19:08.511480873 -0800
> +++ b/include/linux/netdevice.h 2009-11-10 09:27:17.973376267 -0800
> @@ -1079,6 +1079,8 @@ extern rwlock_t dev_base_lock; /* De
> list_for_each_entry_safe(d, n, &(net)->dev_base_head, dev_list)
> #define for_each_netdev_continue(net, d) \
> list_for_each_entry_continue(d, &(net)->dev_base_head, dev_list)
> +#define for_each_netdev_continue_rcu(net, d) \
> + list_for_each_entry_continue_rcu(d, &(net)->dev_base_head, dev_list)
> #define net_device_entry(lh) list_entry(lh, struct net_device, dev_list)
>
> static inline struct net_device *next_net_device(struct net_device *dev)
> --- a/include/linux/rculist.h 2009-11-09 22:19:08.529480859 -0800
> +++ b/include/linux/rculist.h 2009-11-10 09:27:17.974376609 -0800
> @@ -262,6 +262,20 @@ static inline void list_splice_init_rcu(
> (pos) = rcu_dereference((pos)->next))
>
> /**
> + * list_for_each_entry_continue_rcu - continue iteration over list of given type
> + * @pos: the type * to use as a loop cursor.
> + * @head: the head for your list.
> + * @member: the name of the list_struct within the struct.
> + *
> + * Continue to iterate over list of given type, continuing after
> + * the current position.
> + */
> +#define list_for_each_entry_continue_rcu(pos, head, member) \
> + for (pos = list_entry_rcu(pos->member.next, typeof(*pos), member); \
> + prefetch(pos->member.next), &pos->member != (head); \
> + pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
> +
> +/**
> * hlist_del_rcu - deletes entry from hash list without re-initialization
> * @n: the element to delete from the hash list.
> *
>
> --
>
^ permalink raw reply
* Re: [PATCH 07/10] decnet: use RCU to find network devices
From: steve @ 2009-11-10 18:24 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Eric Dumazet, David Miller, Christine Caulfield, Hannes Eder,
Alexey Dobriyan, Steven Whitehouse, netdev, linux-decnet-users
In-Reply-To: <20091110105053.16687e93@nehalam>
Hi,
On Tue, Nov 10, 2009 at 10:50:53AM -0800, Stephen Hemminger wrote:
> On Tue, 10 Nov 2009 19:43:21 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Stephen Hemminger a écrit :
> > > When showing device statistics use RCU rather than read_lock(&dev_base_lock)
> > > Compile tested only.
> > >
> > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> > >
> > > --- a/net/decnet/dn_dev.c 2009-11-10 09:30:55.557376454 -0800
> > > +++ b/net/decnet/dn_dev.c 2009-11-10 09:40:03.847005394 -0800
> > > @@ -856,9 +856,7 @@ int dn_dev_bind_default(__le16 *addr)
> > > dev = dn_dev_get_default();
> > > last_chance:
> > > if (dev) {
> > > - read_lock(&dev_base_lock);
> > > rv = dn_dev_get_first(dev, addr);
> > > - read_unlock(&dev_base_lock);
> > > dev_put(dev);
> > > if (rv == 0 || dev == init_net.loopback_dev)
> > > return rv;
> > > @@ -1323,18 +1321,18 @@ static inline int is_dn_dev(struct net_d
> >
> >
> > I dont understand this part. Why previous locking can be avoided ?
>
> dn_dev_get_default acquires a reference on dev so the device can
> not go away.
>
> It could be the original author meant to ensure the address list
> doesn't change. If so, then rtnl_lock() should have been used.
The original author has tried to remember what he was thinking when
he wrote this code :-)
I think you are right that it should be rtnl_lock() as we don't want
the address list changing at this point. On the other hand I notice
also that other bits of the code seem to be using dev_base_lock too.
Maybe this is a hang over from another era? I'll have to refresh
my memory some more before I can give a verdict on that I'm afraid,
Steve.
^ permalink raw reply
* Re: [PATCH 07/10] decnet: use RCU to find network devices
From: Eric Dumazet @ 2009-11-10 19:25 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, Christine Caulfield, Hannes Eder, Alexey Dobriyan,
Steven Whitehouse, netdev, linux-decnet-users
In-Reply-To: <20091110105053.16687e93@nehalam>
Stephen Hemminger a écrit :
> On Tue, 10 Nov 2009 19:43:21 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> Stephen Hemminger a écrit :
>>> When showing device statistics use RCU rather than read_lock(&dev_base_lock)
>>> Compile tested only.
>>>
>>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>>>
>>> --- a/net/decnet/dn_dev.c 2009-11-10 09:30:55.557376454 -0800
>>> +++ b/net/decnet/dn_dev.c 2009-11-10 09:40:03.847005394 -0800
>>> @@ -856,9 +856,7 @@ int dn_dev_bind_default(__le16 *addr)
>>> dev = dn_dev_get_default();
>>> last_chance:
>>> if (dev) {
>>> - read_lock(&dev_base_lock);
>>> rv = dn_dev_get_first(dev, addr);
>>> - read_unlock(&dev_base_lock);
>>> dev_put(dev);
>>> if (rv == 0 || dev == init_net.loopback_dev)
>>> return rv;
>>> @@ -1323,18 +1321,18 @@ static inline int is_dn_dev(struct net_d
>>
>> I dont understand this part. Why previous locking can be avoided ?
>
> dn_dev_get_default acquires a reference on dev so the device can
> not go away.
>
> It could be the original author meant to ensure the address list
> doesn't change. If so, then rtnl_lock() should have been used.
Hmm... I spot some bugs during my previous round of patches, so maybe
this is a real bug... We should double check.
^ permalink raw reply
* Re: [PATCH 40/75] cxgb3: declare MODULE_FIRMWARE
From: Divy Le Ray @ 2009-11-10 19:19 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1257630832.15927.440.camel@localhost>
On Saturday 07 November 2009 01:53:52 pm Ben Hutchings wrote:
> Replace run-time string formatting with preprocessor string
> manipulation.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Acked-by: Divy Le Ray <divy@chelsio.com>
> ---
> drivers/net/cxgb3/common.h | 8 +++-----
> drivers/net/cxgb3/cxgb3_main.c | 25 ++++++++++++++++---------
> 2 files changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
> index 1b2c305..6ff356d 100644
> --- a/drivers/net/cxgb3/common.h
> +++ b/drivers/net/cxgb3/common.h
> @@ -125,11 +125,9 @@ enum { /* adapter interrupt-maintained statistics
> */ IRQ_NUM_STATS /* keep last */
> };
>
> -enum {
> - TP_VERSION_MAJOR = 1,
> - TP_VERSION_MINOR = 1,
> - TP_VERSION_MICRO = 0
> -};
> +#define TP_VERSION_MAJOR 1
> +#define TP_VERSION_MINOR 1
> +#define TP_VERSION_MICRO 0
>
> #define S_TP_VERSION_MAJOR 16
> #define M_TP_VERSION_MAJOR 0xFF
> diff --git a/drivers/net/cxgb3/cxgb3_main.c
> b/drivers/net/cxgb3/cxgb3_main.c index c9113d3..b1a5a00 100644
> --- a/drivers/net/cxgb3/cxgb3_main.c
> +++ b/drivers/net/cxgb3/cxgb3_main.c
> @@ -44,6 +44,7 @@
> #include <linux/rtnetlink.h>
> #include <linux/firmware.h>
> #include <linux/log2.h>
> +#include <linux/stringify.h>
> #include <asm/uaccess.h>
>
> #include "common.h"
> @@ -992,11 +993,21 @@ static int bind_qsets(struct adapter *adap)
> return err;
> }
>
> -#define FW_FNAME "cxgb3/t3fw-%d.%d.%d.bin"
> -#define TPSRAM_NAME "cxgb3/t3%c_psram-%d.%d.%d.bin"
> +#define FW_VERSION __stringify(FW_VERSION_MAJOR) "." \
> + __stringify(FW_VERSION_MINOR) "." __stringify(FW_VERSION_MICRO)
> +#define FW_FNAME "cxgb3/t3fw-" FW_VERSION ".bin"
> +#define TPSRAM_VERSION __stringify(TP_VERSION_MAJOR) "." \
> + __stringify(TP_VERSION_MINOR) "." __stringify(TP_VERSION_MICRO)
> +#define TPSRAM_NAME "cxgb3/t3%c_psram-" TPSRAM_VERSION ".bin"
> #define AEL2005_OPT_EDC_NAME "cxgb3/ael2005_opt_edc.bin"
> #define AEL2005_TWX_EDC_NAME "cxgb3/ael2005_twx_edc.bin"
> #define AEL2020_TWX_EDC_NAME "cxgb3/ael2020_twx_edc.bin"
> +MODULE_FIRMWARE(FW_FNAME);
> +MODULE_FIRMWARE("cxgb3/t3b_psram-" TPSRAM_VERSION ".bin");
> +MODULE_FIRMWARE("cxgb3/t3c_psram-" TPSRAM_VERSION ".bin");
> +MODULE_FIRMWARE(AEL2005_OPT_EDC_NAME);
> +MODULE_FIRMWARE(AEL2005_TWX_EDC_NAME);
> +MODULE_FIRMWARE(AEL2020_TWX_EDC_NAME);
>
> static inline const char *get_edc_fw_name(int edc_idx)
> {
> @@ -1067,16 +1078,13 @@ int t3_get_edc_fw(struct cphy *phy, int edc_idx,
> int size) static int upgrade_fw(struct adapter *adap)
> {
> int ret;
> - char buf[64];
> const struct firmware *fw;
> struct device *dev = &adap->pdev->dev;
>
> - snprintf(buf, sizeof(buf), FW_FNAME, FW_VERSION_MAJOR,
> - FW_VERSION_MINOR, FW_VERSION_MICRO);
> - ret = request_firmware(&fw, buf, dev);
> + ret = request_firmware(&fw, FW_FNAME, dev);
> if (ret < 0) {
> dev_err(dev, "could not upgrade firmware: unable to load %s\n",
> - buf);
> + FW_FNAME);
> return ret;
> }
> ret = t3_load_fw(adap, fw->data, fw->size);
> @@ -1120,8 +1128,7 @@ static int update_tpsram(struct adapter *adap)
> if (!rev)
> return 0;
>
> - snprintf(buf, sizeof(buf), TPSRAM_NAME, rev,
> - TP_VERSION_MAJOR, TP_VERSION_MINOR, TP_VERSION_MICRO);
> + snprintf(buf, sizeof(buf), TPSRAM_NAME, rev);
>
> ret = request_firmware(&tpsram, buf, dev);
> if (ret < 0) {
>
^ permalink raw reply
* More info on SO_TIMESTAMPING problems in V6
From: Marcus D. Leech @ 2009-11-10 19:03 UTC (permalink / raw)
To: netdev; +Cc: patrick.ohly
It looks like there *isn't* support on the V6 side for SO_TIMESTAMPING.
The ipv6/udp.c calls the V4 udp_sendmsg when the packet is a "V4 on a
V6 socket", but otherwise
the necessary "goop" doesn't appear to be implemented for V6.
In particular, the V4 udp_sendmsg function has a structure, ipcm_cookie,
which appears to
be used to carry the shtx flags, including the "hardware" flag that
indicates hardware
timestamping. It's not clear exactly where this gets "attached" to
the outgoing SKB, but
none of this appears in the V6 version of udp.c
While the V6 udp.c is quite *similar* to the V4 version, some of the
data structures are
quite different, and it's not clear to me where to begin. Further, I
got a note from Patrick
Ohly indicating that the e1000 driver guys at Intel have been the
ones maintaining the
SO_TIMESTAMPING code, so I don't want to replicate work that may
already be in-progress/
done.
Looking at even the latest kernel code, there's no hint that this has
been addressed.
Also, there's no hint of implementation for net/packet (AF_PACKET).
The context of all this is a PTPV2 (IEEE1588-2008) implementation that
requires hardware time-stamping support for all three of: IPV4, IPV6,
and ETHERNET (AF_PACKET/SOCK_DGRAM).
I've been testing with IPV4 exclusively, and it has been working quite well.
^ permalink raw reply
* [PATCH] sctp: Set source addresses on the association before adding transports
From: Vlad Yasevich @ 2009-11-10 18:57 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-sctp, Vlad Yasevich
Recent commit 8da645e101a8c20c6073efda3c7cc74eec01b87f
sctp: Get rid of an extra routing lookup when adding a transport
introduced a regression in the connection setup. The behavior was
different between IPv4 and IPv6. IPv4 case ended up working because the
route lookup routing returned a NULL route, which triggered another
route lookup later in the output patch that succeeded. In the IPv6 case,
a valid route was returned for first call, but we could not find a valid
source address at the time since the source addresses were not set on the
association yet. Thus resulted in a hung connection.
The solution is to set the source addresses on the association prior to
adding peers.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
---
include/net/sctp/structs.h | 2 +-
net/sctp/associola.c | 4 +---
net/sctp/sm_statefuns.c | 15 +++++++++------
net/sctp/socket.c | 22 ++++++++++++----------
4 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 6e5f0e0..cd2e187 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -1980,7 +1980,7 @@ void sctp_assoc_set_primary(struct sctp_association *,
void sctp_assoc_del_nonprimary_peers(struct sctp_association *,
struct sctp_transport *);
int sctp_assoc_set_bind_addr_from_ep(struct sctp_association *,
- gfp_t);
+ sctp_scope_t, gfp_t);
int sctp_assoc_set_bind_addr_from_cookie(struct sctp_association *,
struct sctp_cookie*,
gfp_t gfp);
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 8450960..7eed77a 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -1485,15 +1485,13 @@ void sctp_assoc_rwnd_decrease(struct sctp_association *asoc, unsigned len)
* local endpoint and the remote peer.
*/
int sctp_assoc_set_bind_addr_from_ep(struct sctp_association *asoc,
- gfp_t gfp)
+ sctp_scope_t scope, gfp_t gfp)
{
- sctp_scope_t scope;
int flags;
/* Use scoping rules to determine the subset of addresses from
* the endpoint.
*/
- scope = sctp_scope(&asoc->peer.active_path->ipaddr);
flags = (PF_INET6 == asoc->base.sk->sk_family) ? SCTP_ADDR6_ALLOWED : 0;
if (asoc->peer.ipv4_address)
flags |= SCTP_ADDR4_PEERSUPP;
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index c8fae19..d4df450 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -384,6 +384,11 @@ sctp_disposition_t sctp_sf_do_5_1B_init(const struct sctp_endpoint *ep,
if (!new_asoc)
goto nomem;
+ if (sctp_assoc_set_bind_addr_from_ep(new_asoc,
+ sctp_scope(sctp_source(chunk)),
+ GFP_ATOMIC) < 0)
+ goto nomem_init;
+
/* The call, sctp_process_init(), can fail on memory allocation. */
if (!sctp_process_init(new_asoc, chunk->chunk_hdr->type,
sctp_source(chunk),
@@ -401,9 +406,6 @@ sctp_disposition_t sctp_sf_do_5_1B_init(const struct sctp_endpoint *ep,
len = ntohs(err_chunk->chunk_hdr->length) -
sizeof(sctp_chunkhdr_t);
- if (sctp_assoc_set_bind_addr_from_ep(new_asoc, GFP_ATOMIC) < 0)
- goto nomem_init;
-
repl = sctp_make_init_ack(new_asoc, chunk, GFP_ATOMIC, len);
if (!repl)
goto nomem_init;
@@ -1452,6 +1454,10 @@ static sctp_disposition_t sctp_sf_do_unexpected_init(
if (!new_asoc)
goto nomem;
+ if (sctp_assoc_set_bind_addr_from_ep(new_asoc,
+ sctp_scope(sctp_source(chunk)), GFP_ATOMIC) < 0)
+ goto nomem;
+
/* In the outbound INIT ACK the endpoint MUST copy its current
* Verification Tag and Peers Verification tag into a reserved
* place (local tie-tag and per tie-tag) within the state cookie.
@@ -1488,9 +1494,6 @@ static sctp_disposition_t sctp_sf_do_unexpected_init(
sizeof(sctp_chunkhdr_t);
}
- if (sctp_assoc_set_bind_addr_from_ep(new_asoc, GFP_ATOMIC) < 0)
- goto nomem;
-
repl = sctp_make_init_ack(new_asoc, chunk, GFP_ATOMIC, len);
if (!repl)
goto nomem;
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index c8d0575..bf705ba 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1080,6 +1080,13 @@ static int __sctp_connect(struct sock* sk,
err = -ENOMEM;
goto out_free;
}
+
+ err = sctp_assoc_set_bind_addr_from_ep(asoc, scope,
+ GFP_KERNEL);
+ if (err < 0) {
+ goto out_free;
+ }
+
}
/* Prime the peer's transport structures. */
@@ -1095,11 +1102,6 @@ static int __sctp_connect(struct sock* sk,
walk_size += af->sockaddr_len;
}
- err = sctp_assoc_set_bind_addr_from_ep(asoc, GFP_KERNEL);
- if (err < 0) {
- goto out_free;
- }
-
/* In case the user of sctp_connectx() wants an association
* id back, assign one now.
*/
@@ -1689,6 +1691,11 @@ SCTP_STATIC int sctp_sendmsg(struct kiocb *iocb, struct sock *sk,
goto out_unlock;
}
asoc = new_asoc;
+ err = sctp_assoc_set_bind_addr_from_ep(asoc, scope, GFP_KERNEL);
+ if (err < 0) {
+ err = -ENOMEM;
+ goto out_free;
+ }
/* If the SCTP_INIT ancillary data is specified, set all
* the association init values accordingly.
@@ -1718,11 +1725,6 @@ SCTP_STATIC int sctp_sendmsg(struct kiocb *iocb, struct sock *sk,
err = -ENOMEM;
goto out_free;
}
- err = sctp_assoc_set_bind_addr_from_ep(asoc, GFP_KERNEL);
- if (err < 0) {
- err = -ENOMEM;
- goto out_free;
- }
}
/* ASSERT: we have a valid association at this point. */
--
1.6.0.4
^ permalink raw reply related
* RE: [PATCH] e1000e: Add new ID
From: Allan, Bruce W @ 2009-11-10 18:56 UTC (permalink / raw)
To: Sven Anders, netdev
In-Reply-To: <4AF87AAF.2020508@anduras.de>
NAK. While this is indeed a trivial patch to enable a device that is not currently supported in e1000e, this device requires special handling to get the bypass functionality to work properly and as such this patch is insufficient.
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of Sven Anders
>Sent: Monday, November 09, 2009 12:25 PM
>To: netdev
>Subject: [PATCH] e1000e: Add new ID
>
>Hello!
>
>We use the the 82571EB (QUAD COPPER BP) with the e1000e driver.
>We haven't experienced any problems yet.
>
>The patch is trivial, just adding a new PCI ID...
>
>Regards
> Sven Anders
>
>--
> Sven Anders <anders@anduras.de> () Ascii Ribbon Campaign
> /\ Support plain text e-
>mail
> ANDURAS service solutions AG
> Innstrasse 71 - 94036 Passau - Germany
> Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90
>50-55
>
>Those who would give up essential Liberty, to purchase a little
>temporary Safety, deserve neither Liberty nor Safety.
> - Benjamin Franklin
^ permalink raw reply
* Re: [PATCH 00/10] netdev: get rid of read_lock(&dev_base_lock) usages
From: Stephen Hemminger @ 2009-11-10 18:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <4AF9B358.9030006@gmail.com>
On Tue, 10 Nov 2009 19:39:20 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Stephen Hemminger a écrit :
> > I was just trying to pick up the stragglers you left behind :-)
> >
> > The nasty cases left are bonding (whose existing locking model is a pile
> > of crap), and sysfs (slightly less stinky). The bonding code just needs to
> > be rewritten to have a sane/simple model.
> >
>
> I was thinking of improving bonding, so it might be good to coordinate our work :)
I'll be happy to review, but was avoiding doing any serious work on it.
>
> 1) Get rid of rwlock in tx fast path. (RCU ? did I said RCU)
>
> 2) multi queue support (Got two dual 82599 dual ports cards from Intel :) )
I hope to get back to doing netlink interface for bridging, then bonding
over next few weeks.
--
^ permalink raw reply
* Re: [PATCH 07/10] decnet: use RCU to find network devices
From: Stephen Hemminger @ 2009-11-10 18:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Christine Caulfield, Hannes Eder, Alexey Dobriyan,
Steven Whitehouse, netdev, linux-decnet-users
In-Reply-To: <4AF9B449.6040708@gmail.com>
On Tue, 10 Nov 2009 19:43:21 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Stephen Hemminger a écrit :
> > When showing device statistics use RCU rather than read_lock(&dev_base_lock)
> > Compile tested only.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > --- a/net/decnet/dn_dev.c 2009-11-10 09:30:55.557376454 -0800
> > +++ b/net/decnet/dn_dev.c 2009-11-10 09:40:03.847005394 -0800
> > @@ -856,9 +856,7 @@ int dn_dev_bind_default(__le16 *addr)
> > dev = dn_dev_get_default();
> > last_chance:
> > if (dev) {
> > - read_lock(&dev_base_lock);
> > rv = dn_dev_get_first(dev, addr);
> > - read_unlock(&dev_base_lock);
> > dev_put(dev);
> > if (rv == 0 || dev == init_net.loopback_dev)
> > return rv;
> > @@ -1323,18 +1321,18 @@ static inline int is_dn_dev(struct net_d
>
>
> I dont understand this part. Why previous locking can be avoided ?
dn_dev_get_default acquires a reference on dev so the device can
not go away.
It could be the original author meant to ensure the address list
doesn't change. If so, then rtnl_lock() should have been used.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox