Re: [Fwd: [patch 11/15] ppp: handle misaligned accesses]

2005-08-10 Thread Philippe De Muyter
Paul Mackerras wrote :
 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.

I just noticed something at the end of process_input_packet :

/* queue the frame to be processed */
skb-cb[0] = ap-state;
skb_queue_tail(ap-rqueue, skb);
ap-rpkt = 0;
ap-state = 0;
return;

 err:
/* frame had an error, remember that, reset SC_TOSS  SC_ESCAPE */
ap-state = SC_PREV_ERROR;
if (skb)
skb_trim(skb, 0);
}

In the normal case, skb is given to the next stage and ap-rpkt is reset,
but in the error case, skb is kept, ap-rpkt is not reset, so we keep
the skb with skb-data aligned for one message and we put another one
into it :)

Could that not be the culprit ?

Philippe
 
 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: skb-pkt_type

2005-08-10 Thread Harald Welte
On Tue, Aug 09, 2005 at 04:36:58PM -0700, 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.

thanks.  So my initial idea was to put those three bits into the
local_df,cloned,ip_summed,nohdr bitfield.  But meanwhile I stuffed
nfctinfo into that field, so there is no space.

We could however move nfctinfo into it's own field again. This would
mean we could save one __u8 for people who have CONFIG_NETFILTER == n.

I'm not as familiar with the current structure layout, but maybe if we
order the fields strategically, this can save one word, who knows.

-- 
- Harald Welte [EMAIL PROTECTED]  http://gnumonks.org/

Privacy in residential applications is a desirable marketing option.
  (ETSI EN 300 175-7 Ch. A6)


pgpUmtSYELpmp.pgp
Description: PGP signature


kernel to userspace communication

2005-08-10 Thread knash
Hello all,
I'm writing a kernel module which intercepts incoming
IP packets and reads information from a custom header.
The information contained in My header is passed to
userspace via netlink. So userspace builds up a picture
of the current network state, neighbouring nodes etc.

I've inserted this custom header at the hook NF_IP_LOCAL_OUT
in each outgoing IP packet.At the  moment I'm just populating
it with temporary data.

So my outgoing packets look like

[Mac hdr][IP hdr][My header][Data]

I'm wondering whats the best way for the kernel to communicate with 
userspace at the NF_IP_LOCAL_OUT hook so it can populate
[My header] with the latest information from userspace???

So i'm looking to do something like

1. Kernel at NF_IP_LOCAL_OUT, I've got a new packet!
2. Kernel - Userspace what information should I put in [My Header]? 3.
Userspace - Kernel Heres my current view of the network
4. Kernel Populates My header and returns NF_ACCEPT

Anyways I would be happy to hear any ideas your have, :-)

Thanks,
Kevin






-
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]

2005-08-10 Thread Trent Jaeger
I see.

Yes, I need to do pfkey_sadb2xfrm_user_ctx there as well. 

Regards,
Trent.
 
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532
(914) 784-7225, FAX (914) 784-7225




Herbert Xu [EMAIL PROTECTED]
08/09/2005 07:13 PM
 
To: Trent Jaeger/Watson/[EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED], netdev@vger.kernel.org, [EMAIL PROTECTED], Serge E 
Hallyn/Austin/[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: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 ~{PmVHI~} [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: kernel to userspace communication

2005-08-10 Thread Patrick McHardy

[EMAIL PROTECTED] wrote:

Hello all,
I'm writing a kernel module which intercepts incoming
IP packets and reads information from a custom header.
The information contained in My header is passed to
userspace via netlink. So userspace builds up a picture
of the current network state, neighbouring nodes etc.

I've inserted this custom header at the hook NF_IP_LOCAL_OUT
in each outgoing IP packet.At the  moment I'm just populating
it with temporary data.

So my outgoing packets look like

[Mac hdr][IP hdr][My header][Data]

I'm wondering whats the best way for the kernel to communicate with 
userspace at the NF_IP_LOCAL_OUT hook so it can populate

[My header] with the latest information from userspace???

So i'm looking to do something like

1. Kernel at NF_IP_LOCAL_OUT, I've got a new packet!
2. Kernel - Userspace what information should I put in [My Header]? 3.
Userspace - Kernel Heres my current view of the network
4. Kernel Populates My header and returns NF_ACCEPT


ip_queue is meant for this, it passes the entire packet to userspace and
lets you reinject it after doing your modifications.
-
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] disable DEBUG in ibmveth

2005-08-10 Thread Anton Blanchard

 The trailing 1 will cause a warning.

Good point.

--

At the moment ibmveth has DEBUG enabled which is rather verbose. Disable
it.

Signed-off-by: Anton Blanchard [EMAIL PROTECTED]

Index: foobar2/drivers/net/ibmveth.c
===
--- foobar2.orig/drivers/net/ibmveth.c  2005-07-06 07:49:42.0 +1000
+++ foobar2/drivers/net/ibmveth.c   2005-07-14 13:23:32.117030579 +1000
@@ -59,7 +59,7 @@
 
 #include ibmveth.h
 
-#define DEBUG 1
+#undef DEBUG
 
 #define ibmveth_printk(fmt, args...) \
   printk(KERN_INFO %s:  fmt, __FILE__, ## args)
-
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

-
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] Use sk_stream_error function rather than DECnet's own

2005-08-10 Thread David S. Miller
From: Steven Whitehouse [EMAIL PROTECTED]
Date: Wed, 10 Aug 2005 15:45:55 +0100

 Below is the patch I mentioned at UKUUG, its against an older kernel but
 it still applies when I tried it against 2.6.12 just now,

Applied, thanks Steven.
-
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] make use of -private_data in sockfd_lookup

2005-08-10 Thread Benjamin LaHaise
Here is a resend properly signed off.

Please consider the patch below which makes use of file-private_data to 
store the pointer to the socket, which avoids touching several unused 
cachelines in the dentry and inode in sockfd_lookup.

Signed-off-by: Benjamin LaHaise [EMAIL PROTECTED]
diff -purN 00_v2.6.13-rc6/net/socket.c 01_net_file/net/socket.c
--- 00_v2.6.13-rc6/net/socket.c 2005-08-04 15:56:11.0 -0400
+++ 01_net_file/net/socket.c2005-08-10 11:13:18.0 -0400
@@ -404,6 +404,7 @@ int sock_map_fd(struct socket *sock)
file-f_mode = FMODE_READ | FMODE_WRITE;
file-f_flags = O_RDWR;
file-f_pos = 0;
+   file-private_data = sock;
fd_install(fd, file);
}
 
@@ -436,6 +437,9 @@ struct socket *sockfd_lookup(int fd, int
return NULL;
}
 
+   if (file-f_op == socket_file_ops)
+   return file-private_data;  /* set in sock_map_fd */
+
inode = file-f_dentry-d_inode;
if (!S_ISSOCK(inode-i_mode)) {
*err = -ENOTSOCK;
-
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] drivers/net/bnx2.c Possible sparse fixes, take two

2005-08-10 Thread David S. Miller
From: Peter Hagervall [EMAIL PROTECTED]
Date: Tue, 9 Aug 2005 09:49:10 +0200

 This patch contains the following possible cleanups/fixes:

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: where is ethtool source hosted now?

2005-08-10 Thread Jeff Garzik

Randy.Dunlap wrote:

On Wed, 10 Aug 2005, Jesse Brandeburg wrote:



where is the ethtool source hosted now? I wanted to make some patches
against the latest version.

It used to be in bitkeeper but i don't see it at http://www.kernel.org/git



good question.  all i know of is Jeff's files (including ethtool)
at  http://sourceforge.net/projects/gkernel/


TBH I haven't recovered ethtool repository yet.  I'll dig it out and put 
it up under Subversion or git sometime soon.


Jeff



-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: where is ethtool source hosted now?

2005-08-10 Thread Randy.Dunlap
On Wed, 10 Aug 2005, Jeff Garzik wrote:

 Randy.Dunlap wrote:
  On Wed, 10 Aug 2005, Jesse Brandeburg wrote:
 
 
 where is the ethtool source hosted now? I wanted to make some patches
 against the latest version.
 
 It used to be in bitkeeper but i don't see it at http://www.kernel.org/git
 
 
  good question.  all i know of is Jeff's files (including ethtool)
  at  http://sourceforge.net/projects/gkernel/

 TBH I haven't recovered ethtool repository yet.  I'll dig it out and put
 it up under Subversion or git sometime soon.

   Jeff

It may be possible to get some help with that if you are willing
and it's workable/feasible, of course.

-- 
~Randy
-
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: that TCP bug

2005-08-10 Thread Herbert Xu
On Tue, Aug 09, 2005 at 10:19:11PM +1000, herbert wrote:
 
 So cnt is equal to fackets_out - reordering.  Normally
 fackets_out is less than packets_out.  The only reason
 I've found that might cause fackets_out to exceed packets_out
 is if tcp_fragment is called from tcp_retransmit_skb with a
 TSO skb and the current MSS is greater than the MSS stored
 in the TSO skb.  This might occur as the result of an expiring
 dst entry.
 
 In that case, packets_out may decrease (line 1380-1381 in
 tcp_output.c).  However, fackets_out is unchanged which means
 that it may in fact exceed packets_out.
 
 Previously tcp_retrans_try_collapse was the only place where
 packets_out can go down and it takes care of this by decrementing
 fackets_out.
 
 So we should make sure that fackets_out is reduced by an appropriate
 amount here as well.

Here is a patch that adjusts fackets_out accordingly.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1370,15 +1370,21 @@ int tcp_retransmit_skb(struct sock *sk, 
 
if (skb-len  cur_mss) {
int old_factor = tcp_skb_pcount(skb);
-   int new_factor;
+   int diff;
 
if (tcp_fragment(sk, skb, cur_mss, cur_mss))
return -ENOMEM; /* We'll try again later. */
 
/* New SKB created, account for it. */
-   new_factor = tcp_skb_pcount(skb);
-   tp-packets_out -= old_factor - new_factor;
-   tp-packets_out += tcp_skb_pcount(skb-next);
+   diff = old_factor - tcp_skb_pcount(skb) -
+  tcp_skb_pcount(skb-next);
+   tp-packets_out -= diff;
+
+   if (diff  0) {
+   tp-fackets_out -= diff;
+   if ((int)tp-fackets_out  0)
+   tp-fackets_out = 0;
+   }
}
 
/* Collapse two adjacent packets if worthwhile and we can. */


Re: that TCP bug

2005-08-10 Thread Herbert Xu
On Wed, Aug 10, 2005 at 06:29:56PM -0700, David S. Miller wrote:
 
 And what's more the original code there modifying packets_out
 looks wrong.

Hmm I was actually careful in making sure the rewritten expression
did the same thing to packets_out so I hope that's not the case :)

I just had another look and I think it was doing the right thing
and still is doing the right thing.

 I think I'm going to push this in for 2.6.13.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [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: [PATCH] Gianfar PHY Layer Update

2005-08-10 Thread Jeff Garzik


not applied:

Applying 'Gianfar PHY Layer Update'

error: patch failed: drivers/net/gianfar.c:393
error: drivers/net/gianfar.c: patch does not apply
error: drivers/net/gianfar_mii.c: No such file or directory

-
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