On Fri, 9 Dec 2005, David S. Miller wrote:
> From: Sridhar Samudrala <[EMAIL PROTECTED]>
> Date: Fri, 9 Dec 2005 16:37:11 -0800 (PST)
>
> > Did you get a chance to look at the following SCTP update?
> > If possible, could you add them to your 2.6.15 queue as they are
> > SCTP specific changes and contained within sctp directories.
>
> It's in my queue.
>
> While it's SCTP specific, new features are added, so I'll schedule
> this for 2.6.16
>
It looks like you haven't yet pulled in these patches to your 2.6.16 tree.
Actually 1 out of the 3 patches is a bugfix and it will be good if it can
go into 2.6.15. The other 2 add new features and can go into 2.6.16.
I am including this patch so that you can consider it for 2.6.15.
Let me know if you can pull the other 2 from the lksctp-2.6 git tree at
master.kernel.org:/pub/scm/linux/kernel/git/sridhar/lksctp-2.6.git
to your 2.6.16 tree or i can re-submit after 2.6.15 is out.
Thanks
Sridhar
----------------------------------------------------------------------------
[SCTP]: Fix sctp to not return erroneous POLLOUT events.
Make sctp_writeable() use sk_wmem_alloc rather than sk_wmem_queued to
determine the sndbuf space available. It also removes all the modifications
to sk_wmem_queued as it is not currently used in SCTP.
Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
---
commit beb6e9952971114b87646026f9730d18b1d54520
tree 125e3d301fb34648ca833c65270840f2865385b1
parent 436b0f76f2cee6617f27a649637766628909dd5d
author Neil Horman <[EMAIL PROTECTED]> Tue, 06 Dec 2005 11:36:06 -0800
committer Sridhar Samudrala <[EMAIL PROTECTED]> Tue, 06 Dec 2005 11:36:06 -0800
net/sctp/socket.c | 14 +++-----------
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index d890dfa..7201d7d 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -156,10 +156,6 @@ static inline void sctp_set_owner_w(stru
sizeof(struct sk_buff) +
sizeof(struct sctp_chunk);
- sk->sk_wmem_queued += SCTP_DATA_SNDSIZE(chunk) +
- sizeof(struct sk_buff) +
- sizeof(struct sctp_chunk);
-
atomic_add(sizeof(struct sctp_chunk), &sk->sk_wmem_alloc);
}
@@ -4426,7 +4422,7 @@ cleanup:
* tcp_poll(). Note that, based on these implementations, we don't
* lock the socket in this function, even though it seems that,
* ideally, locking or some other mechanisms can be used to ensure
- * the integrity of the counters (sndbuf and wmem_queued) used
+ * the integrity of the counters (sndbuf and wmem_alloc) used
* in this place. We assume that we don't need locks either until proven
* otherwise.
*
@@ -4833,10 +4829,6 @@ static void sctp_wfree(struct sk_buff *s
sizeof(struct sk_buff) +
sizeof(struct sctp_chunk);
- sk->sk_wmem_queued -= SCTP_DATA_SNDSIZE(chunk) +
- sizeof(struct sk_buff) +
- sizeof(struct sctp_chunk);
-
atomic_sub(sizeof(struct sctp_chunk), &sk->sk_wmem_alloc);
sock_wfree(skb);
@@ -4920,7 +4912,7 @@ void sctp_write_space(struct sock *sk)
/* Is there any sndbuf space available on the socket?
*
- * Note that wmem_queued is the sum of the send buffers on all of the
+ * Note that sk_wmem_alloc is the sum of the send buffers on all of the
* associations on the same socket. For a UDP-style socket with
* multiple associations, it is possible for it to be "unwriteable"
* prematurely. I assume that this is acceptable because
@@ -4933,7 +4925,7 @@ static int sctp_writeable(struct sock *s
{
int amt = 0;
- amt = sk->sk_sndbuf - sk->sk_wmem_queued;
+ amt = sk->sk_sndbuf - atomic_read(&sk->sk_wmem_alloc);
if (amt < 0)
amt = 0;
return amt;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
