* Re: [PATCH iproute2 v2 1/2] ip link: fix display of interface groups
From: Stephen Hemminger @ 2013-08-04 18:52 UTC (permalink / raw)
To: Stefan Tomanek; +Cc: netdev
In-Reply-To: <20130803122053.GM21970@zirkel.wertarbyte.de>
Applied.
Since this doesn't depend on anything new, it goes into master for 3.11
^ permalink raw reply
* Re: [PATCH iproute2 v2 2/2] ip rule: add route suppression options
From: Stephen Hemminger @ 2013-08-04 18:56 UTC (permalink / raw)
To: Stefan Tomanek; +Cc: netdev
In-Reply-To: <20130803122316.GN21970@zirkel.wertarbyte.de>
On Sat, 3 Aug 2013 14:23:16 +0200
Stefan Tomanek <stefan.tomanek@wertarbyte.de> wrote:
> When configuring a system with multiple network uplinks and default routes, it
> is often convenient to reference a routing table multiple times - but reject
> its routing decision if certain constraints are not met by it.
>
> Consider this setup:
>
> $ ip route add table secuplink default via 10.42.23.1
>
> $ ip rule add pref 100 table main suppress_prefixlength 0
> $ ip rule add pref 150 fwmark 0xA table secuplink
>
> With this setup, packets marked 0xA will be processed by the additional routing
> table "secuplink", but only if no suitable route in the main routing table can
> be found. By suppressing entries with a prefixlength of 0 (or less), the
> default route (/0) of the table "main" is hidden to packets processed by rule
> 100; packets traveling to destinations via more specific routes are processed
> as usual.
>
> It is also possible to suppress a routing entry if a device belonging to
> a specific interface group is to be used:
>
> $ ip rule add pref 150 table main suppress_group 1
>
> Signed-off-by: Stefan Tomanek <stefan.tomanek@wertarbyte.de>
Applied to net-next-3.11 branch
^ permalink raw reply
* Re: [PATCH] iproute vxlan add support for fdb replace command
From: Stephen Hemminger @ 2013-08-04 18:57 UTC (permalink / raw)
To: Thomas Richter; +Cc: netdev
In-Reply-To: <1375165001-6776-1-git-send-email-tmricht@linux.vnet.ibm.com>
On Tue, 30 Jul 2013 08:16:41 +0200
Thomas Richter <tmricht@linux.vnet.ibm.com> wrote:
> Add support for the bridge fdb replace command to replace an
> existing entry in the vxlan device driver forwarding data base.
> The entry is identified with its unicast mac address and its
> corresponding remote destination information is updated.
>
> This is useful for virtual machine migration and replaces the
> bridge fdb del and bridge fdb add commands.
>
> It follows the same interface as ip neigh replace commands.
>
> Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Applied to master for next release.
^ permalink raw reply
* Re: [PATCH net-next v6 1/8] vxlan: Restructure vxlan socket apis.
From: Stephen Hemminger @ 2013-08-04 21:42 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: netdev
In-Reply-To: <1375382680-3137-1-git-send-email-pshelar@nicira.com>
On Thu, 1 Aug 2013 11:44:40 -0700
Pravin B Shelar <pshelar@nicira.com> wrote:
> @@ -1642,59 +1651,56 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port)
> &vxlan_addr.sin_addr, ntohs(vxlan_addr.sin_port), rc);
> sk_release_kernel(sk);
> kfree(vs);
> - return ERR_PTR(rc);
> + return;
> }
> + atomic_set(&vs->refcnt, 0);
>
> /* Disable multicast loopback */
> inet_sk(sk)->mc_loop = 0;
> + spin_lock(&vn->sock_lock);
> + hlist_add_head_rcu(&vs->hlist, vs_head(net, port));
> + spin_unlock(&vn->sock_lock);
Overall I am fine with this set, except for this.
The change causes a socket to be put into the hash list with a ref count
of 0 and then you increment the ref count. If some other thread
finds the socket and then decrements the ref count, it would go
below zero and might leak, crash or delete it prematurely.
This concerns me.
^ permalink raw reply
* Re: [PATCH net-next v6 2/8] vxlan: Restructure vxlan receive.
From: Stephen Hemminger @ 2013-08-04 21:43 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: netdev
In-Reply-To: <1375382685-3177-1-git-send-email-pshelar@nicira.com>
On Thu, 1 Aug 2013 11:44:45 -0700
Pravin B Shelar <pshelar@nicira.com> wrote:
> Use iptunnel_pull_header() for better code sharing.
>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
This patch is good.
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply
* Re: [PATCH net-next v6 3/8] vxlan: Add vxlan recv demux.
From: Stephen Hemminger @ 2013-08-04 21:45 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: netdev
In-Reply-To: <1375382689-3218-1-git-send-email-pshelar@nicira.com>
On Thu, 1 Aug 2013 11:44:49 -0700
Pravin B Shelar <pshelar@nicira.com> wrote:
> +static struct vxlan_sock *vxlan_sock_add(struct net *net, __be16 port,
> + vxlan_rcv_t *rcv)
> {
> struct vxlan_net *vn = net_generic(net, vxlan_net_id);
> struct vxlan_sock *vs;
>
> - vxlan_socket_create(net, port);
> + vxlan_socket_create(net, port, rcv);
>
> spin_lock(&vn->sock_lock);
> vs = vxlan_find_sock(net, port);
> - if (vs)
> - atomic_inc(&vs->refcnt);
> - else
> + if (vs) {
> + if (vs->rcv == rcv)
> + atomic_inc(&vs->refcnt);
> + else
> + vs = ERR_PTR(-EBUSY);
> + }
> + spin_unlock(&vn->sock_lock);
> +
I think the ref counting needs to be the same for the
kernel and OVS handling of a VXLAN.
^ permalink raw reply
* [PATCH net-next v3] vxlan: fix rcu related warning
From: Stephen Hemminger @ 2013-08-05 0:17 UTC (permalink / raw)
To: Pravin Shelar
Cc: Eric Dumazet, David Miller, Thomas Richter, Mike Rapoport, netdev
In-Reply-To: <CALnjE+obgWjqDhuyWUJ=kimMKQbbweenRdxbU1ZCBWBP_qe8Zg@mail.gmail.com>
Vxlan remote list is protected by RCU and guaranteed to be non-empty.
Split out the rcu and non-rcu access to the list to fix warning
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
v3 - remove one __rcu
--- a/drivers/net/vxlan.c 2013-08-04 11:04:01.922478082 -0700
+++ b/drivers/net/vxlan.c 2013-08-04 16:54:33.214598043 -0700
@@ -177,9 +177,14 @@ static inline struct hlist_head *vs_head
/* First remote destination for a forwarding entry.
* Guaranteed to be non-NULL because remotes are never deleted.
*/
-static inline struct vxlan_rdst *first_remote(struct vxlan_fdb *fdb)
+static inline struct vxlan_rdst *first_remote_rcu(struct vxlan_fdb *fdb)
{
- return list_first_or_null_rcu(&fdb->remotes, struct vxlan_rdst, list);
+ return list_entry_rcu(fdb->remotes.next, struct vxlan_rdst, list);
+}
+
+static inline struct vxlan_rdst *first_remote_rtnl(struct vxlan_fdb *fdb)
+{
+ return list_first_entry(&fdb->remotes, struct vxlan_rdst, list);
}
/* Find VXLAN socket based on network namespace and UDP port */
@@ -297,7 +302,8 @@ static void vxlan_fdb_notify(struct vxla
if (skb == NULL)
goto errout;
- err = vxlan_fdb_info(skb, vxlan, fdb, 0, 0, type, 0, first_remote(fdb));
+ err = vxlan_fdb_info(skb, vxlan, fdb, 0, 0, type, 0,
+ first_remote_rtnl(fdb));
if (err < 0) {
/* -EMSGSIZE implies BUG in vxlan_nlmsg_size() */
WARN_ON(err == -EMSGSIZE);
@@ -740,7 +746,7 @@ static bool vxlan_snoop(struct net_devic
f = vxlan_find_mac(vxlan, src_mac);
if (likely(f)) {
- struct vxlan_rdst *rdst = first_remote(f);
+ struct vxlan_rdst *rdst = first_remote_rcu(f);
if (likely(rdst->remote_ip == src_ip))
return false;
@@ -1005,7 +1011,7 @@ static int arp_reduce(struct net_device
}
f = vxlan_find_mac(vxlan, n->ha);
- if (f && first_remote(f)->remote_ip == htonl(INADDR_ANY)) {
+ if (f && first_remote_rcu(f)->remote_ip == htonl(INADDR_ANY)) {
/* bridge-local neighbor */
neigh_release(n);
goto out;
^ permalink raw reply
* [PATCH net-next] bridge: fix rcu check warning in multicast port group
From: Stephen Hemminger @ 2013-08-05 0:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Use of RCU here with out marked pointer and function doesn't match prototype
with sparse.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/net/bridge/br_mdb.c 2013-08-04 11:04:02.530470675 -0700
+++ b/net/bridge/br_mdb.c 2013-08-04 17:06:46.457182483 -0700
@@ -61,7 +61,8 @@ static int br_mdb_fill_info(struct sk_bu
for (i = 0; i < mdb->max; i++) {
struct net_bridge_mdb_entry *mp;
- struct net_bridge_port_group *p, **pp;
+ struct net_bridge_port_group *p;
+ struct net_bridge_port_group __rcu **pp;
struct net_bridge_port *port;
hlist_for_each_entry_rcu(mp, &mdb->mhash[i], hlist[mdb->ver]) {
--- a/net/bridge/br_private.h 2013-08-04 11:04:02.534470627 -0700
+++ b/net/bridge/br_private.h 2013-08-04 17:02:29.972453140 -0700
@@ -466,7 +466,7 @@ extern void br_multicast_free_pg(struct
extern struct net_bridge_port_group *br_multicast_new_port_group(
struct net_bridge_port *port,
struct br_ip *group,
- struct net_bridge_port_group *next,
+ struct net_bridge_port_group __rcu *next,
unsigned char state);
extern void br_mdb_init(void);
extern void br_mdb_uninit(void);
^ permalink raw reply
* [PATCH net] skge: add dma_mapping check
From: Stephen Hemminger @ 2013-08-05 0:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev
This old driver never checked for DMA mapping errors.
Causing splats with the new DMA mapping checks:
WARNING: at lib/dma-debug.c:937 check_unmap+0x47b/0x930()
skge 0000:01:09.0: DMA-API: device driver failed to check map
Add checks and unwind code.
Reported-by: poma <pomidorabelisima@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/drivers/net/ethernet/marvell/skge.c 2013-08-04 11:03:20.842978549 -0700
+++ b/drivers/net/ethernet/marvell/skge.c 2013-08-04 17:08:19.256002544 -0700
@@ -931,15 +931,18 @@ static int skge_ring_alloc(struct skge_r
}
/* Allocate and setup a new buffer for receiving */
-static void skge_rx_setup(struct skge_port *skge, struct skge_element *e,
+static int skge_rx_setup(struct skge_port *skge, struct skge_element *e,
struct sk_buff *skb, unsigned int bufsize)
{
struct skge_rx_desc *rd = e->desc;
- u64 map;
+ dma_addr_t map;
map = pci_map_single(skge->hw->pdev, skb->data, bufsize,
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(skge->hw->pdev, map))
+ return -1;
+
rd->dma_lo = map;
rd->dma_hi = map >> 32;
e->skb = skb;
@@ -953,6 +956,7 @@ static void skge_rx_setup(struct skge_po
rd->control = BMU_OWN | BMU_STF | BMU_IRQ_EOF | BMU_TCP_CHECK | bufsize;
dma_unmap_addr_set(e, mapaddr, map);
dma_unmap_len_set(e, maplen, bufsize);
+ return 0;
}
/* Resume receiving using existing skb,
@@ -1014,7 +1018,10 @@ static int skge_rx_fill(struct net_devic
return -ENOMEM;
skb_reserve(skb, NET_IP_ALIGN);
- skge_rx_setup(skge, e, skb, skge->rx_buf_size);
+ if (skge_rx_setup(skge, e, skb, skge->rx_buf_size) < 0) {
+ dev_kfree_skb(skb);
+ return -EIO;
+ }
} while ((e = e->next) != ring->start);
ring->to_clean = ring->start;
@@ -2729,7 +2736,7 @@ static netdev_tx_t skge_xmit_frame(struc
struct skge_tx_desc *td;
int i;
u32 control, len;
- u64 map;
+ dma_addr_t map;
if (skb_padto(skb, ETH_ZLEN))
return NETDEV_TX_OK;
@@ -2743,6 +2750,9 @@ static netdev_tx_t skge_xmit_frame(struc
e->skb = skb;
len = skb_headlen(skb);
map = pci_map_single(hw->pdev, skb->data, len, PCI_DMA_TODEVICE);
+ if (pci_dma_mapping_error(hw->pdev, map))
+ goto mapping_error;
+
dma_unmap_addr_set(e, mapaddr, map);
dma_unmap_len_set(e, maplen, len);
@@ -2778,6 +2788,8 @@ static netdev_tx_t skge_xmit_frame(struc
map = skb_frag_dma_map(&hw->pdev->dev, frag, 0,
skb_frag_size(frag), DMA_TO_DEVICE);
+ if (dma_mapping_error(&hw->pdev->dev, map))
+ goto mapping_unwind;
e = e->next;
e->skb = skb;
@@ -2815,6 +2827,26 @@ static netdev_tx_t skge_xmit_frame(struc
}
return NETDEV_TX_OK;
+
+mapping_unwind:
+ e = skge->tx_ring.to_use;
+ pci_unmap_single(hw->pdev,
+ dma_unmap_addr(e, mapaddr),
+ dma_unmap_len(e, maplen),
+ PCI_DMA_TODEVICE);
+ while (i-- > 0) {
+ e = e->next;
+ pci_unmap_page(hw->pdev,
+ dma_unmap_addr(e, mapaddr),
+ dma_unmap_len(e, maplen),
+ PCI_DMA_TODEVICE);
+ }
+
+mapping_error:
+ if (net_ratelimit())
+ dev_warn(&hw->pdev->dev, "%s: tx mapping error\n", dev->name);
+ dev_kfree_skb(skb);
+ return NETDEV_TX_OK;
}
@@ -3058,13 +3090,17 @@ static struct sk_buff *skge_rx_get(struc
if (!nskb)
goto resubmit;
+ if (skge_rx_setup(skge, e, nskb, skge->rx_buf_size) < 0) {
+ dev_kfree_skb(nskb);
+ goto resubmit;
+ }
+
pci_unmap_single(skge->hw->pdev,
dma_unmap_addr(e, mapaddr),
dma_unmap_len(e, maplen),
PCI_DMA_FROMDEVICE);
skb = e->skb;
prefetch(skb->data);
- skge_rx_setup(skge, e, nskb, skge->rx_buf_size);
}
skb_put(skb, len);
^ permalink raw reply
* Re: [PATCH net] skge: add dma_mapping check
From: David Miller @ 2013-08-05 1:35 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20130804172234.345913ae@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sun, 4 Aug 2013 17:22:34 -0700
> This old driver never checked for DMA mapping errors.
> Causing splats with the new DMA mapping checks:
> WARNING: at lib/dma-debug.c:937 check_unmap+0x47b/0x930()
> skge 0000:01:09.0: DMA-API: device driver failed to check map
>
> Add checks and unwind code.
>
> Reported-by: poma <pomidorabelisima@gmail.com>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied, but:
> -static void skge_rx_setup(struct skge_port *skge, struct skge_element *e,
> +static int skge_rx_setup(struct skge_port *skge, struct skge_element *e,
> struct sk_buff *skb, unsigned int bufsize)
I reflowed the argument indentation for this in the final commit.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] bridge: fix rcu check warning in multicast port group
From: David Miller @ 2013-08-05 1:42 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20130804171938.0d515529@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sun, 4 Aug 2013 17:19:38 -0700
> Use of RCU here with out marked pointer and function doesn't match prototype
> with sparse.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3] vxlan: fix rcu related warning
From: David Miller @ 2013-08-05 1:47 UTC (permalink / raw)
To: stephen; +Cc: pshelar, eric.dumazet, tmricht, mike.rapoport, netdev
In-Reply-To: <20130804171739.63ee771e@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sun, 4 Aug 2013 17:17:39 -0700
> Vxlan remote list is protected by RCU and guaranteed to be non-empty.
> Split out the rcu and non-rcu access to the list to fix warning
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Also applied, thanks.
^ permalink raw reply
* RE: [PATCH v3] net/phy: micrel: Add OF configuration support for ksz9021
From: Duan Fugang-B38611 @ 2013-08-05 1:58 UTC (permalink / raw)
To: Sean Cross, Sascha Hauer, netdev@vger.kernel.org,
devicetree@vger.kernel.org
Cc: David Miller, stephen@networkplumber.org, Steven Rostedt
In-Reply-To: <1375348757-12856-2-git-send-email-xobs@kosagi.com>
From: Sean Cross [mailto:xobs@kosagi.com]
Data: Thursday, August 01, 2013 5:19 PM
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt
> @@ -0,0 +1,19 @@
> +Micrel KSZ9021 Gigabit Ethernet PHY
> +
> +Some boards require special tuning values, particularly when it comes
> +to clock delays. You can specify clock delay values by adding
> +micrel-specific properties to an Ethernet OF device node.
> +
> +Optional properties:
> +- micrel,clk-control-pad-skew : Timing offset for the MII clock line
> +- micrel,rx-data-pad-skew : Timing offset for the RX MII pad
> +- micrel,tx-data-pad-skew : Timing offset for the TX MII pad
> +
> +Example:
> + &enet {
> + micrel,clk-control-pad-skew = <0xf0f0>;
> + micrel,rx-data-pad-skew = <0x0000>;
> + micrel,tx-data-pad-skew = <0xffff>;
> + status = "okay";
> + };
> +
The phy binding must be the phy node, not the ethernet node.
Pls refer to:
Documentation/devicetree/booting-without-of.txt
Documentation/devicetree/bindings/net/phy.txt
> +static int ksz9021_config_init(struct phy_device *phydev) {
> + struct device *dev = &phydev->dev;
> + struct device_node *of_node = dev->of_node;
> +
> + if (!of_node && dev->parent->of_node)
> + of_node = dev->parent->of_node;
> +
If phy binding is phy node, there only check of_node, don't re-evaluate the phy node.
Thanks,
Andy
^ permalink raw reply
* Re: [PATCH v3] net/phy: micrel: Add OF configuration support for ksz9021
From: Sean Cross @ 2013-08-05 2:23 UTC (permalink / raw)
To: Duan Fugang-B38611
Cc: Sascha Hauer, netdev@vger.kernel.org, devicetree@vger.kernel.org,
David Miller, stephen@networkplumber.org, Steven Rostedt
In-Reply-To: <9848F2DB572E5649BA045B288BE08FBE015ED2F7@039-SN2MPN1-023.039d.mgd.msft.net>
On Monday, 5 August, 2013 at 9:58 AM, Duan Fugang-B38611 wrote:
> From: Sean Cross [mailto:xobs@kosagi.com]
> Data: Thursday, August 01, 2013 5:19 PM
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt
> > @@ -0,0 +1,19 @@
> > +Micrel KSZ9021 Gigabit Ethernet PHY
> > +
> > +Some boards require special tuning values, particularly when it comes
> > +to clock delays. You can specify clock delay values by adding
> > +micrel-specific properties to an Ethernet OF device node.
> > +
> > +Optional properties:
> > +- micrel,clk-control-pad-skew : Timing offset for the MII clock line
> > +- micrel,rx-data-pad-skew : Timing offset for the RX MII pad
> > +- micrel,tx-data-pad-skew : Timing offset for the TX MII pad
> > +
> > +Example:
> > + &enet {
> > + micrel,clk-control-pad-skew = <0xf0f0>;
> > + micrel,rx-data-pad-skew = <0x0000>;
> > + micrel,tx-data-pad-skew = <0xffff>;
> > + status = "okay";
> > + };
> > +
>
>
>
> The phy binding must be the phy node, not the ethernet node.
> Pls refer to:
> Documentation/devicetree/booting-without-of.txt
> Documentation/devicetree/bindings/net/phy.txt
This won't necessarily work. In my board, I don't think it's possible to manually specify the PHY, as most of the fields required by the OF PHY node don't apply to this device (at least according to phy.txt). There are no interrupts, no interrupt parent, and it's unclear what the reg or linux,phandle fields do. All of these are required fields, none of which seem to apply to this particular board. Furthermore, it doesn't seem to be possible to specify a particular PHY, such as the ksz9021.
I see the pattern of getting OF settings from a parent's node used elsewhere in the kernel. For example, in mmc_of_parse(), or more similarly in the chipidea ci_hdrc_probe() driver.
> > +static int ksz9021_config_init(struct phy_device *phydev) {
> > + struct device *dev = &phydev->dev;
> > + struct device_node *of_node = dev->of_node;
> > +
> > + if (!of_node && dev->parent->of_node)
> > + of_node = dev->parent->of_node;
> > +
>
>
> If phy binding is phy node, there only check of_node, don't re-evaluate the phy node.
It's done this way in case it's not possible to add a phy node, as in this case.
^ permalink raw reply
* Re: [PATCH net-next] Documentation: add networking/netdev-FAQ.txt
From: Rob Landley @ 2013-08-05 2:34 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: David S. Miller, linux-doc, netdev, Paul Gortmaker
In-Reply-To: <1375298180-17628-1-git-send-email-paul.gortmaker@windriver.com>
On 07/31/2013 02:16:20 PM, Paul Gortmaker wrote:
> A collection of expectations and operational details about how
> networking development takes place in the context of the netdev
> mailing list.
http://vger.kernel.org has 149 mailing lists, and that's maybe half of
the kernel lists out there. (The linux foundation's got a bunch, the
device tree list just switched servers, etc.)
Why is this list special?
> +++ b/Documentation/networking/netdev-FAQ.txt
> @@ -0,0 +1,224 @@
> +
> +Information you need to know about netdev
> +-----------------------------------------
> +
> +Q: What is netdev?
> +
> +A: It is a mailing list for all network related linux stuff. This
> includes
> + anything found under net/ (i.e. core code like IPv6) and
> drivers/net
> + (i.e. hardware specific drivers) in the linux source tree.
I'm all for having this somewhere, but this is a silly place for it.
Putting it in linux/Documentation means you'll frequently tell newbies
"read the FAQ, except it's not on the web, we stuck it in a
subdirectory of a sudirectory of the kernel source because that's the
obvious place to stick the FAQ for a mailing list".
Rob
^ permalink raw reply
* Re: [PATCH net-next] Documentation: add networking/netdev-FAQ.txt
From: David Miller @ 2013-08-05 2:36 UTC (permalink / raw)
To: rob; +Cc: paul.gortmaker, linux-doc, netdev
In-Reply-To: <1375670051.8422.6@driftwood>
From: Rob Landley <rob@landley.net>
Date: Sun, 04 Aug 2013 21:34:11 -0500
> Putting it in linux/Documentation means you'll frequently tell newbies
> "read the FAQ, except it's not on the web, we stuck it in a
> subdirectory of a sudirectory of the kernel source because that's the
> obvious place to stick the FAQ for a mailing list".
People who want to do kernel development grab a copy of the kernel
sources, therefore it's appropriate to document operation aspects
of kernel development there.
^ permalink raw reply
* Re: [PATCH net] busy_poll: cleanup do-nothing placeholders
From: David Miller @ 2013-08-05 2:41 UTC (permalink / raw)
To: eliezer.tamir; +Cc: linux-kernel, netdev, eliezer
In-Reply-To: <20130804095548.30006.8133.stgit@ladj378.jer.intel.com>
From: Eliezer Tamir <eliezer.tamir@linux.intel.com>
Date: Sun, 04 Aug 2013 12:55:48 +0300
> When renaming ll_poll to busy poll, I introduced a typo
> in the name of the do-nothing placeholder for sk_busy_loop
> and called it sk_busy_poll.
> This broke compile when busy poll was not configured.
> Cong Wang submitted a patch to fixed that.
> This patch removes the now redundant, misspelled placeholder.
>
> Signed-off-by: Eliezer Tamir <eliezer.tamir@linux.intel.com>
Applied, thanks.
^ permalink raw reply
* BUG cxgb3: Check and handle the dma mapping errors
From: Alexey Kardashevskiy @ 2013-08-05 2:59 UTC (permalink / raw)
To: Santosh Rastapur, Divy Le Ray
Cc: Jay Fenlason, David S. Miller, netdev, Linux Kernel Mailing List
Hi!
Recently I started getting multiple errors like this:
cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
c000001fbdaaa882 npages 1
cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
c000001fbdaaa882 npages 1
cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
c000001fbdaaa882 npages 1
cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
c000001fbdaaa882 npages 1
cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
c000001fbdaaa882 npages 1
cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
c000001fbdaaa882 npages 1
cxgb3 0006:01:00.0: iommu_alloc failed, tbl c000000003067980 vaddr
c000001fbdaaa882 npages 1
... and so on
This is all happening on a PPC64 "powernv" platform machine. To trigger the
error state, it is enough to _flood_ ping CXGB3 card from another machine
(which has Emulex 10Gb NIC + Cisco switch). Just do "ping -f 172.20.1.2"
and wait 10-15 seconds.
The messages are coming from arch/powerpc/kernel/iommu.c and basically
mean that the driver requested more pages than the DMA window has which is
normally 1GB (there could be another possible source of errors -
ppc_md.tce_build callback - but on powernv platform it always succeeds).
The patch after which it broke is:
commit f83331bab149e29fa2c49cf102c0cd8c3f1ce9f9
Author: Santosh Rastapur <santosh@chelsio.com>
Date: Tue May 21 04:21:29 2013 +0000
cxgb3: Check and handle the dma mapping errors
Any quick ideas? Thanks!
--
Alexey
^ permalink raw reply
* [PATCH] hostap: do not return positive number on failure path in prism2_open()
From: Alexey Khoroshilov @ 2013-08-05 3:02 UTC (permalink / raw)
To: Jouni Malinen, John W. Linville
Cc: Alexey Khoroshilov, linux-wireless, netdev, linux-kernel,
ldv-project, Alexey Khoroshilov
prism2_open() as an .ndo_open handler should not return positive numbers
in case of failure, but it does return 1 in a couple of places.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilorv@ispras.ru>
---
drivers/net/wireless/hostap/hostap_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
index 15f0fad..e4f56ad 100644
--- a/drivers/net/wireless/hostap/hostap_main.c
+++ b/drivers/net/wireless/hostap/hostap_main.c
@@ -667,7 +667,7 @@ static int prism2_open(struct net_device *dev)
if (local->no_pri) {
printk(KERN_DEBUG "%s: could not set interface UP - no PRI "
"f/w\n", dev->name);
- return 1;
+ return -ENODEV;
}
if ((local->func->card_present && !local->func->card_present(local)) ||
@@ -682,7 +682,7 @@ static int prism2_open(struct net_device *dev)
printk(KERN_WARNING "%s: could not enable MAC port\n",
dev->name);
prism2_close(dev);
- return 1;
+ return -ENODEV;
}
if (!local->dev_enabled)
prism2_callback(local, PRISM2_CALLBACK_ENABLE);
--
1.8.1.2
^ permalink raw reply related
* RE: [PATCH v3] net/phy: micrel: Add OF configuration support for ksz9021
From: Duan Fugang-B38611 @ 2013-08-05 3:03 UTC (permalink / raw)
To: Sean Cross
Cc: Sascha Hauer, netdev@vger.kernel.org, devicetree@vger.kernel.org,
David Miller, stephen@networkplumber.org, Steven Rostedt
In-Reply-To: <5CE77AC80B4242C98833109D6F1C9F85@kosagi.com>
From: Sean Cross [mailto:xobs@kosagi.com]
Data: Monday, August 05, 2013 10:24 AM
> > > +Example:
> > > + &enet {
> > > + micrel,clk-control-pad-skew = <0xf0f0>; micrel,rx-data-pad-skew =
> > > +<0x0000>; micrel,tx-data-pad-skew = <0xffff>; status = "okay";
> > > +};
> > > +
> >
> >
> >
> > The phy binding must be the phy node, not the ethernet node.
> > Pls refer to:
> > Documentation/devicetree/booting-without-of.txt
> > Documentation/devicetree/bindings/net/phy.txt
>
> This won't necessarily work. In my board, I don't think it's possible to
> manually specify the PHY, as most of the fields required by the OF PHY
> node don't apply to this device (at least according to phy.txt). There
> are no interrupts, no interrupt parent, and it's unclear what the reg or
> linux,phandle fields do. All of these are required fields, none of which
> seem to apply to this particular board. Furthermore, it doesn't seem to
> be possible to specify a particular PHY, such as the ksz9021.
>
> I see the pattern of getting OF settings from a parent's node used
> elsewhere in the kernel. For example, in mmc_of_parse(), or more
> similarly in the chipidea ci_hdrc_probe() driver.
Yes, the patch is only reasonable for your platform, but it is the phy driver for different platforms that you must considerate.
Please add more example cases in binding doc.
^ permalink raw reply
* Re: [Patch net-next v2 1/8] net: introduce generic union inet_addr
From: Cong Wang @ 2013-08-05 3:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, dborkman, joe, linux-kernel
In-Reply-To: <20130802.145041.845804796107623114.davem@davemloft.net>
On Fri, 2013-08-02 at 14:50 -0700, David Miller wrote:
> From: Cong Wang <amwang@redhat.com>
> Date: Fri, 2 Aug 2013 15:14:27 +0800
>
> > From: Cong Wang <amwang@redhat.com>
> >
> > Introduce a generic IP address type, union inet_addr, so that
> > subsystems don't have to use their own definitions. Because
> > netpoll already defines union inet_addr, just move it to global.
> > Some of the helper functions will be used by VXLAN IPv6 code too.
> >
> > This patch also reuses the "%pIS" specifier, to make it accept
> > union inet_addr instead of struct sockaddr.
> >
> > Cc: Daniel Borkmann <dborkman@redhat.com>
> > Cc: Joe Perches <joe@perches.com>
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Cong Wang <amwang@redhat.com>
>
> Changing %pIS to %pIA is pure churn, and of zero value that I can see.
'S' in %pIS is for Sockaddr, since this patch makes it accept union
inet_addr instead of struct sockaddr, I don't think 'S' is meaningful
any more.
>
> Every time I review this patch set I discover some new thing that I'm
> very disappointed with.
The "%pIS" change exists in v1, I don't know why you think it is new in
v2. Also, if you can point all what you dislike at one time, it would
save time for both of us, I prefer to fix them all in one update.
>
> You're going to have to stop being so ambitious, and start very small.
>
> Maybe one tiny patch at a time if needed.
Ok, I will split the %pIS change from this patch.
Thanks!
^ permalink raw reply
* Re: [Patch net-next v2 5/8] sunrpc: use generic union inet_addr
From: Cong Wang @ 2013-08-05 3:14 UTC (permalink / raw)
To: Jeff Layton
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller, Trond Myklebust,
J. Bruce Fields, linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130802093625.2c70a330-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On Fri, 2013-08-02 at 09:36 -0400, Jeff Layton wrote:
> On Fri, 2 Aug 2013 15:14:31 +0800
> Cong Wang <amwang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> > From: Cong Wang <amwang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >
> > sunrpc defines some helper functions for sockaddr, actually they
> > can re-use the generic functions for union inet_addr too.
>
> Only some of these patches in this series have made it to lists to
> which I'm subscribed, so I may be missing some context here...
>
> I'm not sure I really understand the value of "union inet_addr". Why
> not just use the conventional method of passing around "struct sockaddr"
> pointers, and then casting them to struct sockaddr_in/sockaddr_in6
> depending on what the sa_family is set to?
Yes.
>
> With that you wouldn't need to leave the (now pointless) rpc_* wrappers
> in place and could just call your new helpers directly.
>
J. Bruce asked the same question, see:
http://marc.info/?l=linux-nfs&m=137475685903460&w=2
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Cluster-devel] [Patch net-next v2 6/8] fs: use generic union inet_addr and helper functions
From: Cong Wang @ 2013-08-05 3:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-cifs-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
cluster-devel-H+wXaHxf7aLQT0dZR+AlfA, Trond Myklebust,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Steve French,
David S. Miller
In-Reply-To: <20130802103107.GA17244-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Fri, 2013-08-02 at 03:31 -0700, Christoph Hellwig wrote:
> On Fri, Aug 02, 2013 at 03:14:32PM +0800, Cong Wang wrote:
> > From: Cong Wang <amwang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >
> > nfs and cifs define some helper functions for sockaddr,
> > they can use the generic functions for union inet_addr too.
> >
> > Since some dlm code needs to compare ->sin_port, introduce a
> > generic function inet_addr_equal_strict() for it.
>
> Would sound more useful to have a sockaddr_equal case that can be used
> on any sockaddr. For cases that no current user handles just return
> false.
>
Ok, since you and other people ask for it.
Thanks.
^ permalink raw reply
* Re: [PATCH] hostap: do not return positive number on failure path in prism2_open()
From: Alexey Khoroshilov @ 2013-08-05 3:18 UTC (permalink / raw)
To: Jouni Malinen, John W. Linville
Cc: linux-wireless, netdev, linux-kernel, ldv-project
In-Reply-To: <1375671750-2835-1-git-send-email-khoroshilov@ispras.ru>
Please ignore this mail, there is a misprint in signed-off line.
I will resend the patch.
On 08/05/2013 07:02 AM, Alexey Khoroshilov wrote:
> prism2_open() as an .ndo_open handler should not return positive numbers
> in case of failure, but it does return 1 in a couple of places.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilorv@ispras.ru>
> ---
> drivers/net/wireless/hostap/hostap_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
> index 15f0fad..e4f56ad 100644
> --- a/drivers/net/wireless/hostap/hostap_main.c
> +++ b/drivers/net/wireless/hostap/hostap_main.c
> @@ -667,7 +667,7 @@ static int prism2_open(struct net_device *dev)
> if (local->no_pri) {
> printk(KERN_DEBUG "%s: could not set interface UP - no PRI "
> "f/w\n", dev->name);
> - return 1;
> + return -ENODEV;
> }
>
> if ((local->func->card_present && !local->func->card_present(local)) ||
> @@ -682,7 +682,7 @@ static int prism2_open(struct net_device *dev)
> printk(KERN_WARNING "%s: could not enable MAC port\n",
> dev->name);
> prism2_close(dev);
> - return 1;
> + return -ENODEV;
> }
> if (!local->dev_enabled)
> prism2_callback(local, PRISM2_CALLBACK_ENABLE);
^ permalink raw reply
* [PATCH] hostap: do not return positive number on failure path in prism2_open()
From: Alexey Khoroshilov @ 2013-08-05 3:18 UTC (permalink / raw)
To: Jouni Malinen, John W. Linville
Cc: Alexey Khoroshilov, linux-wireless, netdev, linux-kernel,
ldv-project
prism2_open() as an .ndo_open handler should not return positive numbers
in case of failure, but it does return 1 in a couple of places.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
drivers/net/wireless/hostap/hostap_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
index 15f0fad..e4f56ad 100644
--- a/drivers/net/wireless/hostap/hostap_main.c
+++ b/drivers/net/wireless/hostap/hostap_main.c
@@ -667,7 +667,7 @@ static int prism2_open(struct net_device *dev)
if (local->no_pri) {
printk(KERN_DEBUG "%s: could not set interface UP - no PRI "
"f/w\n", dev->name);
- return 1;
+ return -ENODEV;
}
if ((local->func->card_present && !local->func->card_present(local)) ||
@@ -682,7 +682,7 @@ static int prism2_open(struct net_device *dev)
printk(KERN_WARNING "%s: could not enable MAC port\n",
dev->name);
prism2_close(dev);
- return 1;
+ return -ENODEV;
}
if (!local->dev_enabled)
prism2_callback(local, PRISM2_CALLBACK_ENABLE);
--
1.8.1.2
^ permalink raw reply related
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