Re: [PATCH 3/3][DCCP] Finish the TIMEWAIT minisock support
Em Tue, Aug 09, 2005 at 09:29:09PM -0700, David S. Miller escreveu: > From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo) > Date: Tue, 9 Aug 2005 23:12:24 -0300 > > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/ > > All 3 patches hand applied into my rebased net-2.6.14 tree. Thanks! I'll resync right now. - Arnaldo - 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
Re: [PATCH 3/3][DCCP] Finish the TIMEWAIT minisock support
From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo) Date: Tue, 9 Aug 2005 23:12:24 -0300 > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/ All 3 patches hand applied into my rebased net-2.6.14 tree. - 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
[PATCH 3/3][DCCP] Finish the TIMEWAIT minisock support
Hi David,
Please consider pulling from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/
Best Regards,
- Arnaldo
tree a9cf14e45b536f4920d3168e2961e50b91096a09
parent 7a246e1121146f90a28a935e2a85a23f448b77dc
author Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123639218 -0300
committer Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123639218 -0300
[DCCP] Finish the TIMEWAIT minisock support
Using most of the infrastructure TCP uses, with a dccp_death_row, etc. As per
my current interpretation of the draft what we have with this changeset seems
to be all we need (or very close to it 8)).
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
--
include/linux/dccp.h |3 ++
net/dccp/ipv4.c | 15
net/dccp/minisocks.c | 60 ++-
3 files changed, 63 insertions(+), 15 deletions(-)
--
diff --git a/include/linux/dccp.h b/include/linux/dccp.h
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -194,6 +194,7 @@ enum {
#include
#include
+#include
#include
#include
#include
@@ -354,6 +355,8 @@ static inline struct dccp_request_sock *
return (struct dccp_request_sock *)req;
}
+extern struct inet_timewait_death_row dccp_death_row;
+
/* Read about the ECN nonce to see why it is 253 */
#define DCCP_MAX_ACK_VECTOR_LEN 253
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -97,7 +97,7 @@ static int __dccp_v4_check_established(s
NET_INC_STATS_BH(LINUX_MIB_TIMEWAITRECYCLED);
} else if (tw != NULL) {
/* Silly. Should hash-dance instead... */
- dccp_tw_deschedule(tw);
+ inet_twsk_deschedule(tw, &dccp_death_row);
NET_INC_STATS_BH(LINUX_MIB_TIMEWAITRECYCLED);
inet_twsk_put(tw);
@@ -201,7 +201,7 @@ ok:
spin_unlock(&head->lock);
if (tw != NULL) {
- dccp_tw_deschedule(tw);
+ inet_twsk_deschedule(tw, &dccp_death_row);
inet_twsk_put(tw);
}
@@ -1131,8 +1131,9 @@ int dccp_v4_rcv(struct sk_buff *skb)
*/
if (sk->sk_state == DCCP_TIME_WAIT) {
- dccp_pr_debug("sk->sk_state == DCCP_TIME_WAIT:
discard_and_relse\n");
-goto discard_and_relse;
+ dccp_pr_debug("sk->sk_state == DCCP_TIME_WAIT: "
+ "do_time_wait\n");
+goto do_time_wait;
}
if (!xfrm4_policy_check(sk, XFRM_POLICY_IN, skb)) {
@@ -1179,6 +1180,10 @@ discard_it:
discard_and_relse:
sock_put(sk);
goto discard_it;
+
+do_time_wait:
+ inet_twsk_put((struct inet_timewait_sock *)sk);
+ goto no_dccp_socket;
}
static int dccp_v4_init_sock(struct sock *sk)
@@ -1290,5 +1295,5 @@ struct proto dccp_v4_prot = {
.max_header = MAX_DCCP_HEADER,
.obj_size = sizeof(struct dccp_sock),
.rsk_prot = &dccp_request_sock_ops,
- .twsk_obj_size = sizeof(struct inet_timewait_sock), /* FIXME!
create dccp_timewait_sock */
+ .twsk_obj_size = sizeof(struct inet_timewait_sock),
};
diff --git a/net/dccp/minisocks.c b/net/dccp/minisocks.c
--- a/net/dccp/minisocks.c
+++ b/net/dccp/minisocks.c
@@ -22,18 +22,58 @@
#include "ccid.h"
#include "dccp.h"
+struct inet_timewait_death_row dccp_death_row = {
+ .sysctl_max_tw_buckets = NR_FILE * 2,
+ .period = DCCP_TIMEWAIT_LEN / INET_TWDR_TWKILL_SLOTS,
+ .death_lock = SPIN_LOCK_UNLOCKED,
+ .hashinfo = &dccp_hashinfo,
+ .tw_timer = TIMER_INITIALIZER(inet_twdr_hangman, 0,
+ (unsigned long)&dccp_death_row),
+ .twkill_work= __WORK_INITIALIZER(dccp_death_row.twkill_work,
+inet_twdr_twkill_work,
+&dccp_death_row),
+/* Short-time timewait calendar */
+
+ .twcal_hand = -1,
+ .twcal_timer= TIMER_INITIALIZER(inet_twdr_twcal_tick, 0,
+ (unsigned long)&dccp_death_row),
+};
+
void dccp_time_wait(struct sock *sk, int state, int timeo)
{
- /* FIXME: Implement */
- dccp_pr_debug("Want to help? Start here\n");
- dccp_set_state(sk, state);
-}
+ struct inet_timewait_sock *tw = NULL;
-/* This is for handling early-kills of TIME_WAIT sockets. */
-void dccp_tw_deschedule(struct inet_timewait_sock *tw)
-{
- dccp_pr_debug("Want to help? Start here\n");
- __inet_twsk_kill(tw, &dccp_hashinfo);
+ if (dccp_death_row.
[PATCH 2/3][TIMEWAIT] Move inet_timewait_death_row routines to net/ipv4/inet_timewait_sock.c
Hi David,
Please consider pulling from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/
Best Regards,
- Arnaldo
tree 2337884bb9038d51cc8929d8ed46c2dfb29128d1
parent a3499c4b9dc40aaa06d0f96241f07d4d08e213f0
author Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123638681 -0300
committer Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123638681 -0300
[TIMEWAIT] Move inet_timewait_death_row routines to
net/ipv4/inet_timewait_sock.c
Also export the ones that will be used in the next changeset, when DCCP
uses this infrastructure.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
--
include/net/inet_timewait_sock.h | 10 +
include/net/tcp.h|2
net/ipv4/inet_timewait_sock.c| 270 +
net/ipv4/tcp_minisocks.c | 281 +--
4 files changed, 290 insertions(+), 273 deletions(-)
--
diff --git a/include/net/inet_timewait_sock.h b/include/net/inet_timewait_sock.h
--- a/include/net/inet_timewait_sock.h
+++ b/include/net/inet_timewait_sock.h
@@ -82,6 +82,10 @@ struct inet_timewait_death_row {
int sysctl_max_tw_buckets;
};
+extern void inet_twdr_hangman(unsigned long data);
+extern void inet_twdr_twkill_work(void *data);
+extern void inet_twdr_twcal_tick(unsigned long data);
+
#if (BITS_PER_LONG == 64)
#define INET_TIMEWAIT_ADDRCMP_ALIGN_BYTES 8
#else
@@ -206,4 +210,10 @@ extern void __inet_twsk_kill(struct inet
extern void __inet_twsk_hashdance(struct inet_timewait_sock *tw,
struct sock *sk,
struct inet_hashinfo *hashinfo);
+
+extern void inet_twsk_schedule(struct inet_timewait_sock *tw,
+ struct inet_timewait_death_row *twdr,
+ const int timeo, const int timewait_len);
+extern void inet_twsk_deschedule(struct inet_timewait_sock *tw,
+struct inet_timewait_death_row *twdr);
#endif /* _INET_TIMEWAIT_SOCK_ */
diff --git a/include/net/tcp.h b/include/net/tcp.h
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -44,8 +44,6 @@ extern struct inet_hashinfo tcp_hashinfo
extern atomic_t tcp_orphan_count;
extern void tcp_time_wait(struct sock *sk, int state, int timeo);
-extern void inet_twsk_deschedule(struct inet_timewait_sock *tw,
-struct inet_timewait_death_row *twdr);
#define MAX_TCP_HEADER (128 + MAX_HEADER)
diff --git a/net/ipv4/inet_timewait_sock.c b/net/ipv4/inet_timewait_sock.c
--- a/net/ipv4/inet_timewait_sock.c
+++ b/net/ipv4/inet_timewait_sock.c
@@ -12,6 +12,7 @@
#include
#include
+#include
/* Must be called with locally disabled BHs. */
void __inet_twsk_kill(struct inet_timewait_sock *tw, struct inet_hashinfo
*hashinfo)
@@ -85,6 +86,8 @@ void __inet_twsk_hashdance(struct inet_t
write_unlock(&ehead->lock);
}
+EXPORT_SYMBOL_GPL(__inet_twsk_hashdance);
+
struct inet_timewait_sock *inet_twsk_alloc(const struct sock *sk, const int
state)
{
struct inet_timewait_sock *tw =
kmem_cache_alloc(sk->sk_prot_creator->twsk_slab,
@@ -112,3 +115,270 @@ struct inet_timewait_sock *inet_twsk_all
return tw;
}
+
+EXPORT_SYMBOL_GPL(inet_twsk_alloc);
+
+/* Returns non-zero if quota exceeded. */
+static int inet_twdr_do_twkill_work(struct inet_timewait_death_row *twdr,
+ const int slot)
+{
+ struct inet_timewait_sock *tw;
+ struct hlist_node *node;
+ unsigned int killed;
+ int ret;
+
+ /* NOTE: compare this to previous version where lock
+* was released after detaching chain. It was racy,
+* because tw buckets are scheduled in not serialized context
+* in 2.3 (with netfilter), and with softnet it is common, because
+* soft irqs are not sequenced.
+*/
+ killed = 0;
+ ret = 0;
+rescan:
+ inet_twsk_for_each_inmate(tw, node, &twdr->cells[slot]) {
+ __inet_twsk_del_dead_node(tw);
+ spin_unlock(&twdr->death_lock);
+ __inet_twsk_kill(tw, twdr->hashinfo);
+ inet_twsk_put(tw);
+ killed++;
+ spin_lock(&twdr->death_lock);
+ if (killed > INET_TWDR_TWKILL_QUOTA) {
+ ret = 1;
+ break;
+ }
+
+ /* While we dropped twdr->death_lock, another cpu may have
+* killed off the next TW bucket in the list, therefore
+* do a fresh re-read of the hlist head node with the
+* lock reacquired. We still use the hlist traversal
+* macro in order to get the prefetches.
+
[PATCH 1/3][TIMEWAIT] Introduce inet_timewait_death_row
Hi David,
Please consider pulling from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/
Best Regards,
- Arnaldo
tree 48eccf2a23b827f3d93bcd38498c09805de9624b
parent de03379a3df8fdbecc61e77bee0aa931ce308d95
author Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123637622 -0300
committer Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123637622 -0300
[TIMEWAIT] Introduce inet_timewait_death_row
That groups all of the tables and variables associated to the TCP timewait
schedulling/recycling/killing code, that now can be isolated from the TCP
specific code and used by other transport protocols, such as DCCP.
Next changeset will move this code to net/ipv4/inet_timewait_sock.c
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
--
include/net/inet_timewait_sock.h | 57
include/net/tcp.h| 36 -
net/ipv4/proc.c |2
net/ipv4/sysctl_net_ipv4.c |4
net/ipv4/tcp.c |4
net/ipv4/tcp_ipv4.c | 11 -
net/ipv4/tcp_minisocks.c | 254 +++
net/ipv6/tcp_ipv6.c |9 -
8 files changed, 206 insertions(+), 171 deletions(-)
--
diff --git a/include/net/inet_timewait_sock.h b/include/net/inet_timewait_sock.h
--- a/include/net/inet_timewait_sock.h
+++ b/include/net/inet_timewait_sock.h
@@ -19,13 +19,69 @@
#include
#include
+#include
#include
+#include
#include
#include
#include
+struct inet_hashinfo;
+
+#define INET_TWDR_RECYCLE_SLOTS_LOG5
+#define INET_TWDR_RECYCLE_SLOTS(1 <<
INET_TWDR_RECYCLE_SLOTS_LOG)
+
+/*
+ * If time > 4sec, it is "slow" path, no recycling is required,
+ * so that we select tick to get range about 4 seconds.
+ */
+#if HZ <= 16 || HZ > 4096
+# error Unsupported: HZ <= 16 or HZ > 4096
+#elif HZ <= 32
+# define INET_TWDR_RECYCLE_TICK (5 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG)
+#elif HZ <= 64
+# define INET_TWDR_RECYCLE_TICK (6 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG)
+#elif HZ <= 128
+# define INET_TWDR_RECYCLE_TICK (7 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG)
+#elif HZ <= 256
+# define INET_TWDR_RECYCLE_TICK (8 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG)
+#elif HZ <= 512
+# define INET_TWDR_RECYCLE_TICK (9 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG)
+#elif HZ <= 1024
+# define INET_TWDR_RECYCLE_TICK (10 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG)
+#elif HZ <= 2048
+# define INET_TWDR_RECYCLE_TICK (11 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG)
+#else
+# define INET_TWDR_RECYCLE_TICK (12 + 2 - INET_TWDR_RECYCLE_SLOTS_LOG)
+#endif
+
+/* TIME_WAIT reaping mechanism. */
+#define INET_TWDR_TWKILL_SLOTS 8 /* Please keep this a power of 2. */
+
+#define INET_TWDR_TWKILL_QUOTA 100
+
+struct inet_timewait_death_row {
+ /* Short-time timewait calendar */
+ int twcal_hand;
+ int twcal_jiffie;
+ struct timer_list twcal_timer;
+ struct hlist_head twcal_row[INET_TWDR_RECYCLE_SLOTS];
+
+ spinlock_t death_lock;
+ int tw_count;
+ int period;
+ u32 thread_slots;
+ struct work_struct twkill_work;
+ struct timer_list tw_timer;
+ int slot;
+ struct hlist_head cells[INET_TWDR_TWKILL_SLOTS];
+ struct inet_hashinfo*hashinfo;
+ int sysctl_tw_recycle;
+ int sysctl_max_tw_buckets;
+};
+
#if (BITS_PER_LONG == 64)
#define INET_TIMEWAIT_ADDRCMP_ALIGN_BYTES 8
#else
@@ -33,7 +89,6 @@
#endif
struct inet_bind_bucket;
-struct inet_hashinfo;
/*
* This is a TIME_WAIT sock. It works around the memory consumption
diff --git a/include/net/tcp.h b/include/net/tcp.h
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -29,6 +29,7 @@
#include
#include
+#include
#include
#include
#include
@@ -42,9 +43,9 @@
extern struct inet_hashinfo tcp_hashinfo;
extern atomic_t tcp_orphan_count;
-extern int tcp_tw_count;
extern void tcp_time_wait(struct sock *sk, int state, int timeo);
-extern void tcp_tw_deschedule(struct inet_timewait_sock *tw);
+extern void inet_twsk_deschedule(struct inet_timewait_sock *tw,
+struct inet_timewait_death_row *twdr);
#define MAX_TCP_HEADER (128 + MAX_HEADER)
@@ -148,33 +149,6 @@ extern void tcp_tw_deschedule(struct ine
* timestamps. It must be less than
* minimal timewait lifetime.
*/
-
-#define TCP_TW_RECYCLE_SLOTS_LOG 5
-#define TCP_TW_RECYCLE_SLOTS (1< 4sec, it is "slow" path, no recycling is required,
- so that we s
net-2.6.14 to be rebased
I want some net bug fixes in Linus's tree to propagate into the net-2.6.14 tree so I plan to rebase it this evening, so please be careful when sync'ing with my tree over the next day. 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.kernel.org/majordomo-info.html
Re: [PATCH 1/2][DCCP] Introduce dccp_write_xmit from code in dccp_sendmsg
> Ian, it was already merged, I also think that this one changes behaviour, > but I suggest that we keep it in the tree and later add a patch doing > whatever is needed. > > I'll elaborate in another message. > > - Arnaldo > OK. Will look at writing a patch tomorrow unless you beat me to it. Ian - 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
Re: [PATCH 1/2][DCCP] Introduce dccp_write_xmit from code in dccp_sendmsg
Em Wed, Aug 10, 2005 at 12:41:41PM +1200, Ian McDonald escreveu: > David/Arnaldo, > > I believe this patch breaks ccid3 performance. > > If possible please hold off for 24 hours until I verify whether it is > this patch which has caused it or another. Ian, it was already merged, I also think that this one changes behaviour, but I suggest that we keep it in the tree and later add a patch doing whatever is needed. I'll elaborate in another message. - Arnaldo - 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
Re: [PATCH 1/2][DCCP] Introduce dccp_write_xmit from code in dccp_sendmsg
David/Arnaldo, I believe this patch breaks ccid3 performance. If possible please hold off for 24 hours until I verify whether it is this patch which has caused it or another. Regards, Ian On 10/08/05, Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote: > Hi David, > > Please consider pulling from: > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/ > > Best Regards, > > - Arnaldo - 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
Re: skb->pkt_type
Patrick McHardy wrote: > BTW, an idea to make room for ipvs_property would be to place the three > nfctinfo bits in the lower three bits of the nfct pointer. I'm not sure > if it guarantees 8 byte alignemnt, which would be required for this to > work .. I'm to hasty .. with "it" I mean the slab allocator. - 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
Re: skb->pkt_type
David S. Miller wrote: > I pushed a bunch of bluetooth updates into my net-2.6.14 > tree, and in there you will find the change to make > the bluetooth stack not use skb->pkt_type in the funny > way it used to. > > This opens up the possibility to shrink it's size. BTW, an idea to make room for ipvs_property would be to place the three nfctinfo bits in the lower three bits of the nfct pointer. I'm not sure if it guarantees 8 byte alignemnt, which would be required for this to work .. - 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
Re: [PATCH 2/2][DCCP] Initialize icsk_rto in dccp_v4_init_sock
From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo) Date: Tue, 9 Aug 2005 21:07:50 -0300 > Please consider pulling from: > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/ Pulled, 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.kernel.org/majordomo-info.html
[PATCH 2/2][DCCP] Initialize icsk_rto in dccp_v4_init_sock
Hi David, Please consider pulling from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/ Best Regards, - Arnaldo tree 8389bb3fa23d6c8e8db4ba62a0160f4f28938b50 parent 55a364b972cbfbd731f1ae763e9b3818880daed8 author Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123632227 -0300 committer Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123632227 -0300 [DCCP] Initialize icsk_rto in dccp_v4_init_sock Fixes nasty bug related to the retransmit timer (yeah, DCCP does retransmits) firing too early. Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> -- ipv4.c |1 + 1 files changed, 1 insertion(+) -- diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c --- a/net/dccp/ipv4.c +++ b/net/dccp/ipv4.c @@ -1219,6 +1219,7 @@ static int dccp_v4_init_sock(struct sock dccp_ctl_socket_init = 0; dccp_init_xmit_timers(sk); + inet_csk(sk)->icsk_rto = DCCP_TIMEOUT_INIT; sk->sk_state = DCCP_CLOSED; dp->dccps_mss_cache = 536; dp->dccps_role = DCCP_ROLE_UNDEFINED; - 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
[PATCH 1/2][DCCP] Introduce dccp_write_xmit from code in dccp_sendmsg
Hi David,
Please consider pulling from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/
Best Regards,
- Arnaldo
tree cb64f1688f611035ca076d8baed11abf3558361c
parent add709a31388a56411bc19babb8a45552744974e
author Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123631974 -0300
committer Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123631974 -0300
[DCCP] Introduce dccp_write_xmit from code in dccp_sendmsg
This way it gets closer to the TCP flow, where congestion window checks are
done, it seems we can map ccid_hc_tx_send_packet in dccp_write_xmit to
tcp_snd_wnd_test in tcp_write_xmit, a CCID2 decision should just fit in here as
well...
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
--
ccid.h|8 ++-
ccids/ccid3.c | 13 ++-
dccp.h|5 ++--
output.c | 38 +
proto.c | 65 ++
5 files changed, 57 insertions(+), 72 deletions(-)
--
diff --git a/net/dccp/ccid.h b/net/dccp/ccid.h
--- a/net/dccp/ccid.h
+++ b/net/dccp/ccid.h
@@ -43,8 +43,7 @@ struct ccid {
unsigned char len, u16 idx,
unsigned char* value);
int (*ccid_hc_tx_send_packet)(struct sock *sk,
- struct sk_buff *skb, int len,
- long *delay);
+ struct sk_buff *skb, int len);
void(*ccid_hc_tx_packet_sent)(struct sock *sk, int more,
int len);
};
@@ -60,12 +59,11 @@ static inline void __ccid_get(struct cci
}
static inline int ccid_hc_tx_send_packet(struct ccid *ccid, struct sock *sk,
-struct sk_buff *skb, int len,
-long *delay)
+struct sk_buff *skb, int len)
{
int rc = 0;
if (ccid->ccid_hc_tx_send_packet != NULL)
- rc = ccid->ccid_hc_tx_send_packet(sk, skb, len, delay);
+ rc = ccid->ccid_hc_tx_send_packet(sk, skb, len);
return rc;
}
diff --git a/net/dccp/ccids/ccid3.c b/net/dccp/ccids/ccid3.c
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -977,13 +977,14 @@ out:
sock_put(sk);
}
-static int ccid3_hc_tx_send_packet(struct sock *sk, struct sk_buff *skb,
- int len, long *delay)
+static int ccid3_hc_tx_send_packet(struct sock *sk,
+ struct sk_buff *skb, int len)
{
struct dccp_sock *dp = dccp_sk(sk);
struct ccid3_hc_tx_sock *hctx = dp->dccps_hc_tx_ccid_private;
struct ccid3_tx_hist_entry *new_packet = NULL;
struct timeval now;
+ long delay;
int rc = -ENOTCONN;
// ccid3_pr_debug("%s, sk=%p, skb=%p, len=%d\n", dccp_role(sk), sk, skb,
len);
@@ -1037,11 +1038,11 @@ static int ccid3_hc_tx_send_packet(struc
break;
case TFRC_SSTATE_NO_FBACK:
case TFRC_SSTATE_FBACK:
- *delay = (now_delta(hctx->ccid3hctx_t_nom) -
hctx->ccid3hctx_delta);
- ccid3_pr_debug("send_packet delay=%ld\n",*delay);
- *delay /= -1000;
+ delay = (now_delta(hctx->ccid3hctx_t_nom) -
hctx->ccid3hctx_delta);
+ ccid3_pr_debug("send_packet delay=%ld\n", delay);
+ delay /= -1000;
/* divide by -1000 is to convert to ms and get sign right */
- rc = *delay > 0 ? -EAGAIN : 0;
+ rc = delay > 0 ? -EAGAIN : 0;
break;
default:
printk(KERN_CRIT "%s: %s, sk=%p, Illegal state (%d)!\n",
diff --git a/net/dccp/dccp.h b/net/dccp/dccp.h
--- a/net/dccp/dccp.h
+++ b/net/dccp/dccp.h
@@ -122,6 +122,9 @@ extern void dccp_send_ack(struct sock *s
extern void dccp_send_delayed_ack(struct sock *sk);
extern void dccp_send_sync(struct sock *sk, u64 seq);
+extern int dccp_write_xmit(struct sock *sk, struct sk_buff *skb,
+ const int len);
+
extern void dccp_init_xmit_timers(struct sock *sk);
static inline void dccp_clear_xmit_timers(struct sock *sk)
{
@@ -194,8 +197,6 @@ static inline void dccp_openreq_init(str
req->rcv_wnd = 0;
}
-extern void dccp_v4_send_check(struct sock *sk, struct dccp_hdr *dh, int len,
- struct sk_buff *skb);
extern int dccp_v4_conn_request(struct sock *sk, struct sk_buff *skb);
extern struct sock *dccp_create_openreq_child(struct sock *sk,
diff --git a/net/dccp/output.c b/net/dccp/output.c
--- a/net/dccp/output.c
+++ b/net/dccp
skb->pkt_type
I pushed a bunch of bluetooth updates into my net-2.6.14 tree, and in there you will find the change to make the bluetooth stack not use skb->pkt_type in the funny way it used to. This opens up the possibility to shrink it's size. Just FYI... - 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
Re: [PATCH 1/2] LSM-IPSec Networking Hooks -- revised flow cache [resend]
On Tue, Aug 09, 2005 at 02:20:45PM -0400, Trent Jaeger wrote:
>
> > What makes spddelete different from spdadd?
>
> spddelete takes a context string as input and we need to retrieve the
> policy that matches the selector (xfrm_policy_bysel) and the security
> context. The additional code checks the latter. I think that the
> conversion of the context string to a 'normalized' context struct must be
> done by the LSM before we can do this check as done above.
What I meant is why does spdadd do pfkey_sadb2xfrm_user_ctx while
spddelete doesn't?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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
Re: [Fwd: [patch 11/15] ppp: handle misaligned accesses]
Philippe De Muyter writes: > Actually, that's probably the case I had, but my fix gets the ip adresses > 4byte aligned in my case : I had verified the address of the saddr field, > and I needed to shift the buffer by 3, not 1, to get it 4byte aligned. Please outline the code flow that leads to that situation. AFAICS we would only need to shift the buffer by 3 if we had a compressed (1-byte) protocol number at the original skb->data, implying that the protocol byte was first. But if the protocol byte was first, then this code: if (buf[0] != PPP_ALLSTATIONS) skb_reserve(skb, 2 + (buf[0] & 1)); at line 893 should have moved skb->data up by 3 bytes already, since a 1-byte protocol number is always odd. If that is not the case then there is something else going on beyond the data getting misaligned, and I would like to know what it is. Paul. - 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
Re: [PATCH 1/3][DCCP] make include-able from userspace
Em Tue, Aug 09, 2005 at 03:41:30PM -0700, David S. Miller escreveu: > From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo) > Date: Tue, 9 Aug 2005 19:15:44 -0300 > > > Please consider pulling from: > > > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/ > > Pulled, thanks Arnaldo. > > I took the opportunity to fix up all the u64 printf > format string warnings in the DCCP stack, that changeset > should show up right after these 3 in the net-2.6.14 tree. > > Thanks again. Thanks! I'll rebase my tree from there for the upcoming changesets I'll submit to you. - Arnaldo - 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
Re: [PATCH 1/3][DCCP] make include-able from userspace
From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo) Date: Tue, 9 Aug 2005 19:15:44 -0300 > Please consider pulling from: > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/ Pulled, thanks Arnaldo. I took the opportunity to fix up all the u64 printf format string warnings in the DCCP stack, that changeset should show up right after these 3 in the net-2.6.14 tree. Thanks again. - 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
[PATCH 3/3][NETFILTER] New iptables DCCP protocol header match
Hi David,
Please consider pulling from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/
Best Regards,
- Arnaldo
tree c5248bfb66e8514912ba6f1e5dfa145a71a048a7
parent 4c3feaa6256eefd021259857e3351a77da9a17fd
author Harald Welte <[EMAIL PROTECTED]> 1123625328 -0300
committer Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123625328 -0300
[NETFILTER] New iptables DCCP protocol header match
Using this new iptables DCCP protocol header match, it is possible to
create simplistic stateless packet filtering rules for DCCP. It permits
matching of port numbers, packet type and options.
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
--
include/linux/dccp.h| 16 ++
include/linux/netfilter_ipv4/ipt_dccp.h | 23
net/ipv4/netfilter/Kconfig | 11 ++
net/ipv4/netfilter/Makefile |1
net/ipv4/netfilter/ipt_dccp.c | 176
5 files changed, 224 insertions(+), 3 deletions(-)
--
diff --git a/include/linux/dccp.h b/include/linux/dccp.h
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -242,10 +242,15 @@ static inline struct dccp_hdr_ext *dccp_
return (struct dccp_hdr_ext *)(skb->h.raw + sizeof(struct dccp_hdr));
}
+static inline unsigned int __dccp_basic_hdr_len(const struct dccp_hdr *dh)
+{
+ return sizeof(*dh) + (dh->dccph_x ? sizeof(struct dccp_hdr_ext) : 0);
+}
+
static inline unsigned int dccp_basic_hdr_len(const struct sk_buff *skb)
{
const struct dccp_hdr *dh = dccp_hdr(skb);
- return sizeof(*dh) + (dh->dccph_x ? sizeof(struct dccp_hdr_ext) : 0);
+ return __dccp_basic_hdr_len(dh);
}
static inline __u64 dccp_hdr_seq(const struct sk_buff *skb)
@@ -297,10 +302,15 @@ static inline struct dccp_hdr_reset *dcc
return (struct dccp_hdr_reset *)(skb->h.raw + dccp_basic_hdr_len(skb));
}
+static inline unsigned int __dccp_hdr_len(const struct dccp_hdr *dh)
+{
+ return __dccp_basic_hdr_len(dh) +
+ dccp_packet_hdr_len(dh->dccph_type);
+}
+
static inline unsigned int dccp_hdr_len(const struct sk_buff *skb)
{
- return dccp_basic_hdr_len(skb) +
- dccp_packet_hdr_len(dccp_hdr(skb)->dccph_type);
+ return __dccp_hdr_len(dccp_hdr(skb));
}
diff --git a/include/linux/netfilter_ipv4/ipt_dccp.h
b/include/linux/netfilter_ipv4/ipt_dccp.h
new file mode 100644
--- /dev/null
+++ b/include/linux/netfilter_ipv4/ipt_dccp.h
@@ -0,0 +1,23 @@
+#ifndef _IPT_DCCP_H_
+#define _IPT_DCCP_H_
+
+#define IPT_DCCP_SRC_PORTS 0x01
+#define IPT_DCCP_DEST_PORTS0x02
+#define IPT_DCCP_TYPE 0x04
+#define IPT_DCCP_OPTION0x08
+
+#define IPT_DCCP_VALID_FLAGS 0x0f
+
+struct ipt_dccp_info {
+ u_int16_t dpts[2]; /* Min, Max */
+ u_int16_t spts[2]; /* Min, Max */
+
+ u_int16_t flags;
+ u_int16_t invflags;
+
+ u_int16_t typemask;
+ u_int8_t option;
+};
+
+#endif /* _IPT_DCCP_H_ */
+
diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
--- a/net/ipv4/netfilter/Kconfig
+++ b/net/ipv4/netfilter/Kconfig
@@ -354,6 +354,17 @@ config IP_NF_MATCH_SCTP
If you want to compile it as a module, say M here and read
. If unsure, say `N'.
+config IP_NF_MATCH_DCCP
+ tristate 'DCCP protocol match support'
+ depends on IP_NF_IPTABLES
+ help
+ With this option enabled, you will be able to use the iptables
+ `dccp' match in order to match on DCCP source/destination ports
+ and DCCP flags.
+
+ If you want to compile it as a module, say M here and read
+ . If unsure, say `N'.
+
config IP_NF_MATCH_COMMENT
tristate 'comment match support'
depends on IP_NF_IPTABLES
diff --git a/net/ipv4/netfilter/Makefile b/net/ipv4/netfilter/Makefile
--- a/net/ipv4/netfilter/Makefile
+++ b/net/ipv4/netfilter/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_IP_NF_MATCH_HELPER) += ipt_
obj-$(CONFIG_IP_NF_MATCH_LIMIT) += ipt_limit.o
obj-$(CONFIG_IP_NF_MATCH_HASHLIMIT) += ipt_hashlimit.o
obj-$(CONFIG_IP_NF_MATCH_SCTP) += ipt_sctp.o
+obj-$(CONFIG_IP_NF_MATCH_DCCP) += ipt_dccp.o
obj-$(CONFIG_IP_NF_MATCH_MARK) += ipt_mark.o
obj-$(CONFIG_IP_NF_MATCH_MAC) += ipt_mac.o
obj-$(CONFIG_IP_NF_MATCH_IPRANGE) += ipt_iprange.o
diff --git a/net/ipv4/netfilter/ipt_dccp.c b/net/ipv4/netfilter/ipt_dccp.c
new file mode 100644
--- /dev/null
+++ b/net/ipv4/netfilter/ipt_dccp.c
@@ -0,0 +1,176 @@
+/*
+ * iptables module for DCCP protocol header matching
+ *
+ * (C) 2005 by Harald Welte <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License vers
[PATCH 2/3][DCCP] Fix struct sockaddr_dccp definition
Hi David,
Please consider pulling from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/
Best Regards,
- Arnaldo
tree d25c0dd1db78b1021da8902e8ef0dc37cbb5d892
parent ad7764592bf76533ffe823d7f45d7712c0bacfe2
author Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123625109 -0300
committer Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123625109 -0300
[DCCP] Fix struct sockaddr_dccp definition
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
--
dccp.h | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
--
diff --git a/include/linux/dccp.h b/include/linux/dccp.h
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -4,10 +4,14 @@
#include
#include
-/* FIXME: this is utterly wrong */
+/* Structure describing an Internet (DCCP) socket address. */
struct sockaddr_dccp {
- struct sockaddr_in in;
- unsigned intservice;
+ __u16 sdccp_family; /* Address family */
+ __u16 sdccp_port; /* Port number */
+ __u32 sdccp_addr; /* Internet address */
+ __u32 sdccp_service; /* Service */
+ /* Pad to size of `struct sockaddr': 16 bytes . */
+ __u32 sdccp_pad;
};
/**
-
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
[PATCH 1/3][DCCP] make include-able from userspace
Hi David,
Please consider pulling from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/
Best Regards,
- Arnaldo
tree d8b5c75361398171d79a34240bd5eac0192ee419
parent 591454895b6f92b49e12e901b10ad8977c68dbdf
author Harald Welte <[EMAIL PROTECTED]> 1123624808 -0300
committer Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123624808 -0300
[DCCP] make include-able from userspace
The protocol header files in are usually structured in a
way to be included by userspace code. The top section consists of
general protocol structure definitions, typedefs, enums - followed by an
#ifdef __KERNEL__ section.
Currently doesn't follow that convention and can
therefore not be used from userspace. However, for example iptables'
libipt_dccp.c actually needs various definitions from there.
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
--
dccp.h | 238 +
1 files changed, 121 insertions(+), 117 deletions(-)
--
diff --git a/include/linux/dccp.h b/include/linux/dccp.h
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -1,16 +1,8 @@
#ifndef _LINUX_DCCP_H
#define _LINUX_DCCP_H
-#include
-#include
#include
-#include
-#include
-
-#include
-#include
-#include
-#include
+#include
/* FIXME: this is utterly wrong */
struct sockaddr_dccp {
@@ -18,40 +10,6 @@ struct sockaddr_dccp {
unsigned intservice;
};
-enum dccp_state {
- DCCP_OPEN = TCP_ESTABLISHED,
- DCCP_REQUESTING = TCP_SYN_SENT,
- DCCP_PARTOPEN = TCP_FIN_WAIT1, /* FIXME:
- This mapping is horrible, but TCP
has
- no matching state for DCCP_PARTOPEN,
- as TCP_SYN_RECV is already used by
- DCCP_RESPOND, why don't stop using
TCP
- mapping of states? OK, now we don't
use
- sk_stream_sendmsg anymore, so
doesn't
- seem to exist any reason for us to
- do the TCP mapping here */
- DCCP_LISTEN = TCP_LISTEN,
- DCCP_RESPOND= TCP_SYN_RECV,
- DCCP_CLOSING= TCP_CLOSING,
- DCCP_TIME_WAIT = TCP_TIME_WAIT,
- DCCP_CLOSED = TCP_CLOSE,
- DCCP_MAX_STATES = TCP_MAX_STATES,
-};
-
-#define DCCP_STATE_MASK 0xf
-#define DCCP_ACTION_FIN (1<<7)
-
-enum {
- DCCPF_OPEN = TCPF_ESTABLISHED,
- DCCPF_REQUESTING = TCPF_SYN_SENT,
- DCCPF_PARTOPEN = TCPF_FIN_WAIT1,
- DCCPF_LISTEN = TCPF_LISTEN,
- DCCPF_RESPOND= TCPF_SYN_RECV,
- DCCPF_CLOSING= TCPF_CLOSING,
- DCCPF_TIME_WAIT = TCPF_TIME_WAIT,
- DCCPF_CLOSED = TCPF_CLOSE,
-};
-
/**
* struct dccp_hdr - generic part of DCCP packet header
*
@@ -94,11 +52,6 @@ struct dccp_hdr {
#endif
};
-static inline struct dccp_hdr *dccp_hdr(const struct sk_buff *skb)
-{
- return (struct dccp_hdr *)skb->h.raw;
-}
-
/**
* struct dccp_hdr_ext - the low bits of a 48 bit seq packet
*
@@ -108,34 +61,6 @@ struct dccp_hdr_ext {
__u32 dccph_seq_low;
};
-static inline struct dccp_hdr_ext *dccp_hdrx(const struct sk_buff *skb)
-{
- return (struct dccp_hdr_ext *)(skb->h.raw + sizeof(struct dccp_hdr));
-}
-
-static inline unsigned int dccp_basic_hdr_len(const struct sk_buff *skb)
-{
- const struct dccp_hdr *dh = dccp_hdr(skb);
- return sizeof(*dh) + (dh->dccph_x ? sizeof(struct dccp_hdr_ext) : 0);
-}
-
-static inline __u64 dccp_hdr_seq(const struct sk_buff *skb)
-{
- const struct dccp_hdr *dh = dccp_hdr(skb);
-#if defined(__LITTLE_ENDIAN_BITFIELD)
- __u64 seq_nr = ntohl(dh->dccph_seq << 8);
-#elif defined(__BIG_ENDIAN_BITFIELD)
- __u64 seq_nr = ntohl(dh->dccph_seq);
-#else
-#error "Adjust your defines"
-#endif
-
- if (dh->dccph_x != 0)
- seq_nr = (seq_nr << 32) + ntohl(dccp_hdrx(skb)->dccph_seq_low);
-
- return seq_nr;
-}
-
/**
* struct dccp_hdr_request - Conection initiation request header
*
@@ -145,12 +70,6 @@ static inline __u64 dccp_hdr_seq(const s
struct dccp_hdr_request {
__u32 dccph_req_service;
};
-
-static inline struct dccp_hdr_request *dccp_hdr_request(struct sk_buff *skb)
-{
- return (struct dccp_hdr_request *)(skb->h.raw +
dccp_basic_hdr_len(skb));
-}
-
/**
* struct dccp_hdr_ack_bits - acknowledgment bits common to most packets
*
@@ -162,24 +81,6 @@ struct dccp_hdr_ack_bits {
dccph_ack_nr_high:24;
__u32 dccph_ack_nr_low;
};
-
-static inline struct dccp_hdr_ack_bits
Re: [PATCH 1/2] LSM-IPSec Networking Hooks -- revised flow cache [resend]
Trent Jaeger <[EMAIL PROTECTED]> wrote:
>
> This is specific to CONFIG_SECURITY_NETWORK_XFRM as contexts will only be
> used in that case. I will make it conditional on that instead, if that's
> OK.
That sounds good.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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
Re: FW: [ANNOUNCE] Chelsio 10Gb TOE (TCP Offload Engine)
On 8/9/05, David S. Miller wrote: > > @@ -735,6 +737,9 @@ > > ssize_t res; > > struct sock *sk = sock->sk; > > > > + if (sk->sk_prot->sendpage) > > + return sk->sk_prot->sendpage(sk, page, offset, size, flags); > > + > > This doesn't make any sense, invoking sk->sk_prot->sendpage() > is what af_inet.c:inet_sendpage() did to get us to this function > (tcp_sendpage() in tcp.c), so this code will make us recurse > indefinitely into tcp_sendpage() over and over until we run out > of kernel stack. Dave, TCP currently does not go through inet_sendpage, instead calling tcp_sendpage directly in af_inet.c. sk_prot->sendpage is NULL for TCP. Probably for historical reasons since struct proto's sendpage didn't exist in 2.4. If TCP vectors through inet_sendpage like the other protocols then this additional code won't be needed and indeed it would be a recursive call. - 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
Re: [ANNOUNCE] Chelsio 10Gb TOE (TCP Offload Engine)
From: Scott Bardone <[EMAIL PROTECTED]> Date: Tue, 02 Aug 2005 22:01:22 -0700 > @@ -735,6 +737,9 @@ > ssize_t res; > struct sock *sk = sock->sk; > > + if (sk->sk_prot->sendpage) > + return sk->sk_prot->sendpage(sk, page, offset, size, flags); > + This doesn't make any sense, invoking sk->sk_prot->sendpage() is what af_inet.c:inet_sendpage() did to get us to this function (tcp_sendpage() in tcp.c), so this code will make us recurse indefinitely into tcp_sendpage() over and over until we run out of kernel stack. - 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
Re: [patch 3/5] fib_trie: Use const
From: Robert Olsson <[EMAIL PROTECTED]> Date: Mon, 8 Aug 2005 16:01:23 +0200 > Stephen Hemminger writes: > > Use const where possible and get rid of EXTRACT() macro > > that was never used. ... > Signed-off-by: Robert Olsson <[EMAIL PROTECTED]> > > > Signed-off-by: Stephen Hemmigner <[EMAIL PROTECTED]> Applied to net-2.6.14, 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.kernel.org/majordomo-info.html
Re: [patch 2/5] fib_trie: Use ERR_PTR to handle errno return
From: Robert Olsson <[EMAIL PROTECTED]> Date: Mon, 8 Aug 2005 15:58:28 +0200 > Dave IMO it can be appiled. > > Signed-off-by: Robert Olsson <[EMAIL PROTECTED]> > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Done. - 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
[PATCH] farsync: schedule struct fstioc_info::kernelVersion for removal
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> --- Documentation/feature-removal-schedule.txt |8 1 files changed, 8 insertions(+) --- linux-vanilla/Documentation/feature-removal-schedule.txt +++ linux-farsync/Documentation/feature-removal-schedule.txt @@ -121,6 +121,14 @@ Who: Grant Coady <[EMAIL PROTECTED]> --- +What: struct fstioc_info::kernelVersion used in FSTGETCONF ioctl +When: November 2005 +Files: drivers/net/wan/farsync.c, drivers/net/wan/farsync.h +Why: Duplicates uname(2). +Who: Alexey Dobriyan <[EMAIL PROTECTED]> + +--- + What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) When: November 2005 Files: drivers/pcmcia/: pcmcia_ioctl.c - 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
Re: [PATCH][INET] Request module protocol strings
From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo) Date: Tue, 9 Aug 2005 16:19:52 -0300 > [INET] Request module protocol strings > > Changed the syntax to: > > nf-pf--proto--type- > > Matching the one in netlink, as pointed out by Harald. > > Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> Pulled, thanks Arnaldo. - 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
[PATCH][INET] Request module protocol strings
Em Mon, Aug 08, 2005 at 02:01:48PM -0700, David S. Miller escreveu:
>
> We have an icky situation in this area. Harald is right,
> I think.
>
> I'd suggest that Arnaldo fixes up his af_inet.c changes
> so that it uses "net-pf-*" like the rest of the tree
> does.
>
> Arnaldo, I pulled in your net-2.6.14 tree earlier today,
> so please send me a patch on-top of that.
Available at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/
On top of your latest net-2.6.14.git tree.
Regards,
- Arnaldo
tree 798b122078678637377e314fc4940401df5d5a45
parent 0c3ac38e9f848b600698e1d660a40aba3838e7b9
author Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123613281 -0300
committer Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> 1123613281 -0300
[INET] Request module protocol strings
Changed the syntax to:
nf-pf--proto--type-
Matching the one in netlink, as pointed out by Harald.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
--
dccp/proto.c|6 +++---
ipv4/af_inet.c | 16
sctp/protocol.c |2 +-
3 files changed, 16 insertions(+), 8 deletions(-)
--
diff --git a/net/dccp/proto.c b/net/dccp/proto.c
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -814,10 +814,10 @@ module_exit(dccp_fini);
/*
* __stringify doesn't likes enums, so use SOCK_DCCP (6) and IPPROTO_DCCP (33)
* values directly, Also cover the case where the protocol is not specified,
- * i.e. net-proto-PF_INET-0-SOCK_DCCP
+ * i.e. net-pf-PF_INET-proto-0-type-SOCK_DCCP
*/
-MODULE_ALIAS("net-proto-" __stringify(PF_INET) "-33-6");
-MODULE_ALIAS("net-proto-" __stringify(PF_INET) "-0-6");
+MODULE_ALIAS("net-pf-" __stringify(PF_INET) "-proto-33-type-6");
+MODULE_ALIAS("net-pf-" __stringify(PF_INET) "-proto-0-type-6");
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("DCCP - Datagram Congestion Controlled Protocol");
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -259,12 +259,20 @@ lookup_protocol:
if (unlikely(answer == NULL)) {
if (try_loading_module < 2) {
rcu_read_unlock();
- /* Be more specific, e.g. net-proto-2-132-1
(net-proto-PF_INET-IPPROTO_SCTP-SOCK_STREAM) */
+ /*
+* Be more specific, e.g. net-pf-2-proto-132-type-1
+* (net-pf-PF_INET-proto-IPPROTO_SCTP-type-SOCK_STREAM)
+*/
if (++try_loading_module == 1)
- request_module("net-proto-%d-%d-%d", PF_INET,
protocol, sock->type);
- /* Fall back to generic, e.g. net-proto-132-1
(net-proto-IPPROTO_SCTP) */
+ request_module("net-pf-%d-proto-%d-type-%d",
+ PF_INET, protocol, sock->type);
+ /*
+* Fall back to generic, e.g. net-pf-2-proto-132
+* (net-pf-PF_INET-proto-IPPROTO_SCTP)
+*/
else
- request_module("net-proto-%d-%d", PF_INET,
protocol);
+ request_module("net-pf-%d-proto-%d",
+ PF_INET, protocol);
goto lookup_protocol;
} else
goto out_rcu_unlock;
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -1245,7 +1245,7 @@ module_exit(sctp_exit);
/*
* __stringify doesn't likes enums, so use IPPROTO_SCTP value (132) directly.
*/
-MODULE_ALIAS("net-proto-" __stringify(PF_INET) "-132");
+MODULE_ALIAS("net-pf-" __stringify(PF_INET) "-proto-132");
MODULE_AUTHOR("Linux Kernel SCTP developers <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Support for the SCTP protocol (RFC2960)");
MODULE_LICENSE("GPL");
-
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
Re: [PATCH] untracked fix now in Linus' tree, but not in net-2.6.14
From: Harald Welte <[EMAIL PROTECTED]> Subject: [PATCH] untracked fix now in Linus' tree, but not in net-2.6.14 Date: Tue, 9 Aug 2005 09:26:12 +0200 > Hi Dave, please apply the untracked fix (that has been adopted by Linus > for 2.6.13) to your net-2.6.14 tree. Thanks! It will show up there when I rebase the net-2.6.14 tree, which might be later today. I absolutely do not like applying a patch twice, once in net-2.6.13 and once in net-2.6.14, just to get it to show up in both places. That makes for merge headaches later. - 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
Re: [PATCH 1/2] LSM-IPSec Networking Hooks -- revised flow cache [resend]
> > @@ -2108,7 +2230,18 @@ static int pfkey_spddelete(struct sock *
> > if (sel.dport)
> > sel.dport_mask = ~0;
> >
> > -xp = xfrm_policy_bysel(pol->sadb_x_policy_dir-1, &sel,
1);
> > +sec_ctx = (struct sadb_x_sec_ctx *)
ext_hdrs[SADB_X_EXT_SEC_CTX-1];
> > +memset(&tmp, 0, sizeof(struct xfrm_policy));
> > +
> > +if (sec_ctx != NULL) {
> > +err = security_xfrm_policy_alloc(
> > +&tmp, (struct
xfrm_user_sec_ctx *)sec_ctx);
> What makes spddelete different from spdadd?
spddelete takes a context string as input and we need to retrieve the
policy that matches the selector (xfrm_policy_bysel) and the security
context. The additional code checks the latter. I think that the
conversion of the context string to a 'normalized' context struct must be
done by the LSM before we can do this check as done above.
I could hide this computation a bit better (it is also done for xfrm_user)
to clean up the code.
Regards,
Trent.
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532
(914) 784-7225, FAX (914) 784-7225
-
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
Re: [PATCH 1/2] LSM-IPSec Networking Hooks -- revised flow cache [resend]
> > @@ -2703,10 +2837,22 @@ static struct xfrm_policy *pfkey_compile
> > (*dir = parse_ipsecrequests(xp, pol)) < 0)
> > goto out;
> >
> > +/* security context too */
> > +if (len >= (pol->sadb_x_policy_len*8 +
> > +sizeof(struct sadb_x_sec_ctx))) {
> > +char *p = (char *) pol;
> > +p += pol->sadb_x_policy_len*8;
> > +sec_ctx = (struct sadb_x_sec_ctx *) p;
> > +if (security_xfrm_policy_alloc(
> > +xp, (struct
xfrm_user_sec_ctx *)sec_ctx))
> > +goto out;
> > +}
> > +
> Do we really need socket-specific policies with security context?
Security context information is being used by some user-level appls, such
as XWindows, so I can see that applications may want to set security
contexts for their sockets based on the principal for whom the code is
being run. For example, we may want to prevent leakage of data from a
window in X to a remote client by setting the security context for a
socket which limits the receivers of such data.
Regards,
Trent.
PS -- This is all the questions/comments.
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532
(914) 784-7225, FAX (914) 784-7225
-
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
Re: [PATCH 1/2] LSM-IPSec Networking Hooks -- revised flow cache [resend]
I have a few questions on your comments. The ones for which I do not have
questions, I will modify as suggested.
> > diff -puN include/net/xfrm.h~lsm-xfrm-nethooks include/net/xfrm.h
>> --- linux-2.6.13-rc4-xfrm/include/net/xfrm.h~lsm-xfrm-nethooks
2005-08-01 16:11:22.0 -0400
>> +++ linux-2.6.13-rc4-xfrm-root/include/net/xfrm.h 2005-08-01
16:11:22.0 -0400
>> @@ -510,6 +514,27 @@ xfrm_selector_match(struct xfrm_selector
>> return 0;
>> }
>>
>> +/* If neither has a context --> match
>> + Otherwise, both must have a context and the sids, doi, alg must
match */
>> +static inline int xfrm_sec_ctx_match(struct xfrm_sec_ctx *s1, struct
xfrm_sec_ctx *s2)
>> +{
>> + return ((!s1 && !s2) ||
>> + (s1 && s2 &&
>> + (s1->ctx_sid == s2->ctx_sid) &&
>> + (s1->ctx_doi == s2->ctx_doi) &&
>> + (s1->ctx_alg == s2->ctx_alg)));
>> +}
> Would it be possible to make this conditional on
CONFIG_SECURITY_NETWORK?
This is specific to CONFIG_SECURITY_NETWORK_XFRM as contexts will only be
used in that case. I will make it conditional on that instead, if that's
OK.
Regards,
Trent.
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532
(914) 784-7225, FAX (914) 784-7225
-
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
Re: [patch 5/5] fib_trie: use RCU (EXPERIMENTAL)
Stephen Hemminger writes:
> I have a merged patch set in the works. with Robert et al.
> Some of what my differences are:
> > +struct fib_alias *fib_find_alias_rcu(struct list_head *fah, u8 tos,
> > u32 prio) +{
> > + if (fah) {
> > + struct fib_alias *fa;
> > + list_for_each_entry_rcu(fa, fah, fa_list) {
> > + if (fa->fa_tos > tos)
> > + continue;
> > + if (fa->fa_info->fib_priority >= prio ||
> > + fa->fa_tos < tos)
> > + return fa;
> > + }
> > + }
> > + return NULL;
> > +}
>
> fib_find_alias is only used in path's that have RT netlink
> mutex held, so RCU is not needed.
Yes true for the moment but shouldn't we use RCU consequently?
> > +int fib_semantic_match_rcu(struct list_head *head, const struct
> > flowi *flp,
> > + struct fib_result *res, __u32 zone, __u32
> > mask,
> > + int prefixlen)
> > +{
>
>
> Why duplicate the code of of fib_semantic_match? It would be
> better to just change fib_semantic_match to use the for_each_rcu().
> The resulting code will be the same (except alpha) because the
> only addition is a read_barrier_depends().
>
> > int fib_semantic_match(struct list_head *head, const struct flowi
> > *flp, struct fib_result *res, __u32 zone, __u32 mask,
> >int prefixlen)
Yes it duplication as we didn't want to touch any existing FIB code for
the moment also Patrick was thinking of RCU version of fib_hash later on.
You might have a point though...
But it raises the next question ;) when the difference is so minimal.
Why do we keep two sets of (h)list functions? Both RCU and non-RCU
> Also, please don't bother adding RCU to routines that are modifying
> the tree. Only the lookup, dump, and /proc code paths should
> use RCU.
Lists are rcu-procteced. So shouldn't we use ie RCU consistenly even
in the "writer" functions as insert/delete? Is this what you mean?
And lookup is of course run from softirq.
Cheers.
--ro
-
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
RE: [RESEND][PATCH net-drivers-2.6 5/9] ixgb: Fix data output by ethtool -d
Agreed, we will roll in this in our next build
-Malli
-Original Message-
From: Ingo Oeser [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 09, 2005 3:27 AM
To: Chilakala, Mallikarjuna
Cc: [EMAIL PROTECTED]; netdev
Subject: Re: [RESEND][PATCH net-drivers-2.6 5/9] ixgb: Fix data output
by ethtool -d
Hi Malli,
Malli Chilakala wrote:
> Fix data output by ethtool -d
>
> Signed-off-by: Mallikarjuna R Chilakala
<[EMAIL PROTECTED]>
> Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]>
> Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
>
> diff -up netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c
> netdev-2.6/drivers/net/ixgb.new/ixgb_ethtool.c ---
> netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c2005-08-05
09:25:28.0
> -0700 +++ netdev-2.6/drivers/net/ixgb.new/ixgb_ethtool.c
2005-08-05
> 09:25:38.0 -0700 @@ -301,7 +301,8 @@ ixgb_get_regs(struct
> net_device *netdev,
> *reg++ = IXGB_READ_REG(hw, RAIDC); /* 19 */
> *reg++ = IXGB_READ_REG(hw, RXCSUM); /* 20 */
>
> - for (i = 0; i < IXGB_RAR_ENTRIES; i++) {
> + /* there are 16 RAR entries in hardware, we only use 3 */
> + for(i = 0; i < 16; i++) {
Please define a symbol for this constant somewhere. Introducing
hardcoded values are a regression in readability.
Suggested symbol: "#define IXGB_ALL_RAR_ENTRIES 16"
Regards
Ingo Oeser
-
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
[2.6 patch] net/irda/: possible cleanups
This patch contains the following possible cleanups:
- make the following needlessly global function static:
- irnet/irnet_ppp.c: irnet_init
- remove the following unneeded EXPORT_SYMBOL's:
- irlmp.c: sysctl_discovery_timeout
- irlmp.c: irlmp_reasons
- irlmp.c: irlmp_dup
- irqueue.c: hashbin_find_next
Please review which of these changes do make sense and which conflict
with pending patches.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 9 Jul 2005
- 30 May 2005
- 7 May 2005
net/irda/irlmp.c |3 ---
net/irda/irnet/irnet.h |3 ---
net/irda/irnet/irnet_ppp.c |2 +-
net/irda/irqueue.c |1 -
4 files changed, 1 insertion(+), 8 deletions(-)
--- linux-2.6.12-rc3-mm3-full/net/irda/irnet/irnet.h.old2005-05-05
22:38:59.0 +0200
+++ linux-2.6.12-rc3-mm3-full/net/irda/irnet/irnet.h2005-05-05
22:39:12.0 +0200
@@ -517,9 +517,6 @@
irda_irnet_init(void); /* Initialise IrDA part of IrNET */
extern void
irda_irnet_cleanup(void); /* Teardown IrDA part of IrNET */
-/* MODULE */
-extern int
- irnet_init(void); /* Initialise IrNET module */
/ VARIABLES /
--- linux-2.6.12-rc3-mm3-full/net/irda/irnet/irnet_ppp.c.old2005-05-05
22:39:21.0 +0200
+++ linux-2.6.12-rc3-mm3-full/net/irda/irnet/irnet_ppp.c2005-05-05
22:39:29.0 +0200
@@ -1107,7 +1107,7 @@
/*
* Module main entry point
*/
-int __init
+static int __init
irnet_init(void)
{
int err;
--- linux-2.6.12-rc3-mm3-full/net/irda/irlmp.c.old 2005-05-05
22:46:47.0 +0200
+++ linux-2.6.12-rc3-mm3-full/net/irda/irlmp.c 2005-05-05 22:50:52.0
+0200
@@ -53,7 +53,6 @@
/* These can be altered by the sysctl interface */
int sysctl_discovery = 0;
int sysctl_discovery_timeout = 3; /* 3 seconds by default */
-EXPORT_SYMBOL(sysctl_discovery_timeout);
int sysctl_discovery_slots = 6; /* 6 slots by default */
int sysctl_lap_keepalive_time = LM_IDLE_TIMEOUT * 1000 / HZ;
char sysctl_devname[65];
@@ -67,7 +66,6 @@
"LM_INIT_DISCONNECT",
"ERROR, NOT USED",
};
-EXPORT_SYMBOL(irlmp_reasons);
/*
* Function irlmp_init (void)
@@ -675,7 +673,6 @@
return new;
}
-EXPORT_SYMBOL(irlmp_dup);
/*
* Function irlmp_disconnect_request (handle, userdata)
--- linux-2.6.12-rc3-mm3-full/net/irda/irqueue.c.old2005-05-05
22:48:55.0 +0200
+++ linux-2.6.12-rc3-mm3-full/net/irda/irqueue.c2005-05-05
22:49:03.0 +0200
@@ -822,7 +822,6 @@
return entry;
}
-EXPORT_SYMBOL(hashbin_find_next);
/*
* Function hashbin_get_first (hashbin)
-
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
Re: [Fwd: [patch 11/15] ppp: handle misaligned accesses]
Paul Mackerras wrote :
> Philippe De Muyter writes:
>
> > > This patch seems a bit strange and/or incomplete. Are we trying to
> > > get 2-byte alignment or 4-byte alignment of the payload? It seems
> >
> > Actually, we try to get a 4n+2 alignment for skb->data, to get the
> > ip-addresses
> > field 4bytes aligned.
> > I think the only thing wrong is the old comment that said :
> > /* Try to get the payload 4-byte aligned */
> > and that I did not change.
>
> Yes, the payload is the part after the protocol field, so the comment
> is still correct.
>
> > > that if the protocol field is uncompressed, we don't do anything to
> > > the alignment, but if it is compressed, we do this:
> > >
> > > > /* protocol is compressed */
> > > > - skb_push(skb, 1)[0] = 0;
> > > > + if ((unsigned long)skb->data & 1)
> > > > + skb_push(skb, 1)[0] = 0;
> > > > + else { /* Ditto, but realign the payload to 4-byte
> > > > boundary */
> > > > + short len = skb->len;
> > > > +
> > > > + skb_put(skb, 3);
> > > > + memmove(skb->data + 3, skb->data, len);
> > > > + skb_pull(skb, 2)[0] = 0;
> > >
> > > I'm puzzled that we are not testing ((unsigned long)skb->data & 2) if
> > > we are really trying to achieve 4-byte alignment. In fact, if the
> > > skb->data that we get from dev_alloc_skb is 4-byte aligned to start
> > > with, this will end up with the payload starting at the original
> > > skb->data + 6, i.e. 2-byte aligned but not 4-byte aligned AFAICS.
> > >
> > > Can we assume that dev_alloc_skb will give us a 4-byte aligned
> > > skb->data? If we can then I suggest we change 3 to 1 in the skb_put
> >
> > Are you not forgetting that the alignment of skb->data is changed (by the
> > existing code ! ) :
> > if (buf[0] != PPP_ALLSTATIONS)
> > skb_reserve(skb, 2 + (buf[0] & 1));
>
> No, I'm not forgetting. If we assume that skb->data starts out 4-byte
> aligned, then the only case in which we will have
>
> ((unsigned long)skb->data & 1) == 0
>
> is if we have protocol field compression (and a compressible protocol
> number, i.e. less than 0x100) but not address/control compression
> (which would be a weird combination, but legal). In that case, with
> your patch we will move the protocol byte to the original skb->data+5
> and have the payload at +6.
Actually, that's probably the case I had, but my fix gets the ip adresses
4byte aligned in my case : I had verified the address of the saddr field,
and I needed to shift the buffer by 3, not 1, to get it 4byte aligned.
>
> If there is any possibility that skb->data is not 4-byte aligned when
No, that's not the problem I had. skb->data was always 4-byte aligned
at allocation time.
> the skb is first allocated, I think that we should do something like
>
> if ((unsigned long)skb->data & 3)
> skb_reserve(skb, 4 - ((unsigned long)skb->data & 3));
>
> immediately after allocating it, and then just memmove the stuff up
> one byte (rather than 3) if it isn't aligned as we want.
>
> Paul.
>
Philippe
-
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
[PATCH] untracked fix now in Linus' tree, but not in net-2.6.14
Hi Dave, please apply the untracked fix (that has been adopted by Linus
for 2.6.13) to your net-2.6.14 tree. Thanks!
--
- Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[NETFILTER] don't try to do any NAT on untracked connections
With the introduction of 'rustynat' in 2.6.11, the old tricks of preventing
NAT of 'untracked' connections (e.g. NOTRACK target in 'raw' table) are no
longer sufficient. The ip_conntrack_untracked.status |= IPS_NAT_DONE_MASK
effectively prevents iteration of the 'nat' table, but doesn't prevent
nat_packet() to be executed. Since nr_manips is gone in 'rustynat',
nat_packet() now implicitly thinks that it has to do NAT on the packet.
This patch fixes that problem by explicitly checking for
ip_conntrack_untracked in ip_nat_fn().
Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
---
commit c16fd4ffed6349d0888cd97a75d04394dac42021
tree b4f0e73c7c36f3a52b23593c40f1f49353ba67e3
parent 4d08142e287f852db3f4bfd614f2d73521bd7f07
author Harald Welte <[EMAIL PROTECTED]> Sa, 06 Aug 2005 18:11:00 +0200
committer Harald Welte <[EMAIL PROTECTED]> Sa, 06 Aug 2005 18:11:00 +0200
net/ipv4/netfilter/ip_nat_standalone.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/netfilter/ip_nat_standalone.c
b/net/ipv4/netfilter/ip_nat_standalone.c
--- a/net/ipv4/netfilter/ip_nat_standalone.c
+++ b/net/ipv4/netfilter/ip_nat_standalone.c
@@ -100,6 +100,10 @@ ip_nat_fn(unsigned int hooknum,
return NF_ACCEPT;
}
+ /* Don't try to NAT if this packet is not conntracked */
+ if (ct == &ip_conntrack_untracked)
+ return NF_ACCEPT;
+
switch (ctinfo) {
case IP_CT_RELATED:
case IP_CT_RELATED+IP_CT_IS_REPLY:
pgpmvn1o00pSV.pgp
Description: PGP signature
Re: [Fwd: [patch 11/15] ppp: handle misaligned accesses]
Philippe De Muyter writes:
> > This patch seems a bit strange and/or incomplete. Are we trying to
> > get 2-byte alignment or 4-byte alignment of the payload? It seems
>
> Actually, we try to get a 4n+2 alignment for skb->data, to get the
> ip-addresses
> field 4bytes aligned.
> I think the only thing wrong is the old comment that said :
> /* Try to get the payload 4-byte aligned */
> and that I did not change.
Yes, the payload is the part after the protocol field, so the comment
is still correct.
> > that if the protocol field is uncompressed, we don't do anything to
> > the alignment, but if it is compressed, we do this:
> >
> > > /* protocol is compressed */
> > > - skb_push(skb, 1)[0] = 0;
> > > + if ((unsigned long)skb->data & 1)
> > > + skb_push(skb, 1)[0] = 0;
> > > + else { /* Ditto, but realign the payload to 4-byte boundary */
> > > + short len = skb->len;
> > > +
> > > + skb_put(skb, 3);
> > > + memmove(skb->data + 3, skb->data, len);
> > > + skb_pull(skb, 2)[0] = 0;
> >
> > I'm puzzled that we are not testing ((unsigned long)skb->data & 2) if
> > we are really trying to achieve 4-byte alignment. In fact, if the
> > skb->data that we get from dev_alloc_skb is 4-byte aligned to start
> > with, this will end up with the payload starting at the original
> > skb->data + 6, i.e. 2-byte aligned but not 4-byte aligned AFAICS.
> >
> > Can we assume that dev_alloc_skb will give us a 4-byte aligned
> > skb->data? If we can then I suggest we change 3 to 1 in the skb_put
>
> Are you not forgetting that the alignment of skb->data is changed (by the
> existing code ! ) :
> if (buf[0] != PPP_ALLSTATIONS)
> skb_reserve(skb, 2 + (buf[0] & 1));
No, I'm not forgetting. If we assume that skb->data starts out 4-byte
aligned, then the only case in which we will have
((unsigned long)skb->data & 1) == 0
is if we have protocol field compression (and a compressible protocol
number, i.e. less than 0x100) but not address/control compression
(which would be a weird combination, but legal). In that case, with
your patch we will move the protocol byte to the original skb->data+5
and have the payload at +6.
If there is any possibility that skb->data is not 4-byte aligned when
the skb is first allocated, I think that we should do something like
if ((unsigned long)skb->data & 3)
skb_reserve(skb, 4 - ((unsigned long)skb->data & 3));
immediately after allocating it, and then just memmove the stuff up
one byte (rather than 3) if it isn't aligned as we want.
Paul.
-
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
Re: [Fwd: [patch 11/15] ppp: handle misaligned accesses]
Paul Mackerras wrote :
> Jeff Garzik writes:
>
> > From: "Philippe De Muyter" <[EMAIL PROTECTED]>
> >
> > Avoid ppp-generated kernel crashes on machines where unaligned accesses are
> > forbidden (ie: 68000-based CPUs)
>
> This patch seems a bit strange and/or incomplete. Are we trying to
> get 2-byte alignment or 4-byte alignment of the payload? It seems
Actually, we try to get a 4n+2 alignment for skb->data, to get the ip-addresses
field 4bytes aligned.
I think the only thing wrong is the old comment that said :
/* Try to get the payload 4-byte aligned */
and that I did not change.
> that if the protocol field is uncompressed, we don't do anything to
> the alignment, but if it is compressed, we do this:
>
> > /* protocol is compressed */
> > - skb_push(skb, 1)[0] = 0;
> > + if ((unsigned long)skb->data & 1)
> > + skb_push(skb, 1)[0] = 0;
> > + else { /* Ditto, but realign the payload to 4-byte boundary */
> > + short len = skb->len;
> > +
> > + skb_put(skb, 3);
> > + memmove(skb->data + 3, skb->data, len);
> > + skb_pull(skb, 2)[0] = 0;
>
> I'm puzzled that we are not testing ((unsigned long)skb->data & 2) if
> we are really trying to achieve 4-byte alignment. In fact, if the
> skb->data that we get from dev_alloc_skb is 4-byte aligned to start
> with, this will end up with the payload starting at the original
> skb->data + 6, i.e. 2-byte aligned but not 4-byte aligned AFAICS.
>
> Can we assume that dev_alloc_skb will give us a 4-byte aligned
> skb->data? If we can then I suggest we change 3 to 1 in the skb_put
Are you not forgetting that the alignment of skb->data is changed (by the
existing code ! ) :
if (buf[0] != PPP_ALLSTATIONS)
skb_reserve(skb, 2 + (buf[0] & 1));
> and memmove above, and get rid of the if (since its condition will
> always be false).
>
> Paul.
>
Philippe
-
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
Re: [RESEND][PATCH net-drivers-2.6 5/9] ixgb: Fix data output by ethtool -d
Hi Malli,
Malli Chilakala wrote:
> Fix data output by ethtool -d
>
> Signed-off-by: Mallikarjuna R Chilakala <[EMAIL PROTECTED]>
> Signed-off-by: Ganesh Venkatesan <[EMAIL PROTECTED]>
> Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
>
> diff -up netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c
> netdev-2.6/drivers/net/ixgb.new/ixgb_ethtool.c ---
> netdev-2.6/drivers/net/ixgb/ixgb_ethtool.c2005-08-05 09:25:28.0
> -0700 +++ netdev-2.6/drivers/net/ixgb.new/ixgb_ethtool.c 2005-08-05
> 09:25:38.0 -0700 @@ -301,7 +301,8 @@ ixgb_get_regs(struct
> net_device *netdev,
> *reg++ = IXGB_READ_REG(hw, RAIDC); /* 19 */
> *reg++ = IXGB_READ_REG(hw, RXCSUM); /* 20 */
>
> - for (i = 0; i < IXGB_RAR_ENTRIES; i++) {
> + /* there are 16 RAR entries in hardware, we only use 3 */
> + for(i = 0; i < 16; i++) {
Please define a symbol for this constant somewhere. Introducing
hardcoded values are a regression in readability.
Suggested symbol: "#define IXGB_ALL_RAR_ENTRIES 16"
Regards
Ingo Oeser
-
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
[PATCH] drivers/net/bnx2.c Possible sparse fixes, take two
This patch contains the following possible cleanups/fixes:
- use C99 struct initializers
- make a few arrays and structs static
- remove a few uses of literal 0 as NULL pointer
- use convenience function instead of cast+dereference in bnx2_ioctl()
- remove superfluous casts to u8 * in calls to readl/writel
I think I got it right this time, just holler if there's something I
missed.
Signed-off-by: Peter Hagervall <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -52,7 +52,6 @@ static struct {
{ "HP NC370i Multifunction Gigabit Server Adapter" },
{ "Broadcom NetXtreme II BCM5706 1000Base-SX" },
{ "HP NC370F Multifunction Gigabit Server Adapter" },
- { 0 },
};
static struct pci_device_id bnx2_pci_tbl[] = {
@@ -3507,11 +3506,11 @@ bnx2_test_registers(struct bnx2 *bp)
rw_mask = reg_tbl[i].rw_mask;
ro_mask = reg_tbl[i].ro_mask;
- save_val = readl((u8 *) bp->regview + offset);
+ save_val = readl(bp->regview + offset);
- writel(0, (u8 *) bp->regview + offset);
+ writel(0, bp->regview + offset);
- val = readl((u8 *) bp->regview + offset);
+ val = readl(bp->regview + offset);
if ((val & rw_mask) != 0) {
goto reg_test_err;
}
@@ -3520,9 +3519,9 @@ bnx2_test_registers(struct bnx2 *bp)
goto reg_test_err;
}
- writel(0x, (u8 *) bp->regview + offset);
+ writel(0x, bp->regview + offset);
- val = readl((u8 *) bp->regview + offset);
+ val = readl(bp->regview + offset);
if ((val & rw_mask) != rw_mask) {
goto reg_test_err;
}
@@ -3531,11 +3530,11 @@ bnx2_test_registers(struct bnx2 *bp)
goto reg_test_err;
}
- writel(save_val, (u8 *) bp->regview + offset);
+ writel(save_val, bp->regview + offset);
continue;
reg_test_err:
- writel(save_val, (u8 *) bp->regview + offset);
+ writel(save_val, bp->regview + offset);
ret = -ENODEV;
break;
}
@@ -4698,7 +4697,7 @@ bnx2_set_rx_csum(struct net_device *dev,
#define BNX2_NUM_STATS 45
-struct {
+static struct {
char string[ETH_GSTRING_LEN];
} bnx2_stats_str_arr[BNX2_NUM_STATS] = {
{ "rx_bytes" },
@@ -4750,7 +4749,7 @@ struct {
#define STATS_OFFSET32(offset_name) (offsetof(struct statistics_block,
offset_name) / 4)
-unsigned long bnx2_stats_offset_arr[BNX2_NUM_STATS] = {
+static unsigned long bnx2_stats_offset_arr[BNX2_NUM_STATS] = {
STATS_OFFSET32(stat_IfHCInOctets_hi),
STATS_OFFSET32(stat_IfHCInBadOctets_hi),
STATS_OFFSET32(stat_IfHCOutOctets_hi),
@@ -4801,7 +4800,7 @@ unsigned long bnx2_stats_offset_arr[BNX2
/* stat_IfHCInBadOctets and stat_Dot3StatsCarrierSenseErrors are
* skipped because of errata.
*/
-u8 bnx2_5706_stats_len_arr[BNX2_NUM_STATS] = {
+static u8 bnx2_5706_stats_len_arr[BNX2_NUM_STATS] = {
8,0,8,8,8,8,8,8,8,8,
4,0,4,4,4,4,4,4,4,4,
4,4,4,4,4,4,4,4,4,4,
@@ -4811,7 +4810,7 @@ u8 bnx2_5706_stats_len_arr[BNX2_NUM_STAT
#define BNX2_NUM_TESTS 6
-struct {
+static struct {
char string[ETH_GSTRING_LEN];
} bnx2_tests_str_arr[BNX2_NUM_TESTS] = {
{ "register_test (offline)" },
@@ -4910,7 +4909,7 @@ bnx2_get_ethtool_stats(struct net_device
struct bnx2 *bp = dev->priv;
int i;
u32 *hw_stats = (u32 *) bp->stats_blk;
- u8 *stats_len_arr = 0;
+ u8 *stats_len_arr = NULL;
if (hw_stats == NULL) {
memset(buf, 0, sizeof(u64) * BNX2_NUM_STATS);
@@ -5012,7 +5011,7 @@ static struct ethtool_ops bnx2_ethtool_o
static int
bnx2_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
- struct mii_ioctl_data *data = (struct mii_ioctl_data *)&ifr->ifr_data;
+ struct mii_ioctl_data *data = if_mii(ifr);
struct bnx2 *bp = dev->priv;
int err;
@@ -5505,12 +5504,12 @@ bnx2_resume(struct pci_dev *pdev)
}
static struct pci_driver bnx2_pci_driver = {
- name: DRV_MODULE_NAME,
- id_table: bnx2_pci_tbl,
- probe: bnx2_init_one,
- remove: __devexit_p(bnx2_remove_one),
- suspend:bnx2_suspend,
- resume: bnx2_resume,
+ .name = DRV_MODULE_NAME,
+ .id_table = bnx2_pci_tbl,
+ .probe = bnx2_init_one,
+ .remove = __devexit_p(bnx2_remove_one),
+ .suspend= bnx2_suspend,
+ .resume = bnx2_resume,
};
static int __init bnx2_init(void)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PRO
