* Re: [PATCH V4 5/8] ARM: dts: stm32: Add ethernet dwmac on stm32mp1
From: Alexandre Torgue @ 2018-06-26 13:21 UTC (permalink / raw)
To: Christophe Roullier, mark.rutland, mcoquelin.stm32,
peppe.cavallaro
Cc: devicetree, linux-arm-kernel, netdev, andrew
In-Reply-To: <1527090479-5263-6-git-send-email-christophe.roullier@st.com>
Hi christophe
On 05/23/2018 05:47 PM, Christophe Roullier wrote:
> Add Ethernet support (Synopsys MAC IP 4.20a) on stm32mp1 SOC.
> Enable feature supported by the stmmac driver, such as TSO.
>
> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
> ---
> arch/arm/boot/dts/stm32mp157c.dtsi | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
> index 3db03a2..ea7b6cb 100644
> --- a/arch/arm/boot/dts/stm32mp157c.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157c.dtsi
> @@ -179,5 +179,35 @@
> clocks = <&rcc USART1_K>;
> status = "disabled";
> };
> +
> + stmmac_axi_config_0: stmmac-axi-config {
> + snps,wr_osr_lmt = <0x7>;
> + snps,rd_osr_lmt = <0x7>;
> + snps,blen = <0 0 0 0 16 8 4>;
> + };
> +
> + ethernet0: ethernet@5800a000 {
> + compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a";
> + reg = <0x5800a000 0x2000>;
> + reg-names = "stmmaceth";
> + interrupts-extended = <&intc GIC_SPI 61 IRQ_TYPE_NONE>;
IRQ_TYPE_NONE souldn't be used. Please provide edge sensitiv or level
sensitic type.
> + interrupt-names = "macirq";
> + clock-names = "stmmaceth",
> + "mac-clk-tx",
> + "mac-clk-rx",
> + "ethstp",
> + "syscfg-clk";
> + clocks = <&rcc ETHMAC>,
> + <&rcc ETHTX>,
> + <&rcc ETHRX>,
> + <&rcc ETHSTP>,
> + <&rcc SYSCFG>;
> + st,syscon = <&syscfg 0x4>;
> + snps,mixed-burst;
> + snps,pbl = <2>;
> + snps,axi-config = <&stmmac_axi_config_0>;
> + snps,tso;
> + status = "disabled";
> + };
> };
> };
>
^ permalink raw reply
* Re: [PATCH net-next] rds: clean up loopback rds_connections on netns deletion
From: David Miller @ 2018-06-26 13:23 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: netdev, rds-devel, santosh.shilimkar
In-Reply-To: <1529934085-181126-1-git-send-email-sowmini.varadhan@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Mon, 25 Jun 2018 06:41:25 -0700
> The RDS core module creates rds_connections based on callbacks
> from rds_loop_transport when sending/receiving packets to local
> addresses.
>
> These connections will need to be cleaned up when they are
> created from a netns that is not init_net, and that netns is deleted.
>
> Add the changes aligned with the changes from
> commit ebeeb1ad9b8a ("rds: tcp: use rds_destroy_pending() to synchronize
> netns/module teardown and rds connection/workq management") for
> rds_loop_transport
>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Since this probably fixes syzbot reports, this can be targetted
at 'net' instead?
^ permalink raw reply
* Re: [lkp-robot] [bisect done] ace45bec6d [ 52.056290] EIP: lock_release
From: David Howells @ 2018-06-26 13:25 UTC (permalink / raw)
To: kernel test robot; +Cc: dhowells, linux-afs, netdev, LKP
In-Reply-To: <20180626010626.GG11011@yexl-desktop>
kernel test robot <lkp@intel.com> wrote:
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit ace45bec6d77bc061c3c3d8ad99e298ea9800c2b
> Author: David Howells <dhowells@redhat.com>
> AuthorDate: Fri Mar 30 21:04:43 2018 +0100
> Commit: David Howells <dhowells@redhat.com>
> CommitDate: Fri Mar 30 21:04:43 2018 +0100
>
> rxrpc: Fix firewall route keepalive
Are you actually making AF_RXRPC or the AFS filesystem do anything? Or is it
just happening spontaneously?
David
^ permalink raw reply
* Re: [PATCH net-next] net: preserve sock reference when scrubbing the skb.
From: Flavio Leitner @ 2018-06-26 13:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Cong Wang, Linux Kernel Network Developers, Paolo Abeni,
David Miller, Florian Westphal, NetFilter
In-Reply-To: <afa1296b-9c3a-a60c-da69-76c3fd031bbe@gmail.com>
On Tue, Jun 26, 2018 at 06:06:36AM -0700, Eric Dumazet wrote:
>
>
> On 06/26/2018 05:38 AM, Flavio Leitner wrote:
> > On Mon, Jun 25, 2018 at 11:41:05PM -0700, Eric Dumazet wrote:
> >> I am not sure why the patch is so complex, I would have simply
> >> removed the skb_orphan().
> >
> > All the rest is fixing netfilter to consider the namespaces before
> > doing any actions. For instance, it would be possible to dump GID/UID
> > of the process originating the packet in a foreign net namespace.
> >
> > Another example is matching if it has a socket or not. I don't think
> > it's correct to match on a socket that is on a foreign netns.
> >
> > So, you're right that removing the skb_orphan() is the only thing
> > required to fix both issues, but then what about the above examples?
> >
>
> Please split the work in two parts.
>
> 1) Preparation, with clear commit log :)
>
> 2) Removal of skb_orphan()
ok, will do.
Thanks,
--
Flavio
^ permalink raw reply
* Re: [PATCH 00/14] ARM: davinci: step towards removing at24_platform_data
From: Bartosz Golaszewski @ 2018-06-26 13:38 UTC (permalink / raw)
To: Andrew Lunn
Cc: Sekhar Nori, Kevin Hilman, Russell King, Grygorii Strashko,
David S . Miller, Srinivas Kandagatla, Lukas Wunner, Rob Herring,
Florian Fainelli, Dan Carpenter, Ivan Khoronzhuk, David Lechner,
Greg Kroah-Hartman, Linux ARM, Linux Kernel Mailing List,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180626132154.GA5064@lunn.ch>
2018-06-26 15:21 GMT+02:00 Andrew Lunn <andrew@lunn.ch>:
>> I see. I see it this way: the setup callback comes from the time when
>> we didn't have nvmem and should go away. I will protest loud whenever
>> someone will try to use it again and will work towards removing it as
>> soon as possible.
>
> The setup() callback could be moved into the nvmem framework, rather
> than in the at24 driver. Make the call when the cells have been
> connected to the backing store.
>
This would at least make it more generic. And maybe I could also get
rid of the setup callback from the mityomapl138 board file.
Bart
>> I will give your problem a thought and will try to get back with some
>> proposals - maybe we should, as you suggested, extend nvmem even
>> further to allow to remove nvmem info entries etc.
>
> That does not help me too much. I have the same problem with i2c and
> MDIO. So i actually prefer to keep this the same as all others.
>
> Andrew
^ permalink raw reply
* Re: [PATCH net-next] rds: clean up loopback rds_connections on netns deletion
From: Sowmini Varadhan @ 2018-06-26 13:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, rds-devel, santosh.shilimkar
In-Reply-To: <20180626.222345.1953178647182804872.davem@davemloft.net>
On (06/26/18 22:23), David Miller wrote:
>
> Since this probably fixes syzbot reports, this can be targetted
> at 'net' instead?
that thought occurred to me but I wanted to be conservative and have
it in net-next first, have the syzkaller-bugs team confirm the
the fixes and then backport to earlier kernels (if needed)..
--Sowmini
^ permalink raw reply
* Re: [PATCH v2 bpf-net] bpf: Change bpf_fib_lookup to return lookup status
From: David Ahern @ 2018-06-26 13:53 UTC (permalink / raw)
To: Daniel Borkmann, dsahern, netdev, borkmann, ast; +Cc: davem, kafai
In-Reply-To: <4cd62659-1b52-6746-5a37-faa01d476476@iogearbox.net>
On 6/26/18 3:50 AM, Daniel Borkmann wrote:
> [...]
> You change all the semantics of return code here, but this breaks bpf_skb_fib_lookup().
> I cannot see how this would work in that case. The code does the following with the
> bpf_ipv{4,6}_fib_lookup() return code:
>
> [...]
> switch (params->family) {
> #if IS_ENABLED(CONFIG_INET)
> case AF_INET:
> index = bpf_ipv4_fib_lookup(net, params, flags, false);
> break;
> #endif
> #if IS_ENABLED(CONFIG_IPV6)
> case AF_INET6:
> index = bpf_ipv6_fib_lookup(net, params, flags, false);
> break;
> #endif
> }
>
> if (index > 0) {
> struct net_device *dev;
>
> dev = dev_get_by_index_rcu(net, index);
> if (!is_skb_forwardable(dev, skb))
> index = 0;
> }
Yes, I forgot to update the skb path. That should be rc now and then the
dev lookup based on params->ifindex. Will fix.
> [...]
>
> So the BPF_FIB_LKUP_* results become the dev ifindex here and the !is_skb_forwardable()
> case further suggests that the packet *can* be forwarded based on the new semantics
> whereas MTU check is bypassed on success.
>
> It probably helps to craft a selftest for XDP *and* tc case in future, so we can be sure
> nothing breaks with new changes.
yes, will do.
^ permalink raw reply
* Re: [PATCH 0/4] lan78xx minor fixes
From: David Miller @ 2018-06-26 13:54 UTC (permalink / raw)
To: dave.stevenson; +Cc: woojung.huh, UNGLinuxDriver, netdev
In-Reply-To: <cover.1529935234.git.dave.stevenson@raspberrypi.org>
From: Dave Stevenson <dave.stevenson@raspberrypi.org>
Date: Mon, 25 Jun 2018 15:07:11 +0100
> This is a small set of patches for the Microchip LAN78xx chip,
> as used in the Raspberry Pi 3B+.
> The main debug/discussion was on
> https://github.com/raspberrypi/linux/issues/2458
...
Series applied, thank you.
^ permalink raw reply
* Re: [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Michael S. Tsirkin @ 2018-06-26 13:54 UTC (permalink / raw)
To: Cornelia Huck
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, konrad.wilk,
Jakub Kicinski, Samudrala, Sridhar, qemu-devel, virtualization,
Siwei Liu, Venu Busireddy, Netdev, boris.ostrovsky, aaron.f.brown,
Joao Martins
In-Reply-To: <20180626135509.23154723.cohuck@redhat.com>
On Tue, Jun 26, 2018 at 01:55:09PM +0200, Cornelia Huck wrote:
> On Tue, 26 Jun 2018 04:46:03 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Mon, Jun 25, 2018 at 11:55:12AM +0200, Cornelia Huck wrote:
> > > On Fri, 22 Jun 2018 22:05:50 +0300
> > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >
> > > > On Fri, Jun 22, 2018 at 05:09:55PM +0200, Cornelia Huck wrote:
> > > > > On Thu, 21 Jun 2018 21:20:13 +0300
> > > > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > >
> > > > > > On Thu, Jun 21, 2018 at 04:59:13PM +0200, Cornelia Huck wrote:
> > > > > > > OK, so what about the following:
> > > > > > >
> > > > > > > - introduce a new feature bit, VIRTIO_NET_F_STANDBY_UUID that indicates
> > > > > > > that we have a new uuid field in the virtio-net config space
> > > > > > > - in QEMU, add a property for virtio-net that allows to specify a uuid,
> > > > > > > offer VIRTIO_NET_F_STANDBY_UUID if set
> > > > > > > - when configuring, set the property to the group UUID of the vfio-pci
> > > > > > > device
> > > > > > > - in the guest, use the uuid from the virtio-net device's config space
> > > > > > > if applicable; else, fall back to matching by MAC as done today
> > > > > > >
> > > > > > > That should work for all virtio transports.
> > > > > >
> > > > > > True. I'm a bit unhappy that it's virtio net specific though
> > > > > > since down the road I expect we'll have a very similar feature
> > > > > > for scsi (and maybe others).
> > > > > >
> > > > > > But we do not have a way to have fields that are portable
> > > > > > both across devices and transports, and I think it would
> > > > > > be a useful addition. How would this work though? Any idea?
> > > > >
> > > > > Can we introduce some kind of device-independent config space area?
> > > > > Pushing back the device-specific config space by a certain value if the
> > > > > appropriate feature is negotiated and use that for things like the uuid?
> > > >
> > > > So config moves back and forth?
> > > > Reminds me of the msi vector mess we had with pci.
> > >
> > > Yes, that would be a bit unfortunate.
> > >
> > > > I'd rather have every transport add a new config.
> > >
> > > You mean via different mechanisms?
> >
> > I guess so.
>
> Is there an alternate mechanism for pci to use? (Not so familiar with
> it.)
We have a device and transport config capability.
We could add a generic config capability too.
> For ccw, this needs more thought. We already introduced two commands
> for reading/writing the config space (a concept that does not really
> exist on s390). There's the generic read configuration data command,
> but the data returned by it is not really generic enough. So we would
> need one new command (or two, if we need to write as well). I'm not
> sure about that yet.
>
> >
> > > >
> > > > > But regardless of that, I'm not sure whether extending this approach to
> > > > > other device types is the way to go. Tying together two different
> > > > > devices is creating complicated situations at least in the hypervisor
> > > > > (even if it's fairly straightforward in the guest). [I have not come
> > > > > around again to look at the "how to handle visibility in QEMU"
> > > > > questions due to lack of cycles, sorry about that.]
> > > > >
> > > > > So, what's the goal of this approach? Only to allow migration with
> > > > > vfio-pci, or also to plug in a faster device and use it instead of an
> > > > > already attached paravirtualized device?
> > > >
> > > > These are two sides of the same coin, I think the second approach
> > > > is closer to what we are doing here.
> > >
> > > Thinking about it, do we need any knob to keep the vfio device
> > > invisible if the virtio device is not present? IOW, how does the
> > > hypervisor know that the vfio device is supposed to be paired with a
> > > virtio device? It seems we need an explicit tie-in.
> >
> > If we are going the way of the bridge, both bridge and
> > virtio would have some kind of id.
>
> So the presence of the id would indicate "this is one part of a pair"?
I guess so, yes.
> >
> > When pairing using mac, I'm less sure. PAss vfio device mac to qemu
> > as a property?
>
> That feels a bit odd. "This is the vfio device's mac, use this instead
> of your usual mac property"? As we have not designed the QEMU interface
> yet, just go with the id in any case? The guest can still match by mac.
OK
> > > > > What about migration of vfio devices that are not easily replaced by a
> > > > > paravirtualized device? I'm thinking of vfio-ccw, where our main (and
> > > > > currently only) supported device is dasd (disks) -- which can do a lot
> > > > > of specialized things that virtio-blk does not support (and should not
> > > > > or even cannot support).
> > > >
> > > > But maybe virtio-scsi can?
> > >
> > > I don't think so. Dasds have some channel commands that don't map
> > > easily to scsi commands.
> >
> > There's always a choice of adding these to the spec.
> > E.g. FC extensions were proposed, I don't remember why they
> > are still stuck.
>
> FC extensions are a completely different kind of enhancements, though.
> For a start, they are not unique to a certain transport.
>
> Also, we have a whole list of special dasd issues. Weird disk layout
> for eckd, low-level disk formatting, etc. (See the list of commands in
> drivers/s390/block/dasd_eckd.h for an idea. There's also no public
> documentation AFAICS; https://en.wikipedia.org/wiki/ECKD does not link
> to anything interesting.) I don't think we want to cram stuff like this
> into a completely different framework.
^ permalink raw reply
* Re: [PATCH net-next 0/7] l2tp: trivial cleanups
From: David Miller @ 2018-06-26 13:56 UTC (permalink / raw)
To: g.nault; +Cc: netdev, jchapman
In-Reply-To: <cover.1529935024.git.g.nault@alphalink.fr>
From: Guillaume Nault <g.nault@alphalink.fr>
Date: Mon, 25 Jun 2018 16:07:17 +0200
> Just a set of unrelated trivial cleanups (remove unused code, make
> local functions static, etc.).
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] selftests: net: Test headroom handling of ip6_gre devices
From: David Miller @ 2018-06-26 14:03 UTC (permalink / raw)
To: petrm; +Cc: netdev, linux-kselftest, shuah, u9012063
In-Reply-To: <2071eab42614e7019ece0e2d6f89fdde55815347.1529937619.git.petrm@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Date: Mon, 25 Jun 2018 16:43:55 +0200
> Commit 5691484df961 ("net: ip6_gre: Fix headroom request in
> ip6erspan_tunnel_xmit()") and commit 01b8d064d58b ("net: ip6_gre:
> Request headroom in __gre6_xmit()") fix problems in reserving headroom
> in the packets tunneled through ip6gre/tap and ip6erspan netdevices.
>
> These two patches included snippets that reproduced the issues. This
> patch elevates the snippets to a full-fledged test case.
>
> Suggested-by: David Miller <davem@davemloft.net>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] r8169: reject unsupported WoL options
From: David Miller @ 2018-06-26 14:07 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <85243a82-291f-71d7-7519-b6e9dc19463b@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 25 Jun 2018 20:34:41 +0200
> So far unsupported WoL options are silently ignored. Change this and
> reject attempts to set unsupported options. This prevents situations
> where a user tries to set an unsupported WoL option and is under the
> impression it was successful because ethtool doesn't complain.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] sh_eth: RPADIR related clean-ups
From: David Miller @ 2018-06-26 14:16 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <2809eba8-4c9a-1d5f-a47d-8125777e365b@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Mon, 25 Jun 2018 23:34:52 +0300
> Here's a set of 2 patches against DaveM's 'net-next.git' repo. They are
> clean-ups related to RPADIR (DMA padding to NET_IP_ALIGN)...
Series applied.
^ permalink raw reply
* [PATCH net-next 1/1] tc-tests: add an extreme-case csum action test
From: Keara Leibovitz @ 2018-06-26 14:16 UTC (permalink / raw)
To: davem; +Cc: netdev, jhs, xiyou.wangcong, jiri, lucasb, Keara Leibovitz
Added an extreme-case test for all 7 csum action headers.
Signed-off-by: Keara Leibovitz <kleib@mojatatu.com>
---
.../tc-testing/tc-tests/actions/csum.json | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/csum.json b/tools/testing/selftests/tc-testing/tc-tests/actions/csum.json
index 3a2f51fc7fd4..a022792d392a 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/actions/csum.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/actions/csum.json
@@ -336,6 +336,30 @@
]
},
{
+ "id": "b10b",
+ "name": "Add all 7 csum actions",
+ "category": [
+ "actions",
+ "csum"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action csum",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action csum icmp ip4h sctp igmp udplite udp tcp index 7",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action csum index 7",
+ "matchPattern": "action order [0-9]*: csum \\(iph, icmp, igmp, tcp, udp, udplite, sctp\\).*index 7 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action csum"
+ ]
+ },
+ {
"id": "ce92",
"name": "Add csum udp action with cookie",
"category": [
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] NFC: llcp: fix nfc_llcp_send_ui_frame() lockup
From: Steven Rostedt @ 2018-06-26 14:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: Sergey Senozhatsky, Dmitry Vyukov, Samuel Ortiz, David S. Miller,
Petr Mladek, syzkaller-bugs, linux-wireless, netdev, LKML, syzbot,
Sergey Senozhatsky
In-Reply-To: <8c410102-43ab-dfdb-0d71-2ee5951e1af8@gmail.com>
On Mon, 25 Jun 2018 23:44:22 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > The loop is still infinite, correct, but we have a preemption point now.
> > Sure, net people can come with a much better solution, I'll be happy to
> > scratch my patch.
> >
>
> This can not be the right solution, think about current thread being real time,
> cond_resched() might be a nop.
Good point! Bah, as one of the RT maintainers, I should have noticed
that too :-p
I'm losing my touch.
-- Steve
>
> We should probably not loop at all, or not use MSG_DONTWAIT.
>
> (And remove this useless "Could not allocate PDU" message)
>
> NFC maintainers should really take a look at this.
^ permalink raw reply
* Bug report: epoll can fail to report EPOLLOUT when unix datagram socket peer is closed
From: Ian Lance Taylor @ 2018-06-26 14:18 UTC (permalink / raw)
To: netdev
I'm reporting what appears to be a bug in the Linux kernel's epoll
support. It seems that epoll appears to sometimes fail to report an
EPOLLOUT event when the other side of an AF_UNIX/SOCK_DGRAM socket is
closed. This bug report started as a Go program reported at
https://golang.org/issue/23604. I've written a C program that
demonstrates the same symptoms, at
https://github.com/golang/go/issues/23604#issuecomment-398945027 .
The C program sets up an AF_UNIX/SOCK_DGRAM server and serveral
identical clients, all running in non-blocking mode. All the
non-blocking sockets are added to epoll, using EPOLLET. The server
periodically closes and reopens its socket. The clients look for
ECONNREFUSED errors on their write calls, and close and reopen their
sockets when they see one.
The clients will sometimes fill up their buffer and block with EAGAIN.
At that point they expect the poller to return an EPOLLOUT event to
tell them when they are ready to write again. The expectation is that
either the server will read data, freeing up buffer space, or will
close the socket, which should cause the sending packets to be
discarded, freeing up buffer space. Generally the EPOLLOUT event
happens. But sometimes, the poller never returns such an event, and
the client stalls. In the test program this is reported as a client
that waits more than 20 seconds to be told to continue.
A similar bug report was made, with few details, at
https://stackoverflow.com/questions/38441059/edge-triggered-epoll-for-unix-domain-socket
.
I've tested the program and seen the failure on kernel 4.9.0-6-amd64.
A colleague has tested the program and seen the failure on
4.18.0-smp-DEV #3 SMP @1529531011 x86_64 GNU/Linux.
If there is a better way for me to report this, please let me know.
Thanks for your attention.
Ian
^ permalink raw reply
* Re: [PATCH net-next v2 0/7] net: sched: support replay of filter offload when binding to block
From: David Miller @ 2018-06-26 14:21 UTC (permalink / raw)
To: jakub.kicinski; +Cc: jiri, xiyou.wangcong, jhs, gerlitz.or, netdev, oss-drivers
In-Reply-To: <20180625213010.13266-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Mon, 25 Jun 2018 14:30:03 -0700
> This series from John adds the ability to replay filter offload requests
> when new offload callback is being registered on a TC block. This is most
> likely to take place for shared blocks today, when a block which already
> has rules is bound to another interface. Prior to this patch set if any
> of the rules were offloaded the block bind would fail.
>
> A new tcf_proto_op is added to generate a filter-specific offload request.
> The new 'offload' op is supporting extack from day 0, hence we need to
> propagate extack to .ndo_setup_tc TC_BLOCK_BIND/TC_BLOCK_UNBIND and
> through tcf_block_cb_register() to tcf_block_playback_offloads().
>
> The immediate use of this patch set is to simplify life of drivers which
> require duplicating rules when sharing blocks. Switch drivers (mlxsw)
> can bind ports to rule lists dynamically, NIC drivers generally don't
> have that ability and need the rules to be duplicated for each ingress
> they match on. In code terms this means that switch drivers don't
> register multiple callbacks for each port. NIC drivers do, and get a
> separate request and hance rule per-port, as if the block was not shared.
> The registration fails today, however, if some rules were already present.
>
> As John notes in description of patch 7, drivers which register multiple
> callbacks to shared blocks will likely need to flush the rules on block
> unbind. This set makes the core not only replay the the offload add
> requests but also offload remove requests when callback is unregistered.
>
> v2:
> - name parameters in patch 2;
> - use unsigned int instead of u32 for in_hw_coun;
> - improve extack message in patch 7.
Series applied, thank you.
^ permalink raw reply
* Re: [patch net-next RFC 03/12] mlxsw: core: Add core environment module for port temperature reading
From: Andrew Lunn @ 2018-06-26 14:22 UTC (permalink / raw)
To: Vadim Pasternak, linux-pm; +Cc: netdev, linux, rui.zhang, edubezval, jiri
In-Reply-To: <1530015037-67361-4-git-send-email-vadimp@mellanox.com>
On Tue, Jun 26, 2018 at 12:10:28PM +0000, Vadim Pasternak wrote:
Adding the linux-pm@vger.kernel.org list.
> Add new core_env module to allow port temperature reading. This
> information has most critical impact on system's thermal monitoring and
> is to be used by core_hwmon and core_thermal modules.
>
> New internal API reads the temperature from all the modules, which are
> equipped with the thermal sensor and exposes temperature according to
> the worst measure. All individual temperature values are normalized to
> pre-defined range.
This patchset has been sent to the netdev list before. I raised a few
questions about this, which is why it is now being posted to a bigger
group for review.
The hardware has up to 64 temperature sensors. These sensors are
hot-plugable, since they are inside SFP modules, which are
hot-plugable. Different SFP modules can have different operating
temperature ranges. They contain an EEPROM which lists upper and lower
warning and fail temperatures, and report alarms when these thresholds
a reached.
This code takes the 64 sensors readings and calculates a single value
it passes to one thermal zone. That thermal zone then controls one fan
to keep this single value in range.
I queried is this is the correct way to do this? Would it not be
better to have up to 64 thermal zones? Leave the thermal core to
iterate over all the zones in order to determine how the fan should be
driven?
This is possibly the first board with so many sensors. However, i
doubt it is totally unique. Other big Ethernet switches with lots of
SFP modules may be added later. Also, 10G copper PHYs often have
temperature sensors, so this is not limited to just boards with
optical ports. So having a generic solution would be good.
What do the Linux PM exports say about this?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH v4 net-next] mdio-mux-gpio: Remove VLA usage
From: David Miller @ 2018-06-26 14:25 UTC (permalink / raw)
To: keescook; +Cc: linux-kernel, joe, andrew, netdev
In-Reply-To: <20180625224949.GA48766@beast>
From: Kees Cook <keescook@chromium.org>
Date: Mon, 25 Jun 2018 15:49:49 -0700
> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates the values buffer during the callback instead of putting it
> on the stack.
>
> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] selftests: forwarding: mirror_gre_vlan_bridge_1q: Unset rp_filter
From: David Miller @ 2018-06-26 14:25 UTC (permalink / raw)
To: petrm; +Cc: netdev, linux-kselftest, shuah
In-Reply-To: <66d218fb95026460e240752eec3af58920a14d86.1529968802.git.petrm@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Date: Tue, 26 Jun 2018 01:20:32 +0200
> The IP addresses of tunnel endpoint at H3 are set at the VLAN device
> $h3.555. Therefore when test_gretap_untagged_egress() sets vlan 555 to
> egress untagged at $swp3, $h3's rp_filter rejects these packets. The
> test then spuriously fails.
>
> Therefore turn off net.ipv4.conf.{all, $h3}.rp_filter.
>
> Fixes: 9c7c8a82442c ("selftests: forwarding: mirror_gre_vlan_bridge_1q: Add more tests")
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Applied.
^ permalink raw reply
* Re: [patch net-next RFC 11/12] mlxsw: core: Extend hwmon interface with FAN fault attribute
From: Andrew Lunn @ 2018-06-26 14:28 UTC (permalink / raw)
To: Vadim Pasternak
Cc: davem, netdev, linux, rui.zhang, edubezval, jiri, mlxsw,
michaelsh
In-Reply-To: <1530015037-67361-12-git-send-email-vadimp@mellanox.com>
> +static ssize_t mlxsw_hwmon_fan_fault_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct mlxsw_hwmon_attr *mlwsw_hwmon_attr =
> + container_of(attr, struct mlxsw_hwmon_attr, dev_attr);
> + struct mlxsw_hwmon *mlxsw_hwmon = mlwsw_hwmon_attr->hwmon;
> + char mfsm_pl[MLXSW_REG_MFSM_LEN];
> + u16 tach;
> + int err;
> +
> + mlxsw_reg_mfsm_pack(mfsm_pl, mlwsw_hwmon_attr->type_index);
> + err = mlxsw_reg_query(mlxsw_hwmon->core, MLXSW_REG(mfsm), mfsm_pl);
> + if (err) {
> + dev_err(mlxsw_hwmon->bus_info->dev, "Failed to query fan\n");
> + return err;
> + }
> + tach = mlxsw_reg_mfsm_rpm_get(mfsm_pl);
> +
> + return sprintf(buf, "%u\n", (tach < mlxsw_hwmon->tach_min) ? 1 : 0);
> +}
Documentation/hwmon/sysfs-interface says:
Alarms are direct indications read from the chips. The drivers do NOT
make comparisons of readings to thresholds. This allows violations
between readings to be caught and alarmed. The exact definition of an
alarm (for example, whether a threshold must be met or must be exceeded
to cause an alarm) is chip-dependent.
Now, this is a fault, not an alarm. But does the same apply?
Andrew
^ permalink raw reply
* Re: [PATCH net-next] rds: clean up loopback rds_connections on netns deletion
From: David Miller @ 2018-06-26 14:29 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: netdev, rds-devel, santosh.shilimkar
In-Reply-To: <20180626134043.GE20575@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Tue, 26 Jun 2018 09:40:43 -0400
> On (06/26/18 22:23), David Miller wrote:
>>
>> Since this probably fixes syzbot reports, this can be targetted
>> at 'net' instead?
>
> that thought occurred to me but I wanted to be conservative and have
> it in net-next first, have the syzkaller-bugs team confirm the
> the fixes and then backport to earlier kernels (if needed)..
I think there is a way to ask syzbot to test a patch in an
email.
^ permalink raw reply
* Re: [PATCH net-next] rds: clean up loopback rds_connections on netns deletion
From: Sowmini Varadhan @ 2018-06-26 14:44 UTC (permalink / raw)
To: David Miller
Cc: netdev, rds-devel, santosh.shilimkar, dvyukov, syzkaller-bugs
In-Reply-To: <20180626.232956.1181108479532700313.davem@davemloft.net>
On (06/26/18 23:29), David Miller wrote:
>
> I think there is a way to ask syzbot to test a patch in an
> email.
Dmitry/syzkaller-bugs, can you clarify?
This is for the cluster of dup reports like
https://groups.google.com/forum/#!topic/syzkaller-bugs/zBph8Vu-q2U
and (most recently)
https://www.spinics.net/lists/linux-rdma/msg66020.html
as I understand it, if there is no reproducer, you cannot really
have a pass/fail test to confirm the fix.
--Sowmini
^ permalink raw reply
* RE: [patch net-next RFC 11/12] mlxsw: core: Extend hwmon interface with FAN fault attribute
From: Vadim Pasternak @ 2018-06-26 14:47 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem@davemloft.net, netdev@vger.kernel.org, linux@roeck-us.net,
rui.zhang@intel.com, edubezval@gmail.com, jiri@resnulli.us, mlxsw,
Michael Shych
In-Reply-To: <20180626142838.GC5064@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Tuesday, June 26, 2018 5:29 PM
> To: Vadim Pasternak <vadimp@mellanox.com>
> Cc: davem@davemloft.net; netdev@vger.kernel.org; linux@roeck-us.net;
> rui.zhang@intel.com; edubezval@gmail.com; jiri@resnulli.us; mlxsw
> <mlxsw@mellanox.com>; Michael Shych <michaelsh@mellanox.com>
> Subject: Re: [patch net-next RFC 11/12] mlxsw: core: Extend hwmon interface
> with FAN fault attribute
>
> > +static ssize_t mlxsw_hwmon_fan_fault_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + struct mlxsw_hwmon_attr *mlwsw_hwmon_attr =
> > + container_of(attr, struct mlxsw_hwmon_attr,
> dev_attr);
> > + struct mlxsw_hwmon *mlxsw_hwmon = mlwsw_hwmon_attr->hwmon;
> > + char mfsm_pl[MLXSW_REG_MFSM_LEN];
> > + u16 tach;
> > + int err;
> > +
> > + mlxsw_reg_mfsm_pack(mfsm_pl, mlwsw_hwmon_attr->type_index);
> > + err = mlxsw_reg_query(mlxsw_hwmon->core, MLXSW_REG(mfsm),
> mfsm_pl);
> > + if (err) {
> > + dev_err(mlxsw_hwmon->bus_info->dev, "Failed to query
> fan\n");
> > + return err;
> > + }
> > + tach = mlxsw_reg_mfsm_rpm_get(mfsm_pl);
> > +
> > + return sprintf(buf, "%u\n", (tach < mlxsw_hwmon->tach_min) ? 1 : 0);
> > +}
>
> Documentation/hwmon/sysfs-interface says:
>
> Alarms are direct indications read from the chips. The drivers do NOT make
> comparisons of readings to thresholds. This allows violations between readings
> to be caught and alarmed. The exact definition of an alarm (for example,
> whether a threshold must be met or must be exceeded to cause an alarm) is
> chip-dependent.
>
> Now, this is a fault, not an alarm. But does the same apply?
Hi Andrew,
Hardware provides minimum value for tachometer.
Tachometer is considered as faulty in case it's below this
value.
In case any tachometer is faulty, PWM according to the
system requirements should be set to 100% until the fault
is not recovered (f.e. by physical replacing of bad unit).
This is the motivation to expose fan{x}_fault in the way
it's exposed.
Thanks,
Vadim.
>
> Andrew
^ permalink raw reply
* Re: [PATCH net-next] rds: clean up loopback rds_connections on netns deletion
From: Dmitry Vyukov @ 2018-06-26 14:48 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: David Miller, netdev, rds-devel, Santosh Shilimkar,
syzkaller-bugs
In-Reply-To: <20180626144454.GF20575@oracle.com>
On Tue, Jun 26, 2018 at 4:44 PM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> On (06/26/18 23:29), David Miller wrote:
>>
>> I think there is a way to ask syzbot to test a patch in an
>> email.
>
> Dmitry/syzkaller-bugs, can you clarify?
>
> This is for the cluster of dup reports like
> https://groups.google.com/forum/#!topic/syzkaller-bugs/zBph8Vu-q2U
> and (most recently)
> https://www.spinics.net/lists/linux-rdma/msg66020.html
>
> as I understand it, if there is no reproducer, you cannot really
> have a pass/fail test to confirm the fix.
This bug has a reproducer as far as I see:
https://syzkaller.appspot.com/bug?id=f4ef381349e100280193c25f24e01d9d364132d9
It seems to be a subtle race since syzbot did not progress with
minimization too much:
https://syzkaller.appspot.com/text?tag=ReproSyz&x=16cbfeaf800000
it probably hit the race by a pure luck of the large program, but then
never had the same luck when tried to remove any syscalls.
So it can make sense to submit several test requests to get more testing.
^ 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