* Re: [Patch net] ipv4: restore rt->fi for reference counting
From: David Miller @ 2017-05-08 18:35 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, andreyknvl, edumazet
In-Reply-To: <1493934857-6693-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 4 May 2017 14:54:17 -0700
> IPv4 dst could use fi->fib_metrics to store metrics but fib_info
> itself is refcnt'ed, so without taking a refcnt fi and
> fi->fib_metrics could be freed while dst metrics still points to
> it. This triggers use-after-free as reported by Andrey twice.
>
> This patch reverts commit 2860583fe840 ("ipv4: Kill rt->fi") to
> restore this reference counting. It is a quick fix for -net and
> -stable, for -net-next, as Eric suggested, we can consider doing
> reference counting for metrics itself instead of relying on fib_info.
>
> IPv6 is very different, it copies or steals the metrics from mx6_config
> in fib6_commit_metrics() so probably doesn't need a refcnt.
>
> Decnet has already done the refcnt'ing, see dn_fib_semantic_match().
>
> Fixes: 2860583fe840 ("ipv4: Kill rt->fi")
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] tcp: make congestion control optionally skip slow start after idle
From: David Miller @ 2017-05-08 18:37 UTC (permalink / raw)
To: weiwan; +Cc: netdev, ycheng, ncardwell, edumazet
In-Reply-To: <20170505195323.124792-1-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Date: Fri, 5 May 2017 12:53:23 -0700
> From: Wei Wang <weiwan@google.com>
>
> Congestion control modules that want full control over congestion
> control behavior do not want the cwnd modifications controlled by
> the sysctl_tcp_slow_start_after_idle code path.
> So skip those code paths for CC modules that use the cong_control()
> API.
> As an example, those cwnd effects are not desired for the BBR congestion
> control algorithm.
>
> Fixes: c0402760f565 ("tcp: new CC hook to set sending rate with rate_sample in any CA state")
> Signed-off-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2] vlan: Keep NETIF_F_HW_CSUM similar to other software devices
From: David Miller @ 2017-05-08 18:39 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, mkubecek, alexander.duyck, avagin, vyasevic
In-Reply-To: <1494015461-12192-1-git-send-email-vyasevic@redhat.com>
From: Vladislav Yasevich <vyasevich@gmail.com>
Date: Fri, 5 May 2017 16:17:41 -0400
> Vlan devices, like all other software devices, enable
> NETIF_F_HW_CSUM feature. However, unlike all the othe other
> software devices, vlans will switch to using IP|IPV6_CSUM
> features, if the underlying devices uses them. In these situations,
> checksum offload features on the vlan device can't be controlled
> via ethtool.
>
> This patch makes vlans keep HW_CSUM feature if the underlying
> device supports checksum offloading. This makes vlan devices
> behave like other software devices, and restores control to the
> user.
>
> A side-effect is that some offload settings (typically UFO)
> may be enabled on the vlan device while being disabled on the HW.
> However, the GSO code will correctly process the packets. This
> actually results in slightly better raw throughput.
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> ---
> V2: posted the right patch.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] bna: Avoid reading past end of buffer
From: David Miller @ 2017-05-08 18:42 UTC (permalink / raw)
To: keescook
Cc: netdev, rasesh.mody, sudarsana.kalluru, Dept-GELinuxNICDev,
linux-kernel, danielmicay
In-Reply-To: <20170505222532.GA16005@beast>
From: Kees Cook <keescook@chromium.org>
Date: Fri, 5 May 2017 15:25:32 -0700
> Using memcpy() from a string that is shorter than the length copied means
> the destination buffer is being filled with arbitrary data from the kernel
> rodata segment. Instead, use strncpy() which will fill the trailing bytes
> with zeros.
>
> This was found with the future CONFIG_FORTIFY_SOURCE feature.
>
> Cc: Daniel Micay <danielmicay@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Applied.
^ permalink raw reply
* Re: [PATCH] bna: ethtool: Avoid reading past end of buffer
From: David Miller @ 2017-05-08 18:42 UTC (permalink / raw)
To: keescook
Cc: netdev, rasesh.mody, sudarsana.kalluru, linux-kernel,
Dept-GELinuxNICDev, danielmicay
In-Reply-To: <20170505223023.GA17972@beast>
From: Kees Cook <keescook@chromium.org>
Date: Fri, 5 May 2017 15:30:23 -0700
> Using memcpy() from a string that is shorter than the length copied means
> the destination buffer is being filled with arbitrary data from the kernel
> rodata segment. Instead, use strncpy() which will fill the trailing bytes
> with zeros.
>
> This was found with the future CONFIG_FORTIFY_SOURCE feature.
>
> Cc: Daniel Micay <danielmicay@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Applied.
^ permalink raw reply
* Re: [PATCH] qlge: Avoid reading past end of buffer
From: David Miller @ 2017-05-08 18:42 UTC (permalink / raw)
To: keescook
Cc: netdev, harish.patil, manish.chopra, Dept-GELinuxNICDev,
linux-kernel, danielmicay
In-Reply-To: <20170505223434.GA19245@beast>
From: Kees Cook <keescook@chromium.org>
Date: Fri, 5 May 2017 15:34:34 -0700
> Using memcpy() from a string that is shorter than the length copied means
> the destination buffer is being filled with arbitrary data from the kernel
> rodata segment. Instead, use strncpy() which will fill the trailing bytes
> with zeros.
>
> This was found with the future CONFIG_FORTIFY_SOURCE feature.
>
> Cc: Daniel Micay <danielmicay@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Applied.
^ permalink raw reply
* Re: [PATCH] bonding: check nla_put_be32 return value
From: David Miller @ 2017-05-08 18:57 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev
In-Reply-To: <1494040626-13862-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Sat, 6 May 2017 11:17:06 +0800
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bonding: make multi if nla_put_failure check into one
From: David Miller @ 2017-05-08 18:57 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev
In-Reply-To: <1494040672-13934-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Sat, 6 May 2017 11:17:52 +0800
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Changes like this neither make the code better nor worse, so please
avoid this kind of churn.
I'm not applying this.
Thank you.
^ permalink raw reply
* Re: [PATCH] net: dsa: loop: Check for memory allocation failure
From: David Miller @ 2017-05-08 19:01 UTC (permalink / raw)
To: christophe.jaillet
Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <20170506052945.2639-1-christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sat, 6 May 2017 07:29:45 +0200
> If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
> Return -ENOMEM instead, as done for some other memory allocation just a
> few lines above.
>
> Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Please do not separate "Fixes: " tags from signoffs and acks with
empty lines in the future, thank you.
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] cxgb4: avoid disabling FEC by default
From: David Miller @ 2017-05-08 19:01 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil
In-Reply-To: <1494060906-6453-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Sat, 6 May 2017 14:25:06 +0530
> Recent Chelsio firmware started using few port capablity bits to
> manage FEC and as driver was not aware of FEC changes those bits
> were zeroed, consequently disabling FEC.
>
> Avoid zeroing those bits and default to whatever the firmware
> tells us the Link is currently advertising.
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/hippi/rrunner: use memdup_user
From: David Miller @ 2017-05-08 19:02 UTC (permalink / raw)
To: geliangtang; +Cc: jes, linux-hippi, netdev, linux-kernel
In-Reply-To: <58733b05cfe6248e30471a59ad1faee7f2f71280.1493780932.git.geliangtang@gmail.com>
From: Geliang Tang <geliangtang@gmail.com>
Date: Sat, 6 May 2017 23:42:16 +0800
> Use memdup_user() helper instead of open-coding to simplify the code.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] yam: use memdup_user
From: David Miller @ 2017-05-08 19:02 UTC (permalink / raw)
To: geliangtang; +Cc: jpr, linux-hams, netdev, linux-kernel
In-Reply-To: <bd8ca4a87fc128e5260c13960423f025e1b42c5c.1493783298.git.geliangtang@gmail.com>
From: Geliang Tang <geliangtang@gmail.com>
Date: Sat, 6 May 2017 23:42:22 +0800
> Use memdup_user() helper instead of open-coding to simplify the code.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v2] Check for skb_put_padto return value
From: David Miller @ 2017-05-08 19:03 UTC (permalink / raw)
To: mail; +Cc: netdev
In-Reply-To: <0102015be3e8a656-6cd75d31-ac07-4255-80d9-3c481165dfaa-000000@eu-west-1.amazonses.com>
From: Peter Heise <mail@pheise.de>
Date: Sun, 7 May 2017 17:15:26 +0000
> Return value of skb_put_padto is now checked as
> reported by Dan Carpenter. skb might be freed in
> case of error in skb_put_padto.
> ---
> net/hsr/hsr_device.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
> index c73160fb11e7..a1545d09a3c9 100644
> --- a/net/hsr/hsr_device.c
> +++ b/net/hsr/hsr_device.c
> @@ -314,7 +314,8 @@ static void send_hsr_supervision_frame(struct hsr_port *master,
> hsr_sp = (typeof(hsr_sp)) skb_put(skb, sizeof(struct hsr_sup_payload));
> ether_addr_copy(hsr_sp->MacAddressA, master->dev->dev_addr);
>
> - skb_put_padto(skb, ETH_ZLEN + HSR_HLEN);
> + if (skb_put_padto(skb, ETH_ZLEN + HSR_HLEN))
> + return;
>
> hsr_forward_skb(skb, master);
> return;
You're adding a more serious bug than the one you are fixing.
Now, if skb_put_padto() fails, we leak the SKB.
^ permalink raw reply
* Re: [PATCH 0/4] TI Bluetooth serdev support
From: Sebastian Reichel @ 2017-05-08 19:07 UTC (permalink / raw)
To: Adam Ford
Cc: Rob Herring, Marcel Holtmann, linux-bluetooth, Mark Rutland,
devicetree, Johan Hedberg, Gustavo Padovan, Satish Patel, Wei Xu,
Eyal Reizer, netdev, linux-arm-kernel
In-Reply-To: <CAHCN7x+Mq=b6RN-ezU0400W=H=D7DR+Es1FHtT4GyozpVd8ALA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3458 bytes --]
Hi,
On Fri, May 05, 2017 at 09:51:33AM -0500, Adam Ford wrote:
> On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
> > On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
> >> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
> >> > This series adds serdev support to the HCI LL protocol used on TI BT
> >> > modules and enables support on HiKey board with with the WL1835 module.
> >> > With this the custom TI UIM daemon and btattach are no longer needed.
> >>
> >> Without UIM daemon, what instruction do you use to load the BT firmware?
> >>
> >> I was thinking 'hciattach' but I was having trouble. I was hoping you
> >> might have some insight.
> >>
> >> hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow Just
> >> returns a timeout.
> >>
> >> I modified my i.MX6 device tree per the binding documentation and
> >> setup the regulators and enable GPIO pins.
> >
> > If you configured everything correctly no userspace interaction is
> > required. The driver should request the firmware automatically once
> > you power up the bluetooth device.
> >
> > Apart from DT changes make sure, that the following options are
> > enabled and check dmesg for any hints.
> >
> > CONFIG_SERIAL_DEV_BUS
> > CONFIG_SERIAL_DEV_CTRL_TTYPORT
> > CONFIG_BT_HCIUART
> > CONFIG_BT_HCIUART_LL
>
> I have enabled those flags, and I have updated my device tree.
> I am testing this on an OMAP3630 (DM3730) board with a WL1283. I am
> getting a lot of timeout errors. I tested this against the original
> implemention I had in pdata-quirks.c using the ti-st driver, uim & and
> the btwilink driver.
>
> I pulled in some of the newer patches to enable the wl1283-st, but I
> am obviously missing something.
>
> I 58.717651] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [ 58.724853] Bluetooth: hci0: download firmware failed, retrying...
> [ 60.957641] Bluetooth: hci0 command 0x1001 tx timeout
> [ 68.957641] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [ 68.964843] Bluetooth: hci0: download firmware failed, retrying...
> [ 69.132171] Bluetooth: Unknown HCI packet type 06
> [ 69.138244] Bluetooth: Unknown HCI packet type 0c
> [ 69.143249] Bluetooth: Unknown HCI packet type 40
> [ 69.148498] Bluetooth: Unknown HCI packet type 20
> [ 69.153533] Bluetooth: Data length is too large
> [ 69.158569] Bluetooth: Unknown HCI packet type a0
> [ 69.163574] Bluetooth: Unknown HCI packet type 00
> [ 69.168731] Bluetooth: Unknown HCI packet type 00
> [ 69.173736] Bluetooth: Unknown HCI packet type 34
> [ 69.178924] Bluetooth: Unknown HCI packet type 91
> [ 71.197631] Bluetooth: hci0 command 0x1001 tx timeout
> [ 79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
>
> Since the pdata-quirks and original ti-st drivers work together, I
> know the hardware is fine. The only change to the device tree is the
> addition of the Bluetooth container:
>
> bluetooth {
> compatible = "ti,wl1283-st";
> enable-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
> };
>
> Any thoughts or suggestions to try? I get similar behavior on an
> i.MX6 board with a wl1837-st module as well.
Looks like its loosing bytes. I suggest to have a look at
pinmuxing (esp. for cts & rts) and maybe add some debug
prints to see where it starts failing.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net] bpf: don't let ldimm64 leak map addresses on unprivileged
From: David Miller @ 2017-05-08 19:08 UTC (permalink / raw)
To: daniel; +Cc: alexei.starovoitov, jannh, kafai, netdev
In-Reply-To: <793c517a7d163c613ab886eb02d32efea9f902fd.1494194233.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Mon, 8 May 2017 00:04:09 +0200
> The patch fixes two things at once:
>
> 1) It checks the env->allow_ptr_leaks and only prints the map address to
> the log if we have the privileges to do so, otherwise it just dumps 0
> as we would when kptr_restrict is enabled on %pK. Given the latter is
> off by default and not every distro sets it, I don't want to rely on
> this, hence the 0 by default for unprivileged.
>
> 2) Printing of ldimm64 in the verifier log is currently broken in that
> we don't print the full immediate, but only the 32 bit part of the
> first insn part for ldimm64. Thus, fix this up as well; it's okay to
> access, since we verified all ldimm64 earlier already (including just
> constants) through replace_map_fd_with_map_ptr().
>
> Fixes: cbd357008604 ("bpf: verifier (add ability to receive verification log)")
> Reported-by: Jann Horn <jannh@google.com>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Applied, with second Fixes: tag added, and queued up for -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: stmmac: properly set PS bit in MII configurations during reset
From: Thomas Petazzoni @ 2017-05-08 19:12 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: Corentin Labbe, Alexandre Torgue, netdev, stable
In-Reply-To: <49297ed2-84dc-3e9b-8f40-af915476a091@st.com>
Hello,
On Mon, 8 May 2017 16:28:21 +0200, Giuseppe CAVALLARO wrote:
> > I just see that GMAC_CONTROL and MAC_CTRL_REG are the same, so why not create a custom adjust_link for each dwmac type ?
> > This will permit to call it instead of set_ps() and remove lots of if (has_gmac) and co in stmmac_adjust_link()
> > Basicly replace all between "ctrl = readl()... and writel(ctrl)" by a sot of priv->hw->mac->adjust_link()
> >
> > It will also help a lot for my dwmac-sun8i inclusion (since I add some if has_sun8i:))
>
> Corentin, I think this is a good idea and maybe necessary now that the
> driver is supporting a lot of chips.
> In the past it was sufficient to have a adjust link function and a
> stmmac_hw_fix_mac_speed
> to invoke dedicated hook shared between MAC10/100 and GMAC inside STM
> platforms.
>
> Thomas, I wonder if you could take a look at the
> priv->plat->fix_mac_speed. This can be used
> for setting internal registers too.
Once again, this is not called at the right time to fix the issue I'm
seeing with a MII PHY. I need to adjust the PS bit between asserting the
reset and polling for the reset bit to clear.
->fix_mac_speed() is called in the adjust_link() call-back, which is
called way too late.
Please, read again my patch and the description of the problem that I
have sent. But basically, any solution that does not allow to set the
PS bit between asserting the DMA reset bit and polling for it to clear
will not work for MII PHYs.
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH RFC] net: Fix inconsistent teardown and release of private netdev state.
From: Stephen Hemminger @ 2017-05-08 19:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170508.125243.1637135196896174683.davem@davemloft.net>
On Mon, 08 May 2017 12:52:43 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> Network devices can allocate reasources and private memory using
> netdev_ops->ndo_init(). However, the release of these resources
> can occur in one of two different places.
>
> Either netdev_ops->ndo_uninit() or netdev->destructor().
>
> The decision of which operation frees the resources depends upon
> whether it is necessary for all netdev refs to be released before it
> is safe to perform the freeing.
>
> netdev_ops->ndo_uninit() presumably can occur right after the
> NETDEV_UNREGISTER notifier completes and the unicast and multicast
> address lists are flushed.
>
> netdev->destructor(), on the other hand, does not run until the
> netdev references all go away.
>
> Further complicating the situation is that netdev->destructor()
> almost universally does also a free_netdev().
>
> This creates a problem for the logic in register_netdevice().
> Because all callers of register_netdevice() manage the freeing
> of the netdev, and invoke free_netdev(dev) if register_netdevice()
> fails.
>
> If netdev_ops->ndo_init() succeeds, but something else fails inside
> of register_netdevice(), it does call ndo_ops->ndo_uninit(). But
> it is not able to invoke netdev->destructor().
>
> This is because netdev->destructor() will do a free_netdev() and
> then the caller of register_netdevice() will do the same.
>
> However, this means that the resources that would normally be released
> by netdev->destructor() will not be.
>
> Over the years drivers have added local hacks to deal with this, by
> invoking their destructor parts by hand when register_netdevice()
> fails.
>
> Many drivers do not try to deal with this, and instead we have leaks.
>
> Let's close this hole by formalizing the distinction between what
> private things need to be freed up by netdev->destructor() and whether
> the driver needs unregister_netdevice() to perform the free_netdev().
>
> netdev->priv_destructor() performs all actions to free up the private
> resources that used to be freed by netdev->destructor(), except for
> free_netdev().
>
> netdev->needs_free_netdev is a boolean that indicates whether
> free_netdev() should be done at the end of unregister_netdevice().
>
> Now, register_netdevice() can sanely release all resources after
> ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
> and netdev->priv_destructor().
>
> And at the end of unregister_netdevice(), we invoke
> netdev->priv_destructor() and optionally call free_netdev().
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
Thanks for addressing a confusing and messy semantic. If you merge
this then it would be good to update the documentation in Doucmentation/networking
to describe how drivers are supposed to behave.
The original semantics here evolved from a desire not to have to re-engineer
lots of device drivers. And your change does the same; ie. assume that there
is a reason the device needs special treatment on unregister.
An alternative and more difficult way of addressing the problem would
be to rework the drivers that define destructors to work with the simpler
model used by all the other drivers. What makes these drivers special,
and can they be fixed instead. Probably this won't work and would be too
much effort on lots of little used devices.
^ permalink raw reply
* Re: [PATCH v2 net] vti: check nla_put_* return value
From: David Miller @ 2017-05-08 19:14 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev
In-Reply-To: <1494237433-18964-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Mon, 8 May 2017 17:57:13 +0800
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v1 0/4] stmmac: pci: Fix crash on Intel Galileo Gen2
From: David Miller @ 2017-05-08 19:15 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: Joao.Pinto, jan.kiszka, netdev, peppe.cavallaro
In-Reply-To: <20170508141422.39612-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon, 8 May 2017 17:14:18 +0300
> Due to misconfiguration of PCI driver for Intel Quark the user will get
> a kernel crash:
>
> # udhcpc -i eth0
> udhcpc: started, v1.26.2
> stmmaceth 0000:00:14.6 eth0: device MAC address 98:4f:ee:05:ac:47
> Generic PHY stmmac-a6:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=stmmac-a6:01, irq=-1)
> stmmaceth 0000:00:14.6 eth0: IEEE 1588-2008 Advanced Timestamp supported
> stmmaceth 0000:00:14.6 eth0: registered PTP clock
> IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>
> udhcpc: sending discover
>
> stmmaceth 0000:00:14.6 eth0: Link is Up - 100Mbps/Full - flow control off
> IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: stmmac_xmit+0xf1/0x1080
>
> Fix this by adding necessary settings.
>
> P.S. I split fix to three patches according to what each of them adds.
Looks good, series applied, thanks.
^ permalink raw reply
* [PATCH] net: ethernet: ti: cpsw: adjust cpsw fifos depth for fullduplex flow control
From: Grygorii Strashko @ 2017-05-08 19:21 UTC (permalink / raw)
To: David S. Miller, netdev, Sekhar Nori, Ivan Khoronzhuk
Cc: linux-kernel, linux-omap, Grygorii Strashko, Schuyler Patton
When users set flow control using ethtool the bits are set properly in the
CPGMAC_SL MACCONTROL register, but the FIFO depth in the respective Port n
Maximum FIFO Blocks (Pn_MAX_BLKS) registers remains set to the minimum size
reset value. When receive flow control is enabled on a port, the port's
associated FIFO block allocation must be adjusted. The port RX allocation
must increase to accommodate the flow control runout. The TRM recommends
numbers of 5 or 6.
Hence, apply required Port FIFO configuration to
Pn_MAX_BLKS.Pn_TX_MAX_BLKS=0xF and Pn_MAX_BLKS.Pn_RX_MAX_BLKS=0x5 during
interface initialization.
Cc: Schuyler Patton <spatton@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 20fd14c..7cf9c79 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -287,6 +287,10 @@ struct cpsw_ss_regs {
/* Bit definitions for the CPSW1_TS_SEQ_LTYPE register */
#define CPSW_V1_SEQ_ID_OFS_SHIFT 16
+#define CPSW_MAX_BLKS_TX 15
+#define CPSW_MAX_BLKS_TX_SHIFT 4
+#define CPSW_MAX_BLKS_RX 5
+
struct cpsw_host_regs {
u32 max_blks;
u32 blk_cnt;
@@ -1278,11 +1282,23 @@ static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
switch (cpsw->version) {
case CPSW_VERSION_1:
slave_write(slave, TX_PRIORITY_MAPPING, CPSW1_TX_PRI_MAP);
+ /* Increase RX FIFO size to 5 for supporting fullduplex
+ * flow control mode
+ */
+ slave_write(slave,
+ (CPSW_MAX_BLKS_TX << CPSW_MAX_BLKS_TX_SHIFT) |
+ CPSW_MAX_BLKS_RX, CPSW1_MAX_BLKS);
break;
case CPSW_VERSION_2:
case CPSW_VERSION_3:
case CPSW_VERSION_4:
slave_write(slave, TX_PRIORITY_MAPPING, CPSW2_TX_PRI_MAP);
+ /* Increase RX FIFO size to 5 for supporting fullduplex
+ * flow control mode
+ */
+ slave_write(slave,
+ (CPSW_MAX_BLKS_TX << CPSW_MAX_BLKS_TX_SHIFT) |
+ CPSW_MAX_BLKS_RX, CPSW2_MAX_BLKS);
break;
}
--
2.10.1
^ permalink raw reply related
* Re: [PATCH RFC] net: Fix inconsistent teardown and release of private netdev state.
From: David Miller @ 2017-05-08 19:21 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20170508121359.45e367e5@xeon-e3>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Mon, 8 May 2017 12:13:59 -0700
> Thanks for addressing a confusing and messy semantic. If you merge
> this then it would be good to update the documentation in
> Doucmentation/networking to describe how drivers are supposed to
> behave.
Will do.
> An alternative and more difficult way of addressing the problem would
> be to rework the drivers that define destructors to work with the simpler
> model used by all the other drivers. What makes these drivers special,
> and can they be fixed instead. Probably this won't work and would be too
> much effort on lots of little used devices.
The biggest problem is that we have two models of teardown... well
actually the issue is more about resources allocated at probe time.
For many software devices, instances come from ->newlink() or other
config requests, so they go "register the device" and then forget
about it, leaving it to the registered callbacks to cleanup.
But things are different for most hardware devices. They allocate
resources on probe, and therefore absolutely cannot let
register_netdevice(), or the callbacks, release those resources
nor perform the free_netdev().
So what a lot of drivers do is, in their driver ->remove() method,
unregister the device, release the probe time resources, then
do the free_netdev() by hand.
So as you say, these interfaces and their behavior evolved over time
in response to need.
^ permalink raw reply
* Re: [PATCH] net/fsl: remove func xgmac_wait_until_free() as duplicate
From: David Miller @ 2017-05-08 19:34 UTC (permalink / raw)
To: ardeleanalex; +Cc: netdev, Shaohui.Xie
In-Reply-To: <1494243078-17917-1-git-send-email-ardeleanalex@gmail.com>
From: Alexandru Ardelean <ardeleanalex@gmail.com>
Date: Mon, 8 May 2017 14:31:18 +0300
> Looking at xgmac_wait_until_done() and xgmac_wait_until_free()
> functions, they seem to have turned out completely identical.
>
> Though, judging from the git history it seems they
> initially weren't.
>
> Remove xgmac_wait_until_free() in favor of xgmac_wait_until_done().
>
> Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This situation got created by the commit below, I wonder if it
is even correct.
Certainly the original author of this code intended the MDIO
_data_ rather than the _status_ register to be polled.
Otherwise, why in the world have two functions which are in
every other regard identical?
commit 26eee0210ad72a29eb4a70b34320bda266f91a0d
Author: Shaohui Xie <Shaohui.Xie@freescale.com>
Date: Mon Mar 16 18:55:50 2015 +0800
net/fsl: fix a bug in xgmac_mdio
There is a bug in xgmac_wait_until_done() which mdio_stat should be used
instead of mdio_data when checking if busy bit is cleared.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/drivers/net/ethernet/freescale/xgmac_mdio.c b/drivers/net/ethernet/freescale/xgmac_mdio.c
index 3a83bc2..5f691f2 100644
--- a/drivers/net/ethernet/freescale/xgmac_mdio.c
+++ b/drivers/net/ethernet/freescale/xgmac_mdio.c
@@ -79,7 +79,7 @@ static int xgmac_wait_until_done(struct device *dev,
/* Wait till the MDIO write is complete */
timeout = TIMEOUT;
- while ((ioread32be(®s->mdio_data) & MDIO_DATA_BSY) && timeout) {
+ while ((ioread32be(®s->mdio_stat) & MDIO_STAT_BSY) && timeout) {
cpu_relax();
timeout--;
}
^ permalink raw reply related
* Re: SSE instructions for fast packet copy?
From: Benjamin Poirier @ 2017-05-08 19:46 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Kernel Network Developers
In-Reply-To: <CALx6S34r6Q_wCKqzv5YjKJyuETyYmY1y=M7uDYiLfpnXzqbheg@mail.gmail.com>
On 2017/05/04 22:50, Tom Herbert wrote:
> Hi,
>
> I am thinking about the possibility of using SSE in kernel for
> speeding up the kernel memcpy particularly for copy to userspace
> emeory, and maybe even using the string instructions (like if we
> supported regex in something like eBPF). AFAIK we don't use SSE in
> kernel because of xmm register state needing to be saved across
> context switch. However, if we start busy-polling a CPU in kernel on
> network queues then there might not be any context switches to worry
> about. In this model we'd want to enable SSE per CPU.
>
> Has this ever been tried before? Is this at all feasible? :-) Is it
> possible to enable SSE for kernel for just one CPU? (I found CPUID
> will return SSE supported, but don't see how to enable other than
> -msse for compiling).
This reminds me of what you tried in
c6e1a0d12ca7 net: Allow no-cache copy from user on transmit
(v3.0-rc1)
and that I reverted in
cdb3f4a31b64 net: Do not enable tx-nocache-copy by default
(v3.14-rc1)
Sure, it's not exactly the same thing...
^ permalink raw reply
* Re: [PATCH net] ip6_tunnel: remove unreachable ICMP_REDIRECT code
From: David Miller @ 2017-05-08 19:59 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev
In-Reply-To: <1494241863-32549-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Mon, 8 May 2017 19:11:03 +0800
> After call ip6_tnl_err(), the rel_type will be ether ICMPV6_DEST_UNREACH
> or ICMPV6_PKT_TOOBIG. We will never reach ICMP_REDIRECT. So remove it.
>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Your patches here, all seemingly due to "visual inspection", are starting
to really, truly, irritate me.
Half of them are unnecessary, some are completely buggy.
I have to review them and audit them very satrictly as a result, and
this takes up an unnecessarily large amount of my time.
Therefore, I'm basically going to stop looking at your changes _unless_
you can show that you specifically tested and exercised all of the code
paths you are changing.
I am sorry to have to do this, but the value to effort ratio of
reviewing and integrating your changes is quite poor.
^ permalink raw reply
* Re: [PATCH V2 1/1] net: cdc_ncm: Fix TX zero padding
From: David Miller @ 2017-05-08 20:01 UTC (permalink / raw)
To: jim_baxter; +Cc: linux-usb, netdev, linux-kernel, oliver
In-Reply-To: <1494247797-1732-2-git-send-email-jim_baxter@mentor.com>
From: Jim Baxter <jim_baxter@mentor.com>
Date: Mon, 8 May 2017 13:49:57 +0100
> The zero padding that is added to NTB's does
> not zero the memory correctly.
> This is because the skb_put modifies the value
> of skb_out->len which results in the memset
> command not setting any memory to zero as
> (ctx->tx_max - skb_out->len) == 0.
>
> I have resolved this by storing the size of
> the memory to be zeroed before the skb_put
> and using this in the memset call.
>
> Signed-off-by: Jim Baxter <jim_baxter@mentor.com>
> Reviewed-by: Bjørn Mork <bjorn@mork.no>
Applied, thank you.
^ 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