* UBSAN: Undefined behaviour in ./include/net/route.h:239:2: member access within null pointer of type 'struct rtable'
From: Paul Menzel @ 2018-07-20 7:46 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel
Dear Linux folks,
Enabling the undefined behavior sanitizer and building GNU/Linux
4.18-rc5+ (with some unrelated commits) with GCC 8.1.0 from Debian
Sid/unstable, the warning below is shown.
> [ 8.083532] ================================================================================
> [ 8.083781] UBSAN: Undefined behaviour in ./include/net/route.h:239:2
> [ 8.083953] member access within null pointer of type 'struct rtable'
> [ 8.084128] CPU: 1 PID: 239 Comm: sd-resolve Not tainted 4.18.0-rc5-00316-g4864b68cedf2 #104
> [ 8.084131] Hardware name: ASROCK E350M1/E350M1, BIOS TIMELESS 01/01/1970
> [ 8.084133] Call Trace:
> [ 8.084147] dump_stack+0x55/0x89
> [ 8.084154] ubsan_epilogue+0xb/0x33
> [ 8.084158] handle_null_ptr_deref+0x7f/0x90
> [ 8.084163] __ubsan_handle_type_mismatch_v1+0x55/0x60
> [ 8.084170] udp_sendmsg+0xb05/0xf80
> [ 8.084176] ? ip_reply_glue_bits+0x80/0x80
> [ 8.084185] ? import_iovec+0x4a/0x160
> [ 8.084190] ? udp_lib_get_port+0x810/0x810
> [ 8.084194] inet_sendmsg+0x77/0x1d0
> [ 8.084198] ? inet_sk_set_state+0x110/0x110
> [ 8.084203] sock_sendmsg+0x5a/0xb0
> [ 8.084207] ___sys_sendmsg+0x102/0x390
> [ 8.084214] ? seccomp_run_filters+0x79/0x220
> [ 8.084218] ? ip4_datagram_release_cb+0x5f/0x2a0
> [ 8.084222] ? udp_lib_rehash+0x17c/0x300
> [ 8.084228] ? __fget_light+0x99/0x110
> [ 8.084230] ? __fdget+0x12/0x20
> [ 8.084234] ? sockfd_lookup_light+0x1e/0xc0
> [ 8.084238] __sys_sendmmsg+0xef/0x1d0
> [ 8.084244] ? alloc_file+0x9b/0x1e0
> [ 8.084249] ? __secure_computing+0x41/0x120
> [ 8.084253] ? syscall_trace_enter+0x1e5/0x470
> [ 8.084258] sys_sendmmsg+0x28/0x30
> [ 8.084262] do_fast_syscall_32+0xce/0x3e0
> [ 8.084267] entry_SYSENTER_32+0x4e/0x7c
> [ 8.084272] EIP: 0xb7fabbb5
> [ 8.084273] Code: 89 e5 8b 55 08 85 d2 8b 80 5c cd ff ff 74 02 89 02 5d c3 8b 04 24 c3 8b 1c 24 c3 8b 3c 24 c3 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
> [ 8.084339] EAX: ffffffda EBX: 0000000c ECX: b75d240c EDX: 00000002
> [ 8.084342] ESI: 00004000 EDI: 00000000 EBP: 03fdd1f0 ESP: b75d22f0
> [ 8.084345] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000282
> [ 8.084349] ================================================================================
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH net-next 0/2] qed*: Add support for phy module query.
From: David Miller @ 2018-07-20 6:35 UTC (permalink / raw)
To: sudarsana.kalluru; +Cc: netdev, Michal.Kalderon, ariel.elior
In-Reply-To: <20180718132723.3315-1-sudarsana.kalluru@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Wed, 18 Jul 2018 06:27:21 -0700
> The patch series adds driver support for querying the PHY module's
> eeprom data.
>
> Please consider applying it to 'net-next'.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 0/3] set/match the tos/ttl fields of TC based IP tunnels
From: David Miller @ 2018-07-20 6:26 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev
In-Reply-To: <1531844838-6065-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Tue, 17 Jul 2018 19:27:15 +0300
> This series comes to address the case to set (encap) and match (decap)
> also the tos and ttl fields of TC based IP tunnels.
>
> Example encap (1st one) and decap (2nd) that use the new fields
>
> tc filter add dev eth0_0 protocol ip parent ffff: prio 10 flower \
> src_mac e4:11:22:33:44:50 dst_mac e4:11:22:33:44:70 \
> action tunnel_key set src_ip 192.168.10.1 dst_ip 192.168.10.2 id 100 dst_port 4789 tos 0x30 \
> action mirred egress redirect dev vxlan_sys_4789
>
> tc filter add dev vxlan_sys_4789 protocol ip parent ffff: prio 10 flower \
> enc_src_ip 192.168.10.2 enc_dst_ip 192.168.10.1 enc_key_id 100 enc_dst_port 4789 enc_tos 0x30 \
> src_mac e4:11:22:33:44:70 dst_mac e4:11:22:33:44:50 \
> action tunnel_key unset \
> action mirred egress redirect dev eth0_0
Series applied, thanks Or.
^ permalink raw reply
* Re: [PATCH net] net/page_pool: Fix inconsistent lock state warning
From: David Miller @ 2018-07-20 6:23 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, brouer
In-Reply-To: <1531840238-30818-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Tue, 17 Jul 2018 18:10:37 +0300
> Fix the warning below by calling the ptr_ring_consume_bh,
> which uses spin_[un]lock_bh.
...
> Fixes: ff7d6b27f894 ("page_pool: refurbish version of page_pool code")
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH - revised] rhashtable: detect when object movement might have invalidated a lookup
From: NeilBrown @ 2018-07-20 7:09 UTC (permalink / raw)
To: David Miller; +Cc: herbert, tgraf, netdev, linux-kernel, eric.dumazet
In-Reply-To: <20180719.234329.512279372120817504.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Thu, Jul 19 2018, David Miller wrote:
> From: NeilBrown <neilb@suse.com>
> Date: Fri, 20 Jul 2018 16:30:34 +1000
>
>> Does this ruling also apply to the bit-spin-lock changes and the
>> per-cpu-counter changes that I have proposed? These improve
>> scalability when updates dominate. Not having these in mainline
>> would mean I need to carry a separate rhashtables implementation for
>> lustre, which means code diversion which isn't healthy in the long
>> run.
>
> If it helps existing rhashtable users generally, then it is fine,
> since it will actually be tested by upstream users.
Good, thanks.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH net] multicast: remove useless parameter for group add
From: Hangbin Liu @ 2018-07-20 6:07 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Hangbin Liu
Remove the mode parameter for igmp/igmp6_group_added as we can get it
from first parameter.
Fixes: 6e2059b53f988 (ipv4/igmp: init group mode as INCLUDE when join source group)
Fixes: c7ea20c9da5b9 (ipv6/mcast: init as INCLUDE when join SSM INCLUDE group)
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv4/igmp.c | 10 +++++-----
net/ipv6/mcast.c | 8 ++++----
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 28fef7d..bae9096 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1288,7 +1288,7 @@ static void igmp_group_dropped(struct ip_mc_list *im)
#endif
}
-static void igmp_group_added(struct ip_mc_list *im, unsigned int mode)
+static void igmp_group_added(struct ip_mc_list *im)
{
struct in_device *in_dev = im->interface;
#ifdef CONFIG_IP_MULTICAST
@@ -1320,7 +1320,7 @@ static void igmp_group_added(struct ip_mc_list *im, unsigned int mode)
* not send filter-mode change record as the mode should be from
* IN() to IN(A).
*/
- if (mode == MCAST_EXCLUDE)
+ if (im->sfmode == MCAST_EXCLUDE)
im->crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
igmp_ifc_event(in_dev);
@@ -1431,7 +1431,7 @@ void __ip_mc_inc_group(struct in_device *in_dev, __be32 addr, unsigned int mode)
#ifdef CONFIG_IP_MULTICAST
igmpv3_del_delrec(in_dev, im);
#endif
- igmp_group_added(im, mode);
+ igmp_group_added(im);
if (!in_dev->dead)
ip_rt_multicast_event(in_dev);
out:
@@ -1698,7 +1698,7 @@ void ip_mc_remap(struct in_device *in_dev)
#ifdef CONFIG_IP_MULTICAST
igmpv3_del_delrec(in_dev, pmc);
#endif
- igmp_group_added(pmc, pmc->sfmode);
+ igmp_group_added(pmc);
}
}
@@ -1761,7 +1761,7 @@ void ip_mc_up(struct in_device *in_dev)
#ifdef CONFIG_IP_MULTICAST
igmpv3_del_delrec(in_dev, pmc);
#endif
- igmp_group_added(pmc, pmc->sfmode);
+ igmp_group_added(pmc);
}
}
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index f60f310..4ae54aa 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -660,7 +660,7 @@ bool inet6_mc_check(struct sock *sk, const struct in6_addr *mc_addr,
return rv;
}
-static void igmp6_group_added(struct ifmcaddr6 *mc, unsigned int mode)
+static void igmp6_group_added(struct ifmcaddr6 *mc)
{
struct net_device *dev = mc->idev->dev;
char buf[MAX_ADDR_LEN];
@@ -690,7 +690,7 @@ static void igmp6_group_added(struct ifmcaddr6 *mc, unsigned int mode)
* should not send filter-mode change record as the mode
* should be from IN() to IN(A).
*/
- if (mode == MCAST_EXCLUDE)
+ if (mc->mca_sfmode == MCAST_EXCLUDE)
mc->mca_crcount = mc->idev->mc_qrv;
mld_ifc_event(mc->idev);
@@ -931,7 +931,7 @@ static int __ipv6_dev_mc_inc(struct net_device *dev,
write_unlock_bh(&idev->lock);
mld_del_delrec(idev, mc);
- igmp6_group_added(mc, mode);
+ igmp6_group_added(mc);
ma_put(mc);
return 0;
}
@@ -2571,7 +2571,7 @@ void ipv6_mc_up(struct inet6_dev *idev)
ipv6_mc_reset(idev);
for (i = idev->mc_list; i; i = i->next) {
mld_del_delrec(idev, i);
- igmp6_group_added(i, i->mca_sfmode);
+ igmp6_group_added(i);
}
read_unlock_bh(&idev->lock);
}
--
2.5.5
^ permalink raw reply related
* Re: [SPAM]Re: [PATCH] net: mediatek: use dma_zalloc_coherent instead of allocator/memset
From: Sean Wang @ 2018-07-20 6:54 UTC (permalink / raw)
To: YueHaibing
Cc: nbd, nelson.chang, netdev, Russell King - ARM Linux, linux-kernel,
linux-mediatek, john, matthias.bgg, davem, linux-arm-kernel
In-Reply-To: <9a4cdfc6-7487-5908-b584-f3bf6158c4d4@huawei.com>
On Fri, 2018-07-20 at 14:30 +0800, YueHaibing wrote:
> On 2018/7/20 1:02, Sean Wang wrote:
> > On Thu, 2018-07-19 at 15:17 +0100, Russell King - ARM Linux wrote:
> >> On Thu, Jul 19, 2018 at 10:09:55PM +0800, YueHaibing wrote:
> >>> Use dma_zalloc_coherent instead of dma_alloc_coherent
> >>> followed by memset 0.
> >>>
> >>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> >>> ---
> >>> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-----
> >>> 1 file changed, 2 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> >>> index d8ebf0a..fbdb3e3 100644
> >>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> >>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> >>> @@ -1221,14 +1221,11 @@ static int mtk_tx_alloc(struct mtk_eth *eth)
> >>> if (!ring->buf)
> >>> goto no_tx_mem;
> >>>
> >>> - ring->dma = dma_alloc_coherent(eth->dev,
> >>> - MTK_DMA_SIZE * sz,
> >>> - &ring->phys,
> >>> - GFP_ATOMIC | __GFP_ZERO);
> >>> + ring->dma = dma_zalloc_coherent(eth->dev, MTK_DMA_SIZE * sz,
> >>> + &ring->phys, GFP_ATOMIC | __GFP_ZERO);
> >>> if (!ring->dma)
> >>> goto no_tx_mem;
> >>>
> >>> - memset(ring->dma, 0, MTK_DMA_SIZE * sz);
> >>
> >> I have to wonder whether this code needs two forms of zeroing... in
> >> the original code, __GFP_ZERO _and_ a call to memset() just in case
> >> __GFP_ZERO failed to do its job, and in the replacement code, just
> >> in case dma_zalloc_coherent() hasn't got the idea...
> >>
> >> I think you can drop the __GFP_ZERO. ;)
> >>
> >
> > Just now I did an experiment on 4.14.56 on armv7. I found that
> > dma_zalloc_coherent does not guarantee that the buffer we get
> > is all filled with 0.
> >
> >
> > I really think it's a little bit weird OR what was I missing something
> > for enabling dma_zalloc_coherent ? The result seems to tell that we
> > can't remove freely the memset with 0 at this moment until we get a
> > cause.
> >
>
> That means dma_zalloc_coherent doesn't work as expect on armv7?
>
I'm not sure if it's true for every armv7. or it's only happening on my
device.
anyway, i think we can replace all occurrences in the driver for
dma_alloc_coherent with __GFP_ZERO by dma_zalloc_coherent, and but
keep the extra memset as is.
Sean
> >
> > my test code is
> >
> > ring->dma = dma_zalloc_coherent(eth->dev,
> > MTK_DMA_SIZE * sz,
> > &ring->phys,
> > GFP_ATOMIC);
> > if (!ring->dma)
> > goto no_tx_mem;
> >
> > print_hex_dump(KERN_INFO, "mtk_tx_alloc:",
> > DUMP_PREFIX_OFFSET, 16, 1,
> > ring->dma, MTK_DMA_SIZE * sz, false);
> >
> > memset(ring->dma, 0, MTK_DMA_SIZE * sz);
> >
> > print_hex_dump(KERN_INFO, "mtk_tx_alloc2:",
> > DUMP_PREFIX_OFFSET, 16, 1,
> > ring->dma, MTK_DMA_SIZE * sz, false);
> >
> >
> > and the output
> >
> > ...
> >
> > [ 259.610413] mtk_tx_alloc:00000f40: 00 00 00 00 50 1f 00 bc 00 00 00 c0 00 00 00 00
> > [ 259.617934] mtk_tx_alloc:00000f50: 00 00 00 00 60 1f 00 bc 00 00 00 c0 00 00 00 00
> > [ 259.625470] mtk_tx_alloc:00000f60: 00 00 00 00 70 1f 00 bc 00 00 00 c0 00 00 00 00
> > [ 259.633005] mtk_tx_alloc:00000f70: 00 00 00 00 80 1f 00 bc 00 00 00 c0 00 00 00 00
> > [ 259.640539] mtk_tx_alloc:00000f80: 00 00 00 00 90 1f 00 bc 00 00 00 c0 00 00 00 00
> > [ 259.648073] mtk_tx_alloc:00000f90: 00 00 00 00 a0 1f 00 bc 00 00 00 c0 00 00 00 00
> > [ 259.655590] mtk_tx_alloc:00000fa0: 00 00 00 00 b0 1f 00 bc 00 00 00 c0 00 00 00 00
> > [ 259.663124] mtk_tx_alloc:00000fb0: 00 00 00 00 c0 1f 00 bc 00 00 00 c0 00 00 00 00
> > [ 259.670660] mtk_tx_alloc:00000fc0: 00 00 00 00 d0 1f 00 bc 00 00 00 c0 00 00 00 00
> > [ 259.678196] mtk_tx_alloc:00000fd0: 00 00 00 00 e0 1f 00 bc 00 00 00 c0 00 00 00 00
> > [ 259.685713] mtk_tx_alloc:00000fe0: 00 00 00 00 f0 1f 00 bc 00 00 00 c0 00 00 00 00
> > [ 259.693247] mtk_tx_alloc:00000ff0: 02 c0 90 ad 00 10 00 bc 00 40 5a c0 00 00 00 02
> > [ 259.700782] mtk_tx_alloc2:00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [ 259.708405] mtk_tx_alloc2:00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [ 259.716013] mtk_tx_alloc2:00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [ 259.723634] mtk_tx_alloc2:00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [ 259.731253] mtk_tx_alloc2:00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [ 259.738875] mtk_tx_alloc2:00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [ 259.746481] mtk_tx_alloc2:00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [ 259.754103] mtk_tx_alloc2:00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [ 259.761723] mtk_tx_alloc2:00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [ 259.769344] mtk_tx_alloc2:00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > [ 259.776951] mtk_tx_alloc2:000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >
> > ....
> >
> >
> > Sean
> >
> >
> >
> > .
> >
>
^ permalink raw reply
* [PATCH net] multicast: do not restore deleted record source filter mode to new one
From: Hangbin Liu @ 2018-07-20 6:04 UTC (permalink / raw)
To: netdev
Cc: WANG Cong, YOSHIFUJI Hideaki, David Miller, Daniel Borkmann,
Hangbin Liu
There are two scenarios that we will restore deleted records. The first is
when device down and up(or unmap/remap). In this scenario the new filter
mode is same with previous one. Because we get it from in_dev->mc_list and
we do not touch it during device down and up.
The other scenario is when a new socket join a group which was just delete
and not finish sending status reports. In this scenario, we should use the
current filter mode instead of restore old one. Here are 4 cases in total.
old_socket new_socket before_fix after_fix
IN(A) IN(A) ALLOW(A) ALLOW(A)
IN(A) EX( ) TO_IN( ) TO_EX( )
EX( ) IN(A) TO_EX( ) ALLOW(A)
EX( ) EX( ) TO_EX( ) TO_EX( )
Fixes: 24803f38a5c0b (igmp: do not remove igmp souce list info when set link down)
Fixes: 1666d49e1d416 (mld: do not remove mld souce list info when set link down)
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv4/igmp.c | 3 +--
net/ipv6/mcast.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index b3c899a..28fef7d 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1200,8 +1200,7 @@ static void igmpv3_del_delrec(struct in_device *in_dev, struct ip_mc_list *im)
spin_lock_bh(&im->lock);
if (pmc) {
im->interface = pmc->interface;
- im->sfmode = pmc->sfmode;
- if (pmc->sfmode == MCAST_INCLUDE) {
+ if (im->sfmode == MCAST_INCLUDE) {
im->tomb = pmc->tomb;
im->sources = pmc->sources;
for (psf = im->sources; psf; psf = psf->sf_next)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 2699be7..f60f310 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -790,8 +790,7 @@ static void mld_del_delrec(struct inet6_dev *idev, struct ifmcaddr6 *im)
spin_lock_bh(&im->mca_lock);
if (pmc) {
im->idev = pmc->idev;
- im->mca_sfmode = pmc->mca_sfmode;
- if (pmc->mca_sfmode == MCAST_INCLUDE) {
+ if (im->mca_sfmode == MCAST_INCLUDE) {
im->mca_tomb = pmc->mca_tomb;
im->mca_sources = pmc->mca_sources;
for (psf = im->mca_sources; psf; psf = psf->sf_next)
--
2.5.5
^ permalink raw reply related
* Re: [PATCH - revised] rhashtable: detect when object movement might have invalidated a lookup
From: David Miller @ 2018-07-20 6:43 UTC (permalink / raw)
To: neilb; +Cc: herbert, tgraf, netdev, linux-kernel, eric.dumazet
In-Reply-To: <87va9aqv05.fsf@notabene.neil.brown.name>
From: NeilBrown <neilb@suse.com>
Date: Fri, 20 Jul 2018 16:30:34 +1000
> Does this ruling also apply to the bit-spin-lock changes and the
> per-cpu-counter changes that I have proposed? These improve
> scalability when updates dominate. Not having these in mainline
> would mean I need to carry a separate rhashtables implementation for
> lustre, which means code diversion which isn't healthy in the long
> run.
If it helps existing rhashtable users generally, then it is fine,
since it will actually be tested by upstream users.
Thanks.
^ permalink raw reply
* Re: [SPAM]Re: [PATCH] net: mediatek: use dma_zalloc_coherent instead of allocator/memset
From: YueHaibing @ 2018-07-20 6:30 UTC (permalink / raw)
To: Sean Wang, Russell King - ARM Linux
Cc: nbd, nelson.chang, netdev, linux-kernel, linux-mediatek, john,
matthias.bgg, davem, linux-arm-kernel
In-Reply-To: <1532019744.8953.248.camel@mtkswgap22>
On 2018/7/20 1:02, Sean Wang wrote:
> On Thu, 2018-07-19 at 15:17 +0100, Russell King - ARM Linux wrote:
>> On Thu, Jul 19, 2018 at 10:09:55PM +0800, YueHaibing wrote:
>>> Use dma_zalloc_coherent instead of dma_alloc_coherent
>>> followed by memset 0.
>>>
>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>> ---
>>> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-----
>>> 1 file changed, 2 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>> index d8ebf0a..fbdb3e3 100644
>>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>> @@ -1221,14 +1221,11 @@ static int mtk_tx_alloc(struct mtk_eth *eth)
>>> if (!ring->buf)
>>> goto no_tx_mem;
>>>
>>> - ring->dma = dma_alloc_coherent(eth->dev,
>>> - MTK_DMA_SIZE * sz,
>>> - &ring->phys,
>>> - GFP_ATOMIC | __GFP_ZERO);
>>> + ring->dma = dma_zalloc_coherent(eth->dev, MTK_DMA_SIZE * sz,
>>> + &ring->phys, GFP_ATOMIC | __GFP_ZERO);
>>> if (!ring->dma)
>>> goto no_tx_mem;
>>>
>>> - memset(ring->dma, 0, MTK_DMA_SIZE * sz);
>>
>> I have to wonder whether this code needs two forms of zeroing... in
>> the original code, __GFP_ZERO _and_ a call to memset() just in case
>> __GFP_ZERO failed to do its job, and in the replacement code, just
>> in case dma_zalloc_coherent() hasn't got the idea...
>>
>> I think you can drop the __GFP_ZERO. ;)
>>
>
> Just now I did an experiment on 4.14.56 on armv7. I found that
> dma_zalloc_coherent does not guarantee that the buffer we get
> is all filled with 0.
>
>
> I really think it's a little bit weird OR what was I missing something
> for enabling dma_zalloc_coherent ? The result seems to tell that we
> can't remove freely the memset with 0 at this moment until we get a
> cause.
>
That means dma_zalloc_coherent doesn't work as expect on armv7?
>
> my test code is
>
> ring->dma = dma_zalloc_coherent(eth->dev,
> MTK_DMA_SIZE * sz,
> &ring->phys,
> GFP_ATOMIC);
> if (!ring->dma)
> goto no_tx_mem;
>
> print_hex_dump(KERN_INFO, "mtk_tx_alloc:",
> DUMP_PREFIX_OFFSET, 16, 1,
> ring->dma, MTK_DMA_SIZE * sz, false);
>
> memset(ring->dma, 0, MTK_DMA_SIZE * sz);
>
> print_hex_dump(KERN_INFO, "mtk_tx_alloc2:",
> DUMP_PREFIX_OFFSET, 16, 1,
> ring->dma, MTK_DMA_SIZE * sz, false);
>
>
> and the output
>
> ...
>
> [ 259.610413] mtk_tx_alloc:00000f40: 00 00 00 00 50 1f 00 bc 00 00 00 c0 00 00 00 00
> [ 259.617934] mtk_tx_alloc:00000f50: 00 00 00 00 60 1f 00 bc 00 00 00 c0 00 00 00 00
> [ 259.625470] mtk_tx_alloc:00000f60: 00 00 00 00 70 1f 00 bc 00 00 00 c0 00 00 00 00
> [ 259.633005] mtk_tx_alloc:00000f70: 00 00 00 00 80 1f 00 bc 00 00 00 c0 00 00 00 00
> [ 259.640539] mtk_tx_alloc:00000f80: 00 00 00 00 90 1f 00 bc 00 00 00 c0 00 00 00 00
> [ 259.648073] mtk_tx_alloc:00000f90: 00 00 00 00 a0 1f 00 bc 00 00 00 c0 00 00 00 00
> [ 259.655590] mtk_tx_alloc:00000fa0: 00 00 00 00 b0 1f 00 bc 00 00 00 c0 00 00 00 00
> [ 259.663124] mtk_tx_alloc:00000fb0: 00 00 00 00 c0 1f 00 bc 00 00 00 c0 00 00 00 00
> [ 259.670660] mtk_tx_alloc:00000fc0: 00 00 00 00 d0 1f 00 bc 00 00 00 c0 00 00 00 00
> [ 259.678196] mtk_tx_alloc:00000fd0: 00 00 00 00 e0 1f 00 bc 00 00 00 c0 00 00 00 00
> [ 259.685713] mtk_tx_alloc:00000fe0: 00 00 00 00 f0 1f 00 bc 00 00 00 c0 00 00 00 00
> [ 259.693247] mtk_tx_alloc:00000ff0: 02 c0 90 ad 00 10 00 bc 00 40 5a c0 00 00 00 02
> [ 259.700782] mtk_tx_alloc2:00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 259.708405] mtk_tx_alloc2:00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 259.716013] mtk_tx_alloc2:00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 259.723634] mtk_tx_alloc2:00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 259.731253] mtk_tx_alloc2:00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 259.738875] mtk_tx_alloc2:00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 259.746481] mtk_tx_alloc2:00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 259.754103] mtk_tx_alloc2:00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 259.761723] mtk_tx_alloc2:00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 259.769344] mtk_tx_alloc2:00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 259.776951] mtk_tx_alloc2:000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> ....
>
>
> Sean
>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH - revised] rhashtable: detect when object movement might have invalidated a lookup
From: NeilBrown @ 2018-07-20 6:30 UTC (permalink / raw)
To: David Miller; +Cc: herbert, tgraf, netdev, linux-kernel, eric.dumazet
In-Reply-To: <20180719.051440.931407144963903326.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]
On Thu, Jul 19 2018, David Miller wrote:
> From: NeilBrown <neilb@suse.com>
> Date: Mon, 16 Jul 2018 09:57:11 +1000
>
>> Some users of rhashtable might need to change the key
>> of an object and move it to a different location in the table.
>> Other users might want to allocate objects using
>> SLAB_TYPESAFE_BY_RCU which can result in the same memory allocation
>> being used for a different (type-compatible) purpose and similarly
>> end up in a different hash-chain.
>>
>> To support these, we store a unique NULLS_MARKER at the end of
>> each chain, and when a search fails to find a match, we check
>> if the NULLS marker found was the expected one. If not,
>> the search is repeated.
>>
>> The unique NULLS_MARKER is derived from the address of the
>> head of the chain.
>>
>> If an object is removed and re-added to the same hash chain, we won't
>> notice by looking that the NULLS marker. In this case we must be sure
>> that it was not re-added *after* its original location, or a lookup may
>> incorrectly fail. The easiest solution is to ensure it is inserted at
>> the start of the chain. insert_slow() already does that,
>> insert_fast() does not. So this patch changes insert_fast to always
>> insert at the head of the chain.
>>
>> Note that such a user must do their own double-checking of
>> the object found by rhashtable_lookup_fast() after ensuring
>> mutual exclusion which anything that might change the key, such as
>> successfully taking a new reference.
>>
>> Signed-off-by: NeilBrown <neilb@suse.com>
>
> Neil I have to be honest with you.
Thank you.
>
> During this whole ordeal I was under the impression that this was all
> going to be used for something in-tree. But now I see that you want
> to use all of this stuff for lustre which is out of tree.
>
> It would be extremely hard for me to accept adding this kind of
> complexity and weird semantics to an already extremely complicated
> and delicate piece of infrastructure if something in-tree would use
> it.
>
> But for something out-of-tree? I'm sorry, no way.
That's unfortunate, but I can live with it. null-list support is
just a nice-to-have for me.
I'll resend the patch with the unwanted complexity removed.
Does this ruling also apply to the bit-spin-lock changes and the
per-cpu-counter changes that I have proposed?
These improve scalability when updates dominate. Not having these
in mainline would mean I need to carry a separate rhashtables
implementation for lustre, which means code diversion which isn't
healthy in the long run.
(Note that, in my mind, lustre is only temporarily out-of-tree. It is
coming back, hopefully this year).
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] net-next/hinic: fix a problem in hinic_xmit_frame()
From: David Miller @ 2018-07-20 6:28 UTC (permalink / raw)
To: zhaochen6
Cc: linux-kernel, netdev, aviad.krawczyk, tony.qu, yin.yinshi,
luoshaokai
In-Reply-To: <20180718043318.3211-1-zhaochen6@huawei.com>
From: Zhao Chen <zhaochen6@huawei.com>
Date: Wed, 18 Jul 2018 00:33:18 -0400
> The calculation of "wqe_size" is not correct when the tx queue is busy in
> hinic_xmit_frame().
>
> When there are no free WQEs, the tx flow will unmap the skb buffer, then
> ring the doobell for the pending packets. But the "wqe_size" which used
> to calculate the doorbell address is not correct. The wqe size should be
> cleared to 0, otherwise, it will cause a doorbell error.
>
> This patch fixes the problem.
>
> Reported-by: Zhou Wang <wangzhou1@hisilicon.com>
> Signed-off-by: Zhao Chen <zhaochen6@huawei.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH - revised] rhashtable: detect when object movement might have invalidated a lookup
From: NeilBrown @ 2018-07-20 6:24 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, tgraf, netdev, linux-kernel, eric.dumazet
In-Reply-To: <20180717063020.rpqsgrbpwavklxz7@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 929 bytes --]
On Tue, Jul 17 2018, Herbert Xu wrote:
> On Mon, Jul 16, 2018 at 01:26:42PM +1000, NeilBrown wrote:
>>
>> Look in Documenation/RCU/rculist_nulls.txt.
>> The very first example is a typical lookup for a nulls list.
>> The above sample code would read:
>
> OK, but how will this work with rhlist? It would be very bad to
> have a feature that works for rhashtable but fails in strange
> ways when you use rhlist.
It should be easy enough to handle in rhlist too.
When inserting a new object, we put it at the start of the chain, and if
there was already a list with the same key, it gets moved to
the new object.
A walk could see some objects repeatedly when this happens, but that
is already possible.
Thanks,
NeilBrown
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH bpf] bpf: Use option "help" in the llvm-objcopy test
From: Martin KaFai Lau @ 2018-07-20 5:34 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
I noticed the "--version" option of the llvm-objcopy command has recently
disappeared from the master llvm branch. It is currently used as a BTF
support test in tools/testing/selftests/bpf/Makefile.
This patch replaces it with "--help" which should be
less error prone in the future.
Fixes: c0fa1b6c3efc ("bpf: btf: Add BTF tests")
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
---
tools/testing/selftests/bpf/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 7a6214e9ae58..a362e3d7abc6 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -105,7 +105,7 @@ $(OUTPUT)/test_xdp_noinline.o: CLANG_FLAGS += -fno-inline
BTF_LLC_PROBE := $(shell $(LLC) -march=bpf -mattr=help 2>&1 | grep dwarfris)
BTF_PAHOLE_PROBE := $(shell $(BTF_PAHOLE) --help 2>&1 | grep BTF)
-BTF_OBJCOPY_PROBE := $(shell $(LLVM_OBJCOPY) --version 2>&1 | grep LLVM)
+BTF_OBJCOPY_PROBE := $(shell $(LLVM_OBJCOPY) --help 2>&1 | grep -i 'usage.*llvm')
ifneq ($(BTF_LLC_PROBE),)
ifneq ($(BTF_PAHOLE_PROBE),)
--
2.17.1
^ permalink raw reply related
* [PATCH bpf] bpf: btf: Clean up BTF_INT_BITS() in uapi btf.h
From: Martin KaFai Lau @ 2018-07-20 5:14 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
This patch shrinks the BTF_INT_BITS() mask. The current
btf_int_check_meta() ensures the nr_bits of an integer
cannot exceed 64. Hence, it is mostly an uapi cleanup.
The actual btf usage (i.e. seq_show()) is also modified
to use u8 instead of u16. The verification (e.g. btf_int_check_meta())
path stays as is to deal with invalid BTF situation.
Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)")
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
---
include/uapi/linux/btf.h | 2 +-
kernel/bpf/btf.c | 16 ++++++++++------
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/btf.h b/include/uapi/linux/btf.h
index 0b5ddbe135a4..972265f32871 100644
--- a/include/uapi/linux/btf.h
+++ b/include/uapi/linux/btf.h
@@ -76,7 +76,7 @@ struct btf_type {
*/
#define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f000000) >> 24)
#define BTF_INT_OFFSET(VAL) (((VAL & 0x00ff0000)) >> 16)
-#define BTF_INT_BITS(VAL) ((VAL) & 0x0000ffff)
+#define BTF_INT_BITS(VAL) ((VAL) & 0x000000ff)
/* Attributes stored in the BTF_INT_ENCODING */
#define BTF_INT_SIGNED (1 << 0)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index e016ac3afa24..9704934252b3 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -450,7 +450,7 @@ static const struct btf_type *btf_type_by_id(const struct btf *btf, u32 type_id)
*/
static bool btf_type_int_is_regular(const struct btf_type *t)
{
- u16 nr_bits, nr_bytes;
+ u8 nr_bits, nr_bytes;
u32 int_data;
int_data = btf_type_int(t);
@@ -993,12 +993,16 @@ static void btf_int_bits_seq_show(const struct btf *btf,
{
u16 left_shift_bits, right_shift_bits;
u32 int_data = btf_type_int(t);
- u16 nr_bits = BTF_INT_BITS(int_data);
- u16 total_bits_offset;
- u16 nr_copy_bytes;
- u16 nr_copy_bits;
+ u8 nr_bits = BTF_INT_BITS(int_data);
+ u8 total_bits_offset;
+ u8 nr_copy_bytes;
+ u8 nr_copy_bits;
u64 print_num;
+ /*
+ * bits_offset is at most 7.
+ * BTF_INT_OFFSET() cannot exceed 64 bits.
+ */
total_bits_offset = bits_offset + BTF_INT_OFFSET(int_data);
data += BITS_ROUNDDOWN_BYTES(total_bits_offset);
bits_offset = BITS_PER_BYTE_MASKED(total_bits_offset);
@@ -1028,7 +1032,7 @@ static void btf_int_seq_show(const struct btf *btf, const struct btf_type *t,
u32 int_data = btf_type_int(t);
u8 encoding = BTF_INT_ENCODING(int_data);
bool sign = encoding & BTF_INT_SIGNED;
- u32 nr_bits = BTF_INT_BITS(int_data);
+ u8 nr_bits = BTF_INT_BITS(int_data);
if (bits_offset || BTF_INT_OFFSET(int_data) ||
BITS_PER_BYTE_MASKED(nr_bits)) {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 5/5] net: add MTD support to eth_platform_get_mac_address()
From: Sekhar Nori @ 2018-07-20 5:17 UTC (permalink / raw)
To: Bartosz Golaszewski, Andrew Lunn
Cc: Rob Herring, Grygorii Strashko, David Lechner, Ivan Khoronzhuk,
Kevin Hilman, Greg Kroah-Hartman, Russell King,
Linux Kernel Mailing List, Bartosz Golaszewski, Lukas Wunner,
Srinivas Kandagatla, Linux ARM, netdev, Florian Fainelli,
Linux-OMAP, David S . Miller, Dan Carpenter
In-Reply-To: <CAMRc=MeqnRXF_R1J5G8ySvCr8pZhZMHiV3WHNFun=d8GjiOT9A@mail.gmail.com>
On Thursday 19 July 2018 09:05 PM, Bartosz Golaszewski wrote:
> 2018-07-19 17:27 GMT+02:00 Andrew Lunn <andrew@lunn.ch>:
>>> Unfortunately: this would effectively block me from improving the
>>> support for older davinci boards.
>>
>> Is there something blocking you from converting the board to device
>> tree? This is something i did with a lot of the Marvell boards a few
>> years ago. For a while, we had both DT and board setup files. After a
>> couple of cycles, we killed off the setup files.
>>
>> Andrew
>
> Actually some board are supported both in DT and board files
> (da850-evm) right now, but Sekhar wants to keep the support via board
> files in the kernel so that's a no go.
Its not that I want it that way, but we cannot get rid of board files
till DT has equivalent support.
The bigger issue is not on DA850, but on the 5 older DaVinci SoCs which
do not support device-tree based boot today.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
From: Sekhar Nori @ 2018-07-20 5:04 UTC (permalink / raw)
To: Srinivas Kandagatla, Bartosz Golaszewski, Andrew Lunn
Cc: Linux ARM, Rob Herring, Florian Fainelli, David Lechner,
Ivan Khoronzhuk, Kevin Hilman, Greg Kroah-Hartman,
Jonathan Corbet, Russell King, Linux Kernel Mailing List,
Bartosz Golaszewski, Grygorii Strashko, Ladislav Michl, netdev,
Lukas Wunner, linux-omap, David S . Miller, Dan Carpenter
In-Reply-To: <a70aebb0-408c-c61f-897a-227114888585@linaro.org>
On Monday 16 July 2018 02:26 PM, Srinivas Kandagatla wrote:
>
>
> On 16/07/18 09:50, Sekhar Nori wrote:
>> On Friday 13 July 2018 11:30 PM, Bartosz Golaszewski wrote:
>>
>>> We're getting close to rc5 so I'd like to make a case for this series
>>> again.
>>>
>>> I understand that there's more to do than just the changes introduced
>>> here, but we shouldn't try to fix several problems in many different
>>> places at once. There's just too many moving pieces. I'd rather start
>>> merging small improvements right away.
>>>
>>> The idea behind this series is to remove (almost) all users of
>>> at24_platform_data. The davinci_emac patches are there only because we
>>> need to remove some MAC adress reading stuff from the board files.
>>> Having this code there and calling it back from EEPROM/MTD drivers is
>>> already wrong and we should work towards using nvmem for that anyway.
>>>
>>> Currently for MTD the nvmem support series seems to be dead and it's
>>> going to take some time before anything gets upstream.
>>>
>>> So I'd like to again ask you to consider picking up the patches from
>>> this series to your respective trees or at the very least: I'd like to
>>> ask Srinivas to pick up the nvmem patches and Sekhar to take the
>>> first, non-controversial batch of davinci platform changes so that
>>> we'll have less code to carry for the next release.
>>
>> I think those are patches 3-7. I can take those if I get an immutable
>> commit over v4.18-rc1 from Srinivas with patches 1 & 2 applied.
> nvmem patches go via Greg KH char-misc tree, if it makes things easy I
> can provide Ack on nvmem patches, so that you can take these patches via
> your tree?
There is a lot of follow-up traffic on how exactly to develop the needed
interfaces for reading mac address in mtd and/or network subsystem.
But, I don't think any of that negates the need for nvmem lookups that
work for non-device-tree and populating the lookups in mach-davinci
board code.
I am going to send patches 1-7 to ARM-SoC soon, so please do say if
there is any disagreement on this.
Thanks,
Sekhar
>
> Let me know.
>
> --srini
>>
>> Thanks,
>> Sekhar
>>
^ permalink raw reply
* Re: DNAT with VRF support in Linux Kernel
From: David Ahern @ 2018-07-20 3:42 UTC (permalink / raw)
To: D'Souza, Nelson, netdev@vger.kernel.org
In-Reply-To: <35AAB24A-2D10-4C50-9DC3-3BD41F0DE3DF@ciena.com>
On 7/19/18 7:52 PM, D'Souza, Nelson wrote:
> Hi,
>
>
>
> I'm seeing a VRF/Netfilter related issue on a system running a 4.14.52
> Linux kernel.
>
>
>
> I have an eth interface enslaved to l3mdev mgmtvrf device.
>
>
>
> After reviewing
> https://netdevconf.org/1.2/papers/ahern-what-is-l3mdev-paper.pdf, I was
> expecting that the Netfilter NF_INET_PRE_ROUTING rules would be applied
> to packets at the ingress eth interface and VRF device level. I
> confirmed that this works for pre-routing rules added to the raw and
> mangle tables at the ingress interface and VRF device level. I'm having
> issues though with pre-routing rules that are applied to the NAT table.
> NAT pre-routing rules only match on the ingress eth interface, not on
> the mgmtVRF device. As a result, I'm not able to apply DNAT at the
> mgmtvrf device level for IPv4 packets sourced from an external host and
> destined to the eth interface ip address.
>
>
>
> Also observed that a tcpdump on the mgmtvrf device captures packets
> ingressing on the mgmtvrf.
>
>
>
> Please let me know if my understanding is correct, and if so, if this is
> a resolved/outstanding issue.
>
I am puzzled by this one. My main dev server uses mgmt vrf with DNAT
rules to access VMs running on it, so I know it works to some degree. e.g.,
$ sudo iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 409 packets, 68587 bytes)
pkts bytes target prot opt in out source
destination
8761 583K ACCEPT all -- br0 * 0.0.0.0/0
0.0.0.0/0
5 320 DNAT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:2201 to:10.1.1.1:22
...
But, adding LOG rule does not show a hit with dev == mgmt.
^ permalink raw reply
* Re: VRF with enslaved L3 enabled bridge
From: David Ahern @ 2018-07-20 3:37 UTC (permalink / raw)
To: D'Souza, Nelson, netdev@vger.kernel.org
In-Reply-To: <9E3A1F70-E009-49DC-B639-B48B28F99C52@ciena.com>
On 7/19/18 8:19 PM, D'Souza, Nelson wrote:
> Hi,
>
>
>
> I'm seeing the following issue on a system running a 4.14.52 Linux kernel.
>
>
>
> With an eth interface enslaved to a VRF device, pings sent out on the
> VRF to an neighboring host are successful. But, with an eth interface
> enslaved to a L3 enabled bridge (mgmtbr0), and the bridge enslaved to a
> l3mdev VRF (mgmtvrf), the pings sent out on the VRF are not received
> back at the application level.
you mean this setup:
eth1 (ingress port) -> br0 (bridge) -> red (vrf)
IP address on br0:
9: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master
red state UP group default qlen 1000
link/ether 02:e0:f9:1c:00:37 brd ff:ff:ff:ff:ff:ff
inet 10.100.1.4/24 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::e0:f9ff:fe1c:37/64 scope link
valid_lft forever preferred_lft forever
And then ping a neighbor:
# ping -I red -c1 -w1 10.100.1.254
ping: Warning: source address might be selected on device other than red.
PING 10.100.1.254 (10.100.1.254) from 10.100.1.4 red: 56(84) bytes of data.
64 bytes from 10.100.1.254: icmp_seq=1 ttl=64 time=0.810 ms
--- 10.100.1.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.810/0.810/0.810/0.000 ms
>
>
>
> ICMP Echo requests are successfully sent out on the mgmtvrf device to a
> neighboring host. However, ICMP echo replies that are received back from
> the neighboring host via the eth and mgmtbr0 interfaces are not seen at
> the vrf device level and therefore fail to be delivered locally to the
> ping application.
Does tcpdump on each level show the response? tcpdump on eth, tcpdump on
bridge and tcpdump on the vrf device?
>
>
>
> The following LOG rules were added to the raw table, prerouting chain
> and the filter table, OUTPUT chains:
>
>
>
> root@x10sdv-4c-tln4f:~# iptables -t raw -S PREROUTING
>
> -P PREROUTING ACCEPT
>
> -A PREROUTING -s 10.32.8.135/32 -i mgmtbr0 -j LOG
>
> -A PREROUTING -s 10.32.8.135/32 -i mgmtvrf -j LOG
>
>
>
> root@x10sdv-4c-tln4f:~# iptables -S OUTPUT
>
> -P OUTPUT ACCEPT
>
> -A OUTPUT -o mgmtvrf -j LOG
>
> -A OUTPUT -o mgmtbr0 -j LOG
>
>
>
> Pings are sent on the management VRF to a neighboring host (10.32.8.135)
> and the netfilter logs included below:
>
> Note, that in the logs, ICMP echo requests are sent out on the mgmtvrf
> and match the output rules for mgmvrf and mgmtbr0, but the ICMP echo
> replies are only seen on mgmtbr0, not on mgmtvrf
>
>
>
> root@x10sdv-4c-tln4f:~# ping 10.32.8.135 -I mgmtvrf -c 1
>
> PING 10.32.8.135 (10.32.8.135):
>
> 56 data bytes
>
> [ 2679.683027] IN= OUT=mgmtvrf SRC=10.33.96.131 DST=10.32.8.135 LEN=84
> TOS=0x00 PREC=0x00 TTL=64 ID=23921 DF PROTO=ICMP TYPE=8 CODE=0 ID=32610
> SEQ=0 <<< ICMP echo sent on mgmtvrf
>
> [ 2679.697560] IN= OUT=mgmtbr0 SRC=10.33.96.131 DST=10.32.8.135 LEN=84
> TOS=0x00 PREC=0x00 TTL=64 ID=23921 DF PROTO=ICMP TYPE=8 CODE=0 ID=32610
> SEQ=0 <<< ICMP echo sent on mgmtbr0
>
> [ 2679.713312] IN=mgmtbr0 OUT= PHYSIN=ethUSB
> MAC=c0:56:27:90:4f:75:c4:7d:4f:bb:02:e7:08:00 SRC=10.32.8.135
> DST=10.33.96.131 LEN=84 TOS=0x00 PREC=0x00 TTL=62 ID=64949 PROTO=ICMP
> TYPE=0 CODE=0 ID=32610 SEQ=0 <<< ICMP echo reply rcvd on mgmtbr0,
> but not on mgmtvrf
>
>
>
> --- 10.32.8.135 ping statistics ---
>
> 1 packets transmitted, 0 packets received, 100% packet loss <<<<
> ping failed
>
>
>
> I’d like to know if this is an outstanding/resolved issue.
>
This one works (see above), so I suspect it is something with your setup.
^ permalink raw reply
* [PATCH ipsec-next] xfrm: Allow xfrmi if_id to be updated by UPDSA
From: Nathan Harold @ 2018-07-20 2:07 UTC (permalink / raw)
To: netdev; +Cc: lorenzo, benedictwong, nharold
Allow attaching an SA to an xfrm interface id after
the creation of the SA, so that tasks such as keying
which must be done as the SA is created, can remain
separate from the decision on how to route traffic
from an SA. This permits SA creation to be decomposed
in to three separate steps:
1) allocation of a SPI
2) algorithm and key negotiation
3) insertion into the data path
Signed-off-by: Nathan Harold <nharold@google.com>
---
net/xfrm/xfrm_state.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 27c84e63c7ff..c4c563d9be47 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1562,10 +1562,14 @@ int xfrm_state_update(struct xfrm_state *x)
if (x1->curlft.use_time)
xfrm_state_check_expire(x1);
- if (x->props.smark.m || x->props.smark.v) {
+ if (x->props.smark.m || x->props.smark.v || x->if_id) {
spin_lock_bh(&net->xfrm.xfrm_state_lock);
- x1->props.smark = x->props.smark;
+ if (x->props.smark.m || x->props.smark.v)
+ x1->props.smark = x->props.smark;
+
+ if (x->if_id)
+ x1->if_id = x->if_id;
__xfrm_state_bump_genids(x1);
spin_unlock_bh(&net->xfrm.xfrm_state_lock);
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Max Gurtovoy @ 2018-07-20 1:25 UTC (permalink / raw)
To: Steve Wise, 'Sagi Grimberg', 'Leon Romanovsky'
Cc: 'Doug Ledford', 'Jason Gunthorpe',
'RDMA mailing list', 'Saeed Mahameed',
'linux-netdev'
In-Reply-To: <a9c4a70d-d578-0581-09aa-a3a56f3b2c02@opengridcomputing.com>
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
>>> [ 2032.194376] nvme nvme0: failed to connect queue: 9 ret=-18
>>
>> queue 9 is not mapped (overlap).
>> please try the bellow:
>>
>
> This seems to work. Here are three mapping cases: each vector on its
> own cpu, each vector on 1 cpu within the local numa node, and each
> vector having all cpus in its numa node. The 2nd mapping looks kinda
> funny, but I think it achieved what you wanted? And all the cases
> resulted in successful connections.
>
Thanks for testing this.
I slightly improved the setting of the left CPUs and actually used
Sagi's initial proposal.
Sagi,
please review the attached patch and let me know if I should add your
signature on it.
I'll run some perf test early next week on it (meanwhile I run
login/logout with different num_queues successfully and irq settings).
Steve,
It will be great if you can apply the attached in your system and send
your findings.
Regards,
Max,
[-- Attachment #2: 0001-blk-mq-fix-RDMA-queue-cpu-mappings-assignments-for-m.patch --]
[-- Type: text/plain, Size: 4759 bytes --]
From 6f7b98f1c43252f459772390c178fc3ad043fc82 Mon Sep 17 00:00:00 2001
From: Max Gurtovoy <maxg@mellanox.com>
Date: Thu, 19 Jul 2018 12:42:00 +0000
Subject: [PATCH 1/1] blk-mq: fix RDMA queue/cpu mappings assignments for mq
In order to fulfil the block layer cpu <-> queue mapping, all the
allocated queues and all the possible CPUs should be mapped. First,
try to map the queues according to the affinity hint from the underlying
RDMA device. Second, map all the unmapped queues in a naive way to unmapped
CPU. In case we still have unmapped CPUs, use the default blk-mq mappings
to map the rest. This way we guarantee that no matter what is the underlying
affinity, all the possible CPUs and all the allocated block queues will be
mapped.
Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
---
block/blk-mq-cpumap.c | 41 ++++++++++++++++++++++++-----------------
block/blk-mq-rdma.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
include/linux/blk-mq.h | 1 +
3 files changed, 67 insertions(+), 19 deletions(-)
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 3eb169f..02b888f 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -30,29 +30,36 @@ static int get_first_sibling(unsigned int cpu)
return cpu;
}
-int blk_mq_map_queues(struct blk_mq_tag_set *set)
+void blk_mq_map_queue_to_cpu(struct blk_mq_tag_set *set, unsigned int cpu)
{
unsigned int *map = set->mq_map;
unsigned int nr_queues = set->nr_hw_queues;
- unsigned int cpu, first_sibling;
+ unsigned int first_sibling;
- for_each_possible_cpu(cpu) {
- /*
- * First do sequential mapping between CPUs and queues.
- * In case we still have CPUs to map, and we have some number of
- * threads per cores then map sibling threads to the same queue for
- * performace optimizations.
- */
- if (cpu < nr_queues) {
+ /*
+ * First do sequential mapping between CPUs and queues.
+ * In case we still have CPUs to map, and we have some number of
+ * threads per cores then map sibling threads to the same queue for
+ * performace optimizations.
+ */
+ if (cpu < nr_queues) {
+ map[cpu] = cpu_to_queue_index(nr_queues, cpu);
+ } else {
+ first_sibling = get_first_sibling(cpu);
+ if (first_sibling == cpu)
map[cpu] = cpu_to_queue_index(nr_queues, cpu);
- } else {
- first_sibling = get_first_sibling(cpu);
- if (first_sibling == cpu)
- map[cpu] = cpu_to_queue_index(nr_queues, cpu);
- else
- map[cpu] = map[first_sibling];
- }
+ else
+ map[cpu] = map[first_sibling];
}
+}
+EXPORT_SYMBOL_GPL(blk_mq_map_queue_to_cpu);
+
+int blk_mq_map_queues(struct blk_mq_tag_set *set)
+{
+ unsigned int cpu;
+
+ for_each_possible_cpu(cpu)
+ blk_mq_map_queue_to_cpu(set, cpu);
return 0;
}
diff --git a/block/blk-mq-rdma.c b/block/blk-mq-rdma.c
index 996167f..10e4f8a 100644
--- a/block/blk-mq-rdma.c
+++ b/block/blk-mq-rdma.c
@@ -34,14 +34,54 @@ int blk_mq_rdma_map_queues(struct blk_mq_tag_set *set,
{
const struct cpumask *mask;
unsigned int queue, cpu;
+ bool mapped;
+ /* reset all CPUs mapping */
+ for_each_possible_cpu(cpu)
+ set->mq_map[cpu] = UINT_MAX;
+
+ /* Try to map the queues according to affinity */
for (queue = 0; queue < set->nr_hw_queues; queue++) {
mask = ib_get_vector_affinity(dev, first_vec + queue);
if (!mask)
goto fallback;
- for_each_cpu(cpu, mask)
- set->mq_map[cpu] = queue;
+ for_each_cpu(cpu, mask) {
+ if (set->mq_map[cpu] == UINT_MAX) {
+ set->mq_map[cpu] = queue;
+ /* Initialy each queue mapped to 1 cpu */
+ break;
+ }
+ }
+ }
+
+ /* Map the unmapped queues in a naive way */
+ for (queue = 0; queue < set->nr_hw_queues; queue++) {
+ mapped = false;
+ for_each_possible_cpu(cpu) {
+ if (set->mq_map[cpu] == queue) {
+ mapped = true;
+ break;
+ }
+ }
+ if (!mapped) {
+ for_each_possible_cpu(cpu) {
+ if (set->mq_map[cpu] == UINT_MAX) {
+ set->mq_map[cpu] = queue;
+ mapped = true;
+ break;
+ }
+ }
+ }
+ /* This case should never happen */
+ if (WARN_ON_ONCE(!mapped))
+ goto fallback;
+ }
+
+ /* set all the rest of the CPUs */
+ for_each_possible_cpu(cpu) {
+ if (set->mq_map[cpu] == UINT_MAX)
+ blk_mq_map_queue_to_cpu(set, cpu);
}
return 0;
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index e3147eb..d6cd114 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -282,6 +282,7 @@ void blk_mq_tagset_busy_iter(struct blk_mq_tag_set *tagset,
int blk_mq_freeze_queue_wait_timeout(struct request_queue *q,
unsigned long timeout);
+void blk_mq_map_queue_to_cpu(struct blk_mq_tag_set *set, unsigned int cpu);
int blk_mq_map_queues(struct blk_mq_tag_set *set);
void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_queues);
--
1.8.3.1
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with Linus' tree
From: Stephen Rothwell @ 2018-07-20 1:49 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Alexander Sverdlin, Arnd Bergmann
[-- Attachment #1: Type: text/plain, Size: 794 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/cavium/Kconfig
between commit:
e40562abdf81 ("net: cavium: Add fine-granular dependencies on PCI")
from Linus' tree and commit:
74525cc5f5f7 ("net: cavium: add missing PCI dependencies")
from the net-next tree.
I fixed it up (I used the latter version, but they were logically
identical) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: skb_segment() should not return NULL
From: Alexander Duyck @ 2018-07-20 0:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S . Miller, netdev, Eric Dumazet, Alexander Duyck
In-Reply-To: <20180719230438.190659-1-edumazet@google.com>
On Thu, Jul 19, 2018 at 4:04 PM, Eric Dumazet <edumazet@google.com> wrote:
> syzbot caught a NULL deref [1], caused by skb_segment()
>
> skb_segment() has many "goto err;" that assume the @err variable
> contains -ENOMEM.
>
> A successful call to __skb_linearize() should not clear @err,
> otherwise a subsequent memory allocation error could return NULL.
>
> While we are at it, we might use -EINVAL instead of -ENOMEM when
> MAX_SKB_FRAGS limit is reached.
>
> [1]
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> CPU: 0 PID: 13285 Comm: syz-executor3 Not tainted 4.18.0-rc4+ #146
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:tcp_gso_segment+0x3dc/0x1780 net/ipv4/tcp_offload.c:106
> Code: f0 ff ff 0f 87 1c fd ff ff e8 00 88 0b fb 48 8b 75 d0 48 b9 00 00 00 00 00 fc ff df 48 8d be 90 00 00 00 48 89 f8 48 c1 e8 03 <0f> b6 14 08 48 8d 86 94 00 00 00 48 89 c6 83 e0 07 48 c1 ee 03 0f
> RSP: 0018:ffff88019b7fd060 EFLAGS: 00010206
> RAX: 0000000000000012 RBX: 0000000000000020 RCX: dffffc0000000000
> RDX: 0000000000040000 RSI: 0000000000000000 RDI: 0000000000000090
> RBP: ffff88019b7fd0f0 R08: ffff88019510e0c0 R09: ffffed003b5c46d6
> R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: 0000000000000001
> R13: ffff8801d6c581f4 R14: 0000000000000000 R15: ffff8801d6c58128
> FS: 00007fcae64d6700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000004e8664 CR3: 00000001b669b000 CR4: 00000000001406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> tcp4_gso_segment+0x1c3/0x440 net/ipv4/tcp_offload.c:54
> inet_gso_segment+0x64e/0x12d0 net/ipv4/af_inet.c:1342
> inet_gso_segment+0x64e/0x12d0 net/ipv4/af_inet.c:1342
> skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
> __skb_gso_segment+0x3c3/0x880 net/core/dev.c:2865
> skb_gso_segment include/linux/netdevice.h:4099 [inline]
> validate_xmit_skb+0x640/0xf30 net/core/dev.c:3104
> __dev_queue_xmit+0xc14/0x3910 net/core/dev.c:3561
> dev_queue_xmit+0x17/0x20 net/core/dev.c:3602
> neigh_hh_output include/net/neighbour.h:473 [inline]
> neigh_output include/net/neighbour.h:481 [inline]
> ip_finish_output2+0x1063/0x1860 net/ipv4/ip_output.c:229
> ip_finish_output+0x841/0xfa0 net/ipv4/ip_output.c:317
> NF_HOOK_COND include/linux/netfilter.h:276 [inline]
> ip_output+0x223/0x880 net/ipv4/ip_output.c:405
> dst_output include/net/dst.h:444 [inline]
> ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
> iptunnel_xmit+0x567/0x850 net/ipv4/ip_tunnel_core.c:91
> ip_tunnel_xmit+0x1598/0x3af1 net/ipv4/ip_tunnel.c:778
> ipip_tunnel_xmit+0x264/0x2c0 net/ipv4/ipip.c:308
> __netdev_start_xmit include/linux/netdevice.h:4148 [inline]
> netdev_start_xmit include/linux/netdevice.h:4157 [inline]
> xmit_one net/core/dev.c:3034 [inline]
> dev_hard_start_xmit+0x26c/0xc30 net/core/dev.c:3050
> __dev_queue_xmit+0x29ef/0x3910 net/core/dev.c:3569
> dev_queue_xmit+0x17/0x20 net/core/dev.c:3602
> neigh_direct_output+0x15/0x20 net/core/neighbour.c:1403
> neigh_output include/net/neighbour.h:483 [inline]
> ip_finish_output2+0xa67/0x1860 net/ipv4/ip_output.c:229
> ip_finish_output+0x841/0xfa0 net/ipv4/ip_output.c:317
> NF_HOOK_COND include/linux/netfilter.h:276 [inline]
> ip_output+0x223/0x880 net/ipv4/ip_output.c:405
> dst_output include/net/dst.h:444 [inline]
> ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
> ip_queue_xmit+0x9df/0x1f80 net/ipv4/ip_output.c:504
> tcp_transmit_skb+0x1bf9/0x3f10 net/ipv4/tcp_output.c:1168
> tcp_write_xmit+0x1641/0x5c20 net/ipv4/tcp_output.c:2363
> __tcp_push_pending_frames+0xb2/0x290 net/ipv4/tcp_output.c:2536
> tcp_push+0x638/0x8c0 net/ipv4/tcp.c:735
> tcp_sendmsg_locked+0x2ec5/0x3f00 net/ipv4/tcp.c:1410
> tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1447
> inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:641 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:651
> __sys_sendto+0x3d7/0x670 net/socket.c:1797
> __do_sys_sendto net/socket.c:1809 [inline]
> __se_sys_sendto net/socket.c:1805 [inline]
> __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1805
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x455ab9
> Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fcae64d5c68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
> RAX: ffffffffffffffda RBX: 00007fcae64d66d4 RCX: 0000000000455ab9
> RDX: 0000000000000001 RSI: 0000000020000200 RDI: 0000000000000013
> RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000014
> R13: 00000000004c1145 R14: 00000000004d1818 R15: 0000000000000006
> Modules linked in:
> Dumping ftrace buffer:
> (ftrace buffer empty)
>
> Fixes: ddff00d42043 ("net: Move skb_has_shared_frag check out of GRE code and into segmentation")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Alexander Duyck <alexander.h.duyck@intel.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Thanks for fixing this.
Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
> net/core/skbuff.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 8e51f8555e11b95bc48ab334f50571048f705101..fb35b62af2724025f743d61de24f9fb7eb9186a8 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -3720,6 +3720,7 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
> net_warn_ratelimited(
> "skb_segment: too many frags: %u %u\n",
> pos, mss);
> + err = -EINVAL;
> goto err;
> }
>
> @@ -3753,11 +3754,10 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
>
> perform_csum_check:
> if (!csum) {
> - if (skb_has_shared_frag(nskb)) {
> - err = __skb_linearize(nskb);
> - if (err)
> - goto err;
> - }
> + if (skb_has_shared_frag(nskb) &&
> + __skb_linearize(nskb))
> + goto err;
> +
> if (!nskb->remcsum_offload)
> nskb->ip_summed = CHECKSUM_NONE;
> SKB_GSO_CB(nskb)->csum =
> --
> 2.18.0.233.g985f88cf7e-goog
>
^ permalink raw reply
* Re: linux-next: build warning after merge of the net-next tree
From: Stephen Rothwell @ 2018-07-20 1:06 UTC (permalink / raw)
To: Guenter Roeck
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List, Masahiro Yamada, Andrew Lunn
In-Reply-To: <20180719223521.GA30287@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
Hi Guenter,
On Thu, 19 Jul 2018 15:35:21 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>
> Yes, replacing imply with the dependency is what I did in the fixup patch.
> Sorry, I should have copied you: https://patchwork.kernel.org/patch/10534925/
I will use that as a merge fix patch when I merge the net-next tree
today (unless Dave adds it to his tree first).
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net-next 9/9] vhost_net: batch update used ring for datacopy TX
From: Jason Wang @ 2018-07-20 0:15 UTC (permalink / raw)
To: mst, jasowang, netdev; +Cc: kvm, virtualization, linux-kernel
In-Reply-To: <1532045721-4958-1-git-send-email-jasowang@redhat.com>
Like commit e2b3b35eb989 ("vhost_net: batch used ring update in rx"),
this patches implements batch used ring update for datacopy TX
(zerocopy has already done some kind of batching).
Testpmd transmission from guest to host (XDP_DROP on tap) shows 25.8%
improvement (from ~3.1Mpps to ~3.9Mpps) on Broadwell i7-5600U CPU @
2.60GHz machine. Netperf TCP tests does not show obvious differences.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 40 +++++++++++++++++++++++++---------------
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 2fd2f0e3..367d802 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -428,16 +428,31 @@ static int vhost_net_enable_vq(struct vhost_net *n,
return vhost_poll_start(poll, sock->file);
}
+static void vhost_net_signal_used(struct vhost_net_virtqueue *nvq)
+{
+ struct vhost_virtqueue *vq = &nvq->vq;
+ struct vhost_dev *dev = vq->dev;
+
+ if (!nvq->done_idx)
+ return;
+
+ vhost_add_used_and_signal_n(dev, vq, vq->heads, nvq->done_idx);
+ nvq->done_idx = 0;
+}
+
static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
- struct vhost_virtqueue *vq,
+ struct vhost_net_virtqueue *nvq,
unsigned int *out_num, unsigned int *in_num,
bool *busyloop_intr)
{
+ struct vhost_virtqueue *vq = &nvq->vq;
unsigned long uninitialized_var(endtime);
int r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
out_num, in_num, NULL, NULL);
if (r == vq->num && vq->busyloop_timeout) {
+ if (!vhost_sock_zcopy(vq->private_data))
+ vhost_net_signal_used(nvq);
preempt_disable();
endtime = busy_clock() + vq->busyloop_timeout;
while (vhost_can_busy_poll(endtime)) {
@@ -493,7 +508,8 @@ static int get_tx_bufs(struct vhost_net *net,
struct vhost_virtqueue *vq = &nvq->vq;
int ret;
- ret = vhost_net_tx_get_vq_desc(net, vq, out, in, busyloop_intr);
+ ret = vhost_net_tx_get_vq_desc(net, nvq, out, in, busyloop_intr);
+
if (ret < 0 || ret == vq->num)
return ret;
@@ -557,6 +573,9 @@ static void handle_tx_copy(struct vhost_net *net, struct socket *sock)
break;
}
+ vq->heads[nvq->done_idx].id = cpu_to_vhost32(vq, head);
+ vq->heads[nvq->done_idx].len = 0;
+
total_len += len;
if (tx_can_batch(vq, total_len))
msg.msg_flags |= MSG_MORE;
@@ -573,12 +592,15 @@ static void handle_tx_copy(struct vhost_net *net, struct socket *sock)
if (err != len)
pr_debug("Truncated TX packet: len %d != %zd\n",
err, len);
- vhost_add_used_and_signal(&net->dev, vq, head, 0);
+ if (++nvq->done_idx >= VHOST_NET_BATCH)
+ vhost_net_signal_used(nvq);
if (vhost_exceeds_weight(++sent_pkts, total_len)) {
vhost_poll_queue(&vq->poll);
break;
}
}
+
+ vhost_net_signal_used(nvq);
}
static void handle_tx_zerocopy(struct vhost_net *net, struct socket *sock)
@@ -741,18 +763,6 @@ static int sk_has_rx_data(struct sock *sk)
return skb_queue_empty(&sk->sk_receive_queue);
}
-static void vhost_net_signal_used(struct vhost_net_virtqueue *nvq)
-{
- struct vhost_virtqueue *vq = &nvq->vq;
- struct vhost_dev *dev = vq->dev;
-
- if (!nvq->done_idx)
- return;
-
- vhost_add_used_and_signal_n(dev, vq, vq->heads, nvq->done_idx);
- nvq->done_idx = 0;
-}
-
static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk,
bool *busyloop_intr)
{
--
2.7.4
^ 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