date:20061030

From: James Morris <[EMAIL PROTECTED]>
Date: Mon, 30 Oct 2006 19:31:31 -0500 (EST)

> Currently, when an application requests a lease for a flowlabel via the 
> IPV6_FLOWLABEL_MGR socket option, no error is returned if an invalid type 
> of destination address is supplied as part of the request, leading to a 
> silent failure.  This patch ensures that EINVAL is returned to the 
> application in this case.
> 
> Please apply.
> 
> Signed-off-by: James Morris <[EMAIL PROTECTED]>

Applied, thanks a lot James.
-
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] [SCTP]: Remove temporary associations from backlog and hash

From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Mon, 30 Oct 2006 17:38:41 -0800

> [SCTP]: Remove temporary associations from backlog and hash.
> 
> Every time SCTP creates a temporary association, the stack hashes it,
> puts it on a list of endpoint associations and increments the backlog.
> However, the lifetime of a temporary association is the processing time
> of a current packet and it's destroyed after that. In fact, we don't
> really want anyone else finding this association. There is no reason to
> do this extra work.
> 
> Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
> Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

Also applied, thanks a lot.

-
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] [SCTP]: Correctly set IP id for SCTP traffic

From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Mon, 30 Oct 2006 17:38:37 -0800

> [SCTP]: Correctly set IP id for SCTP traffic
> 
> Make SCTP 1-1 style and peeled-off associations behave like TCP when
> setting IP id. In both cases, we set the inet_sk(sk)->daddr and initialize
> inet_sk(sk)->id to a random value.
> 
> Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
> Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

Applied, 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: ipw3945?

2006-10-30 Thread Zhu Yi

On Mon, 2006-10-30 at 19:54 +0100, dragoran wrote:
> Can this be used to make the driver work without the daemon?

Yup. And we have already successfully put the daemon's work into the
firmware/ucode. The new firmware will be released soon. Stay tuned.

Thanks,
-yi
-
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] [SCTP]: Remove temporary associations from backlog and hash

2006-10-30 Thread Sridhar Samudrala

[SCTP]: Remove temporary associations from backlog and hash.

Every time SCTP creates a temporary association, the stack hashes it,
puts it on a list of endpoint associations and increments the backlog.
However, the lifetime of a temporary association is the processing time
of a current packet and it's destroyed after that. In fact, we don't
really want anyone else finding this association. There is no reason to
do this extra work.

Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

---
 net/sctp/associola.c   |   15 +++
 net/sctp/endpointola.c |7 +++
 net/sctp/input.c   |6 ++
 3 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 27329ce..ed0445f 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -346,11 +346,18 @@ void sctp_association_free(struct sctp_a
struct list_head *pos, *temp;
int i;
 
-   list_del(&asoc->asocs);
+   /* Only real associations count against the endpoint, so
+* don't bother for if this is a temporary association.
+*/
+   if (!asoc->temp) {
+   list_del(&asoc->asocs);
 
-   /* Decrement the backlog value for a TCP-style listening socket. */
-   if (sctp_style(sk, TCP) && sctp_sstate(sk, LISTENING))
-   sk->sk_ack_backlog--;
+   /* Decrement the backlog value for a TCP-style listening
+* socket.
+*/
+   if (sctp_style(sk, TCP) && sctp_sstate(sk, LISTENING))
+   sk->sk_ack_backlog--;
+   }
 
/* Mark as dead, so other users can know this structure is
 * going away.
diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
index 35c49ff..9b6b394 100644
--- a/net/sctp/endpointola.c
+++ b/net/sctp/endpointola.c
@@ -144,6 +144,13 @@ void sctp_endpoint_add_asoc(struct sctp_
 {
struct sock *sk = ep->base.sk;
 
+   /* If this is a temporary association, don't bother
+* since we'll be removing it shortly and don't
+* want anyone to find it anyway.
+*/
+   if (asoc->temp)
+   return;
+
/* Now just add it to our list of asocs */
list_add_tail(&asoc->asocs, &ep->asocs);
 
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 64f6301..cd20cd0 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -768,6 +768,9 @@ static void __sctp_hash_established(stru
 /* Add an association to the hash. Local BH-safe. */
 void sctp_hash_established(struct sctp_association *asoc)
 {
+   if (asoc->temp)
+   return;
+
sctp_local_bh_disable();
__sctp_hash_established(asoc);
sctp_local_bh_enable();
@@ -801,6 +804,9 @@ static void __sctp_unhash_established(st
 /* Remove association from the hash table.  Local BH-safe. */
 void sctp_unhash_established(struct sctp_association *asoc)
 {
+   if (asoc->temp)
+   return;
+
sctp_local_bh_disable();
__sctp_unhash_established(asoc);
sctp_local_bh_enable();


-
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] [SCTP]: Correctly set IP id for SCTP traffic

2006-10-30 Thread Sridhar Samudrala

[SCTP]: Correctly set IP id for SCTP traffic

Make SCTP 1-1 style and peeled-off associations behave like TCP when
setting IP id. In both cases, we set the inet_sk(sk)->daddr and initialize
inet_sk(sk)->id to a random value.

Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>

---
 net/sctp/protocol.c |2 +-
 net/sctp/socket.c   |9 +
 2 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index fac7674..5b4f82f 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -591,7 +591,7 @@ static struct sock *sctp_v4_create_accep
newinet->dport = htons(asoc->peer.port);
newinet->daddr = asoc->peer.primary_addr.v4.sin_addr.s_addr;
newinet->pmtudisc = inet->pmtudisc;
-   newinet->id = 0;
+   newinet->id = asoc->next_tsn ^ jiffies;
 
newinet->uc_ttl = -1;
newinet->mc_loop = 1;
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 9f34dec..c58fa6d 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3372,6 +3372,7 @@ SCTP_STATIC int sctp_do_peeloff(struct s
 {
struct sock *sk = asoc->base.sk;
struct socket *sock;
+   struct inet_sock *inetsk;
int err = 0;
 
/* An association cannot be branched off from an already peeled-off
@@ -3389,6 +3390,14 @@ SCTP_STATIC int sctp_do_peeloff(struct s
 * asoc to the newsk.
 */
sctp_sock_migrate(sk, sock->sk, asoc, SCTP_SOCKET_UDP_HIGH_BANDWIDTH);
+
+   /* Make peeled-off sockets more like 1-1 accepted sockets.
+* Set the daddr and initialize id to something more random
+*/
+   inetsk = inet_sk(sock->sk);
+   inetsk->daddr = asoc->peer.primary_addr.v4.sin_addr.s_addr;
+   inetsk->id = asoc->next_tsn ^ jiffies;
+
*sockp = sock;
 
return err;


-
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: [SCTP]: Always linearise packet on input

2006-10-30 Thread Sridhar Samudrala

On Sun, 2006-10-29 at 23:46 -0800, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Mon, 30 Oct 2006 18:11:28 +1100
> 
> > [SCTP]: Always linearise packet on input
>  ...
> > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
> 
> I'll apply this, thanks a lot.
> 
> > Sridhar, could you please organise an audit of SCTP to make sure
> > that it deals with skb fragments (both pages and frag_list) in a
> > safe manner? Basically before you do an skb_pull or access skb->data
> > you must ensure that the data you want to access is in the head,
> > usually by doing skb_may_pull.  Of course, for large payloads it
> > helps if you can avoid pulling it into the head.
> 
> Of course, you mean "pskb_may_pull" here.

I think we currently assume atleast the SCTP header and the data
chunk header to be in the skb head.
But we do handle skbs with data in the frag_list.
Not sure about skb's with paged fragments.

Does XEN use frag_list or frags array?
Is there a simple way to simulate incoming packets with transport
headers and data in skb's frag_list/pages without having to use XEN.

Thanks
Sridhar

-
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: [take1] d80211: switch crypto to use new ciphers API

2006-10-30 Thread Herbert Xu

On Mon, Oct 30, 2006 at 10:08:58AM -0800, David Kimdon wrote:
> 
> Updated patch, now aes, tkip and wep are all tested.
> 
> Changes from take0:
> 
> Use IS_ERR() to evaluate return value of crypto_alloc_cipher().  Use
> ciper interface rather than blkcipher for aes encryption since we only
> encrypt a single block at a time.
> 
> 
> 
> Switch d80211 software crypto to use the new cipher API.
> 
> Signed-off-by: David Kimdon <[EMAIL PROTECTED]>

Thanks David.  Looks good here.

Acked-by: Herbert Xu <[EMAIL PROTECTED]>

Cheers,
-- 
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

[PATCH] ipv6: return EINVAL for invalid address with flowlabel lease request

2006-10-30 Thread James Morris

Currently, when an application requests a lease for a flowlabel via the 
IPV6_FLOWLABEL_MGR socket option, no error is returned if an invalid type 
of destination address is supplied as part of the request, leading to a 
silent failure.  This patch ensures that EINVAL is returned to the 
application in this case.

Please apply.

Signed-off-by: James Morris <[EMAIL PROTECTED]>

---

 net/ipv6/ip6_flowlabel.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff -purN -X dontdiff linux-2.6.p/net/ipv6/ip6_flowlabel.c 
linux-2.6.w/net/ipv6/ip6_flowlabel.c
--- linux-2.6.p/net/ipv6/ip6_flowlabel.c2006-10-30 18:30:34.0 
-0500
+++ linux-2.6.w/net/ipv6/ip6_flowlabel.c2006-10-30 18:57:33.0 
-0500
@@ -330,8 +330,10 @@ fl_create(struct in6_flowlabel_req *freq
fl->share = freq->flr_share;
addr_type = ipv6_addr_type(&freq->flr_dst);
if ((addr_type&IPV6_ADDR_MAPPED)
-   || addr_type == IPV6_ADDR_ANY)
+   || addr_type == IPV6_ADDR_ANY) {
+   err = -EINVAL;
goto done;
+   }
ipv6_addr_copy(&fl->dst, &freq->flr_dst);
atomic_set(&fl->users, 1);
switch (fl->share) {
-
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

pktgen patch available for perusal.

2006-10-30 Thread Ben Greear


I've completed the first pass of my changes to pktgen in 2.6.18.
Many of these features are probably DOA based on previous conversations,
but perhaps this will help someone

Changes:
* use a nano-second timer based on the scheduler timer (TSC) for relative 
times, instead of get_time_of_day.
* Don't busy-spin:
   * add hook to netdevice wake tx queue to re-start when queue was stopped.
   * add logic to pktgen to register/unregister this hook.
   * accumulate delay and sleep interruptible on a queue when 1ms of sleep has 
accumulated
 or when the associated netdev tx-queues for pktgen devices needing to 
transmit are asleep.
   (This all assumes that HZ is 1000, could probably work with other HZ with 
minor work.)
* Add receive logic to dev.c so that pktgen can receive packets and report on 
various stats
  including latency, packet loss, jitter, etc.
* Remove the if-lock, primarily by making the 'add-interface' logic deferred to 
the
  thread's main loop.  It's likely I missed a corner case or two here, 
hopefully I'll
  find them all in testing...
* Add ioctl to grab all of the pktgen stats in one call.

The pktgen.[ch] patch is here:  http://www.candelatech.com/oss/pktgen.patch

The full patch, including the callback hooks (and several other features)
is located here:  http://www.candelatech.com/oss/candela_2.6.18.patch

Thanks,
Ben

--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc  http://www.candelatech.com

-
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] net: fix uaccess handling

From: Heiko Carstens <[EMAIL PROTECTED]>
Date: Thu, 26 Oct 2006 15:03:17 +0200

> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
> ---
>  net/ipv4/raw.c   |   17 +++--
>  net/ipv6/raw.c   |   17 +++--
>  net/netlink/af_netlink.c |5 +++--
>  3 files changed, 25 insertions(+), 14 deletions(-)

Patch applied, 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] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11

2006-10-30 Thread Uli Kunitz


Johannes Berg wrote:
I'm not so sure about this. This patching might be US-specific and we 
cannot simply apply the setting for top channel of another domain 
instead of channel 11. One option would be to set the value only under 
the US regulatory domain.


??
What the patch does is replace the top channel which is hardcoded to 11
by the top channel given by the current regulatory domain. How can that
be wrong? Except that you may want to init the regulatory domain from
the EEPROM but I'm not sure how the ieee80211 code works wrt. that.

johannes


The problem is not so much that I don't trust the geo code, but whether
setting the register to that band-edge value for a higher channel is
the right thing to do. It looks like that this is a hack for FFC
compliance. Therefore I suggest to patch CR128 only
for the US regulatory domain.

Here is the code from the GPL vendor driver (zdhw.c):

   if (pObj->HWFeature & BIT_21)  //6321 for FCC regulation, enabled HWFeature 
6M band edge bit (for AL2230, AL2230S)
{
if (ChannelNo == 1 || ChannelNo == 11)  //MARK_003, band edge, these 
may depend on PCB layout
{
pObj->SetReg(reg, ZD_CR128, 0x12);
pObj->SetReg(reg, ZD_CR129, 0x12);
pObj->SetReg(reg, ZD_CR130, 0x10);
pObj->SetReg(reg, ZD_CR47, 0x1E);
}
else //(ChannelNo 2 ~ 10, 12 ~ 14)
{
pObj->SetReg(reg, ZD_CR128, 0x14);
pObj->SetReg(reg, ZD_CR129, 0x12);
pObj->SetReg(reg, ZD_CR130, 0x10);
pObj->SetReg(reg, ZD_CR47, 0x1E);
}
}

The patch from Holden would set ZD_CR128 to 0x12 for the highest channel,
which would not reflect the logic of the vendor driver.

Kind regards,

Uli

--
Uli Kunitz ([EMAIL PROTECTED])
-
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: [RFC] Any strong reason why socket dentries are hashed in global d_hash table ?

From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Mon, 30 Oct 2006 22:30:39 +0100

> In sock_attach_fd(), we are currently using
> 
> d_add(file->f_dentry, SOCK_INODE(sock));
> 
> This has the effect to insert the dentry into the dentry_hashtable.
> 
> I was wondering if it is really necessary : On a machine with many sockets, 
> the dentry_hashtable lookups may be slowed down for no good reason. (sockets 
> are not accessable by other means than socket() syscall, and not subject to 
> 'unuse and LRU freeable syndrom').
> 
> If we replace d_add(file->f_dentry, SOCK_INODE(sock)) call by
> d_instantiate(file->f_dentry, SOCK_INODE(sock)), we also avoid using rcu 
> callback when socket is closed. (We would have to not provide a 
> d_op->d_delete 
> () method in sockfs_dentry_operations)

Sounds like a useful optimization for sure.

You can't mount sockfs on the filesystem, but they are visible
via /proc/${pid}/fd/, I wonder if the dentry hashing is required
just to make those nodes visible properly?
-
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

[RFC] Any strong reason why socket dentries are hashed in global d_hash table ?

2006-10-30 Thread Eric Dumazet


In sock_attach_fd(), we are currently using

d_add(file->f_dentry, SOCK_INODE(sock));

This has the effect to insert the dentry into the dentry_hashtable.

I was wondering if it is really necessary : On a machine with many sockets, 
the dentry_hashtable lookups may be slowed down for no good reason. (sockets 
are not accessable by other means than socket() syscall, and not subject to 
'unuse and LRU freeable syndrom').


If we replace d_add(file->f_dentry, SOCK_INODE(sock)) call by
d_instantiate(file->f_dentry, SOCK_INODE(sock)), we also avoid using rcu 
callback when socket is closed. (We would have to not provide a d_op->d_delete 
() method in sockfs_dentry_operations)


Maybe I just provide a patch instead of just talking ? :)

Eric
-
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/1] NetLabel: protect the CIPSOv4 socket option from setsockopt()

2006-10-30 Thread Paul Moore

Eric Paris wrote:
> On Mon, 2006-10-30 at 13:03 -0500, [EMAIL PROTECTED] wrote:
> 
>>plain text document attachment (netlabel-sockopts)
>>From: Paul Moore <[EMAIL PROTECTED]>
>>
>>This patch makes two changes to protect applications from either removing or
>>tampering with the CIPSOv4 IP option on a socket.  The first is the 
>>requirement
>>that applications have the CAP_NET_RAW capability to set an IPOPT_CIPSO option
>>on a socket; this prevents untrusted applications from setting their own
>>CIPSOv4 security attributes on the packets they send.  The second change is to
>>SELinux and it prevents applications from setting any IPv4 options when there
>>is an IPOPT_CIPSO option already present on the socket; this prevents
>>applications from removing CIPSOv4 security attributes from the packets they
>>send.
> 
> 
>>--- net-2.6_sockopt.orig/security/selinux/ss/services.c
>>+++ net-2.6_sockopt/security/selinux/ss/services.c
>>@@ -2682,4 +2682,41 @@ u32 selinux_netlbl_socket_getpeersec_dgr
>> 
>>  return peer_sid;
>> }
>>+
>>+/**
>>+ * selinux_netlbl_socket_setsockopt - Do not allow users to remove a NetLabel
>>+ * @sock: the socket
>>+ * @level: the socket level or protocol
>>+ * @optname: the socket option name
>>+ *
>>+ * Description:
>>+ * Check the setsockopt() call and if the user is trying to replace the IP
>>+ * options on a socket and a NetLabel is in place for the socket deny the
>>+ * access; otherwise allow the access.  Returns zero when the access is
>>+ * allowed, -EACCES when denied, and other negative values on error.
>>+ *
>>+ */
>>+int selinux_netlbl_socket_setsockopt(struct socket *sock,
>>+  int level,
>>+  int optname)
>>+{
>>+ int rc = 0;
>>+ struct inode *inode = SOCK_INODE(sock);
>>+ struct sk_security_struct *sksec = sock->sk->sk_security;
>>+ struct inode_security_struct *isec = inode->i_security;
>>+ struct netlbl_lsm_secattr secattr;
>>+
>>+ mutex_lock(&isec->lock);
>>+ if (level == IPPROTO_IP && optname == IP_OPTIONS &&
>>+ sksec->nlbl_state == NLBL_LABELED) {
>>+ netlbl_secattr_init(&secattr);
>>+ rc = netlbl_socket_getattr(sock, &secattr);
>>+ if (rc == 0 && (secattr.cache || secattr.mls_lvl_vld))
>>+ rc = -EACCES;
>>+ netlbl_secattr_destroy(&secattr);
>>+ }
>>+ mutex_unlock(&isec->lock);
>>+
>>+ return rc;
>>+}
>> #endif /* CONFIG_NETLABEL */
> 
> I probably should have ask this a while back but both here and in
> selinux_netlbl_socket_setsid() you are taking the isec->lock.  As I
> originally understood the isec->lock it was just supposed to just
> prevent multiple tasks from initializing the isec information
> simultaneously while the isec information could be in an inconsistent
> state.  After isec->initialized was set we didn't use the lock any more
> (as typically the only change inside the isec was the ->sid which
> couldn't even be 'in the middle').  I'm wondering what you are hoping to
> protect taking this lock.  It doesn't seem like it would hurt anything,
> but i'd like to hear what you see it's purpose as being...   (Then again
> it's just as unlikely that I understood what it was being used for
> pre-netlabel)

Fair question.  It was discussed a while back on either the SELinux or LSPP
mailing list, I don't have a link handy but I'm sure you could find it with your
favorite search engine (it was discussed back when it was a semaphore); I might
be wrong but I think it was Stephen Smalley that suggested using the isec
semaphore/mutex.  Basically, inode_security_struct mutex also protects the
sk_security_struct->nlbl_state field.  You will see some cases where the
nlbl_state field is set/checked without holding the mutex but in those cases
only one thread should have access to the sock.

Perhaps at some point it would make sense to protect this with some other
locking mechanism (rcu might make the most sense) but considering the stage that
2.6.19 is at right now I think we should probably leave it alone right now.

-- 
paul moore
linux security @ hp
-
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/1] NetLabel: protect the CIPSOv4 socket option from setsockopt()

2006-10-30 Thread Eric Paris

On Mon, 2006-10-30 at 13:03 -0500, [EMAIL PROTECTED] wrote:
> plain text document attachment (netlabel-sockopts)
> From: Paul Moore <[EMAIL PROTECTED]>
> 
> This patch makes two changes to protect applications from either removing or
> tampering with the CIPSOv4 IP option on a socket.  The first is the 
> requirement
> that applications have the CAP_NET_RAW capability to set an IPOPT_CIPSO option
> on a socket; this prevents untrusted applications from setting their own
> CIPSOv4 security attributes on the packets they send.  The second change is to
> SELinux and it prevents applications from setting any IPv4 options when there
> is an IPOPT_CIPSO option already present on the socket; this prevents
> applications from removing CIPSOv4 security attributes from the packets they
> send.

> --- net-2.6_sockopt.orig/security/selinux/ss/services.c
> +++ net-2.6_sockopt/security/selinux/ss/services.c
> @@ -2682,4 +2682,41 @@ u32 selinux_netlbl_socket_getpeersec_dgr
>  
>   return peer_sid;
>  }
> +
> +/**
> + * selinux_netlbl_socket_setsockopt - Do not allow users to remove a NetLabel
> + * @sock: the socket
> + * @level: the socket level or protocol
> + * @optname: the socket option name
> + *
> + * Description:
> + * Check the setsockopt() call and if the user is trying to replace the IP
> + * options on a socket and a NetLabel is in place for the socket deny the
> + * access; otherwise allow the access.  Returns zero when the access is
> + * allowed, -EACCES when denied, and other negative values on error.
> + *
> + */
> +int selinux_netlbl_socket_setsockopt(struct socket *sock,
> +  int level,
> +  int optname)
> +{
> + int rc = 0;
> + struct inode *inode = SOCK_INODE(sock);
> + struct sk_security_struct *sksec = sock->sk->sk_security;
> + struct inode_security_struct *isec = inode->i_security;
> + struct netlbl_lsm_secattr secattr;
> +
> + mutex_lock(&isec->lock);
> + if (level == IPPROTO_IP && optname == IP_OPTIONS &&
> + sksec->nlbl_state == NLBL_LABELED) {
> + netlbl_secattr_init(&secattr);
> + rc = netlbl_socket_getattr(sock, &secattr);
> + if (rc == 0 && (secattr.cache || secattr.mls_lvl_vld))
> + rc = -EACCES;
> + netlbl_secattr_destroy(&secattr);
> + }
> + mutex_unlock(&isec->lock);
> +
> + return rc;
> +}
>  #endif /* CONFIG_NETLABEL */

I probably should have ask this a while back but both here and in
selinux_netlbl_socket_setsid() you are taking the isec->lock.  As I
originally understood the isec->lock it was just supposed to just
prevent multiple tasks from initializing the isec information
simultaneously while the isec information could be in an inconsistent
state.  After isec->initialized was set we didn't use the lock any more
(as typically the only change inside the isec was the ->sid which
couldn't even be 'in the middle').  I'm wondering what you are hoping to
protect taking this lock.  It doesn't seem like it would hurt anything,
but i'd like to hear what you see it's purpose as being...   (Then again
it's just as unlikely that I understood what it was being used for
pre-netlabel)

-Eric

-
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 wireless-2.6-git] prism54: WPA/RSN support for fullmac cards

2006-10-30 Thread Dan Williams

On Sun, 2006-10-29 at 14:35 +0200, [EMAIL PROTECTED] wrote:
> This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards.
> I removed all parts which are not relevant for wpa_supplicant (managed mode).
> 
> you can connect to your WLAN with: 
> wpa_supplicant -Dwext -c{WPA_CONF} -i{WPA_ETH} 
> 
> Signed-off-by: Christian Lamparter <[EMAIL PROTECTED]>
> 
> off-topic:
> Can someone please check my changelog for spelling "errors"?

What git tree or kernel source version is this patch based off?  It
doesn't appear to be based off 2.6.18, 2.6.19-rc3, or wireless-dev.  I
wanted to test it out with a WPA access point and see if there are
regressions...

Thanks,
Dan


-
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: Lost packets after switching Wi-Fi AP

2006-10-30 Thread Jiri Benc

On Mon, 30 Oct 2006 15:55:57 +0100, Benjamin Thery wrote:
> When I switch my Mobile Node between 2 Wi-Fi Access Points, there is a 
> period of time where all the packets I send are lost, although I got 
> the netlink event SIOCGIWAP 'up' for the new AP. The device is 
> supposed to be ready, but the packets are lost.

Which wireless card are you using? Which version of the kernel?

 Jiri

-- 
Jiri Benc
SUSE Labs
-
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 wireless-2.6-git] prism54: WPA/RSN support for fullmac cards

2006-10-30 Thread Luis R. Rodriguez


On 10/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards.
I removed all parts which are not relevant for wpa_supplicant (managed mode).


This is great effort and thanks for it! My only concern with the patch
is breaking compatiblity with 2.4 but then again I'm tired of having
to keep this compat work up too and soon, after d80211 full force push
it may not be possible. So I ACK it.

 Luis
-
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: ipw3945?

2006-10-30 Thread Jiri Slaby

Arjan van de Ven wrote:
> On Mon, 2006-10-30 at 19:54 +0100, dragoran wrote:
>> The ipw3945 driver has been out for a while and is not yet upstream.
>> It requires a binary only daemon to work, but I still see no reason not
>> to merge it.
>> Many wlan drivers require binary firmware anyway, so I don't see a
>> reason not to merge it.
> 
> has Intel submitted it for inclusion?
> 
> No.

It seems to be still in a devel phase -- it doesn't work for me (and other 
people):
http://bughost.org/bugzilla/show_bug.cgi?id=1152

regards,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
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] forcedeth: add new NVIDIA pci ids


Mgmt unit set was created first. However, it should not matter.

Ayaz


Jeff Garzik wrote:

You sent two pairs of patches, both labelled "1/2" and "2/2".

Which pair should go first, the pci ids or mgmt unit?
Or does it matter?

Jeff





---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
-
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: e100: Wait for PHY reset to complete?

2006-10-30 Thread Auke Kok


Auke Kok wrote:

Anders Grafström wrote:

Auke Kok wrote:
Allthough the spec itself didn't talk about phy reset times, I've ran 
this

patch with
some debugging output on a few boxes and did some speed/duplex settings,
and the PHY
reset returned succesfull after the very first mdio_read, which is 
before

any msleep(10)
is executed. That is also expected behaviour.

I think you might be confusing this with a MAC reset, which has a
documented 10usec
timeout (see 8255x developers manual). The driver already adheres to 
this

by doing a
20usec delay after software/selective resets.

which gets us back to the original problem: how did your driver end 
up in

loopback mode?
(and, how did you figure out that it did??).



This is what the 2.4.33.3 driver does:

void
e100_phy_reset(struct e100_private *bdp)
{
u16 ctrl_reg;
ctrl_reg = BMCR_RESET;
e100_mdi_write(bdp, MII_BMCR, bdp->phy_addr, ctrl_reg);
/* ieee 802.3 : The reset process shall be completed   */
/* within 0.5 seconds from the settting of PHY reset bit.  */
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(HZ / 2);
}

And here
http://www.cs.helsinki.fi/linux/linux-kernel/2003-23/1245.html
I found this entry:

<[EMAIL PROTECTED]> (03/06/08 1.1218)
[e100] misc
<...>
* Add 1/2 second delay after PHY reset to allow link partner to
see and respond to reset, per IEEE 802.3.


I ran mii-diag when the LEDs went out and the register dump
said it was in loopback. It is somewhat difficult reproduce.
It seems to be timing dependent, something else has to occur
at the same time.
I must confess I have only seen it with the 2.6.13 kernel.
I have not been able to reproduce it with 2.6.18.
But I have found no change in the driver that would fix it so
I suspect the problem is still there.

I have tried adding debug output to see if I can read back the
RESET bit in set state, but then the problem refuses to show
so I don't think I can rule out an unfinished PHY reset.


theoretically, yes, the ieee spec PHY reset timeout is kind of silly: in 
no way do we assume that we have re-negotiated link after 1/2 a second! 
Other code in the driver should take care of that, and since it works 
I'll assume it does ;)


the mdio_read probably acts as a flush to the hardware too - 
masquerading problems, more goodness. Perhaps we should do a single read 
in all cases and forget about the timeout (is there an mdio_write_flush?)


Anders,

It appears that there isn't such a thing as an mdio_write_flush in e100 but we can force 
a flush by reading the status register. Not sure if it works 100% so please give this a 
try and let me know if this fixes the problem for you.


Basically, we're preventing mdio writes that might happen after our reset write from 
being reordered. This might have caused an undefined state.


Auke


---

e100: force mdio write flush after PHY reset

Make sure the PHY reset happens without delay by flushing the reset write.

Signed-off-by: Auke Kok <[EMAIL PROTECTED]>


diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 815eb29..04a52cd 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2197,6 +2197,8 @@ static int e100_set_settings(struct net_
int err;

mdio_write(netdev, nic->mii.phy_id, MII_BMCR, BMCR_RESET);
+   /* flush MDIO write */
+   mdio_read(netdev, nic->mii.phy_id, MII_BMSR);
err = mii_ethtool_sset(&nic->mii, cmd);
e100_exec_cb(nic, NULL, e100_configure);

-
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] forcedeth: add new NVIDIA pci ids

2006-10-30 Thread Jeff Garzik


You sent two pairs of patches, both labelled "1/2" and "2/2".

Which pair should go first, the pci ids or mgmt unit?
Or does it matter?

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

[PATCH,try2 1/3] ep93xx_eth: fix RX/TXstatus ring full handling

Ray Lehtiniemi reported that an incoming UDP packet flood can lock up
the ep93xx ethernet driver.  Herbert Valerio Riedel noted that due to
the way ep93xx_eth manages the RX/TXstatus rings, it cannot distinguish
a full ring from an empty one, and correctly suggested that this was
likely to be causing this lockup to occur.

Instead of looking at the hardware's RX/TXstatus ring write pointers
to determine when to stop reading from those rings, we should just check
every individual RX/TXstatus descriptor's valid bit instead, since there
is no other way to distinguish an empty ring from a full ring, and if
there is a descriptor waiting, we take the hit of reading the descriptor
from memory anyway.

Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]>

Index: linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
===
--- linux-2.6.19-rc3.orig/drivers/net/arm/ep93xx_eth.c
+++ linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
@@ -193,12 +193,9 @@ static struct net_device_stats *ep93xx_g
 static int ep93xx_rx(struct net_device *dev, int *budget)
 {
struct ep93xx_priv *ep = netdev_priv(dev);
-   int tail_offset;
int rx_done;
int processed;
 
-   tail_offset = rdl(ep, REG_RXSTSQCURADD) - ep->descs_dma_addr;
-
rx_done = 0;
processed = 0;
while (*budget > 0) {
@@ -211,28 +208,23 @@ static int ep93xx_rx(struct net_device *
 
entry = ep->rx_pointer;
rstat = ep->descs->rstat + entry;
-   if ((void *)rstat - (void *)ep->descs == tail_offset) {
+
+   rstat0 = rstat->rstat0;
+   rstat1 = rstat->rstat1;
+   if (!(rstat0 & RSTAT0_RFP) || !(rstat1 & RSTAT1_RFP)) {
rx_done = 1;
break;
}
 
-   rstat0 = rstat->rstat0;
-   rstat1 = rstat->rstat1;
rstat->rstat0 = 0;
rstat->rstat1 = 0;
 
-   if (!(rstat0 & RSTAT0_RFP))
-   printk(KERN_CRIT "ep93xx_rx: buffer not done "
-" %.8x %.8x\n", rstat0, rstat1);
if (!(rstat0 & RSTAT0_EOF))
printk(KERN_CRIT "ep93xx_rx: not end-of-frame "
 " %.8x %.8x\n", rstat0, rstat1);
if (!(rstat0 & RSTAT0_EOB))
printk(KERN_CRIT "ep93xx_rx: not end-of-buffer "
 " %.8x %.8x\n", rstat0, rstat1);
-   if (!(rstat1 & RSTAT1_RFP))
-   printk(KERN_CRIT "ep93xx_rx: buffer1 not done "
-" %.8x %.8x\n", rstat0, rstat1);
if ((rstat1 & RSTAT1_BUFFER_INDEX) >> 16 != entry)
printk(KERN_CRIT "ep93xx_rx: entry mismatch "
 " %.8x %.8x\n", rstat0, rstat1);
@@ -301,13 +293,8 @@ err:
 
 static int ep93xx_have_more_rx(struct ep93xx_priv *ep)
 {
-   struct ep93xx_rstat *rstat;
-   int tail_offset;
-
-   rstat = ep->descs->rstat + ep->rx_pointer;
-   tail_offset = rdl(ep, REG_RXSTSQCURADD) - ep->descs_dma_addr;
-
-   return !((void *)rstat - (void *)ep->descs == tail_offset);
+   struct ep93xx_rstat *rstat = ep->descs->rstat + ep->rx_pointer;
+   return !!((rstat->rstat0 & RSTAT0_RFP) && (rstat->rstat1 & RSTAT1_RFP));
 }
 
 static int ep93xx_poll(struct net_device *dev, int *budget)
@@ -379,10 +366,8 @@ static int ep93xx_xmit(struct sk_buff *s
 static void ep93xx_tx_complete(struct net_device *dev)
 {
struct ep93xx_priv *ep = netdev_priv(dev);
-   int tail_offset;
int wake;
 
-   tail_offset = rdl(ep, REG_TXSTSQCURADD) - ep->descs_dma_addr;
wake = 0;
 
spin_lock(&ep->tx_pending_lock);
@@ -393,15 +378,13 @@ static void ep93xx_tx_complete(struct ne
 
entry = ep->tx_clean_pointer;
tstat = ep->descs->tstat + entry;
-   if ((void *)tstat - (void *)ep->descs == tail_offset)
-   break;
 
tstat0 = tstat->tstat0;
+   if (!(tstat0 & TSTAT0_TXFP))
+   break;
+
tstat->tstat0 = 0;
 
-   if (!(tstat0 & TSTAT0_TXFP))
-   printk(KERN_CRIT "ep93xx_tx_complete: buffer not done "
-" %.8x\n", tstat0);
if (tstat0 & TSTAT0_FA)
printk(KERN_CRIT "ep93xx_tx_complete: frame aborted "
 " %.8x\n", tstat0);
-
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,try2 0/3] ep93xx_eth: three fixes for 2.6.19

This patchset fixes three issues in ep93xx_eth.  The first fix is for
an RX/TX lockup bug due to mishandling of the RX/TXstatus rings in the
driver, and is a showstopper.  The second and third aren't really
showstopper bugs, but real issues nevertheless, and easy enough to fix.

In this new queue, I've replaced the third patch, which modified
ep93xx_eth to only printk for non-FIFO overrun-type RX errors, by a
patch which stops ep93xx_eth reporting RX errors at all, since it makes
little sense, and the regular error counters should be sufficient.

Please apply for 2.6.19 -- 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,try3 3/3] ep93xx_eth: don't report RX errors

Flooding the console with error messages for every RX FIFO overrun,
checksum error and framing error isn't very sensible.  Each of these
errors can occur during normal operation, so stop printk'ing error
messages for RX errors at all.

Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]>

Index: linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
===
--- linux-2.6.19-rc3.orig/drivers/net/arm/ep93xx_eth.c
+++ linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
@@ -230,9 +230,6 @@ static int ep93xx_rx(struct net_device *
 " %.8x %.8x\n", rstat0, rstat1);
 
if (!(rstat0 & RSTAT0_RWE)) {
-   printk(KERN_NOTICE "ep93xx_rx: receive error "
-" %.8x %.8x\n", rstat0, rstat1);
-
ep->stats.rx_errors++;
if (rstat0 & RSTAT0_OE)
ep->stats.rx_fifo_errors++;
-
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

ipw3945?

2006-10-30 Thread dragoran


The ipw3945 driver has been out for a while and is not yet upstream.
It requires a binary only daemon to work, but I still see no reason not
to merge it.
Many wlan drivers require binary firmware anyway, so I don't see a
reason not to merge it.
I also have read this: http://lwn.net/Articles/205988/ (and the old
thread on lkml/netdev)
Can this be used to make the driver work without the daemon?
It seems that the development of the driver has stopped since july,
maybe because it never will get merged and intel decided to stop working
on it?
If this is true it could mean that feature intel wlan chips will end up
with no linux drivers :(

please CC me ...
-
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/1] NetLabel: protect the CIPSOv4 socket option from setsockopt()

2006-10-30 Thread James Morris

On Mon, 30 Oct 2006, [EMAIL PROTECTED] wrote:

> From: Paul Moore <[EMAIL PROTECTED]>
> 
> This patch makes two changes to protect applications from either removing or
> tampering with the CIPSOv4 IP option on a socket. 

Thanks.  Applied to:

git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-net-2.6.git




-- 
James Morris
<[EMAIL PROTECTED]>
-
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,try2 2/3] ep93xx_eth: fix unlikely(x) > y test

Fix unlikely(x) > y test in ep93xx_eth.

Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]>

Index: linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
===
--- linux-2.6.19-rc3.orig/drivers/net/arm/ep93xx_eth.c
+++ linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
@@ -334,7 +334,7 @@ static int ep93xx_xmit(struct sk_buff *s
struct ep93xx_priv *ep = netdev_priv(dev);
int entry;
 
-   if (unlikely(skb->len) > MAX_PKT_SIZE) {
+   if (unlikely(skb->len > MAX_PKT_SIZE)) {
ep->stats.tx_dropped++;
dev_kfree_skb(skb);
return NETDEV_TX_OK;
-
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] forcedeth: add new NVIDIA pci ids


This patch adds pci device ids for the NVIDIA MCP67 chip.

Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>

--- a/include/linux/pci_ids.h   2006-10-30 17:22:09.0 -0500
+++ b/include/linux/pci_ids.h   2006-10-30 17:22:17.0 -0500
@@ -1213,6 +1213,10 @@
 #define PCI_DEVICE_ID_NVIDIA_NVENET_21  0x0451
 #define PCI_DEVICE_ID_NVIDIA_NVENET_22  0x0452
 #define PCI_DEVICE_ID_NVIDIA_NVENET_23  0x0453
+#define PCI_DEVICE_ID_NVIDIA_NVENET_24  0x054C
+#define PCI_DEVICE_ID_NVIDIA_NVENET_25  0x054D
+#define PCI_DEVICE_ID_NVIDIA_NVENET_26  0x054E
+#define PCI_DEVICE_ID_NVIDIA_NVENET_27  0x054F
 
 #define PCI_VENDOR_ID_IMS  0x10e0
 #define PCI_DEVICE_ID_IMS_TT1280x9128

ipw3945?

2006-10-30 Thread dragoran


The ipw3945 driver has been out for a while and is not yet upstream.
It requires a binary only daemon to work, but I still see no reason not 
to merge it.
Many wlan drivers require binary firmware anyway, so I don't see a 
reason not to merge it.
I also have read this: http://lwn.net/Articles/205988/ (and the old 
thread on lkml/netdev)

Can this be used to make the driver work without the daemon?
It seems that the development of the driver has stopped since july, 
maybe because it never will get merged and intel decided to stop working 
on it?
If this is true it could mean that feature intel wlan chips will end up 
with no linux drivers :(

-
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: ipw3945?

2006-10-30 Thread Arjan van de Ven

On Mon, 2006-10-30 at 19:54 +0100, dragoran wrote:
> The ipw3945 driver has been out for a while and is not yet upstream.
> It requires a binary only daemon to work, but I still see no reason not
> to merge it.
> Many wlan drivers require binary firmware anyway, so I don't see a
> reason not to merge it.

has Intel submitted it for inclusion?

No.

> It seems that the development of the driver has stopped since july,
> maybe because it never will get merged and intel decided to stop working
> on it?

No this is not correct. I'll let James comment on what we are doing
though, he can explain that a lot better than I can.


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

-
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

[PATC 2/2] forcedeth: add support for new mcp67 device


This patch adds support for the new mcp67 device into forcedeth.

Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>

--- orig-2.6/drivers/net/forcedeth.c2006-10-30 16:26:57.0 -0500
+++ new-2.6/drivers/net/forcedeth.c 2006-10-30 17:08:46.0 -0500
@@ -4927,6 +4927,22 @@
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 
PCI_DEVICE_ID_NVIDIA_NVENET_23),
.driver_data = 
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
},
+   {   /* MCP67 Ethernet Controller */
+   PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 
PCI_DEVICE_ID_NVIDIA_NVENET_24),
+   .driver_data = 
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+   },
+   {   /* MCP67 Ethernet Controller */
+   PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 
PCI_DEVICE_ID_NVIDIA_NVENET_25),
+   .driver_data = 
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+   },
+   {   /* MCP67 Ethernet Controller */
+   PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 
PCI_DEVICE_ID_NVIDIA_NVENET_26),
+   .driver_data = 
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+   },
+   {   /* MCP67 Ethernet Controller */
+   PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 
PCI_DEVICE_ID_NVIDIA_NVENET_27),
+   .driver_data = 
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+   },
{0,},
 };

[PATCH 1/2] forcedeth: add mgmt unit support

This patch adds support for the mgmt unit in certain chipsets. The MAC 
and the mgmt unit share the PHY and therefore proper intialization 
procedures are needed for them to maintain coexistense.


Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>

--- orig-2.6/drivers/net/forcedeth.c2006-10-30 16:03:56.0 -0500
+++ new-2.6/drivers/net/forcedeth.c 2006-10-30 16:04:03.0 -0500
@@ -110,6 +110,7 @@
  * 0.55: 22 Mar 2006: Add flow control (pause frame).
  * 0.56: 22 Mar 2006: Additional ethtool config and moduleparam support.
  * 0.57: 14 May 2006: Mac address set in probe/remove and order 
corrections.
+ * 0.58: 30 Oct 2006: Added support for sideband management unit.
  *
  * Known bugs:
  * We suspect that on some hardware no TX done interrupts are generated.
@@ -126,7 +127,7 @@
 #else
 #define DRIVERNAPI
 #endif
-#define FORCEDETH_VERSION  "0.57"
+#define FORCEDETH_VERSION  "0.58"
 #define DRV_NAME   "forcedeth"
 
 #include 
@@ -174,6 +175,7 @@
 #define DEV_HAS_PAUSEFRAME_TX   0x0200  /* device supports tx pause frames */
 #define DEV_HAS_STATISTICS  0x0400  /* device supports hw statistics */
 #define DEV_HAS_TEST_EXTENDED   0x0800  /* device supports extended diagnostic 
test */
+#define DEV_HAS_MGMT_UNIT   0x1000  /* device supports management unit */
 
 enum {
NvRegIrqStatus = 0x000,
@@ -222,6 +224,15 @@
 #define NVREG_MAC_RESET_ASSERT 0x0F3
NvRegTransmitterControl = 0x084,
 #define NVREG_XMITCTL_START0x01
+#define NVREG_XMITCTL_MGMT_ST  0x4000
+#define NVREG_XMITCTL_SYNC_MASK0x000f
+#define NVREG_XMITCTL_SYNC_NOT_READY   0x0
+#define NVREG_XMITCTL_SYNC_PHY_INIT0x0004
+#define NVREG_XMITCTL_MGMT_SEMA_MASK   0x0f00
+#define NVREG_XMITCTL_MGMT_SEMA_FREE   0x0
+#define NVREG_XMITCTL_HOST_SEMA_MASK   0xf000
+#define NVREG_XMITCTL_HOST_SEMA_ACQ0xf000
+#define NVREG_XMITCTL_HOST_LOADED  0x4000
NvRegTransmitterStatus = 0x088,
 #define NVREG_XMITSTAT_BUSY0x01
 
@@ -304,8 +315,8 @@
 #define NVREG_MIISTAT_LINKCHANGE   0x0008
 #define NVREG_MIISTAT_MASK 0x000f
 #define NVREG_MIISTAT_MASK20x000f
-   NvRegUnknownSetupReg4 = 0x184,
-#define NVREG_UNKSETUP4_VAL8
+   NvRegMIIMask = 0x184,
+#define NVREG_MII_LINKCHANGE   0x0008
 
NvRegAdapterControl = 0x188,
 #define NVREG_ADAPTCTL_START   0x02
@@ -719,6 +730,7 @@
u32 driver_data;
u32 register_size;
int rx_csum;
+   u32 mac_in_use;
 
void __iomem *base;
 
@@ -4030,6 +4042,54 @@
/* nothing to do */
 };
 
+/* The mgmt unit and driver use a semaphore to access the phy during init */
+static int nv_mgmt_acquire_sema(struct net_device *dev)
+{
+   u8 __iomem *base = get_hwbase(dev);
+   int i;
+   u32 tx_ctrl, mgmt_sema;
+
+   for (i = 0; i < 10; i++) {
+   mgmt_sema = readl(base + NvRegTransmitterControl) & 
NVREG_XMITCTL_MGMT_SEMA_MASK;
+   if (mgmt_sema == NVREG_XMITCTL_MGMT_SEMA_FREE)
+   break;
+   msleep(500);
+   }
+
+   if (mgmt_sema != NVREG_XMITCTL_MGMT_SEMA_FREE)
+   return 0;
+
+   for (i = 0; i < 2; i++) {
+   tx_ctrl = readl(base + NvRegTransmitterControl);
+   tx_ctrl |= NVREG_XMITCTL_HOST_SEMA_ACQ;
+   writel(tx_ctrl, base + NvRegTransmitterControl);
+
+   /* verify that semaphore was acquired */
+   tx_ctrl = readl(base + NvRegTransmitterControl);
+   if (((tx_ctrl & NVREG_XMITCTL_HOST_SEMA_MASK) == 
NVREG_XMITCTL_HOST_SEMA_ACQ) &&
+   ((tx_ctrl & NVREG_XMITCTL_MGMT_SEMA_MASK) == 
NVREG_XMITCTL_MGMT_SEMA_FREE))
+   return 1;
+   else
+   udelay(50);
+   }
+
+   return 0;
+}
+
+/* Indicate to mgmt unit whether driver is loaded or not */
+static void nv_mgmt_driver_loaded(struct net_device *dev, int loaded)
+{
+   u8 __iomem *base = get_hwbase(dev);
+   u32 tx_ctrl;
+
+   tx_ctrl = readl(base + NvRegTransmitterControl);
+   if (loaded)
+   tx_ctrl |= NVREG_XMITCTL_HOST_LOADED;
+   else
+   tx_ctrl &= ~NVREG_XMITCTL_HOST_LOADED;
+   writel(tx_ctrl, base + NvRegTransmitterControl);
+}
+
 static int nv_open(struct net_device *dev)
 {
struct fe_priv *np = netdev_priv(dev);
@@ -4085,7 +4145,7 @@
NV_SETUP5_DELAY, NV_SETUP5_DELAYMAX,
KERN_INFO "open: SetupReg5, Bit 31 remained off\n");
 
-   writel(0, base + NvRegUnknownSetupReg4);
+   writel(0, base + NvRegMIIMask);
writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus);
writel(NVREG_MIISTAT_MASK2, base + NvRegMIIStatus);
 
@@ -4111,7 +4171,7 @@
writel((np->phyaddr << 
NVREG_ADAPTCTL_PHYSHIFT)|NVREG_ADAPTCTL_PHYVALID|NVREG_ADAPTCTL_RUNNING,
base + NvRegA

[PATCH 2/2] forcedeth: add recoverable error support

This patch adds support to recover from a previously fatal MAC error. In 
the past the MAC would be hung on an internal fatal error. On new 
chipsets, the MAC has the ability to enter a non-fatal state and allow 
the driver to re-init it.


Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>

--- orig-2.6/drivers/net/forcedeth.c2006-10-30 16:07:05.0 -0500
+++ new-2.6/drivers/net/forcedeth.c 2006-10-30 16:23:43.0 -0500
@@ -111,6 +111,7 @@
  * 0.56: 22 Mar 2006: Additional ethtool config and moduleparam support.
  * 0.57: 14 May 2006: Mac address set in probe/remove and order 
corrections.
  * 0.58: 30 Oct 2006: Added support for sideband management unit.
+ * 0.59: 30 Oct 2006: Added support for recoverable error.
  *
  * Known bugs:
  * We suspect that on some hardware no TX done interrupts are generated.
@@ -127,7 +128,7 @@
 #else
 #define DRIVERNAPI
 #endif
-#define FORCEDETH_VERSION  "0.58"
+#define FORCEDETH_VERSION  "0.59"
 #define DRV_NAME   "forcedeth"
 
 #include 
@@ -180,7 +181,7 @@
 enum {
NvRegIrqStatus = 0x000,
 #define NVREG_IRQSTAT_MIIEVENT 0x040
-#define NVREG_IRQSTAT_MASK 0x1ff
+#define NVREG_IRQSTAT_MASK 0x81ff
NvRegIrqMask = 0x004,
 #define NVREG_IRQ_RX_ERROR 0x0001
 #define NVREG_IRQ_RX   0x0002
@@ -191,15 +192,16 @@
 #define NVREG_IRQ_LINK 0x0040
 #define NVREG_IRQ_RX_FORCED0x0080
 #define NVREG_IRQ_TX_FORCED0x0100
+#define NVREG_IRQ_RECOVER_ERROR0x8000
 #define NVREG_IRQMASK_THROUGHPUT   0x00df
 #define NVREG_IRQMASK_CPU  0x0040
 #define NVREG_IRQ_TX_ALL   
(NVREG_IRQ_TX_ERR|NVREG_IRQ_TX_OK|NVREG_IRQ_TX_FORCED)
 #define NVREG_IRQ_RX_ALL   
(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_RX_FORCED)
-#define NVREG_IRQ_OTHER(NVREG_IRQ_TIMER|NVREG_IRQ_LINK)
+#define NVREG_IRQ_OTHER
(NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_RECOVER_ERROR)
 
 #define NVREG_IRQ_UNKNOWN  
(~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR| \

NVREG_IRQ_TX_OK|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_RX_FORCED| \
-   NVREG_IRQ_TX_FORCED))
+   
NVREG_IRQ_TX_FORCED|NVREG_IRQ_RECOVER_ERROR))
 
NvRegUnknownSetupReg6 = 0x008,
 #define NVREG_UNKSETUP6_VAL3
@@ -718,6 +720,7 @@
unsigned int phy_model;
u16 gigabit;
int intr_test;
+   int recover_error;
 
/* General data: RO fields */
dma_addr_t ring_addr;
@@ -2455,6 +2458,23 @@
printk(KERN_DEBUG "%s: received irq with unknown events 
0x%x. Please report\n",
dev->name, events);
}
+   if (unlikely(events & NVREG_IRQ_RECOVER_ERROR)) {
+   spin_lock(&np->lock);
+   /* disable interrupts on the nic */
+   if (!(np->msi_flags & NV_MSI_X_ENABLED))
+   writel(0, base + NvRegIrqMask);
+   else
+   writel(np->irqmask, base + NvRegIrqMask);
+   pci_push(base);
+
+   if (!np->in_shutdown) {
+   np->nic_poll_irq = np->irqmask;
+   np->recover_error = 1;
+   mod_timer(&np->nic_poll, jiffies + POLL_WAIT);
+   }
+   spin_unlock(&np->lock);
+   break;
+   }
 #ifdef CONFIG_FORCEDETH_NAPI
if (events & NVREG_IRQ_RX_ALL) {
netif_rx_schedule(dev);
@@ -2685,6 +2705,20 @@
spin_unlock_irqrestore(&np->lock, flags);
np->link_timeout = jiffies + LINK_TIMEOUT;
}
+   if (events & NVREG_IRQ_RECOVER_ERROR) {
+   spin_lock_irq(&np->lock);
+   /* disable interrupts on the nic */
+   writel(NVREG_IRQ_OTHER, base + NvRegIrqMask);
+   pci_push(base);
+
+   if (!np->in_shutdown) {
+   np->nic_poll_irq |= NVREG_IRQ_OTHER;
+   np->recover_error = 1;
+   mod_timer(&np->nic_poll, jiffies + POLL_WAIT);
+   }
+   spin_unlock_irq(&np->lock);
+   break;
+   }
if (events & (NVREG_IRQ_UNKNOWN)) {
printk(KERN_DEBUG "%s: received irq with unknown events 
0x%x. Please report\n",
dev->name, events);
@@ -2914,6 +2948,42 @@
}
np->nic_poll

[patch 0/1] NetLabel bugfix for 2.6.19

2006-10-30 Thread paul . moore

Sorry, but another bugfix patch for NetLabel which I think should be included
2.6.19.

The problem is that the SELinux reference policy is a bit more free in allowing
applications to call setsockopt() than I had originally thought, which means
that normal applications could add or tamper with the NetLabel/CIPSO options on
a socket causing all sorts of nastiness.  This patch should solve these
problems.

--
paul moore
linux security @ hp
-
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/1] NetLabel: protect the CIPSOv4 socket option from setsockopt()

2006-10-30 Thread paul . moore

From: Paul Moore <[EMAIL PROTECTED]>

This patch makes two changes to protect applications from either removing or
tampering with the CIPSOv4 IP option on a socket.  The first is the requirement
that applications have the CAP_NET_RAW capability to set an IPOPT_CIPSO option
on a socket; this prevents untrusted applications from setting their own
CIPSOv4 security attributes on the packets they send.  The second change is to
SELinux and it prevents applications from setting any IPv4 options when there
is an IPOPT_CIPSO option already present on the socket; this prevents
applications from removing CIPSOv4 security attributes from the packets they
send.

Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
---
 net/ipv4/cipso_ipv4.c   |7 ++---
 net/ipv4/ip_options.c   |2 -
 security/selinux/hooks.c|8 +-
 security/selinux/include/selinux_netlabel.h |   10 +++
 security/selinux/ss/services.c  |   37 
 5 files changed, 58 insertions(+), 6 deletions(-)

Index: net-2.6_sockopt/net/ipv4/cipso_ipv4.c
===
--- net-2.6_sockopt.orig/net/ipv4/cipso_ipv4.c
+++ net-2.6_sockopt/net/ipv4/cipso_ipv4.c
@@ -1307,7 +1307,8 @@ int cipso_v4_socket_setattr(const struct
 
/* We can't use ip_options_get() directly because it makes a call to
 * ip_options_get_alloc() which allocates memory with GFP_KERNEL and
-* we can't block here. */
+* we won't always have CAP_NET_RAW even though we _always_ want to
+* set the IPOPT_CIPSO option. */
opt_len = (buf_len + 3) & ~3;
opt = kzalloc(sizeof(*opt) + opt_len, GFP_ATOMIC);
if (opt == NULL) {
@@ -1317,11 +1318,9 @@ int cipso_v4_socket_setattr(const struct
memcpy(opt->__data, buf, buf_len);
opt->optlen = opt_len;
opt->is_data = 1;
+   opt->cipso = sizeof(struct iphdr);
kfree(buf);
buf = NULL;
-   ret_val = ip_options_compile(opt, NULL);
-   if (ret_val != 0)
-   goto socket_setattr_failure;
 
sk_inet = inet_sk(sk);
if (sk_inet->is_icsk) {
Index: net-2.6_sockopt/net/ipv4/ip_options.c
===
--- net-2.6_sockopt.orig/net/ipv4/ip_options.c
+++ net-2.6_sockopt/net/ipv4/ip_options.c
@@ -443,7 +443,7 @@ int ip_options_compile(struct ip_options
opt->router_alert = optptr - iph;
break;
  case IPOPT_CIPSO:
-   if (opt->cipso) {
+   if ((!skb && !capable(CAP_NET_RAW)) || opt->cipso) {
pp_ptr = optptr;
goto error;
}
Index: net-2.6_sockopt/security/selinux/hooks.c
===
--- net-2.6_sockopt.orig/security/selinux/hooks.c
+++ net-2.6_sockopt/security/selinux/hooks.c
@@ -3313,7 +3313,13 @@ static int selinux_socket_getpeername(st
 
 static int selinux_socket_setsockopt(struct socket *sock,int level,int optname)
 {
-   return socket_has_perm(current, sock, SOCKET__SETOPT);
+   int err;
+
+   err = socket_has_perm(current, sock, SOCKET__SETOPT);
+   if (err)
+   return err;
+
+   return selinux_netlbl_socket_setsockopt(sock, level, optname);
 }
 
 static int selinux_socket_getsockopt(struct socket *sock, int level,
Index: net-2.6_sockopt/security/selinux/include/selinux_netlabel.h
===
--- net-2.6_sockopt.orig/security/selinux/include/selinux_netlabel.h
+++ net-2.6_sockopt/security/selinux/include/selinux_netlabel.h
@@ -53,6 +53,9 @@ void selinux_netlbl_sk_security_init(str
 void selinux_netlbl_sk_clone_security(struct sk_security_struct *ssec,
  struct sk_security_struct *newssec);
 int selinux_netlbl_inode_permission(struct inode *inode, int mask);
+int selinux_netlbl_socket_setsockopt(struct socket *sock,
+int level,
+int optname);
 #else
 static inline void selinux_netlbl_cache_invalidate(void)
 {
@@ -114,6 +117,13 @@ static inline int selinux_netlbl_inode_p
 {
return 0;
 }
+
+static inline int selinux_netlbl_socket_setsockopt(struct socket *sock,
+  int level,
+  int optname)
+{
+   return 0;
+}
 #endif /* CONFIG_NETLABEL */
 
 #endif
Index: net-2.6_sockopt/security/selinux/ss/services.c
===
--- net-2.6_sockopt.orig/security/selinux/ss/services.c
+++ net-2.6_sockopt/security/selinux/ss/services.c
@@ -2682,4 +2682,41 @@ u32 selinux_netlbl_socket_getpeersec_dgr
 
return peer_sid;
 }
+
+/**
+ * selinux

[take1] d80211: switch crypto to use new ciphers API

2006-10-30 Thread David Kimdon

On Thu, Oct 26, 2006 at 10:06:24AM +1000, Herbert Xu wrote:
> If you're only encrypting/decrypting a single block then you should
> use the cipher interface.  So net/d80211/aes_ccm.c should do that
> instead.  See drivers/net/wirless/airo.c for an example of that.

Thanks Herbert.

Updated patch, now aes, tkip and wep are all tested.

Changes from take0:

Use IS_ERR() to evaluate return value of crypto_alloc_cipher().  Use
ciper interface rather than blkcipher for aes encryption since we only
encrypt a single block at a time.



Switch d80211 software crypto to use the new cipher API.

Signed-off-by: David Kimdon <[EMAIL PROTECTED]>

Index: wireless-dev/net/d80211/wep.c
===
--- wireless-dev.orig/net/d80211/wep.c
+++ wireless-dev/net/d80211/wep.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -26,8 +27,9 @@ int ieee80211_wep_init(struct ieee80211_
/* start WEP IV from a random value */
get_random_bytes(&local->wep_iv, WEP_IV_LEN);
 
-   local->wep_tfm = crypto_alloc_tfm("arc4", 0);
-   if (!local->wep_tfm)
+   local->wep_tfm = crypto_alloc_blkcipher("ecb(arc4)", 0,
+   CRYPTO_ALG_ASYNC);
+   if (IS_ERR(local->wep_tfm))
return -ENOMEM;
 
return 0;
@@ -35,7 +37,7 @@ int ieee80211_wep_init(struct ieee80211_
 
 void ieee80211_wep_free(struct ieee80211_local *local)
 {
-   crypto_free_tfm(local->wep_tfm);
+   crypto_free_blkcipher(local->wep_tfm);
 }
 
 static inline int ieee80211_wep_weak_iv(u32 iv, int keylen)
@@ -116,20 +118,21 @@ void ieee80211_wep_remove_iv(struct ieee
 /* Perform WEP encryption using given key. data buffer must have tailroom
  * for 4-byte ICV. data_len must not include this ICV. Note: this function
  * does _not_ add IV. data = RC4(data | CRC32(data)) */
-void ieee80211_wep_encrypt_data(struct crypto_tfm *tfm, u8 *rc4key,
+void ieee80211_wep_encrypt_data(struct crypto_blkcipher *tfm, u8 *rc4key,
size_t klen, u8 *data, size_t data_len)
 {
+   struct blkcipher_desc desc = { .tfm = tfm };
struct scatterlist sg;
__le32 *icv;
 
icv = (__le32 *)(data + data_len);
*icv = cpu_to_le32(~crc32_le(~0, data, data_len));
 
-   crypto_cipher_setkey(tfm, rc4key, klen);
+   crypto_blkcipher_setkey(tfm, rc4key, klen);
sg.page = virt_to_page(data);
sg.offset = offset_in_page(data);
sg.length = data_len + WEP_ICV_LEN;
-   crypto_cipher_encrypt(tfm, &sg, &sg, sg.length);
+   crypto_blkcipher_encrypt(&desc, &sg, &sg, sg.length);
 }
 
 
@@ -183,17 +186,18 @@ int ieee80211_wep_encrypt(struct ieee802
 /* Perform WEP decryption using given key. data buffer includes encrypted
  * payload, including 4-byte ICV, but _not_ IV. data_len must not include ICV.
  * Return 0 on success and -1 on ICV mismatch. */
-int ieee80211_wep_decrypt_data(struct crypto_tfm *tfm, u8 *rc4key,
+int ieee80211_wep_decrypt_data(struct crypto_blkcipher *tfm, u8 *rc4key,
   size_t klen, u8 *data, size_t data_len)
 {
+   struct blkcipher_desc desc = { .tfm = tfm };
struct scatterlist sg;
__le32 crc;
 
-   crypto_cipher_setkey(tfm, rc4key, klen);
+   crypto_blkcipher_setkey(tfm, rc4key, klen);
sg.page = virt_to_page(data);
sg.offset = offset_in_page(data);
sg.length = data_len + WEP_ICV_LEN;
-   crypto_cipher_decrypt(tfm, &sg, &sg, sg.length);
+   crypto_blkcipher_decrypt(&desc, &sg, &sg, sg.length);
 
crc = cpu_to_le32(~crc32_le(~0, data, data_len));
if (memcmp(&crc, data + data_len, WEP_ICV_LEN) != 0)
Index: wireless-dev/net/d80211/aes_ccm.c
===
--- wireless-dev.orig/net/d80211/aes_ccm.c
+++ wireless-dev/net/d80211/aes_ccm.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -16,24 +17,14 @@
 #include "aes_ccm.h"
 
 
-static void ieee80211_aes_encrypt(struct crypto_tfm *tfm,
+static void ieee80211_aes_encrypt(struct crypto_cipher *tfm,
  const u8 pt[16], u8 ct[16])
 {
-   struct scatterlist src, dst;
-
-   src.page = virt_to_page(pt);
-   src.offset = offset_in_page(pt);
-   src.length = AES_BLOCK_LEN;
-
-   dst.page = virt_to_page(ct);
-   dst.offset = offset_in_page(ct);
-   dst.length = AES_BLOCK_LEN;
-
-   crypto_cipher_encrypt(tfm, &dst, &src, AES_BLOCK_LEN);
+   crypto_cipher_encrypt_one(tfm, ct, pt);
 }
 
 
-static inline void aes_ccm_prepare(struct crypto_tfm *tfm, u8 *b_0, u8 *aad,
+static inline void aes_ccm_prepare(struct crypto_cipher *tfm, u8 *b_0, u8 *aad,
   u8 *b, u8 *s_0, u8 *a)
 {
int i;
@@ -61,7 +52,7 @@ static inline void aes_ccm_prepare(struc
 }
 
 
-void ieee80211_aes_ccm_encrypt(struct crypto_tfm *t

Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11

2006-10-30 Thread Holden Karau

Hi Ulrich,

I'm fairly certain the patch is safe, even for non-US regulatory domains.

Looking at the zd1211rw code the highest channel in the geo object
would appear to be set in zd_geo_init as determined by
zd_channel_range which just does a simple look up in channel_ranges[],
so if this code behaves correctly [and there is no indication it does
not], then setting the upper channel to be that in the geo object
would appear to be safe for any of the supported regulatory domains.

Cheers,

Holden :-)

On 10/30/06, Johannes Berg <[EMAIL PROTECTED]> wrote:

> I'm not so sure about this. This patching might be US-specific and we
> cannot simply apply the setting for top channel of another domain
> instead of channel 11. One option would be to set the value only under
> the US regulatory domain.

??
What the patch does is replace the top channel which is hardcoded to 11
by the top channel given by the current regulatory domain. How can that
be wrong? Except that you may want to init the regulatory domain from
the EEPROM but I'm not sure how the ieee80211 code works wrt. that.

johannes

--
Cell: 613-276-1645
-
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: watchdog timeout panic in e1000 driver

2006-10-30 Thread Auke Kok

Kenzo Iwami wrote:

Hi,

Thank you for your comment.

Anyway as I said in the same e-mail, we're working on reducing the lock timeout to a
reasonable time. This will unfortunately take some time, as we need to change some major
components in the driver to make sure this doesn't happen.

How about the following approach?

If acquiring semaphore fails inside the interrupt handler, acquiring semaphore
is abandoned immediately without waiting for timeout.
However, I don't know whether this method affects other processes.

with the current hardware being accessed simultaneously from several users in the
kernel, that would lead to large problems - the watchdog task accesses it every 2
seconds as it reads the PHY link status, so when one of those fails the driver would
have no choice but to reset the entire device.

>>>

This problem occurs because interrupt handler is executed while the
interrupted code is still holding the semaphore. Acquiring the semaphore
fails regardless of the timeout period.

I think the watchdog task will fail trying to read the PHY link status,
even if the lock timeout period has been reduced.

>>
correct, we're not looking into reducing the lock timeout but towards reducing the total
lock time. Once we have reduced that to something acceptable, we can reduce the timout
accordingly.

Even if the total lock time can be reduced, it's possible that interrupt
handler is executed while the interrupted code is still holding the semaphore.
I think your method only decrease the frequency of this problem.
Why does reducing the lock time solve this problem?

there are several problems here that need addressing. It's not acceptable for our driver
to wait up to 15 seconds, and we can (presumably) reduce it to milliseconds, so that
would help a lot. We should in no case at all hold it for any period longer than (give
or take) half a second, so working towards that is a very good step in the right direction.

Adding the timer task back may also help, as we are no longer trying to aqcuire the
sw_fw_semaphore in interrupt context, but we removed it for a reason, and I need to dig
up what reason this exactly was before we can revert it. Jesse might know, so I'll talk
to him. But this will not fix the fact that the semaphore is held for a long time :)

so, this needs two fixes. much to do.

Cheers,

Auke
-
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: Bridge & it's MAC address question

2006-10-30 Thread Stephen Hemminger

On Mon, 30 Oct 2006 15:27:14 +0300
Dmitry Mishin <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> Could somebody explain, why bridge uses minimal MAC of the attached devices?
> It makes this address instable, variable during bridge life-cycle, which is 
> not good for DHCP. For example, I want to attach multiple virtual devices to 
> one physical. Then, I need to make sure that after each virtual device 
> addition, bridge addr is not changed and still addr of the physical device.  
> Why not to use MAC of the first attached device?
> 

The bridge physical address is the minimum of all the attached devices.
This is done because the STP standard requires it.  You can reset it
to be the same as any of the attached devices. This will not cause a problem
unless using STP.
-
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

Lost packets after switching Wi-Fi AP

2006-10-30 Thread Benjamin Thery


Hello,

I work on an extension of the mobility protocol for IPv6 
(FMIPv6-RFC4068) and I've noticed the following problem:


When I switch my Mobile Node between 2 Wi-Fi Access Points, there is a 
period of time where all the packets I send are lost, although I got 
the netlink event SIOCGIWAP 'up' for the new AP. The device is 
supposed to be ready, but the packets are lost.


By 'lost', I mean: silently discarded by the kernel, no error returned 
to the user-space application sending the packet, packets never appear 
on the network monitored with wireshark.


Here is the setup:
--

1. The daemon decides to switch from one AP to the other for some 
reason (better link quality, ...) and set the new ESSID, etc.


2. The daemon waits for the SIOCGIWAP 'up' netlink event.

3. SIOCGIWAP received: the daemon sends a unique Mobility Header 
packet using a raw socket to its new router to signal it has 
successfully moved. sendmsg() returned 0, no error, but the packet 
never shows up.


- The interface has an IPv6 address configured for the new network 
(previously created).

- There is a route between the node and the router.
- I set the socket option IPV6_RECVERR to get all the errors, but none 
shows up.
- The "black hole" period lasts for about 500ms after the SIOCGIWAP 
event. Every packets sent during this period are lost.
- I tried to get the interface status before sending the packet 
(ioctl(SIOCSIFFLAGS)) but I got a perfect IFF_UP|IFF_RUNNING.


What I've found in the kernel:
--

- The packet is discarded in the packet scheduler in 
net/sched/sch_generic.c::noop_enqueue() which returns NET_XMIT_CN.


- The error doesn't go up to the application because 
net/ipv6/ip6_output.c::ip6_push_pending_frames() filters this type of 
error (using net_xmit_errno(err)).


- noop_enqueue() is used to enqueue the packet because the device has 
been deactivated by link_watch_run_queue() calling dev_deactivate(). 
The device is re-activated about 500ms later.


- According to net/sched/sch_api.c, NET_XMIT_CN means "probably this 
packet enqueued, but another one dropped". But it seems to me that 
this packet IS actually dropped in noop_enqueue() (kfree_skb()). 
Shouldn't the routine return NET_XMIT_DROP instead? Then the 
application should be able to get the error code when the device is 
deactivated and retry later?



My questions:
-

- Am I doing something obviously wrong? Is there another event I 
should expect before sending my packet? An event that signals more 
reliably that the link is up and running and associated with the new AP?


- Shouldn't we change the return code in noop_enqueue()?


Thanks a lot for your help,
Benjamin

--
B e n j a m i n   T h e r y  - BULL/DT/Open Software R&D

   http://www.bull.com
-
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

[hch: [PATCH 1/3]: leak tracking for kmalloc node]

I should have noticed by now that netdev isn't at oss.sgi.com anymore..

- Forwarded message from Christoph Hellwig  -

Date: Mon, 30 Oct 2006 15:14:54 +0100
From: Christoph Hellwig 
Subject: [PATCH 1/3]: leak tracking for kmalloc node
To: [EMAIL PROTECTED], [EMAIL PROTECTED]

If we want to use the node-aware kmalloc in __alloc_skb we need
the tracker is responsible for leak tracking magic for it.  This
patch implements it.  The code is far too ugly for my taste, but it's
doing exactly what the regular kmalloc is doing and thus follows it's
style.


Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>

Index: linux-2.6/include/linux/slab.h
===
--- linux-2.6.orig/include/linux/slab.h 2006-10-23 17:20:14.0 +0200
+++ linux-2.6/include/linux/slab.h  2006-10-30 13:13:52.0 +0100
@@ -236,7 +236,25 @@
}
return __kmalloc_node(size, flags, node);
 }
+
+/*
+ * kmalloc_node_track_caller is a special version of kmalloc_node that
+ * records the calling function of the routine calling it for slab leak
+ * tracking instead of just the calling function (confusing, eh?).
+ * It's useful when the call to kmalloc_node comes from a widely-used
+ * standard allocator where we care about the real place the memory
+ * allocation request comes from.
+ */
+#ifndef CONFIG_DEBUG_SLAB
+#define kmalloc_node_track_caller(size, flags, node) \
+   __kmalloc_node(size, flags, node)
 #else
+extern void *__kmalloc_node_track_caller(size_t, gfp_t, int, void *);
+#define kmalloc_node_track_caller(size, flags, node) \
+   __kmalloc_node_track_caller(size, flags, node, \
+   __builtin_return_address(0))
+#endif
+#else /* CONFIG_NUMA */
 static inline void *kmem_cache_alloc_node(kmem_cache_t *cachep, gfp_t flags, 
int node)
 {
return kmem_cache_alloc(cachep, flags);
@@ -245,6 +263,9 @@
 {
return kmalloc(size, flags);
 }
+
+#define kmalloc_node_track_caller(size, flags, node) \
+   kmalloc_track_caller(size, flags)
 #endif
 
 extern int FASTCALL(kmem_cache_reap(int));
@@ -283,6 +304,8 @@
 #define kzalloc(s, f) __kzalloc(s, f)
 #define kmalloc_track_caller kmalloc
 
+#define kmalloc_node_track_caller kmalloc_node
+
 #endif /* CONFIG_SLOB */
 
 /* System wide caches */
Index: linux-2.6/mm/slab.c
===
--- linux-2.6.orig/mm/slab.c2006-10-23 17:21:47.0 +0200
+++ linux-2.6/mm/slab.c 2006-10-30 13:14:20.0 +0100
@@ -996,7 +996,7 @@
return NULL;
 }
 
-static inline void *__cache_alloc_node(struct kmem_cache *cachep,
+static inline void *cache_alloc_node(struct kmem_cache *cachep,
 gfp_t flags, int nodeid)
 {
return NULL;
@@ -1004,7 +1004,7 @@
 
 #else  /* CONFIG_NUMA */
 
-static void *__cache_alloc_node(struct kmem_cache *, gfp_t, int);
+static void *cache_alloc_node(struct kmem_cache *, gfp_t, int);
 static void *alternate_node_alloc(struct kmem_cache *, gfp_t);
 
 static struct array_cache **alloc_alien_cache(int node, int limit)
@@ -3105,10 +3105,10 @@
objp = cache_alloc(cachep, flags);
/*
 * We may just have run out of memory on the local node.
-* __cache_alloc_node() knows how to locate memory on other nodes
+* cache_alloc_node() knows how to locate memory on other nodes
 */
if (NUMA_BUILD && !objp)
-   objp = __cache_alloc_node(cachep, flags, numa_node_id());
+   objp = cache_alloc_node(cachep, flags, numa_node_id());
local_irq_restore(save_flags);
objp = cache_alloc_debugcheck_after(cachep, flags, objp,
caller);
@@ -3135,7 +3135,7 @@
else if (current->mempolicy)
nid_alloc = slab_node(current->mempolicy);
if (nid_alloc != nid_here)
-   return __cache_alloc_node(cachep, flags, nid_alloc);
+   return cache_alloc_node(cachep, flags, nid_alloc);
return NULL;
 }
 
@@ -3158,7 +3158,7 @@
if (zone_idx(*z) <= ZONE_NORMAL &&
cpuset_zone_allowed(*z, flags) &&
cache->nodelists[nid])
-   obj = __cache_alloc_node(cache,
+   obj = cache_alloc_node(cache,
flags | __GFP_THISNODE, nid);
}
return obj;
@@ -3167,7 +3167,7 @@
 /*
  * A interface to enable slab creation on nodeid
  */
-static void *__cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
+static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
int nodeid)
 {
struct list_head *entry;
@@ -3440,7 +3440,9 @@
  * New and improved: it will now make sure that the object gets
  * put on the correct node list so that there is no false sharing.
  */
-void *kmem_cache_alloc_node(str

[PATCH 2/3] add dev_to_node()

Davem suggested to get the node-affinity information directly from
struct device instead of having the caller extreact it from the
pci_dev.  This patch adds dev_to_node() to the topology API for that.
The implementation is rather ugly as we need to compare the bus
operations which we can't do inline in a header without pulling all
kinds of mess in.

Thus provide an out of line dev_to_node for ppc and let everyone else
use the dummy variant in asm-generic.h for now.


Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>

Index: linux-2.6/include/asm-generic/topology.h
===
--- linux-2.6.orig/include/asm-generic/topology.h   2006-10-10 
14:53:52.0 +0200
+++ linux-2.6/include/asm-generic/topology.h2006-10-30 13:42:22.0 
+0100
@@ -45,11 +45,14 @@
 #define pcibus_to_node(node)   (-1)
 #endif
 
+#ifndef dev_to_node
+#define dev_to_node(dev)   (-1)
+#endif
+
 #ifndef pcibus_to_cpumask
 #define pcibus_to_cpumask(bus) (pcibus_to_node(bus) == -1 ? \
CPU_MASK_ALL : \
node_to_cpumask(pcibus_to_node(bus)) \
)
 #endif
-
 #endif /* _ASM_GENERIC_TOPOLOGY_H */
Index: linux-2.6/include/asm-powerpc/topology.h
===
--- linux-2.6.orig/include/asm-powerpc/topology.h   2006-10-10 
14:53:52.0 +0200
+++ linux-2.6/include/asm-powerpc/topology.h2006-10-30 14:03:44.0 
+0100
@@ -5,6 +5,7 @@
 
 struct sys_device;
 struct device_node;
+struct device;
 
 #ifdef CONFIG_NUMA
 
@@ -33,6 +34,7 @@
 
 struct pci_bus;
 extern int pcibus_to_node(struct pci_bus *bus);
+int dev_to_node(struct device *dev);
 
 #define pcibus_to_cpumask(bus) (pcibus_to_node(bus) == -1 ? \
CPU_MASK_ALL : \
Index: linux-2.6/arch/powerpc/kernel/pci_64.c
===
--- linux-2.6.orig/arch/powerpc/kernel/pci_64.c 2006-10-23 17:21:43.0 
+0200
+++ linux-2.6/arch/powerpc/kernel/pci_64.c  2006-10-30 14:02:40.0 
+0100
@@ -1424,4 +1424,12 @@
return phb->node;
 }
 EXPORT_SYMBOL(pcibus_to_node);
+
+int dev_to_node(struct device *dev)
+{
+   if (dev->bus == &pci_bus_type)
+   return pcibus_to_node(to_pci_dev(dev)->bus);
+   return -1;
+}
+EXPORT_SYMBOL(dev_to_node);
 #endif
-
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] node-aware netdev_alloc_skb

This patch finnally switches netdev_alloc_skb to be node-locale.
It uses dev_to_node and kmalloc_node_track_caller from the previous two
patches.


Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>

Index: linux-2.6/include/linux/skbuff.h
===
--- linux-2.6.orig/include/linux/skbuff.h   2006-10-23 17:20:14.0 
+0200
+++ linux-2.6/include/linux/skbuff.h2006-10-30 13:23:38.0 +0100
@@ -331,17 +331,17 @@
 extern void kfree_skb(struct sk_buff *skb);
 extern void   __kfree_skb(struct sk_buff *skb);
 extern struct sk_buff *__alloc_skb(unsigned int size,
-  gfp_t priority, int fclone);
+  gfp_t priority, int fclone, int node);
 static inline struct sk_buff *alloc_skb(unsigned int size,
gfp_t priority)
 {
-   return __alloc_skb(size, priority, 0);
+   return __alloc_skb(size, priority, 0, -1);
 }
 
 static inline struct sk_buff *alloc_skb_fclone(unsigned int size,
   gfp_t priority)
 {
-   return __alloc_skb(size, priority, 1);
+   return __alloc_skb(size, priority, 1, -1);
 }
 
 extern struct sk_buff *alloc_skb_from_cache(kmem_cache_t *cp,
Index: linux-2.6/net/core/skbuff.c
===
--- linux-2.6.orig/net/core/skbuff.c2006-10-23 17:20:14.0 +0200
+++ linux-2.6/net/core/skbuff.c 2006-10-30 13:39:15.0 +0100
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -131,6 +132,7 @@
  * @gfp_mask: allocation mask
  * @fclone: allocate from fclone cache instead of head cache
  * and allocate a cloned (child) skb
+ * @node: numa node to allocate memory on
  *
  * Allocate a new &sk_buff. The returned buffer has no headroom and a
  * tail room of size bytes. The object has a reference count of one.
@@ -140,7 +142,7 @@
  * %GFP_ATOMIC.
  */
 struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
-   int fclone)
+   int fclone, int node)
 {
kmem_cache_t *cache;
struct skb_shared_info *shinfo;
@@ -150,14 +152,14 @@
cache = fclone ? skbuff_fclone_cache : skbuff_head_cache;
 
/* Get the HEAD */
-   skb = kmem_cache_alloc(cache, gfp_mask & ~__GFP_DMA);
+   skb = kmem_cache_alloc_node(cache, gfp_mask & ~__GFP_DMA, node);
if (!skb)
goto out;
 
/* Get the DATA. Size must match skb_add_mtu(). */
size = SKB_DATA_ALIGN(size);
-   data = kmalloc_track_caller(size + sizeof(struct skb_shared_info),
-   gfp_mask);
+   data = kmalloc_node_track_caller(size + sizeof(struct skb_shared_info),
+   gfp_mask, node);
if (!data)
goto nodata;
 
@@ -266,9 +268,10 @@
 struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
unsigned int length, gfp_t gfp_mask)
 {
+   int node = dev->class_dev.dev ? dev_to_node(dev->class_dev.dev) : -1;
struct sk_buff *skb;
 
-   skb = alloc_skb(length + NET_SKB_PAD, gfp_mask);
+   skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask, 0, node);
if (likely(skb)) {
skb_reserve(skb, NET_SKB_PAD);
skb->dev = dev;
-
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] spidernet: user netdev_alloc_skb