* [PATCH net-next] macvlan: fix failure during registration v3
From: Francesco Ruggeri @ 2016-04-23 22:03 UTC (permalink / raw)
To: netdev
Cc: Francesco Ruggeri, Eric W. Biederman, David S. Miller,
Mahesh Bandewar
If macvlan_common_newlink fails in register_netdevice after macvlan_init
then it decrements port->count twice, first in macvlan_uninit (from
register_netdevice or rollback_registered) and then again in
macvlan_common_newlink.
A similar problem may exist in the ipvlan driver.
This patch consolidates modifications to port->count into macvlan_init
and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
v3: remove macvtap specific bits.
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
---
drivers/net/macvlan.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 2bcf1f3..cb01023 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -795,6 +795,7 @@ static int macvlan_init(struct net_device *dev)
{
struct macvlan_dev *vlan = netdev_priv(dev);
const struct net_device *lowerdev = vlan->lowerdev;
+ struct macvlan_port *port = vlan->port;
dev->state = (dev->state & ~MACVLAN_STATE_MASK) |
(lowerdev->state & MACVLAN_STATE_MASK);
@@ -812,6 +813,8 @@ static int macvlan_init(struct net_device *dev)
if (!vlan->pcpu_stats)
return -ENOMEM;
+ port->count += 1;
+
return 0;
}
@@ -1312,10 +1315,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
return err;
}
- port->count += 1;
err = register_netdevice(dev);
if (err < 0)
- goto destroy_port;
+ return err;
dev->priv_flags |= IFF_MACVLAN;
err = netdev_upper_dev_link(lowerdev, dev);
@@ -1330,10 +1332,6 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
unregister_netdev:
unregister_netdevice(dev);
-destroy_port:
- port->count -= 1;
- if (!port->count)
- macvlan_port_destroy(lowerdev);
return err;
}
--
1.8.1.4
^ permalink raw reply related
* [PATCH net-next] macvtap: check minor when unregistering
From: Francesco Ruggeri @ 2016-04-23 22:04 UTC (permalink / raw)
To: netdev; +Cc: Francesco Ruggeri, Eric W. Biederman, David S. Miller
macvtap_device_event(NETDEV_UNREGISTER) should check vlan->minor to
determine if it is being invoked in the context of a macvtap_newlink
that failed, for example in this code sequence:
macvtap_newlink
macvlan_common_newlink
register_netdevice
call_netdevice_notifiers(NETDEV_REGISTER, dev)
macvtap_device_event(NETDEV_REGISTER)
<fail here, vlan->minor = 0>
rollback_registered(dev);
rollback_registered_many
call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
macvtap_device_event(NETDEV_UNREGISTER)
<nothing to clean up here>
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
---
drivers/net/macvtap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 95394ed..74cb15a 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -1303,6 +1303,9 @@ static int macvtap_device_event(struct notifier_block *unused,
}
break;
case NETDEV_UNREGISTER:
+ /* vlan->minor == 0 if NETDEV_REGISTER above failed */
+ if (vlan->minor == 0)
+ break;
devt = MKDEV(MAJOR(macvtap_major), vlan->minor);
device_destroy(macvtap_class, devt);
macvtap_free_minor(vlan);
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH net-next 2/2] net: ethernet: enc28j60: add device tree support
From: Arnd Bergmann @ 2016-04-23 22:20 UTC (permalink / raw)
To: Michael Heimpold
Cc: Jonathan Cameron, Andrew F . Davis, Mark Brown, netdev,
devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Claudio Lanconelli
In-Reply-To: <1461447800-11381-3-git-send-email-mhei@heimpold.de>
On Saturday 23 April 2016 23:43:20 Michael Heimpold wrote:
> diff --git a/drivers/net/ethernet/microchip/enc28j60.c b/drivers/net/ethernet/microchip/enc28j60.c
> index b723622..49635d7 100644
> --- a/drivers/net/ethernet/microchip/enc28j60.c
> +++ b/drivers/net/ethernet/microchip/enc28j60.c
> @@ -1634,9 +1634,20 @@ static int enc28j60_remove(struct spi_device *spi)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id enc28j60_dt_ids[] = {
> + { .compatible = "microchip,enc28j60" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, enc28j60_dt_ids);
> +#else
> +#define enc28j60_dt_ids NULL
> +#endif
> +
> static struct spi_driver enc28j60_driver = {
> .driver = {
> - .name = DRV_NAME,
> + .name = DRV_NAME,
> + .of_match_table = enc28j60_dt_ids,
> },
> .probe = enc28j60_probe,
> .remove = enc28j60_remove,
> --
>
You probably also want to add support for calling of_get_mac_address()
here, to allow giving the device a fixed address from the boot loader.
I think you can drop the #ifdef and just define the device table
unconditionally.
Arnd
^ permalink raw reply
* Re: [PATCH net-next 12/12] net/mlx5e: Disable link up on INIT HCA command
From: Ido Schimmel @ 2016-04-23 22:03 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Saeed Mahameed, David S. Miller, Linux Netdev List, Or Gerlitz,
Tal Alon, Eran Ben Elisha, Eugenia Emantayev, Jiri Pirko, eladr
In-Reply-To: <CALzJLG-AWFHnba=ysCAQLqCjFHo3L-sQTeW+NbpMg-X6PRtRPQ@mail.gmail.com>
Sat, Apr 23, 2016 at 11:21:45PM IDT, saeedm@dev.mellanox.co.il wrote:
>On Sat, Apr 23, 2016 at 7:00 PM, Ido Schimmel <idosch@mellanox.com> wrote:
>> mutt suggests I sent you the following patches a while ago:
>>
>> net/mlx5e: Set port administrative status in ndo_{open, close}
>> net/mlx5e: Initialize port administrative status to down
>>
>> So I'm curious as to why you didn't follow up on them and instead came
>> up with this patch.
>>
>> When I initially debugged this I pointed you to the fact that the
>> firmware also needs to be patched, as setting the administrative status
>> down via PAOS doesn't really do anything. The operational status will
>> remain up. I just tested this patchset with the latest release firmware
>> (12.14.2036) and I'm bumping into the same problem.
>>
>
>Hi Ido,
>
>I do remember that patch, and back then i told you that your patch is
>not cooked enough and that we were working on a solution:
>
>1. you need to negotiate with the FW on if the FW can give up port
>ownership to SW, you can find that in handle_hca_cap,
>MLX5_CAP_GEN_MAX(dev, disable_link_up).
Yea, I don't think that part was available back then? I just directly
set a value in firmware memory hoping it would be the default in the
next version following my report.
>2. you need to configure the FW to give up port ownership via NVconfig
>(mlxconfig tool) i think it is PORT_OWNER bit, Eran can elaborate
>more if needed.
I'll check that tomorrow morning and report.
>3.1 and 2 are required for mlx5_set_port_admin_status to take effect,
>otherwise it is a NOOP.
>
>Eran tested this patch and it works for him, maybe you missed step 2.
>Step 2 will not be required in future FW (it will be the FW default).
Great!
>Other than this patch, nothing more is required for driver to assume
>ownership on port's link status.
>
>> Until this is properly fixed the mlx5 driver is blacklisted in our test:
>> https://github.com/jpirko/lnst/blob/master/recipes/switchdev/basic-001-links.py#L19
>>
>> Also, why is this directed at net-next?
>>
>
>it is kind of new behavior, and not a bug fix.
>
>>> drivers/infiniband/hw/mlx5/main.c | 11 +++++++++++
>>> drivers/infiniband/hw/mlx5/mlx5_ib.h | 5 +++++
>>> drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 4 ++--
>>> .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 4 ++--
>>> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 4 ++++
>>> drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 ++++
>>> drivers/net/ethernet/mellanox/mlx5/core/port.c | 5 +++--
>>> include/linux/mlx5/port.h | 3 ++-
>>> 8 files changed, 33 insertions(+), 7 deletions(-)
>>>
>>
>> [...]
>>
>>>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>>>index b2db180..f083797 100644
>>>--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>>>+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>>>@@ -202,12 +202,12 @@ static int mlx5e_dcbnl_ieee_setpfc(struct net_device *dev,
>>>
>>> mlx5_query_port_admin_status(mdev, &ps);
>>> if (ps == MLX5_PORT_UP)
>>>- mlx5_set_port_admin_status(mdev, MLX5_PORT_DOWN);
>>>+ mlx5_set_port_admin_status(mdev, MLX5_PORT_DOWN, 1);
>>
>> Why is this needed? The link doesn't need to go through training when
>> setting PFC. It's only needed for PAUSE frames when auto-negotiation is
>> on, but you don't support that anyway.
>>
>> Thanks.
>>
>
>The code was there before this patch, only the function prototype was changed.
>Maybe you have a valid point here, but this need to be fixed in a
>different patch, it has nothing to do with this one.
>Eran and Team please check this on Sunday, I found nothing re this
>matter in PRM.
See PFCC register:
"Setting pfctx / pfcrx when the link is up takes effect immediately."
Thanks.
^ permalink raw reply
* net merged into net-next
From: David Miller @ 2016-04-24 0:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
Eric, please double check my merge work for net/ipv4/udp.c
In net we fixed a soreuseport bug that added a hlist_nulls_add_tail_rcu()
call to net/ipv4/udp.c
And in net-next you converted UDP sockets away from nulls lists.
Therefore I had to add a hlist_add_tail_rcu() implementation to
linux/rculist.h and use it in net/ipv4/udp.c
Please make sure this is fine and will work safely.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 0/9] netlink: align attributes when needed (patchset #1)
From: David Miller @ 2016-04-24 0:13 UTC (permalink / raw)
To: nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w
Cc: dev-yBygre7rU0TnMu66kgdUjQ,
steffen.klassert-opNxpl+3fjRBDgjK7y7TUQ,
herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
aar-bIcnvbaLZ9MEGnE8C9+IrQ, netdev-u79uwXL29TY76Z2rM5mHXA,
bsingharora-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jmorris-gx6/JNMH7DfYtjvyW6yDsg, yoshfuji-VfPWfsRibaP+Ru+s062T9g,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
kuznet-v/Mj1YrvjDBInbfyfbPRSQ, linux-wpan-u79uwXL29TY76Z2rM5mHXA,
kaber-dcUjhNyLwpNeoWH0uzbU5w, pablo-Cap9r6Oaw4JrovVCs/uTlw
In-Reply-To: <1461339084-3849-1-git-send-email-nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 22 Apr 2016 17:31:15 +0200
> This is the continuation of the work done to align netlink attributes
> when these attributes contain some 64-bit fields.
>
> David, if the third patch is too big (or maybe the series), I can split it.
> Just tell me what you prefer.
This looks excellent, series applied, thanks!
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: fix spurious timestamping callbacks
From: Eric Dumazet @ 2016-04-24 0:55 UTC (permalink / raw)
To: Or Gerlitz; +Cc: David Miller, netdev, Eugenia Emantayev, Eran Ben Elisha
In-Reply-To: <CAJ3xEMg3HwbZG6qh5=ydaUesQX_goRSD6H_LowsEuW46TVDnbA@mail.gmail.com>
On Sat, 2016-04-23 at 23:23 +0300, Or Gerlitz wrote:
> On Sat, Apr 23, 2016 at 9:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > When multiple skb are TX-completed in a row, we might incorrectly keep
> > a timestamp of a prior skb and cause extra work.
> >
> > Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Willem de Bruijn <willemb@google.com>
>
> Eric, was that supposed to be Reported-by: or Signed-off-by: ...
This was meant to be.
Cc: Willem de Bruijn <willemb@google.com>
Willem was CC on the original bug at Google (Google-Bug-Id: 28356763 )
Thanks.
^ permalink raw reply
* Re: net merged into net-next
From: Eric Dumazet @ 2016-04-24 1:39 UTC (permalink / raw)
To: David Miller, Craig Gallek; +Cc: netdev
In-Reply-To: <20160423.201230.364025148300253838.davem@davemloft.net>
On Sat, 2016-04-23 at 20:12 -0400, David Miller wrote:
> Eric, please double check my merge work for net/ipv4/udp.c
>
> In net we fixed a soreuseport bug that added a hlist_nulls_add_tail_rcu()
> call to net/ipv4/udp.c
>
> And in net-next you converted UDP sockets away from nulls lists.
>
> Therefore I had to add a hlist_add_tail_rcu() implementation to
> linux/rculist.h and use it in net/ipv4/udp.c
>
> Please make sure this is fine and will work safely.
>
> Thanks!
Looks fine to me, thanks David
Craig, please have a look ?
( commit 1602f49b58abcb0d34a5f0a29d68e7c1769547aa in net-next)
^ permalink raw reply
* Re: [PATCH 00/23] Netfilter updates for net-next
From: David Miller @ 2016-04-24 4:26 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1461332394-3994-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri, 22 Apr 2016 15:39:31 +0200
> The following patchset contains Netfilter updates for your net-next
> tree, mostly from Florian Westphal to sort out the lack of sufficient
> validation in x_tables and connlabel preparation patches to add
> nf_tables support. They are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks a lot Pablo!
^ permalink raw reply
* smc911 vs smsc911
From: Ran Shalit @ 2016-04-24 5:25 UTC (permalink / raw)
To: netdev
Hello,
Does anyone can say what's the difference between smc911 and smsc911 ?
On reading the first comments in each file it seems that there is
overlapping between them:
smc911x.c
========
* This is a driver for SMSC's LAN911{5,6,7,8} single-chip Ethernet devices.
smsc911x.c
===========
* Supported devices:
* LAN9115, LAN9116, LAN9117, LAN9118
* LAN9215, LAN9216, LAN9217, LAN9218
* LAN9210, LAN9211
* LAN9220, LAN9221
* LAN89218
*
*/
Regards,
Ran
^ permalink raw reply
* VRF_DEVICE integration plan
From: Elluru, Krishna Mohan @ 2016-04-24 4:07 UTC (permalink / raw)
To: netdev@vger.kernel.org
HI Netdev team,
Greetings. We have been monitoring the vrf device approach for l3 isolation from cumulus networks and we are currently interested in validating it. We have following questions on them and hoping to get answers from you/concerned team.
1. As per the linux documentation, there are known limits on if_index lookup, as the incoming if_index is changed to vrf_device index and thus an application receiving this packet will perceive this as a vrf_device packet, than right if_index. I saw you mentioned about a special flag to identify the origin, but didn't see the same in the latest linux 4.4.2 version code. Is there a patch expected for it?
2. What are the future additions planned for this approach? Are there any ipv4 and ipv6 known bugs with vrf_device model?
3. It has been said in the documentation that, with addition of cgroup functionality for vrf device, with net_admin capabilities, we should be able to add an interface to vrf_device, currently it is not so. Any timelines on these?
4. Currently the changes are available and portable from 4.3.x onwards. Is there a plan to port them to previous kernel versions?
5. Is there a possibility of enabling secondary level lookup, to give a leak functionality to parent route table from device local route table? I tested with veth pair, configured one as default gateway, it is possible to forward traffic b/w the interfaces, looking for cleaner method.
6. With "VRF Device" in place, please confirm if there are any plans to add VRF support for applications like
1. Ping
2. Traceroute
3. DNS-Client [glibc]
In case of DNS-Client, most of the name resolution APIs will have to consider the VRF to do the lookup in and the way the domain-name/name-server configuration is stored.
Please revert back, if you need more clarification on the questions.
Thanks in Advance
Krishna Mohan
^ permalink raw reply
* [PATCH 03/21] io-mapping: Specify mapping size for io_mapping_map_wc()
From: Chris Wilson @ 2016-04-24 7:18 UTC (permalink / raw)
To: intel-gfx
Cc: Tvrtko Ursulin, netdev, Yishai Hadas, linux-kernel,
Peter Zijlstra (Intel), Luis R . Rodriguez, dri-devel, linux-rdma,
Daniel Vetter, Dan Williams, Ingo Molnar, David Hildenbrand
In-Reply-To: <1461482332-21975-1-git-send-email-chris@chris-wilson.co.uk>
The ioremap() hidden behind the io_mapping_map_wc() convenience helper
can be used for remapping multiple pages. Extend the helper so that
future callers can use it for larger ranges.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Yishai Hadas <yishaih@mellanox.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: netdev@vger.kernel.org
Cc: linux-rdma@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/gpu/drm/i915/intel_overlay.c | 3 ++-
drivers/net/ethernet/mellanox/mlx4/pd.c | 4 +++-
include/linux/io-mapping.h | 10 +++++++---
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c
index 9746b9841c13..0d5a376878d3 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -198,7 +198,8 @@ intel_overlay_map_regs(struct intel_overlay *overlay)
regs = (struct overlay_registers __iomem *)overlay->reg_bo->phys_handle->vaddr;
else
regs = io_mapping_map_wc(ggtt->mappable,
- overlay->flip_addr);
+ overlay->flip_addr,
+ PAGE_SIZE);
return regs;
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/pd.c b/drivers/net/ethernet/mellanox/mlx4/pd.c
index b3cc3ab63799..6fc156a3918d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/pd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/pd.c
@@ -205,7 +205,9 @@ int mlx4_bf_alloc(struct mlx4_dev *dev, struct mlx4_bf *bf, int node)
goto free_uar;
}
- uar->bf_map = io_mapping_map_wc(priv->bf_mapping, uar->index << PAGE_SHIFT);
+ uar->bf_map = io_mapping_map_wc(priv->bf_mapping,
+ uar->index << PAGE_SHIFT,
+ PAGE_SIZE);
if (!uar->bf_map) {
err = -ENOMEM;
goto unamp_uar;
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index e399029b68c5..645ad06b5d52 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -100,14 +100,16 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
}
static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
{
resource_size_t phys_addr;
BUG_ON(offset >= mapping->size);
phys_addr = mapping->base + offset;
- return ioremap_wc(phys_addr, PAGE_SIZE);
+ return ioremap_wc(phys_addr, size);
}
static inline void
@@ -155,7 +157,9 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
/* Non-atomic map/unmap */
static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
{
return ((char __force __iomem *) mapping) + offset;
}
--
2.8.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v2 03/21] io-mapping: Specify mapping size for io_mapping_map_wc()
From: Chris Wilson @ 2016-04-24 7:31 UTC (permalink / raw)
To: intel-gfx
Cc: Tvrtko Ursulin, netdev, Yishai Hadas, linux-kernel,
Peter Zijlstra (Intel), Luis R . Rodriguez, dri-devel, linux-rdma,
Daniel Vetter, Dan Williams, Ingo Molnar, David Hildenbrand
In-Reply-To: <1461483101-10618-1-git-send-email-chris@chris-wilson.co.uk>
The ioremap() hidden behind the io_mapping_map_wc() convenience helper
can be used for remapping multiple pages. Extend the helper so that
future callers can use it for larger ranges.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Yishai Hadas <yishaih@mellanox.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: netdev@vger.kernel.org
Cc: linux-rdma@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/gpu/drm/i915/intel_overlay.c | 3 ++-
drivers/net/ethernet/mellanox/mlx4/pd.c | 4 +++-
include/linux/io-mapping.h | 10 +++++++---
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c
index 9746b9841c13..0d5a376878d3 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -198,7 +198,8 @@ intel_overlay_map_regs(struct intel_overlay *overlay)
regs = (struct overlay_registers __iomem *)overlay->reg_bo->phys_handle->vaddr;
else
regs = io_mapping_map_wc(ggtt->mappable,
- overlay->flip_addr);
+ overlay->flip_addr,
+ PAGE_SIZE);
return regs;
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/pd.c b/drivers/net/ethernet/mellanox/mlx4/pd.c
index b3cc3ab63799..6fc156a3918d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/pd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/pd.c
@@ -205,7 +205,9 @@ int mlx4_bf_alloc(struct mlx4_dev *dev, struct mlx4_bf *bf, int node)
goto free_uar;
}
- uar->bf_map = io_mapping_map_wc(priv->bf_mapping, uar->index << PAGE_SHIFT);
+ uar->bf_map = io_mapping_map_wc(priv->bf_mapping,
+ uar->index << PAGE_SHIFT,
+ PAGE_SIZE);
if (!uar->bf_map) {
err = -ENOMEM;
goto unamp_uar;
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index e399029b68c5..645ad06b5d52 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -100,14 +100,16 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
}
static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
{
resource_size_t phys_addr;
BUG_ON(offset >= mapping->size);
phys_addr = mapping->base + offset;
- return ioremap_wc(phys_addr, PAGE_SIZE);
+ return ioremap_wc(phys_addr, size);
}
static inline void
@@ -155,7 +157,9 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
/* Non-atomic map/unmap */
static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
{
return ((char __force __iomem *) mapping) + offset;
}
--
2.8.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH v5 00/21] Add HiSilicon RoCE driver
From: Leon Romanovsky @ 2016-04-24 7:44 UTC (permalink / raw)
To: Lijun Ou
Cc: dledford, sean.hefty, hal.rosenstock, davem, jeffrey.t.kirsher,
jiri, ogerlitz, linuxarm, linux-rdma, linux-kernel, netdev,
gongyangming, xiaokun, tangchaofei, haifeng.wei, yisen.zhuang,
yankejian, lisheng011, charles.chenxin
In-Reply-To: <1461407219-72027-1-git-send-email-oulijun@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]
On Sat, Apr 23, 2016 at 06:26:38PM +0800, Lijun Ou wrote:
> The HiSilicon Network Substem is a long term evolution IP which is
> supposed to be used in HiSilicon ICT SoCs. HNS (HiSilicon Network
> Sybsystem) also has a hardware support of performing RDMA with
> RoCEE.
> The driver for HiSilicon RoCEE(RoCE Engine) is a platform driver and will
> support mulitple versions of SOCs in future. This version of driver is
> meant to support Hip06 SoC (which confirms to RoCEEv1 hardware specifications).
>
> Changes v5 -> v4:
v4 -> v5
> 1. redesign the patchset for RoCE modules in order to split the huge
> patch into small patches.
Thanks,
I may admit that I didn't look on the patches yet, however two things
already spotted my attention:
1. Please fix Signed-off-by signatures to include First name, Last name
and email address.
2. Please run spelling checker on all your patches.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 09/21] IB/hns: Add hca support
From: Leon Romanovsky @ 2016-04-24 7:54 UTC (permalink / raw)
To: Lijun Ou
Cc: dledford, sean.hefty, hal.rosenstock, davem, jeffrey.t.kirsher,
jiri, ogerlitz, linuxarm, linux-rdma, linux-kernel, netdev,
gongyangming, xiaokun, tangchaofei, haifeng.wei, yisen.zhuang,
yankejian, lisheng011, charles.chenxin
In-Reply-To: <1461407219-72027-10-git-send-email-oulijun@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]
On Sat, Apr 23, 2016 at 06:26:47PM +0800, Lijun Ou wrote:
> This patch mainly setup hca for RoCE. it will do a series of
> initial works as follows:
> 1. init uar table, allocate uar resource
> 2. init pd table
> 3. init cq table
> 4. init mr table
> 5. init qp table
>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> Signed-off-by: Wei Hu(Xavier) <xavier.huwei@huawei.com>
> ---
> drivers/infiniband/hw/hns/hns_roce_alloc.c | 104 ++++++++++++++++
> drivers/infiniband/hw/hns/hns_roce_cq.c | 25 ++++
> drivers/infiniband/hw/hns/hns_roce_device.h | 69 ++++++++++
> drivers/infiniband/hw/hns/hns_roce_eq.c | 1 -
> drivers/infiniband/hw/hns/hns_roce_icm.c | 88 +++++++++++++
> drivers/infiniband/hw/hns/hns_roce_icm.h | 9 ++
> drivers/infiniband/hw/hns/hns_roce_main.c | 79 ++++++++++++
> drivers/infiniband/hw/hns/hns_roce_mr.c | 187 ++++++++++++++++++++++++++++
> drivers/infiniband/hw/hns/hns_roce_pd.c | 65 ++++++++++
> drivers/infiniband/hw/hns/hns_roce_qp.c | 30 +++++
> 10 files changed, 656 insertions(+), 1 deletion(-)
> create mode 100644 drivers/infiniband/hw/hns/hns_roce_alloc.c
> create mode 100644 drivers/infiniband/hw/hns/hns_roce_mr.c
> create mode 100644 drivers/infiniband/hw/hns/hns_roce_pd.c
>
> diff --git a/drivers/infiniband/hw/hns/hns_roce_alloc.c b/drivers/infiniband/hw/hns/hns_roce_alloc.c
> new file mode 100644
> index 0000000..0c76f1b
> --- /dev/null
> +++ b/drivers/infiniband/hw/hns/hns_roce_alloc.c
> @@ -0,0 +1,104 @@
> +/*
> + * Copyright (c) 2016 Hisilicon Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/bitmap.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/errno.h>
> +#include <linux/mm.h>
> +#include <linux/slab.h>
> +#include <linux/vmalloc.h>
> +#include "hns_roce_device.h"
> +
> +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj)
> +{
> + int ret = 0;
> +
> + spin_lock(&bitmap->lock);
> + *obj = find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
> + if (*obj >= bitmap->max) {
> + bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
> + & bitmap->mask;
> + *obj = find_first_zero_bit(bitmap->table, bitmap->max);
find_first_zero_bit function returns "unsigned long" which may or may
not be equal to u32 on some architectures.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: fix spurious timestamping callbacks
From: Eran Ben Elisha @ 2016-04-24 8:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Eugenia Emantayev
In-Reply-To: <1461436546.7627.45.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, Apr 23, 2016 at 9:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> When multiple skb are TX-completed in a row, we might incorrectly keep
> a timestamp of a prior skb and cause extra work.
>
> Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Willem de Bruijn <willemb@google.com>
Other than the commit message issue raised by Or,
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
^ permalink raw reply
* Re: [PATCH net 1/3] gre: do not assign header_ops in collect metadata mode
From: Jiri Benc @ 2016-04-24 9:31 UTC (permalink / raw)
To: Thomas Graf
Cc: pravin shelar, Linux Kernel Network Developers, Pravin B Shelar,
Simon Horman
In-Reply-To: <20160423014143.GC32327@pox.localdomain>
On Sat, 23 Apr 2016 03:41:43 +0200, Thomas Graf wrote:
> On 04/22/16 at 11:20pm, Jiri Benc wrote:
> > On Fri, 22 Apr 2016 14:04:48 -0700, pravin shelar wrote:
> > > I think we should we return error in case of such configuration rather
> > > than silently ignoring it.
> >
> > I thought about it and I'm not sure. We're not returning an error
> > currently, starting returning it now might be perceived as uAPI
> > breakage.
> >
> > But given it doesn't work at all currently, there are apparently no
> > users yet. I'll wait for more feedback.
>
> As a user, I would probably favour receiving an error for a configuration
> that can't possibly work and was not working before.
Okay, I'll change this in v2. Thanks, Pravin and Thomas.
Jiri
^ permalink raw reply
* Re: [PATCH net 3/3] gre: receive also TEB packets for lwtunnels
From: Jiri Benc @ 2016-04-24 9:38 UTC (permalink / raw)
To: Simon Horman; +Cc: Thomas Graf, netdev, Pravin B Shelar
In-Reply-To: <20160423050912.GA4520@penelope.isobedori.kobe.vergenet.net>
On Sat, 23 Apr 2016 15:09:16 +1000, Simon Horman wrote:
> On Sat, Apr 23, 2016 at 03:49:38AM +0200, Thomas Graf wrote:
> > I may be missing some context. Is anyone using this already or is this
> > preparing the stage for another user? It's not clear to me from the
> > commit message.
>
> Hi Thomas,
>
> I'm not sure what use Jiri may have in mind but I plan to use
> this to allow OvS to support packets without an Ethernet header to
> be received from and sent to a GRE tunnel.
>
> I am reasonably sure there are no existing users.
Yes, that's the main use case as far as I can see. Sorry for not being
clear.
The intention is to support tunnels that can have mixed L2+L3 traffic
over a single lwtunnel interface. VXLAN-GPE already does this, this
patch makes GRE behave identically, while preserving all current GRE
users.
The reason I sent this for net and not net-next is that I wanted to
prevent the situation when we have a kernel released that supports
ipgre lwtunnels but incompletely - i.e., ETH_P_TEB frames are
discarded. But thinking about it more, it's probably non-issue. I'll
retarget this patch for net-next and resend the first two for net.
Thanks,
Jiri
^ permalink raw reply
* Re: [PATCH net 3/3] gre: receive also TEB packets for lwtunnels
From: Jiri Benc @ 2016-04-24 9:54 UTC (permalink / raw)
To: pravin shelar
Cc: Linux Kernel Network Developers, Pravin B Shelar, Thomas Graf,
Simon Horman
In-Reply-To: <CAOrHB_DXzE8XNBmMc_VLzz+hkJCUmMVT2uMhWORCgq+g7ym9HA@mail.gmail.com>
On Fri, 22 Apr 2016 20:40:13 -0700, pravin shelar wrote:
> But skb->protocol is not set to ETH_P_TEB anywhere in ip-gre module.
> Am I missing something?
Ah, I see your point. It needs to be solved a bit differently, though,
we need to call __iptunnel_pull_header instead of iptunnel_pull_header
for these packets. I'll rework the patch.
> ip_tunnel_rcv() checks device type (tunnel->dev->type) to perform
> ethernet specific processing on packet. I think that should be changed
> to check packet type.
The current behavior is correct. The Ethernet processing depends on
the interface type, ARPHRD_IPGRE interfaces can't treat Ethernet
headers as L2 headers, that wouldn't match the interface type.
Jiri
^ permalink raw reply
* [PATCH net v2 0/3] gre: fix lwtunnel support
From: Jiri Benc @ 2016-04-24 11:00 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar, Thomas Graf, Simon Horman
This patchset fixes a few bugs in gre metadata mode implementation, mainly
with ipgre.
As an example, in this setup:
ip a a 192.168.1.1/24 dev eth0
ip l a gre1 type gre external
ip l s gre1 up
ip a a 192.168.99.1/24 dev gre1
ip r a 192.168.99.2/32 encap ip dst 192.168.1.2 ttl 10 dev gre1
ping 192.168.99.2
the traffic does not go through before this patchset and does as expected
with it applied.
v2: Rejecting invalid configuration, added patch 3, dropped patch for
ETH_P_TEB (will target net-next).
Jiri Benc (3):
gre: do not assign header_ops in collect metadata mode
gre: build header correctly for collect metadata tunnels
gre: allow creation of gretap interfaces in metadata mode
net/ipv4/ip_gre.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net v2 1/3] gre: do not assign header_ops in collect metadata mode
From: Jiri Benc @ 2016-04-24 11:00 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar, Thomas Graf, Simon Horman
In-Reply-To: <cover.1461495411.git.jbenc@redhat.com>
In ipgre mode (i.e. not gretap) with collect metadata flag set, the tunnel
is incorrectly assumed to be mGRE in NBMA mode (see commit 6a5f44d7a048c).
This is not the case, we're controlling the encapsulation addresses by
lwtunnel metadata. And anyway, assigning dev->header_ops in collect metadata
mode does not make sense.
Similarly, when a multicast remote IP address is set together with the
collect metadata flag, the processing described above would happen, too. As
there's not much sense in specifying remote/local IP address for lwtunnels,
reject such configuration.
v2: Reject configuration specifying both remote/local address and collect
metadata flag.
Fixes: 2e15ea390e6f4 ("ip_gre: Add support to collect tunnel metadata.")
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
net/ipv4/ip_gre.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index af5d1f38217f..c035b43b1d4b 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -902,8 +902,9 @@ static int ipgre_tunnel_init(struct net_device *dev)
dev->header_ops = &ipgre_header_ops;
}
#endif
- } else
+ } else if (!tunnel->collect_md) {
dev->header_ops = &ipgre_header_ops;
+ }
return ip_tunnel_init(dev);
}
@@ -946,6 +947,15 @@ static int ipgre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[])
if (flags & (GRE_VERSION|GRE_ROUTING))
return -EINVAL;
+ if (data[IFLA_GRE_COLLECT_METADATA]) {
+ if (data[IFLA_GRE_REMOTE] &&
+ nla_get_in_addr(data[IFLA_GRE_REMOTE]))
+ return -EINVAL;
+ if (data[IFLA_GRE_LOCAL] &&
+ nla_get_in_addr(data[IFLA_GRE_LOCAL]))
+ return -EINVAL;
+ }
+
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net v2 2/3] gre: build header correctly for collect metadata tunnels
From: Jiri Benc @ 2016-04-24 11:00 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar, Thomas Graf, Simon Horman
In-Reply-To: <cover.1461495411.git.jbenc@redhat.com>
In ipgre (i.e. not gretap) + collect metadata mode, the skb was assumed to
contain Ethernet header and was encapsulated as ETH_P_TEB. This is not the
case, the interface is ARPHRD_IPGRE and the protocol to be used for
encapsulation is skb->protocol.
Fixes: 2e15ea390e6f4 ("ip_gre: Add support to collect tunnel metadata.")
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
---
v2: unchanged
---
net/ipv4/ip_gre.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index c035b43b1d4b..02b12db59437 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -523,7 +523,8 @@ static struct rtable *gre_get_rt(struct sk_buff *skb,
return ip_route_output_key(net, fl);
}
-static void gre_fb_xmit(struct sk_buff *skb, struct net_device *dev)
+static void gre_fb_xmit(struct sk_buff *skb, struct net_device *dev,
+ __be16 proto)
{
struct ip_tunnel_info *tun_info;
const struct ip_tunnel_key *key;
@@ -575,7 +576,7 @@ static void gre_fb_xmit(struct sk_buff *skb, struct net_device *dev)
}
flags = tun_info->key.tun_flags & (TUNNEL_CSUM | TUNNEL_KEY);
- build_header(skb, tunnel_hlen, flags, htons(ETH_P_TEB),
+ build_header(skb, tunnel_hlen, flags, proto,
tunnel_id_to_key(tun_info->key.tun_id), 0);
df = key->tun_flags & TUNNEL_DONT_FRAGMENT ? htons(IP_DF) : 0;
@@ -616,7 +617,7 @@ static netdev_tx_t ipgre_xmit(struct sk_buff *skb,
const struct iphdr *tnl_params;
if (tunnel->collect_md) {
- gre_fb_xmit(skb, dev);
+ gre_fb_xmit(skb, dev, skb->protocol);
return NETDEV_TX_OK;
}
@@ -660,7 +661,7 @@ static netdev_tx_t gre_tap_xmit(struct sk_buff *skb,
struct ip_tunnel *tunnel = netdev_priv(dev);
if (tunnel->collect_md) {
- gre_fb_xmit(skb, dev);
+ gre_fb_xmit(skb, dev, htons(ETH_P_TEB));
return NETDEV_TX_OK;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net v2 3/3] gre: allow creation of gretap interfaces in metadata mode
From: Jiri Benc @ 2016-04-24 11:00 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar, Thomas Graf, Simon Horman
In-Reply-To: <cover.1461495411.git.jbenc@redhat.com>
The IFLA_GRE_REMOTE attribute does not make sense together with collect
metadata and is ignored in such case. However, iproute2 always sets it; it
will be zero if there's no remote address specified on the command line.
Remove the check for non-zero IFLA_GRE_REMOTE when collect medata flag is
set.
Before the patch, this command returns failure, after the patch, it works as
expected:
ip link add gre1 type gretap external
Fixes: 2e15ea390e6f4 ("ip_gre: Add support to collect tunnel metadata.")
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
New in v2.
---
net/ipv4/ip_gre.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 02b12db59437..27716c72b8e2 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -974,7 +974,7 @@ static int ipgre_tap_validate(struct nlattr *tb[], struct nlattr *data[])
if (!data)
goto out;
- if (data[IFLA_GRE_REMOTE]) {
+ if (data[IFLA_GRE_REMOTE] && !data[IFLA_GRE_COLLECT_METADATA]) {
memcpy(&daddr, nla_data(data[IFLA_GRE_REMOTE]), 4);
if (!daddr)
return -EINVAL;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net v2 1/3] gre: do not assign header_ops in collect metadata mode
From: Sergei Shtylyov @ 2016-04-24 13:45 UTC (permalink / raw)
To: Jiri Benc, netdev; +Cc: Pravin B Shelar, Thomas Graf, Simon Horman
In-Reply-To: <bd50f4691e9edc28c5a9ec861863f7f6cf316077.1461495411.git.jbenc@redhat.com>
Hello.
On 4/24/2016 2:00 PM, Jiri Benc wrote:
> In ipgre mode (i.e. not gretap) with collect metadata flag set, the tunnel
> is incorrectly assumed to be mGRE in NBMA mode (see commit 6a5f44d7a048c).
Didn't checkpatch.pl complain about the commit citing style?
> This is not the case, we're controlling the encapsulation addresses by
> lwtunnel metadata. And anyway, assigning dev->header_ops in collect metadata
> mode does not make sense.
>
> Similarly, when a multicast remote IP address is set together with the
> collect metadata flag, the processing described above would happen, too. As
> there's not much sense in specifying remote/local IP address for lwtunnels,
> reject such configuration.
>
> v2: Reject configuration specifying both remote/local address and collect
> metadata flag.
>
> Fixes: 2e15ea390e6f4 ("ip_gre: Add support to collect tunnel metadata.")
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next] sctp: sctp_diag should fill RMEM_ALLOC with asoc->rmem_alloc when rcvbuf_policy is set
From: Xin Long @ 2016-04-24 15:21 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: Marcelo Ricardo Leitner, Vlad Yasevich, daniel, davem,
eric.dumazet
For sctp assoc, when rcvbuf_policy is set, it will has it's own
rmem_alloc, when we dump asoc info in sctp_diag, we should use that
value on RMEM_ALLOC as well, just like WMEM_ALLOC.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/sctp_diag.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/sctp/sctp_diag.c b/net/sctp/sctp_diag.c
index bb2d8d9..b5269df 100644
--- a/net/sctp/sctp_diag.c
+++ b/net/sctp/sctp_diag.c
@@ -145,7 +145,11 @@ static int inet_sctp_diag_fill(struct sock *sk, struct sctp_association *asoc,
else
amt = sk_wmem_alloc_get(sk);
mem[SK_MEMINFO_WMEM_ALLOC] = amt;
- mem[SK_MEMINFO_RMEM_ALLOC] = sk_rmem_alloc_get(sk);
+ if (asoc && asoc->ep->rcvbuf_policy)
+ amt = atomic_read(&asoc->rmem_alloc);
+ else
+ amt = sk_rmem_alloc_get(sk);
+ mem[SK_MEMINFO_RMEM_ALLOC] = amt;
mem[SK_MEMINFO_RCVBUF] = sk->sk_rcvbuf;
mem[SK_MEMINFO_SNDBUF] = sk->sk_sndbuf;
mem[SK_MEMINFO_FWD_ALLOC] = sk->sk_forward_alloc;
--
2.1.0
^ 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