* Re: [PATCH] decnet: fix DN_IFREQ_SIZE
From: David Miller @ 2019-01-28 7:13 UTC (permalink / raw)
To: johannes; +Cc: netdev, viro, linux-decnet-user, johannes.berg
In-Reply-To: <20190126201219.14934-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Sat, 26 Jan 2019 21:12:19 +0100
> From: Johannes Berg <johannes.berg@intel.com>
>
> Digging through the ioctls with Al because of the previous
> patches, we found that on 64-bit decnet's dn_dev_ioctl()
> is wrong, because struct ifreq::ifr_ifru is actually 24
> bytes (not 16 as expected from struct sockaddr) due to the
> ifru_map and ifru_settings members.
>
> Clearly, decnet expects the ioctl to be called with a struct
> like
> struct ifreq_dn {
> char ifr_name[IFNAMSIZ];
> struct sockaddr_dn ifr_addr;
> };
>
> since it does
> struct ifreq *ifr = ...;
> struct sockaddr_dn *sdn = (struct sockaddr_dn *)&ifr->ifr_addr;
>
> This means that DN_IFREQ_SIZE is too big for what it wants on
> 64-bit, as it is
> sizeof(struct ifreq) - sizeof(struct sockaddr) +
> sizeof(struct sockaddr_dn)
>
> This assumes that sizeof(struct sockaddr) is the size of ifr_ifru
> but that isn't true.
>
> Fix this to use offsetof(struct ifreq, ifr_ifru).
>
> This indeed doesn't really matter much - the result is that we
> copy in/out 8 bytes more than we should on 64-bit platforms. In
> case the "struct ifreq_dn" lands just on the end of a page though
> it might lead to faults.
>
> As far as I can tell, it has been like this forever, so it seems
> very likely that nobody cares.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ip6mr: Fix notifiers call on mroute_clean_tables()
From: David Miller @ 2019-01-28 7:17 UTC (permalink / raw)
To: nird; +Cc: netdev, nikolay, mlxsw
In-Reply-To: <20190127072622.24835-1-nird@mellanox.com>
From: Nir Dotan <nird@mellanox.com>
Date: Sun, 27 Jan 2019 09:26:22 +0200
> When the MC route socket is closed, mroute_clean_tables() is called to
> cleanup existing routes. Mistakenly notifiers call was put on the cleanup
> of the unresolved MC route entries cache.
> In a case where the MC socket closes before an unresolved route expires,
> the notifier call leads to a crash, caused by the driver trying to
> increment a non initialized refcount_t object [1] and then when handling
> is done, to decrement it [2]. This was detected by a test recently added in
> commit 6d4efada3b82 ("selftests: forwarding: Add multicast routing test").
>
> Fix that by putting notifiers call on the resolved entries traversal,
> instead of on the unresolved entries traversal.
...
> Fixes: 088aa3eec2ce ("ip6mr: Support fib notifications")
> Signed-off-by: Nir Dotan <nird@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] net: dsa: mv88e6xxx: Fix serdes irq setup going recursive
From: David Miller @ 2019-01-28 7:20 UTC (permalink / raw)
To: andrew; +Cc: vivien.didelot, netdev
In-Reply-To: <20190127214800.4202-1-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 27 Jan 2019 22:48:00 +0100
> Duec to a typo, mv88e6390_serdes_irq_setup() calls itself, rather than
> mv88e6390x_serdes_irq_setup(). It then blows the stack, and shortly
> after the machine blows up.
>
> Fixes: 2defda1f4b91 ("net: dsa: mv88e6xxx: Add support for SERDES on ports 2-8 for 6390X")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied, thanks Andrew.
^ permalink raw reply
* Re: WoL broken in r8169.c since kernel 4.19
From: Marc Haber @ 2019-01-28 7:30 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev@vger.kernel.org
In-Reply-To: <64b22f62-ca8a-caee-5a39-f06ffe6598d1@gmail.com>
On Sun, Jan 27, 2019 at 10:09:51PM +0100, Heiner Kallweit wrote:
> Yes. All you have to do after each "git bisect good/bad" is build again,
> test, and make current build as good or bad.
Will report back if I get any results. When I bisected last time, I
ended up with a kernel that didn't even boot, but with 5 steps this is
probably manageable. Will take most of the week though.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* Re: [PATCH net-next] remove TWKilled counter
From: peng yu @ 2019-01-28 7:35 UTC (permalink / raw)
To: David Miller, Linux Kernel Network Developers, Cong Wang
Cc: Alexey Kuznetsov, Hideaki YOSHIFUJI
In-Reply-To: <CAM_iQpU5x=g+VQ7WODWskv2V184rdvxL_4WKzpwf7po_QK7m7w@mail.gmail.com>
Hi, David and Cong
I don't quite understand where this patch to go. This patch wants to
delete the LINUX_MIB_TIMEWAITKILLED counter. Moving snmp.h out of the
uapi directory is a difference thing. Do we really need to do it?
On Tue, Jan 22, 2019 at 10:58 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> On Mon, Jan 21, 2019 at 3:14 PM peng yu <yupeng0921@gmail.com> wrote:
> >
> > Hello, I think the snmp.h didn't try to keep user-space compatibility,
> > so we could delete LINUX_MIB_TIMEWAITKILLED counter. Do I
> > misunderstand anything?
>
> I don't know. Maybe user-space doesn't need these definitions at all,
> as like nstat can figure out the values from /proc/net/netstat. It looks
> like we either could just kill snmp.h or we have to keep it for backward
> compatibility.
^ permalink raw reply
* Re: [PATCH] PCI / ACPI: Don't clear pme_poll on device that has unreliable ACPI wake
From: Kai Heng Feng @ 2019-01-28 7:51 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Rafael J. Wysocki, Len Brown, jeffrey.t.kirsher, intel-wired-lan,
netdev, linux-acpi, linux-pci, linux-kernel
In-Reply-To: <20190124200508.GH14636@google.com>
> On Jan 25, 2019, at 4:05 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Thu, Jan 24, 2019 at 11:29:37PM +0800, Kai Heng Feng wrote:
>>> On Jan 24, 2019, at 11:15 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>>> On Wed, Jan 23, 2019 at 03:17:37PM +0800, Kai Heng Feng wrote:
>>>>> On Jan 23, 2019, at 7:51 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>>>>> On Tue, Jan 22, 2019 at 02:45:44PM +0800, Kai-Heng Feng wrote:
>>>>>> There are some e1000e devices can only be woken up from D3 one time, by
>>>>>> plugging ethernet cable. Subsequent cable plugging does set PME bit
>>>>>> correctly, but it still doesn't get woken up.
>>>>>>
>>>>>> Since e1000e connects to the root complex directly, we rely on ACPI to
>>>>>> wake it up. In this case, the GPE from _PRW only works once and stops
>>>>>> working after that.
>>>>>>
>>>>>> So introduce a new PCI quirk, to avoid clearing pme_poll flag for buggy
>>>>>> platform firmwares that have unreliable GPE wake.
>>>>>
>>>>> This quirk applies to all 0x15bb (E1000_DEV_ID_PCH_CNP_I219_LM7) and
>>>>> 0x15bd (E1000_DEV_ID_PCH_CNP_I219_LM6) devices. The e1000e driver
>>>>> claims about a zillion different device IDs.
>>>>>
>>>>> I would be surprised if these two devices are defective but all the
>>>>> others work correctly. Could it be that there is a problem with the
>>>>> wiring on this particular motherboard or with the ACPI _PRW methods
>>>>> (or the way Linux interprets them) in this firmware?
>>>>
>>>> If this is a motherboard issue or platform specific, do you prefer to use
>>>> DMI matches here?
>>>
>>> I'm not sure what the problem is yet, so let's hold off on the exact
>>> structure of the fix.
>>
>> I think DMI table can put in e1000e driver instead of PCI quirk.
>
> I don't think we should add a quirk or DMI table yet because we
> haven't gotten to the root cause of this problem. If the root cause
> is a problem in the Linux code, adding a quirk will mask the problem
> for this specific system, but will leave other systems with similar
> problems.
>
>>> If I understand correctly, e1000e wakeup works once, but doesn't work
>>> after that. Your lspci (from after that first wakeup, from
>>> https://bugzilla.kernel.org/attachment.cgi?id=280691) shows this:
>>>
>>> 00:14.0 XHC XHCI USB
>>> Flags: PMEClk- DSI- D1- D2- ... PME(D0-,D1-,D2-,D3hot+,D3cold+)
>>> Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
>>> 00:1f.3 HDAS audio
>>> Flags: PMEClk- DSI- D1- D2- ... PME(D0-,D1-,D2-,D3hot+,D3cold+)
>>> Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
>>> 00:1f.6 GLAN e1000e
>>> Flags: PMEClk- DSI+ D1- D2- ... PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>> Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=1 PME+
>>>
>>> So the e1000e PME_Status bit is still set, which means it probably
>>> won't generate another PME interrupt, which would explain why wakeup
>>> doesn't work. To test this theory, can you try this:
>>>
>>> - sleep
>>> - wakeup via e1000e
>>> # DEV=00:1f.6
>>> # lspci -vvs $DEV
>>> # setpci -s $DEV CAP_PM+4.W
>>> # setpci -s $DEV CAP_PM+4.W=0x8100
>>> - sleep
>>> - attempt another wakeup via e1000e
>>>
>>> If this second wakeup works, it would suggest that PME_Status isn't
>>> being cleared correctly. I see code, e.g., in
>>> acpi_setup_gpe_for_wake(), that *looks* like it would arrange to clear
>>> it, but I'm not very familiar with it. Maybe there's some issue with
>>> multiple devices sharing an "implicit notification" situation like
>>> this.
>>
>> The PME status is being cleared correctly.
>
> I was hoping to understand this better via the experiment above, but
> I'm still confused. Here's the scenario as I understand it:
>
> 0) fresh boot
> 1) e1000e PME_Status should be 0
> 2) sleep
> 3) wakeup via e1000e succeeds
> 4) e1000e PME_Status should be 0
> 5) sleep
> 6) wakeup via e1000e fails
> 7) wakeup via USB succeeds
> 8) e1000e PME_Status should be 0, but is actually 1
Sorry for not illustrating the scenario more clearly, here’s the test scenario:
0) fresh boot
1) no ethernet cable plugged
2) e1000e runtime suspend
3) PME_Status is 0
4) plug ethernet cable
5) e1000e gets woken up by ACPI wakeup
6) network connection established
6) unplug the ethernet cable
7) e1000e runtime suspend
8) plug ethernet cable again
9) PME_Status=1 but it’s not woken up, stays suspended
10) Plug a USB device, e1000e wakes up.
This shows somehow the ACPI GPE still works for USB controller but not ethernet device.
>
> If I understand correctly, the bugzilla lspci
> (https://bugzilla.kernel.org/attachment.cgi?id=280691) was collected
> at point 8, and it shows PME_Status=1 when it should be 0.
>
> If we write a 1 to PME_Status to clear it, and it remains set, that's
> obviously a hardware defect, and Intel should document that in an
> erratum, and a quirk would be the appropriate way to work around it.
> But I doubt that's what's happening.
I’ll ask them if they can provide an erratum.
>
> If e1000e changes PME_Status from 0 to 1 and we don't get an interrupt
> (in this case, an SCI triggering GPE 0x6d), the problem is something
> in the path outside e1000e. Since the wakeup works the first time, we
> know e1000e is *capable* of generating an interrupt, and the problem
> is probably something in the way we acknowledge it.
>
> I want to make sure we're executing the code that clears
> PCI_PM_CTRL_PME_STATUS. Would you mind applying the patch below,
> turning on CONFIG_ACPI_DEBUG, booting with
>
> acpi.debug_layer=0x00000004 acpi.debug_level=0x00000004
>
> and collecting the dmesg log? I think you can also set these debug
> flags via /sys/module/acpi/parameters/debug_* if that's easier.
Dmesg with the debug patch applied:
https://bugzilla.kernel.org/attachment.cgi?id=280819
At the end, I re-plugged the ethernet cable, nothing shows.
Kai-Heng
>
>> The lspci is captured after I plugged the ethernet cable second time,
>> i.e. PME is set but not being woken up.
>>
>> Kai-Heng
>
> Bjorn
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index c9d8e3c837de..91a70ffdd3a1 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1927,7 +1927,7 @@ void pcie_clear_root_pme_status(struct pci_dev *dev)
> bool pci_check_pme_status(struct pci_dev *dev)
> {
> int pmcsr_pos;
> - u16 pmcsr;
> + u16 pmcsr, pmcsr_orig;
> bool ret = false;
>
> if (!dev->pm_cap)
> @@ -1939,6 +1939,7 @@ bool pci_check_pme_status(struct pci_dev *dev)
> return false;
>
> /* Clear PME status. */
> + pmcsr_orig = pmcsr;
> pmcsr |= PCI_PM_CTRL_PME_STATUS;
> if (pmcsr & PCI_PM_CTRL_PME_ENABLE) {
> /* Disable PME to avoid interrupt flood. */
> @@ -1948,6 +1949,9 @@ bool pci_check_pme_status(struct pci_dev *dev)
>
> pci_write_config_word(dev, pmcsr_pos, pmcsr);
>
> + pci_read_config_word(dev, pmcsr_pos, &pmcsr);
> + pci_info(dev, "%s PM_CTRL %#06x -> %#06x\n", __func__, pmcsr_orig, pmcsr);
> +
> return ret;
> }
>
> @@ -2027,18 +2031,22 @@ static void pci_pme_list_scan(struct work_struct *work)
>
> static void __pci_pme_active(struct pci_dev *dev, bool enable)
> {
> - u16 pmcsr;
> + u16 pmcsr, pmcsr_orig;
>
> if (!dev->pme_support)
> return;
>
> pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
> + pmcsr_orig = pmcsr;
> /* Clear PME_Status by writing 1 to it and enable PME# */
> pmcsr |= PCI_PM_CTRL_PME_STATUS | PCI_PM_CTRL_PME_ENABLE;
> if (!enable)
> pmcsr &= ~PCI_PM_CTRL_PME_ENABLE;
>
> pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pmcsr);
> +
> + pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
> + pci_info(dev, "%s PM_CTRL %#06x -> %#06x\n", __func__, pmcsr_orig, pmcsr);
> }
>
> /**
^ permalink raw reply
* Re: [PATCH RFC 0/3] Support fraglist GRO/GSO
From: Steffen Klassert @ 2019-01-28 7:51 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Network Development, Willem de Bruijn, Paolo Abeni,
Jason A. Donenfeld
In-Reply-To: <CAF=yD-LvhJECOsbgWUvo_-H9dgDmjyNSWBoEkfo9P=wudU68DQ@mail.gmail.com>
On Fri, Jan 25, 2019 at 08:57:00AM -0500, Willem de Bruijn wrote:
> On Fri, Jan 25, 2019 at 3:14 AM Steffen Klassert
> <steffen.klassert@secunet.com> wrote:
> >
> > On Mon, Jan 14, 2019 at 12:09:22PM -0500, Willem de Bruijn wrote:
> > > On Mon, Jan 14, 2019 at 7:50 AM Steffen Klassert
> > > <steffen.klassert@secunet.com> wrote:
> > > > On Sun, Dec 23, 2018 at 08:15:40PM -0500, Willem de Bruijn wrote:
> > >
> > > I don't think that the route lookup is needed. If listified is cheaper
> > > for local delivery, too, then we can make that the default unless a
> > > device is active with h/w offload and ip forwarding is enabled. If it
> > > isn't, then use it iff ip forwarding is enabled. I think it's fine to
> > > mispredict between the two in edge cases with netfilter mangling, as
> > > long as all paths can correctly handle both types of GRO packets.
> >
> > I'd need at least a route lookup for my usecase, because listified
> > GRO is always cheaper when a xfrm transformation is needed (even for
> > TCP). In this case is software GSO needed. So I'd need to either have
> > an early route lookup or maybe some early ingress hook where a route
> > lookup could be imlemented in.
>
> Could you use a similar system wide approach as what we discussed
> previous wrt hardware offload? Use listified only if (forwarding is enabled
> and no device is registered that implements h/w segmentation offload) or
> any path requires xfrm transformation (?).
The xfrm transformation has to happen for the segments. So if we need to
do xfrm transformation in software, we need to do segmentation in
software too. I think that just forwarding is enabled and the presence
of a device that can do hardware segmentation offload is not a good
indicator. The more devices support hardware segmentation offload
the more likely is it that xfrm take a suboptimal path.
We have to do a route lookup anyway, why not just do it early
in case forwarding is enabled?
^ permalink raw reply
* TCP/IPv4 sending using MSG_ZEROCOPY and closing the socket
From: mathias_koehrer @ 2019-01-28 7:44 UTC (permalink / raw)
To: netdev, willemb
Hi all,
I have one question on the behavior of TCP/IPv4 sending using the MSG_ZEROCOPY flag,
the kernel version is 4.19.18.
What happens if I close the sending socket immediately after performing a socket
send() or sendmsg() call (called with the MSG_ZEROCOPY flag)?
I.e. in this situation not all messages have been sent yet, however - as the
socket is closed - it is no longer possible to retrieve the completion
notification via the error channel.
Is it fine for the user space program to free all outstanding messages after the
socket close() has returned?
Or is there anything else that has to be considered?
Thanks for any help
Best regards
Mathias
^ permalink raw reply
* Re: [PATCH iproute2-next] Introduce ip-brctl shell script
From: Stefano Brivio @ 2019-01-28 7:57 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Nikolay Aleksandrov, David Ahern, Phil Sutter, Eric Garver,
Tomas Dolezal, Stephen Hemminger, Lennert Buytenhek, netdev
In-Reply-To: <CAJieiUj9q-YsyKv3SOHKkfipCJyeZtxMFY7KFE+dBgih10s-6A@mail.gmail.com>
On Sun, 27 Jan 2019 21:08:13 -0800
Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On Fri, Jan 25, 2019 at 2:05 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> >
> > Hi Roopa,
> >
> > On Wed, 23 Jan 2019 08:33:27 -0800
> > Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> >
> > > On Wed, Jan 23, 2019 at 7:09 AM Nikolay Aleksandrov
> > > <nikolay@cumulusnetworks.com> wrote:
> > >
> > > > Hi,
> > > > IMO the effort should be towards improving iproute2 to be
> > > > easier to use and more intuitive. We should be pushing people to
> > > > use the new tools instead of trying to find workarounds to keep the
> > > > old tools alive. I do like to idea of deprecating bridge-utils, but
> > > > I think it should be done via improving ip/bridge enough to be
> > > > pleasant to use. We will have to maintain this compatibility layer
> > > > forever if it gets accepted and we'll never get rid of brctl this
> > > > way.
> > >
> > > +1, we should move people away from brtcl. there is enough confusion
> > > among users looking at bridge attributes.,
> > >
> > > ip -d link show
> > > bridge -d link show
> > > brctl
> >
> > Why is this confusing? One can simply pick the most appropriate tool.
> >
> > > Adding a 4th one to the list is not going to ease the confusion.
> >
> > Why do you say I'm adding a fourth (I guess) tool? I'm replacing the
> > third one.
>
> I know. But the first two commands were supposed to replace the third
> one already.
> and they should be.
They can't replace brctl not because they are badly designed or
unusable, but simply because they are different tools with different
purposes (see also my comments to Nikolay).
> So, I think its better to fix the first two instead of introducing
> another one.
This is really not the same thing: I'm not introducing a new tool, I'm
effectively replacing a 1794-LoC, non-trivial, ioctl-based
implementation with a trivial, 572-lines shell script, with half
the binary size.
I'm not doing this on bridge-utils directly because that would imply
the need to still maintain a different tool. For all practical
maintenance purposes, I'm actually getting rid of a separate tool,
which is my only goal here.
I'd rather say we go from 3 tools to slightly more than 2.
> > > We should try to make the 'ip -d link show and bridge -d link show'
> > > outputs better. Any suggestions there from people will be useful.
> >
> > To be honest, I don't see any problem with them -- they just do
> > different things.
>
> Can we extend 'bridge' tool with extra options to provide a summary
> view of all bridges like brctl ?
We could, and I initially thought of that approach instead, but that
has a number of fundamental downsides:
- we can't provide a brctl-compatible syntax, unless we want to
substantially rewrite the 'bridge' interface, and I think it's a
bad idea to break 'bridge' syntax for users, while we won't be able to
replace brctl if we don't provide a similar syntax, history showed
- the fdb implementation has a long-dated comment by Stephen in its
header,
* TODO: merge/replace this with ip neighbour
and this is actually the only part of 'bridge' I'm using in ip-brctl.
Code is conceptually duplicated there, and I think we should actually
get rid of that -- but then 'bridge' wouldn't even give information
about the FDB, one would need to use ip neighbour instead.
- 'bridge' doesn't implement settings for basic bridge features (say,
STP), which are convenient for users, especially if they are used to
brctl. To get that, even at an interface/syntax level, we would need
to duplicate some parts of ip-link, which looks like a bad idea per
se.
> Its supposed to be the netlink based tool for all bridging and hence
> could be a good replacement for all brctl users.
I still think the best replacement for users is the one that changes
absolutely nothing, and if that's easily achievable, I'd rather go for
it.
--
Stefano
^ permalink raw reply
* Re: [PATCH RFC 3/3] udp: Support UDP fraglist GRO/GSO.
From: Steffen Klassert @ 2019-01-28 8:09 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev, Willem de Bruijn, Jason A. Donenfeld
In-Reply-To: <33fac48cd79c98b1da7af20f04c5acef9b740ce3.camel@redhat.com>
On Sat, Jan 26, 2019 at 10:36:40AM +0100, Paolo Abeni wrote:
> On Fri, 2019-01-25 at 08:58 +0100, Steffen Klassert wrote:
> > Do you have some performance tests for UDP GRO receive?
>
> I have a bunch of ansible(!!!) scripts I can share, if you dare. They
> have a lot of hard-coded setting, so I'm not sure how much can be re-
> used outside my testbed.
>
> I also hope/wish/think/ I can allocate some time for benchmarking this
> on my own in the next week[s], so I'll try to post some results for the
> next iteration.
That would be great, thanks!
^ permalink raw reply
* Re: [PATCH] net: wireless: prefix header search paths with $(srctree)/
From: Kalle Valo @ 2019-01-28 8:21 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-wireless, brcm80211-dev-list.pdl, Franky Lin,
Intel Linux Wireless, Luca Coelho, Johannes Berg, netdev,
Emmanuel Grumbach, Chi-Hsien Lin, Hin-Tak Leung, Larry Finger,
Herton Ronaldo Krzesinski, Hante Meuleman, Wright Feng,
Arend van Spriel, brcm80211-dev-list, linux-kernel,
David S. Miller
In-Reply-To: <1548429480-22137-1-git-send-email-yamada.masahiro@socionext.com>
Masahiro Yamada <yamada.masahiro@socionext.com> writes:
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> that way, but not all. The goal of this work is to make the notation
> consistent, and finally get rid of the gross hacks.
>
> Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> ("kbuild: do not drop -I without parameter").
>
> I also removed one header search path in:
>
> drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile
>
> I was able to compile without it.
>
> [1]: https://patchwork.kernel.org/patch/9632347/
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 4 ++--
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 6 +++---
> drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile | 4 +---
> drivers/net/wireless/intel/iwlwifi/dvm/Makefile | 2 +-
> drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 2 +-
> drivers/net/wireless/realtek/rtl818x/rtl8180/Makefile | 2 +-
> drivers/net/wireless/realtek/rtl818x/rtl8187/Makefile | 2 +-
> 7 files changed, 10 insertions(+), 12 deletions(-)
Luca, is it ok if I take this to wireless-drivers-next even though it
touches iwlwifi makefiles?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Peter Zijlstra @ 2019-01-28 8:24 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, davem, daniel, jakub.kicinski, netdev,
kernel-team, mingo, will.deacon, Paul McKenney, jannh
In-Reply-To: <20190125234241.soomtkrgp2i7m7ul@ast-mbp.dhcp.thefacebook.com>
On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
> > Do we want something like (the completely untested) below to avoid
> > having to manually audit this over and over?
> >
> > ---
> > include/linux/filter.h | 2 +-
> > include/linux/kernel.h | 9 +++++++--
> > kernel/sched/core.c | 28 ++++++++++++++++++++++++++++
> > 3 files changed, 36 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/filter.h b/include/linux/filter.h
> > index d531d4250bff..4ab51e78da36 100644
> > --- a/include/linux/filter.h
> > +++ b/include/linux/filter.h
> > @@ -513,7 +513,7 @@ struct sk_filter {
> > struct bpf_prog *prog;
> > };
> >
> > -#define BPF_PROG_RUN(filter, ctx) (*(filter)->bpf_func)(ctx, (filter)->insnsi)
> > +#define BPF_PROG_RUN(filter, ctx) ({ cant_sleep(); (*(filter)->bpf_func)(ctx, (filter)->insnsi); })
>
> That looks reasonable and I intent to apply this patch to bpf-next after testing.
> Can you pls reply with a sob ?
Sure; with the caveat that I didn't even hold it near a compiler, and it
probably should grow a comment to explain the interface (similar to
might_sleep):
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> The easiest fix is to add preempt_disable/enable for socket filters.
> There is a concern that such fix will make classic bpf non-preemptable
> and classic bpf can be quite cpu expensive.
> Also on the receive side classic runs in bh, so 4k flow_dissector calls
> in classic has to be dealt with anyway.
Right and agreed; per that argument the worst case (legacy) BPF was
already present under non-preempt and thus making it consistently so
should not affect the worst case.
^ permalink raw reply
* Re: [PATCH] net: wireless: prefix header search paths with $(srctree)/
From: Luca Coelho @ 2019-01-28 8:26 UTC (permalink / raw)
To: Kalle Valo, Masahiro Yamada
Cc: linux-wireless, brcm80211-dev-list.pdl, Franky Lin,
Intel Linux Wireless, Johannes Berg, netdev, Emmanuel Grumbach,
Chi-Hsien Lin, Hin-Tak Leung, Larry Finger,
Herton Ronaldo Krzesinski, Hante Meuleman, Wright Feng,
Arend van Spriel, brcm80211-dev-list, linux-kernel,
David S. Miller
In-Reply-To: <8736pd2nw4.fsf@codeaurora.org>
On Mon, 2019-01-28 at 10:21 +0200, Kalle Valo wrote:
> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
>
> > Currently, the Kbuild core manipulates header search paths in a
> > crazy
> > way [1].
> >
> > To fix this mess, I want all Makefiles to add explicit $(srctree)/
> > to
> > the search paths in the srctree. Some Makefiles are already written
> > in
> > that way, but not all. The goal of this work is to make the
> > notation
> > consistent, and finally get rid of the gross hacks.
> >
> > Having whitespaces after -I does not matter since commit
> > 48f6e3cf5bc6
> > ("kbuild: do not drop -I without parameter").
> >
> > I also removed one header search path in:
> >
> > drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile
> >
> > I was able to compile without it.
> >
> > [1]: https://patchwork.kernel.org/patch/9632347/
> >
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > ---
> >
> > drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 4 ++--
> > drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 6 +++-
> > --
> > drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile | 4 +---
> > drivers/net/wireless/intel/iwlwifi/dvm/Makefile | 2 +-
> > drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 2 +-
> > drivers/net/wireless/realtek/rtl818x/rtl8180/Makefile | 2 +-
> > drivers/net/wireless/realtek/rtl818x/rtl8187/Makefile | 2 +-
> > 7 files changed, 10 insertions(+), 12 deletions(-)
>
> Luca, is it ok if I take this to wireless-drivers-next even though it
> touches iwlwifi makefiles?
Sure, it's much easier like that.
Acked-by: Luca Coelho <luciano.coelho@intel.com>
--
Cheers,
Luca.
^ permalink raw reply
* Re: KASAN: use-after-free Read in br_mdb_ip_get
From: Dmitry Vyukov @ 2019-01-28 8:28 UTC (permalink / raw)
To: Nikolay Aleksandrov, Thomas Graf, Herbert Xu
Cc: syzbot, bridge, David Miller, LKML, netdev, Roopa Prabhu,
syzkaller-bugs
In-Reply-To: <3c44c1ff-2790-ec06-35c6-3572b92170c7@cumulusnetworks.com>
On Sun, Jan 27, 2019 at 10:34 PM Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
>
> On 27/01/2019 22:26, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: ba6069759381 Merge tag 'mmc-v5.0-rc2' of git://git.kernel...
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=17b342c4c00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68
> > dashboard link: https://syzkaller.appspot.com/bug?extid=bc5ab0af2dbf3b0ae897
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >
> >Unfortunately,I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+bc5ab0af2dbf3b0ae897@syzkaller.appspotmail.com
> >
> > bridge0: port 2(bridge_slave_1) entered blocking state
> > bridge0: port 2(bridge_slave_1) entered forwarding state
> > bridge0: port 1(bridge_slave_0) entered blocking state
> > bridge0: port 1(bridge_slave_0) entered forwarding state
> > ==================================================================
> > BUG: KASAN: use-after-free in memcmp+0xb3/0xc0 lib/string.c:862
> > Read of size 1 at addr ffff88809f1efe70 by task syz-executor1/8111
> >
> [snip]
> >
> >Allocated by task 8111:
> > save_stack+0x45/0xd0 mm/kasan/common.c:73
> > set_track mm/kasan/common.c:85 [inline]
> > __kasan_kmalloc mm/kasan/common.c:496 [inline]
> > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
> > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504
> > kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3609
> > kmalloc include/linux/slab.h:545 [inline]
> > kzalloc include/linux/slab.h:740 [inline]
> > br_multicast_new_group.part.0+0xdc/0x1a40 net/bridge/br_multicast.c:476
> > br_multicast_new_group+0x19d/0x200 net/bridge/br_multicast.c:471
> > br_multicast_add_group+0x4ce/0x7d0 net/bridge/br_multicast.c:552
> >br_ip6_multicast_add_group net/bridge/br_multicast.c:626 [inline]
> > br_ip6_multicast_mld2_report net/bridge/br_multicast.c:1043 [inline]
> > br_multicast_ipv6_rcv net/bridge/br_multicast.c:1667 [inline]
> > br_multicast_rcv+0x24aa/0x4270 net/bridge/br_multicast.c:1705
> > br_dev_xmit+0x7f4/0x1780 net/bridge/br_device.c:93
> > __netdev_start_xmit include/linux/netdevice.h:4382 [inline]
> > netdev_start_xmit include/linux/netdevice.h:4391 [inline]
> > xmit_one net/core/dev.c:3278 [inline]
> > dev_hard_start_xmit+0x261/0xc70 net/core/dev.c:3294
> > __dev_queue_xmit+0x2f8a/0x3a60 net/core/dev.c:3864
> > dev_queue_xmit+0x18/0x20 net/core/dev.c:3897
> > neigh_resolve_output net/core/neighbour.c:1476 [inline]
> > neigh_resolve_output+0x6a0/0xb30 net/core/neighbour.c:1456
> > neigh_output include/net/neighbour.h:508 [inline]
> > ip6_finish_output2+0xc56/0x28e0 net/ipv6/ip6_output.c:120
> > ip6_finish_output+0x577/0xc30 net/ipv6/ip6_output.c:154
> > NF_HOOK_COND include/linux/netfilter.h:278 [inline]
> > ip6_output+0x23c/0xa00 net/ipv6/ip6_output.c:171
> > dst_output include/net/dst.h:444 [inline]
> > NF_HOOK include/linux/netfilter.h:289 [inline]
> > NF_HOOK include/linux/netfilter.h:283 [inline]
> > mld_sendpack+0xa44/0xfd0 net/ipv6/mcast.c:1683
> > mld_send_cr net/ipv6/mcast.c:1979 [inline]
> > mld_ifc_timer_expire+0x449/0x8a0 net/ipv6/mcast.c:2478
> > call_timer_fn+0x254/0x900 kernel/time/timer.c:1325
> > expire_timers kernel/time/timer.c:1362 [inline]
> > __run_timers+0x6fc/0xd50 kernel/time/timer.c:1681
> > run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1694
> > __do_softirq+0x30b/0xb11 kernel/softirq.c:292
> >
> > Freed by task 8111:
> > save_stack+0x45/0xd0 mm/kasan/common.c:73
> > set_track mm/kasan/common.c:85 [inline]
> > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
> > kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
> > __cache_free mm/slab.c:3487 [inline]
> > kfree+0xcf/0x230 mm/slab.c:3806
> > br_multicast_new_group.part.0+0x1489/0x1a40 net/bridge/br_multicast.c:486
>
>
> Weird, this is the kfree() on the error path of br_multicast_new_group()
> when rhashtable_lookup_insert_fast() fails, which means the entry should
> not be linked in the rhashtable or the hlist.
> All other frees are via kfree_rcu. I'll keep looking..
Humm.... +rhashtable.c maintianers
The code in br_multicast_new_group is effectively:
mp = kzalloc(sizeof(*mp), GFP_ATOMIC);
err = rhashtable_lookup_insert_fast(&br->mdb_hash_tbl, &mp->rhnode,
br_mdb_rht_params);
if (err)
kfree(mp);
So it looks like rhashtable_lookup_insert_fast both returned an error
and left the new object linked in the table. Since it happened only
once, it may have something to do with concurrent resizing/shrinking.
> > br_multicast_new_group+0x19d/0x200 net/bridge/br_multicast.c:471
> > br_multicast_add_group+0x4ce/0x7d0 net/bridge/br_multicast.c:552
> > br_ip6_multicast_add_group net/bridge/br_multicast.c:626 [inline]
> > br_ip6_multicast_mld2_report net/bridge/br_multicast.c:1043 [inline]
> > br_multicast_ipv6_rcv net/bridge/br_multicast.c:1667 [inline]
> > br_multicast_rcv+0x24aa/0x4270 net/bridge/br_multicast.c:1705
> > br_dev_xmit+0x7f4/0x1780 net/bridge/br_device.c:93
> > __netdev_start_xmit include/linux/netdevice.h:4382 [inline]
> > netdev_start_xmit include/linux/netdevice.h:4391 [inline]
> > xmit_one net/core/dev.c:3278 [inline]
> > dev_hard_start_xmit+0x261/0xc70 net/core/dev.c:3294
> > __dev_queue_xmit+0x2f8a/0x3a60 net/core/dev.c:3864
> > dev_queue_xmit+0x18/0x20 net/core/dev.c:3897
> > neigh_resolve_output net/core/neighbour.c:1476 [inline]
> > neigh_resolve_output+0x6a0/0xb30 net/core/neighbour.c:1456
> > neigh_output include/net/neighbour.h:508 [inline]
> > ip6_finish_output2+0xc56/0x28e0 net/ipv6/ip6_output.c:120
> > ip6_finish_output+0x577/0xc30 net/ipv6/ip6_output.c:154
> > NF_HOOK_COND include/linux/netfilter.h:278 [inline]
> > ip6_output+0x23c/0xa00 net/ipv6/ip6_output.c:171
> > dst_output include/net/dst.h:444 [inline]
> > NF_HOOK include/linux/netfilter.h:289 [inline]
> > NF_HOOK include/linux/netfilter.h:283 [inline]
> > mld_sendpack+0xa44/0xfd0 net/ipv6/mcast.c:1683
> > mld_send_cr net/ipv6/mcast.c:1979 [inline]
> > mld_ifc_timer_expire+0x449/0x8a0 net/ipv6/mcast.c:2478
> > call_timer_fn+0x254/0x900 kernel/time/timer.c:1325
> > expire_timers kernel/time/timer.c:1362 [inline]
> > __run_timers+0x6fc/0xd50 kernel/time/timer.c:1681
> > run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1694
> > __do_softirq+0x30b/0xb11 kernel/softirq.c:292
> >
> > The buggy address belongs to the object at ffff88809f1efe00
> > which belongs to the cache kmalloc-192 of size 192
> > The buggy address is located 112 bytes inside of
> > 192-byte region [ffff88809f1efe00,ffff88809f1efec0)
> > The buggy address belongs to the page:
> > page:ffffea00027c7bc0 count:1 mapcount:0 mapping:ffff88812c3f0040 index:0x0
> > flags: 0x1fffc0000000200(slab)
> > raw: 01fffc0000000200 ffffea00027df108 ffffea00027c7c48 ffff88812c3f0040
> > raw: 0000000000000000 ffff88809f1ef000 0000000100000010 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff88809f1efd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ffff88809f1efd80: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >> ffff88809f1efe00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ^
> > ffff88809f1efe80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> > ffff88809f1eff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ==================================================================
> >
> >
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> >syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
>
> --
>You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/3c44c1ff-2790-ec06-35c6-3572b92170c7%40cumulusnetworks.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Peter Zijlstra @ 2019-01-28 8:31 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, davem, daniel, jakub.kicinski, netdev,
kernel-team, mingo, will.deacon, Paul McKenney, jannh
In-Reply-To: <20190125234241.soomtkrgp2i7m7ul@ast-mbp.dhcp.thefacebook.com>
On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> > > nmi checks for bpf_prog_active==0. See bpf_overflow_handler.
> > yuck yuck yuck.. That's horrific :-( That means the whole BPF crud is
> > unreliable and events can go randomly missing.
>
> bpf_prog_active is the mechanism to workaround non-reentrant pieces of the kernel.
'the kernel' or 'bpf' ?
perf has a recursion counter per context (task,softirq,hardirq,nmi) and
that ensures that perf doesn't recurse in on itself while allowing the
nesting of these contexts.
But if BPF itself is not able to deal with such nesting that won't work
of course.
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Peter Zijlstra @ 2019-01-28 8:35 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, davem, daniel, jakub.kicinski, netdev,
kernel-team, mingo, will.deacon, Paul McKenney, jannh
In-Reply-To: <20190128083123.GB28467@hirez.programming.kicks-ass.net>
On Mon, Jan 28, 2019 at 09:31:23AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote:
> > On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
>
> > > > nmi checks for bpf_prog_active==0. See bpf_overflow_handler.
>
> > > yuck yuck yuck.. That's horrific :-( That means the whole BPF crud is
> > > unreliable and events can go randomly missing.
> >
> > bpf_prog_active is the mechanism to workaround non-reentrant pieces of the kernel.
>
> 'the kernel' or 'bpf' ?
>
> perf has a recursion counter per context (task,softirq,hardirq,nmi) and
> that ensures that perf doesn't recurse in on itself while allowing the
> nesting of these contexts.
>
> But if BPF itself is not able to deal with such nesting that won't work
> of course.
Ooh, later you say:
> Also we allow tracing progs to nest with networking progs.
Which seems to suggest BPF itself can suppord (limited) nesting.
See: kernel/events/internal.h:get_recursion_context()
^ permalink raw reply
* Re: [PATCH net] net: dsa: mv88e6xxx: Fix serdes irq setup going recursive
From: Sergei Shtylyov @ 2019-01-28 8:37 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: Vivien Didelot, netdev
In-Reply-To: <20190127214800.4202-1-andrew@lunn.ch>
Hello!
On 28.01.2019 0:48, Andrew Lunn wrote:
> Duec to a typo, mv88e6390_serdes_irq_setup() calls itself, rather than
Due?
> mv88e6390x_serdes_irq_setup(). It then blows the stack, and shortly
> after the machine blows up.
Never seen a stack overflow in the kernel... :-)
> Fixes: 2defda1f4b91 ("net: dsa: mv88e6xxx: Add support for SERDES on ports 2-8 for 6390X")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Peter Zijlstra @ 2019-01-28 8:43 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, davem, daniel, jakub.kicinski, netdev,
kernel-team, mingo, will.deacon, Paul McKenney, jannh
In-Reply-To: <20190125234241.soomtkrgp2i7m7ul@ast-mbp.dhcp.thefacebook.com>
On Fri, Jan 25, 2019 at 03:42:43PM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 25, 2019 at 10:10:57AM +0100, Peter Zijlstra wrote:
> > What about the progs that run from SoftIRQ ? Since that bpf_prog_active
> > thing isn't inside BPF_PROG_RUN() what is to stop say:
> >
> > reuseport_select_sock()
> > ...
> > BPF_PROG_RUN()
> > bpf_spin_lock()
> > <IRQ>
> > ...
> > BPF_PROG_RUN()
> > bpf_spin_lock() // forever more
> >
> > </IRQ>
> >
> > Unless you stick that bpf_prog_active stuff inside BPF_PROG_RUN itself,
> > I don't see how you can fundamentally avoid this happening (now or in
> > the future).
> But your issue above is valid.
> We don't use bpf_prog_active for networking progs, since we allow
> for one level of nesting due to the classic SKF_AD_PAY_OFFSET legacy.
> Also we allow tracing progs to nest with networking progs.
> People using this actively.
> Typically it's not an issue, since in networking there is no
> arbitrary nesting (unlike kprobe/nmi in tracing),
> but for bpf_spin_lock it can be, since the same map can be shared
> by networking and tracing progs and above deadlock would be possible:
> (first BPF_PROG_RUN will be from networking prog, then kprobe+bpf's
> BPF_PROG_RUN accessing the same map with bpf_spin_lock)
>
> So for now I'm going to allow bpf_spin_lock in networking progs only,
> since there is no arbitrary nesting there.
Isn't that still broken? AFAIU networking progs can happen in task
context (TX) and SoftIRQ context (RX), which can nest.
> And once we figure out the safety concerns for kprobe/tracepoint progs
> we can enable bpf_spin_lock there too.
> NMI bpf progs will never have bpf_spin_lock.
kprobe is like NMI, since it pokes an INT3 instruction which can trigger
in the middle of IRQ-disabled or even in NMIs. Similar arguments can be
made for tracepoints, they can happen 'anywhere'.
^ permalink raw reply
* [PATCH] esp: Skip TX bytes accounting when sending from a request socket
From: Martin Willi @ 2019-01-28 8:35 UTC (permalink / raw)
To: Steffen Klassert; +Cc: netdev
On ESP output, sk_wmem_alloc is incremented for the added padding if a
socket is associated to the skb. When replying with TCP SYNACKs over
IPsec, the associated sk is a casted request socket, only. Increasing
sk_wmem_alloc on a request socket results in a write at an arbitrary
struct offset. In the best case, this produces the following WARNING:
WARNING: CPU: 1 PID: 0 at lib/refcount.c:102 esp_output_head+0x2e4/0x308 [esp4]
refcount_t: addition on 0; use-after-free.
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.0.0-rc3 #2
Hardware name: Marvell Armada 380/385 (Device Tree)
[...]
[<bf0ff354>] (esp_output_head [esp4]) from [<bf1006a4>] (esp_output+0xb8/0x180 [esp4])
[<bf1006a4>] (esp_output [esp4]) from [<c05dee64>] (xfrm_output_resume+0x558/0x664)
[<c05dee64>] (xfrm_output_resume) from [<c05d07b0>] (xfrm4_output+0x44/0xc4)
[<c05d07b0>] (xfrm4_output) from [<c05956bc>] (tcp_v4_send_synack+0xa8/0xe8)
[<c05956bc>] (tcp_v4_send_synack) from [<c0586ad8>] (tcp_conn_request+0x7f4/0x948)
[<c0586ad8>] (tcp_conn_request) from [<c058c404>] (tcp_rcv_state_process+0x2a0/0xe64)
[<c058c404>] (tcp_rcv_state_process) from [<c05958ac>] (tcp_v4_do_rcv+0xf0/0x1f4)
[<c05958ac>] (tcp_v4_do_rcv) from [<c0598a4c>] (tcp_v4_rcv+0xdb8/0xe20)
[<c0598a4c>] (tcp_v4_rcv) from [<c056eb74>] (ip_protocol_deliver_rcu+0x2c/0x2dc)
[<c056eb74>] (ip_protocol_deliver_rcu) from [<c056ee6c>] (ip_local_deliver_finish+0x48/0x54)
[<c056ee6c>] (ip_local_deliver_finish) from [<c056eecc>] (ip_local_deliver+0x54/0xec)
[<c056eecc>] (ip_local_deliver) from [<c056efac>] (ip_rcv+0x48/0xb8)
[<c056efac>] (ip_rcv) from [<c0519c2c>] (__netif_receive_skb_one_core+0x50/0x6c)
[...]
The issue triggers only when not using TCP syncookies, as for syncookies
no socket is associated.
Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible")
Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible")
Signed-off-by: Martin Willi <martin@strongswan.org>
---
net/ipv4/esp4.c | 2 +-
net/ipv6/esp6.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 5459f41fc26f..10e809b296ec 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -328,7 +328,7 @@ int esp_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info *
skb->len += tailen;
skb->data_len += tailen;
skb->truesize += tailen;
- if (sk)
+ if (sk && sk_fullsock(sk))
refcount_add(tailen, &sk->sk_wmem_alloc);
goto out;
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 5afe9f83374d..239d4a65ad6e 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -296,7 +296,7 @@ int esp6_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info
skb->len += tailen;
skb->data_len += tailen;
skb->truesize += tailen;
- if (sk)
+ if (sk && sk_fullsock(sk))
refcount_add(tailen, &sk->sk_wmem_alloc);
goto out;
--
2.17.1
^ permalink raw reply related
* [PATCH RFC v2 0/3] Support fraglist GRO/GSO
From: Steffen Klassert @ 2019-01-28 8:50 UTC (permalink / raw)
To: netdev; +Cc: Steffen Klassert, Willem de Bruijn, Paolo Abeni,
Jason A. Donenfeld
This patchset adds support to do GRO/GSO by chaining packets
of the same flow at the SKB frag_list pointer. This avoids
the overhead to merge payloads into one big packet, and
on the other end, if GSO is needed it avoids the overhead
of splitting the big packet back to the native form.
Patch 1 Enables UDP GRO by default.
Patch 2 adds the core infrastructure to do fraglist
GRO/GSO.
Patch 3 enables UDP to use fraglist GRO/GSO if no GRO
supported socket is found.
I have only forwarding performance measurements so far:
I used used my IPsec forwarding test setup for this:
------------ ------------
-->| router 1 |-------->| router 2 |--
| ------------ ------------ |
| |
| -------------------- |
--------|Spirent Testcenter|<----------
--------------------
net-next (December 27th):
Single stream UDP frame size 1460 Bytes: 1.385.000 fps (16.2 Gbps).
----------------------------------------------------------------------
net-next (December 27th) + hack to enable forwarding for standard UDP GRO:
Single stream UDP frame size 1460 Bytes: 1.759.000 fps (20.5 Gbps).
----------------------------------------------------------------------
net-next (December 27th) + fraglist UDP GRO/GSO:
Single stream UDP frame size 1460 Bytes: 3.016.000 fps (35.2 Gbps).
-----------------------------------------------------------------------
Known issues:
- With this patchset fraglist GRO/GSO is done always on forwarding.
This will change as soon as we agreed on how to decide beteen
standard and fraglist GRO/GSO.
Changes from v1:
- Add IPv6 support.
- Split patchset to enable UDP GRO by default before adding
fraglist GRO support.
- Mark fraglist GRO packets as CHECKSUM_NONE.
- Take a refcount on the first segment skb when doing fraglist
segmentation. With this we can use the same error handling
path as with standard segmentation.
^ permalink raw reply
* [PATCH RFC v2 3/3] udp: Support UDP fraglist GRO/GSO.
From: Steffen Klassert @ 2019-01-28 8:50 UTC (permalink / raw)
To: netdev; +Cc: Steffen Klassert, Willem de Bruijn, Paolo Abeni,
Jason A. Donenfeld
In-Reply-To: <20190128085025.14532-1-steffen.klassert@secunet.com>
This patch extends UDP GRO to support fraglist GRO/GSO
by using the previously introduced infrastructure.
All UDP packets that are not targeted to a GRO capable
UDP sockets are going to fraglist GRO now (local input
and forward).
---
net/ipv4/udp_offload.c | 45 ++++++++++++++++++++++++++++++++++++++----
net/ipv6/udp_offload.c | 9 +++++++++
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 584635db9231..c0be33216750 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -188,6 +188,22 @@ struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,
}
EXPORT_SYMBOL(skb_udp_tunnel_segment);
+static struct sk_buff *__udp_gso_segment_list(struct sk_buff *skb,
+ netdev_features_t features)
+{
+ unsigned int mss = skb_shinfo(skb)->gso_size;
+
+ skb = skb_segment_list(skb, features, skb_mac_header_len(skb));
+ if (IS_ERR(skb))
+ return skb;
+
+ udp_hdr(skb)->len = htons(sizeof(struct udphdr) + mss);
+ skb->ip_summed = CHECKSUM_NONE;
+ skb->csum_valid = 1;
+
+ return skb;
+}
+
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
netdev_features_t features)
{
@@ -200,6 +216,9 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
__sum16 check;
__be16 newlen;
+ if (skb_shinfo(gso_skb)->gso_type & SKB_GSO_FRAGLIST)
+ return __udp_gso_segment_list(gso_skb, features);
+
mss = skb_shinfo(gso_skb)->gso_size;
if (gso_skb->len <= sizeof(*uh) + mss)
return ERR_PTR(-EINVAL);
@@ -352,16 +371,15 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
struct sk_buff *pp = NULL;
struct udphdr *uh2;
struct sk_buff *p;
+ int ret;
/* requires non zero csum, for symmetry with GSO */
if (!uh->check) {
NAPI_GRO_CB(skb)->flush = 1;
return NULL;
}
-
/* pull encapsulating udp header */
skb_gro_pull(skb, sizeof(struct udphdr));
- skb_gro_postpull_rcsum(skb, uh, sizeof(struct udphdr));
list_for_each_entry(p, head, list) {
if (!NAPI_GRO_CB(p)->same_flow)
@@ -379,8 +397,17 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
* Under small packet flood GRO count could elsewhere grow a lot
* leading to execessive truesize values
*/
- if (!skb_gro_receive(p, skb) &&
- NAPI_GRO_CB(p)->count >= UDP_GRO_CNT_MAX)
+ if (NAPI_GRO_CB(skb)->is_flist) {
+ if (!pskb_may_pull(skb, skb_gro_offset(skb)))
+ return NULL;
+ ret = skb_gro_receive_list(p, skb);
+ } else {
+ skb_gro_postpull_rcsum(skb, uh, sizeof(struct udphdr));
+
+ ret = skb_gro_receive(p, skb);
+ }
+
+ if (!ret && NAPI_GRO_CB(p)->count > UDP_GRO_CNT_MAX)
pp = p;
else if (uh->len != uh2->len)
pp = p;
@@ -402,6 +429,7 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,
int flush = 1;
if (!sk || !udp_sk(sk)->gro_receive) {
+ NAPI_GRO_CB(skb)->is_flist = sk ? !udp_sk(sk)->gro_enabled: 1;
pp = call_gro_receive(udp_gro_receive_segment, head, skb);
return pp;
}
@@ -530,6 +558,15 @@ INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff *skb, int nhoff)
const struct iphdr *iph = ip_hdr(skb);
struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
+ if (NAPI_GRO_CB(skb)->is_flist) {
+ uh->len = htons(skb->len - nhoff);
+
+ skb_shinfo(skb)->gso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);
+ skb_shinfo(skb)->gso_segs = NAPI_GRO_CB(skb)->count;
+
+ return 0;
+ }
+
if (uh->check)
uh->check = ~udp_v4_check(skb->len - nhoff, iph->saddr,
iph->daddr, 0);
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index 5f7937a4f71a..7c3f28310baa 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -154,6 +154,15 @@ INDIRECT_CALLABLE_SCOPE int udp6_gro_complete(struct sk_buff *skb, int nhoff)
const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
+ if (NAPI_GRO_CB(skb)->is_flist) {
+ uh->len = htons(skb->len - nhoff);
+
+ skb_shinfo(skb)->gso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);
+ skb_shinfo(skb)->gso_segs = NAPI_GRO_CB(skb)->count;
+
+ return 0;
+ }
+
if (uh->check)
uh->check = ~udp_v6_check(skb->len - nhoff, &ipv6h->saddr,
&ipv6h->daddr, 0);
--
2.17.1
^ permalink raw reply related
* [PATCH RFC v2 1/3] UDP: enable GRO by default.
From: Steffen Klassert @ 2019-01-28 8:50 UTC (permalink / raw)
To: netdev; +Cc: Steffen Klassert, Willem de Bruijn, Paolo Abeni,
Jason A. Donenfeld
In-Reply-To: <20190128085025.14532-1-steffen.klassert@secunet.com>
This patch enables UDP GRO regardless if a GRO capable
socket is present. With this GRO is done by default
for the local input and forwarding path.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
include/net/udp.h | 2 +-
net/ipv4/udp_offload.c | 33 ++++++++++++++-------------------
net/ipv6/udp_offload.c | 8 +++++++-
3 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/include/net/udp.h b/include/net/udp.h
index fd6d948755c8..2b8a0119264d 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -171,7 +171,7 @@ typedef struct sock *(*udp_lookup_t)(struct sk_buff *skb, __be16 sport,
__be16 dport);
struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,
- struct udphdr *uh, udp_lookup_t lookup);
+ struct udphdr *uh, struct sock *sk);
int udp_gro_complete(struct sk_buff *skb, int nhoff, udp_lookup_t lookup);
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 64f9715173ac..584635db9231 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -392,35 +392,24 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
return NULL;
}
-INDIRECT_CALLABLE_DECLARE(struct sock *udp6_lib_lookup_skb(struct sk_buff *skb,
- __be16 sport, __be16 dport));
struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,
- struct udphdr *uh, udp_lookup_t lookup)
+ struct udphdr *uh, struct sock *sk)
{
struct sk_buff *pp = NULL;
struct sk_buff *p;
struct udphdr *uh2;
unsigned int off = skb_gro_offset(skb);
int flush = 1;
- struct sock *sk;
-
- rcu_read_lock();
- sk = INDIRECT_CALL_INET(lookup, udp6_lib_lookup_skb,
- udp4_lib_lookup_skb, skb, uh->source, uh->dest);
- if (!sk)
- goto out_unlock;
- if (udp_sk(sk)->gro_enabled) {
+ if (!sk || !udp_sk(sk)->gro_receive) {
pp = call_gro_receive(udp_gro_receive_segment, head, skb);
- rcu_read_unlock();
return pp;
}
if (NAPI_GRO_CB(skb)->encap_mark ||
(skb->ip_summed != CHECKSUM_PARTIAL &&
NAPI_GRO_CB(skb)->csum_cnt == 0 &&
- !NAPI_GRO_CB(skb)->csum_valid) ||
- !udp_sk(sk)->gro_receive)
+ !NAPI_GRO_CB(skb)->csum_valid))
goto out_unlock;
/* mark that this skb passed once through the tunnel gro layer */
@@ -459,8 +448,10 @@ INDIRECT_CALLABLE_SCOPE
struct sk_buff *udp4_gro_receive(struct list_head *head, struct sk_buff *skb)
{
struct udphdr *uh = udp_gro_udphdr(skb);
+ struct sk_buff *pp;
+ struct sock *sk;
- if (unlikely(!uh) || !static_branch_unlikely(&udp_encap_needed_key))
+ if (unlikely(!uh))
goto flush;
/* Don't bother verifying checksum if we're going to flush anyway. */
@@ -475,7 +466,11 @@ struct sk_buff *udp4_gro_receive(struct list_head *head, struct sk_buff *skb)
inet_gro_compute_pseudo);
skip:
NAPI_GRO_CB(skb)->is_ipv6 = 0;
- return udp_gro_receive(head, skb, uh, udp4_lib_lookup_skb);
+ rcu_read_lock();
+ sk = static_branch_unlikely(&udp_encap_needed_key) ? udp4_lib_lookup_skb(skb, uh->source, uh->dest) : NULL;
+ pp = udp_gro_receive(head, skb, uh, sk);
+ rcu_read_unlock();
+ return pp;
flush:
NAPI_GRO_CB(skb)->flush = 1;
@@ -508,9 +503,7 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff,
rcu_read_lock();
sk = INDIRECT_CALL_INET(lookup, udp6_lib_lookup_skb,
udp4_lib_lookup_skb, skb, uh->source, uh->dest);
- if (sk && udp_sk(sk)->gro_enabled) {
- err = udp_gro_complete_segment(skb);
- } else if (sk && udp_sk(sk)->gro_complete) {
+ if (sk && udp_sk(sk)->gro_complete) {
skb_shinfo(skb)->gso_type = uh->check ? SKB_GSO_UDP_TUNNEL_CSUM
: SKB_GSO_UDP_TUNNEL;
@@ -520,6 +513,8 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff,
skb->encapsulation = 1;
err = udp_sk(sk)->gro_complete(sk, skb,
nhoff + sizeof(struct udphdr));
+ } else {
+ err = udp_gro_complete_segment(skb);
}
rcu_read_unlock();
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index 83b11d0ac091..5f7937a4f71a 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -119,6 +119,8 @@ INDIRECT_CALLABLE_SCOPE
struct sk_buff *udp6_gro_receive(struct list_head *head, struct sk_buff *skb)
{
struct udphdr *uh = udp_gro_udphdr(skb);
+ struct sk_buff *pp;
+ struct sock *sk;
if (unlikely(!uh) || !static_branch_unlikely(&udpv6_encap_needed_key))
goto flush;
@@ -136,7 +138,11 @@ struct sk_buff *udp6_gro_receive(struct list_head *head, struct sk_buff *skb)
skip:
NAPI_GRO_CB(skb)->is_ipv6 = 1;
- return udp_gro_receive(head, skb, uh, udp6_lib_lookup_skb);
+ rcu_read_lock();
+ sk = static_branch_unlikely(&udp_encap_needed_key) ? udp6_lib_lookup_skb(skb, uh->source, uh->dest) : NULL;
+ pp = udp_gro_receive(head, skb, uh, sk);
+ rcu_read_unlock();
+ return pp;
flush:
NAPI_GRO_CB(skb)->flush = 1;
--
2.17.1
^ permalink raw reply related
* [PATCH RFC v2 2/3] net: Support GRO/GSO fraglist chaining.
From: Steffen Klassert @ 2019-01-28 8:50 UTC (permalink / raw)
To: netdev; +Cc: Steffen Klassert, Willem de Bruijn, Paolo Abeni,
Jason A. Donenfeld
In-Reply-To: <20190128085025.14532-1-steffen.klassert@secunet.com>
This patch adds the core functions to chain/unchain
GSO skbs at the frag_list pointer. This also adds
a new GSO type SKB_GSO_FRAGLIST and a is_flist
flag to napi_gro_cb which indicates that this
flow will be GROed by fraglist chaining.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
include/linux/netdevice.h | 4 +-
include/linux/skbuff.h | 4 ++
net/core/dev.c | 2 +-
net/core/skbuff.c | 106 ++++++++++++++++++++++++++++++++++++++
4 files changed, 114 insertions(+), 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 1377d085ef99..050cff782fbc 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2300,7 +2300,8 @@ struct napi_gro_cb {
/* Number of gro_receive callbacks this packet already went through */
u8 recursion_counter:4;
- /* 1 bit hole */
+ /* GRO is done by frag_list pointer chaining. */
+ u8 is_flist:1;
/* used to support CHECKSUM_COMPLETE for tunneling protocols */
__wsum csum;
@@ -2660,6 +2661,7 @@ struct net_device *dev_get_by_napi_id(unsigned int napi_id);
int netdev_get_name(struct net *net, char *name, int ifindex);
int dev_restart(struct net_device *dev);
int skb_gro_receive(struct sk_buff *p, struct sk_buff *skb);
+int skb_gro_receive_list(struct sk_buff *p, struct sk_buff *skb);
static inline unsigned int skb_gro_offset(const struct sk_buff *skb)
{
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 2a57a365c711..b35a209c9c55 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -578,6 +578,8 @@ enum {
SKB_GSO_UDP = 1 << 16,
SKB_GSO_UDP_L4 = 1 << 17,
+
+ SKB_GSO_FRAGLIST = 1 << 18,
};
#if BITS_PER_LONG > 32
@@ -3369,6 +3371,8 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet);
bool skb_gso_validate_network_len(const struct sk_buff *skb, unsigned int mtu);
bool skb_gso_validate_mac_len(const struct sk_buff *skb, unsigned int len);
struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features);
+struct sk_buff *skb_segment_list(struct sk_buff *skb, netdev_features_t features,
+ unsigned int offset);
struct sk_buff *skb_vlan_untag(struct sk_buff *skb);
int skb_ensure_writable(struct sk_buff *skb, int write_len);
int __skb_vlan_pop(struct sk_buff *skb, u16 *vlan_tci);
diff --git a/net/core/dev.c b/net/core/dev.c
index 1b5a4410be0e..90b480b5bdf6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3101,7 +3101,7 @@ struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
segs = skb_mac_gso_segment(skb, features);
- if (unlikely(skb_needs_check(skb, tx_path) && !IS_ERR(segs)))
+ if (segs != skb && unlikely(skb_needs_check(skb, tx_path) && !IS_ERR(segs)))
skb_warn_bad_offload(skb);
return segs;
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 37317ffec146..7cd5e9da21bd 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3462,6 +3462,112 @@ static inline skb_frag_t skb_head_frag_to_page_desc(struct sk_buff *frag_skb)
return head_frag;
}
+struct sk_buff *skb_segment_list(struct sk_buff *skb,
+ netdev_features_t features,
+ unsigned int offset)
+{
+ struct sk_buff *list_skb = skb_shinfo(skb)->frag_list;
+ unsigned int tnl_hlen = skb_tnl_header_len(skb);
+ unsigned int delta_truesize = 0;
+ unsigned int delta_len = 0;
+ struct sk_buff *tail = NULL;
+ struct sk_buff *nskb;
+
+ skb_push(skb, -skb_network_offset(skb) + offset);
+
+ skb_shinfo(skb)->frag_list = NULL;
+
+ do {
+ nskb = list_skb;
+ list_skb = list_skb->next;
+
+ if (!tail)
+ skb->next = nskb;
+ else
+ tail->next = nskb;
+
+ tail = nskb;
+
+ delta_len += nskb->len;
+ delta_truesize += nskb->truesize;
+
+ skb_push(nskb, -skb_network_offset(nskb) + offset);
+
+ if (!secpath_exists(nskb))
+ __skb_ext_copy(nskb, skb);
+
+ memcpy(nskb->cb, skb->cb, sizeof(skb->cb));
+
+ nskb->ip_summed = CHECKSUM_NONE;
+ nskb->csum_valid = 1;
+ nskb->tstamp = skb->tstamp;
+ nskb->dev = skb->dev;
+ nskb->queue_mapping = skb->queue_mapping;
+
+ nskb->mac_len = skb->mac_len;
+ nskb->mac_header = skb->mac_header;
+ nskb->transport_header = skb->transport_header;
+ nskb->network_header = skb->network_header;
+ skb_dst_copy(nskb, skb);
+
+ skb_headers_offset_update(nskb, skb_headroom(nskb) - skb_headroom(skb));
+ skb_copy_from_linear_data_offset(skb, -tnl_hlen,
+ nskb->data - tnl_hlen,
+ offset + tnl_hlen);
+
+ if (skb_needs_linearize(nskb, features) &&
+ __skb_linearize(nskb)) {
+ kfree_skb_list(skb->next);
+ skb->next = NULL;
+ return ERR_PTR(-ENOMEM);
+ }
+ } while (list_skb);
+
+ skb->truesize = skb->truesize - delta_truesize;
+ skb->data_len = skb->data_len - delta_len;
+ skb->len = skb->len - delta_len;
+
+ skb_gso_reset(skb);
+
+ skb->prev = tail;
+
+ if (skb_needs_linearize(skb, features) &&
+ __skb_linearize(skb)) {
+ skb->next = NULL;
+ kfree_skb_list(skb->next);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ skb_get(skb);
+
+ return skb;
+}
+EXPORT_SYMBOL_GPL(skb_segment_list);
+
+int skb_gro_receive_list(struct sk_buff *p, struct sk_buff *skb)
+{
+ if (unlikely(p->len + skb->len >= 65536))
+ return -E2BIG;
+
+ if (NAPI_GRO_CB(p)->last == p)
+ skb_shinfo(p)->frag_list = skb;
+ else
+ NAPI_GRO_CB(p)->last->next = skb;
+
+ skb_pull(skb, skb_gro_offset(skb));
+
+ NAPI_GRO_CB(p)->last = skb;
+ NAPI_GRO_CB(p)->count++;
+ p->data_len += skb->len;
+ p->truesize += skb->truesize;
+ p->len += skb->len;
+
+ NAPI_GRO_CB(skb)->same_flow = 1;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(skb_gro_receive_list);
+
/**
* skb_segment - Perform protocol segmentation on skb.
* @head_skb: buffer to segment
--
2.17.1
^ permalink raw reply related
* [PATCH net] sk_msg: Always cancel strp work before freeing the psock
From: Jakub Sitnicki @ 2019-01-28 9:13 UTC (permalink / raw)
To: netdev; +Cc: John Fastabend, Daniel Borkmann, Marek Majkowski
Despite having stopped the parser, we still need to deinitialize it by
calling strp_done so that it cancels its work. Otherwise the worker
thread can run after we have freed the parser, and attempt to access its
workqueue resulting in a use-after-free:
==================================================================
BUG: KASAN: use-after-free in pwq_activate_delayed_work+0x1b/0x1d0
Read of size 8 at addr ffff888069975240 by task kworker/u2:2/93
CPU: 0 PID: 93 Comm: kworker/u2:2 Not tainted 5.0.0-rc2-00335-g28f9d1a3d4fe-dirty #14
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
Workqueue: (null) (kstrp)
Call Trace:
print_address_description+0x6e/0x2b0
? pwq_activate_delayed_work+0x1b/0x1d0
kasan_report+0xfd/0x177
? pwq_activate_delayed_work+0x1b/0x1d0
? pwq_activate_delayed_work+0x1b/0x1d0
pwq_activate_delayed_work+0x1b/0x1d0
? process_one_work+0x4aa/0x660
pwq_dec_nr_in_flight+0x9b/0x100
worker_thread+0x82/0x680
? process_one_work+0x660/0x660
kthread+0x1b9/0x1e0
? __kthread_create_on_node+0x250/0x250
ret_from_fork+0x1f/0x30
Allocated by task 111:
sk_psock_init+0x3c/0x1b0
sock_map_link.isra.2+0x103/0x4b0
sock_map_update_common+0x94/0x270
sock_map_update_elem+0x145/0x160
__se_sys_bpf+0x152e/0x1e10
do_syscall_64+0xb2/0x3e0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 112:
kfree+0x7f/0x140
process_one_work+0x40b/0x660
worker_thread+0x82/0x680
kthread+0x1b9/0x1e0
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff888069975180
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 192 bytes inside of
512-byte region [ffff888069975180, ffff888069975380)
The buggy address belongs to the page:
page:ffffea0001a65d00 count:1 mapcount:0 mapping:ffff88806d401280 index:0x0 compound_mapcount: 0
flags: 0x4000000000010200(slab|head)
raw: 4000000000010200 dead000000000100 dead000000000200 ffff88806d401280
raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888069975100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888069975180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888069975200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888069975280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888069975300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Reported-by: Marek Majkowski <marek@cloudflare.com>
Link: https://lore.kernel.org/netdev/CAJPywTLwgXNEZ2dZVoa=udiZmtrWJ0q5SuBW64aYs0Y1khXX3A@mail.gmail.com
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
---
net/core/skmsg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/core/skmsg.c b/net/core/skmsg.c
index d6d5c20d7044..8c826603bf36 100644
--- a/net/core/skmsg.c
+++ b/net/core/skmsg.c
@@ -545,8 +545,7 @@ static void sk_psock_destroy_deferred(struct work_struct *gc)
struct sk_psock *psock = container_of(gc, struct sk_psock, gc);
/* No sk_callback_lock since already detached. */
- if (psock->parser.enabled)
- strp_done(&psock->parser.strp);
+ strp_done(&psock->parser.strp);
cancel_work_sync(&psock->work);
--
2.17.2
^ permalink raw reply related
* [PATCH] ucc_geth: Reset BQL queue when stopping device
From: Mathias Thore @ 2019-01-28 9:07 UTC (permalink / raw)
To: leoyang.li, netdev, linuxppc-dev, david.gounaris,
joakim.tjernlund
Cc: Mathias Thore
After a timeout event caused by for example a broadcast storm, when
the MAC and PHY are reset, the BQL TX queue needs to be reset as
well. Otherwise, the device will exhibit severe performance issues
even after the storm has ended.
Co-authored-by: David Gounaris <david.gounaris@infinera.com>
Signed-off-by: Mathias Thore <mathias.thore@infinera.com>
---
drivers/net/ethernet/freescale/ucc_geth.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index c3d539e209ed..eb3e65e8868f 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -1879,6 +1879,8 @@ static void ucc_geth_free_tx(struct ucc_geth_private *ugeth)
u16 i, j;
u8 __iomem *bd;
+ netdev_reset_queue(ugeth->ndev);
+
ug_info = ugeth->ug_info;
uf_info = &ug_info->uf_info;
--
2.19.2
^ permalink raw reply related
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