* Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac
From: Marcel Holtmann @ 2018-04-05 8:46 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Johan Hedberg, David S. Miller, Bluez mailing list,
Network Development, linux-kernel
In-Reply-To: <2af25866-4e8a-7f9c-9298-e45abfab20c7@embeddedor.com>
Hi Gustavo,
>> so I took this patch back out of bluetooth-next before sending the pull request. I think the discussion on how to fix SHASH_DESC_ON_STACK macro needs to complete first. Once that has concluded we can revisit if this patch is still needed or if another solution has been found. Same as with WiFi, these are not just one-shot calls where a memory allocation doesn’t matter. We need this for random address resolution and thus there can be many of the aes_cmac calls when seeing neighboring devices.
>
> Yeah. I agree.
>
> Based on Herbert's response to the discussion about SHASH_DESC_ON_STACK https://lkml.org/lkml/2018/3/27/300
>
> it seems it is feasible to fix that macro very easily. I will follow up on this.
>
> By the way, what is you opinion on replacing crypto_shash_descsize(ctx) with PAGE_SIZE / 8 in SHASH_DESC_ON_STACK?
>
> Does it work for you?
isn’t that just waste?
The macro itself is this.
#define SHASH_DESC_ON_STACK(shash, ctx) \
char __##shash##_desc[sizeof(struct shash_desc) + \
crypto_shash_descsize(ctx)] CRYPTO_MINALIGN_ATTR; \
struct shash_desc *shash = (struct shash_desc *)__##shash##_desc
For AES-CMAC, we could always do this with a manual macro that gives us the right size. However that is error prone if any internals change. I think what has to happened that crypto_shash_decsize becomes something the compiler can evaluate at compile time.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac
From: Gustavo A. R. Silva @ 2018-04-05 8:35 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Johan Hedberg, David S. Miller, Bluez mailing list,
Network Development, linux-kernel
In-Reply-To: <3BD15121-532A-45E2-B62E-1008C0289500@holtmann.org>
Hi Marcel,
On 04/05/2018 02:23 AM, Marcel Holtmann wrote:
> so I took this patch back out of bluetooth-next before sending the pull request. I think the discussion on how to fix SHASH_DESC_ON_STACK macro needs to complete first. Once that has concluded we can revisit if this patch is still needed or if another solution has been found. Same as with WiFi, these are not just one-shot calls where a memory allocation doesn’t matter. We need this for random address resolution and thus there can be many of the aes_cmac calls when seeing neighboring devices.
>
Yeah. I agree.
Based on Herbert's response to the discussion about SHASH_DESC_ON_STACK
https://lkml.org/lkml/2018/3/27/300
it seems it is feasible to fix that macro very easily. I will follow up
on this.
By the way, what is you opinion on replacing crypto_shash_descsize(ctx)
with PAGE_SIZE / 8 in SHASH_DESC_ON_STACK?
Does it work for you?
Thanks
--
Gustavo
^ permalink raw reply
* [PATCH net] arp: fix arp_filter on l3slave devices
From: Miguel Fadon Perlines @ 2018-04-05 8:25 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Miguel Fadon Perlines
arp_filter performs an ip_route_output search for arp source address and
checks if output device is the same where the arp request was received,
if it is not, the arp request is not answered.
This route lookup is always done on main route table so l3slave devices
never find the proper route and arp is not answered.
Passing l3mdev_master_ifindex_rcu(dev) return value as oif fixes the
lookup for l3slave devices while maintaining same behavior for non
l3slave devices as this function returns 0 in that case.
Signed-off-by: Miguel Fadon Perlines <mfadon@teldat.com>
---
net/ipv4/arp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index f28f06c..7333db1 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -437,7 +437,7 @@ static int arp_filter(__be32 sip, __be32 tip, struct net_device *dev)
/*unsigned long now; */
struct net *net = dev_net(dev);
- rt = ip_route_output(net, sip, tip, 0, 0);
+ rt = ip_route_output(net, sip, tip, 0, l3mdev_master_ifindex_rcu(dev));
if (IS_ERR(rt))
return 1;
if (rt->dst.dev != dev) {
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac
From: Marcel Holtmann @ 2018-04-05 7:23 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Johan Hedberg, David S. Miller, Bluez mailing list,
Network Development, linux-kernel
In-Reply-To: <20180321010527.GA16616@embeddedor.com>
Hi Gustavo,
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation instead.
>
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> or a security flaw. Also, in general, as code evolves it is easy to
> lose track of how big a VLA can get. Thus, we can end up having runtime
> failures that are hard to debug.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
> ---
> Changes in v2:
> - Fix memory leak in previous patch.
>
> net/bluetooth/smp.c | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> index a2ddae2..0fa7035 100644
> --- a/net/bluetooth/smp.c
> +++ b/net/bluetooth/smp.c
> @@ -173,7 +173,7 @@ static int aes_cmac(struct crypto_shash *tfm, const u8 k[16], const u8 *m,
> size_t len, u8 mac[16])
> {
> uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX];
> - SHASH_DESC_ON_STACK(desc, tfm);
> + struct shash_desc *shash;
so I took this patch back out of bluetooth-next before sending the pull request. I think the discussion on how to fix SHASH_DESC_ON_STACK macro needs to complete first. Once that has concluded we can revisit if this patch is still needed or if another solution has been found. Same as with WiFi, these are not just one-shot calls where a memory allocation doesn’t matter. We need this for random address resolution and thus there can be many of the aes_cmac calls when seeing neighboring devices.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 00/15] ARM: pxa: switch to DMA slave maps
From: Arnd Bergmann @ 2018-04-05 6:50 UTC (permalink / raw)
To: Ulf Hansson
Cc: Boris Brezillon, Robert Jarzmik, Daniel Mack, Haojian Zhuang,
Bartlomiej Zolnierkiewicz, Tejun Heo, Vinod Koul,
Mauro Carvalho Chehab, Ezequiel Garcia, Boris Brezillon,
David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Nicolas Pitre, Samuel Ortiz, Greg Kroah-Hartman,
Jaroslav
In-Reply-To: <CAPDyKFoFz_HgYPOMGuOTpehrTR3DtWE3uZbcnVwUwVhDy02Mow@mail.gmail.com>
On Thu, Apr 5, 2018 at 8:29 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 4 April 2018 at 21:56, Boris Brezillon <boris.brezillon@bootlin.com> wrote:
>> On Wed, 04 Apr 2018 21:49:26 +0200
>> Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>>
>>> Ulf Hansson <ulf.hansson@linaro.org> writes:
>>>
>>> > On 2 April 2018 at 16:26, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>>> >> Hi,
>>> >>
>>> >> This serie is aimed at removing the dmaengine slave compat use, and transfer
>>> >> knowledge of the DMA requestors into architecture code.
>>> >> As this looks like a patch bomb, each maintainer expressing for his tree either
>>> >> an Ack or "I want to take through my tree" will be spared in the next iterations
>>> >> of this serie.
>>> >
>>> > Perhaps an option is to send this hole series as PR for 3.17 rc1, that
>>> > would removed some churns and make this faster/easier? Well, if you
>>> > receive the needed acks of course.
>>> For 3.17-rc1 it looks a bit optimistic with the review time ... If I have all
>>
>> Especially since 3.17-rc1 has been released more than 3 years ago :-),
>> but I guess you meant 4.17-rc1.
>
> Yeah, I realize that I was a bit lost in time yesterday. Even more
> people have been having fun about it (me too). :-)
I occasionally still type 2.6.17 when I mean 4.17.
Arnd
^ permalink raw reply
* Re: [PATCH 00/15] ARM: pxa: switch to DMA slave maps
From: Ulf Hansson @ 2018-04-05 6:29 UTC (permalink / raw)
To: Boris Brezillon
Cc: alsa-devel, Takashi Iwai, linux-ide, netdev, linux-mtd,
Robert Jarzmik, driverdevel, Boris Brezillon, Vinod Koul,
Richard Weinberger, Marek Vasut, Ezequiel Garcia, linux-media,
Samuel Ortiz, Arnd Bergmann, Bartlomiej Zolnierkiewicz,
Haojian Zhuang, dmaengine, Mark Brown, Jaroslav Kysela,
Mauro Carvalho Chehab, Linux ARM, Nicolas Pitre,
Greg Kroah-Hartman <gregk
In-Reply-To: <20180404215623.2bf07406@bbrezillon>
On 4 April 2018 at 21:56, Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> On Wed, 04 Apr 2018 21:49:26 +0200
> Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>
>> Ulf Hansson <ulf.hansson@linaro.org> writes:
>>
>> > On 2 April 2018 at 16:26, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> >> Hi,
>> >>
>> >> This serie is aimed at removing the dmaengine slave compat use, and transfer
>> >> knowledge of the DMA requestors into architecture code.
>> >> As this looks like a patch bomb, each maintainer expressing for his tree either
>> >> an Ack or "I want to take through my tree" will be spared in the next iterations
>> >> of this serie.
>> >
>> > Perhaps an option is to send this hole series as PR for 3.17 rc1, that
>> > would removed some churns and make this faster/easier? Well, if you
>> > receive the needed acks of course.
>> For 3.17-rc1 it looks a bit optimistic with the review time ... If I have all
>
> Especially since 3.17-rc1 has been released more than 3 years ago :-),
> but I guess you meant 4.17-rc1.
Yeah, I realize that I was a bit lost in time yesterday. Even more
people have been having fun about it (me too). :-)
Kind regards
Uffe
^ permalink raw reply
* [PATCH ethtool] ethtool: Add register dump support for MICROCHIP LAN78xx
From: Raghuram Chary J @ 2018-04-05 6:11 UTC (permalink / raw)
To: davem; +Cc: netdev, unglinuxdriver, woojung.huh, raghuramchary.jallipalli
This patch adds support for Microchip's lan78xx families
of USB Ethernet controllers to ethtool's dump registers
command.
This patch is for use with the lan78xx driver.
Signed-off-by: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
---
Makefile.am | 2 +-
ethtool.c | 1 +
internal.h | 4 +++
lan78xx.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 93 insertions(+), 1 deletion(-)
create mode 100644 lan78xx.c
diff --git a/Makefile.am b/Makefile.am
index edbda57..14f79b6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,7 +14,7 @@ ethtool_SOURCES += \
pcnet32.c realtek.c tg3.c marvell.c vioc.c \
smsc911x.c at76c50x-usb.c sfc.c stmmac.c \
sff-common.c sff-common.h sfpid.c sfpdiag.c \
- ixgbevf.c tse.c vmxnet3.c qsfp.c qsfp.h fjes.c
+ ixgbevf.c tse.c vmxnet3.c qsfp.c qsfp.h fjes.c lan78xx.c
endif
TESTS = test-cmdline test-features
diff --git a/ethtool.c b/ethtool.c
index da7421c..3494402 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1160,6 +1160,7 @@ static const struct {
{ "altera_tse", altera_tse_dump_regs },
{ "vmxnet3", vmxnet3_dump_regs },
{ "fjes", fjes_dump_regs },
+ { "lan78xx", lan78xx_dump_regs },
#endif
};
diff --git a/internal.h b/internal.h
index 913f4eb..b239dc7 100644
--- a/internal.h
+++ b/internal.h
@@ -350,4 +350,8 @@ void sff8636_show_all(const __u8 *id, __u32 eeprom_len);
/* FUJITSU Extended Socket network device */
int fjes_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+
+/* MICROCHIP LAN78XX USB ETHERNET Controller */
+int lan78xx_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+
#endif /* ETHTOOL_INTERNAL_H__ */
diff --git a/lan78xx.c b/lan78xx.c
new file mode 100644
index 0000000..bb64e80
--- /dev/null
+++ b/lan78xx.c
@@ -0,0 +1,87 @@
+#include <stdio.h>
+#include <string.h>
+#include "internal.h"
+
+int lan78xx_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
+{
+ unsigned int *lan78xx_reg = (unsigned int *)regs->data;
+
+ fprintf(stdout, "LAN78xx Registers:\n");
+ fprintf(stdout, "------------------\n");
+ fprintf(stdout, "ID_REV = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "INT_STS = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "HW_CFG = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "PMT_CTRL = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "E2P_CMD = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "E2P_DATA = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "USB_STATUS = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "VLAN_TYPE = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "\n");
+
+ fprintf(stdout, "MAC Registers:\n");
+ fprintf(stdout, "--------------\n");
+ fprintf(stdout, "MAC_CR = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "MAC_RX = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "MAC_TX = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "FLOW = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "ERR_STS = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "MII_ACC = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "MII_DATA = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "EEE_TX_LPI_REQ_DLY = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "EEE_TW_TX_SYS = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "EEE_TX_LPI_REM_DLY = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "WUCSR = 0x%08X\n", *lan78xx_reg++);
+ fprintf(stdout, "\n");
+
+ fprintf(stdout, "PHY Registers:\n");
+ fprintf(stdout, "--------------\n");
+ fprintf(stdout, "Mode Control = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Mode Status = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Device identifier1 = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Device identifier2 = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Auto-Neg Advertisement = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "Auto-Neg Link Partner Ability = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "Auto-Neg Expansion = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Auto-Neg Next Page TX = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Auto-Neg Link Partner Next Page RX = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "1000BASE-T Control = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "1000BASE-T Status = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Reserved = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Reserved = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "MMD Access Control = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "MMD Access Address/Data = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "1000BASE-T Status Extension1 = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "1000BASE-TX Status Extension = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "1000BASE-T Status Extension2 = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "Bypass Control = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout,
+ "100BASE-TX/1000BASE-T Rx Error Counter = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout,
+ "100BASE-TX/1000BASE-T FC Err Counter = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout,
+ "10BASE-T/100BASE-TX/1000BASE-T LD Counter = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "Extended 10BASE-T Control and Status = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "Extended PHY Control1 = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Extended PHY Control2 = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Interrupt Mask = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Interrupt Status = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Reserved = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Auxiliary Control and Status = 0x%04X\n",
+ *lan78xx_reg++);
+ fprintf(stdout, "LED Mode Select = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "LED Behavior = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "Extended Page Access = 0x%04X\n", *lan78xx_reg++);
+ fprintf(stdout, "\n");
+
+ return 0;
+}
--
2.16.2
^ permalink raw reply related
* Re: [PATCH net-next 09/11] devlink: convert occ_get op to separate registration
From: Jiri Pirko @ 2018-04-05 5:36 UTC (permalink / raw)
To: David Ahern
Cc: Jakub Kicinski, Ido Schimmel, netdev, davem, jiri, petrm, mlxsw
In-Reply-To: <addb04b3-b63d-6675-f3a6-3fb8969eb980@gmail.com>
Thu, Apr 05, 2018 at 01:00:18AM CEST, dsahern@gmail.com wrote:
>On 4/4/18 4:59 PM, Jakub Kicinski wrote:
>> On Wed, 4 Apr 2018 08:25:11 +0200, Jiri Pirko wrote:
>>>> Jiri, I am not aware of any other API where a driver registers with it
>>>> yet doesn't want the handler to be called so either waits to register
>>>
>>> Again, the thing is, this is kind of unusual because of the reload
>>> thing.
>>
>> FWIW my knee jerk thought is that it's strange that devlink ops can
>> be executed at all while reload is happening (incl. another reload
>> request). I'm probably missing the real issue..
>>
>
>Just responding with the same question ...
>
>Why are you not unregistering resources on a reload?
Because you need the use the values of course!
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications
From: Alexei Starovoitov @ 2018-04-05 5:28 UTC (permalink / raw)
To: Edward Cree; +Cc: Daniel Borkmann, netdev
In-Reply-To: <3484e40e-57a7-e7c6-520d-b9ca795616e2@solarflare.com>
On Thu, Apr 05, 2018 at 12:58:46AM +0100, Edward Cree wrote:
> On 04/04/18 00:37, Alexei Starovoitov wrote:
> > hmm. that doesn't fail for me and any other bots didn't complain.
> > Are you sure you're running the latest kernel and tests?
> Ah, test_progs isn't actually rebuilding because __NR_bpf is undeclared;
> something must be going wrong with header files.
> Never mind.
>
> > hmm. what's wrong with bsearch? It's trivial and fast.
> bsearch is O(log n), and the sort() call on the subprog_starts (which happens
> every time add_subprog() is called) is O(n log n).
> Whereas reading aux->subprogno is O(1).
> As far as I'm concerned, that's a sign that the latter data structure is the
> appropriate one.
only if it can be done as separate _first_ pass before cfg.
> > Even if we don't see the solution today we have to work towards it.
> I guess I'm just not confident "towards" is the direction you think it is.
>
> > Compiler designers could have combined multiple of such passes into
> > fewer ones, but it's not done, because it increases complexity and
> > causes tough bugs where pass is partially complete.
> I'm not trying to combine together multiple 'for bb in prog/for insn in bb'-
> type passes. The combining I was doing was more on 'for all possible
> execution paths'-type passes, because it's those that explode combinatorially.
> Happily I think we can go a long way towards getting rid of them; but while I
> think we can get down to only having 1, I don't think we can reach 0.
we have to. That's the point. 'explore all possible paths' must be removed.
New code should not be relying on that in a way that it's difficult to remove
later. subprog boundaries is a typical example where doing it as
part of 'explore all paths' is harmful long term. Regardless of extra
O(num_of_subrogs) complexity it brings short term.
> > The prime example where more than 4k instructions and loops are mandatory
> > is user space stack analysis inside the program. Like walking python stack
> > requires non-trival pointer chasing. With 'pragma unroll' the stack depth
> > limit today is ~18. That's not really usable. Looping through 100 python
> > frames would require about 16k bpf assembler instructions.
> But this would be solved by having support for bounded loops, and I think I've
> successfully shown that this is not inherently incompatible with a do_check()
> style walk.
No. It's worse. Your proposed approach to bounded loops completely
relying on 'explore all paths' whereas John's does not.
Can 'explore all paths' work with 1M bpf insns? No.
Whereas an approach that builds dom graph, detects natural loops
and loop invariants - can.
> > Hence do_check approach must go. The rough idea is to compute per basic
> > block a set of INs (registers and stack) that basic block needs
> > to see to be safe and corresponding set of OUTs.
> > Then propagate this knowledge across cfg edges.
> > Once we have such set per bpf function, it will essentially answer the question
> > 'what arguments this function needs to see to be safe and what it returns'
> > To make bpf libraries scale we'd need to keep such information
> > around after the verification, so dynamic linking and indirect calls
> > are fast to verify.
> > It's very high level obviously. There are many gotchas to resolve.
> I agree that if we can do this it'll be ideal. But that's a big 'if'; my
> example code was intended to demonstrate that the "set of INs bb/func needs to
> see to be safe" can be an arbitrarily complicated disjunction, and that instead
> of a combinatorially exploding number of paths to walk (the do_check() approach)
> you now have combinatorially exploding IN-constraints to propagate backwards.
This sounds like arbitrary assumptions what this new approach would do.
Instead of rejecting it outright try to solve this very hard problem.
Before this discussion gets carried away too far let's get back to this patch set.
Having seen all arguments I still think that only patch 3 is worth pursuing further.
^ permalink raw reply
* Re: [PATCH net-next RFC 0/5] ipv6: sr: introduce seg6local End.BPF action
From: Alexei Starovoitov @ 2018-04-05 5:10 UTC (permalink / raw)
To: Mathieu Xhonneux
Cc: David Lebrun, Network Development, David Lebrun, Daniel Borkmann
On Wed, Apr 4, 2018 at 2:34 AM, Mathieu Xhonneux <m.xhonneux@gmail.com> wrote:
> 2018-04-03 16:25 GMT+02:00 David Lebrun <dav.lebrun@gmail.com>:
>> Actually I'm wrong here. dst_input() will call either ip6_input() or
>> ip6_forward(), not ipv6_rcv(). Both functions expect IP6CB() to be set,
>> so using skb->cb here will interfere with them.
>>
>> What about saving and restoring the IPv6 CB, similarly to what TCP does with
>> tcp_v6_restore_cb() ?
>
>
> Yes. I can change the call to bpf_prog_run_save_cb to bpf_prog_run_clear_cb,
> and then manually save/restore the IPv6 CB in input_action_end_bpf.
>
> Or is there maybe a better solution to share some state between the bpf caller
> and helpers, that does not need access to skb->cb ?
I think per-cpu scratch buffer approach can work for this
situation. Similar to one used by do_redirect and sockmap.
^ permalink raw reply
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: Stuart Yoder @ 2018-04-05 4:24 UTC (permalink / raw)
To: Andrew Lunn
Cc: Arnd Bergmann, Ioana Ciornei, gregkh, Laurentiu Tudor,
Linux Kernel Mailing List, Ruxandra Ioana Ciocoi Radulescu,
Razvan Stefanescu, Roy Pledge, Networking
In-Reply-To: <20180404124246.GA20869@lunn.ch>
On Wed, Apr 4, 2018 at 7:42 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>> I hear you. It is more complicated this way...having all these individual
>> objects vs just a single "bundle" of them that represents a NIC. But, that's
>> the way the DPAA2 hardware is, and we're implementing kernel support for
>> the hardware as it is.
>
> Hi Stuart
>
> I see we are not making any progress here.
>
> So what i suggest is you post the kernel code and configuration tool
> concept to netdev for a full review. You want reviews from David
> Miller, Jiri Pirko, Jakub Kicinski, David Ahern, etc.
I know Ioana has other feedback she is addressing so a respin will be coming
soon, and she can include those additional reviewers.
Thanks,
Stuart
^ permalink raw reply
* Re: [PATCH net-next] vxlan: add ttl inherit support
From: Hangbin Liu @ 2018-04-05 3:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20180404.120339.1405395328329628050.davem@davemloft.net>
On Wed, Apr 04, 2018 at 12:03:39PM -0400, David Miller wrote:
> The net-next tree is closed, please resubmit this when the net-next tree opens
> back up.
Sorry, I didn't pay much attention on the net-next open/close cycle before.
After re-read netdev-FAQ.txt. Now I understand the steps and I need send
net-next patch after rc1 released.
Sorry to bother you again...
Regards
Hangbin
^ permalink raw reply
* marvell switch
From: Ran Shalit @ 2018-04-05 2:47 UTC (permalink / raw)
To: netdev
Hello,
I am trying to use marvell switch in linux,
Is it that the kernel drivers from marvell switch are used just to
enable all ports, or do they also provide APIs to userspace to enable
specific ports only.
I have not find examples or wiki for marvell switch, so I am not too
sure as what are the drivers meant for.
Thank you,
ranran
^ permalink raw reply
* Re: [PATCH net] net: dsa: Discard frames from unused ports
From: Andrew Lunn @ 2018-04-05 2:17 UTC (permalink / raw)
To: Florian Fainelli; +Cc: David Miller, netdev, Vivien Didelot
In-Reply-To: <ac81103a-97f4-c7ae-3f12-c78e617f4edc@gmail.com>
On Wed, Apr 04, 2018 at 05:49:10PM -0700, Florian Fainelli wrote:
> On 04/04/2018 04:56 PM, Andrew Lunn wrote:
> > The Marvell switches under some conditions will pass a frame to the
> > host with the port being the CPU port. Such frames are invalid, and
> > should be dropped. Not dropping them can result in a crash when
> > incrementing the receive statistics for an invalid port.
> >
> > Reported-by: Chris Healy <cphealy@gmail.com>
> > Fixes: 5f6b4e14cada ("net: dsa: User per-cpu 64-bit statistics")
>
> Are you sure this is the commit that introduced the problem?
Hi Florian
Well, the problem is it crashes when trying to update the
statistics. The CPU port is not allocated a p->stats64, only slave
ports get those. So before this patch, there was no crash and the
frame would be delivered to the master interface. This in itself is
probably not correct, but also not fatal. Talking to Chris, it seems
this behaviour has existing for a long while. I needed to use lldpd to
trigger the issue, because i assume the Marvell switch sees these as
special frames and forwards them to the CPU. The other thing is, the
code got refactored recently. So this fix will not rebase to too many
earlier versions. It needs a fix per tagging protocol for before the
common dsa_master_find_slave() was added.
> > - return ds->ports[port].slave;
> > + slave_port = &ds->ports[port];
> > +
> > + if (slave_port->type != DSA_PORT_TYPE_USER)
>
> Can we optimize this with an unlikely()?
Yes, that would make sense.
Andrew
^ permalink raw reply
* Re: [rtlwifi-btcoex] Suspicious code in halbtc8821a1ant driver
From: Pkshih @ 2018-04-05 2:06 UTC (permalink / raw)
To: 莊彥宣, kvalo@codeaurora.org,
gustavo@embeddedor.com
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180405012540.GA24241@embeddedor.com>
On Thu, 2018-04-05 at 01:25 +0000, Gustavo A. R. Silva wrote:
> Hi all,
>
> While doing some static analysis I came across the following piece of code at
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c:1581:
>
> 1581 static void btc8821a1ant_act_bt_sco_hid_only_busy(struct btc_coexist *btcoexist,
> 1582 u8 wifi_status)
> 1583 {
> 1584 /* tdma and coex table */
> 1585 btc8821a1ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 5);
> 1586
> 1587 if (BT_8821A_1ANT_WIFI_STATUS_NON_CONNECTED_ASSO_AUTH_SCAN ==
> 1588 wifi_status)
> 1589 btc8821a1ant_coex_table_with_type(btcoexist, NORMAL_EXEC, 1);
> 1590 else
> 1591 btc8821a1ant_coex_table_with_type(btcoexist, NORMAL_EXEC, 1);
> 1592 }
>
> The issue here is that the code for both branches of the if-else statement is identical.
>
> The if-else was introduced a year ago in this commit c6821613e653
>
> I wonder if an argument should be changed in any of the calls to
> btc8821a1ant_coex_table_with_type?
>
>
It looks weird. Since we're in spring vacation, I'll check my colleague next Monday.
PK
^ permalink raw reply
* [PULL] fwcfg, vhost: features and fixes
From: Michael S. Tsirkin @ 2018-04-05 1:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: kvm, virtualization, netdev, linux-kernel, bhe, dyoung,
marcandre.lureau, mst, somlo, sonnyrao
The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae:
Linux 4.16-rc5 (2018-03-11 17:25:09 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to dc32bb678e103afbcfa4d814489af0566307f528:
vhost: add vsock compat ioctl (2018-03-20 03:17:42 +0200)
----------------------------------------------------------------
fw_cfg, vhost: features fixes
This cleans up the qemu fw cfg device driver.
On top of this, vmcore is dumped there on crash to
help debugging witH kASLR enabled.
Also included are some fixes in vhost.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
----------------------------------------------------------------
Marc-André Lureau (10):
fw_cfg: fix sparse warnings in fw_cfg_sel_endianness()
fw_cfg: fix sparse warnings with fw_cfg_file
fw_cfg: fix sparse warning reading FW_CFG_ID
fw_cfg: fix sparse warnings around FW_CFG_FILE_DIR read
fw_cfg: remove inline from fw_cfg_read_blob()
fw_cfg: handle fw_cfg_read_blob() error
fw_cfg: add a public uapi header
fw_cfg: add DMA register
crash: export paddr_vmcoreinfo_note()
fw_cfg: write vmcoreinfo details
Michael S. Tsirkin (1):
ptr_ring: fix build
Sonny Rao (2):
vhost: fix vhost ioctl signature to build with clang
vhost: add vsock compat ioctl
MAINTAINERS | 1 +
drivers/firmware/qemu_fw_cfg.c | 291 +++++++++++++++++++++++++++++++--------
drivers/vhost/vhost.c | 2 +-
drivers/vhost/vhost.h | 4 +-
drivers/vhost/vsock.c | 11 ++
include/uapi/linux/qemu_fw_cfg.h | 97 +++++++++++++
kernel/crash_core.c | 1 +
tools/virtio/ringtest/ptr_ring.c | 5 +
8 files changed, 348 insertions(+), 64 deletions(-)
create mode 100644 include/uapi/linux/qemu_fw_cfg.h
^ permalink raw reply
* RE: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC address support for ethtool nftuple filters
From: Brown, Aaron F @ 2018-04-05 1:47 UTC (permalink / raw)
To: Gomes, Vinicius, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Sanchez-Palencia, Jesus
In-Reply-To: <20180329210751.11531-9-vinicius.gomes@intel.com>
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Thursday, March 29, 2018 2:08 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus <jesus.sanchez-
> palencia@intel.com>
> Subject: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC
> address support for ethtool nftuple filters
>
> This adds the capability of configuring the queue steering of arriving
> packets based on their source and destination MAC addresses.
>
> In practical terms this adds support for the following use cases,
> characterized by these examples:
>
> $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0
> (this will direct packets with destination address "aa:aa:aa:aa:aa:aa"
> to the RX queue 0)
This is now working for me, testing with the dst MAC being the MAC on the i210. I set the filter and all the traffic to the destination MAC address gets routed to the chosen RX queue.
> $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 action 3
> (this will direct packets with source address "44:44:44:44:44:44" to
> the RX queue 3)
However, I am still not getting the raw ethernet source filter to work. Even back to back with no other system to "confuse" the stream, I set the filter so the source MAC is the same as the MAC on the link partner, send traffic and the traffic bounces around the queues as if the filter is not set.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb_ethtool.c | 35
> ++++++++++++++++++++++++----
> 1 file changed, 31 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the pci tree
From: Stephen Rothwell @ 2018-04-05 1:40 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List, Tariq Toukan, Saeed Mahameed,
Tal Gilboa
In-Reply-To: <20180403131454.4f9f032d@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 3018 bytes --]
Hi all,
On Tue, 3 Apr 2018 13:14:54 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>
> between commit:
>
> 2907938d2375 ("net/mlx5e: Use pcie_bandwidth_available() to compute bandwidth")
>
> from the pci tree and commit:
>
> 0608d4dbaf4e ("net/mlx5e: Unify slow PCI heuristic")
>
> from the net-next tree.
>
> I fixed it up (see below) 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
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 884337f88589,0aab3afc6885..000000000000
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@@ -3880,16 -4026,50 +4033,20 @@@ void mlx5e_build_default_indir_rqt(u32
> indirection_rqt[i] = i % num_channels;
> }
>
> - static bool cqe_compress_heuristic(u32 link_speed, u32 pci_bw)
> -static int mlx5e_get_pci_bw(struct mlx5_core_dev *mdev, u32 *pci_bw)
> -{
> - enum pcie_link_width width;
> - enum pci_bus_speed speed;
> - int err = 0;
> -
> - err = pcie_get_minimum_link(mdev->pdev, &speed, &width);
> - if (err)
> - return err;
> -
> - if (speed == PCI_SPEED_UNKNOWN || width == PCIE_LNK_WIDTH_UNKNOWN)
> - return -EINVAL;
> -
> - switch (speed) {
> - case PCIE_SPEED_2_5GT:
> - *pci_bw = 2500 * width;
> - break;
> - case PCIE_SPEED_5_0GT:
> - *pci_bw = 5000 * width;
> - break;
> - case PCIE_SPEED_8_0GT:
> - *pci_bw = 8000 * width;
> - break;
> - default:
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
> + static bool slow_pci_heuristic(struct mlx5_core_dev *mdev)
> {
> - return (link_speed && pci_bw &&
> - (pci_bw < 40000) && (pci_bw < link_speed));
> - }
> + u32 link_speed = 0;
> + u32 pci_bw = 0;
>
> - static bool hw_lro_heuristic(u32 link_speed, u32 pci_bw)
> - {
> - return !(link_speed && pci_bw &&
> - (pci_bw <= 16000) && (pci_bw < link_speed));
> + mlx5e_get_max_linkspeed(mdev, &link_speed);
> - mlx5e_get_pci_bw(mdev, &pci_bw);
> ++ pci_bw = pcie_bandwidth_available(mdev->pdev, NULL, NULL, NULL);
> + mlx5_core_dbg_once(mdev, "Max link speed = %d, PCI BW = %d\n",
> + link_speed, pci_bw);
> +
> + #define MLX5E_SLOW_PCI_RATIO (2)
> +
> + return link_speed && pci_bw &&
> + link_speed > MLX5E_SLOW_PCI_RATIO * pci_bw;
> }
>
> void mlx5e_set_tx_cq_mode_params(struct mlx5e_params *params, u8 cq_period_mode)
This is now a conflict between the pci tree and Linus' tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net] netns: filter uevents correctly
From: Christian Brauner @ 2018-04-05 1:35 UTC (permalink / raw)
To: Eric W. Biederman, davem
Cc: Christian Brauner, gregkh, netdev, linux-kernel, avagin, ktkhai,
serge
In-Reply-To: <871sfuha2d.fsf@xmission.com>
On Wed, Apr 04, 2018 at 05:38:02PM -0500, Eric W. Biederman wrote:
> Christian Brauner <christian.brauner@canonical.com> writes:
>
> > On Wed, Apr 04, 2018 at 09:48:57PM +0200, Christian Brauner wrote:
> >> commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces")
> >>
> >> enabled sending hotplug events into all network namespaces back in 2010.
> >> Over time the set of uevents that get sent into all network namespaces has
> >> shrunk. We have now reached the point where hotplug events for all devices
> >> that carry a namespace tag are filtered according to that namespace.
> >>
> >> Specifically, they are filtered whenever the namespace tag of the kobject
> >> does not match the namespace tag of the netlink socket. One example are
> >> network devices. Uevents for network devices only show up in the network
> >> namespaces these devices are moved to or created in.
> >>
> >> However, any uevent for a kobject that does not have a namespace tag
> >> associated with it will not be filtered and we will *try* to broadcast it
> >> into all network namespaces.
> >>
> >> The original patchset was written in 2010 before user namespaces were a
> >> thing. With the introduction of user namespaces sending out uevents became
> >> partially isolated as they were filtered by user namespaces:
> >>
> >> net/netlink/af_netlink.c:do_one_broadcast()
> >>
> >> if (!net_eq(sock_net(sk), p->net)) {
> >> if (!(nlk->flags & NETLINK_F_LISTEN_ALL_NSID))
> >> return;
> >>
> >> if (!peernet_has_id(sock_net(sk), p->net))
> >> return;
> >>
> >> if (!file_ns_capable(sk->sk_socket->file, p->net->user_ns,
> >> CAP_NET_BROADCAST))
> >> j return;
> >> }
> >>
> >> The file_ns_capable() check will check whether the caller had
> >> CAP_NET_BROADCAST at the time of opening the netlink socket in the user
> >> namespace of interest. This check is fine in general but seems insufficient
> >> to me when paired with uevents. The reason is that devices always belong to
> >> the initial user namespace so uevents for kobjects that do not carry a
> >> namespace tag should never be sent into another user namespace. This has
> >> been the intention all along. But there's one case where this breaks,
> >> namely if a new user namespace is created by root on the host and an
> >> identity mapping is established between root on the host and root in the
> >> new user namespace. Here's a reproducer:
> >>
> >> sudo unshare -U --map-root
> >> udevadm monitor -k
> >> # Now change to initial user namespace and e.g. do
> >> modprobe kvm
> >> # or
> >> rmmod kvm
> >>
> >> will allow the non-initial user namespace to retrieve all uevents from the
> >> host. This seems very anecdotal given that in the general case user
> >> namespaces do not see any uevents and also can't really do anything useful
> >> with them.
> >>
> >> Additionally, it is now possible to send uevents from userspace. As such we
> >> can let a sufficiently privileged (CAP_SYS_ADMIN in the owning user
> >> namespace of the network namespace of the netlink socket) userspace process
> >> make a decision what uevents should be sent.
> >>
> >> This makes me think that we should simply ensure that uevents for kobjects
> >> that do not carry a namespace tag are *always* filtered by user namespace
> >> in kobj_bcast_filter(). Specifically:
> >> - If the owning user namespace of the uevent socket is not init_user_ns the
> >> event will always be filtered.
> >> - If the network namespace the uevent socket belongs to was created in the
> >> initial user namespace but was opened from a non-initial user namespace
> >> the event will be filtered as well.
> >> Put another way, uevents for kobjects not carrying a namespace tag are now
> >> always only sent to the initial user namespace. The regression potential
> >> for this is near to non-existent since user namespaces can't really do
> >> anything with interesting devices.
> >>
> >> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> >
> > That was supposed to be [PATCH net] not [PATCH net-next] which is
> > obviously closed. Sorry about that.
>
> This does not appear to be a fix.
> This looks like feature work.
> The motivation appears to be that looks wrong let's change it.
Hm, it looked like an oversight an therefore seems like a bug which is
why I thought would be a good candidate for net. Recent patches to the
semantics here just make it more obvious and provide a better argument
to fix it in the current release rather then defer it to the next one.
But I'm happy to leave this for net-next. I don't want to rush things if
this change in semantics is not trivial enough. For the record, I'm
merely fixing/expanding on the current status quo.
David, is it ok to queue this or would you prefer I resend when net-next
reopens?
>
> So let's please leave this for when net-next opens again so we can
> have time to fully consider a change in semantics.
Sure, if we agree that this is the way to go I'm happy too.
Is your issue just with when we merge it and you disagree from a
technical perspective? That wasn't entirely obvious from your previous
mail. :)
Thanks!
Christian
>
> Thank you,
> Eric
^ permalink raw reply
* Re: [PATCH net v5 3/3] ipv6: udp6: set dst cache for a connected sk if current not valid
From: Sasha Levin @ 2018-04-05 1:34 UTC (permalink / raw)
To: Sasha Levin, Alexey Kodanev, netdev@vger.kernel.org
Cc: Eric Dumazet, stable@vger.kernel.org
In-Reply-To: <1522677635-5364-4-git-send-email-alexey.kodanev@oracle.com>
Hi Alexey Kodanev.
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag.
fixing commit: 33c162a980fe ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update.
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92,
v4.15.15: Failed to apply! Possible dependencies:
22b12d2bf404: ("ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow()")
v4.14.32: Failed to apply! Possible dependencies:
22b12d2bf404: ("ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow()")
v4.9.92: Failed to apply! Possible dependencies:
22b12d2bf404: ("ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow()")
^ permalink raw reply
* Re: [PATCH net 2/2] net: bgmac: Fix endian access in bgmac_dma_tx_ring_free()
From: Sasha Levin @ 2018-04-05 1:33 UTC (permalink / raw)
To: Sasha Levin, Florian Fainelli, netdev@vger.kernel.org
Cc: Florian Fainelli, stable@vger.kernel.org
In-Reply-To: <20180401172630.12883-3-f.fainelli@gmail.com>
Hi Florian Fainelli.
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag.
fixing commit: 9cde94506eac bgmac: implement scatter/gather support.
The bot has also determined it's probably a bug fixing patch. (score: 45.9160)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Build OK!
^ permalink raw reply
* Re: [PATCH net 1/2] net: bgmac: Correctly annotate register space
From: Sasha Levin @ 2018-04-05 1:33 UTC (permalink / raw)
To: Sasha Levin, Florian Fainelli, netdev@vger.kernel.org
Cc: Florian Fainelli, stable@vger.kernel.org
In-Reply-To: <20180401172630.12883-2-f.fainelli@gmail.com>
Hi Florian Fainelli.
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag.
fixing commit: f6a95a24957a net: ethernet: bgmac: Add platform device support.
The bot has also determined it's probably a bug fixing patch. (score: 67.8237)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Failed to apply! Possible dependencies:
dd5c5d037f5e: ("net: ethernet: bgmac: add NS2 support")
1676aba5ef7e: ("net: ethernet: bgmac: device tree phy enablement")
^ permalink raw reply
* Re: [PATCH net] route: check sysctl_fib_multipath_use_neigh earlier than hash
From: Sasha Levin @ 2018-04-05 1:33 UTC (permalink / raw)
To: Sasha Levin, Xin Long, network dev
Cc: davem@davemloft.net, Julian Anastasov, stable@vger.kernel.org
In-Reply-To: <6265ae9495a93efac372d41001c5ebccbb916df7.1522593635.git.lucien.xin@gmail.com>
Hi Xin Long.
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag.
fixing commit: a6db4494d218 net: ipv4: Consider failed nexthops in multipath routes.
The bot has also determined it's probably a bug fixing patch. (score: 58.0140)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
^ permalink raw reply
* Re: [PATCH v2 net-next 01/10] mlxsw: spectrum_acl: Fix flex actions header ifndef define construct
From: Sasha Levin @ 2018-04-05 1:33 UTC (permalink / raw)
To: Sasha Levin, Ido Schimmel, Jiri Pirko, netdev@vger.kernel.org
Cc: davem@davemloft.net, jiri@mellanox.com, petrm@mellanox.com,
stable@vger.kernel.org
In-Reply-To: <20180401143459.30770-2-idosch@mellanox.com>
Hi Ido Schimmel
Jiri Pirko.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 2.6781)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Failed to apply! Possible dependencies:
d3b939b8f9a5: ("mlxsw: spectrum: Move ACL flexible actions instance to spectrum")
e2b2d35a052d: ("mlxsw: spectrum: Change init order")
v4.9.92: Failed to apply! Possible dependencies:
d3b939b8f9a5: ("mlxsw: spectrum: Move ACL flexible actions instance to spectrum")
38ebc0f45474: ("mlxsw: spectrum_router: Add mlxsw_sp_ipip_ops")
ff7b0d27208b: ("mlxsw: spectrum: Add support for counter allocator")
7aa0f5aa9030: ("mlxsw: spectrum: Implement TC flower offload")
22a677661f56: ("mlxsw: spectrum: Introduce ACL core with simple TCAM implementation")
1d20d23c59c9: ("mlxsw: Move PCI id table definitions into driver modules")
62e86f9e8281: ("mlxsw: pci: Rename header with HW definitions")
98d0f7b9acda: ("mlxsw: spectrum: Add packet sample offloading support")
65acb5d0827c: ("mlxsw: spectrum: Make the add_matchall_tc_entry symmetric")
5724b8b56947: ("net/sched: tc_mirred: Rename public predicates 'is_tcf_mirred_redirect' and 'is_tcf_mirred_mirror'")
v4.4.126: Failed to apply! Possible dependencies:
d3b939b8f9a5: ("mlxsw: spectrum: Move ACL flexible actions instance to spectrum")
38ebc0f45474: ("mlxsw: spectrum_router: Add mlxsw_sp_ipip_ops")
ff7b0d27208b: ("mlxsw: spectrum: Add support for counter allocator")
7aa0f5aa9030: ("mlxsw: spectrum: Implement TC flower offload")
b090ef068645: ("mlxsw: Introduce simplistic KVD linear area manager")
464dce188487: ("mlxsw: spectrum_router: Add basic ipv4 router initialization")
f00817df2b42: ("mlxsw: spectrum: Introduce support for Data Center Bridging (DCB)")
90183b980d0a: ("mlxsw: spectrum: Initialize egress scheduling")
7f71eb46a485: ("mlxsw: spectrum: Split vFID range in two")
bd40e9d6d538: ("mlxsw: spectrum: Allocate active VLANs only for port netdevs")
0d65fc13042f: ("mlxsw: spectrum: Implement LAG port join/leave")
c4745500e988: ("mlxsw: Implement devlink interface")
89309da39f55: ("mlxsw: core: Implement temperature hwmon interface")
7f71eb46a485: ("mlxsw: spectrum: Split vFID range in two")
bd40e9d6d538: ("mlxsw: spectrum: Allocate active VLANs only for port netdevs")
0d65fc13042f: ("mlxsw: spectrum: Implement LAG port join/leave")
18f1e70c4137: ("mlxsw: spectrum: Introduce port splitting")
3e9b27b8fc8b: ("mlxsw: spectrum: Unmap local port from module during teardown")
bd40e9d6d538: ("mlxsw: spectrum: Allocate active VLANs only for port netdevs")
c4745500e988: ("mlxsw: Implement devlink interface")
Please let us know if you'd like to have this patch included in a stable tree.
^ permalink raw reply
* Re: [PATCH v2 net-next 06/10] mlxsw: core: Fix arg name of MLXSW_CORE_RES_VALID and MLXSW_CORE_RES_GET
From: Sasha Levin @ 2018-04-05 1:33 UTC (permalink / raw)
To: Sasha Levin, Ido Schimmel, Jiri Pirko, netdev@vger.kernel.org
Cc: davem@davemloft.net, jiri@mellanox.com, petrm@mellanox.com,
stable@vger.kernel.org
In-Reply-To: <20180401143459.30770-7-idosch@mellanox.com>
Hi Ido Schimmel
Jiri Pirko.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 1.5151)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Failed to apply! Possible dependencies:
c1a3831121f6: ("mlxsw: Convert resources into array")
v4.4.126: Failed to apply! Possible dependencies:
403547d38d0b: ("mlxsw: profile: Add KVD resources to profile config")
489107bda1d1: ("mlxsw: Add KVD sizes configuration into profile")
57d316ba2017: ("mlxsw: pci: Add resources query implementation.")
8060646a0fd1: ("mlxsw: core: Add support for packets received from LAG port")
89309da39f55: ("mlxsw: core: Implement temperature hwmon interface")
89309da39f55: ("mlxsw: core: Implement temperature hwmon interface")
932762b69a28: ("mlxsw: Move devlink port registration into common core code")
8060646a0fd1: ("mlxsw: core: Add support for packets received from LAG port")
89309da39f55: ("mlxsw: core: Implement temperature hwmon interface")
90183b980d0a: ("mlxsw: spectrum: Initialize egress scheduling")
7f71eb46a485: ("mlxsw: spectrum: Split vFID range in two")
bd40e9d6d538: ("mlxsw: spectrum: Allocate active VLANs only for port netdevs")
0d65fc13042f: ("mlxsw: spectrum: Implement LAG port join/leave")
c4745500e988: ("mlxsw: Implement devlink interface")
89309da39f55: ("mlxsw: core: Implement temperature hwmon interface")
7f71eb46a485: ("mlxsw: spectrum: Split vFID range in two")
Please let us know if you'd like to have this patch included in a stable tree.
^ 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