* Re: [patch 2.6.24-git] net/enc28j60: low power mode
From: Claudio Lanconelli @ 2008-02-07 11:21 UTC (permalink / raw)
To: netdev; +Cc: David Brownell
In-Reply-To: <200802062208.17435.david-b@pacbell.net>
Sorry,
let me repeat what I said in previous mail.
I propose you to add set_lowpower(true) in the enc28j60_probe() and in
the enc28j60_net_close() after enc28j60_hw_disable().
Probably we don't need to set_lowpower(false) in enc28j60_net_open() since
it performs a soft reset with enc28j60_hw_init() (not sure).
Furthermore, as you suggested, we also need to remove hw_init() from the
setlink()
because hw_init() is called when we bring link up.
--- enc28j60.c 20 Dec 2007 10:47:01 -0000 1.22
+++ enc28j60.c 7 Feb 2008 11:07:20 -0000
@@ -740,12 +740,6 @@
if (!priv->hw_enable) {
if (autoneg == AUTONEG_DISABLE && speed == SPEED_10) {
priv->full_duplex = (duplex == DUPLEX_FULL);
- if (!enc28j60_hw_init(priv)) {
- if (netif_msg_drv(priv))
- dev_err(&ndev->dev,
- "hw_reset() failed\n");
- ret = -EINVAL;
- }
} else {
if (netif_msg_link(priv))
dev_warn(&ndev->dev,
Can you update your low power patch with these modifications?
^ permalink raw reply
* [RFC] [IPV4][IPV6][TCP] remove skb->dev NULL assignation in tcp_v[4|6]_rcv functions
From: Daniel Lezcano @ 2008-02-07 11:17 UTC (permalink / raw)
To: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: rfc-why-dev-null.patch --]
[-- Type: text/x-patch, Size: 1148 bytes --]
Subject: [RFC] remove skb->dev NULL assignation
From: Daniel Lezcano <dlezcano@fr.ibm.com>
I was trying to figure out why in the tcp_v4_rcv/tcp_v6_rcv function,
the skb->dev field is set to NULL. There is certainly a good reason,
but I was not able to find it.
Is it possible to remove this ?
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
---
net/ipv4/tcp_ipv4.c | 2 --
net/ipv6/tcp_ipv6.c | 2 --
2 files changed, 4 deletions(-)
Index: net-2.6/net/ipv4/tcp_ipv4.c
===================================================================
--- net-2.6.orig/net/ipv4/tcp_ipv4.c
+++ net-2.6/net/ipv4/tcp_ipv4.c
@@ -1661,8 +1661,6 @@ process:
if (sk_filter(sk, skb))
goto discard_and_relse;
- skb->dev = NULL;
-
bh_lock_sock_nested(sk);
ret = 0;
if (!sock_owned_by_user(sk)) {
Index: net-2.6/net/ipv6/tcp_ipv6.c
===================================================================
--- net-2.6.orig/net/ipv6/tcp_ipv6.c
+++ net-2.6/net/ipv6/tcp_ipv6.c
@@ -1722,8 +1722,6 @@ process:
if (sk_filter(sk, skb))
goto discard_and_relse;
- skb->dev = NULL;
-
bh_lock_sock_nested(sk);
ret = 0;
if (!sock_owned_by_user(sk)) {
^ permalink raw reply
* Re: [RFC] [IPV4][IPV6][TCP] remove skb->dev NULL assignation in tcp_v[4|6]_rcv functions
From: David Miller @ 2008-02-07 11:45 UTC (permalink / raw)
To: dlezcano; +Cc: netdev
In-Reply-To: <47AAE8C7.9090109@fr.ibm.com>
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Date: Thu, 07 Feb 2008 12:17:27 +0100
> Subject: [RFC] remove skb->dev NULL assignation
>
> I was trying to figure out why in the tcp_v4_rcv/tcp_v6_rcv function,
> the skb->dev field is set to NULL. There is certainly a good reason,
> but I was not able to find it.
>
> Is it possible to remove this ?
>
> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
It is illegal to reference a device outside of the netif_receive_skb()
code path without taking a reference to it.
Since we are queueing it to a socket, we have to NULL out the skb->dev
since thee packets lifetime is being expanded outside of that allowed
window.
^ permalink raw reply
* Re: [bisected] Re: [bug] networking broke, ssh: connect to port 22: Protocol error
From: Ingo Molnar @ 2008-02-07 11:44 UTC (permalink / raw)
To: Casey Schaufler; +Cc: David Miller, linux-kernel, netdev, Linus Torvalds
In-Reply-To: <657224.72762.qm@web36615.mail.mud.yahoo.com>
* Casey Schaufler <casey@schaufler-ca.com> wrote:
> > So unlike some other security modules like SELINUX, enabling SMACK
> > breaks un-aware userspace and breaks TCP networking?
> >
> > I dont think that's expected behavior - and i'd definitely like to
> > enable SMACK in automated tests to check for regressions, etc.
>
> As Stephen mentions later, Smack uses CIPSO. sshd does not like any IP
> options because of traceroute, and must be built with that check
> disabled with the current Smack version. I have been looking at using
> unlabeled packets for the "ambient" label, it appears that doing so
> would make life simpler. I will get right on it.
ok - feel free to send me any patches to test.
Ingo
^ permalink raw reply
* Re: [PATCH] [resend] 3c509: convert to isa_driver and pnp_driver v3
From: Marc Zyngier @ 2008-02-07 11:51 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Jeff Garzik, netdev, Linux Kernel, Andrew Morton
In-Reply-To: <200802061909.37452.linux@rainbow-software.org>
>>>>> "Ondrej" == Ondrej Zary <linux@rainbow-software.org> writes:
Ondrej> Tested using 3 ISA cards in various combinations of PnP and non-PnP modes.
Ondrej> #ifdef CONFIG_EISA
Ondrej> ret = eisa_driver_register(&el3_eisa_driver);
Ondrej> + if (!ret)
Ondrej> + eisa_registeted = 1;
Ondrej> #endif
^^^^^^^^^^^^^^^
You probably should at least test-compile this driver with CONFIG_EISA
enabled...
Regards,
M.
--
And if you don't know where you're going, any road will take you there...
^ permalink raw reply
* [PATCH] rtnetlink.c: send a single notification on device state changes
From: Laszlo Attila Toth @ 2008-02-07 11:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Laszlo Attila Toth
In-Reply-To: <20080205.175337.266368079.davem@davemloft.net>
In do_setlink() a single notification is sent at the end of the function
if any modification occured. If the address has been changed, another
notification is sent.
Both of them is required because originally only the NETDEV_CHANGEADDR
notification was sent and although device state change implies address
change, some programs may expect the original notification. It remains
for compatibity.
If set_operstate() is called from do_setlink(), it doesn't send
a notification, only if it is called from rtnl_create_link() as earlier.
Signed-off-by: Laszlo Attila Toth <panther@balabit.hu>
---
net/core/rtnetlink.c | 36 ++++++++++++++++++++++++++----------
1 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 61ac8d0..ecb02af 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -504,7 +504,7 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
EXPORT_SYMBOL_GPL(rtnl_put_cacheinfo);
-static void set_operstate(struct net_device *dev, unsigned char transition)
+static int set_operstate(struct net_device *dev, unsigned char transition, bool send_notification)
{
unsigned char operstate = dev->operstate;
@@ -527,8 +527,12 @@ static void set_operstate(struct net_device *dev, unsigned char transition)
write_lock_bh(&dev_base_lock);
dev->operstate = operstate;
write_unlock_bh(&dev_base_lock);
- netdev_state_change(dev);
- }
+
+ if (send_notification)
+ netdev_state_change(dev);
+ return 1;
+ } else
+ return 0;
}
static void copy_rtnl_link_stats(struct rtnl_link_stats *a,
@@ -822,6 +826,7 @@ static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
if (tb[IFLA_BROADCAST]) {
nla_memcpy(dev->broadcast, tb[IFLA_BROADCAST], dev->addr_len);
send_addr_notify = 1;
+ modified = 1;
}
if (ifm->ifi_flags || ifm->ifi_change) {
@@ -834,16 +839,23 @@ static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
dev_change_flags(dev, flags);
}
- if (tb[IFLA_TXQLEN])
- dev->tx_queue_len = nla_get_u32(tb[IFLA_TXQLEN]);
+ if (tb[IFLA_TXQLEN]) {
+ if (dev->tx_queue_len != nla_get_u32(tb[IFLA_TXQLEN])) {
+ dev->tx_queue_len = nla_get_u32(tb[IFLA_TXQLEN]);
+ modified = 1;
+ }
+ }
if (tb[IFLA_OPERSTATE])
- set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]));
+ modified |= set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]), false);
if (tb[IFLA_LINKMODE]) {
- write_lock_bh(&dev_base_lock);
- dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
- write_unlock_bh(&dev_base_lock);
+ if (dev->link_mode != nla_get_u8(tb[IFLA_LINKMODE])) {
+ write_lock_bh(&dev_base_lock);
+ dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
+ write_lock_bh(&dev_base_lock);
+ modified = 1;
+ }
}
err = 0;
@@ -857,6 +869,10 @@ errout:
if (send_addr_notify)
call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
+
+ if (modified)
+ netdev_state_change(dev);
+
return err;
}
@@ -974,7 +990,7 @@ struct net_device *rtnl_create_link(struct net *net, char *ifname,
if (tb[IFLA_TXQLEN])
dev->tx_queue_len = nla_get_u32(tb[IFLA_TXQLEN]);
if (tb[IFLA_OPERSTATE])
- set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]));
+ set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]), true);
if (tb[IFLA_LINKMODE])
dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
--
1.5.2.5
^ permalink raw reply related
* [BUG][AX25] Fwd: SMP with AX.25
From: Jarek Poplawski @ 2008-02-07 12:07 UTC (permalink / raw)
To: Jann Traschewski; +Cc: Ralf Baechle, netdev
In-Reply-To: <20080206074529.GC4496@ff.dom.local>
On Wed, Feb 06, 2008 at 07:45:29AM +0000, Jarek Poplawski wrote:
...
> From: Jann Traschewski <jann@gmx.de>
> Subject: SMP with AX.25
(testing patch #2)
According to some OOPSes reported by Jann it seems ax25_kick
tries to clone NULL skbs sometimes. Probably there is needed
a sock lock, but until it's checked more this patch should
help to avoid this. There are probably also cases where ax25
->paclen == 0 can happen: let's check for this.
I attach this patch for testing purpose only.
Jarek P.
---
diff -Nurp 2.6.24-/net/ax25/ax25_out.c 2.6.24+/net/ax25/ax25_out.c
--- 2.6.24-/net/ax25/ax25_out.c 2008-01-24 22:58:37.000000000 +0000
+++ 2.6.24+/net/ax25/ax25_out.c 2008-02-07 11:48:39.000000000 +0000
@@ -117,6 +117,12 @@ void ax25_output(ax25_cb *ax25, int pacl
unsigned char *p;
int frontlen, len, fragno, ka9qfrag, first = 1;
+ if (paclen < 16) {
+ WARN_ON_ONCE(1);
+ kfree_skb(skb);
+ return;
+ }
+
if ((skb->len - 1) > paclen) {
if (*skb->data == AX25_P_TEXT) {
skb_pull(skb, 1); /* skip PID */
@@ -263,6 +269,8 @@ void ax25_kick(ax25_cb *ax25)
* Dequeue the frame and copy it.
*/
skb = skb_dequeue(&ax25->write_queue);
+ if (!skb)
+ return;
do {
if ((skbn = skb_clone(skb, GFP_ATOMIC)) == NULL) {
^ permalink raw reply
* Re: [PATCH 1/2] Remove unnecessary locks from rtnetlink
From: Laszlo Attila Toth @ 2008-02-07 12:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20080205.175337.266368079.davem@davemloft.net>
David Miller írta:
> From: Laszlo Attila Toth <panther@balabit.hu>
> Date: Fri, 1 Feb 2008 17:07:33 +0100
>
>> The do_setlink() function is protected by rtnl, additional locks are unnecessary.
>> and the set_operstate() function is called from protected parts. Locks removed
>> from both functions.
>>
>> The set_operstate() is also called from rtnl_create_link() and from no other places.
>> In rtnl_create_link() none of the changes is protected by set_lock_bh() except
>> inside set_operstate(), different locking scheme is not necessary
>> for the operstate.
>>
>> Signed-off-by: Laszlo Attila Toth <panther@balabit.hu>
>
> The protection using dev_base_lock() is needed.
>
> When analyzing cases like this you need to also look at other code
> paths outside of rtnetlink that access ->operstate and ->link_mode,
> you obviously didn't do this.
>
> For example, net/core/net-sysfs.c takes a read lock on dev_base_lock
> in order to fetch a stable copy of both netif_running() and
> dev->operstate at the same time.
>
> Similar write locking to protect dev->operstate is made by
> net/core/link_watch.c:rfc2863_policy(), for the same reason rtnetlink
> has to make this locking.
>
> You therefore cannot remove it.
Thanks for your answer, yes, unfortunatelly I checked only inside
rtnetlink.c
--
Attila
^ permalink raw reply
* Re: [RFC] [IPV4][IPV6][TCP] remove skb->dev NULL assignation in tcp_v[4|6]_rcv functions
From: Daniel Lezcano @ 2008-02-07 11:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20080207.034525.74982838.davem@davemloft.net>
David Miller wrote:
> From: Daniel Lezcano <dlezcano@fr.ibm.com>
> Date: Thu, 07 Feb 2008 12:17:27 +0100
>
>> Subject: [RFC] remove skb->dev NULL assignation
>>
>> I was trying to figure out why in the tcp_v4_rcv/tcp_v6_rcv function,
>> the skb->dev field is set to NULL. There is certainly a good reason,
>> but I was not able to find it.
>>
>> Is it possible to remove this ?
>>
>> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
>
> It is illegal to reference a device outside of the netif_receive_skb()
> code path without taking a reference to it.
>
> Since we are queueing it to a socket, we have to NULL out the skb->dev
> since thee packets lifetime is being expanded outside of that allowed
> window.
Got it. Thank you very much.
^ permalink raw reply
* Re: [patch 3/4] ctcm: infrastructure for replaced ctc driver
From: Rick Troth @ 2008-02-07 11:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ursula Braun, jgarzik, netdev, linux-s390, Peter Tiedemann
In-Reply-To: <20080207063534.GB27498@infradead.org>
On Thu, 7 Feb 2008, Christoph Hellwig wrote:
...
> > +/*
> > + * drivers/s390/net/ctcm_dbug.c
> > + *
> > + * Copyright IBM Corp. 2001, 2007
> > + * Authors: Peter Tiedemann (ptiedem@de.ibm.com)
> > + *
> > + */
>
> Please don't mention filenames in the top of file comments.
> On the other hand a little description of what this file
> does would be quite useful. (This comment applies to all
> files in this patch)
Better descriptions, yes. Of course.
But are you saying to NOT name the file in its comments?
I am surprised. If I am reading correctly, then I disagree.
Is the exclusion of the name of the source file from its comments
a stylistic decision the other kernel developers have agreed to?
Or is it tied to automation? Or have I (hopefully) misunderstood?
-- R; <><
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
^ permalink raw reply
* Re: [PATCH 01/24 for-2.6.25] DM9000: Fix endian-ness of data accesses. Patch from: Laurent Pinchart <laurentp@cse-semaphore.com>
From: Laurent Pinchart @ 2008-02-07 13:28 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Ben Dooks, netdev, akpm, daniel
In-Reply-To: <47A99E1A.3050808@garzik.org>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Wednesday 06 February 2008 12:46, Jeff Garzik wrote:
> two comments:
>
> 1) you should be using __le16 type
>
> 2) seems like you should do the same for RxStatus, rather than splitting it
The DM9000 datasheet (or rather the application notes) describes two distinct
fields, even though they both contain some kind of status information.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 01/24 for-2.6.25] DM9000: Fix endian-ness of data accesses. Patch from: Laurent Pinchart <laurentp@cse-semaphore.com>
From: Christoph Hellwig @ 2008-02-07 13:30 UTC (permalink / raw)
To: Ben Dooks; +Cc: netdev, jeff, akpm, daniel, laurentp
In-Reply-To: <20080205000814.539308209@fluff.org.uk>
On Tue, Feb 05, 2008 at 12:02:00AM +0000, Ben Dooks wrote:
> This patch splits the receive status in 8bit wide fields and convert the
> packet length from little endian to CPU byte order.
>
> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
> Signed-off-by: Ben Dooks <ben-linux@fluff.org>
>
> Index: linux-2.6.24-git5-dm9k/drivers/net/dm9000.c
> ===================================================================
> --- linux-2.6.24-git5-dm9k.orig/drivers/net/dm9000.c
> +++ linux-2.6.24-git5-dm9k/drivers/net/dm9000.c
> @@ -867,7 +867,8 @@ dm9000_timer(unsigned long data)
> }
>
> struct dm9000_rxhdr {
> - u16 RxStatus;
> + u8 RxPktReady;
> + u8 RxStatus;
> u16 RxLen;
thgis should be __le16. Also please install sparse and do a
make C=2 CHECKFLAGS="-D__CHECK_ENDIAN__"
run over the driver to make sure all hw structures are properly
annotated and you do byteswaps consistantly.
^ permalink raw reply
* [patch 1/3] iucv: wrong irq-disabling locking at module load time
From: Ursula Braun @ 2008-02-07 14:28 UTC (permalink / raw)
To: davem, netdev, linux-s390
In-Reply-To: <20080207142842.852003000@linux.vnet.ibm.com>
[-- Attachment #1: 707-iucv-irq.diff --]
[-- Type: text/plain, Size: 1096 bytes --]
From: Ursula Braun <braunu@de.ibm.com>
Linux may hang when running af_iucv socket programs concurrently
with a load of module netiucv. iucv_register() tries to take the
iucv_table_lock with spin_lock_irq. This conflicts with
iucv_connect() which has a need for an smp_call_function while
holding the iucv_table_lock.
Solution: use bh-disabling locking in iucv_register()
Signed-off-by: Ursula Braun <braunu@de.ibm.com>
---
net/iucv/iucv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -urpN linux-2.6/net/iucv/iucv.c linux-2.6-patched/net/iucv/iucv.c
--- linux-2.6/net/iucv/iucv.c 2008-02-07 13:24:12.000000000 +0100
+++ linux-2.6-patched/net/iucv/iucv.c 2008-02-07 13:24:34.000000000 +0100
@@ -693,9 +693,9 @@ int iucv_register(struct iucv_handler *h
iucv_setmask_up();
INIT_LIST_HEAD(&handler->paths);
- spin_lock_irq(&iucv_table_lock);
+ spin_lock_bh(&iucv_table_lock);
list_add_tail(&handler->list, &iucv_handler_list);
- spin_unlock_irq(&iucv_table_lock);
+ spin_unlock_bh(&iucv_table_lock);
rc = 0;
out_mutex:
mutex_unlock(&iucv_register_mutex);
--
^ permalink raw reply
* [patch 0/3] [IUCV] fixes for net-2.6.25
From: Ursula Braun @ 2008-02-07 14:28 UTC (permalink / raw)
To: davem, netdev, linux-s390
--
Dave,
the following 3 patches are intended for 2.6.25 and contain:
- locking changes in iucv.c
- locking changes in af_iucv.c
- extra checkings for successful allocations in af_iucv.c
- secure handling of send_skb_q list in af_iucv.c
^ permalink raw reply
* [patch 3/3] af_iucv: defensive programming of iucv_callback_txdone
From: Ursula Braun @ 2008-02-07 14:28 UTC (permalink / raw)
To: davem, netdev, linux-s390
In-Reply-To: <20080207142842.852003000@linux.vnet.ibm.com>
[-- Attachment #1: 714-afiucv-txdone.diff --]
[-- Type: text/plain, Size: 1705 bytes --]
From: Ursula Braun <braunu@de.ibm.com>
The loop in iucv_callback_txdone presumes existence of an entry
with msg->tag in the send_skb_q list. In error cases this
assumption might be wrong and might cause an endless loop.
Loop is rewritten to guarantee loop end in case of missing
msg->tag entry in send_skb_q.
Signed-off-by: Ursula Braun <braunu@de.ibm.com>
---
net/iucv/af_iucv.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff -urpN linux-2.6/net/iucv/af_iucv.c linux-2.6-patched/net/iucv/af_iucv.c
--- linux-2.6/net/iucv/af_iucv.c 2008-02-07 13:24:39.000000000 +0100
+++ linux-2.6-patched/net/iucv/af_iucv.c 2008-02-07 13:24:39.000000000 +0100
@@ -1112,24 +1112,31 @@ static void iucv_callback_txdone(struct
struct iucv_message *msg)
{
struct sock *sk = path->private;
- struct sk_buff *this;
+ struct sk_buff *this = NULL;
struct sk_buff_head *list = &iucv_sk(sk)->send_skb_q;
struct sk_buff *list_skb = list->next;
unsigned long flags;
- if (list_skb) {
+ if (!skb_queue_empty(list)) {
spin_lock_irqsave(&list->lock, flags);
- do {
- this = list_skb;
+ while (list_skb != (struct sk_buff *)list) {
+ if (!memcmp(&msg->tag, list_skb->cb, 4)) {
+ this = list_skb;
+ break;
+ }
list_skb = list_skb->next;
- } while (memcmp(&msg->tag, this->cb, 4) && list_skb);
- __skb_unlink(this, list);
+ }
+ if (this)
+ __skb_unlink(this, list);
spin_unlock_irqrestore(&list->lock, flags);
- kfree_skb(this);
+ if (this)
+ kfree_skb(this);
}
+ if (!this)
+ printk(KERN_ERR "AF_IUCV msg tag %u not found\n", msg->tag);
if (sk->sk_state == IUCV_CLOSING) {
if (skb_queue_empty(&iucv_sk(sk)->send_skb_q)) {
--
^ permalink raw reply
* [patch 2/3] af_iucv: broken send_skb_q results in endless loop
From: Ursula Braun @ 2008-02-07 14:28 UTC (permalink / raw)
To: davem, netdev, linux-s390
In-Reply-To: <20080207142842.852003000@linux.vnet.ibm.com>
[-- Attachment #1: 713-afiucv.diff --]
[-- Type: text/plain, Size: 1472 bytes --]
From: Ursula Braun <braunu@de.ibm.com>
A race has been detected in iucv_callback_txdone().
skb_unlink has to be done inside the locked area.
In addition checkings for successful allocations are inserted.
Signed-off-by: Ursula Braun <braunu@de.ibm.com>
---
net/iucv/af_iucv.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff -urpN linux-2.6/net/iucv/af_iucv.c linux-2.6-patched/net/iucv/af_iucv.c
--- linux-2.6/net/iucv/af_iucv.c 2008-02-07 13:24:12.000000000 +0100
+++ linux-2.6-patched/net/iucv/af_iucv.c 2008-02-07 13:24:38.000000000 +0100
@@ -482,6 +482,10 @@ static int iucv_sock_connect(struct sock
/* Create path. */
iucv->path = iucv_path_alloc(IUCV_QUEUELEN_DEFAULT,
IPRMDATA, GFP_KERNEL);
+ if (!iucv->path) {
+ err = -ENOMEM;
+ goto done;
+ }
err = iucv_path_connect(iucv->path, &af_iucv_handler,
sa->siucv_user_id, NULL, user_data, sk);
if (err) {
@@ -1094,6 +1098,8 @@ static void iucv_callback_rx(struct iucv
save_message:
save_msg = kzalloc(sizeof(struct sock_msg_q), GFP_ATOMIC | GFP_DMA);
+ if (!save_msg)
+ return;
save_msg->path = path;
save_msg->msg = *msg;
@@ -1118,10 +1124,10 @@ static void iucv_callback_txdone(struct
this = list_skb;
list_skb = list_skb->next;
} while (memcmp(&msg->tag, this->cb, 4) && list_skb);
+ __skb_unlink(this, list);
spin_unlock_irqrestore(&list->lock, flags);
- skb_unlink(this, &iucv_sk(sk)->send_skb_q);
kfree_skb(this);
}
--
^ permalink raw reply
* Re: [PATCH 01/24 for-2.6.25] DM9000: Fix endian-ness of data accesses. Patch from: Laurent Pinchart <laurentp@cse-semaphore.com>
From: Jeff Garzik @ 2008-02-07 14:54 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Ben Dooks, netdev, akpm, daniel
In-Reply-To: <200802071428.38849.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> On Wednesday 06 February 2008 12:46, Jeff Garzik wrote:
>> two comments:
>>
>> 1) you should be using __le16 type
>>
>> 2) seems like you should do the same for RxStatus, rather than splitting it
>
> The DM9000 datasheet (or rather the application notes) describes two distinct
> fields, even though they both contain some kind of status information.
Sure, there are plenty of distinct fields, just like with every chipset.
That doesn't mean byte instructions are the best choice.
Jeff
^ permalink raw reply
* Problem receiving multicast/promiscuous-mode with kernel.2.6.24
From: Reither Robert @ 2008-02-07 15:39 UTC (permalink / raw)
To: netdev
Visit AVD on prolight+sound in Frankfurt from 12.-15. March 2008 - Hall 8.0, Stand G16
________________________________________________________________________
Hi,
i'm working on a realtime-audio application, which should be capeable to receive RTP packets via multicast addresses.
App did work fine till i switched from 2.6.22 to kernel 2.6.24 (because of hwmon support for VIA EPIA LT15000AG)
With kernel 2.6.22 i had no problems, i'm using almost identical .config
Also tried kernel 2.6.24-rc5, same problem.
Tried it on two different boards (VIA EPIA LT, VIA EPIA 5000, diff. NIC's, cpu's mem, etc ..)
I'm using the same setsockopt with IP_ADD_MEMBERSHIP as before for all interfaces.
But now my app does not receive multicast packets !
Strange thing is, as long as tcpdump is running, the app (and tcpdump) get the multicast packets, but if i stopp tcpdump, my application at the same moment gets no more multicast packets.
I can see with netstat -g the joined MC-address (if app is active)
multicast route is set up properly.
Closer look:
-------------
Right after reboot, receiving of mc-packets worked for just one time.
After one ADD_MEMBERSHIP/DROP_MEMBERSHIP cycle it won't work any longer.
If i deny tcpdump setting promiscous-mode (-p) i get no packets.
Looks like somehow the NIC won't be (re)set to promiscous mode.
My user code:
int join_multicast_group (int fd, const char *mc_address)
{
struct ip_mreqn imr;
log_message(DVA_LOG_INFO,"In join_mc_group: %s\n",mc_address);
if (inet_aton (mc_address, &imr.imr_multiaddr) == 0) {
log_message (DVA_LOG_ERROR, "join_mc:Bad IP address format: %s\n", mc_address);
return -1;
}
imr.imr_address.s_addr = INADDR_ANY;
imr.imr_ifindex = 0;
// Check if already member
if (setsockopt (fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &imr, sizeof (imr)) < 0)
{
if (errno == EADDRINUSE) // Address already joined for IP_ADD_MEMBERSHIP
log_message(DVA_LOG_INFO,"Already joined IP_ADD_MEMBERSHIP for %s.\n", mc_address);
else
{
log_perror (DVA_LOG_ERROR, "getsockopt ip_add_membership");
return -1;
}
}
return 0;
}
and quite the same with DROP_MEMBERSHIP before i close the socket.
Robert Reither
Research & Development
AV Digital Audio- Videotechnik GmbH
Pottendorfer Strasse 25-27/4/1/1
A-1120 Wien/Austria
Commercial Register No.: FN 201615v
Commercial Court: Handelsgericht Wien
VAT-No.: ATU 50461904
Tel.: +43/1/3680368 43
email: robert.reither@av-digital.at
Visit: <http://www.av-digital.at>
Robert Reither
Research & Development
AV Digital Audio- Videotechnik GmbH
Pottendorfer Strasse 25-27/4/1/1
A-1120 Wien/Austria
Commercial Register No.: FN 201615v
Commercial Court: Handelsgericht Wien
VAT-No.: ATU 50461904
Tel.: +43/1/3680368 43
email: robert.reither@av-digital.at
Visit: <http://www.av-digital.at>
^ permalink raw reply
* Re: oops with ipcomp
From: Herbert Xu @ 2008-02-07 15:44 UTC (permalink / raw)
To: Beschorner Daniel; +Cc: netdev
In-Reply-To: <3C59DB883F7B0B4D8096010D45ACCD134F20C0@exch.facton.local>
On Wed, Feb 06, 2008 at 09:55:03PM +0100, Beschorner Daniel wrote:
>
> A is the oopsing 2.6.24, B is 2.6.23.
> I didn't change anything in the scenario recently, till 2.6.23 all
> worked fine.
OK, so are you now able to reproduce this crash without waiting
for hours? That would be really helpful in tracking it down.
Could you show me the exact policies/SAs of the tunnel involved
in the crash?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] [IPV6] Minor clenup: remove two unused definitions in net/ip6_route.h
From: Rami Rosen @ 2008-02-07 15:58 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 193 bytes --]
Hi,
Remove IP6_RT_PRIO_FW and IP6_RT_FLOW_MASK definitions in
include/net/ip6_route.h, as they are not used in the kernel.
Regards,
Rami Rosen
Signed-off-by: Rami Rosen <ramirose@gmail.com>
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 418 bytes --]
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index faac0ee..f99e4f0 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -1,11 +1,9 @@
#ifndef _NET_IP6_ROUTE_H
#define _NET_IP6_ROUTE_H
-#define IP6_RT_PRIO_FW 16
#define IP6_RT_PRIO_USER 1024
#define IP6_RT_PRIO_ADDRCONF 256
#define IP6_RT_PRIO_KERN 512
-#define IP6_RT_FLOW_MASK 0x00ff
struct route_info {
__u8 type;
^ permalink raw reply related
* Re: Problem receiving multicast/promiscuous-mode with kernel.2.6.24
From: David Stevens @ 2008-02-07 16:09 UTC (permalink / raw)
To: Reither Robert; +Cc: netdev
In-Reply-To: <BA41E8A07B73A041948C2E3A4EF6239D062F0B@av-digital-exch.avdigital.at>
You need to join the multicast group on the interface you want
to receive it. If you're setting both imr_address and imr_index
to 0, you haven't specified an interface.
Instead of setting imr_ifindex to 0, try setting it like this:
imr.imr_ifindex = if_nametoindex("eth0");
(or whatever interface you need).
You can verify that you've joined the group on the correct
interface with "netstat -g", also. Make sure that the interface
field is correct for the group you want.
And because I can't resist mentioning it, "inet_aton" is deprecated--
suggest inet_pton() with appropriate arguments and return value
checking instead.
There was a bug fix where the sense of promiscuous mode was
backwards for multicasting, which is probably why it was accidently
(and incorrectly) working in earlier kernels.
If that doesn't do it for you, let me know; better if you can post the
full code (or even better, the smallest subset that demonstrates the
problem).
+-DLS
^ permalink raw reply
* [PATCH] New device for DM9601 usb net driver
From: Robert Brockway @ 2008-02-07 16:00 UTC (permalink / raw)
To: jacmet; +Cc: netdev
[-- Attachment #1: Type: TEXT/PLAIN, Size: 330 bytes --]
Hi Peter. I've verified that the Hirose USB-100 (0x0a47, 0x9601) is a
clone of the DAVICOM DM9601. I patched dm9601.c to identify this device
and now have these in production. Unified diff against 2.6.24 attached.
Cheers,
Rob
--
"With sufficient thrust, pigs fly just fine..."
-- RFC 1925 "The Twelve Networking Truths"
[-- Attachment #2: Type: TEXT/X-DIFF, Size: 452 bytes --]
--- drivers/net/usb/dm9601.c.old 2008-01-27 00:51:50.000000000 -0500
+++ drivers/net/usb/dm9601.c 2008-02-07 10:27:40.000000000 -0500
@@ -590,6 +590,10 @@ static const struct usb_device_id produc
USB_DEVICE(0x0a46, 0x8515), /* ADMtek ADM8515 USB NIC */
.driver_info = (unsigned long)&dm9601_info,
},
+ {
+ USB_DEVICE(0x0a47, 0x9601), /* Hirose USB-100 */
+ .driver_info = (unsigned long)&dm9601_info,
+ },
{}, // END
};
^ permalink raw reply
* [PATCH] [IPV6] Minor cleanup: remove unused definitions in net/ip6_fib.h
From: Rami Rosen @ 2008-02-07 16:23 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 225 bytes --]
Hi,
This patch removes some unused definitions and one method typedef
declaration (f_pnode)
in include/net/ip6_fib.h, as they are not used in the kernel.
Regards,
Rami Rosen
Signed-off-by: Rami Rosen <ramirose@gmail.com>
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 704 bytes --]
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index d8d85b1..953d604 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -150,19 +150,6 @@ struct rt6_statistics {
*
*/
-#define RTPRI_FIREWALL 8 /* Firewall control information */
-#define RTPRI_FLOW 16 /* Flow based forwarding rules */
-#define RTPRI_KERN_CTL 32 /* Kernel control routes */
-
-#define RTPRI_USER_MIN 256 /* Mimimum user priority */
-#define RTPRI_USER_MAX 1024 /* Maximum user priority */
-
-#define RTPRI_KERN_DFLT 4096 /* Kernel default routes */
-
-#define MAX_FLOW_BACKTRACE 32
-
-
-typedef void (*f_pnode)(struct fib6_node *fn, void *);
struct fib6_table {
struct hlist_node tb6_hlist;
^ permalink raw reply related
* Re: Bug? Kernels 2.6.2x drops TCP packets over wireless (independent of card used)
From: Eric Dumazet @ 2008-02-07 16:30 UTC (permalink / raw)
To: Marcin Koziej; +Cc: Oliver Pinter, linux-kernel, netdev
In-Reply-To: <776aaa6c.68622465.47ab2df0.78e4b@o2.pl>
Marcin Koziej a écrit :
>> hmm, i think, the site is broken (193.219.28.140), and not the card or
>> the driver is wrong. when it does, then other sites are auch
>> reproductable ..
>>
>> /* is use auch madwifi-0.9.3.3, but it think, it is not driver problem */
>>
>
> Unfortunately, this is not the case :( This happens to all TCP connections, inside and outside LAN,
> also with the telnet session with the router. I also tried to manipulate MTU, but without any positive effect.
> I also tried to change things like net.ipv4.tcp_congestion_control -- which i figured out might affect TCP traffic, but also didn't get any results.
> I'm afraid this can have something to do with IRQ, because the PCMCIA cards (my Atheros wireless card is such) are visible only with irqpoll kernel option.
>
> Of course, as I mentioned, everything works fine with kernel 2.6.19; with the same servers etc.
>
>
Very strange, as the tcpdump you gave shows that the remote peer only
sent "220-\r\n"
This was ACKed, and then nothing but timeout. We can conclude remote
peer is *very* slow or a firewall is blocking trafic after 6 bytes sent :)
Could you give a tcpdump for the same destination, on 2.6.19 this time ?
^ permalink raw reply
* [PATCH] (02/06/08 Linus git) Smack unlabeled outgoing ambient packets
From: Casey Schaufler @ 2008-02-07 17:07 UTC (permalink / raw)
To: akpm, torvalds, mingo; +Cc: davem, netdev, linux-kernel
From: Casey Schaufler <casey@schaufler-ca.com>
Smack uses CIPSO labeling, but allows for unlabeled packets
by specifying an "ambient" label that is applied to incoming
unlabeled packets. Because the other end of the connection
may dislike IP options, and ssh is one know application that
behaves thus, it is prudent to respond in kind. This patch
changes the network labeling behavior such that an outgoing
packet that would be given a CIPSO label that matches the
ambient label is left unlabeled.
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
---
security/smack/smack_lsm.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff -uprN -X linux-2.6.25-g0206-base//Documentation/dontdiff linux-2.6.25-g0206-base/security/smack/smack_lsm.c linux-2.6.25-g0206/security/smack/smack_lsm.c
--- linux-2.6.25-g0206-base/security/smack/smack_lsm.c 2008-02-06 16:01:43.000000000 -0800
+++ linux-2.6.25-g0206/security/smack/smack_lsm.c 2008-02-06 18:39:55.000000000 -0800
@@ -1276,6 +1276,12 @@ static void smack_to_secattr(char *smack
* Convert the outbound smack value (smk_out) to a
* secattr and attach it to the socket.
*
+ * If the label is the ambient label do not set the secattr.
+ * Thus, all ambient packets are unlabeled and all unlabeled
+ * packets are ambient. This permits unlabeled responces to
+ * unlabeled requests without knowing on a per-packet basis
+ * if the packet was labeled ambient or was unlabeled.
+ *
* Returns 0 on success or an error code
*/
static int smack_netlabel(struct sock *sk)
@@ -1284,6 +1290,9 @@ static int smack_netlabel(struct sock *s
struct netlbl_lsm_secattr secattr;
int rc = 0;
+ if (strncmp(ssp->smk_out, smack_net_ambient, SMK_MAXLEN) == 0)
+ return 0;
+
netlbl_secattr_init(&secattr);
smack_to_secattr(ssp->smk_out, &secattr);
if (secattr.flags != NETLBL_SECATTR_NONE)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox