* Re: [PATCH net 1/2] ibmvnic: Unmap ibmvnic_statistics structure
From: David Miller @ 2016-11-13 18:42 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, mwb
In-Reply-To: <1478883646-10760-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Fri, 11 Nov 2016 11:00:45 -0600
> This structure was mapped but never subsequently unmapped.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 2/2] ibmvnic: Fix size of debugfs name buffer
From: David Miller @ 2016-11-13 18:42 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, mwb
In-Reply-To: <1478883646-10760-2-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Fri, 11 Nov 2016 11:00:46 -0600
> This mistake was causing debugfs directory creation
> failures when multiple ibmvnic devices were probed.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/2] bnx2: Wait for in-flight DMA to complete at probe stage
From: Michael Chan @ 2016-11-13 19:02 UTC (permalink / raw)
To: Baoquan He
Cc: Netdev, David Miller, open list, Dept-GELinuxNICDev, rasesh.mody,
harish.patil, frank, jsr, pmenzel, jroedel, dyoung
In-Reply-To: <1479013293-21001-3-git-send-email-bhe@redhat.com>
On Sat, Nov 12, 2016 at 9:01 PM, Baoquan He <bhe@redhat.com> wrote:
> In-flight DMA from 1st kernel could continue going in kdump kernel.
> New io-page table has been created before bnx2 does reset at open stage.
> We have to wait for the in-flight DMA to complete to avoid it look up
> into the newly created io-page table at probe stage.
>
> Suggested-by: Michael Chan <michael.chan@broadcom.com>
> Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Michael Chan <michael.chan@broadcom.com>
^ permalink raw reply
* [PATCH v2] ip6_output: ensure flow saddr actually belongs to device
From: Jason A. Donenfeld @ 2016-11-13 19:02 UTC (permalink / raw)
To: David Ahern, Netdev, WireGuard mailing list, LKML,
YOSHIFUJI Hideaki, Hannes Frederic Sowa
In-Reply-To: <405b2e79-854d-4c30-07b0-bd524137d2f6@cumulusnetworks.com>
This puts the IPv6 routing functions in parity with the IPv4 routing
functions. Namely, we now check in v6 that if a flowi6 requests an
saddr, the returned dst actually corresponds to a net device that has
that saddr. This mirrors the v4 logic with __ip_dev_find in
__ip_route_output_key_hash. In the event that the returned dst is not
for a dst with a dev that has the saddr, we return -EINVAL, just like
v4; this makes it easy to use the same error handlers for both cases.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: David Ahern <dsa@cumulusnetworks.com>
---
Changes from v1:
This moves the check to the top and now sees if it's a valid address
on _any_ device, not just the one in dst.
include/net/ipv6.h | 2 ++
net/ipv6/ip6_output.c | 28 ++++++++++++++++++++++++++++
2 files changed, 30 insertions(+)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 8fed1cd..e5dc14f 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -914,6 +914,8 @@ struct dst_entry *ip6_sk_dst_lookup_flow(struct sock *sk, struct flowi6 *fl6,
const struct in6_addr *final_dst);
struct dst_entry *ip6_blackhole_route(struct net *net,
struct dst_entry *orig_dst);
+struct net_device *__ip6_dev_find(struct net *net, struct in6_addr *addr,
+ bool devref);
/*
* skb processing functions
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 6001e78..371170b 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -916,6 +916,30 @@ static struct dst_entry *ip6_sk_dst_check(struct sock *sk,
return dst;
}
+/**
+ * __ip6_dev_find - find the first device with a given source address.
+ * @net: the net namespace
+ * @addr: the source address
+ * @devref: if true, take a reference on the found device
+ *
+ * If a caller uses devref=false, it should be protected by RCU, or RTNL
+ */
+struct net_device *__ip6_dev_find(struct net *net, struct in6_addr *addr, bool devref)
+{
+ struct net_device *result;
+
+ rcu_read_lock();
+ for_each_netdev_rcu(net, result) {
+ if (ipv6_chk_addr(net, addr, result, 1))
+ break;
+ }
+ if (result && devref)
+ dev_hold(result);
+ rcu_read_unlock();
+ return result;
+}
+EXPORT_SYMBOL(__ip6_dev_find);
+
static int ip6_dst_lookup_tail(struct net *net, const struct sock *sk,
struct dst_entry **dst, struct flowi6 *fl6)
{
@@ -926,6 +950,10 @@ static int ip6_dst_lookup_tail(struct net *net, const struct sock *sk,
int err;
int flags = 0;
+ if (!ipv6_addr_any(&fl6->saddr) &&
+ !__ip6_dev_find(net, &fl6->saddr, false))
+ return -EINVAL;
+
/* The correct way to handle this would be to do
* ip6_route_get_saddr, and then ip6_route_output; however,
* the route-specific preferred source forces the
--
2.10.2
^ permalink raw reply related
* Re: stmmac/RTL8211F/Meson GXBB: TX throughput problems
From: André Roth @ 2016-11-13 19:13 UTC (permalink / raw)
To: Jerome Brunet
Cc: Martin Blumenstingl, Johnson Leung, Giuseppe CAVALLARO,
linux-amlogic, Alexandre Torgue, netdev
In-Reply-To: <1478192276.6632.34.camel@baylibre.com>
> Andre, the 3.14 kernel you are talking, is it this one ? :
> https://github.com/hardkernel/linux/tree/odroidc2-3.14.y
yes
> Because in drivers/net/phy/realtek.c, they disable EEE, but
> also 1000Base-T Full Duplex advertisement ?
>
> + /* disable 1000m adv*/
> + val = phy_read(phydev, 0x9);
> + phy_write(phydev, 0x9, val&(~(1<<9)));
>
> If this is the kernel you are running, you should not be able to have
> ethernet at 1000MB/s ? Or is it in half duplex mode ?
ethtool shows 1000Mb/s Full-Duplex and the bandwith is around 300Mb/s
(as measured by scp). kernel version: 3.14.65-73
^ permalink raw reply
* Re: stmmac/RTL8211F/Meson GXBB: TX throughput problems
From: André Roth @ 2016-11-13 19:20 UTC (permalink / raw)
To: Jerome Brunet
Cc: Martin Blumenstingl, Giuseppe CAVALLARO, Johnson Leung, netdev,
Alexandre Torgue, linux-amlogic
In-Reply-To: <1478190980.6632.26.camel@baylibre.com>
Hi all,
> To everybody having similar issue with their OdroidC2, could you try
> the attached patch and let us know if it changes anything for you ?
I can confirm that this patch removes the problem, I have now constant
~300Mb/s in both directions without any issue ! :)
I used the v4.10/integ branch, which shows the problem without applying
this patch.
Thanks for your work,
André
^ permalink raw reply
* Re: Debugging Ethernet issues
From: Mason @ 2016-11-13 19:51 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Florian Fainelli, Mans Rullgard, Sergei Shtylyov,
Tom Lendacky, Zach Brown, Shaohui Xie, Tim Beale, Brian Hill,
Vince Bridgers, Balakumaran Kannan, David S. Miller,
Sebastian Frias, Kirill Kapranov
In-Reply-To: <20161113030919.GA2892@lunn.ch>
On 13/11/2016 04:09, Andrew Lunn wrote:
> Mason wrote:
>
>> When connected to a Gigabit switch
>> 3.4 negotiates a LAN DHCP setup instantly
>> 4.7 requires over 5 seconds to do so
>
> When you run tcpdump on the DHCP server, are you noticing the first
> request is missing?
>
> What can happen is the dhclient gets started immediately and sends out
> its first request before auto-negotiation has finished. So this first packet
> gets lost. The retransmit after a few seconds is then successful.
I will run tcpdump on the server as I run udhcpc on the client
for Linux 3.4 vs 4.7
Do you know what would make auto-negotiation fail at 100 Mbps
on 4.7? (whereas it succeeds on 3.4)
(Thinking out loud) If the problem were in auto-negotiation,
then if should work if I hard-code speed and duplex using
ethtool, right? (IIRC, hard-coding doesn't help.)
Regards.
^ permalink raw reply
* Re: Debugging Ethernet issues
From: Florian Fainelli @ 2016-11-13 19:55 UTC (permalink / raw)
To: Mason, Andrew Lunn
Cc: netdev, Mans Rullgard, Sergei Shtylyov, Tom Lendacky, Zach Brown,
Shaohui Xie, Tim Beale, Brian Hill, Vince Bridgers,
Balakumaran Kannan, David S. Miller, Sebastian Frias,
Kirill Kapranov
In-Reply-To: <5828C452.6050808@free.fr>
Le 13/11/2016 à 11:51, Mason a écrit :
> On 13/11/2016 04:09, Andrew Lunn wrote:
>
>> Mason wrote:
>>
>>> When connected to a Gigabit switch
>>> 3.4 negotiates a LAN DHCP setup instantly
>>> 4.7 requires over 5 seconds to do so
>>
>> When you run tcpdump on the DHCP server, are you noticing the first
>> request is missing?
>>
>> What can happen is the dhclient gets started immediately and sends out
>> its first request before auto-negotiation has finished. So this first packet
>> gets lost. The retransmit after a few seconds is then successful.
>
> I will run tcpdump on the server as I run udhcpc on the client
> for Linux 3.4 vs 4.7
>
> Do you know what would make auto-negotiation fail at 100 Mbps
> on 4.7? (whereas it succeeds on 3.4)
>
> (Thinking out loud) If the problem were in auto-negotiation,
> then if should work if I hard-code speed and duplex using
> ethtool, right? (IIRC, hard-coding doesn't help.)
I would start with checking basic things:
- does your Ethernet driver get a link UP being reported correctly
(netif_carrier_ok returns 1)?
- if you let the bootloader configure the PHY and utilize the Generic
PHY driver instead of the Atheros PHY driver, does the problem appear as
well?
- what do transmit/receive counters on the Ethernet driver/MAC return?
--
Florian
^ permalink raw reply
* Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
From: Andrew Lunn @ 2016-11-13 19:55 UTC (permalink / raw)
To: Lino Sanfilippo
Cc: davem, charrer, liodot, gregkh, devel, linux-kernel, netdev
In-Reply-To: <1479012453-19410-2-git-send-email-LinoSanfilippo@gmx.de>
> +static const char slic_stats_strings[][ETH_GSTRING_LEN] = {
> + "rx_packets ",
> + "rx_bytes ",
> + "rx_multicasts ",
> + "rx_errors ",
> + "rx_buff_miss ",
> + "rx_tp_csum ",
> + "rx_tp_oflow ",
> + "rx_tp_hlen ",
> + "rx_ip_csum ",
> + "rx_ip_len ",
Are there any other drivers which pad the statistics strings?
> +static void slic_set_link_autoneg(struct slic_device *sdev)
> +{
> + unsigned int subid = sdev->pdev->subsystem_device;
> + u32 val;
> +
> + if (sdev->is_fiber) {
> + /* We've got a fiber gigabit interface, and register 4 is
> + * different in fiber mode than in copper mode.
> + */
> + /* advertise FD only @1000 Mb */
> + val = MII_ADVERTISE << 16 | SLIC_PAR_ADV1000XFD |
> + SLIC_PAR_ASYMPAUSE_FIBER;
> + /* enable PAUSE frames */
> + slic_write(sdev, SLIC_REG_WPHY, val);
> + /* reset phy, enable auto-neg */
> + val = MII_BMCR << 16 | SLIC_PCR_RESET | SLIC_PCR_AUTONEG |
> + SLIC_PCR_AUTONEG_RST;
> + slic_write(sdev, SLIC_REG_WPHY, val);
> + } else { /* copper gigabit */
> + /* We've got a copper gigabit interface, and register 4 is
> + * different in copper mode than in fiber mode.
> + */
> + /* advertise 10/100 Mb modes */
> + val = MII_ADVERTISE << 16 | SLIC_PAR_ADV100FD |
> + SLIC_PAR_ADV100HD | SLIC_PAR_ADV10FD | SLIC_PAR_ADV10HD;
> + /* enable PAUSE frames */
> + val |= SLIC_PAR_ASYMPAUSE;
> + /* required by the Cicada PHY */
> + val |= SLIC_PAR_802_3;
> + slic_write(sdev, SLIC_REG_WPHY, val);
> +
> + /* advertise FD only @1000 Mb */
> + val = MII_CTRL1000 << 16 | SLIC_PGC_ADV1000FD;
> + slic_write(sdev, SLIC_REG_WPHY, val);
> +
> + if (subid != PCI_SUBDEVICE_ID_ALACRITECH_CICADA) {
> + /* if a Marvell PHY enable auto crossover */
> + val = SLIC_MIICR_REG_16 | SLIC_MRV_REG16_XOVERON;
> + slic_write(sdev, SLIC_REG_WPHY, val);
> +
> + /* reset phy, enable auto-neg */
> + val = MII_BMCR << 16 | SLIC_PCR_RESET |
> + SLIC_PCR_AUTONEG | SLIC_PCR_AUTONEG_RST;
> + slic_write(sdev, SLIC_REG_WPHY, val);
> + } else {
> + /* enable and restart auto-neg (don't reset) */
> + val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
> + SLIC_PCR_AUTONEG_RST;
> + slic_write(sdev, SLIC_REG_WPHY, val);
> + }
> + }
> + sdev->autoneg = true;
> +}
Could this be pulled out into a standard PHY driver? All the SLIC
SLIC_PCR_ defines seems to be the same as those in mii.h. This could
be a standard PHY hidden behind a single register.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: sr: fix IPv6 initialization failure without lwtunnels
From: David Lebrun @ 2016-11-13 19:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, lorenzo
In-Reply-To: <20161113.002348.81553025732356797.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]
On 11/13/2016 06:23 AM, David Miller wrote:
> This seems like such a huge mess, quite frankly.
>
> IPV6-SR has so many strange dependencies, a weird Kconfig option that is
> simply controlling what a responsible sysadmin should be allow to do if
> he chooses anyways.
>
> Every distribution is going to say "¯\_(ツ)_/¯" and just turn the thing
> on in their builds.
Indeed, the issue is that seg6_iptunnel.o was included in obj-y instead
of ipv6-y, triggering the bug when CONFIG_IPV6=m. Fixed with the
following modification to the patch (tested with allyesconfig and
allmodconfig):
diff --git a/net/ipv6/Makefile b/net/ipv6/Makefile
index 8979d53..a233136 100644
--- a/net/ipv6/Makefile
+++ b/net/ipv6/Makefile
@@ -53,6 +53,6 @@ obj-$(subst m,y,$(CONFIG_IPV6)) += inet6_hashtables.o
ifneq ($(CONFIG_IPV6),)
obj-$(CONFIG_NET_UDP_TUNNEL) += ip6_udp_tunnel.o
-obj-$(CONFIG_LWTUNNEL) += seg6_iptunnel.o
+ipv6-$(CONFIG_LWTUNNEL) += seg6_iptunnel.o
obj-y += mcast_snoop.o
endif
I agree with you that the way to combine the dependencies is strange,
even if they are very few. The part of the IPv6-SR patch that is enabled
by default depends on two things: IPV6 and LWTUNNEL. The problem is that
LWTUNNEL does not depend on IPV6 and is not necessarily enabled. To fix
the bug reported by Lorenzo, I propose to select one the three following
solutions:
1. Make LWTUNNEL always enabled (removing the option).
Pros: remove an option
Cons: add always-enabled code
2. Create an option IPV6_SEG6_LWTUNNEL, which would select LWTUNNEL and
enable the compilation of seg6_iptunnel.o.
Pros: logically dissociate the part of IPv6-SR that depends on
LWTUNNEL from the core patch and simplifies compilation
Cons: add an option
3. Apply the proposed patch with the fix
Pros: do not modify options
Cons: weird conditional compilation
What do you think ?
David
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]
^ permalink raw reply related
* Re: [patch net v2 0/2] mlxsw: Couple of fixes
From: Jiri Pirko @ 2016-11-13 20:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, yotamg, arkadis, idosch, eladr, nogahf, ogerlitz
In-Reply-To: <20161113.125133.1226481580321868668.davem@davemloft.net>
Sun, Nov 13, 2016 at 06:51:33PM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Fri, 11 Nov 2016 16:34:24 +0100
>
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Please, queue-up both for stable. Thanks!
>
>Just to be clear I did make sure to take v2 rather than
>v1.
Good. Thanks!
^ permalink raw reply
* Re: [PATCH] ip6_output: ensure flow saddr actually belongs to device
From: Jason A. Donenfeld @ 2016-11-13 20:19 UTC (permalink / raw)
To: David Ahern
Cc: Netdev, WireGuard mailing list, LKML, YOSHIFUJI Hideaki,
Hannes Frederic Sowa
In-Reply-To: <405b2e79-854d-4c30-07b0-bd524137d2f6@cumulusnetworks.com>
Hi David,
On Sun, Nov 13, 2016 at 5:30 PM, David Ahern <dsa@cumulusnetworks.com> wrote:
> You can't require the address to be on the dst device. e.g., it can be an address from the loopback/vrf device.
>
> This block needs to be done at function entry, and pass dev as NULL to mean is the address assigned to any interface. That gets you the equivalency of the IPv4 check.
I gave v2 my best shot. Hopefully it's adequate, but I have a feeling
it might be best for you to just code up what you have in mind.
Regards,
Jason
^ permalink raw reply
* Re: [PATCH net-next 00/11] Start adding support for mv88e6390 family
From: Andrew Lunn @ 2016-11-13 20:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, vivien.didelot
In-Reply-To: <20161113.004859.749028544003333521.davem@davemloft.net>
On Sun, Nov 13, 2016 at 12:48:59AM -0500, David Miller wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Fri, 11 Nov 2016 03:53:32 +0100
>
> > This is the first patchset implementing support for the mv88e6390
> > family. This is a new generation of switch devices and has numerous
> > incompatible changes to the registers. These patches allow the switch
> > to the detected during probe, and makes the statistics unit work.
> >
> > These patches are insufficient to make the mv88e6390 functional. More
> > patches will follow.
>
> Andrew, this series doesn't apply cleanly to net-next, so you'll
> need to respin.
Hi David
I'm happy to respin, but i'm wondering why the don't apply.
What seems to be the issue is you said you have accepted:
[PATCH net-next 0/2] Fixes for port refactoring
https://marc.info/?l=linux-netdev&m=147880114928996&w=1
Yet i don't see these in net-next. And i based this patchset on a tree
which included the fixes. Hence they are not applying.
Have the fixes really been accepted?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net 2/2] r8152: rx descriptor check
From: Mark Lord @ 2016-11-13 20:34 UTC (permalink / raw)
To: David Miller, hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <20161113.123954.2134945576362221851.davem@davemloft.net>
On 16-11-13 12:39 PM, David Miller wrote:
> From: Hayes Wang <hayeswang@realtek.com>
> Date: Fri, 11 Nov 2016 15:15:41 +0800
>
>> For some platforms, the data in memory is not the same with the one
>> from the device. That is, the data of memory is unbelievable. The
>> check is used to find out this situation.
>>
>> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
>
> I'm all for adding consistency checks, but I disagree with proceeding
> in this manner for this.
>
> If you add this patch now, there is a much smaller likelyhood that you
> will work with a high priority to figure out _why_ this is happening.
>
> For all we know this could be a platform bug in the DMA API for the
> systems in question.
>
> It could also be a bug elsewhere in the driver, either in setting up
> the descriptor DMA mappings or how the chip is programmed.
>
> Either way the true cause must be found before we start throwing
> changes like this into the driver.
I agree.
The system I use it with is a 32-bit ppc476, with non-coherent RAM,
and using 16KB page sizes.
The dongle instantly becomes a lot more reliable when r8152.c is updated
to use usb_alloc_coherent() for URB buffers, rather than kmalloc().
Not sure why that would be though, as the USB stack normally would handle
kmalloc'd buffers just fine. It is calling the appropriate routines,
which boil down to invalidating the dcache lines (for inbound bulk xfers)
as part of usb_submit_urb(), and yet the problem there persists.
It could be caused by cache-line sharing with other allocations, but that seems
unlikely as the kmalloc() size is 16384 bytes per buffer. Perhaps the driver
is somehow accessing the buffer space again after doing usb_submit_urb()?
That would certainly produce this kind of behaviour.
Or maybe there's just a memory barrier missing somewhere in path.
The really weird thing is that ASIX-based dongles (which use a different driver)
don't have this problem, and yet they also use kmalloc'd buffers.
I have access to the test system only for a day or two a week,
and it takes a few hours to do a good test as to whether something helps or not.
I'll continue to poke at it as time and New Ideas permit.
New Ideas welcome!
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
* Re: [PATCH net 2/2] r8152: rx descriptor check
From: Mark Lord @ 2016-11-13 20:38 UTC (permalink / raw)
To: David Miller, hayeswang-Rasf1IRRPZFBDgjK7y7TUQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cd36fce8-2f17-debd-d514-e3cbe7ed3762-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
On 16-11-13 03:34 PM, Mark Lord wrote:
>
> The system I use it with is a 32-bit ppc476, with non-coherent RAM,
> and using 16KB page sizes.
>
> The dongle instantly becomes a lot more reliable when r8152.c is updated
> to use usb_alloc_coherent() for URB buffers, rather than kmalloc().
>
> Not sure why that would be though, as the USB stack normally would handle
> kmalloc'd buffers just fine. It is calling the appropriate routines,
> which boil down to invalidating the dcache lines (for inbound bulk xfers)
> as part of usb_submit_urb(), and yet the problem there persists.
>
> It could be caused by cache-line sharing with other allocations, but that seems
> unlikely as the kmalloc() size is 16384 bytes per buffer. Perhaps the driver
> is somehow accessing the buffer space again after doing usb_submit_urb()?
> That would certainly produce this kind of behaviour.
>
> Or maybe there's just a memory barrier missing somewhere in path.
>
> The really weird thing is that ASIX-based dongles (which use a different driver)
> don't have this problem, and yet they also use kmalloc'd buffers.
>
> I have access to the test system only for a day or two a week,
> and it takes a few hours to do a good test as to whether something helps or not.
> I'll continue to poke at it as time and New Ideas permit.
Oh, and the problems did not exist with the 3.14.xx kernels and earlier.
They began to show up when we tried 3.16.xx and all newer kernels.
The difference there is that RX checksums were enabled in hardware as of 3.16.xx,
and thus the network stack began accepting bad packets from the r8152 driver.
I don't know if the ASIX driver uses hardware checksums or just software checksums.
That might explain why it is more reliable here.
--
Mark Lord
Real-Time Remedies Inc.
mlord-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ip6_output: ensure flow saddr actually belongs to device
From: David Ahern @ 2016-11-13 20:39 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Netdev, Hannes Frederic Sowa, LKML, WireGuard mailing list,
YOSHIFUJI Hideaki
In-Reply-To: <CAHmME9rV_Qqj_QNKOARav6vOyyF-__E07saChPYo9MF6wED83A@mail.gmail.com>
On 11/13/16 1:19 PM, Jason A. Donenfeld wrote:
> I gave v2 my best shot. Hopefully it's adequate, but I have a feeling
> it might be best for you to just code up what you have in mind.
nah, you are doing fine. one more comment on v2.
^ permalink raw reply
* Re: [PATCH v2] ip6_output: ensure flow saddr actually belongs to device
From: David Ahern @ 2016-11-13 20:45 UTC (permalink / raw)
To: Jason A. Donenfeld, Netdev, WireGuard mailing list, LKML,
YOSHIFUJI Hideaki, Hannes Frederic Sowa
In-Reply-To: <20161113190251.1027-1-Jason@zx2c4.com>
On 11/13/16 12:02 PM, Jason A. Donenfeld wrote:
> This puts the IPv6 routing functions in parity with the IPv4 routing
> functions. Namely, we now check in v6 that if a flowi6 requests an
> saddr, the returned dst actually corresponds to a net device that has
> that saddr. This mirrors the v4 logic with __ip_dev_find in
> __ip_route_output_key_hash. In the event that the returned dst is not
> for a dst with a dev that has the saddr, we return -EINVAL, just like
> v4; this makes it easy to use the same error handlers for both cases.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: David Ahern <dsa@cumulusnetworks.com>
> ---
> Changes from v1:
> This moves the check to the top and now sees if it's a valid address
> on _any_ device, not just the one in dst.
>
> include/net/ipv6.h | 2 ++
> net/ipv6/ip6_output.c | 28 ++++++++++++++++++++++++++++
> 2 files changed, 30 insertions(+)
>
> diff --git a/include/net/ipv6.h b/include/net/ipv6.h
> index 8fed1cd..e5dc14f 100644
> --- a/include/net/ipv6.h
> +++ b/include/net/ipv6.h
> @@ -914,6 +914,8 @@ struct dst_entry *ip6_sk_dst_lookup_flow(struct sock *sk, struct flowi6 *fl6,
> const struct in6_addr *final_dst);
> struct dst_entry *ip6_blackhole_route(struct net *net,
> struct dst_entry *orig_dst);
> +struct net_device *__ip6_dev_find(struct net *net, struct in6_addr *addr,
> + bool devref);
>
> /*
> * skb processing functions
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 6001e78..371170b 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -916,6 +916,30 @@ static struct dst_entry *ip6_sk_dst_check(struct sock *sk,
> return dst;
> }
>
> +/**
> + * __ip6_dev_find - find the first device with a given source address.
> + * @net: the net namespace
> + * @addr: the source address
> + * @devref: if true, take a reference on the found device
> + *
> + * If a caller uses devref=false, it should be protected by RCU, or RTNL
> + */
> +struct net_device *__ip6_dev_find(struct net *net, struct in6_addr *addr, bool devref)
> +{
> + struct net_device *result;
> +
> + rcu_read_lock();
> + for_each_netdev_rcu(net, result) {
> + if (ipv6_chk_addr(net, addr, result, 1))
> + break;
> + }
> + if (result && devref)
> + dev_hold(result);
> + rcu_read_unlock();
> + return result;
> +}
> +EXPORT_SYMBOL(__ip6_dev_find);
You don't need a new function to walk all interfaces; just use ipv6_chk_addr with a dev arg of NULL. IPv6 has a hash table with all unicast addresses -- inet6_addr_lst. ipv6_chk_addr is checking that list for the address in question. The actual device is not relevant for verifying the address is a valid local one (though the device can be returned from ifp->idev->dev if ever needed).
So drop the above ...
> +
> static int ip6_dst_lookup_tail(struct net *net, const struct sock *sk,
> struct dst_entry **dst, struct flowi6 *fl6)
> {
> @@ -926,6 +950,10 @@ static int ip6_dst_lookup_tail(struct net *net, const struct sock *sk,
> int err;
> int flags = 0;
>
> + if (!ipv6_addr_any(&fl6->saddr) &&
> + !__ip6_dev_find(net, &fl6->saddr, false))
... and just use ipv6_chk_addr here.
> + return -EINVAL;
> +
> /* The correct way to handle this would be to do
> * ip6_route_get_saddr, and then ip6_route_output; however,
> * the route-specific preferred source forces the
>
^ permalink raw reply
* [PATCH] net: stmmac: Add support for ethtool::nway_reset
From: Florian Fainelli @ 2016-11-13 21:24 UTC (permalink / raw)
To: netdev
Cc: davem, Florian Fainelli, Giuseppe Cavallaro, Alexandre Torgue,
open list
If we have a PHY device, just invoke genphy_restart_aneg() to restart
auto-negotiation.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 3fe9340b748f..7a487c9ccdea 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -862,6 +862,16 @@ static int stmmac_set_tunable(struct net_device *dev,
return ret;
}
+static int stmmac_nway_reset(struct net_device *dev)
+{
+ struct stmmac_priv *priv = netdev_priv(dev);
+
+ if (!dev->phydev)
+ return -ENODEV;
+
+ return genphy_restart_aneg(dev->phydev);
+}
+
static const struct ethtool_ops stmmac_ethtool_ops = {
.begin = stmmac_check_if_running,
.get_drvinfo = stmmac_ethtool_getdrvinfo,
@@ -886,6 +896,7 @@ static const struct ethtool_ops stmmac_ethtool_ops = {
.set_tunable = stmmac_set_tunable,
.get_link_ksettings = stmmac_ethtool_get_link_ksettings,
.set_link_ksettings = stmmac_ethtool_set_link_ksettings,
+ .nway_reset = stmmac_nway_reset,
};
void stmmac_set_ethtool_ops(struct net_device *netdev)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] netfilter: x_tables: simplify IS_ERR_OR_NULL to NULL test
From: Pablo Neira Ayuso @ 2016-11-13 21:27 UTC (permalink / raw)
To: Julia Lawall
Cc: Florian Westphal, David S. Miller, kernel-janitors, linux-kernel,
netdev, coreteam, netfilter-devel, Hideaki YOSHIFUJI,
James Morris, Alexey Kuznetsov, Jozsef Kadlecsik, Patrick McHardy,
christophe.jaillet
In-Reply-To: <1478867558-21650-1-git-send-email-Julia.Lawall@lip6.fr>
On Fri, Nov 11, 2016 at 01:32:38PM +0100, Julia Lawall wrote:
> Since commit 7926dbfa4bc1 ("netfilter: don't use
> mutex_lock_interruptible()"), the function xt_find_table_lock can only
> return NULL on an error. Simplify the call sites and update the
> comment before the function.
Applied, thanks Julia!
^ permalink raw reply
* Re: [PATCH] net: stmmac: Add support for ethtool::nway_reset
From: Florian Fainelli @ 2016-11-13 21:35 UTC (permalink / raw)
To: netdev; +Cc: davem, Giuseppe Cavallaro, Alexandre Torgue, open list
In-Reply-To: <20161113212444.3777-1-f.fainelli@gmail.com>
Le 13/11/2016 à 13:24, Florian Fainelli a écrit :
> If we have a PHY device, just invoke genphy_restart_aneg() to restart
> auto-negotiation.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
David, please drop this patch for now, since I have another one pending
which is going to touch the net_device/phydev interaction, this one also
causes a build warning since priv is not used.
Thank you!
--
Florian
^ permalink raw reply
* Re: [PATCH] net: stmmac: Add support for ethtool::nway_reset
From: kbuild test robot @ 2016-11-13 22:19 UTC (permalink / raw)
To: Florian Fainelli
Cc: kbuild-all, netdev, davem, Florian Fainelli, Giuseppe Cavallaro,
Alexandre Torgue, open list
In-Reply-To: <20161113212444.3777-1-f.fainelli@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]
Hi Florian,
[auto build test WARNING on net-next/master]
[also build test WARNING on next-20161111]
[cannot apply to v4.9-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-stmmac-Add-support-for-ethtool-nway_reset/20161114-053015
config: x86_64-kexec (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c: In function 'stmmac_nway_reset':
>> drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c:867:22: warning: unused variable 'priv' [-Wunused-variable]
struct stmmac_priv *priv = netdev_priv(dev);
^~~~
vim +/priv +867 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
851 int ret = 0;
852
853 switch (tuna->id) {
854 case ETHTOOL_RX_COPYBREAK:
855 priv->rx_copybreak = *(u32 *)data;
856 break;
857 default:
858 ret = -EINVAL;
859 break;
860 }
861
862 return ret;
863 }
864
865 static int stmmac_nway_reset(struct net_device *dev)
866 {
> 867 struct stmmac_priv *priv = netdev_priv(dev);
868
869 if (!dev->phydev)
870 return -ENODEV;
871
872 return genphy_restart_aneg(dev->phydev);
873 }
874
875 static const struct ethtool_ops stmmac_ethtool_ops = {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24265 bytes --]
^ permalink raw reply
* [PATCH 01/39] netfilter: get rid of useless debugging from core
From: Pablo Neira Ayuso @ 2016-11-13 22:24 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1479075933-4491-1-git-send-email-pablo@netfilter.org>
This patch remove compile time code to catch inconventional verdicts.
We have better ways to handle this case these days, eg. pr_debug() but
even though I don't think this is useful at all, so let's remove this.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/core.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 004af030ef1a..3d4aa96cb219 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -323,15 +323,6 @@ unsigned int nf_iterate(struct sk_buff *skb,
repeat:
verdict = (*entryp)->ops.hook((*entryp)->ops.priv, skb, state);
if (verdict != NF_ACCEPT) {
-#ifdef CONFIG_NETFILTER_DEBUG
- if (unlikely((verdict & NF_VERDICT_MASK)
- > NF_MAX_VERDICT)) {
- NFDEBUG("Evil return from %p(%u).\n",
- (*entryp)->ops.hook, state->hook);
- *entryp = rcu_dereference((*entryp)->next);
- continue;
- }
-#endif
if (verdict != NF_REPEAT)
return verdict;
goto repeat;
--
2.1.4
^ permalink raw reply related
* [PATCH 02/39] netfilter: remove comments that predate rcu days
From: Pablo Neira Ayuso @ 2016-11-13 22:24 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1479075933-4491-1-git-send-email-pablo@netfilter.org>
We cannot block/sleep on nf_iterate because netfilter runs under rcu
read lock these days, where blocking is well-known to be illegal. So
let's remove these old comments.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/core.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 3d4aa96cb219..76014ad72ec5 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -308,18 +308,11 @@ unsigned int nf_iterate(struct sk_buff *skb,
{
unsigned int verdict;
- /*
- * The caller must not block between calls to this
- * function because of risk of continuing from deleted element.
- */
while (*entryp) {
if (state->thresh > (*entryp)->ops.priority) {
*entryp = rcu_dereference((*entryp)->next);
continue;
}
-
- /* Optimization: we don't need to hold module
- reference here, since function can't sleep. --RR */
repeat:
verdict = (*entryp)->ops.hook((*entryp)->ops.priv, skb, state);
if (verdict != NF_ACCEPT) {
--
2.1.4
^ permalink raw reply related
* [PATCH 03/39] netfilter: kill NF_HOOK_THRESH() and state->tresh
From: Pablo Neira Ayuso @ 2016-11-13 22:24 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1479075933-4491-1-git-send-email-pablo@netfilter.org>
Patch c5136b15ea36 ("netfilter: bridge: add and use br_nf_hook_thresh")
introduced br_nf_hook_thresh().
Replace NF_HOOK_THRESH() by br_nf_hook_thresh from
br_nf_forward_finish(), so we have no more callers for this macro.
As a result, state->thresh and explicit thresh parameter in the hook
state structure is not required anymore. And we can get rid of
skip-hook-under-thresh loop in nf_iterate() in the core path that is
only used by br_netfilter to search for the filter hook.
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/linux/netfilter.h | 50 +++++++++--------------------------
include/linux/netfilter_ingress.h | 2 +-
net/bridge/br_netfilter_hooks.c | 8 +++---
net/bridge/netfilter/ebtable_broute.c | 2 +-
net/netfilter/core.c | 4 ---
net/netfilter/nf_queue.c | 2 --
6 files changed, 19 insertions(+), 49 deletions(-)
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index abc7fdcb9eb1..e0d000f6c9bf 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -49,7 +49,6 @@ struct sock;
struct nf_hook_state {
unsigned int hook;
- int thresh;
u_int8_t pf;
struct net_device *in;
struct net_device *out;
@@ -84,7 +83,7 @@ struct nf_hook_entry {
static inline void nf_hook_state_init(struct nf_hook_state *p,
struct nf_hook_entry *hook_entry,
unsigned int hook,
- int thresh, u_int8_t pf,
+ u_int8_t pf,
struct net_device *indev,
struct net_device *outdev,
struct sock *sk,
@@ -92,7 +91,6 @@ static inline void nf_hook_state_init(struct nf_hook_state *p,
int (*okfn)(struct net *, struct sock *, struct sk_buff *))
{
p->hook = hook;
- p->thresh = thresh;
p->pf = pf;
p->in = indev;
p->out = outdev;
@@ -155,20 +153,16 @@ extern struct static_key nf_hooks_needed[NFPROTO_NUMPROTO][NF_MAX_HOOKS];
int nf_hook_slow(struct sk_buff *skb, struct nf_hook_state *state);
/**
- * nf_hook_thresh - call a netfilter hook
+ * nf_hook - call a netfilter hook
*
* Returns 1 if the hook has allowed the packet to pass. The function
* okfn must be invoked by the caller in this case. Any other return
* value indicates the packet has been consumed by the hook.
*/
-static inline int nf_hook_thresh(u_int8_t pf, unsigned int hook,
- struct net *net,
- struct sock *sk,
- struct sk_buff *skb,
- struct net_device *indev,
- struct net_device *outdev,
- int (*okfn)(struct net *, struct sock *, struct sk_buff *),
- int thresh)
+static inline int nf_hook(u_int8_t pf, unsigned int hook, struct net *net,
+ struct sock *sk, struct sk_buff *skb,
+ struct net_device *indev, struct net_device *outdev,
+ int (*okfn)(struct net *, struct sock *, struct sk_buff *))
{
struct nf_hook_entry *hook_head;
int ret = 1;
@@ -185,8 +179,8 @@ static inline int nf_hook_thresh(u_int8_t pf, unsigned int hook,
if (hook_head) {
struct nf_hook_state state;
- nf_hook_state_init(&state, hook_head, hook, thresh,
- pf, indev, outdev, sk, net, okfn);
+ nf_hook_state_init(&state, hook_head, hook, pf, indev, outdev,
+ sk, net, okfn);
ret = nf_hook_slow(skb, &state);
}
@@ -195,14 +189,6 @@ static inline int nf_hook_thresh(u_int8_t pf, unsigned int hook,
return ret;
}
-static inline int nf_hook(u_int8_t pf, unsigned int hook, struct net *net,
- struct sock *sk, struct sk_buff *skb,
- struct net_device *indev, struct net_device *outdev,
- int (*okfn)(struct net *, struct sock *, struct sk_buff *))
-{
- return nf_hook_thresh(pf, hook, net, sk, skb, indev, outdev, okfn, INT_MIN);
-}
-
/* Activate hook; either okfn or kfree_skb called, unless a hook
returns NF_STOLEN (in which case, it's up to the hook to deal with
the consequences).
@@ -221,19 +207,6 @@ static inline int nf_hook(u_int8_t pf, unsigned int hook, struct net *net,
*/
static inline int
-NF_HOOK_THRESH(uint8_t pf, unsigned int hook, struct net *net, struct sock *sk,
- struct sk_buff *skb, struct net_device *in,
- struct net_device *out,
- int (*okfn)(struct net *, struct sock *, struct sk_buff *),
- int thresh)
-{
- int ret = nf_hook_thresh(pf, hook, net, sk, skb, in, out, okfn, thresh);
- if (ret == 1)
- ret = okfn(net, sk, skb);
- return ret;
-}
-
-static inline int
NF_HOOK_COND(uint8_t pf, unsigned int hook, struct net *net, struct sock *sk,
struct sk_buff *skb, struct net_device *in, struct net_device *out,
int (*okfn)(struct net *, struct sock *, struct sk_buff *),
@@ -242,7 +215,7 @@ NF_HOOK_COND(uint8_t pf, unsigned int hook, struct net *net, struct sock *sk,
int ret;
if (!cond ||
- ((ret = nf_hook_thresh(pf, hook, net, sk, skb, in, out, okfn, INT_MIN)) == 1))
+ ((ret = nf_hook(pf, hook, net, sk, skb, in, out, okfn)) == 1))
ret = okfn(net, sk, skb);
return ret;
}
@@ -252,7 +225,10 @@ NF_HOOK(uint8_t pf, unsigned int hook, struct net *net, struct sock *sk, struct
struct net_device *in, struct net_device *out,
int (*okfn)(struct net *, struct sock *, struct sk_buff *))
{
- return NF_HOOK_THRESH(pf, hook, net, sk, skb, in, out, okfn, INT_MIN);
+ int ret = nf_hook(pf, hook, net, sk, skb, in, out, okfn);
+ if (ret == 1)
+ ret = okfn(net, sk, skb);
+ return ret;
}
/* Call setsockopt() */
diff --git a/include/linux/netfilter_ingress.h b/include/linux/netfilter_ingress.h
index 33e37fb41d5d..fd44e4131710 100644
--- a/include/linux/netfilter_ingress.h
+++ b/include/linux/netfilter_ingress.h
@@ -26,7 +26,7 @@ static inline int nf_hook_ingress(struct sk_buff *skb)
if (unlikely(!e))
return 0;
- nf_hook_state_init(&state, e, NF_NETDEV_INGRESS, INT_MIN,
+ nf_hook_state_init(&state, e, NF_NETDEV_INGRESS,
NFPROTO_NETDEV, skb->dev, NULL, NULL,
dev_net(skb->dev), NULL);
return nf_hook_slow(skb, &state);
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index 2fe9345c1407..d0d66faebe90 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -561,8 +561,8 @@ static int br_nf_forward_finish(struct net *net, struct sock *sk, struct sk_buff
}
nf_bridge_push_encap_header(skb);
- NF_HOOK_THRESH(NFPROTO_BRIDGE, NF_BR_FORWARD, net, sk, skb,
- in, skb->dev, br_forward_finish, 1);
+ br_nf_hook_thresh(NF_BR_FORWARD, net, sk, skb, in, skb->dev,
+ br_forward_finish);
return 0;
}
@@ -1016,8 +1016,8 @@ int br_nf_hook_thresh(unsigned int hook, struct net *net,
/* We may already have this, but read-locks nest anyway */
rcu_read_lock();
- nf_hook_state_init(&state, elem, hook, NF_BR_PRI_BRNF + 1,
- NFPROTO_BRIDGE, indev, outdev, sk, net, okfn);
+ nf_hook_state_init(&state, elem, hook, NFPROTO_BRIDGE, indev, outdev,
+ sk, net, okfn);
ret = nf_hook_slow(skb, &state);
rcu_read_unlock();
diff --git a/net/bridge/netfilter/ebtable_broute.c b/net/bridge/netfilter/ebtable_broute.c
index ec94c6f1ae88..599679e3498d 100644
--- a/net/bridge/netfilter/ebtable_broute.c
+++ b/net/bridge/netfilter/ebtable_broute.c
@@ -53,7 +53,7 @@ static int ebt_broute(struct sk_buff *skb)
struct nf_hook_state state;
int ret;
- nf_hook_state_init(&state, NULL, NF_BR_BROUTING, INT_MIN,
+ nf_hook_state_init(&state, NULL, NF_BR_BROUTING,
NFPROTO_BRIDGE, skb->dev, NULL, NULL,
dev_net(skb->dev), NULL);
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 76014ad72ec5..cb0232c11bc8 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -309,10 +309,6 @@ unsigned int nf_iterate(struct sk_buff *skb,
unsigned int verdict;
while (*entryp) {
- if (state->thresh > (*entryp)->ops.priority) {
- *entryp = rcu_dereference((*entryp)->next);
- continue;
- }
repeat:
verdict = (*entryp)->ops.hook((*entryp)->ops.priv, skb, state);
if (verdict != NF_ACCEPT) {
diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c
index 8f08d759844a..0fb38966e5bf 100644
--- a/net/netfilter/nf_queue.c
+++ b/net/netfilter/nf_queue.c
@@ -200,8 +200,6 @@ void nf_reinject(struct nf_queue_entry *entry, unsigned int verdict)
verdict = NF_DROP;
}
- entry->state.thresh = INT_MIN;
-
if (verdict == NF_ACCEPT) {
hook_entry = rcu_dereference(hook_entry->next);
if (hook_entry)
--
2.1.4
^ permalink raw reply related
* [PATCH 04/39] netfilter: deprecate NF_STOP
From: Pablo Neira Ayuso @ 2016-11-13 22:24 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1479075933-4491-1-git-send-email-pablo@netfilter.org>
NF_STOP is only used by br_netfilter these days, and it can be emulated
with a combination of NF_STOLEN plus explicit call to the ->okfn()
function as Florian suggests.
To retain binary compatibility with userspace nf_queue application, we
have to keep NF_STOP around, so libnetfilter_queue userspace userspace
applications still work if they use NF_STOP for some exotic reason.
Out of tree modules using NF_STOP would break, but we don't care about
those.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/uapi/linux/netfilter.h | 2 +-
net/bridge/br_netfilter_hooks.c | 6 ++++--
net/netfilter/core.c | 2 +-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/netfilter.h b/include/uapi/linux/netfilter.h
index d93f949d1d9a..7550e9176a54 100644
--- a/include/uapi/linux/netfilter.h
+++ b/include/uapi/linux/netfilter.h
@@ -13,7 +13,7 @@
#define NF_STOLEN 2
#define NF_QUEUE 3
#define NF_REPEAT 4
-#define NF_STOP 5
+#define NF_STOP 5 /* Deprecated, for userspace nf_queue compatibility. */
#define NF_MAX_VERDICT NF_STOP
/* we overload the higher bits for encoding auxiliary data such as the queue
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index d0d66faebe90..7e3645fa6339 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -845,8 +845,10 @@ static unsigned int ip_sabotage_in(void *priv,
struct sk_buff *skb,
const struct nf_hook_state *state)
{
- if (skb->nf_bridge && !skb->nf_bridge->in_prerouting)
- return NF_STOP;
+ if (skb->nf_bridge && !skb->nf_bridge->in_prerouting) {
+ state->okfn(state->net, state->sk, skb);
+ return NF_STOLEN;
+ }
return NF_ACCEPT;
}
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index cb0232c11bc8..14f97b624f98 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -333,7 +333,7 @@ int nf_hook_slow(struct sk_buff *skb, struct nf_hook_state *state)
entry = rcu_dereference(state->hook_entries);
next_hook:
verdict = nf_iterate(skb, state, &entry);
- if (verdict == NF_ACCEPT || verdict == NF_STOP) {
+ if (verdict == NF_ACCEPT) {
ret = 1;
} else if ((verdict & NF_VERDICT_MASK) == NF_DROP) {
kfree_skb(skb);
--
2.1.4
^ 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