* Re: pull-request: can-next 2014-01-11
From: Marc Kleine-Budde @ 2014-01-14 20:31 UTC (permalink / raw)
To: Sergei Shtylyov, netdev
Cc: David Miller, linux-can@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <52D597B4.7020607@cogentembedded.com>
[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]
On 01/14/2014 09:01 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 01/11/2014 09:48 PM, Marc Kleine-Budde wrote:
>
>> Hello David,
>
>> this is a pull request of three patches for net-next/master.
>
>> Oleg Moroz added support for a new PCI card to the generic SJA1000 PCI
>> driver, Guenter Roeck's patch limits the flexcan driver to little
>> endian arm (and powerpc) and I fixed a sparse warning found by the
>> kbuild robot in the ti_hecc driver.
>
> What about the rewritten Renesas R-Car CAN driver? Is there a chance
> to get it into 3.14-rc1 now that we've missed 3.13-rc1? I've sent it at
> the very end of December, and have got no feedback still...
I was ill last week and as a customer today and tomorrow, I'll review
your driver this week.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]
^ permalink raw reply
* Re: [PATCH RFC] reciprocal_divide: correction/update of the algorithm
From: Hannes Frederic Sowa @ 2014-01-14 20:10 UTC (permalink / raw)
To: Eric Dumazet
Cc: Austin S Hemmelgarn, netdev, dborkman, linux-kernel, darkjames-ws
In-Reply-To: <1389729032.31367.262.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Jan 14, 2014 at 11:50:32AM -0800, Eric Dumazet wrote:
> On Tue, 2014-01-14 at 14:22 -0500, Austin S Hemmelgarn wrote:
>
> > I disagree with the statement that current CPU's have reasonably fast
> > dividers. A lot of embedded processors and many low-end x86 CPU's do
> > not in-fact have any hardware divider, and usually provide it using
> > microcode based emulation if they provide it at all. The AMD Jaguar
> > micro-architecture in particular comes to mind, it uses an iterative
> > division algorithm provided by the microcode that only produces 2 bits
> > of quotient per cycle, even in the best case (2 8-bit integers and an
> > integral 8-bit quotient) this still takes 4 cycles, which is twice as
> > slow as any other math operation on the same processor.
>
> I doubt you run any BPF filter with a divide instruction in it on these
> platform.
>
> Get real, do not over optimize things where it does not matter.
If I read the instruction tables correctly, we could half the latency with
reciprocal divide even on haswell.
What a pitty that the Intel Architecture Code Analyzer does not support imul
nor div instruction. :(
^ permalink raw reply
* Re: pull-request: can-next 2014-01-11
From: Sergei Shtylyov @ 2014-01-14 20:01 UTC (permalink / raw)
To: Marc Kleine-Budde, netdev
Cc: David Miller, linux-can@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <52D191E2.8040703@pengutronix.de>
Hello.
On 01/11/2014 09:48 PM, Marc Kleine-Budde wrote:
> Hello David,
> this is a pull request of three patches for net-next/master.
> Oleg Moroz added support for a new PCI card to the generic SJA1000 PCI
> driver, Guenter Roeck's patch limits the flexcan driver to little
> endian arm (and powerpc) and I fixed a sparse warning found by the
> kbuild robot in the ti_hecc driver.
What about the rewritten Renesas R-Car CAN driver? Is there a chance to
get it into 3.14-rc1 now that we've missed 3.13-rc1? I've sent it at the very
end of December, and have got no feedback still...
> regards,
> Marc
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] stmmac: Fix kernel crashes for jumbo frames
From: Ben Hutchings @ 2014-01-14 19:53 UTC (permalink / raw)
To: Vince Bridgers
Cc: devicetree, netdev, peppe.cavallaro, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, dinguyen, rayagond
In-Reply-To: <1389719859-29071-3-git-send-email-vbridgers2013@gmail.com>
On Tue, 2014-01-14 at 11:17 -0600, Vince Bridgers wrote:
> These changes correct the following issues with jumbo frames on the
> stmmac driver:
>
> 1) The Synopsys EMAC can be configured to support different FIFO
> sizes at core configuration time. There's no way to query the
> controller and know the FIFO size, so the driver needs to get this
> information from the device tree in order to know how to correctly
> handle MTU changes and setting up dma buffers. The default
> max-frame-size is as currently used, which is the size of a jumbo
> frame.
>
> 2) The driver was enabling Jumbo frames by default, but was not allocating
> dma buffers of sufficient size to handle the maximum possible packet
> size that could be received. This led to memory corruption since DMAs were
> occurring beyond the extent of the allocated receive buffers for certain types
> of network traffic.
[...]
> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> @@ -293,6 +293,8 @@ struct dma_features {
> #define STMMAC_CHAIN_MODE 0x1
> #define STMMAC_RING_MODE 0x2
>
> +#define JUMBO_LEN 9000
> +
> struct stmmac_desc_ops {
> /* DMA RX descriptor ring initialization */
> void (*init_rx_desc) (struct dma_desc *p, int disable_rx_ic, int mode,
[...]
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -51,6 +51,10 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
> plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
> sizeof(struct stmmac_mdio_bus_data),
> GFP_KERNEL);
> + /* Set the maxmtu to a default of 1500 in case the
> + * parameter is not present in the device tree
> + */
> + plat->maxmtu = JUMBO_LEN;
The comment disagrees with the definition of JUMBO_LEN.
>
> /*
> * Currently only the properties needed on SPEAr600
> @@ -60,6 +64,7 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
> if (of_device_is_compatible(np, "st,spear600-gmac") ||
> of_device_is_compatible(np, "snps,dwmac-3.70a") ||
> of_device_is_compatible(np, "snps,dwmac")) {
> + of_property_read_u32(np, "max-frame-size", &plat->maxmtu);
[...]
Is it the maximum frame size, including Ethernet header? (And then, is
the CRC or any VLAN header included in the frame size?)
Or is it the MTU, excluding all of those?
You really need to be very clear about what this number represents.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH RFC] reciprocal_divide: correction/update of the algorithm
From: Eric Dumazet @ 2014-01-14 19:50 UTC (permalink / raw)
To: Austin S Hemmelgarn
Cc: Hannes Frederic Sowa, netdev, dborkman, linux-kernel,
darkjames-ws
In-Reply-To: <52D58E6F.4050000@gmail.com>
On Tue, 2014-01-14 at 14:22 -0500, Austin S Hemmelgarn wrote:
> I disagree with the statement that current CPU's have reasonably fast
> dividers. A lot of embedded processors and many low-end x86 CPU's do
> not in-fact have any hardware divider, and usually provide it using
> microcode based emulation if they provide it at all. The AMD Jaguar
> micro-architecture in particular comes to mind, it uses an iterative
> division algorithm provided by the microcode that only produces 2 bits
> of quotient per cycle, even in the best case (2 8-bit integers and an
> integral 8-bit quotient) this still takes 4 cycles, which is twice as
> slow as any other math operation on the same processor.
I doubt you run any BPF filter with a divide instruction in it on these
platform.
Get real, do not over optimize things where it does not matter.
^ permalink raw reply
* [PATCH v2 net-next] stmmac: Add vlan rx for better GRO performance.
From: Vince Bridgers @ 2014-01-14 19:42 UTC (permalink / raw)
To: netdev; +Cc: peppe.cavallaro, rayagond, vbridgers2013
GRO requires VLANs to be removed before aggregation can occur.
The Synopsys EMAC does not strip VLAN tags so this must be
done by the driver.
Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
---
V2: remove inline on added function, line up broken lines per review comments
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b8e3a4c..ecdc8ab 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1951,6 +1951,23 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
}
+static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
+{
+ struct ethhdr *ehdr;
+ u16 vlanid;
+
+ if ((dev->features & NETIF_F_HW_VLAN_CTAG_RX) ==
+ NETIF_F_HW_VLAN_CTAG_RX &&
+ !__vlan_get_tag(skb, &vlanid)) {
+ /* pop the vlan tag */
+ ehdr = (struct ethhdr *)skb->data;
+ memmove(skb->data + VLAN_HLEN, ehdr, ETH_ALEN * 2);
+ skb_pull(skb, VLAN_HLEN);
+ __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlanid);
+ }
+}
+
+
/**
* stmmac_rx_refill: refill used skb preallocated buffers
* @priv: driver private structure
@@ -2102,6 +2119,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit)
print_pkt(skb->data, frame_len);
}
+ stmmac_rx_vlan(priv->dev, skb);
+
skb->protocol = eth_type_trans(skb, priv->dev);
if (unlikely(!coe))
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/2] net/mlx4_core: clean up srq_res_start_move_to()
From: Paul Bolle @ 2014-01-14 19:46 UTC (permalink / raw)
To: Or Gerlitz, Jack Morgenstein, Rony Efraim, Hadar Hen Zion,
David S. Miller
Cc: netdev, linux-kernel
In-Reply-To: <20140114084050.70a612af@jpm-OptiPlex-GX620>
Building resource_tracker.o triggers a GCC warning:
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_HW2SW_SRQ_wrapper':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3202:17: warning: 'srq' may be used uninitialized in this function [-Wmaybe-uninitialized]
atomic_dec(&srq->mtt->ref_count);
^
This is a false positive. But a cleanup of srq_res_start_move_to() can
help GCC here. The code currently uses a switch statement where a plain
if/else would do, since only two of the switch's four cases can ever
occur. Dropping that switch makes the warning go away.
While we're at it, add some missing braces, and convert state to the
correct type.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
v2: adjust to Jack's review.
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 46 ++++++++--------------
1 file changed, 16 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 15cd659..4acd84c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -1371,7 +1371,7 @@ static int cq_res_start_move_to(struct mlx4_dev *dev, int slave, int cqn,
}
static int srq_res_start_move_to(struct mlx4_dev *dev, int slave, int index,
- enum res_cq_states state, struct res_srq **srq)
+ enum res_srq_states state, struct res_srq **srq)
{
struct mlx4_priv *priv = mlx4_priv(dev);
struct mlx4_resource_tracker *tracker = &priv->mfunc.master.res_tracker;
@@ -1380,39 +1380,25 @@ static int srq_res_start_move_to(struct mlx4_dev *dev, int slave, int index,
spin_lock_irq(mlx4_tlock(dev));
r = res_tracker_lookup(&tracker->res_tree[RES_SRQ], index);
- if (!r)
+ if (!r) {
err = -ENOENT;
- else if (r->com.owner != slave)
+ } else if (r->com.owner != slave) {
err = -EPERM;
- else {
- switch (state) {
- case RES_SRQ_BUSY:
- err = -EINVAL;
- break;
-
- case RES_SRQ_ALLOCATED:
- if (r->com.state != RES_SRQ_HW)
- err = -EINVAL;
- else if (atomic_read(&r->ref_count))
- err = -EBUSY;
- break;
-
- case RES_SRQ_HW:
- if (r->com.state != RES_SRQ_ALLOCATED)
- err = -EINVAL;
- break;
-
- default:
+ } else if (state == RES_SRQ_ALLOCATED) {
+ if (r->com.state != RES_SRQ_HW)
err = -EINVAL;
- }
+ else if (atomic_read(&r->ref_count))
+ err = -EBUSY;
+ } else if (state != RES_SRQ_HW || r->com.state != RES_SRQ_ALLOCATED) {
+ err = -EINVAL;
+ }
- if (!err) {
- r->com.from_state = r->com.state;
- r->com.to_state = state;
- r->com.state = RES_SRQ_BUSY;
- if (srq)
- *srq = r;
- }
+ if (!err) {
+ r->com.from_state = r->com.state;
+ r->com.to_state = state;
+ r->com.state = RES_SRQ_BUSY;
+ if (srq)
+ *srq = r;
}
spin_unlock_irq(mlx4_tlock(dev));
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 1/2] net/mlx4_core: clean up cq_res_start_move_to()
From: Paul Bolle @ 2014-01-14 19:45 UTC (permalink / raw)
To: Or Gerlitz, Jack Morgenstein, Rony Efraim, Hadar Hen Zion,
David S. Miller
Cc: netdev, linux-kernel
In-Reply-To: <20140114084752.1db64b21@jpm-OptiPlex-GX620>
Building resource_tracker.o triggers a GCC warning:
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_HW2SW_CQ_wrapper':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3019:16: warning: 'cq' may be used uninitialized in this function [-Wmaybe-uninitialized]
atomic_dec(&cq->mtt->ref_count);
^
This is a false positive. But a cleanup of cq_res_start_move_to() can
help GCC here. The code currently uses a switch statement where an
if/else construct would do too, since only two of the switch's four
cases can ever occur. Dropping that switch makes the warning go away.
While we're at it, add some missing braces.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
v2: adjust to Jack's review.
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 52 ++++++++--------------
1 file changed, 19 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 2f3f2bc..15cd659 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -1340,43 +1340,29 @@ static int cq_res_start_move_to(struct mlx4_dev *dev, int slave, int cqn,
spin_lock_irq(mlx4_tlock(dev));
r = res_tracker_lookup(&tracker->res_tree[RES_CQ], cqn);
- if (!r)
+ if (!r) {
err = -ENOENT;
- else if (r->com.owner != slave)
+ } else if (r->com.owner != slave) {
err = -EPERM;
- else {
- switch (state) {
- case RES_CQ_BUSY:
- err = -EBUSY;
- break;
-
- case RES_CQ_ALLOCATED:
- if (r->com.state != RES_CQ_HW)
- err = -EINVAL;
- else if (atomic_read(&r->ref_count))
- err = -EBUSY;
- else
- err = 0;
- break;
-
- case RES_CQ_HW:
- if (r->com.state != RES_CQ_ALLOCATED)
- err = -EINVAL;
- else
- err = 0;
- break;
-
- default:
+ } else if (state == RES_CQ_ALLOCATED) {
+ if (r->com.state != RES_CQ_HW)
err = -EINVAL;
- }
+ else if (atomic_read(&r->ref_count))
+ err = -EBUSY;
+ else
+ err = 0;
+ } else if (state != RES_CQ_HW || r->com.state != RES_CQ_ALLOCATED) {
+ err = -EINVAL;
+ } else {
+ err = 0;
+ }
- if (!err) {
- r->com.from_state = r->com.state;
- r->com.to_state = state;
- r->com.state = RES_CQ_BUSY;
- if (cq)
- *cq = r;
- }
+ if (!err) {
+ r->com.from_state = r->com.state;
+ r->com.to_state = state;
+ r->com.state = RES_CQ_BUSY;
+ if (cq)
+ *cq = r;
}
spin_unlock_irq(mlx4_tlock(dev));
--
1.8.4.2
^ permalink raw reply related
* Re: [RFC] sysfs_rename_link() and its usage
From: Greg KH @ 2014-01-14 19:31 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: linux-kernel, netdev, ebiederm
In-Reply-To: <20140114191208.GA9942@redhat.com>
On Tue, Jan 14, 2014 at 08:12:08PM +0100, Veaceslav Falico wrote:
> On Tue, Jan 14, 2014 at 10:21:35AM -0800, Greg KH wrote:
> >On Tue, Jan 14, 2014 at 06:17:40PM +0100, Veaceslav Falico wrote:
> >>Hi,
> >>
> >>I'm hitting a strange issue and/or I'm completely lost in sysfs internals.
> >>
> >>Consider having two net_device *a, *b; which are registered normally.
> >>Now, to create a link from /sys/class/net/a->name/linkname to b, one should
> >>use:
> >>
> >>sysfs_create_link(&(a->dev.kobj), &(b->dev.kobj), linkname);
> >>
> >>To remove it, even simpler:
> >>
> >>sysfs_remove_link(&(a->dev.kobj), linkname);
> >>
> >>This works like a charm. However, if I want to use (obviously, with the
> >>symlink present):
> >>
> >>sysfs_rename_link(&(a->dev.kobj), &(b->dev.kobj), oldname, newname);
> >
> >You forgot the namespace option to this call, what kernel version are
> >you using here?
>
> It's git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next ,
> 3.13-rc6 with some networking patches on top of it.
>
> And wrt namespace - there are two functions, one is sysfs_rename_link(),
> which calls the second one - sysfs_rename_link_ns() with NULL namespace.
>
> >
> >>this fails with:
> >>
> >>"sysfs: ns invalid in 'a->name' for 'oldname'"
> >
> >Looks like the namespace for this link isn't valid.
>
> Yep, though dunno why.
Are you testing this with network namespaces enabled? Perhaps that is
why, you need to specify the namespace of the link that you are
changing.
The fact that the bridge link works is odd to me, I would think that it
too needs to specify the network namespace involved, but perhaps bridge
objects aren't part of any specific network namespace? I don't know the
bridging code at all, sorry.
So try calling sysfs_rename_link_ns() and specify the namespace of the
kobject you are changing, and see if that works or not.
thanks,
greg k-h
^ permalink raw reply
* [net PATCH 1/1] qlge: Fix vlan netdev features.
From: Jitendra Kalsaria @ 2014-01-14 18:57 UTC (permalink / raw)
To: davem
Cc: netdev, ron.mercer, shahed.shaikh, Dept-HSGLinuxNICDev,
Jitendra Kalsaria
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
vlan gets the same netdev features except vlan filter.
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
---
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_main.c b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
index 449f506..f705aee 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_main.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
@@ -4765,6 +4765,8 @@ static int qlge_probe(struct pci_dev *pdev,
NETIF_F_RXCSUM;
ndev->features = ndev->hw_features;
ndev->vlan_features = ndev->hw_features;
+ /* vlan gets same features (except vlan filter) */
+ ndev->vlan_features &= ~NETIF_F_HW_VLAN_CTAG_FILTER;
if (test_bit(QL_DMA64, &qdev->flags))
ndev->features |= NETIF_F_HIGHDMA;
--
1.7.6.rc1.1.g2c162b
^ permalink raw reply related
* [PATCH net-next] xen-netback: Rework rx_work_todo
From: Zoltan Kiss @ 2014-01-14 19:28 UTC (permalink / raw)
To: ian.campbell, wei.liu2, xen-devel, netdev, linux-kernel,
jonathan.davies
Cc: Zoltan Kiss
The recent patch to fix receive side flow control (11b57f) solved the spinning
thread problem, however caused an another one. The receive side can stall, if:
- xenvif_rx_action sets rx_queue_stopped to false
- interrupt happens, and sets rx_event to true
- then xenvif_kthread sets rx_event to false
Also, through rx_event a malicious guest can force the RX thread to spin. This
patch ditch that two variable, and rework rx_work_todo. If the thread finds it
can't fit more skb's into the ring, it saves the last slot estimation into
rx_last_skb_slots, otherwise it's kept as 0. Then rx_work_todo will check if:
- there is something to send to the ring
- there is space for the topmost packet in the queue
Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
---
drivers/net/xen-netback/common.h | 6 +-----
drivers/net/xen-netback/interface.c | 1 -
drivers/net/xen-netback/netback.c | 16 ++++++----------
3 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 4c76bcb..ae413a2 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -143,11 +143,7 @@ struct xenvif {
char rx_irq_name[IFNAMSIZ+4]; /* DEVNAME-rx */
struct xen_netif_rx_back_ring rx;
struct sk_buff_head rx_queue;
- bool rx_queue_stopped;
- /* Set when the RX interrupt is triggered by the frontend.
- * The worker thread may need to wake the queue.
- */
- bool rx_event;
+ RING_IDX rx_last_skb_slots;
/* This array is allocated seperately as it is large */
struct gnttab_copy *grant_copy_op;
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b9de31e..7669d49 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -100,7 +100,6 @@ static irqreturn_t xenvif_rx_interrupt(int irq, void *dev_id)
{
struct xenvif *vif = dev_id;
- vif->rx_event = true;
xenvif_kick_thread(vif);
return IRQ_HANDLED;
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2738563..bb241d0 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -477,7 +477,6 @@ static void xenvif_rx_action(struct xenvif *vif)
unsigned long offset;
struct skb_cb_overlay *sco;
bool need_to_notify = false;
- bool ring_full = false;
struct netrx_pending_operations npo = {
.copy = vif->grant_copy_op,
@@ -487,7 +486,7 @@ static void xenvif_rx_action(struct xenvif *vif)
skb_queue_head_init(&rxq);
while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
- int max_slots_needed;
+ RING_IDX max_slots_needed;
int i;
/* We need a cheap worse case estimate for the number of
@@ -510,9 +509,10 @@ static void xenvif_rx_action(struct xenvif *vif)
if (!xenvif_rx_ring_slots_available(vif, max_slots_needed)) {
skb_queue_head(&vif->rx_queue, skb);
need_to_notify = true;
- ring_full = true;
+ vif->rx_last_skb_slots = max_slots_needed;
break;
- }
+ } else
+ vif->rx_last_skb_slots = 0;
sco = (struct skb_cb_overlay *)skb->cb;
sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
@@ -523,8 +523,6 @@ static void xenvif_rx_action(struct xenvif *vif)
BUG_ON(npo.meta_prod > ARRAY_SIZE(vif->meta));
- vif->rx_queue_stopped = !npo.copy_prod && ring_full;
-
if (!npo.copy_prod)
goto done;
@@ -1727,8 +1725,8 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
static inline int rx_work_todo(struct xenvif *vif)
{
- return (!skb_queue_empty(&vif->rx_queue) && !vif->rx_queue_stopped) ||
- vif->rx_event;
+ return !skb_queue_empty(&vif->rx_queue) &&
+ xenvif_rx_ring_slots_available(vif, vif->rx_last_skb_slots);
}
static inline int tx_work_todo(struct xenvif *vif)
@@ -1814,8 +1812,6 @@ int xenvif_kthread(void *data)
if (!skb_queue_empty(&vif->rx_queue))
xenvif_rx_action(vif);
- vif->rx_event = false;
-
if (skb_queue_empty(&vif->rx_queue) &&
netif_queue_stopped(vif->dev))
xenvif_start_queue(vif);
^ permalink raw reply related
* Re: [PATCH RFC] reciprocal_divide: correction/update of the algorithm
From: Austin S Hemmelgarn @ 2014-01-14 19:22 UTC (permalink / raw)
To: Eric Dumazet, Hannes Frederic Sowa
Cc: netdev, dborkman, linux-kernel, darkjames-ws
In-Reply-To: <1389722825.31367.260.camel@edumazet-glaptop2.roam.corp.google.com>
On 2014-01-14 13:07, Eric Dumazet wrote:
> On Mon, 2014-01-13 at 22:42 +0100, Hannes Frederic Sowa wrote:
>> This patch is a RFC and part of a series Daniel Borkmann and me want to
>> do when introducing prandom_u32_range{,_ro} and prandom_u32_max{,_ro}
>> helpers later this week.
>
>> -static inline u32 reciprocal_divide(u32 A, u32 R)
>> +struct reciprocal_value reciprocal_value(u32 d);
>> +
>> +static inline u32 reciprocal_divide(u32 a, struct reciprocal_value R)
>> {
>> - return (u32)(((u64)A * R) >> 32);
>> + u32 t = (u32)(((u64)a * R.m) >> 32);
>> + return (t + ((a - t) >> R.sh1)) >> R.sh2;
>> }
>
> I would rather introduce new helpers and convert users that really need
> them.
>
> For instance, just use a divide in BPF, because doing this on JIT might
> be too complex for the gains. Strangely, libpcap doesn't seem to
> optimize any divide, like divides by a power of two...
>
> Reciprocal were added 7 years ago, for very specific uses, but current
> cpus have reasonably fast dividers.
I disagree with the statement that current CPU's have reasonably fast
dividers. A lot of embedded processors and many low-end x86 CPU's do
not in-fact have any hardware divider, and usually provide it using
microcode based emulation if they provide it at all. The AMD Jaguar
micro-architecture in particular comes to mind, it uses an iterative
division algorithm provided by the microcode that only produces 2 bits
of quotient per cycle, even in the best case (2 8-bit integers and an
integral 8-bit quotient) this still takes 4 cycles, which is twice as
slow as any other math operation on the same processor.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: rename sysfs symlinks on device name change
From: Veaceslav Falico @ 2014-01-14 19:14 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, Ding Tianhong, David S. Miller, Eric Dumazet,
Nicolas Dichtel
In-Reply-To: <CAHA+R7N=iFAGqoRuL8HD3SnkmH-dMPpUCkrJkLEGd1SPTbe4Kw@mail.gmail.com>
On Tue, Jan 14, 2014 at 10:30:56AM -0800, Cong Wang wrote:
>On Tue, Jan 14, 2014 at 8:36 AM, Veaceslav Falico <vfalico@redhat.com> wrote:
>> +void netdev_adjacent_rename_links(struct net_device *dev, char *oldname)
>> +{
>> + struct netdev_adjacent *iter;
>> +
>> + list_for_each_entry(iter, &dev->adj_list.upper, list) {
>> + netdev_adjacent_sysfs_del(iter->dev, oldname,
>> + &iter->dev->adj_list.lower);
>> + netdev_adjacent_sysfs_add(iter->dev, dev,
>> + &iter->dev->adj_list.lower);
>> + }
>> +
>> + list_for_each_entry(iter, &dev->adj_list.lower, list) {
>> + netdev_adjacent_sysfs_del(iter->dev, oldname,
>> + &iter->dev->adj_list.upper);
>> + netdev_adjacent_sysfs_add(iter->dev, dev,
>> + &iter->dev->adj_list.upper);
>> + }
>> +}
>> +EXPORT_SYMBOL(netdev_adjacent_rename_links);
>
>Since it is only used within net/core/dev.c, why do you make it extern
>and export it? It can become static.
Hm, good point, exported it automatically, didn't realise that dev_rename()
is also in dev.c.
Will send v2.
^ permalink raw reply
* Re: [RFC] sysfs_rename_link() and its usage
From: Veaceslav Falico @ 2014-01-14 19:12 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, netdev, ebiederm
In-Reply-To: <20140114182135.GA29296@kroah.com>
On Tue, Jan 14, 2014 at 10:21:35AM -0800, Greg KH wrote:
>On Tue, Jan 14, 2014 at 06:17:40PM +0100, Veaceslav Falico wrote:
>> Hi,
>>
>> I'm hitting a strange issue and/or I'm completely lost in sysfs internals.
>>
>> Consider having two net_device *a, *b; which are registered normally.
>> Now, to create a link from /sys/class/net/a->name/linkname to b, one should
>> use:
>>
>> sysfs_create_link(&(a->dev.kobj), &(b->dev.kobj), linkname);
>>
>> To remove it, even simpler:
>>
>> sysfs_remove_link(&(a->dev.kobj), linkname);
>>
>> This works like a charm. However, if I want to use (obviously, with the
>> symlink present):
>>
>> sysfs_rename_link(&(a->dev.kobj), &(b->dev.kobj), oldname, newname);
>
>You forgot the namespace option to this call, what kernel version are
>you using here?
It's git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next ,
3.13-rc6 with some networking patches on top of it.
And wrt namespace - there are two functions, one is sysfs_rename_link(),
which calls the second one - sysfs_rename_link_ns() with NULL namespace.
>
>> this fails with:
>>
>> "sysfs: ns invalid in 'a->name' for 'oldname'"
>
>Looks like the namespace for this link isn't valid.
Yep, though dunno why.
>
>> in
>>
>> 608 struct sysfs_dirent *sysfs_find_dirent(struct sysfs_dirent *parent_sd,
>> ...
>> 615 if (!!sysfs_ns_type(parent_sd) != !!ns) {
>> 616 WARN(1, KERN_WARNING "sysfs: ns %s in '%s' for '%s'\n",
>> 617 sysfs_ns_type(parent_sd) ? "required" : "invalid",
>> 618 parent_sd->s_name, name);
>> 619 return NULL;
>> 620 }
>>
>> Code path:
>> warn_slowpath_fmt+0x46/0x50
>> sysfs_get_dirent_ns+0x30/0x80
>> sysfs_find_dirent+0x84/0x110
>> sysfs_get_dirent_ns+0x3e/0x80
>> sysfs_rename_link_ns+0x54/0xd0
>>
>> I have no idea what this code means. Is there any reason for it to
>> fail (i.e. am I doing something wrong?) or I've hit a bug?
>
>What exactly are you trying to do here? Care to provide a pointer to
>your code somewhere?
I've tried to handle the network device renames, ended up doing it with
sysfs_remove/add_link() calls. Patches:
http://patchwork.ozlabs.org/patch/310798/
http://patchwork.ozlabs.org/patch/310796/
If an upper device (say, vlan, bonding, bridge etc.) enslaves another
device, symlinks are created (given bridge0 and eth0):
/sys/class/net/eth0/upper_bridge0 -> ../bridge0
/sys/class/net/bridge0/lower_eth0 -> ../eth0
However, in case someone renames eth0/bridge0, these symlinks should also
be renamed, and sysfs_rename_link() should fit great here. But it fails.
>
>> I've tested the only user of it (bridge) - and it works fine, however it's
>> not using its own net_device's kobject but rather its own dir.
>
>The driver core also uses this function, and it works there, so I'd
>blame your code :)
Yeah, I'd also like to blame it, I'm afraid of touching anything
sysfs-related :).
>
>thanks,
>
>greg k-h
^ permalink raw reply
* Re: [PATCHv2 net-next 3/4] flowcache: Fixup flow cache part in xfrm policy
From: Sabrina Dubroca @ 2014-01-14 18:59 UTC (permalink / raw)
To: Fan Du; +Cc: steffen.klassert, davem, netdev
In-Reply-To: <1389663588-29678-4-git-send-email-fan.du@windriver.com>
2014-01-14, 09:39:46 +0800, Fan Du wrote:
> Bump flow cache genid, and flush flow cache should also be made
> in per net style.
>
> Signed-off-by: Fan Du <fan.du@windriver.com>
> ---
> net/xfrm/xfrm_policy.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> index e205c4b..d39c90f 100644
> --- a/net/xfrm/xfrm_policy.c
> +++ b/net/xfrm/xfrm_policy.c
> @@ -661,7 +661,7 @@ int xfrm_policy_insert(int dir, struct xfrm_policy *policy, int excl)
> hlist_add_head(&policy->bydst, chain);
> xfrm_pol_hold(policy);
> net->xfrm.policy_count[dir]++;
> - atomic_inc(&flow_cache_genid);
> + atomic_inc(&net->xfrm.flow_cache_genid);
>
> /* After previous checking, family can either be AF_INET or AF_INET6 */
> if (policy->family == AF_INET)
> @@ -2567,14 +2567,14 @@ static void __xfrm_garbage_collect(struct net *net)
>
> void xfrm_garbage_collect(struct net *net)
> {
> - flow_cache_flush();
> + flow_cache_flush(net);
> __xfrm_garbage_collect(net);
> }
> EXPORT_SYMBOL(xfrm_garbage_collect);
>
> static void xfrm_garbage_collect_deferred(struct net *net)
> {
> - flow_cache_flush_deferred();
> + flow_cache_flush_deferred(net);
> __xfrm_garbage_collect(net);
> }
>
> @@ -2947,6 +2947,7 @@ static int __net_init xfrm_net_init(struct net *net)
> spin_lock_init(&net->xfrm.xfrm_policy_sk_bundle_lock);
> mutex_init(&net->xfrm.xfrm_cfg_mutex);
>
> + flow_cache_init(net);
> return 0;
>
> out_sysctl:
You didn't address Cong Wang's comments for v1:
2014-01-13, 11:42:47 -0800, Cong Wang wrote:
> On Sun, Jan 12, 2014 at 11:49 PM, Fan Du <fan.du@windriver.com> wrote:
> > void xfrm_garbage_collect(struct net *net)
> > {
> > - flow_cache_flush();
> > + flow_cache_flush(net);
> > __xfrm_garbage_collect(net);
> > }
> > EXPORT_SYMBOL(xfrm_garbage_collect);
> >
> > static void xfrm_garbage_collect_deferred(struct net *net)
> > {
> > - flow_cache_flush_deferred();
> > + flow_cache_flush_deferred(net);
> > __xfrm_garbage_collect(net);
> > }
> >
>
> You changed the prototypes of flow_cache_flush*() in the previous
> patch, so, here you break bisect. They have to be in one commit.
--
Sabrina
^ permalink raw reply
* Re: [Patch net-next 6/7] net_sched: cls: move allocation in ->init to generic layer
From: Cong Wang @ 2014-01-14 18:57 UTC (permalink / raw)
To: David Miller
Cc: Linux Kernel Network Developers, Thomas Graf, Jamal Hadi Salim
In-Reply-To: <20140113.114923.2164522715863402981.davem@davemloft.net>
On Mon, Jan 13, 2014 at 11:49 AM, David Miller <davem@davemloft.net> wrote:
>
> What I'm going to do for now is apply patches 1-5 and 7.
>
Sounds good to me. I will re-work on it.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next v2] openvswitch: Pad OVS_PACKET_ATTR_PACKET if linear copy was performed
From: Zoltan Kiss @ 2014-01-14 18:56 UTC (permalink / raw)
To: Thomas Graf
Cc: Thomas Graf, Jesse Gross, David Miller, dev@openvswitch.org,
netdev
In-Reply-To: <20140114162749.GC24121@casper.infradead.org>
It works for me, thanks!
Acked-by: Zoltan Kiss <zoltan.kiss@citrix.com>
On 14/01/14 16:27, Thomas Graf wrote:
> While the zerocopy method is correctly omitted if user space
> does not support unaligned Netlink messages. The attribute is
> still not padded correctly as skb_zerocopy() will not ensure
> padding and the attribute size is no longer pre calculated
> though nla_reserve() which ensured padding previously.
>
> This patch applies appropriate padding if a linear data copy
> was performed in skb_zerocopy().
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> ---
> v2: initialize padding to 0's
>
> net/openvswitch/datapath.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index df46928..3ca9121 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -396,7 +396,7 @@ static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb,
> .dst_sk = ovs_dp_get_net(dp)->genl_sock,
> .snd_portid = upcall_info->portid,
> };
> - size_t len;
> + size_t len, plen;
> unsigned int hlen;
> int err, dp_ifindex;
>
> @@ -466,6 +466,11 @@ static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb,
>
> skb_zerocopy(user_skb, skb, skb->len, hlen);
>
> + /* Pad OVS_PACKET_ATTR_PACKET if linear copy was performed */
> + if (!(dp->user_features & OVS_DP_F_UNALIGNED) &&
> + (plen = (ALIGN(user_skb->len, NLA_ALIGNTO) - user_skb->len)) > 0)
> + memset(skb_put(user_skb, plen), 0, plen);
> +
> ((struct nlmsghdr *) user_skb->data)->nlmsg_len = user_skb->len;
>
> err = genlmsg_unicast(ovs_dp_get_net(dp), user_skb, upcall_info->portid);
>
^ permalink raw reply
* Re: [Patch net-next 6/7] net_sched: cls: move allocation in ->init to generic layer
From: Cong Wang @ 2014-01-14 18:56 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Linux Kernel Network Developers, Thomas Graf, David S. Miller
In-Reply-To: <52D293A2.2070703@mojatatu.com>
On Sun, Jan 12, 2014 at 5:07 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 01/09/14 19:14, Cong Wang wrote:
>>
>> Most of the filters need allocation of tp->root in ->init()
>> and free it in ->destroy(), make this generic.
>>
>> Also we could reduce the use of tcf_tree_lock a bit.
>>
>> Cc: Thomas Graf <tgraf@suug.ch>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>
>
>
> Hrm. This one worries me a little.
> I dont see how just pre-allocing the private head of the classifier
> magically allows you to get rid of locks. Have you tested against those
> classifiers you changed?
> If those locks are useless - then that is a separate patch to kill
> them (sorry, dont have time to test myself right now).
Yeah, I am not sure either. I will re-think about this locking stuff.
^ permalink raw reply
* Re: [Patch net-next 0/7] net_sched: some more cleanup and improvements
From: Cong Wang @ 2014-01-14 18:54 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: Linux Kernel Network Developers, David S. Miller
In-Reply-To: <52D28B77.7030000@mojatatu.com>
On Sun, Jan 12, 2014 at 4:32 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 01/09/14 19:13, Cong Wang wrote:
>>
>> This patchset collects the previous patches I sent which Jamal doesn't
>> object.
>> They are still some cleanup and improvements for tc actions and filters.
>>
>>
>
> Cong - I dont have time to test at the moment and like you said
> they dont look controversial; i will review them, please try to test
> them to the best you can.
>
I did and I will continue to test them in net-next.
Thanks for reviews!
^ permalink raw reply
* Re: [PATCHv2 net-next 1/4] flowcache: Namespacify flowcache global parameters with xfrm
From: Sabrina Dubroca @ 2014-01-14 18:53 UTC (permalink / raw)
To: Fan Du; +Cc: steffen.klassert, davem, netdev
In-Reply-To: <1389663588-29678-2-git-send-email-fan.du@windriver.com>
2014-01-14, 09:39:44 +0800, Fan Du wrote:
> Since flowcache is tightly coupled with IPsec, so it would be
> easier to put flow cache global parameters here into xfrm
> namespace part.
>
> Signed-off-by: Fan Du <fan.du@windriver.com>
> ---
> include/net/netns/xfrm.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/net/netns/xfrm.h b/include/net/netns/xfrm.h
> index 1006a26..52d0086 100644
> --- a/include/net/netns/xfrm.h
> +++ b/include/net/netns/xfrm.h
> @@ -6,6 +6,7 @@
> #include <linux/workqueue.h>
> #include <linux/xfrm.h>
> #include <net/dst_ops.h>
> +#include <net/flowcache.h>
You are including a file that doesn't exist yet. You create it later,
with patch 2. This breaks bisection.
--
Sabrina
^ permalink raw reply
* Re: [PATCH] [RFC] netfilter: nf_conntrack: don't relase a conntrack with non-zero refcnt
From: Florian Westphal @ 2014-01-14 18:53 UTC (permalink / raw)
To: Andrey Vagin
Cc: netfilter-devel, Eric Dumazet, netfilter, netdev, linux-kernel,
vvs, Florian Westphal, Cyrill Gorcunov, Vasiliy Averin
In-Reply-To: <1389720948-7883-1-git-send-email-avagin@openvz.org>
Andrey Vagin <avagin@openvz.org> wrote:
> ----
> Eric and Florian, could you look at this patch. When you say,
> that it looks good, I will ask the user to validate it.
> I can't reorder these actions, because it's reproduced on a real host
> with real users. Thanks.
> ----
>
> nf_conntrack_free can't be called for a conntract with non-zero ref-counter,
> because it can race with nf_conntrack_find_get().
Indeed.
> A conntrack slab is created with SLAB_DESTROY_BY_RCU. Non-zero
> ref-conunter says that this conntrack is used now. So when we release a
> conntrack with non-zero counter, we break this assumption.
>
> CPU1 CPU2
> ____nf_conntrack_find()
> nf_ct_put()
> destroy_conntrack()
> ...
> init_conntrack
> __nf_conntrack_alloc (set use = 1)
> atomic_inc_not_zero(&ct->use) (use = 2)
> if (!l4proto->new(ct, skb, dataoff, timeouts))
> nf_conntrack_free(ct); (use = 2 !!!)
> ...
Yes, I think this sequence is possible; we must not use nf_conntrack_free here.
> - /* We overload first tuple to link into unconfirmed or dying list.*/
> - BUG_ON(hlist_nulls_unhashed(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode));
> - hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);
> + if (!hlist_nulls_unhashed(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode))
> + hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);
This is the only thing that I don't like about this patch. Currently
all the conntracks in the system are always put on a list before they're
supposed to be visible/handled via refcnt system (unconfirmed, hash, or
dying list).
I think it would be nice if we could keep it that way.
If everything fails we could proably intoduce a 'larval' dummy list
similar to the one used by template conntracks?
^ permalink raw reply
* Re: [PATCH] usbnet: Fix dma setup for fragmented packets that need a pad byte appended.
From: Bjørn Mork @ 2014-01-14 18:51 UTC (permalink / raw)
To: David Laight; +Cc: 'Eric Dumazet', netdev
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D45B744@AcuExch.aculab.com>
David Laight <David.Laight@ACULAB.COM> writes:
> From: Bjørn Mork [mailto:bjorn@mork.no]
>> David Laight <David.Laight@ACULAB.COM> writes:
>>
>> > I couldn't find the original patch anywhere!
>> > I did do quite a lot of looking as well - if I'd found it I've
>> > have done something else.
>>
>> You obviously haven't looked the one place you are supposed to always
>> look before submitting *anything*:
>> https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=fdc3452cd2c7b2bfe0f378f92123f4f9
>> a98fa2bd
>>
>> I am not impressed...
>
> Without the commit id that is rather hard.
I suggest you stop this nonsense now.
If you are going to submit a patch for "net", then the last thing you do
is check out net/master and rebase on top of it. If you had done so,
then you would have noticed the conflict. You never need to know the
commit id. Where the heck do you think I got it?
> Does anything even get there without manual actions.
> usb patches sit in a hidden limbo for ages.
>
> I looked through my mailboxes and searched for the thread - but only
> found the messages that included the one that said you'd send a patch
> soon.
>
> What I still don't understand is how I found the patch before!
Does it matter? You obviously knew you were posting a duplicate. There
is no excuse for that. Duplicates do *not* help. Whether you are able
to find the original or not doesn't matter. The rest of the world is.
Duplicate are confusing. Confusion cause delays and noise. I assume
you don't want either.
> The fact that work make me use outluck makes searching mail locally
> almost impossible.
Your lack of proper tools is your problem...
Now I know I come out a bit harsh. I can't help it. It's not that I
care much about whether or not I am credited for this oneliner, and you
did credit me in any case. But this whole discussion is so completely
unnecessary. Just use patchwork to track the status of patches you are
interested in. If you can't find a patch there, then YOU are doing
something wrong. It's as simple as that. No excuse.
Bjørn
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: rename sysfs symlinks on device name change
From: Cong Wang @ 2014-01-14 18:30 UTC (permalink / raw)
To: Veaceslav Falico
Cc: netdev, Ding Tianhong, David S. Miller, Eric Dumazet,
Nicolas Dichtel
In-Reply-To: <1389717360-13920-3-git-send-email-vfalico@redhat.com>
On Tue, Jan 14, 2014 at 8:36 AM, Veaceslav Falico <vfalico@redhat.com> wrote:
> +void netdev_adjacent_rename_links(struct net_device *dev, char *oldname)
> +{
> + struct netdev_adjacent *iter;
> +
> + list_for_each_entry(iter, &dev->adj_list.upper, list) {
> + netdev_adjacent_sysfs_del(iter->dev, oldname,
> + &iter->dev->adj_list.lower);
> + netdev_adjacent_sysfs_add(iter->dev, dev,
> + &iter->dev->adj_list.lower);
> + }
> +
> + list_for_each_entry(iter, &dev->adj_list.lower, list) {
> + netdev_adjacent_sysfs_del(iter->dev, oldname,
> + &iter->dev->adj_list.upper);
> + netdev_adjacent_sysfs_add(iter->dev, dev,
> + &iter->dev->adj_list.upper);
> + }
> +}
> +EXPORT_SYMBOL(netdev_adjacent_rename_links);
Since it is only used within net/core/dev.c, why do you make it extern
and export it? It can become static.
^ permalink raw reply
* [PATCH net] be2net: add dma_mapping_error() check for dma_map_page()
From: Ivan Vecera @ 2014-01-14 18:28 UTC (permalink / raw)
To: netdev; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde
The driver does not check value returned by dma_map_page. The patch
fixes this as well as one additional bug. The prev_page_info is
dereferenced after 'for' loop but if the 1st be_alloc_pages fails its
value is NULL.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index bf40fda..f2811b5 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1776,6 +1776,7 @@ static void be_post_rx_frags(struct be_rx_obj *rxo, gfp_t gfp)
struct be_rx_page_info *page_info = NULL, *prev_page_info = NULL;
struct be_queue_info *rxq = &rxo->q;
struct page *pagep = NULL;
+ struct device *dev = &adapter->pdev->dev;
struct be_eth_rx_d *rxd;
u64 page_dmaaddr = 0, frag_dmaaddr;
u32 posted, page_offset = 0;
@@ -1788,9 +1789,15 @@ static void be_post_rx_frags(struct be_rx_obj *rxo, gfp_t gfp)
rx_stats(rxo)->rx_post_fail++;
break;
}
- page_dmaaddr = dma_map_page(&adapter->pdev->dev, pagep,
- 0, adapter->big_page_size,
+ page_dmaaddr = dma_map_page(dev, pagep, 0,
+ adapter->big_page_size,
DMA_FROM_DEVICE);
+ if (dma_mapping_error(dev, page_dmaaddr)) {
+ put_page(pagep);
+ pagep = NULL;
+ rx_stats(rxo)->rx_post_fail++;
+ break;
+ }
page_info->page_offset = 0;
} else {
get_page(pagep);
@@ -1816,7 +1823,7 @@ static void be_post_rx_frags(struct be_rx_obj *rxo, gfp_t gfp)
queue_head_inc(rxq);
page_info = &rxo->page_info_tbl[rxq->head];
}
- if (pagep)
+ if (pagep && prev_page_info)
prev_page_info->last_page_user = true;
if (posted) {
--
1.8.3.2
^ permalink raw reply related
* Re: [RFC] sysfs_rename_link() and its usage
From: Greg KH @ 2014-01-14 18:21 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: linux-kernel, netdev, ebiederm
In-Reply-To: <20140114171740.GB1867@redhat.com>
On Tue, Jan 14, 2014 at 06:17:40PM +0100, Veaceslav Falico wrote:
> Hi,
>
> I'm hitting a strange issue and/or I'm completely lost in sysfs internals.
>
> Consider having two net_device *a, *b; which are registered normally.
> Now, to create a link from /sys/class/net/a->name/linkname to b, one should
> use:
>
> sysfs_create_link(&(a->dev.kobj), &(b->dev.kobj), linkname);
>
> To remove it, even simpler:
>
> sysfs_remove_link(&(a->dev.kobj), linkname);
>
> This works like a charm. However, if I want to use (obviously, with the
> symlink present):
>
> sysfs_rename_link(&(a->dev.kobj), &(b->dev.kobj), oldname, newname);
You forgot the namespace option to this call, what kernel version are
you using here?
> this fails with:
>
> "sysfs: ns invalid in 'a->name' for 'oldname'"
Looks like the namespace for this link isn't valid.
> in
>
> 608 struct sysfs_dirent *sysfs_find_dirent(struct sysfs_dirent *parent_sd,
> ...
> 615 if (!!sysfs_ns_type(parent_sd) != !!ns) {
> 616 WARN(1, KERN_WARNING "sysfs: ns %s in '%s' for '%s'\n",
> 617 sysfs_ns_type(parent_sd) ? "required" : "invalid",
> 618 parent_sd->s_name, name);
> 619 return NULL;
> 620 }
>
> Code path:
> warn_slowpath_fmt+0x46/0x50
> sysfs_get_dirent_ns+0x30/0x80
> sysfs_find_dirent+0x84/0x110
> sysfs_get_dirent_ns+0x3e/0x80
> sysfs_rename_link_ns+0x54/0xd0
>
> I have no idea what this code means. Is there any reason for it to
> fail (i.e. am I doing something wrong?) or I've hit a bug?
What exactly are you trying to do here? Care to provide a pointer to
your code somewhere?
> I've tested the only user of it (bridge) - and it works fine, however it's
> not using its own net_device's kobject but rather its own dir.
The driver core also uses this function, and it works there, so I'd
blame your code :)
thanks,
greg k-h
^ 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