* Re: [PATCH 1/5] net/phy/marvell: Expose IDs and flags in a .h and add dns323 LEDs setup flag
From: Benjamin Herrenschmidt @ 2010-05-22 22:53 UTC (permalink / raw)
To: Wolfram Sang; +Cc: netdev, linux-arm-kernel@lists.infradead.org, Nicolas Pitre
In-Reply-To: <20100522130624.GA28561@pengutronix.de>
On Sat, 2010-05-22 at 15:06 +0200, Wolfram Sang wrote:
> On Sat, May 22, 2010 at 08:54:43PM +1000, Benjamin Herrenschmidt wrote:
> > This moves the various known Marvell PHY IDs to include/linux/marvell_phy.h
> > along with dev_flags definitions for use by the driver.
>
> I think this one from the driver should go there, too:
>
> #define M1145_DEV_FLAGS_RESISTANCE 0x00000001
>
> (which makes me wonder how this flag was set as it was not exported before)
I missed that one indeed.
> and thus yours could be maybe like
>
> #define M1118_DEV_FLAGS_ALT_LED_INIT 0x00000001
>
> (or 1 << 0)
Right, it should be 2. I'd rather keep the "DNS323" name in there
since the LED setup is specific to that NAS and somebody else might
need a different one. If we end up in the long run with too many
of them, we'll find a better solution, but we aren't there yet.
> Otherwise looks good enough to me.
Ok, thanks. I'll respin the whole lot soon.
Cheers,
Ben.
^ permalink raw reply
* [patch] caif: cleanup: remove duplicate checks
From: Dan Carpenter @ 2010-05-22 20:45 UTC (permalink / raw)
To: netdev; +Cc: Sjur Braendeland, Stephen Rothwell, kernel-janitors,
David S. Miller
These checks merely duplicate the things we've asserted already. In the
case of the checks for null we've already dereferenced those variables
as well.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/caif/cfcnfg.c b/net/caif/cfcnfg.c
index df43f26..cc2f072 100644
--- a/net/caif/cfcnfg.c
+++ b/net/caif/cfcnfg.c
@@ -313,14 +313,10 @@ cfcnfg_linkup_rsp(struct cflayer *layer, u8 channel_id, enum cfctrl_srv serv,
caif_assert(phyinfo->phy_layer != NULL);
caif_assert(phyinfo->phy_layer->id == phyid);
- if (phyinfo != NULL &&
- phyinfo->phy_ref_count++ == 0 &&
- phyinfo->phy_layer != NULL &&
+ if (phyinfo->phy_ref_count++ == 0 &&
phyinfo->phy_layer->modemcmd != NULL) {
- caif_assert(phyinfo->phy_layer->id == phyid);
phyinfo->phy_layer->modemcmd(phyinfo->phy_layer,
_CAIF_MODEMCMD_PHYIF_USEFULL);
-
}
adapt_layer->id = channel_id;
^ permalink raw reply related
* [patch] caif: remove unneeded null check in caif_connect()
From: Dan Carpenter @ 2010-05-22 20:43 UTC (permalink / raw)
To: Sjur Braendeland
Cc: Eric Dumazet, David S. Miller, linux-kernel, netdev,
kernel-janitors
We already dereferenced uaddr towards the start of the function when we
checked that "uaddr->sa_family != AF_CAIF". Both the check here and the
earlier check were added in bece7b2398d0: "caif: Rewritten socket
implementation". Before that patch, we assumed that we recieved a valid
pointer for uaddr, and based on that, I have removed this check.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index c3a70c5..bd67bb3 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -890,8 +890,7 @@ static int caif_connect(struct socket *sock, struct sockaddr *uaddr,
sk_stream_kill_queues(&cf_sk->sk);
err = -EINVAL;
- if (addr_len != sizeof(struct sockaddr_caif) ||
- !uaddr)
+ if (addr_len != sizeof(struct sockaddr_caif))
goto out;
memcpy(&cf_sk->conn_req.sockaddr, uaddr,
^ permalink raw reply related
* [patch] pppoe: uninitialized variable in pppoe_flush_dev()
From: Dan Carpenter @ 2010-05-22 20:27 UTC (permalink / raw)
To: Michal Ostrowski
Cc: David S. Miller, Eric Dumazet, Jiri Pirko, Denys Fedoryschenko,
netdev, kernel-janitors
This assignment got deleted along with the checks by mistake. This
comes from: 8753d29fd "pppoe: remove unnecessary checks in
pppoe_flush_dev"
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index b1b93ff..805b64d 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -289,6 +289,7 @@ static void pppoe_flush_dev(struct net_device *dev)
struct pppoe_net *pn;
int i;
+ pn = pppoe_pernet(dev_net(dev));
write_lock_bh(&pn->hash_lock);
for (i = 0; i < PPPOE_HASH_SIZE; i++) {
struct pppox_sock *po = pn->hash_table[i];
^ permalink raw reply related
* bug report: xfrm: potential null deref in xfrm_bundle_lookup()
From: Dan Carpenter @ 2010-05-22 20:24 UTC (permalink / raw)
To: timo.teras; +Cc: netdev
This is a smatch thing. I couldn't tell if it was a real issue so I
thought I would send this mail to the experts. :)
net/xfrm/xfrm_policy.c +1679 xfrm_bundle_lookup(51)
error: we previously assumed 'xdst' could be null.
1672 new_xdst = xfrm_resolve_and_create_bundle(pols, num_pols, fl, family, dst_orig);
1673 if (IS_ERR(new_xdst)) {
1674 err = PTR_ERR(new_xdst);
1675 if (err != -EAGAIN)
1676 goto error;
1677 if (oldflo == NULL)
1678 goto make_dummy_bundle;
1679 dst_hold(&xdst->u.dst);
^^^^^^^^^^^
Can xdst be NULL here? It would have to be something like
oldflo gets passed in as null and __xfrm_policy_lookup() fails.
1680 return oldflo;
1681 }
regards,
dan carpenter
^ permalink raw reply
* [patch] sctp: dubious bitfields in sctp_transport
From: Dan Carpenter @ 2010-05-22 20:20 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Sridhar Samudrala, David S. Miller, Wei Yongjun, linux-sctp,
netdev, kernel-janitors
Sparse complains because these one-bit bitfields are signed.
include/net/sctp/structs.h:879:24: error: dubious one-bit signed bitfield
include/net/sctp/structs.h:889:31: error: dubious one-bit signed bitfield
include/net/sctp/structs.h:895:26: error: dubious one-bit signed bitfield
include/net/sctp/structs.h:898:31: error: dubious one-bit signed bitfield
include/net/sctp/structs.h:901:27: error: dubious one-bit signed bitfield
It doesn't cause a problem in the current code, but it would be better
to clean it up. This was introduced by c0058a35aacc7: "sctp: Save some
room in the sctp_transport by using bitfields".
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
It looks like this header is exported to user space. I don't know if
that makes a difference.
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 6173c61..4b86011 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -876,7 +876,7 @@ struct sctp_transport {
/* Reference counting. */
atomic_t refcnt;
- int dead:1,
+ __u32 dead:1,
/* RTO-Pending : A flag used to track if one of the DATA
* chunks sent to this address is currently being
* used to compute a RTT. If this flag is 0,
^ permalink raw reply related
* Re: VLANs, bonding redux: vlan state does not follow ethernet
From: George B. @ 2010-05-22 20:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <AANLkTimar_hs5zpvbB6iGUg3b9UqgUASqlhMtK81ccXZ@mail.gmail.com>
On Sat, May 22, 2010 at 10:47 AM, George B. <georgeb@gmail.com> wrote:
> This is with both physical links up. The arp monitor just causes the
> links to constantly fail back and forth each arp_monitor interval.
>
I can get it to work with miimon and use_carrier=1 with the vlan
interface (works to the raw ethernet without the use_carrier).
It would be nice, though, for arp_monitor to actually work as by
monitoring an IP on the core switch it would allow me to detect a
failed uplink from the access switch.
^ permalink raw reply
* [patch] e1000e: change logical negate to bitwise
From: Dan Carpenter @ 2010-05-22 19:45 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Jesse Brandeburg, Bruce Allan, Alex Duyck, PJ Waskiewicz,
John Ronciak, David S. Miller, e1000-devel, netdev,
kernel-janitors
The bitwise negate is intended here. With the logical negate the
condition is always false.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 24507f3..57a7e41 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -2554,7 +2554,7 @@ static void e1000_init_manageability_pt(struct e1000_adapter *adapter)
mdef = er32(MDEF(i));
/* Ignore filters with anything other than IPMI ports */
- if (mdef & !(E1000_MDEF_PORT_623 | E1000_MDEF_PORT_664))
+ if (mdef & ~(E1000_MDEF_PORT_623 | E1000_MDEF_PORT_664))
continue;
/* Enable this decision filter in MANC2H */
^ permalink raw reply related
* [patch] ipmr: off by one in __ipmr_fill_mroute()
From: Dan Carpenter @ 2010-05-22 17:54 UTC (permalink / raw)
To: netdev
Cc: Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet,
kernel-janitors@vger.kernel.org David S. Miller
This fixes a smatch warning:
net/ipv4/ipmr.c +1917 __ipmr_fill_mroute(12) error: buffer overflow
'(mrt)->vif_table' 32 <= 32
The ipv6 version had the same issue.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 4588910..856123f 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1911,7 +1911,7 @@ static int __ipmr_fill_mroute(struct mr_table *mrt, struct sk_buff *skb,
struct rtattr *mp_head;
/* If cache is unresolved, don't try to parse IIF and OIF */
- if (c->mfc_parent > MAXVIFS)
+ if (c->mfc_parent >= MAXVIFS)
return -ENOENT;
if (VIF_EXISTS(mrt, c->mfc_parent))
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index bd9e7d3..073071f 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -2017,7 +2017,7 @@ static int __ip6mr_fill_mroute(struct mr6_table *mrt, struct sk_buff *skb,
struct rtattr *mp_head;
/* If cache is unresolved, don't try to parse IIF and OIF */
- if (c->mf6c_parent > MAXMIFS)
+ if (c->mf6c_parent >= MAXMIFS)
return -ENOENT;
if (MIF_EXISTS(mrt, c->mf6c_parent))
^ permalink raw reply related
* RE: ixgbe: macvlan on PF/VF when SRIOV is enabled
From: Rose, Gregory V @ 2010-05-22 17:53 UTC (permalink / raw)
To: Shirley Ma, Kirsher, Jeffrey T
Cc: davem@davemloft.net, kvm@vger.kernel.org, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
In-Reply-To: <1274473846.8701.25.camel@localhost.localdomain>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of Shirley Ma
>Sent: Friday, May 21, 2010 1:31 PM
>To: Kirsher, Jeffrey T
>Cc: davem@davemloft.net; kvm@vger.kernel.org; netdev@vger.kernel.org;
>e1000-devel@lists.sourceforge.net
>Subject: ixgbe: macvlan on PF/VF when SRIOV is enabled
>
>Hello Jeff,
>
>macvlan doesn't work on PF when SRIOV is enabled. Creating macvlan has
>been successful, but ping (icmp request) goes to VF interface not
>PF/macvlan even arp entry is correct. I patched ixgbe driver, and
>macvlan/PF has worked with the patch. But I am not sure whether it is
>right since I don't have the HW spec. What I did for ixgbe driver was:
>
>1. PF's rar index is 0, VMDQ index is adatper->num_vfs;
>2. VF's rar is based on rar_used_count and mc_addr_in_rar_count, VMDQ
>index is ;
>3. PF's secondary addresses is PF's rar index + i, VMDQ index is
>adapter->num_vfs.
As of 2.6.34 the ixgbe driver does not support multiple queues for macvlan.
Support for multiple queues for macvlan will come in a subsequent release.
>
>
>Before I submit the patch, I want to understand the right index
>assignment for both rar index and VMDQ index, when SRIOV enabled:
>1. VMDQ index for PF is adapter->num_vfs, or 0? rar index is 0?
>2. PF's secondary address rar index is based on
>rar_used_count/mc_addr_in_rar_count?
>2. VF's VPDQ index is based on vf number?
>3. VF's rar index is vf + 1, or should be based on rar_used_count?
>
>I am also working on macvlan on VF. The question here is whether macvlan
>on VF should work or not? Looks like ixgbevf secondary addresses are not
>in receiver address filter, so macvlan on VF doesn't work.
The VF driver does not support macvlan. Future releases may but there
are no immediate plans to support it.
- Greg Rose
Intel Corp.
Lan Access Division
^ permalink raw reply
* Re: VLANs, bonding redux: vlan state does not follow ethernet
From: George B. @ 2010-05-22 17:47 UTC (permalink / raw)
To: netdev
In-Reply-To: <AANLkTim9nKSOdTW9YcrfNNJCmZoJ6t40mY_9f60GrWuG@mail.gmail.com>
On Fri, May 21, 2010 at 11:45 PM, George B. <georgeb@gmail.com> wrote:
> On Fri, May 21, 2010 at 11:24 PM, George B. <georgeb@gmail.com> wrote:
>> Using 2.6.34 I am trying to remove bottlenecks. Instead of bonding
>> two ethernet interfaces and applying vlans to the bond, I am applying
>> the vlans to the ethernet and bonding the vlans creating a separate
>> bond interface for each vlan.
>>
>> The trouble now is that the bond interface does not see when the
>> ethernet interface goes down. The vlan reports to the bonding driver
>> that it is up when the ethernet it is connected to is down. This
>> results in packet loss through the bond interface as the bond driver
>> attempts to use that vlan.
>>
>> eth1 shows having no link:
>>
>> root@sandbox:/proc/net# ethtool eth1
>> Settings for eth1:
>> Supported ports: [ TP ]
>> Supported link modes: 10baseT/Half 10baseT/Full
>> 100baseT/Half 100baseT/Full
>> 1000baseT/Full
>> Supports auto-negotiation: Yes
>> Advertised link modes: 10baseT/Half 10baseT/Full
>> 100baseT/Half 100baseT/Full
>> 1000baseT/Full
>> Advertised pause frame use: No
>> Advertised auto-negotiation: Yes
>> Link partner advertised link modes: Not reported
>> Link partner advertised pause frame use: No
>> Link partner advertised auto-negotiation: No
>> Speed: Unknown!
>> Duplex: Unknown! (255)
>> Port: Twisted Pair
>> PHYAD: 1
>> Transceiver: internal
>> Auto-negotiation: on
>> MDI-X: Unknown
>> Supports Wake-on: pumbag
>> Wake-on: g
>> Current message level: 0x00000001 (1)
>> Link detected: no
>>
>> bonding driver says eth1.99 reports MII status up:
>>
>> root@sandbox:/proc/net# cat bonding/bond0
>> Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
>>
>> Bonding Mode: load balancing (round-robin)
>> MII Status: up
>> MII Polling Interval (ms): 0
>> Up Delay (ms): 0
>> Down Delay (ms): 0
>>
>> Slave Interface: eth0.99
>> MII Status: up
>> Link Failure Count: 0
>> Permanent HW addr: 00:26:9e:1c:d3:3e
>>
>> Slave Interface: eth1.99
>> MII Status: up
>> Link Failure Count: 0
>> Permanent HW addr: 00:26:9e:1c:d3:3f
>>
>> is there some parameter I can give that tells the vlan driver to
>> follow the state of the interface it is attached to? Having a vlan
>> that reports being up all the time even when its underlying interface
>> is down is less than useful. It would seem intuitive that a vlan's
>> state would follow that of the interface it is attached to.
>>
>> root@sandbox:/proc/net# cat vlan/eth0.99
>> eth0.99 VID: 99 REORDER_HDR: 1 dev->priv_flags: 21
>> total frames received 32
>> total bytes received 4735
>> Broadcast/Multicast Rcvd 0
>>
>> total frames transmitted 50
>> total bytes transmitted 3852
>> total headroom inc 0
>> total encap on xmit 0
>> Device: eth0
>> INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
>> EGRESS priority mappings:
>> root@sandbox:/proc/net# cat vlan/eth1.99
>> eth1.99 VID: 99 REORDER_HDR: 1 dev->priv_flags: 21
>> total frames received 0
>> total bytes received 0
>> Broadcast/Multicast Rcvd 0
>>
>> total frames transmitted 0
>> total bytes transmitted 0
>> total headroom inc 0
>> total encap on xmit 0
>> Device: eth1
>> INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
>> EGRESS priority mappings:
>>
>> root@sandbox:/proc/net# ping 10.1.99.1
>> PING 10.1.99.1 (10.1.99.1) 56(84) bytes of data.
>> 64 bytes from 10.1.99.1: icmp_seq=2 ttl=255 time=0.299 ms
>> 64 bytes from 10.1.99.1: icmp_seq=4 ttl=255 time=0.311 ms
>> 64 bytes from 10.1.99.1: icmp_seq=6 ttl=255 time=0.325 ms
>> 64 bytes from 10.1.99.1: icmp_seq=8 ttl=255 time=0.291 ms
>> 64 bytes from 10.1.99.1: icmp_seq=10 ttl=255 time=0.308 ms
>>
>> George
>>
>
> But interestingly, mii-tool reports the correct result:
>
> root@sandbox:/usr/src/linux-source-2.6.34/Documentation/networking#
> mii-tool -v eth1.99
>
> eth1.99: no link
> product info: vendor 00:50:43, model 10 rev 0
> basic mode: autonegotiation enabled
> basic status: no link
> capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
>
I can't use arp monitor because when I do that it just flips back and
forth each second between slaves each monitor period:
May 22 10:45:28 sandbox kernel: [69276.450013] bonding: bond0: making
interface eth0.99 the new active one.
May 22 10:45:29 sandbox kernel: [69277.450010] bonding: bond0: link
status definitely up for interface eth1.99.
May 22 10:45:30 sandbox kernel: [69278.450009] bonding: bond0: link
status definitely down for interface eth0.99, disabl
ing it
May 22 10:45:30 sandbox kernel: [69278.450012] bonding: bond0: making
interface eth1.99 the new active one.
May 22 10:45:31 sandbox kernel: [69279.450009] bonding: bond0: link
status definitely up for interface eth0.99.
May 22 10:45:32 sandbox kernel: [69280.450009] bonding: bond0: link
status definitely down for interface eth1.99, disabl
ing it
May 22 10:45:32 sandbox kernel: [69280.450012] bonding: bond0: making
interface eth0.99 the new active one.
May 22 10:45:33 sandbox kernel: [69281.450012] bonding: bond0: link
status definitely up for interface eth1.99.
May 22 10:45:34 sandbox kernel: [69282.450009] bonding: bond0: link
status definitely down for interface eth0.99, disabl
ing it
May 22 10:45:34 sandbox kernel: [69282.450012] bonding: bond0: making
interface eth1.99 the new active one.
May 22 10:45:35 sandbox kernel: [69283.450012] bonding: bond0: link
status definitely up for interface eth0.99.
May 22 10:45:36 sandbox kernel: [69284.450009] bonding: bond0: link
status definitely down for interface eth1.99, disabl
ing it
May 22 10:45:36 sandbox kernel: [69284.450012] bonding: bond0: making
interface eth0.99 the new active one.
May 22 10:45:37 sandbox kernel: [69285.450012] bonding: bond0: link
status definitely up for interface eth1.99.
May 22 10:45:38 sandbox kernel: [69286.450008] bonding: bond0: link
status definitely down for interface eth0.99, disabl
ing it
May 22 10:45:38 sandbox kernel: [69286.450011] bonding: bond0: making
interface eth1.99 the new active one.
May 22 10:45:39 sandbox kernel: [69287.450010] bonding: bond0: link
status definitely up for interface eth0.99.
May 22 10:45:40 sandbox kernel: [69288.450008] bonding: bond0: link
status definitely down for interface eth1.99, disabl
ing it
This is with both physical links up. The arp monitor just causes the
links to constantly fail back and forth each arp_monitor interval.
^ permalink raw reply
* [PATCH 12/12] caif: remove duplicated #include
From: Huang Weiyi @ 2010-05-22 17:13 UTC (permalink / raw)
To: davem; +Cc: netdev, Huang Weiyi
Remove duplicated #include('s) in
net/caif/caif_socket.c
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
---
net/caif/caif_socket.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index c3a70c5..a9681c3 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -15,7 +15,6 @@
#include <linux/poll.h>
#include <linux/tcp.h>
#include <linux/uaccess.h>
-#include <linux/mutex.h>
#include <linux/debugfs.h>
#include <linux/caif/caif_socket.h>
#include <asm/atomic.h>
--
1.6.1.3
^ permalink raw reply related
* [PATCH 03/12] caif: remove unused #include <linux/version.h>
From: Huang Weiyi @ 2010-05-22 17:11 UTC (permalink / raw)
To: davem; +Cc: netdev, Huang Weiyi
Remove unused #include <linux/version.h>('s) in
net/caif/caif_dev.c
net/caif/chnl_net.c
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
---
net/caif/caif_dev.c | 1 -
net/caif/chnl_net.c | 1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
index e2b86f1..a5f1559 100644
--- a/net/caif/caif_dev.c
+++ b/net/caif/caif_dev.c
@@ -9,7 +9,6 @@
* and Sakari Ailus <sakari.ailus@nokia.com>
*/
-#include <linux/version.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/if_arp.h>
diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c
index 610966a..49c4a7b 100644
--- a/net/caif/chnl_net.c
+++ b/net/caif/chnl_net.c
@@ -5,7 +5,6 @@
* License terms: GNU General Public License (GPL) version 2
*/
-#include <linux/version.h>
#include <linux/fs.h>
#include <linux/init.h>
#include <linux/module.h>
--
1.6.1.3
^ permalink raw reply related
* [PATCH 01/12] caif: remove unused #include <linux/version.h>
From: Huang Weiyi @ 2010-05-22 17:11 UTC (permalink / raw)
To: davem; +Cc: netdev, Huang Weiyi
Remove unused #include <linux/version.h>('s) in
drivers/net/caif/caif_serial.c
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
---
drivers/net/caif/caif_serial.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
index 09257ca..b259650 100644
--- a/drivers/net/caif/caif_serial.c
+++ b/drivers/net/caif/caif_serial.c
@@ -5,7 +5,6 @@
*/
#include <linux/init.h>
-#include <linux/version.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/types.h>
--
1.6.1.3
^ permalink raw reply related
* null dereference in ethoc_probe()
From: Dan Carpenter @ 2010-05-22 15:55 UTC (permalink / raw)
To: thomas; +Cc: netdev
The patch 0baa080c75c: "ethoc: use system memory as buffer" introduced a
potential null dereference.
1060 free:
1061 if (priv->dma_alloc)
^^^^^^^^^^^^^^^
priv can be null here.
1062 dma_free_coherent(NULL, priv->dma_alloc, priv->membase,
1063 netdev->mem_start);
1064 free_netdev(netdev);
Also I think the error handling is not as complete as it should be. It
seems like we should call devm_iounmap() and release some of the other
resources as well.
regards,
dan carpenter
^ permalink raw reply
* [regression] fib6_del() bug from 2.6.34-rc1 still present in 2.6.34
From: Julien BLACHE @ 2010-05-22 15:55 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Hi,
[subscribed to lkml but not netdev, Cc me on replies]
I'm seeing a warning in fib6_del() that is very close to what was
reported by Emil S Tantilov back in march/april for 2.6.34-rc1:
<http://kerneltrap.org/mailarchive/linux-netdev/2010/4/9/6274401/thread>
It looks like there hasn't been a fix, other than what was mentioned in
this thread for net-next and Emil reported that it did not fix it for
him. So it looks like it's still there, alive and kicking.
This is the warning I'm getting:
------------[ cut here ]------------
WARNING: at net/ipv6/ip6_fib.c:1160 fib6_del+0x506/0x5b0()
Hardware name: MacBookPro2,2
Modules linked in: sco bnep rfcomm l2cap crc16 cpufreq_userspace cpufreq_powersave cpufreq_conservative nfsd nfs lockd auth_rpcgss sunrpc uinput btusb ath9k ath9k_common mac80211 ath9k_hw ath isight_firmware joydev cfg80211 i2c_i801 ohci1394 ieee1394 [last unloaded: scsi_wait_scan]
Pid: 4020, comm: ifconfig Not tainted 2.6.34 #1
Call Trace:
[<ffffffff810389d3>] ? warn_slowpath_common+0x73/0xb0
[<ffffffff8142f956>] ? fib6_del+0x506/0x5b0
[<ffffffff8102ceb3>] ? __wake_up+0x43/0x70
[<ffffffff813c68ef>] ? netlink_broadcast+0x21f/0x410
[<ffffffff8142c2ab>] ? __ip6_del_rt+0x4b/0x80
[<ffffffff8142c436>] ? ip6_del_rt+0x26/0x30
[<ffffffff81426dff>] ? __ipv6_ifa_notify+0x15f/0x200
[<ffffffff81428d99>] ? addrconf_ifdown+0x159/0x350
[<ffffffff8142915d>] ? addrconf_notify+0xed/0x920
[<ffffffff81043d33>] ? lock_timer_base+0x33/0x70
[<ffffffff810445ab>] ? mod_timer+0x11b/0x1a0
[<ffffffff81054826>] ? notifier_call_chain+0x46/0x70
[<ffffffff813b1ae5>] ? __dev_notify_flags+0x65/0x90
[<ffffffff813b1b4b>] ? dev_change_flags+0x3b/0x70
[<ffffffff813fd2a2>] ? devinet_ioctl+0x602/0x750
[<ffffffff813a12ea>] ? T.945+0x1a/0x50
[<ffffffff813a1589>] ? sock_ioctl+0x59/0x2a0
[<ffffffff810bee55>] ? vfs_ioctl+0x35/0xd0
[<ffffffff810bf018>] ? do_vfs_ioctl+0x88/0x570
[<ffffffff810bf549>] ? sys_ioctl+0x49/0x80
[<ffffffff810023eb>] ? system_call_fastpath+0x16/0x1b
---[ end trace b5a833c8e5539431 ]---
I can reliably reproduce it on both ath9k and sky2 with the
following sequence:
# ifconfig eth0 up
# ifconfig eth0 add 2001:7a8:5dd7:123::12/64
# ifconfig eth0 down
# ifconfig eth0 up
# ifconfig eth0 add 2001:7a8:5dd7:123::12/64 <=== fails
# ifconfig eth0 down <=== triggers the warning
Note that this sequence is equivalent to:
# ifup eth0
# ifdown eth0
# ifup eth0 (will fail because it cannot add the v6 address)
# ifconfig eth0 down
This regression breaks ifupdown as it always tries to add the v6 address
when configuring the interface. It's a behaviour change compared to
previous kernel versions.
It looks like triggering this warning a couple times (3-4) in a row ends
up locking up the machine, too.
I can test patches etc.
JB.
--
Julien BLACHE <http://www.jblache.org>
<jb@jblache.org> GPG KeyID 0xF5D65169
^ permalink raw reply
* Re: QoS weirdness : HTB accuracy
From: Julien Vehent @ 2010-05-22 14:29 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: Netdev, netfilter
In-Reply-To: <4BF32BB0.7010700@redfish-solutions.com>
On Tue, 18 May 2010 18:07:12 -0600, "Philip A. Prindeville"
<philipp_subx@redfish-solutions.com> wrote:
>
> Sorry for the late response: could this be an "aliasing" issue caused
> by sampling intervals (granularity)?
>
> -Philip
I was, in fact, an error in my ruleset. I had put the 'linklayer atm' at
both the branch and leaf levels, so the overhead was computed twice,
creating those holes in the bandwidth.
Julien
^ permalink raw reply
* Re: [PATCH 1/5] net/phy/marvell: Expose IDs and flags in a .h and add dns323 LEDs setup flag
From: Wolfram Sang @ 2010-05-22 13:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-arm-kernel@lists.infradead.org, netdev, Nicolas Pitre
In-Reply-To: <1274525683.1931.139.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]
On Sat, May 22, 2010 at 08:54:43PM +1000, Benjamin Herrenschmidt wrote:
> This moves the various known Marvell PHY IDs to include/linux/marvell_phy.h
> along with dev_flags definitions for use by the driver.
I think this one from the driver should go there, too:
#define M1145_DEV_FLAGS_RESISTANCE 0x00000001
(which makes me wonder how this flag was set as it was not exported before)
and thus yours could be maybe like
#define M1118_DEV_FLAGS_ALT_LED_INIT 0x00000001
(or 1 << 0)
?
Otherwise looks good enough to me.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* ASSITANCE NEEDED..
From: Dr Raymond Kuo Fung CHIEN. @ 2010-05-22 12:48 UTC (permalink / raw)
Dear Friend,
I am Dr Raymond Kuo Fung CHIEN Executive Director and Chief Financial Officer
of the operations of the Hang Seng Bank Ltd.
Befor the U.S and Iraqi war our client Mr.Fayez A Mohammed a business
merchant made a fixed deposit of USD30 Million for 2Yrs where i was the only
one that knew about his deposits.
Upon maturity during the war in 2003,Fayez,his wife and only daugther died in
a bomb blast that hits His Resident.
Investigations showed that he didnt declear any next of kin.As a foreigner,I
want you to stand as the next of kin to claim the fund because soon the fund
will be claimed by my government if no one comes for it.
I have an attorney that will prepare all the documents to back you up as the
next of kin to Mr.Fayez A.Mohammed.Plz let me know your willingness so that i
can provide you with more details of this transaction.
contact me on email: drrayfung@9.cn
1. Full name and Age
2. Occupation
3. Private/office phone number
4. Current residential address
Kind Regards,
Dr Raymond Kuo Fung CHIEN.
^ permalink raw reply
* Re: tc: RTM_GETQDISC causes kernel OOPS
From: jamal @ 2010-05-22 12:31 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, Ben Pfaff, netdev
In-Reply-To: <4BF7A929.2090007@trash.net>
On Sat, 2010-05-22 at 11:51 +0200, Patrick McHardy wrote:
>
> We already use TCQ_F_BUILTIN in tc_qdisc_dump_ignore(), so I
> think it would be more consistent than checking for a handle
> to use it here as well.
Agree - it is more semantically correct..
I wonder though if it is better to do the check in tc_get_qdisc()
and tc_modify_qdisc()?
cheers,
jamal
^ permalink raw reply
* Re: cls_cgroup: Store classid in struct sock
From: Neil Horman @ 2010-05-22 12:26 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, eric.dumazet, bmb, tgraf, nhorman, netdev
In-Reply-To: <20100522014957.GA8779@gondor.apana.org.au>
On Sat, May 22, 2010 at 11:49:57AM +1000, Herbert Xu wrote:
> On Fri, May 21, 2010 at 12:40:54PM -0400, Neil Horman wrote:
> >
> > There may also be an issue with the setting of the classid (possible use of the
> > wrong subsys id value when grabbing our cgroup_subsys_state), but I'm checking
> > on that now.
>
> Actually, I think it's because my patch mistook CONFIG_CGROUP
> for CONFIG_CGROUPS.
>
Thats definately part of it yes. But its not all of it, although I think the
rest doesn't have anything to do with your patch. I fixed that straight away,
but I was still alwasy getting classids of zero in the qemu processes. Looking
at the cgroup classifier, I'm wondering how this cgroup code ever worked in the
first place. When we register the cgroup subsystem, we don't register an attach
method, so we never get a chance to assign task_cls_sate(tsk)->classid to any
non-zero value. I've got a version of the patch that add that, but for some
reason, even though I set task_cls_state(tsk)->classid to the cgroup classid on
attach, task_cls_classid still returns zero. I'm not sure why that is yet, but
I'm looking into it.
Neil
>
^ permalink raw reply
* REPLY ME....
From: Dr Raymond Kuo Fung Chien @ 2010-05-22 11:15 UTC (permalink / raw)
Dear Friend,
I am Dr Raymond Kuo Fung CHIEN Executive Director and Chief Financial
Officer of the operations of the Hang Seng Bank Ltd.
Befor the U.S and Iraqi war our client Mr.Fayez A Mohammed a business
merchant made a fixed deposit of USD30 Million for 2Yrs
where i was the only one that knew about his deposits.
Upon maturity during the war in 2003,Fayez,his wife and only daugther died
in a bomb blast that hits His Resident.
Investigations showed that he didnt declear any next of kin.As a
foreigner,I want you to stand as the next of kin to claim
the fund because soon the fund will be claimed by my government if no one
comes for it.
I have an attorney that will prepare all the documents to back you up as
the next of kin to Mr.Fayez A.Mohammed.Plz let me
know your willingness so that i can provide you with more details of this
transaction.
contact me on email: drrayfung@9.cn
1. Full name and Age
2. Occupation
3. Private/office phone number
4. Current residential address
Kind Regards,
Dr Raymond Kuo Fung CHIEN.
^ permalink raw reply
* REPLY ME....
From: Dr Raymond Kuo Fung Chien @ 2010-05-22 11:15 UTC (permalink / raw)
Dear Friend,
I am Dr Raymond Kuo Fung CHIEN Executive Director and Chief Financial
Officer of the operations of the Hang Seng Bank Ltd.
Befor the U.S and Iraqi war our client Mr.Fayez A Mohammed a business
merchant made a fixed deposit of USD30 Million for 2Yrs
where i was the only one that knew about his deposits.
Upon maturity during the war in 2003,Fayez,his wife and only daugther died
in a bomb blast that hits His Resident.
Investigations showed that he didnt declear any next of kin.As a
foreigner,I want you to stand as the next of kin to claim
the fund because soon the fund will be claimed by my government if no one
comes for it.
I have an attorney that will prepare all the documents to back you up as
the next of kin to Mr.Fayez A.Mohammed.Plz let me
know your willingness so that i can provide you with more details of this
transaction.
contact me on email: drrayfung@9.cn
1. Full name and Age
2. Occupation
3. Private/office phone number
4. Current residential address
Kind Regards,
Dr Raymond Kuo Fung CHIEN.
^ permalink raw reply
* [PATCH 1/5] net/phy/marvell: Expose IDs and flags in a .h and add dns323 LEDs setup flag
From: Benjamin Herrenschmidt @ 2010-05-22 10:54 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org; +Cc: netdev, Wolfram Sang, Nicolas Pitre
This moves the various known Marvell PHY IDs to include/linux/marvell_phy.h
along with dev_flags definitions for use by the driver.
I then added a flag that changes the PHY init code to setup the LEDs
config to the values needed to operate a dns323 rev C1 NAS.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: netdev@vger.kernel.org
CC: Wolfram Sang <w.sang@pengutronix.de>
---
Note: My subsequent DNS-323 rev C support patches depend on that one, so if
you (netdev) guys are ok with it, it could be merged via the ARM tree along
with the other stuff.
drivers/net/phy/marvell.c | 34 +++++++++++++++++++---------------
include/linux/marvell_phy.h | 19 +++++++++++++++++++
2 files changed, 38 insertions(+), 15 deletions(-)
create mode 100644 include/linux/marvell_phy.h
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 64c7fbe..34447ef 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -29,6 +29,7 @@
#include <linux/mii.h>
#include <linux/ethtool.h>
#include <linux/phy.h>
+#include <linux/marvell_phy.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -350,7 +351,10 @@ static int m88e1118_config_init(struct phy_device *phydev)
return err;
/* Adjust LED Control */
- err = phy_write(phydev, 0x10, 0x021e);
+ if (phydev->dev_flags & MARVELL_PHY_DNS323_LEDS)
+ err = phy_write(phydev, 0x10, 0x1100);
+ else
+ err = phy_write(phydev, 0x10, 0x021e);
if (err < 0)
return err;
@@ -529,8 +533,8 @@ static int m88e1121_did_interrupt(struct phy_device *phydev)
static struct phy_driver marvell_drivers[] = {
{
- .phy_id = 0x01410c60,
- .phy_id_mask = 0xfffffff0,
+ .phy_id = MARVELL_PHY_ID_88E1101,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1101",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
@@ -541,8 +545,8 @@ static struct phy_driver marvell_drivers[] = {
.driver = { .owner = THIS_MODULE },
},
{
- .phy_id = 0x01410c90,
- .phy_id_mask = 0xfffffff0,
+ .phy_id = MARVELL_PHY_ID_88E1112,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1112",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
@@ -554,8 +558,8 @@ static struct phy_driver marvell_drivers[] = {
.driver = { .owner = THIS_MODULE },
},
{
- .phy_id = 0x01410cc0,
- .phy_id_mask = 0xfffffff0,
+ .phy_id = MARVELL_PHY_ID_88E1111,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1111",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
@@ -567,8 +571,8 @@ static struct phy_driver marvell_drivers[] = {
.driver = { .owner = THIS_MODULE },
},
{
- .phy_id = 0x01410e10,
- .phy_id_mask = 0xfffffff0,
+ .phy_id = MARVELL_PHY_ID_88E1118,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1118",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
@@ -580,8 +584,8 @@ static struct phy_driver marvell_drivers[] = {
.driver = {.owner = THIS_MODULE,},
},
{
- .phy_id = 0x01410cb0,
- .phy_id_mask = 0xfffffff0,
+ .phy_id = MARVELL_PHY_ID_88E1121R,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1121R",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
@@ -593,8 +597,8 @@ static struct phy_driver marvell_drivers[] = {
.driver = { .owner = THIS_MODULE },
},
{
- .phy_id = 0x01410cd0,
- .phy_id_mask = 0xfffffff0,
+ .phy_id = MARVELL_PHY_ID_88E1145,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1145",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
@@ -606,8 +610,8 @@ static struct phy_driver marvell_drivers[] = {
.driver = { .owner = THIS_MODULE },
},
{
- .phy_id = 0x01410e30,
- .phy_id_mask = 0xfffffff0,
+ .phy_id = MARVELL_PHY_ID_88E1240,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1240",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
new file mode 100644
index 0000000..b5cb8c8
--- /dev/null
+++ b/include/linux/marvell_phy.h
@@ -0,0 +1,19 @@
+#ifndef _MARVELL_PHY_H
+#define _MARVELL_PHY_H
+
+/* Mask used for ID comparisons */
+#define MARVELL_PHY_ID_MASK 0xfffffff0
+
+/* Known PHY IDs */
+#define MARVELL_PHY_ID_88E1101 0x01410c60
+#define MARVELL_PHY_ID_88E1112 0x01410c90
+#define MARVELL_PHY_ID_88E1111 0x01410cc0
+#define MARVELL_PHY_ID_88E1118 0x01410e10
+#define MARVELL_PHY_ID_88E1121R 0x01410cb0
+#define MARVELL_PHY_ID_88E1145 0x01410cd0
+#define MARVELL_PHY_ID_88E1240 0x01410e30
+
+/* struct phy_device dev_flags definitions */
+#define MARVELL_PHY_DNS323_LEDS 0x00000001
+
+#endif /* _MARVELL_PHY_H */
^ permalink raw reply related
* Re: tc: RTM_GETQDISC causes kernel OOPS
From: Patrick McHardy @ 2010-05-22 9:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Pfaff, Jamal Hadi Salim, netdev
In-Reply-To: <1274512687.5020.21.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le vendredi 21 mai 2010 à 15:42 -0700, Ben Pfaff a écrit :
>> Hi. While working on some library code for working with qdiscs and
>> classes I came upon a kernel OOPS. Originally I came across it with a
>> 2.6.26 kernel, but I can also reproduce it with unmodified v2.6.34 from
>> kernel.org.
>>
>> At the end of this mail I'm appending both an example of the OOPS and a
>> simple test program that reliably reproduces the problem for me when I
>> invoke it with "lo" as argument. The program does not need to be run as
>> root.
>>
>> After the OOPS, a lot of networking and other system functions stop
>> working, so it seems to me a serious issue.
>>
>> The null pointer dereference that causes the OOPS is the dereference of
>> the return value of qdisc_dev() in tc_fill_qdisc() in
>> net/sched/sch_api.c line 1163:
>>
>> 1161 tcm->tcm__pad1 = 0;
>> 1162 tcm->tcm__pad2 = 0;
>> 1163 tcm->tcm_ifindex = qdisc_dev(q)->ifindex;
>> 1164 tcm->tcm_parent = clid;
>> 1165 tcm->tcm_handle = q->handle;
>>
>> I am pretty sure about that, because if I add "WARN_ON(!qdisc_dev(q));"
>> just before line 1163 then that warning triggers.
>>
>> Thanks,
>
> Indeed, thanks for this very useful report !
>
> We could add a check for TCQ_F_BUILTIN flag, or just make
> qdisc_notify() checks consistent for both old and new qdisc
>
> What other people thinks ?
We already use TCQ_F_BUILTIN in tc_qdisc_dump_ignore(), so I
think it would be more consistent than checking for a handle
to use it here as well.
^ 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