* Re: [Patch net-next] net_sched: only create filter chains for new filters/actions
From: Cong Wang @ 2017-05-26 16:55 UTC (permalink / raw)
To: David Miller
Cc: Jiri Pirko, Linux Kernel Network Developers, Jamal Hadi Salim,
Jiri Pirko
In-Reply-To: <20170526.105443.1489276661727770629.davem@davemloft.net>
On Fri, May 26, 2017 at 7:54 AM, David Miller <davem@davemloft.net> wrote:
> And I also didn't find the boolean logic hard to understand at all.
>
> It is in fact a very common pattern to pass a "create" boolean into
> lookup functions, to tell them whether to create a new object on
> lookup failure or not. And then also to control that boolean via
> what kind of netlink request we are processing.
+10
It is a widely used pattern among the kernel source code.
I'd be surprised if an experienced kernel developer is not
aware of this pattern. ;)
^ permalink raw reply
* Re: [PATCH net] ipv4: add reference counting to metrics
From: Cong Wang @ 2017-05-26 17:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Eric Dumazet, Andrey Konovalov, Julian Anastasov,
netdev
In-Reply-To: <1495747655.6465.113.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, May 25, 2017 at 2:27 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Andrey Konovalov reported crashes in ipv4_mtu()
>
> I could reproduce the issue with KASAN kernels, between
> 10.246.7.151 and 10.246.7.152 :
>
> 1) 20 concurrent netperf -t TCP_RR -H 10.246.7.152 -l 1000 &
>
> 2) At the same time run following loop :
> while :
> do
> ip ro add 10.246.7.152 dev eth0 src 10.246.7.151 mtu 1500
> ip ro del 10.246.7.152 dev eth0 src 10.246.7.151 mtu 1500
> done
>
>
> Cong Wang attempted to add back rt->fi in commit
> 82486aa6f1b9 ("ipv4: restore rt->fi for reference counting")
> but this proved to add some issues that were complex to solve.
>
> Instead, I suggested to add a refcount to the metrics themselves,
> being a standalone object (in particular, no reference to other objects)
>
> I tried to make this patch as small as possible to ease its backport,
> instead of being super clean. Note that we believe that only ipv4 dst
> need to take care of the metric refcount. But if this is wrong,
> this patch adds the basic infrastructure to extend this to other
> families.
>
> Many thanks to Julian Anastasov for reviewing this patch, and Cong Wang
> for his efforts on this problem.
>
> Fixes: 2860583fe840 ("ipv4: Kill rt->fi")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
Nice work!! Thanks for your effort of making it small!
Just one nit below.
> -const u32 dst_default_metrics[RTAX_MAX + 1] = {
> +const struct dst_metrics dst_default_metrics = {
> /* This initializer is needed to force linker to place this variable
> * into const section. Otherwise it might end into bss section.
> * We really want to avoid false sharing on this variable, and catch
> * any writes on it.
> */
> - [RTAX_MAX] = 0xdeadbeef,
> + .refcnt = ATOMIC_INIT(1),
> };
The code comment above is no longer needed since
we have to initialize refcnt to 1, instead of merely for const
section.
Anyway,
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
^ permalink raw reply
* Re: [PATCH 5/5] MIPS: Add support for eBPF JIT.
From: kbuild test robot @ 2017-05-26 17:12 UTC (permalink / raw)
To: David Daney
Cc: kbuild-all, Alexei Starovoitov, Daniel Borkmann, netdev,
linux-kernel, linux-mips, ralf, Markos Chandras, David Daney
In-Reply-To: <20170526003826.10834-6-david.daney@cavium.com>
[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]
Hi David,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc2]
[cannot apply to next-20170526]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/David-Daney/MIPS-Implement-eBPF-JIT/20170526-124316
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips
All errors (new ones prefixed by >>):
arch/mips/net/bpf_jit.c: In function 'build_one_insn':
>> arch/mips/net/bpf_jit.c:2276:27: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
t64s = (s64)insn->imm + (s64)__bpf_call_base;
^
arch/mips/net/bpf_jit.c:2293:38: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
emit_const_to_reg(ctx, MIPS_R_T9, (u64)bpf_internal_load_pointer_neg_helper);
^
arch/mips/net/bpf_jit.c:2295:38: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
emit_const_to_reg(ctx, MIPS_R_T9, (u64)ool_skb_header_pointer);
^
arch/mips/net/bpf_jit.c:2325:37: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
emit_const_to_reg(ctx, MIPS_R_T8, (u64)bpf_internal_load_pointer_neg_helper);
^
arch/mips/net/bpf_jit.c:2326:37: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
emit_const_to_reg(ctx, MIPS_R_T9, (u64)ool_skb_header_pointer);
^
cc1: all warnings being treated as errors
vim +2276 arch/mips/net/bpf_jit.c
2270 t64 = ((u64)(u32)insn->imm) | ((u64)(insn + 1)->imm << 32);
2271 emit_const_to_reg(ctx, dst, t64);
2272 return 2; /* Double slot insn */
2273
2274 case BPF_JMP | BPF_CALL:
2275 ctx->flags |= EBPF_SAVE_RA;
> 2276 t64s = (s64)insn->imm + (s64)__bpf_call_base;
2277 emit_const_to_reg(ctx, MIPS_R_T9, (u64)t64s);
2278 emit_jalr(MIPS_R_RA, MIPS_R_T9, ctx);
2279 /* delay slot */
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 46428 bytes --]
^ permalink raw reply
* Re: [PATCH net] ipv4: add reference counting to metrics
From: Eric Dumazet @ 2017-05-26 17:13 UTC (permalink / raw)
To: Cong Wang
Cc: Eric Dumazet, David Miller, Andrey Konovalov, Julian Anastasov,
netdev
In-Reply-To: <CAM_iQpWDnNz5u9Jtk0MAywNs=N4F8ogvT3bRji3vYj1Tfk830g@mail.gmail.com>
On Fri, May 26, 2017 at 10:08 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, May 25, 2017 at 2:27 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Just one nit below.
>
>> -const u32 dst_default_metrics[RTAX_MAX + 1] = {
>> +const struct dst_metrics dst_default_metrics = {
>> /* This initializer is needed to force linker to place this variable
>> * into const section. Otherwise it might end into bss section.
>> * We really want to avoid false sharing on this variable, and catch
>> * any writes on it.
>> */
>> - [RTAX_MAX] = 0xdeadbeef,
>> + .refcnt = ATOMIC_INIT(1),
>> };
>
> The code comment above is no longer needed since
> we have to initialize refcnt to 1, instead of merely for const
> section.
I believe the comment is still needed, because normally we make sure
dst_default_metrics.refcnt is never touched (incremened nor
decremented)
So its value should not really matter ?
I found that ATOMIC_INIT(1) was less ugly than the 0xdeadbeef
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: ndisc.c: fix coding style issue
From: 吉藤英明 @ 2017-05-26 17:25 UTC (permalink / raw)
To: cugyly
Cc: network dev, David S . Miller, Joe Perches, David Ahern,
yuan linyu, YOSHIFUJI Hideaki
In-Reply-To: <1495806932.5755.4.camel@163.com>
Hi,
2017-05-26 22:55 GMT+09:00 yuan linyu <cugyly@163.com>:
> On 五, 2017-05-26 at 22:45 +0900, 吉藤英明 wrote:
>> Hi,
>>
>> 2017-05-26 22:23 GMT+09:00 yuan linyu <cugyly@163.com>:
>> >
>> > From: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
>> >
>> > Signed-off-by: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
>> > ---
>> > net/ipv6/ndisc.c | 109 ++++++++++++++++++++++++++++---------------------------
>> > 1 file changed, 55 insertions(+), 54 deletions(-)
>> Sorry, I don't think this kind of change for style is good
>> bacause this makes effort of backport more difficult.
> hi, i can't understand.
> if any change of this code you decide to backport, it need effort,
> not only important fix.
>
> do I miss your point ?
Please let us minimize our effort when doing so.
If the style is not changed, we have more chance to apply the patch
itself on top of old tree.
Thank you.
>>
>> --yoshfuji
>>
>
>
^ permalink raw reply
* Re: [PATCH net] ipv4: add reference counting to metrics
From: Cong Wang @ 2017-05-26 17:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, David Miller, Andrey Konovalov, Julian Anastasov,
netdev
In-Reply-To: <CANn89i+_TqFHa9dNFFSbe6msYaWyWr7RfN7_LURs+XL9gd94Pw@mail.gmail.com>
On Fri, May 26, 2017 at 10:13 AM, Eric Dumazet <edumazet@google.com> wrote:
> On Fri, May 26, 2017 at 10:08 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Thu, May 25, 2017 at 2:27 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> Just one nit below.
>>
>>> -const u32 dst_default_metrics[RTAX_MAX + 1] = {
>>> +const struct dst_metrics dst_default_metrics = {
>>> /* This initializer is needed to force linker to place this variable
>>> * into const section. Otherwise it might end into bss section.
>>> * We really want to avoid false sharing on this variable, and catch
>>> * any writes on it.
>>> */
>>> - [RTAX_MAX] = 0xdeadbeef,
>>> + .refcnt = ATOMIC_INIT(1),
>>> };
>>
>> The code comment above is no longer needed since
>> we have to initialize refcnt to 1, instead of merely for const
>> section.
>
> I believe the comment is still needed, because normally we make sure
> dst_default_metrics.refcnt is never touched (incremened nor
> decremented)
>
> So its value should not really matter ?
Oh, you're right, we always have the check on != &dst_default_metrics.
>
> I found that ATOMIC_INIT(1) was less ugly than the 0xdeadbeef
Of course.
^ permalink raw reply
* [PATCH] tcp: reinitialize MTU probing when setting MSS in a TCP repair
From: Douglas Caetano dos Santos @ 2017-05-26 17:28 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Pavel Emelyanov
From: Douglas Caetano dos Santos <douglascs@taghos.com.br>
MTU probing initialization occurred only at connect() and at SYN or
SYN-ACK reception, but the former sets MSS to either the default or the
user set value (through TCP_MAXSEG sockopt) and the latter never happens
with repaired sockets.
The result was that, with MTU probing enabled and unless TCP_MAXSEG
sockopt was used before connect(), probing would be stuck at
tcp_base_mss value until tcp_probe_interval seconds have passed.
Signed-off-by: Douglas Caetano dos Santos <douglascs@taghos.com.br>
---
I'm not sure if there are any side effects doing this, so comments are welcome
as always.
Also, I changed the function's argument from struct tcp_sock to struct sock
because I couldn't find any inverse of tcp_sk() funciton and thought that using
"&tp->inet_conn.icsk_inet.sk" or "(struct sock *)tp" would be worse.
net/ipv4/tcp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 842b575f8fdd..d782637e595e 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2378,9 +2378,10 @@ static int tcp_repair_set_window(struct tcp_sock *tp, char __user *optbuf, int l
return 0;
}
-static int tcp_repair_options_est(struct tcp_sock *tp,
+static int tcp_repair_options_est(struct sock *sk,
struct tcp_repair_opt __user *optbuf, unsigned int len)
{
+ struct tcp_sock *tp = tcp_sk(sk);
struct tcp_repair_opt opt;
while (len >= sizeof(opt)) {
@@ -2393,6 +2394,7 @@ static int tcp_repair_options_est(struct tcp_sock *tp,
switch (opt.opt_code) {
case TCPOPT_MSS:
tp->rx_opt.mss_clamp = opt.opt_val;
+ tcp_mtup_init(sk);
break;
case TCPOPT_WINDOW:
{
@@ -2552,7 +2554,7 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
if (!tp->repair)
err = -EINVAL;
else if (sk->sk_state == TCP_ESTABLISHED)
- err = tcp_repair_options_est(tp,
+ err = tcp_repair_options_est(sk,
(struct tcp_repair_opt __user *)optval,
optlen);
else
--
2.12.2
^ permalink raw reply related
* Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
From: Alexei Starovoitov @ 2017-05-26 17:56 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Ilan Tayari, David S. Miller, Doug Ledford,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jsorensen-b10kYP2dOMg@public.gmane.org, Andy Shevchenko,
linux-fpga-u79uwXL29TY76Z2rM5mHXA, Alan Tull,
yi1.li-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <CALzJLG98D=3yMJV_q4sjVNG41AERFRU+6rwqQJsxnRuVeDTPdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, May 26, 2017 at 11:59:26AM +0300, Saeed Mahameed wrote:
>
> And for FPGA support, we did it correctly this time, all the new code
> is under mlx5/core/fgpa ..
s/correctly/incorrectly/ ?
> Well, this is a well known dilemma, if one has a new feature and has no sandbox
> area to put it in the first phase, it is better to start from the most
> common place
> for that feature which is the originating place, before defining
> APIs/infrastructures,
> until the feature is complete and every body is happy about it.
There is driver/fpga to manage fpga, but mlx fpga+nic combo
will be managed via mlx5/core/fpga/
Adding fpga folks for visibility.
> 1. eswitch is a very integral steering feature of the ConnectX family
> and is valid for all ConnectX4/lx/5/6 .. cards.
and kernel has no visibility into it and mlx has no incentive to expose it,
since community needs to agree on api whereas hiding in the driver
is 'mlx territory' and much easier to push arbitrary patches to.
> "The FPGA is a bump-on-the-wire and thus affects operation of
> the mlx5_core driver on the ConnectX ASIC."
>
> This is not a general purpose FPGA ! it even doesn't have a PCI Id or
> it is own PCI function.
> it simply allows the ConnectX Chip user to inspect/inject or run user
> specif login on traffic going in/out of the chip.
... and bluefield arm cpus are not general purpose cpus and
only used to offload networking just like this fpga?
> But i agree with you some serious API brainstorming should be
> considered, but not at this stage,
> this patch only tells the ConnectX card (if you have FPGA, please enable it).
serious api discussion needs be done before things like eswitch, fpga
exposed to users otherwise we end up in the eswitch situation that
drops packets based on its own invisible logic, but with hidden fpga
it will be even more obscure.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [for-next 5/6] net/mlx5: Bump driver version
From: Leon Romanovsky @ 2017-05-26 18:10 UTC (permalink / raw)
To: Dennis Dalessandro
Cc: Saeed Mahameed, Saeed Mahameed, David S. Miller, Doug Ledford,
Linux Netdev List, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Ilan Tayari,
Tariq Toukan
In-Reply-To: <ee23ad82-4a2e-8546-d41b-11f979b127bb-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]
On Fri, May 26, 2017 at 12:55:22PM -0400, Dennis Dalessandro wrote:
> On 5/26/2017 12:35 PM, Saeed Mahameed wrote:
> > On Fri, May 26, 2017 at 3:56 PM, Dennis Dalessandro
> > <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> > > On 5/23/2017 7:44 AM, Saeed Mahameed wrote:
>
> > Anyway i don't think we are going to change this frequently or even use it.
>
> > But if you are that much against touching this ethtool field, why
> > don't you just jump into the mud and remove it from the tree, I
> > imagine it is really hard for you to watch for patches doing this and
> > nack them on the list.
>
> I have no interest in policing that. I complained about the other driver
> because I know patches like that were NAKed by Greg KH in the past (ours).
> I'd rather not see the rdma subsystem keep making the same mistakes is all.
> We want to improve our standing in the community after all. As I said I'm
> not personally against it as evidenced by our driver.
I personally would like to see patch which does two things:
1. Removes all these MODULE_VERSIONS
2. Puts some hardcoded value common to kernel, so no user space
application (like modinfo) won't be broken.
>
> > > I realize Dave has already pulled this and I'm not asking for it to be
> > > reverted but maybe some discussion will help guide future patch submissions
> > > which do this stuff.
> > >
> >
> > Sure, although i don't think we are going to use those version fields
> > in the future,
> > please allow me to ask, how do you do your driver versioning ? how do
> > you track things ?
> > and what is your future vision regarding ethool->drv_version ?
>
> That's just the thing, we don't do anything with it either really. I'm
> trying to justify its existence to myself and if you folks had some whiz
> bang idea for a driver version I was interested in hearing what it was.
No, we didn't find any real usage of it too. My attempts raise attention
to that issue in netdev weren't successful, maybe you will have
more luck than me.
https://lkml.org/lkml/2016/7/15/17
https://patchwork.kernel.org/patch/9349357/
Thanks
>
> -Denny
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.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: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
From: Jason Gunthorpe @ 2017-05-26 18:15 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Saeed Mahameed, Ilan Tayari, David S. Miller, Doug Ledford,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jsorensen-b10kYP2dOMg@public.gmane.org, Andy Shevchenko,
linux-fpga-u79uwXL29TY76Z2rM5mHXA, Alan Tull,
yi1.li-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <20170526175624.5xxflpf24je5673h@ast-mbp>
On Fri, May 26, 2017 at 10:56:25AM -0700, Alexei Starovoitov wrote:
> > for that feature which is the originating place, before defining
> > APIs/infrastructures,
> > until the feature is complete and every body is happy about it.
>
> There is driver/fpga to manage fpga, but mlx fpga+nic combo
> will be managed via mlx5/core/fpga/
>
> Adding fpga folks for visibility.
It would be good to use the existing fpga loading infrastructure to
get the bitstream into the NIC, and to use the same Xilinx bitstream
format as eg Zynq does for consistency.
I'm unclear how this works - there must be more to it than just a
'bump on the wire', there must be some communication channel between
the FPGA and Linux to set operational data (eg load keys) etc.
If that is register mapped into a PCI-BAR someplace then it really
should use the FPGA layer functions to manage binding drivers to that
register window.
If it is mailbox command based then it is not as good of a fit.
Is this FPGA expected to be customer programmable? In that case you
really need the full infrastructure to bind the right driver (possibly
a customer driver) to the current FPGA, to expose the correct
operational interface to the kernel.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v2 0/8] net: extend RTM_GETROUTE to return fib result
From: David Miller @ 2017-05-26 18:18 UTC (permalink / raw)
To: roopa; +Cc: dsahern, rami.rosen, netdev, nikolay
In-Reply-To: <1495734160-47659-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Thu, 25 May 2017 10:42:32 -0700
> This series adds a new RTM_F_FIB_MATCH flag to return matched fib result
> with RTM_GETROUTE. This is useful for applications and protocols in
> userspace wanting to query the selected route.
Looks good, series applied, thanks.
Have you considered taking this further and allowing one to see which
nexthop a route lookup picked?
^ permalink raw reply
* Re: [PATCH] net: llc: add lock_sock in llc_ui_bind to avoid a race condition
From: David Miller @ 2017-05-26 18:24 UTC (permalink / raw)
To: xiaolou4617; +Cc: netdev, linux-kernel
In-Reply-To: <1495692438-9781-1-git-send-email-xiaolou4617@gmail.com>
From: Lin Zhang <xiaolou4617@gmail.com>
Date: Thu, 25 May 2017 14:07:18 +0800
> There is a race condition in llc_ui_bind if two or more processes/threads
> try to bind a same socket.
>
> If more processes/threads bind a same socket success that will lead to
> two problems, one is this action is not what we expected, another is
> will lead to kernel in unstable status or oops(in my simple test case,
> cause llc2.ko can't unload).
>
> The current code is test SOCK_ZAPPED bit to avoid a process to
> bind a same socket twice but that is can't avoid more processes/threads
> try to bind a same socket at the same time.
>
> So, add lock_sock in llc_ui_bind like others, such as llc_ui_connect.
>
> Signed-off-by: Lin Zhang <xiaolou4617@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/5] MIPS: Optimize uasm insn lookup.
From: David Daney @ 2017-05-26 18:25 UTC (permalink / raw)
To: Matt Redfearn, David Daney, Alexei Starovoitov, Daniel Borkmann,
netdev, linux-kernel, linux-mips, ralf
In-Reply-To: <c8d6691a-0c17-eab7-ac34-efc4e18589b9@imgtec.com>
On 05/26/2017 01:07 AM, Matt Redfearn wrote:
[...]
>> - { insn_lwx, 0, 0 },
>> - { insn_ldx, 0, 0 },
>> - { insn_invalid, 0, 0 }
>> +static struct insn insn_table_MM[insn_invalid] = {
>
> ^ You could make this const too, like you have the one in uasm-mips.c.
>
Good catch. I meant to do that.
I will fix it for the next revision of the patch set.
> Thanks,
> Matt
>
^ permalink raw reply
* Re: [PATCH v5 net-next 0/2] rtnetlink: Updates to rtnetlink_event()
From: David Miller @ 2017-05-26 18:30 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, dsahern, roopa, jiri, vfalico, andy, vyasevic
In-Reply-To: <1495726316-27626-1-git-send-email-vyasevic@redhat.com>
From: Vladislav Yasevich <vyasevich@gmail.com>
Date: Thu, 25 May 2017 11:31:53 -0400
> This is a version 5 series came out of the conversation that started
> as a result my first attempt to add netdevice event info to netlink
> messages.
David Ahern, please review.
Thanks.
^ permalink raw reply
* Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
From: Jes Sorensen @ 2017-05-26 18:31 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Ilan Tayari, Alexei Starovoitov, Saeed Mahameed, David S. Miller,
Doug Ledford, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CALzJLG9YNpagdJAcrh6O0jJhZWtsck6KigRtVxyjkArTm=82ew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 05/26/2017 04:29 AM, Saeed Mahameed wrote:
> On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen <jsorensen-b10kYP2dOMg@public.gmane.org> wrote:
>> On 05/25/2017 06:40 AM, Saeed Mahameed wrote:
> Hi Jes,
>
> No, It is clearly stated in the commit message :
>
> "The FPGA is a bump-on-the-wire and thus affects operation of
> the mlx5_core driver on the ConnectX ASIC."
>
> Which means mlx5 FPGA user can only write logic which affects only
> packets going in/out
> A ConnectX chip - so it is only network stuff -.
>
>> We have this with other devices in the kernel where a primary device driver
>> provides an interface for an additional sub-driver to access another device
>> behind it. Like bt-coexist in some of the wifi drivers allowing access to a
>> bluetooth device behind it.
>
> Blutooth over wifi or vise versa is a very good example to what you
> are requesting.
> But, it doesn't fit to what we are trying to do here. mlx5 FGPA is a
> ConnectX card feature, not a new protocol.
In that case it would need to be an optional module that can be enabled
or disabled at build time.
Cheers,
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: phy: Create sysfs reciprocal links for attached_dev/phydev
From: David Miller @ 2017-05-26 18:38 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, netdev
In-Reply-To: <20170525164227.GB18357@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Thu, 25 May 2017 18:42:27 +0200
> On Thu, May 25, 2017 at 09:21:40AM -0700, Florian Fainelli wrote:
>> Hi David, Andrew,
>>
>> This patch series addresses a device topology shortcoming where a program
>> scanning /sys would not be able to establish a mapping between the network
>> device and the PHY device.
>>
>> In the process it turned out that no PHY device documentation existed for
>> sysfs attributes.
>>
>> Thanks!
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Series applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net v2] sctp: fix ICMP processing if skb is non-linear
From: David Miller @ 2017-05-26 18:42 UTC (permalink / raw)
To: dcaratti; +Cc: netdev, linux-sctp, lucien.xin, marcelo.leitner
In-Reply-To: <d0cd7c2e4b9329ec23e48aed94bf2fbf94554f44.1495730857.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Thu, 25 May 2017 19:14:56 +0200
> sometimes ICMP replies to INIT chunks are ignored by the client, even if
> the encapsulated SCTP headers match an open socket. This happens when the
> ICMP packet is carried by a paged skb: use skb_header_pointer() to read
> packet contents beyond the SCTP header, so that chunk header and initiate
> tag are validated correctly.
>
> v2:
> - don't use skb_header_pointer() to read the transport header, since
> icmp_socket_deliver() already puts these 8 bytes in the linear area.
> - change commit message to make specific reference to INIT chunks.
>
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: fix rare pci_driver.probe failure of VF driver
From: David Miller @ 2017-05-26 18:42 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
prasad.kanneganti
In-Reply-To: <20170525174214.GA1444@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Thu, 25 May 2017 10:42:14 -0700
> From: Prasad Kanneganti <prasad.kanneganti@cavium.com>
>
> There's a rare pci_driver.probe failure of the VF driver that's caused by
> PF/VF handshake going out of sync. The culprit is octeon_mbox_write() who
> ignores an ack timeout condition; it just keeps unconditionally writing all
> elements of mbox_cmd->data[] even when the other side is not ready for
> them. Fix it by making each write of mbox_cmd->data[i] conditional to
> having previously received an ack.
>
> Also fix the octeon_mbox_state enum such that each state gets a unique
> value. Also add ULL suffix to numeric literals in macro definitions.
>
> Signed-off-by: Prasad Kanneganti <prasad.kanneganti@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: fix inaccurate count of napi-processed rx packets reported to Octeon
From: David Miller @ 2017-05-26 18:42 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
prasad.kanneganti
In-Reply-To: <20170525175429.GA1476@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Thu, 25 May 2017 10:54:29 -0700
> From: Prasad Kanneganti <prasad.kanneganti@cavium.com>
>
> lio_enable_irq (called by napi poll) is reporting to Octeon an inaccurate
> count of processed rx packets causing Octeon to eventually stop forwarding
> packets to the host. Fix it by using this formula for an accurate count:
>
> processed rx packets = droq->pkt_count - droq->pkts_pending
>
> Also increase SOFT_COMMAND_BUFFER_SIZE to match what the firmware expects.
>
> Signed-off-by: Prasad Kanneganti <prasad.kanneganti@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/4] More marvell phy cleanups
From: David Miller @ 2017-05-26 18:45 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, netdev
In-Reply-To: <1495741328-25001-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Thu, 25 May 2017 21:42:04 +0200
> This patchset continues the cleanup of the Marvell PHY driver. These
> phys use pages to allow more than the 32 registers that fit into the
> MDIO address space. Cleanup the code used for changing pages.
>
> v2
> Reverse christmas tree
Series applied, thank you Andrew.
^ permalink raw reply
* Re: [PATCH net,v2] ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets
From: David Miller @ 2017-05-26 18:55 UTC (permalink / raw)
To: petedaws; +Cc: kuznet, jmorris, yoshfuji, kaber, stephen, netdev, linux-kernel
In-Reply-To: <20170526063518.612f51f9@udesktop>
From: Peter Dawson <petedaws@gmail.com>
Date: Fri, 26 May 2017 06:35:18 +1000
> This fix addresses two problems in the way the DSCP field is formulated
> on the encapsulating header of IPv6 tunnels.
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195661
>
> 1) The IPv6 tunneling code was manipulating the DSCP field of the
> encapsulating packet using the 32b flowlabel. Since the flowlabel is
> only the lower 20b it was incorrect to assume that the upper 12b
> containing the DSCP and ECN fields would remain intact when formulating
> the encapsulating header. This fix handles the 'inherit' and
> 'fixed-value' DSCP cases explicitly using the extant dsfield u8 variable.
>
> 2) The use of INET_ECN_encapsulate(0, dsfield) in ip6_tnl_xmit was
> incorrect and resulted in the DSCP value always being set to 0.
>
> Commit 90427ef5d2a4 ("ipv6: fix flow labels when the traffic class
> is non-0") caused the regression by masking out the flowlabel
> which exposed the incorrect handling of the DSCP portion of the
> flowlabel in ip6_tunnel and ip6_gre.
>
> Fixes: 90427ef5d2a4 ("ipv6: fix flow labels when the traffic class is non-0")
> Signed-off-by: Peter Dawson <peter.a.dawson@boeing.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net: ethernet: ax88796: don't call free_irq without request_irq first
From: David Miller @ 2017-05-26 18:57 UTC (permalink / raw)
To: u.kleine-koenig; +Cc: netdev, kernel, ben.dooks
In-Reply-To: <20170525205453.21999-1-u.kleine-koenig@pengutronix.de>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Thu, 25 May 2017 22:54:53 +0200
> The function ax_init_dev (which is called only from the driver's .probe
> function) calls free_irq in the error path without having requested the
> irq in the first place. So drop the free_irq call in the error path.
>
> Fixes: 825a2ff1896e ("AX88796 network driver")
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: ax88796: support generating a random mac address
From: David Miller @ 2017-05-26 18:58 UTC (permalink / raw)
To: u.kleine-koenig; +Cc: netdev, kernel
In-Reply-To: <20170525205511.22048-1-u.kleine-koenig@pengutronix.de>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Thu, 25 May 2017 22:55:11 +0200
> Instead of falling back to 00:00:00:00:00:00 generate a random address
> if none is provided via platform data or from the the device's register
> space.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv4: add reference counting to metrics
From: David Miller @ 2017-05-26 18:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: edumazet, andreyknvl, ja, xiyou.wangcong, netdev
In-Reply-To: <1495747655.6465.113.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 25 May 2017 14:27:35 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Andrey Konovalov reported crashes in ipv4_mtu()
>
> I could reproduce the issue with KASAN kernels, between
> 10.246.7.151 and 10.246.7.152 :
>
> 1) 20 concurrent netperf -t TCP_RR -H 10.246.7.152 -l 1000 &
>
> 2) At the same time run following loop :
> while :
> do
> ip ro add 10.246.7.152 dev eth0 src 10.246.7.151 mtu 1500
> ip ro del 10.246.7.152 dev eth0 src 10.246.7.151 mtu 1500
> done
>
>
> Cong Wang attempted to add back rt->fi in commit
> 82486aa6f1b9 ("ipv4: restore rt->fi for reference counting")
> but this proved to add some issues that were complex to solve.
>
> Instead, I suggested to add a refcount to the metrics themselves,
> being a standalone object (in particular, no reference to other objects)
>
> I tried to make this patch as small as possible to ease its backport,
> instead of being super clean. Note that we believe that only ipv4 dst
> need to take care of the metric refcount. But if this is wrong,
> this patch adds the basic infrastructure to extend this to other
> families.
>
> Many thanks to Julian Anastasov for reviewing this patch, and Cong Wang
> for his efforts on this problem.
>
> Fixes: 2860583fe840 ("ipv4: Kill rt->fi")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
Applied, thanks everyone for following through on this bug fix.
And sorry for introducing the problem in the first place :)
^ permalink raw reply
* Re: [PATCH v3 net-next 0/5] net: dsa: mv88e6xxx: Add basic SERDES support
From: David Miller @ 2017-05-26 19:01 UTC (permalink / raw)
To: andrew; +Cc: vivien.didelot, netdev
In-Reply-To: <1495753404-29943-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Fri, 26 May 2017 01:03:19 +0200
> Some of the Marvell switches are SERDES interface, which must be
> powered up before packets can be passed. This is particularly true on
> the 6390, where the SERDES defaults to down, probably to save power.
>
> This series refactors the existing SERDES support for the 6352, and
> adds 6390 support.
...
Series applied, thanks Andrew.
^ 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