* RE: interdependencies with cxgb4 and iw_cxgb4
From: Steve Wise @ 2018-03-20 13:47 UTC (permalink / raw)
To: 'David Miller'
Cc: rajur, dledford, linux-rdma, jgg, netdev, bharat, ganeshgr,
rahul.lakkireddy
In-Reply-To: <20180319.193440.1570733225238398675.davem@davemloft.net>
> From: Steve Wise <swise@opengridcomputing.com>
> Date: Mon, 19 Mar 2018 14:50:57 -0500
>
> > Let me ask a dumb question:� Why cannot one of the maintaners pull the
> > commit from the other mainainer's git repo directly?� IE why have this
> > third trusted/signed git repo that has to be on k.o, from which both
> > maintainers pull?� If one of you can pull it in via a patch series,
> > like you do for all other patches, and then notify the other
> > maintainer to pull it from the first maintainers' repo if the series
> > meets the requirements that it needs to be in both maintainers'
> > repositories?� This avoids adding more staging git repos on k.o.� But
> > probably I'm missing something...
>
> Tree A may not want all of tree B's changes, and vice versa.
I was thinking the special commit would go into a branch that was based on,
say rc1 or rc2 of one of the maintainers. Then both maintainers pull that
into their -next branch. Would that work?
^ permalink raw reply
* Re: interdependencies with cxgb4 and iw_cxgb4
From: Leon Romanovsky @ 2018-03-20 14:03 UTC (permalink / raw)
To: Steve Wise
Cc: 'David Miller', rajur, dledford, linux-rdma, jgg, netdev,
bharat, ganeshgr, rahul.lakkireddy
In-Reply-To: <01a201d3c051$eebbded0$cc339c70$@opengridcomputing.com>
[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]
On Tue, Mar 20, 2018 at 08:47:04AM -0500, Steve Wise wrote:
> > From: Steve Wise <swise@opengridcomputing.com>
> > Date: Mon, 19 Mar 2018 14:50:57 -0500
> >
> > > Let me ask a dumb question: Why cannot one of the maintaners pull the
> > > commit from the other mainainer's git repo directly? IE why have this
> > > third trusted/signed git repo that has to be on k.o, from which both
> > > maintainers pull? If one of you can pull it in via a patch series,
> > > like you do for all other patches, and then notify the other
> > > maintainer to pull it from the first maintainers' repo if the series
> > > meets the requirements that it needs to be in both maintainers'
> > > repositories? This avoids adding more staging git repos on k.o. But
> > > probably I'm missing something...
> >
> > Tree A may not want all of tree B's changes, and vice versa.
>
> I was thinking the special commit would go into a branch that was based on,
> say rc1 or rc2 of one of the maintainers. Then both maintainers pull that
> into their -next branch. Would that work?
Steve,
It is more or less what we are doing with our shared PR, we just
"offloaded" the overhead of creating and maintaining that special
branch from maintainers. I don't think that anyone here will say no
to you to create that special branch from time to time.
Thanks
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [bpf-next V2 PATCH 10/15] xdp: rhashtable with allocator ID to pointer mapping
From: Jesper Dangaard Brouer @ 2018-03-20 14:27 UTC (permalink / raw)
To: Jason Wang
Cc: netdev, BjörnTöpel, magnus.karlsson, eugenia,
John Fastabend, Eran Ben Elisha, Saeed Mahameed, galp,
Daniel Borkmann, Alexei Starovoitov, Tariq Toukan, brouer
In-Reply-To: <6950eb76-8e3d-60f2-6de1-005a4e4fd3f6@redhat.com>
On Tue, 20 Mar 2018 10:26:50 +0800
Jason Wang <jasowang@redhat.com> wrote:
> On 2018年03月19日 17:48, Jesper Dangaard Brouer wrote:
> > On Fri, 16 Mar 2018 16:45:30 +0800
> > Jason Wang <jasowang@redhat.com> wrote:
> >
> >> On 2018年03月10日 00:07, Jesper Dangaard Brouer wrote:
> >>> On Fri, 9 Mar 2018 21:07:36 +0800
> >>> Jason Wang <jasowang@redhat.com> wrote:
> >>>
> >>>>>>> Use the IDA infrastructure for getting a cyclic increasing ID number,
> >>>>>>> that is used for keeping track of each registered allocator per
> >>>>>>> RX-queue xdp_rxq_info.
> >>>>>>>
> >>>>>>> Signed-off-by: Jesper Dangaard Brouer<brouer@redhat.com>
> >>>>>> A stupid question is, can we manage to unify this ID with NAPI id?
> >>>>> Sorry I don't understand the question?
> >>>> I mean can we associate page poll pointer to napi_struct, record NAPI id
> >>>> in xdp_mem_info and do lookup through NAPI id?
> >>> No. The driver can unreg/reg a new XDP memory model,
> >>
> >> Is there an actual use case for this?
> >
> > I believe this is the common use case. When attaching an XDP/bpf prog,
> > then the driver usually want to change the RX-ring memory model
> > (different performance trade off).
>
> Right, but a single driver should only have one XDP memory model.
No! -- a driver can have multiple XDP memory models, based on different
performance trade offs and hardware capabilities.
The mlx5 (100Gbit/s) driver/hardware is a good example, which need
different memory models. It already support multiple RX memory models,
depending on HW support. So, I predict that we hit at performance
limit around 42Mpps on PCIe (I can measure 36Mpps), this is due to
PCI-express translations/sec limit. The mlx5 HW supports a compressed
descriptor format which deliver packets in several pages (based on
offset and len), thus lowering the needed PCIe transactions. The
pitfall is that this comes tail room limitations, which can be okay if
e.g. the users use-case does not involve cpumap.
Plus, when a driver need to support AF_XDP zero-copy, that also count
as another XDP memory model...
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: pull request: bluetooth 2018-03-16
From: David Miller @ 2018-03-20 14:29 UTC (permalink / raw)
To: marcel; +Cc: johan.hedberg, linux-bluetooth, netdev
In-Reply-To: <2162D348-7B5F-4693-87AB-8835A1638CF3@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Tue, 20 Mar 2018 09:44:37 +0100
> any issue with this pull request? I ask since it seems to have
> disappeared from patchwork.
Should be pulled in now, don't know how that happened ;-)
Thanks.
^ permalink raw reply
* Re: [RFC PATCH] net: phy: Added device tree binding for dev-addr and dev-addr code check-up and usage
From: Andrew Lunn @ 2018-03-20 14:30 UTC (permalink / raw)
To: Vicentiu Galanopulo
Cc: f.fainelli, netdev, linux-kernel, robh+dt, mark.rutland, davem,
marcel, devicetree, madalin.bucur, alexandru.marginean
In-Reply-To: <20180320134615.17817-1-vicentiu.galanopulo@nxp.com>
On Tue, Mar 20, 2018 at 08:46:15AM -0500, Vicentiu Galanopulo wrote:
> Reason for this patch is that the Inphi PHY
> has a vendor specific address space for accessing
> the C45 MDIO registers - starting from 0x1e.
>
> A new function has been added, get_phy_c45_dev_addr,
> which loops through all the PHY device nodes under
> a MDIO bus node and looks for the <dev-addr> property. If
> it's not set/found, the get_phy_c45_devs_in_pkg,
> will be called with the value 0 as dev_addr parameter,
> else it will be called with the dev-addr property
> value from the device tree.
This seems like the wrong way to implement this. How about:
of_mdiobus_register(), when it loops over the children, looks for the
new property. If found, it passed dev-id to of_mdiobus_register_phy().
That passes it to get_phy_device(). I think get_phy_device() can then
set the ID in c45_ids, before passing it to
get_phy_id(). get_phy_c45_ids() will first look at devices in package
and can add further devices to c45_ids. It will then probe both those
found, and the static one you added.
Andrew
^ permalink raw reply
* Re: [PATCH] Add possibility to turn off promiscuous mode
From: David Miller @ 2018-03-20 14:36 UTC (permalink / raw)
To: s.mondwurf; +Cc: vbridger, netdev, nios2-dev
In-Reply-To: <1ad29d4d-ec70-381e-9d57-86f916d6799c@astro-kom.de>
From: Stephan Mondwurf <s.mondwurf@astro-kom.de>
Date: Tue, 20 Mar 2018 11:28:20 +0100
> The driver is capable of switching on the promiscuous mode.
>
> This patch adds the possibility to turn it off again.
>
> Signed-off-by: Stephan Mondwurf <s.mondwurf@astro-kom.de>
Please fix your patch submissions.
Your subject line should have an appropriate subsystem prefix, for
drivers like this simply "altera: " is sufficient. You should
also specify what tree your patch is targetting in the '[PATCH]'
string. So together that means:
Subject: [PATCH net] altera: Add possibility to turn off promiscuous mode
or:
Subject: [PATCH net-next] altera: Add possibility to turn off promiscuous mode
Also, your patches has both been completely corrupted by your email
client. Long lines have been split up.
Please email the patch to yourself, and try to apply it. Do not
resubmit the patch to the list here until you can do that
successfully.
Thank you.
^ permalink raw reply
* RE: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write
From: David Laight @ 2018-03-20 14:40 UTC (permalink / raw)
To: 'Rahul Lakkireddy', Thomas Gleixner
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
davem@davemloft.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <20180320133206.GB25574@chelsio.com>
From: Rahul Lakkireddy
> Sent: 20 March 2018 13:32
...
> On High Availability Server, the logs of the failing system must be
> collected as quickly as possible. So, we're concerned with the amount
> of time taken to collect our large on-chip memory. We see improvement
> in doing 256-bit reads at a time.
Two other options:
1) Get the device to DMA into host memory.
2) Use mmap() (and vm_iomap_memory() in your driver) to get direct
userspace access to the (I assume) PCIe memory space.
You can then use whatever copy instructions the cpu has.
(Just don't use memcpy().)
David
^ permalink raw reply
* Re: interdependencies with cxgb4 and iw_cxgb4
From: David Miller @ 2018-03-20 14:40 UTC (permalink / raw)
To: swise
Cc: rajur, dledford, linux-rdma, jgg, netdev, bharat, ganeshgr,
rahul.lakkireddy
In-Reply-To: <01a201d3c051$eebbded0$cc339c70$@opengridcomputing.com>
From: "Steve Wise" <swise@opengridcomputing.com>
Date: Tue, 20 Mar 2018 08:47:04 -0500
>> From: Steve Wise <swise@opengridcomputing.com>
>> Date: Mon, 19 Mar 2018 14:50:57 -0500
>>
>> > Let me ask a dumb question:� Why cannot one of the maintaners pull the
>> > commit from the other mainainer's git repo directly?� IE why have this
>> > third trusted/signed git repo that has to be on k.o, from which both
>> > maintainers pull?� If one of you can pull it in via a patch series,
>> > like you do for all other patches, and then notify the other
>> > maintainer to pull it from the first maintainers' repo if the series
>> > meets the requirements that it needs to be in both maintainers'
>> > repositories?� This avoids adding more staging git repos on k.o.� But
>> > probably I'm missing something...
>>
>> Tree A may not want all of tree B's changes, and vice versa.
>
> I was thinking the special commit would go into a branch that was based on,
> say rc1 or rc2 of one of the maintainers. Then both maintainers pull that
> into their -next branch. Would that work?
That makes things more complicated.
The simplest design is that "identical" commits end up in both the
RDMA and the net-next tree.
Then it absolutely doesn't matter whose tree goes into Linus's first.
Also, we should not be merging "merge window" code after -rc1. "-rc1"
means the merge window is closed.
^ permalink raw reply
* Re: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write
From: Alexander Duyck @ 2018-03-20 14:42 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: Thomas Gleixner, x86@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
davem@davemloft.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <20180320133206.GB25574@chelsio.com>
On Tue, Mar 20, 2018 at 6:32 AM, Rahul Lakkireddy
<rahul.lakkireddy@chelsio.com> wrote:
> On Monday, March 03/19/18, 2018 at 20:13:10 +0530, Thomas Gleixner wrote:
>> On Mon, 19 Mar 2018, Rahul Lakkireddy wrote:
>>
>> > Use VMOVDQU AVX CPU instruction when available to do 256-bit
>> > IO read and write.
>>
>> That's not what the patch does. See below.
>>
>> > Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
>> > Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
>>
>> That Signed-off-by chain is wrong....
>>
>> > +#ifdef CONFIG_AS_AVX
>> > +#include <asm/fpu/api.h>
>> > +
>> > +static inline u256 __readqq(const volatile void __iomem *addr)
>> > +{
>> > + u256 ret;
>> > +
>> > + kernel_fpu_begin();
>> > + asm volatile("vmovdqu %0, %%ymm0" :
>> > + : "m" (*(volatile u256 __force *)addr));
>> > + asm volatile("vmovdqu %%ymm0, %0" : "=m" (ret));
>> > + kernel_fpu_end();
>> > + return ret;
>>
>> You _cannot_ assume that the instruction is available just because
>> CONFIG_AS_AVX is set. The availability is determined by the runtime
>> evaluated CPU feature flags, i.e. X86_FEATURE_AVX.
>>
>
> Ok. Will add boot_cpu_has(X86_FEATURE_AVX) check as well.
>
>> Aside of that I very much doubt that this is faster than 4 consecutive
>> 64bit reads/writes as you have the full overhead of
>> kernel_fpu_begin()/end() for each access.
>>
>> You did not provide any numbers for this so its even harder to
>> determine.
>>
>
> Sorry about that. Here are the numbers with and without this series.
>
> When reading up to 2 GB on-chip memory via MMIO, the time taken:
>
> Without Series With Series
> (64-bit read) (256-bit read)
>
> 52 seconds 26 seconds
>
> As can be seen, we see good improvement with doing 256-bits at a
> time.
Instead of framing this as an enhanced version of the read/write ops
why not look at replacing or extending something like the
memcpy_fromio or memcpy_toio operations? It would probably be more
comparable to what you are doing if you are wanting to move large
chunks of memory from one region to another, and it should translate
into something like AVX instructions once the CPU optimizations kick
in for a memcpy.
- Alex
^ permalink raw reply
* [PATCH net] ipv6: sr: fix scheduling in RCU when creating seg6 lwtunnel state
From: David Lebrun @ 2018-03-20 14:44 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun, David Lebrun
From: David Lebrun <dlebrun@google.com>
The seg6_build_state() function is called with RCU read lock held,
so we cannot use GFP_KERNEL. This patch uses GFP_ATOMIC instead.
[ 92.770271] =============================
[ 92.770628] WARNING: suspicious RCU usage
[ 92.770921] 4.16.0-rc4+ #12 Not tainted
[ 92.771277] -----------------------------
[ 92.771585] ./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side critical section!
[ 92.772279]
[ 92.772279] other info that might help us debug this:
[ 92.772279]
[ 92.773067]
[ 92.773067] rcu_scheduler_active = 2, debug_locks = 1
[ 92.773514] 2 locks held by ip/2413:
[ 92.773765] #0: (rtnl_mutex){+.+.}, at: [<00000000e5461720>] rtnetlink_rcv_msg+0x441/0x4d0
[ 92.774377] #1: (rcu_read_lock){....}, at: [<00000000df4f161e>] lwtunnel_build_state+0x59/0x210
[ 92.775065]
[ 92.775065] stack backtrace:
[ 92.775371] CPU: 0 PID: 2413 Comm: ip Not tainted 4.16.0-rc4+ #12
[ 92.775791] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc27 04/01/2014
[ 92.776608] Call Trace:
[ 92.776852] dump_stack+0x7d/0xbc
[ 92.777130] __schedule+0x133/0xf00
[ 92.777393] ? unwind_get_return_address_ptr+0x50/0x50
[ 92.777783] ? __sched_text_start+0x8/0x8
[ 92.778073] ? rcu_is_watching+0x19/0x30
[ 92.778383] ? kernel_text_address+0x49/0x60
[ 92.778800] ? __kernel_text_address+0x9/0x30
[ 92.779241] ? unwind_get_return_address+0x29/0x40
[ 92.779727] ? pcpu_alloc+0x102/0x8f0
[ 92.780101] _cond_resched+0x23/0x50
[ 92.780459] __mutex_lock+0xbd/0xad0
[ 92.780818] ? pcpu_alloc+0x102/0x8f0
[ 92.781194] ? seg6_build_state+0x11d/0x240
[ 92.781611] ? save_stack+0x9b/0xb0
[ 92.781965] ? __ww_mutex_wakeup_for_backoff+0xf0/0xf0
[ 92.782480] ? seg6_build_state+0x11d/0x240
[ 92.782925] ? lwtunnel_build_state+0x1bd/0x210
[ 92.783393] ? ip6_route_info_create+0x687/0x1640
[ 92.783846] ? ip6_route_add+0x74/0x110
[ 92.784236] ? inet6_rtm_newroute+0x8a/0xd0
Fixes: 6c8702c60b886 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
Signed-off-by: David Lebrun <dlebrun@google.com>
---
net/ipv6/seg6_iptunnel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index bd6cc688bd19..8367b859a934 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -418,7 +418,7 @@ static int seg6_build_state(struct nlattr *nla,
slwt = seg6_lwt_lwtunnel(newts);
- err = dst_cache_init(&slwt->cache, GFP_KERNEL);
+ err = dst_cache_init(&slwt->cache, GFP_ATOMIC);
if (err) {
kfree(newts);
return err;
--
2.16.2.804.g6dcf76e118-goog
^ permalink raw reply related
* [PATCH net] ipv6: sr: fix NULL pointer dereference when setting encap source address
From: David Lebrun @ 2018-03-20 14:44 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun, David Lebrun
From: David Lebrun <dlebrun@google.com>
When using seg6 in encap mode, we call ipv6_dev_get_saddr() to set the
source address of the outer IPv6 header, in case none was specified.
Using skb->dev can lead to BUG() when it is in an inconsistent state.
This patch uses the net_device attached to the skb's dst instead.
[940807.667429] BUG: unable to handle kernel NULL pointer dereference at 000000000000047c
[940807.762427] IP: ipv6_dev_get_saddr+0x8b/0x1d0
[940807.815725] PGD 0 P4D 0
[940807.847173] Oops: 0000 [#1] SMP PTI
[940807.890073] Modules linked in:
[940807.927765] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G W 4.16.0-rc1-seg6bpf+ #2
[940808.028988] Hardware name: HP ProLiant DL120 G6/ProLiant DL120 G6, BIOS O26 09/06/2010
[940808.128128] RIP: 0010:ipv6_dev_get_saddr+0x8b/0x1d0
[940808.187667] RSP: 0018:ffff88043fd836b0 EFLAGS: 00010206
[940808.251366] RAX: 0000000000000005 RBX: ffff88042cb1c860 RCX: 00000000000000fe
[940808.338025] RDX: 00000000000002c0 RSI: ffff88042cb1c860 RDI: 0000000000004500
[940808.424683] RBP: ffff88043fd83740 R08: 0000000000000000 R09: ffffffffffffffff
[940808.511342] R10: 0000000000000040 R11: 0000000000000000 R12: ffff88042cb1c850
[940808.598012] R13: ffffffff8208e380 R14: ffff88042ac8da00 R15: 0000000000000002
[940808.684675] FS: 0000000000000000(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000
[940808.783036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[940808.852975] CR2: 000000000000047c CR3: 00000004255fe000 CR4: 00000000000006e0
[940808.939634] Call Trace:
[940808.970041] <IRQ>
[940808.995250] ? ip6t_do_table+0x265/0x640
[940809.043341] seg6_do_srh_encap+0x28f/0x300
[940809.093516] ? seg6_do_srh+0x1a0/0x210
[940809.139528] seg6_do_srh+0x1a0/0x210
[940809.183462] seg6_output+0x28/0x1e0
[940809.226358] lwtunnel_output+0x3f/0x70
[940809.272370] ip6_xmit+0x2b8/0x530
[940809.313185] ? ac6_proc_exit+0x20/0x20
[940809.359197] inet6_csk_xmit+0x7d/0xc0
[940809.404173] tcp_transmit_skb+0x548/0x9a0
[940809.453304] __tcp_retransmit_skb+0x1a8/0x7a0
[940809.506603] ? ip6_default_advmss+0x40/0x40
[940809.557824] ? tcp_current_mss+0x24/0x90
[940809.605925] tcp_retransmit_skb+0xd/0x80
[940809.654016] tcp_xmit_retransmit_queue.part.17+0xf9/0x210
[940809.719797] tcp_ack+0xa47/0x1110
[940809.760612] tcp_rcv_established+0x13c/0x570
[940809.812865] tcp_v6_do_rcv+0x151/0x3d0
[940809.858879] tcp_v6_rcv+0xa5c/0xb10
[940809.901770] ? seg6_output+0xdd/0x1e0
[940809.946745] ip6_input_finish+0xbb/0x460
[940809.994837] ip6_input+0x74/0x80
[940810.034612] ? ip6_rcv_finish+0xb0/0xb0
[940810.081663] ipv6_rcv+0x31c/0x4c0
...
Fixes: 6c8702c60b886 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
Reported-by: Tom Herbert <tom@quantonium.net>
Signed-off-by: David Lebrun <dlebrun@google.com>
---
net/ipv6/seg6_iptunnel.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index 8367b859a934..7a78dcfda68a 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -93,7 +93,8 @@ static void set_tun_src(struct net *net, struct net_device *dev,
/* encapsulate an IPv6 packet within an outer IPv6 header with a given SRH */
int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto)
{
- struct net *net = dev_net(skb_dst(skb)->dev);
+ struct dst_entry *dst = skb_dst(skb);
+ struct net *net = dev_net(dst->dev);
struct ipv6hdr *hdr, *inner_hdr;
struct ipv6_sr_hdr *isrh;
int hdrlen, tot_len, err;
@@ -134,7 +135,7 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto)
isrh->nexthdr = proto;
hdr->daddr = isrh->segments[isrh->first_segment];
- set_tun_src(net, skb->dev, &hdr->daddr, &hdr->saddr);
+ set_tun_src(net, ip6_dst_idev(dst)->dev, &hdr->daddr, &hdr->saddr);
#ifdef CONFIG_IPV6_SEG6_HMAC
if (sr_has_hmac(isrh)) {
--
2.16.2.804.g6dcf76e118-goog
^ permalink raw reply related
* Re: [PATCH] mlx5: Remove call to ida_pre_get
From: David Miller @ 2018-03-20 14:46 UTC (permalink / raw)
To: maorg; +Cc: saeedm, willy, matanb, netdev, linux-rdma, leon
In-Reply-To: <5d362a5b-9697-e1c1-c48c-3d64564f09e7@mellanox.com>
From: Maor Gottlieb <maorg@mellanox.com>
Date: Tue, 20 Mar 2018 14:41:49 +0200
> Saeed, Matan and I okay with this fix as well, it looks like it
> shouldn't impact on the insertion rate.
I've applied this to net-next, thanks everyone.
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: David Miller @ 2018-03-20 14:47 UTC (permalink / raw)
To: liran.alon; +Cc: netdev, linux-kernel, idan.brown, yuval.shaia
In-Reply-To: <1520953642-8145-1-git-send-email-liran.alon@oracle.com>
From: Liran Alon <liran.alon@oracle.com>
Date: Tue, 13 Mar 2018 17:07:22 +0200
> Before this commit, dev_forward_skb() always cleared packet's
> per-network-namespace info. Even if the packet doesn't cross
> network namespaces.
There was a lot of discussion about this patch.
Particularly whether it could potentially break current
users or not.
If this is resolved and the patch should still be applied,
please repost and the folks involved in this dicussion should
add their ACKs.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
From: Andy Lutomirski @ 2018-03-20 14:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, David Laight, Rahul Lakkireddy, x86@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
mingo@redhat.com, hpa@zytor.com, davem@davemloft.net,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
ganeshgr@chelsio.com, nirranjan@chelsio.com, indranil@chelsio.com,
Andy Lutomirski, Peter Zijlstra, Fenghua Yu
In-Reply-To: <20180320082651.jmxvvii2xvmpyr2s@gmail.com>
On Tue, Mar 20, 2018 at 8:26 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Thomas Gleixner <tglx@linutronix.de> wrote:
>
>> > Useful also for code that needs AVX-like registers to do things like CRCs.
>>
>> x86/crypto/ has a lot of AVX optimized code.
>
> Yeah, that's true, but the crypto code is processing fundamentally bigger blocks
> of data, which amortizes the cost of using kernel_fpu_begin()/_end().
>
> kernel_fpu_begin()/_end() is a pretty heavy operation because it does a full FPU
> save/restore via the XSAVE[S] and XRSTOR[S] instructions, which can easily copy a
> thousand bytes around! So kernel_fpu_begin()/_end() is probably a non-starter for
> something small, like a single 256-bit or 512-bit word access.
>
> But there's actually a new thing in modern kernels: we got rid of (most of) lazy
> save/restore FPU code, our new x86 FPU model is very "direct" with no FPU faults
> taken normally.
>
> So assuming the target driver will only load on modern FPUs I *think* it should
> actually be possible to do something like (pseudocode):
>
> vmovdqa %ymm0, 40(%rsp)
> vmovdqa %ymm1, 80(%rsp)
>
> ...
> # use ymm0 and ymm1
> ...
>
> vmovdqa 80(%rsp), %ymm1
> vmovdqa 40(%rsp), %ymm0
>
I think this kinda sorts works, but only kinda sorta:
- I'm a bit worried about newer CPUs where, say, a 256-bit vector
operation will implicitly clear the high 768 bits of the regs. (IIRC
that's how it works for the new VEX stuff.)
- This code will cause XINUSE to be set, which is user-visible and
may have performance and correctness effects. I think the kernel may
already have some but where it occasionally sets XINUSE on its own,
and this caused problems for rr in the past. This might not be a
total showstopper, but it's odd.
I'd rather see us finally finish the work that Rik started to rework
this differently. I'd like kernel_fpu_begin() to look like:
if (test_thread_flag(TIF_NEED_FPU_RESTORE)) {
return; // we're already okay. maybe we need to check
in_interrupt() or something, though?
} else {
XSAVES/XSAVEOPT/XSAVE;
set_thread_flag(TIF_NEED_FPU_RESTORE):
}
and kernel_fpu_end() does nothing at all.
We take the full performance hit for a *single* kernel_fpu_begin() on
an otherwise short syscall or interrupt, but there's no additional
cost for more of them or for long-enough-running things that we
schedule in the middle.
As I remember, the main hangup was that this interacts a bit oddly
with PKRU, but that's manageable.
--Andy
^ permalink raw reply
* Re: [PATCH] vmxnet3: fix LRO feature check
From: David Miller @ 2018-03-20 14:57 UTC (permalink / raw)
To: lkp; +Cc: ipylypiv, kbuild-all, skhare, pv-drivers, netdev
In-Reply-To: <201803181411.VTfldbIf%fengguang.wu@intel.com>
From: kbuild test robot <lkp@intel.com>
Date: Sun, 18 Mar 2018 14:37:35 +0800
> All warnings (new ones prefixed by >>):
>
> drivers/net/vmxnet3/vmxnet3_drv.c: In function 'vmxnet3_rq_rx_complete':
>>> drivers/net/vmxnet3/vmxnet3_drv.c:1474:8: warning: suggest parentheses around operand of '!' or change '&' to '&&' or '!' to '~' [-Wparentheses]
> !adapter->netdev->features & NETIF_F_LRO) {
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
Igor, I will fix this up for you. But it is clear that this patch wasn't tested
very well.
Because !adapter->netdev->features evaluates wholly before the "& NETIF_F_LRO",
the flags aren't being tested properly at all.
^ permalink raw reply
* Re: [PATCH net] devlink: Remove redundant free on error path
From: David Miller @ 2018-03-20 15:00 UTC (permalink / raw)
To: arkadis; +Cc: netdev, mlxsw, jiri
In-Reply-To: <1521387442-31494-1-git-send-email-arkadis@mellanox.com>
From: Arkadi Sharshevsky <arkadis@mellanox.com>
Date: Sun, 18 Mar 2018 17:37:22 +0200
> The current code performs unneeded free. Remove the redundant skb freeing
> during the error path.
>
> Fixes: 1555d204e743 ("devlink: Support for pipeline debug (dpipe)")
> Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH net] ipv6: sr: fix scheduling in RCU when creating seg6 lwtunnel state
From: Eric Dumazet @ 2018-03-20 15:07 UTC (permalink / raw)
To: David Lebrun, netdev; +Cc: David Lebrun
In-Reply-To: <20180320144456.223556-1-dav.lebrun@gmail.com>
On 03/20/2018 07:44 AM, David Lebrun wrote:
> From: David Lebrun <dlebrun@google.com>
>
> The seg6_build_state() function is called with RCU read lock held,
> so we cannot use GFP_KERNEL. This patch uses GFP_ATOMIC instead.
>
>
> Fixes: 6c8702c60b886 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
> Signed-off-by: David Lebrun <dlebrun@google.com>
> ---
> net/ipv6/seg6_iptunnel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
> index bd6cc688bd19..8367b859a934 100644
> --- a/net/ipv6/seg6_iptunnel.c
> +++ b/net/ipv6/seg6_iptunnel.c
> @@ -418,7 +418,7 @@ static int seg6_build_state(struct nlattr *nla,
>
> slwt = seg6_lwt_lwtunnel(newts);
>
> - err = dst_cache_init(&slwt->cache, GFP_KERNEL);
> + err = dst_cache_init(&slwt->cache, GFP_ATOMIC);
>
This is not the proper fix.
Control path holds RTNL and can sleeep if needed.
RCU should be avoided in lwtunnel_build_state()
^ permalink raw reply
* RE: interdependencies with cxgb4 and iw_cxgb4
From: Steve Wise @ 2018-03-20 15:08 UTC (permalink / raw)
To: 'David Miller'
Cc: rajur, dledford, linux-rdma, jgg, netdev, bharat, ganeshgr,
rahul.lakkireddy
In-Reply-To: <20180320.104046.957152577341740274.davem@davemloft.net>
> >> > Let me ask a dumb question:� Why cannot one of the maintaners pull
> the
> >> > commit from the other mainainer's git repo directly?� IE why have
this
> >> > third trusted/signed git repo that has to be on k.o, from which both
> >> > maintainers pull?� If one of you can pull it in via a patch series,
> >> > like you do for all other patches, and then notify the other
> >> > maintainer to pull it from the first maintainers' repo if the series
> >> > meets the requirements that it needs to be in both maintainers'
> >> > repositories?� This avoids adding more staging git repos on k.o.� But
> >> > probably I'm missing something...
> >>
> >> Tree A may not want all of tree B's changes, and vice versa.
> >
> > I was thinking the special commit would go into a branch that was based
> on,
> > say rc1 or rc2 of one of the maintainers. Then both maintainers pull
that
> > into their -next branch. Would that work?
>
> That makes things more complicated.
For the maintainers, yes. But it avoids setting up k.o accounts and git
repos for each device driver maintainer that has this issue.
>
> The simplest design is that "identical" commits end up in both the
> RDMA and the net-next tree.
>
> Then it absolutely doesn't matter whose tree goes into Linus's first.
>
Yes, and that would still be the case, from my understanding: Instead of
each driver having a k.o. signed git repo, we ask the maintainers to stage
this common branch that both maintainers pull from into their -next
branches/repos.
> Also, we should not be merging "merge window" code after -rc1. "-rc1"
> means the merge window is closed.
I meant using rc-1 for the current release when submitting these shared
commits for the _following merge window_.
Steve.
^ permalink raw reply
* RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
From: David Laight @ 2018-03-20 15:10 UTC (permalink / raw)
To: 'Andy Lutomirski', Ingo Molnar
Cc: Thomas Gleixner, Rahul Lakkireddy, x86@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
mingo@redhat.com, hpa@zytor.com, davem@davemloft.net,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
ganeshgr@chelsio.com, nirranjan@chelsio.com, indranil@chelsio.com,
Peter Zijlstra, Fenghua Yu, Eric Biggers, Rik van Riel
In-Reply-To: <CALCETrVMF140-XZLi9nARPeAmyi8QRRzLRm6SSpB0BkAUSGakg@mail.gmail.com>
From: Andy Lutomirski
> Sent: 20 March 2018 14:57
...
> I'd rather see us finally finish the work that Rik started to rework
> this differently. I'd like kernel_fpu_begin() to look like:
>
> if (test_thread_flag(TIF_NEED_FPU_RESTORE)) {
> return; // we're already okay. maybe we need to check
> in_interrupt() or something, though?
> } else {
> XSAVES/XSAVEOPT/XSAVE;
> set_thread_flag(TIF_NEED_FPU_RESTORE):
> }
>
> and kernel_fpu_end() does nothing at all.
I guess it might need to set (clear?) the CFLAGS bit for a process
that isn't using the fpu at all - which seems a sensible feature.
> We take the full performance hit for a *single* kernel_fpu_begin() on
> an otherwise short syscall or interrupt, but there's no additional
> cost for more of them or for long-enough-running things that we
> schedule in the middle.
It might be worth adding a parameter to kernel_fpu_begin() to indicate
which registers are needed, and a return value to say what has been
granted.
Then a driver could request AVX2 (for example) and use a fallback path
if the register set isn't available (for any reason).
A call from an ISR could always fail.
> As I remember, the main hangup was that this interacts a bit oddly
> with PKRU, but that's manageable.
WTF PKRU ??
Dvaid
^ permalink raw reply
* linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u
From: valdis.kletnieks @ 2018-03-20 15:17 UTC (permalink / raw)
To: Florian Westphal, Pablo Neira Ayuso; +Cc: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]
(Resending because I haven't heard anything)
Am hitting an issue with this commit:
commit 0d7df906a0e78079a02108b06d32c3ef2238ad25
Author: Florian Westphal <fw@strlen.de>
Date: Tue Feb 27 19:42:37 2018 +0100
netfilter: x_tables: ensure last rule in base chain matches underflow/policy
This trips on my system:
[ 64.402790] ip6_tables: last base chain position 1136 doesn't match underflow 1344 (hook 1)
More annoyingly, the return value means that ip6tables aren't initialized
so there's no firewall protection. (In other words, this:
If a (syzkaller generated) ruleset doesn't have the underflow/policy
stored as the last rule in the base chain, then iptables will abort()
because it doesn't find the chain policy.
ends up meaning iptables aborts anyhow.
My iptables isn't syzkaller generated - it's mostly crufty vi-generated. ;)
Messages generated as I tried to build smaller tables to narrow down the problem:
(not sure where it gets the numbers from, as I reduced it from 50 lines down to 3
and no real correlation to the tables I was trying to load - in particular the numbers
went up once and remained unchanged once, even though between each try I was
whacking out another 5-10 lines...)
[ 64.402790] ip6_tables: last base chain position 1136 doesn't match underflow 1344 (hook 1)
[ 1897.914828] ip6_tables: last base chain position 928 doesn't match underflow 1136 (hook 1)
[ 1954.032735] ip6_tables: last base chain position 720 doesn't match underflow 928 (hook 1)
[ 2021.813719] ip6_tables: last base chain position 920 doesn't match underflow 1128 (hook 1)
[ 2035.044103] ip6_tables: last base chain position 920 doesn't match underflow 1128 (hook 1)
[ 2060.594412] ip6_tables: last base chain position 616 doesn't match underflow 824 (hook 1)
I finally got /etc/sysconfig/ip6tables down to this:
# Generated by ip6tables-save v1.6.2 on Thu Mar 8 08:20:04 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [208207395:46346275671]
[120166037:34218429901] -A INPUT -i lo+ -j ACCEPT
[129329499:129691207309] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[0:0] -A INPUT -j DROP
COMMIT
# Completed on Thu Mar 8 08:20:04 2018
About as minimal as it can get. :)
Any ideas?
[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]
^ permalink raw reply
* Re: interdependencies with cxgb4 and iw_cxgb4
From: David Miller @ 2018-03-20 15:18 UTC (permalink / raw)
To: swise
Cc: rajur, dledford, linux-rdma, jgg, netdev, bharat, ganeshgr,
rahul.lakkireddy
In-Reply-To: <3d6501d3c05d$571a28a0$054e79e0$@opengridcomputing.com>
From: "Steve Wise" <swise@opengridcomputing.com>
Date: Tue, 20 Mar 2018 10:08:44 -0500
> For the maintainers, yes. But it avoids setting up k.o accounts and
> git repos for each device driver maintainer that has this issue.
I think this is quite a reasonable requirement for submitters wishing
to make significant changes across two subsystems with complex
interdependencies.
It is critical to get the changes tested in both the RDMA and net-next
tree contexts as early as possible, and to shake out any intergration
issues (which happens transparently via linux-next).
I know it's easy to see the personal "burdon" it causes you as an
individual developer, but you really have to consider how much is
in-flight and being dealt with by maintainers of very active
subsystems like the networking.
Thank you.
^ permalink raw reply
* Re: [PATCH] mlx5: Remove call to ida_pre_get
From: Matthew Wilcox @ 2018-03-20 15:20 UTC (permalink / raw)
To: David Miller; +Cc: maorg, saeedm, matanb, netdev, linux-rdma, leon
In-Reply-To: <20180320.104620.1702410080256879438.davem@davemloft.net>
On Tue, Mar 20, 2018 at 10:46:20AM -0400, David Miller wrote:
> From: Maor Gottlieb <maorg@mellanox.com>
> Date: Tue, 20 Mar 2018 14:41:49 +0200
>
> > Saeed, Matan and I okay with this fix as well, it looks like it
> > shouldn't impact on the insertion rate.
>
> I've applied this to net-next, thanks everyone.
Thanks, Dave.
I realised why this made sense when it was originally written. Before
December 2016 (commit 7ad3d4d85c7a), ida_pre_get used to allocate one
bitmap per ida. I moved it to a percpu variable, and at that point this
stopped making sense.
^ permalink raw reply
* Re: [PATCH 07/36] aio: add delayed cancel support
From: Christoph Hellwig @ 2018-03-20 15:20 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Christoph Hellwig, viro, Avi Kivity, linux-aio, linux-fsdevel,
netdev, linux-api, linux-kernel
In-Reply-To: <20180320031957.GJ7282@magnolia>
On Mon, Mar 19, 2018 at 08:19:57PM -0700, Darrick J. Wong wrote:
> On Mon, Mar 05, 2018 at 01:27:14PM -0800, Christoph Hellwig wrote:
> > The upcoming aio poll support would like to be able to complete the
> > iocb inline from the cancellation context, but that would cause
> > a lock order reversal. Add support for optionally moving the cancelation
> > outside the context lock to avoid this reversal.
>
> I started to wonder which lock order reversal the commit message refers
> to?
>
> I think the reason for adding delayed cancellations is that we want to
> be able to call io_cancel -> kiocb_cancel -> aio_poll_cancel ->
> aio_complete without double locking ctx_lock?
It is. I've updated the commit message.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* RE: interdependencies with cxgb4 and iw_cxgb4
From: Steve Wise @ 2018-03-20 15:20 UTC (permalink / raw)
To: 'David Miller'
Cc: rajur, dledford, linux-rdma, jgg, netdev, bharat, ganeshgr,
rahul.lakkireddy
In-Reply-To: <20180320.111824.2214262102648467414.davem@davemloft.net>
>
> From: "Steve Wise" <swise@opengridcomputing.com>
> Date: Tue, 20 Mar 2018 10:08:44 -0500
>
> > For the maintainers, yes. But it avoids setting up k.o accounts and
> > git repos for each device driver maintainer that has this issue.
>
> I think this is quite a reasonable requirement for submitters wishing
> to make significant changes across two subsystems with complex
> interdependencies.
>
> It is critical to get the changes tested in both the RDMA and net-next
> tree contexts as early as possible, and to shake out any intergration
> issues (which happens transparently via linux-next).
>
> I know it's easy to see the personal "burdon" it causes you as an
> individual developer, but you really have to consider how much is
> in-flight and being dealt with by maintainers of very active
> subsystems like the networking.
>
> Thank you.
Fair enough. Thanks Dave.
^ permalink raw reply
* Re: [PATCH 08/36] aio: implement io_pgetevents
From: Christoph Hellwig @ 2018-03-20 15:22 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Christoph Hellwig, viro, Avi Kivity, linux-aio, linux-fsdevel,
netdev, linux-api, linux-kernel
In-Reply-To: <20180320021241.GE7282@magnolia>
On Mon, Mar 19, 2018 at 07:12:41PM -0700, Darrick J. Wong wrote:
> > Note that unlike many other signal related calls we do not pass a sigmask
> > size, as that would get us to 7 arguments, which aren't easily supported
> > by the syscall infrastructure. It seems a lot less painful to just add a
> > new syscall variant in the unlikely case we're going to increase the
> > sigset size.
>
> I'm assuming there's a proposed manpage update for this somewhere? :)
In this commit:
http://git.infradead.org/users/hch/libaio.git/commitdiff/49f77d595210393ce7b125cb00233cf737402f56
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox