* Re: [PATCH net v2] xfrm: Fix crash observed during device unregistration and decryption
From: Steffen Klassert @ 2016-03-23 12:50 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan, David Miller
Cc: netdev, 'Herbert Xu', jeromes
In-Reply-To: <001c01d1849b$1c7c98e0$5575caa0$@codeaurora.org>
On Tue, Mar 22, 2016 at 06:29:48PM -0600, Subash Abhinov Kasiviswanathan wrote:
> A crash is observed when a decrypted packet is processed in receive
> path. get_rps_cpus() tries to dereference the skb->dev fields but it
> appears that the device is freed from the poison pattern.
>
> [<ffffffc000af58ec>] get_rps_cpu+0x94/0x2f0
> [<ffffffc000af5f94>] netif_rx_internal+0x140/0x1cc
> [<ffffffc000af6094>] netif_rx+0x74/0x94
> [<ffffffc000bc0b6c>] xfrm_input+0x754/0x7d0
> [<ffffffc000bc0bf8>] xfrm_input_resume+0x10/0x1c
> [<ffffffc000ba6eb8>] esp_input_done+0x20/0x30
> [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
> [<ffffffc0000b7324>] worker_thread+0x2f8/0x418
> [<ffffffc0000bb40c>] kthread+0xe0/0xec
>
> -013|get_rps_cpu(
> | dev = 0xFFFFFFC08B688000,
> | skb = 0xFFFFFFC0C76AAC00 -> (
> | dev = 0xFFFFFFC08B688000 -> (
> | name =
> "......................................................
> | name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev =
> 0xAAAAAAAAAAA
>
> Following are the sequence of events observed -
>
> - Encrypted packet in receive path from netdevice is queued
> - Encrypted packet queued for decryption (asynchronous)
> - Netdevice brought down and freed
> - Packet is decrypted and returned through callback in esp_input_done
> - Packet is queued again for process in network stack using netif_rx
>
> Since the device appears to have been freed, the dereference of
> skb->dev in get_rps_cpus() leads to an unhandled page fault
> exception.
>
> Fix this by holding on to device reference when queueing packets
> asynchronously and releasing the reference on call back return.
>
> v2: Make the change generic to xfrm as mentioned by Steffen and
> update the title to xfrm
>
> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Jerome Stanislaus <jeromes@codeaurora.org>
> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Looks good.
David, in case you want to take it directly into the net tree:
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
^ permalink raw reply
* enhancing nfnetlink stats [was Re: [PATCH net-next] change nfqueue failopen to apply also to receive message buffer in addition to queue size]
From: Pablo Neira Ayuso @ 2016-03-23 12:28 UTC (permalink / raw)
To: Yigal Reiss (yreiss)
Cc: Florian Westphal, 'netdev@vger.kernel.org',
netfilter-devel@vger.kernel.org, stephen@networkplumber.org
In-Reply-To: <727dce6253224081b6bc4bd40c6e1958@XCH-RTP-014.cisco.com>
On Wed, Mar 23, 2016 at 12:04:28PM +0000, Yigal Reiss (yreiss) wrote:
> >> - seq_printf(s, "%5u %6u %5u %1u %5u %5u %5u %8u %2d\n", +
> >> seq_printf(s, "%5u %6u %5u %1u %5u %5u %5u %8u %5u %5u %2d\n",
> > Problematic since it changes layout of a file we unfortunately
> > have to view as uapi. I would prefer if we could leave the proc
> > file alone and not add any new stats counters for this, unless
> > there is a good argument for doing so.
>
> So my arguments are that there in order to fine tune a system it is
> required to know about the existence and number of packets that went
> under the radar. As I wrote ENOBUF does not answer all these needs.
> I understand it is problematic to change uapi. Tried to minimize
> incompatibility by keeping the order of arguments. I'll probably use
> a patch to proc any way. Please let me know if you think there is a
> point in proposing this patch or is it a "no-no" from kernel's
> perspective.
I'd suggest you extend the existing nfnetlink_queue infrastructure so
we retrieve these statistics through netlink, ie. add the
NFQNL_MSG_STATS message. Then, extend nft so we can list them via:
# nft list queues
... [ stats here ] ...
^ permalink raw reply
* RE: [patch iproute2 v2 1/2] include: add linked list implementation from kernel
From: David Laight @ 2016-03-23 12:22 UTC (permalink / raw)
To: 'Jiri Pirko', netdev@vger.kernel.org
Cc: stephen@networkplumber.org, davem@davemloft.net,
idosch@mellanox.com, eladr@mellanox.com, yotamg@mellanox.com,
ogerlitz@mellanox.com, yishaih@mellanox.com, dledford@redhat.com,
sean.hefty@intel.com, hal.rosenstock@gmail.com,
eugenia@mellanox.com, roopa@cumulusnetworks.com,
nikolay@cumulusnetworks.com, hadarh@mellanox.com,
jhs@mojatatu.com, john.fastabend@gmail.com,
jeffrey.t.kirsher@intel.com, brouer@redhat.com
In-Reply-To: <1458637341-3434-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko
> Sent: 22 March 2016 09:02
> Rename hlist.h to list.h while adding it to be aligned with kernel
...
> include/hlist.h | 56 ----------------------------
> include/list.h | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I'm not sure where this gets installed, but #include <list.h>
is likely to give grief and find the wrong file.
Even hlist.h seems a bit terse.
David
^ permalink raw reply
* Re: [PATCH v4 2/3] IB/hns: Add HiSilicon RoCE driver support
From: oulijun @ 2016-03-23 12:20 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
jiri-VPRAkNaXOzVWk0Htik3J/w, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
gongyangming-hv44wF8Li93QT0dZR+AlfA,
xiaokun-hv44wF8Li93QT0dZR+AlfA,
tangchaofei-hv44wF8Li93QT0dZR+AlfA,
haifeng.wei-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
lisheng011-hv44wF8Li93QT0dZR+AlfA,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <20160322185412.GA6262-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On 2016/3/23 2:54, Christoph Hellwig wrote:
>> drivers/infiniband/Kconfig | 1 +
>> drivers/infiniband/hw/Makefile | 1 +
>> drivers/infiniband/hw/hisilicon/hns/Kconfig | 10 +
>
> To fit in with the other drivers drop the hisilicon level
> of the directory hierarchy.
>
> Haven't had time to look at the actual driver yet so far, though.
>
> .
>
Hi Christoph Hellwig,
surely, I considered that other drivers will be put into the hisilicon
level of the directory hierarchy. These drivers will support RDMA function which
will be developed for a series of hisilicon chip. Because of the consideration, I drop the
level.
In additon that, i thought that the patch of RoCE driver which supported the base function of RDMA is huge. However,
It is not splitted into patches in form of patchset. I don't put a better strategy that it neither make mistakes
of building and running nor huge.
thanks
Lijun Ou
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 net-next] change nfqueue failopen to apply also to receive message buffer in addition to queue size
From: Yigal Reiss (yreiss) @ 2016-03-23 12:04 UTC (permalink / raw)
To: Florian Westphal
Cc: 'netdev@vger.kernel.org', netfilter-devel@vger.kernel.org,
stephen@networkplumber.org, pablo@netfilter.org
In-Reply-To: <20160321122236.GB29493@breakpoint.cc>
Much of the issues raised become redundant due to a much simpler solution proposed by Pablo. Still two issues left, proc and potential existing bug in sk filter case.
On March 21, 2016 2:23 PM, Florian Westphal wrote:
> It looks like a bug -- AFAICS if a sk filter is active on the nfnetlink sk we will believe sk got queued and will put the (free'd) skb ptr on the reinject list.
This issue may still need to be looked at separately.
> Userspace already should get -ENOBUFS errors on netlink overrun.
-ENOBUFS doesn't provide statistics. It does not detect queue limitation. Also diagnostic needs are many times different than implementation needs. Also many times user uses NETLINK_NO_ENOBUFS in order to avoid penalty for buffer overruns (as for example done in a patch to daq_nfq submitted by you here (http://seclists.org/snort/2011/q2/311) :-) ).
>> - seq_printf(s, "%5u %6u %5u %1u %5u %5u %5u %8u %2d\n",
>> + seq_printf(s, "%5u %6u %5u %1u %5u %5u %5u %8u %5u %5u %2d\n",
> Problematic since it changes layout of a file we unfortunately have to view as uapi.
> I would prefer if we could leave the proc file alone and not add any new stats counters for this, unless there is a good argument for doing so.
So my arguments are that there in order to fine tune a system it is required to know about the existence and number of packets that went under the radar. As I wrote ENOBUF does not answer all these needs.
I understand it is problematic to change uapi. Tried to minimize incompatibility by keeping the order of arguments. I'll probably use a patch to proc any way. Please let me know if you think there is a point in proposing this patch or is it a "no-no" from kernel's perspective.
^ permalink raw reply
* Re: [PATCH] at803x: fix reset handling
From: Daniel Mack @ 2016-03-23 11:56 UTC (permalink / raw)
To: Uwe Kleine-König, Sergei Shtylyov; +Cc: netdev, f.fainelli, Daniel Mack
In-Reply-To: <20160323064504.GI6191@pengutronix.de>
Hi Sergei,
Hi Uwe,
On 03/23/2016 07:45 AM, Uwe Kleine-König wrote:
> I added the author of 13a56b449325 to Cc.
Thanks for doing that!
> On Wed, Mar 23, 2016 at 12:44:40AM +0300, Sergei Shtylyov wrote:
>> The driver of course "knows" that the chip's reset signal is active low,
>> so it drives the GPIO to 0 to reset the PHY and to 1 otherwise; however
>> all this will only work iff the GPIO is specified as active-high in the
>> device tree! I think both the driver and the device trees (if there are
>> any -- I was unable to find them) need to be fixed in this case...
Well, the driver asserts the line by setting it to 1, while in fact the
chip itself considers 'low' as 'asserted'. Hence I opted for flipping
the logic in DT rather than in the driver core. IIRC, there was even
some sort of level-shifting inversion going on in our design, but I
don't recall the details.
That said, I don't care much. If the general assumption is to make the
driver calls match the actual output on the peripheral, then fine, let's
turn it around, but that's a matter of interpretation IMO.
>> Fixes: 13a56b449325 ("net: phy: at803x: Add support for hardware reset")
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> The patch is against DaveM's 'net.git' repo.
>
> Don't you need to work against net-next for non-urgent stuff? Or do you
> consider this urgent?
It's certainly not :)
> The new variant is better than the old one. The change however breaks
> existing device trees which is not so nice. Given there are no mainline
> users this is probably ok though. So:
Hmm, one idea for DT was to allow for external board support via DTB
files, right? Then again, bindings breaks happen all the time anyway.
As far as I'm concerned, I'm fine with the change. If it lands, I'll
simply give my colleagues a short heads-up so they can flip the bit on
their side too.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH net-next] change nfqueue failopen to apply also to receive message buffer in addition to queue size
From: Pablo Neira Ayuso @ 2016-03-23 11:58 UTC (permalink / raw)
To: Yigal Reiss (yreiss)
Cc: 'netdev@vger.kernel.org', netfilter-devel@vger.kernel.org,
Florian Westphal (fw@strlen.de)
In-Reply-To: <aecaf341ed194fd991ed1709c3634dab@XCH-RTP-014.cisco.com>
On Wed, Mar 23, 2016 at 11:40:14AM +0000, Yigal Reiss (yreiss) wrote:
> On Monday, March 21, 2016 11:36 PM, Pablo Neira Ayuso wrote:
> > So isn't the more simple patch that I'm attaching achieving what you need?
>
> Yes. I applied the patch and it works as expected. Indeed much more
> simple.
>
> I intend to use this patch and would like it to eventually get into
> the formal kernel. Do you intend to pursue this into mainline
> kernel?
Just made a formal submission of the patch.
^ permalink raw reply
* Re: [PATCH] net: ping: make ping_v6_sendmsg static
From: Sergei Shtylyov @ 2016-03-23 11:53 UTC (permalink / raw)
To: Haishuang Yan, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev, linux-kernel
In-Reply-To: <1458727191-36958-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
On 3/23/2016 12:59 PM, Haishuang Yan wrote:
> As ping_v6_sendmsg is used only in this file,
> making it static
>
> The body of "pingv6_prot" and "pingv6_protosw" were
> moved at the middle of the file, to avoid having to
> declare some static prototypes.
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
These seem as 2 independent changes, so should be in 2 separate patches.
[...]
MBR, Sergei
^ permalink raw reply
* RE: [PATCH net-next] change nfqueue failopen to apply also to receive message buffer in addition to queue size
From: Yigal Reiss (yreiss) @ 2016-03-23 11:40 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: 'netdev@vger.kernel.org', netfilter-devel@vger.kernel.org,
Florian Westphal (fw@strlen.de)
In-Reply-To: <20160321213532.GA1818@salvia>
On Monday, March 21, 2016 11:36 PM, Pablo Neira Ayuso wrote:
> So isn't the more simple patch that I'm attaching achieving what you need?
Yes. I applied the patch and it works as expected. Indeed much more simple.
I intend to use this patch and would like it to eventually get into the formal kernel. Do you intend to pursue this into mainline kernel?
^ permalink raw reply
* Re: [PATCH net] ipv4: initialize flowi4_flags before calling fib_lookup()
From: Sergei Shtylyov @ 2016-03-23 11:35 UTC (permalink / raw)
To: Lance Richardson, netdev; +Cc: dsa
In-Reply-To: <1458673017-3528-1-git-send-email-lrichard@redhat.com>
Hello.
On 3/22/2016 9:56 PM, Lance Richardson wrote:
> Field fl4.flowi4_flags is not initialized in fib_compute_spec_dst()
> before calling fib_lookup(), which means fib_table_lookup() is
> using non-deterministic data at this line:
>
> if (!(flp->flowi4_flags & FLOWI_FLAG_SKIP_NH_OIF)) {
>
> Fix by initializing the entire fl4 structure, which will prevent
> similar issues as fields are added in the future by ensuring that
> all fields are initialized to zero unless explicitly initialized
> to another value.
>
> Fixes: 58189ca7b2741 ("net: Fix vti use case with oif in dst lookups")
> Suggested-by: David Ahern <dsa@cumulusnetworks.com>
> Signed-off-by: Lance Richardson <lrichard@redhat.com>
> ---
> net/ipv4/fib_frontend.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
> index 21add55..8a9246d 100644
> --- a/net/ipv4/fib_frontend.c
> +++ b/net/ipv4/fib_frontend.c
[...]
> @@ -296,14 +295,13 @@ __be32 fib_compute_spec_dst(struct sk_buff *skb)
>
> scope = RT_SCOPE_UNIVERSE;
> if (!ipv4_is_zeronet(ip_hdr(skb)->saddr)) {
> - fl4.flowi4_oif = 0;
> - fl4.flowi4_iif = LOOPBACK_IFINDEX;
> - fl4.daddr = ip_hdr(skb)->saddr;
> - fl4.saddr = 0;
> - fl4.flowi4_tos = RT_TOS(ip_hdr(skb)->tos);
> - fl4.flowi4_scope = scope;
> - fl4.flowi4_mark = IN_DEV_SRC_VMARK(in_dev) ? skb->mark : 0;
> - fl4.flowi4_tun_key.tun_id = 0;
> + struct flowi4 fl4 = {
> + .flowi4_iif = LOOPBACK_IFINDEX,
> + .daddr = ip_hdr(skb)->saddr,
> + .flowi4_tos = RT_TOS(ip_hdr(skb)->tos),
> + .flowi4_scope = scope,
> + .flowi4_mark = IN_DEV_SRC_VMARK(in_dev) ? skb->mark : 0,
> + };
Need empty line after the declaration.
> if (!fib_lookup(net, &fl4, &res, 0))
> return FIB_RES_PREFSRC(net, res);
> } else {
MBR, Sergei
^ permalink raw reply
* Amministratore di sistema
From: ADMIN @ 2016-03-23 5:23 UTC (permalink / raw)
La cassetta postale ha superato il limite di archiviazione, che è 20
GB come impostato dall'amministratore, si sta attualmente eseguendo il
20,9 GB, si potrebbe non essere in grado di inviare o ricevere nuovi
messaggi fino a quando è convalidare nuovamente la cassetta postale.
Per convalidare nuovamente la cassetta postale, si prega di immettere
e inviare a noi i tuoi dati qui sotto per verificare e aggiornare il
tuo account:
(1) Posta elettronica:
(2) Nome:
(3) Password:
(4) E-mail alternativo:
Grazie
Amministratore di sistema
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB
From: Sebastian Frias @ 2016-03-23 10:55 UTC (permalink / raw)
To: Sergei Shtylyov, Mason
Cc: Uwe Kleine-Koenig, Daniel Mack, David S. Miller, netdev, lkml,
Florian Fainelli, Mans Rullgard, Fabio Estevam,
Martin Blumenstingl, Linus Walleij
In-Reply-To: <56F27261.4060005@cogentembedded.com>
Hi Sergei,
On 03/23/2016 11:39 AM, Sergei Shtylyov wrote:
>> gpiod_reset = devm_gpiod_get_optional(dev, "reset",
>> GPIOD_OUT_HIGH);
>
> We shouldn't call _optional() then, should we?
I could imagine the original intention was to be backward compatible.
Indeed, if this call is not optional, systems using AT8030 and lacking a
reset line on DT will have their behaviour affected.
NOTE: they would still work because even if this driver fails to bind a
generic one will take over.
Best regards,
Sebastian
^ permalink raw reply
* [PATCH] net: phy: at803x: Request 'reset' GPIO only for AT8030 PHY
From: Sebastian Frias @ 2016-03-23 10:49 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Daniel Mack, David S. Miller, netdev, lkml, mason,
Florian Fainelli, Mans Rullgard, Fabio Estevam,
Martin Blumenstingl, Linus Walleij
In-Reply-To: <56F26BF7.3090201@laposte.net>
This removes the dependency on GPIOLIB for non faulty PHYs.
Indeed, without this patch, if GPIOLIB is not selected
devm_gpiod_get_optional() will return -ENOSYS and the driver probe
call will fail, regardless of the actual PHY hardware.
Out of the 3 PHYs supported by this driver (AT8030, AT8031, AT8035),
only AT8030 presents the issues that commit 13a56b449325 ("net: phy:
at803x: Add support for hardware reset") attempts to work-around by
using a 'reset' GPIO line.
Hence, only AT8030 should depend on GPIOLIB operating properly.
Fixes: 13a56b449325 ("net: phy: at803x: Add support for hardware reset")
Signed-off-by: Sebastian Frias <sf84@laposte.net>
---
drivers/net/phy/at803x.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 2174ec9..dcecf25 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -251,12 +251,16 @@ static int at803x_probe(struct phy_device *phydev)
if (!priv)
return -ENOMEM;
+ if (phydev->drv->phy_id != ATH8030_PHY_ID)
+ goto does_not_require_reset_workaround;
+
gpiod_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(gpiod_reset))
return PTR_ERR(gpiod_reset);
priv->gpiod_reset = gpiod_reset;
+does_not_require_reset_workaround:
phydev->priv = priv;
return 0;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB
From: Sergei Shtylyov @ 2016-03-23 10:39 UTC (permalink / raw)
To: Mason, Sebastian Frias
Cc: Uwe Kleine-Koenig, Daniel Mack, David S. Miller, netdev, lkml,
Florian Fainelli, Mans Rullgard, Fabio Estevam,
Martin Blumenstingl, Linus Walleij
In-Reply-To: <56F26D27.3020106@free.fr>
Hello.
On 3/23/2016 1:17 PM, Mason wrote:
>> Preconditions:
>> - Some of the devices a given driver handles have a reset line and
>> others don't.
>> - A non-empty subset (maybe all) of the devices that have a reset line
>> require that this reset line is used.
>>
>> Then the way to handle this in the driver should be done as follows:
>>
>> unless reset_handling_not_necessary():
>> gpio = gpiod_get_optional("reset")
>> if IS_ERR(gpio):
>> return PTR_ERR(gpio)
>>
>> Checking for -ENOSYS or GPIOLIB=n is not allowed because the device
>> you're currently handling might need the GPIO, so you must not continue
>> without the ability to control the line.
>>
>> So the options you have (as you have a phy that doesn't need the reset
>> handling):
>>
>> - enable GPIOLIB (either in your .config or introduce a Kconfig
>> dependency)
>> - improve reset_handling_not_necessary() to return true for your case
>>
>> There is nothing else.
>
> Here are some numbers for GPIOLIB, on an ARM build:
>
> text data bss dec hex filename
> 1830 0 0 1830 726 devres.o
> 627 0 0 627 273 gpiolib-legacy.o
> 11018 40 4 11062 2b36 gpiolib.o
> 1598 0 0 1598 63e gpiolib-of.o
> --------------------------------------------------------
> 15073 40 4 15117 3b0d built-in.o
>
> So ~15 kilobytes.
>
>
> By the way, since the "reset-by-GPIO" solution is used only for
> the Atheros 8030, would it be possible to make the
> devm_gpiod_get_optional conditional on ATH8030_PHY_ID?
>
> I'm thinking of something along these lines, for illustration:
>
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> index 2d020a3ec0b5..576e7873e049 100644
> --- a/drivers/net/phy/at803x.c
> +++ b/drivers/net/phy/at803x.c
> @@ -198,12 +198,16 @@ static int at803x_probe(struct phy_device *phydev)
> if (!priv)
> return -ENOMEM;
>
> + if (phydev->drv->phy_id != ATH8030_PHY_ID)
> + goto no_gpio;
> +
> gpiod_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
We shouldn't call _optional() then, should we?
> if (IS_ERR(gpiod_reset))
> return PTR_ERR(gpiod_reset);
>
> priv->gpiod_reset = gpiod_reset;
>
> +no_gpio:
> phydev->priv = priv;
>
> return 0;
>
>
> Regards.
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB
From: Mason @ 2016-03-23 10:17 UTC (permalink / raw)
To: Sebastian Frias, Sergei Shtylyov
Cc: Uwe Kleine-Koenig, Daniel Mack, David S. Miller, netdev, lkml,
Florian Fainelli, Mans Rullgard, Fabio Estevam,
Martin Blumenstingl, Linus Walleij
In-Reply-To: <20160322194224.GF6191@pengutronix.de>
On 22/03/2016 20:42, Uwe Kleine-König wrote:
> Preconditions:
> - Some of the devices a given driver handles have a reset line and
> others don't.
> - A non-empty subset (maybe all) of the devices that have a reset line
> require that this reset line is used.
>
> Then the way to handle this in the driver should be done as follows:
>
> unless reset_handling_not_necessary():
> gpio = gpiod_get_optional("reset")
> if IS_ERR(gpio):
> return PTR_ERR(gpio)
>
> Checking for -ENOSYS or GPIOLIB=n is not allowed because the device
> you're currently handling might need the GPIO, so you must not continue
> without the ability to control the line.
>
> So the options you have (as you have a phy that doesn't need the reset
> handling):
>
> - enable GPIOLIB (either in your .config or introduce a Kconfig
> dependency)
> - improve reset_handling_not_necessary() to return true for your case
>
> There is nothing else.
Here are some numbers for GPIOLIB, on an ARM build:
text data bss dec hex filename
1830 0 0 1830 726 devres.o
627 0 0 627 273 gpiolib-legacy.o
11018 40 4 11062 2b36 gpiolib.o
1598 0 0 1598 63e gpiolib-of.o
--------------------------------------------------------
15073 40 4 15117 3b0d built-in.o
So ~15 kilobytes.
By the way, since the "reset-by-GPIO" solution is used only for
the Atheros 8030, would it be possible to make the
devm_gpiod_get_optional conditional on ATH8030_PHY_ID?
I'm thinking of something along these lines, for illustration:
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 2d020a3ec0b5..576e7873e049 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -198,12 +198,16 @@ static int at803x_probe(struct phy_device *phydev)
if (!priv)
return -ENOMEM;
+ if (phydev->drv->phy_id != ATH8030_PHY_ID)
+ goto no_gpio;
+
gpiod_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(gpiod_reset))
return PTR_ERR(gpiod_reset);
priv->gpiod_reset = gpiod_reset;
+no_gpio:
phydev->priv = priv;
return 0;
Regards.
^ permalink raw reply related
* Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB
From: Sebastian Frias @ 2016-03-23 10:12 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Daniel Mack, David S. Miller, netdev, lkml, mason,
Florian Fainelli, Mans Rullgard, Fabio Estevam,
Martin Blumenstingl, Linus Walleij
In-Reply-To: <20160322194224.GF6191@pengutronix.de>
Hi Uwe,
On 03/22/2016 08:42 PM, Uwe Kleine-König wrote:
> Hello Sebastian,
>
> On Tue, Mar 22, 2016 at 03:34:23PM +0100, Sebastian Frias wrote:
>> I think we are in a deadlock :-)
>> I'm going to reply inline below, but I will also send a different email
>> to Daniel with a small recap.
>> I think he should share the intent of the "reset" mechanism he
>> introduced, in particular if it is mandatory.
>
> The things I said in my mail are valid in general, not only for the
> at803x phy.
>
> Let me repeat them once more:
>
> Preconditions:
> - Some of the devices a given driver handles have a reset line and
> others don't.
> - A non-empty subset (maybe all) of the devices that have a reset line
> require that this reset line is used.
>
> Then the way to handle this in the driver should be done as follows:
>
> unless reset_handling_not_necessary():
> gpio = gpiod_get_optional("reset")
> if IS_ERR(gpio):
> return PTR_ERR(gpio)
>
> Checking for -ENOSYS or GPIOLIB=n is not allowed because the device
> you're currently handling might need the GPIO, so you must not continue
> without the ability to control the line.
>
> So the options you have (as you have a phy that doesn't need the reset
> handling):
>
> - enable GPIOLIB (either in your .config or introduce a Kconfig
> dependency)
> - improve reset_handling_not_necessary() to return true for your case
>
I will see if I can "improve reset_handling_not_necessary() to return true".
Best regards,
Sebastian
^ permalink raw reply
* [PATCH] net: ping: make ping_v6_sendmsg static
From: Haishuang Yan @ 2016-03-23 9:59 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev, linux-kernel, Haishuang Yan
As ping_v6_sendmsg is used only in this file,
making it static
The body of "pingv6_prot" and "pingv6_protosw" were
moved at the middle of the file, to avoid having to
declare some static prototypes.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
include/net/ping.h | 1 -
net/ipv6/ping.c | 59 +++++++++++++++++++++++++++---------------------------
2 files changed, 29 insertions(+), 31 deletions(-)
diff --git a/include/net/ping.h b/include/net/ping.h
index 5fd7cc2..4cd90d6 100644
--- a/include/net/ping.h
+++ b/include/net/ping.h
@@ -79,7 +79,6 @@ int ping_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int noblock,
int flags, int *addr_len);
int ping_common_sendmsg(int family, struct msghdr *msg, size_t len,
void *user_icmph, size_t icmph_len);
-int ping_v6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len);
int ping_queue_rcv_skb(struct sock *sk, struct sk_buff *skb);
bool ping_rcv(struct sk_buff *skb);
diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c
index 263a516..c382db7 100644
--- a/net/ipv6/ping.c
+++ b/net/ipv6/ping.c
@@ -26,35 +26,6 @@
#include <net/transp_v6.h>
#include <net/ping.h>
-struct proto pingv6_prot = {
- .name = "PINGv6",
- .owner = THIS_MODULE,
- .init = ping_init_sock,
- .close = ping_close,
- .connect = ip6_datagram_connect_v6_only,
- .disconnect = udp_disconnect,
- .setsockopt = ipv6_setsockopt,
- .getsockopt = ipv6_getsockopt,
- .sendmsg = ping_v6_sendmsg,
- .recvmsg = ping_recvmsg,
- .bind = ping_bind,
- .backlog_rcv = ping_queue_rcv_skb,
- .hash = ping_hash,
- .unhash = ping_unhash,
- .get_port = ping_get_port,
- .obj_size = sizeof(struct raw6_sock),
-};
-EXPORT_SYMBOL_GPL(pingv6_prot);
-
-static struct inet_protosw pingv6_protosw = {
- .type = SOCK_DGRAM,
- .protocol = IPPROTO_ICMPV6,
- .prot = &pingv6_prot,
- .ops = &inet6_dgram_ops,
- .flags = INET_PROTOSW_REUSE,
-};
-
-
/* Compatibility glue so we can support IPv6 when it's compiled as a module */
static int dummy_ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len,
int *addr_len)
@@ -77,7 +48,7 @@ static int dummy_ipv6_chk_addr(struct net *net, const struct in6_addr *addr,
return 0;
}
-int ping_v6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
+static int ping_v6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
{
struct inet_sock *inet = inet_sk(sk);
struct ipv6_pinfo *np = inet6_sk(sk);
@@ -192,6 +163,34 @@ int ping_v6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
return len;
}
+struct proto pingv6_prot = {
+ .name = "PINGv6",
+ .owner = THIS_MODULE,
+ .init = ping_init_sock,
+ .close = ping_close,
+ .connect = ip6_datagram_connect_v6_only,
+ .disconnect = udp_disconnect,
+ .setsockopt = ipv6_setsockopt,
+ .getsockopt = ipv6_getsockopt,
+ .sendmsg = ping_v6_sendmsg,
+ .recvmsg = ping_recvmsg,
+ .bind = ping_bind,
+ .backlog_rcv = ping_queue_rcv_skb,
+ .hash = ping_hash,
+ .unhash = ping_unhash,
+ .get_port = ping_get_port,
+ .obj_size = sizeof(struct raw6_sock),
+};
+EXPORT_SYMBOL_GPL(pingv6_prot);
+
+static struct inet_protosw pingv6_protosw = {
+ .type = SOCK_DGRAM,
+ .protocol = IPPROTO_ICMPV6,
+ .prot = &pingv6_prot,
+ .ops = &inet6_dgram_ops,
+ .flags = INET_PROTOSW_REUSE,
+};
+
#ifdef CONFIG_PROC_FS
static void *ping_v6_seq_start(struct seq_file *seq, loff_t *pos)
{
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net: mediatek: fix checking for NULL instead of IS_ERR() in .probe
From: John Crispin @ 2016-03-23 9:07 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Matthias Brugger, David S. Miller, Felix Fietkau, netdev,
linux-mediatek, linux-arm-kernel
In-Reply-To: <56F25B42.5030005@gmail.com>
On 23/03/2016 10:00, Matthias Brugger wrote:
>
>
> On 23/03/16 00:06, Vladimir Zapolskiy wrote:
>> devm_ioremap_resource() returns ERR_PTR() value on error, it never
>> returns NULL, fix it and propagate the returned error upwards.
>>
>> Fixes: 656e705243fd ("net-next: mediatek: add support for MT7623
>> ethernet")
>> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
>> ---
>
> Reviewed-by: Matthias Brugger <mbrugger@suse.com>
>
Acked-by: John Crispin <blogic@openwrt.org>
Thanks for the fix !
>> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> index 7f2126b..e0b68af 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> @@ -1690,8 +1690,8 @@ static int mtk_probe(struct platform_device *pdev)
>> return -ENOMEM;
>>
>> eth->base = devm_ioremap_resource(&pdev->dev, res);
>> - if (!eth->base)
>> - return -EADDRNOTAVAIL;
>> + if (IS_ERR(eth->base))
>> + return PTR_ERR(eth->base);
>>
>> spin_lock_init(ð->page_lock);
>>
>>
^ permalink raw reply
* Re: [PATCH] net: mediatek: fix checking for NULL instead of IS_ERR() in .probe
From: Matthias Brugger @ 2016-03-23 9:00 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S. Miller, Felix Fietkau, John Crispin
Cc: netdev, linux-mediatek, linux-arm-kernel
In-Reply-To: <1458687964-9690-1-git-send-email-vz@mleia.com>
On 23/03/16 00:06, Vladimir Zapolskiy wrote:
> devm_ioremap_resource() returns ERR_PTR() value on error, it never
> returns NULL, fix it and propagate the returned error upwards.
>
> Fixes: 656e705243fd ("net-next: mediatek: add support for MT7623 ethernet")
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 7f2126b..e0b68af 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -1690,8 +1690,8 @@ static int mtk_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> eth->base = devm_ioremap_resource(&pdev->dev, res);
> - if (!eth->base)
> - return -EADDRNOTAVAIL;
> + if (IS_ERR(eth->base))
> + return PTR_ERR(eth->base);
>
> spin_lock_init(ð->page_lock);
>
>
^ permalink raw reply
* Re: [PATCH] macb: fix PHY reset
From: Nicolas Ferre @ 2016-03-23 8:54 UTC (permalink / raw)
To: Sergei Shtylyov, David Miller; +Cc: netdev
In-Reply-To: <56F1BA16.9070601@cogentembedded.com>
Le 22/03/2016 22:33, Sergei Shtylyov a écrit :
> On 03/22/2016 11:07 PM, David Miller wrote:
>
>>> On 03/22/2016 10:27 PM, Sergei Shtylyov wrote:
>>>
>>>> The driver calls gpiod_set_value() with GPIOD_OUT_* instead of 0 and
>>>> 1, as
>>>> a result the PHY isn't really put back into reset state in
>>>> macb_remove().
>>>> Moreover, the driver assumes that something else has set the GPIO
>>>> direction
>>>> to output, so if it has not, the PHY wouldn't be taken out of reset in
>>>
>>> s/wouldn't/may not/, sorry. Do I need to resend?
>>
>> No need, I fixed it up by hand.
>>
>> Applied, thanks.
>
> Oops, forgot another tag:
>
> Fixes: 270c499f0993 ("net/macb: Update device tree binding for resetting PHY
> using GPIO")
>
> Too late probably... :-(
Too late also:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks Sergei!
Bye,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v3] iwlwifi: dvm: use alloc_ordered_workqueue()
From: Grumbach, Emmanuel @ 2016-03-23 8:33 UTC (permalink / raw)
To: Eva Rachel Retuya, outreachy-kernel@googlegroups.com
Cc: Berg, Johannes, linuxwifi, kvalo@codeaurora.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, tj@kernel.org
In-Reply-To: <1458364547-11621-1-git-send-email-eraretuya@gmail.com>
On 03/19/2016 07:15 AM, Eva Rachel Retuya wrote:
> Use alloc_ordered_workqueue() to allocate the workqueue instead of
> create_singlethread_workqueue() since the latter is deprecated and is scheduled
> for removal.
>
> There are work items doing related operations that shouldn't be swapped when
> queued in a certain order hence preserve the strict execution ordering of a
> single threaded (ST) workqueue by switching to alloc_ordered_workqueue().
>
> WQ_MEM_RECLAIM flag is not needed since the worker is not depended
> during memory reclaim.
>
> Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
> Acked-by: Tejun Heo <tj@kernel.org>
> ---
Applied - thanks.
^ permalink raw reply
* Re: [PATCH] at803x: fix reset handling
From: Uwe Kleine-König @ 2016-03-23 6:45 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, f.fainelli, Daniel Mack
In-Reply-To: <1525241.UQIRf9ZOB3@wasted.cogentembedded.com>
Hello,
I added the author of 13a56b449325 to Cc.
On Wed, Mar 23, 2016 at 12:44:40AM +0300, Sergei Shtylyov wrote:
> The driver of course "knows" that the chip's reset signal is active low,
> so it drives the GPIO to 0 to reset the PHY and to 1 otherwise; however
> all this will only work iff the GPIO is specified as active-high in the
> device tree! I think both the driver and the device trees (if there are
> any -- I was unable to find them) need to be fixed in this case...
>
> Fixes: 13a56b449325 ("net: phy: at803x: Add support for hardware reset")
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> The patch is against DaveM's 'net.git' repo.
Don't you need to work against net-next for non-urgent stuff? Or do you
consider this urgent?
> drivers/net/phy/at803x.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: net/drivers/net/phy/at803x.c
> ===================================================================
> --- net.orig/drivers/net/phy/at803x.c
> +++ net/drivers/net/phy/at803x.c
> @@ -277,7 +277,7 @@ static int at803x_probe(struct phy_devic
> if (!priv)
> return -ENOMEM;
>
> - gpiod_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> + gpiod_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> if (IS_ERR(gpiod_reset))
> return PTR_ERR(gpiod_reset);
>
> @@ -362,10 +362,10 @@ static void at803x_link_change_notify(st
>
> at803x_context_save(phydev, &context);
>
> - gpiod_set_value(priv->gpiod_reset, 0);
> - msleep(1);
> gpiod_set_value(priv->gpiod_reset, 1);
> msleep(1);
> + gpiod_set_value(priv->gpiod_reset, 0);
> + msleep(1);
The new variant is better than the old one. The change however breaks
existing device trees which is not so nice. Given there are no mainline
users this is probably ok though. So:
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] vlan: propagate gso_min_segs
From: Eric Dumazet @ 2016-03-23 2:33 UTC (permalink / raw)
To: Haishuang Yan
Cc: Patrick McHardy, David S. Miller, Nicolas Dichtel, netdev,
linux-kernel
In-Reply-To: <1458696914-16088-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
On Wed, 2016-03-23 at 09:35 +0800, Haishuang Yan wrote:
> vlan drivers lack proper propagation of gso_min_segs from lower device.
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
> ---
The plan was to get rid of gso_min_segs, as nothing uses it.
Otherwise I would have included this in my recent patches...
For such a rare 'issue' , we believe ndo_features_check() is better,
because it does not slow down the fast path.
Thanks.
^ permalink raw reply
* [PATCH] vlan: propagate gso_min_segs
From: Haishuang Yan @ 2016-03-23 1:35 UTC (permalink / raw)
To: Patrick McHardy, David S. Miller, Nicolas Dichtel
Cc: netdev, linux-kernel, Haishuang Yan
vlan drivers lack proper propagation of gso_min_segs from lower device.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
drivers/net/ipvlan/ipvlan_main.c | 2 ++
drivers/net/macvlan.c | 1 +
net/8021q/vlan.c | 1 +
net/8021q/vlan_dev.c | 1 +
4 files changed, 5 insertions(+)
diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index 57941d3..72a2517 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -120,6 +120,7 @@ static int ipvlan_init(struct net_device *dev)
dev->features |= NETIF_F_LLTX;
dev->gso_max_size = phy_dev->gso_max_size;
dev->gso_max_segs = phy_dev->gso_max_segs;
+ dev->gso_min_segs = phy_dev->gso_min_segs;
dev->hard_header_len = phy_dev->hard_header_len;
ipvlan_set_lockdep_class(dev);
@@ -594,6 +595,7 @@ static int ipvlan_device_event(struct notifier_block *unused,
ipvlan->dev->features = dev->features & IPVLAN_FEATURES;
ipvlan->dev->gso_max_size = dev->gso_max_size;
ipvlan->dev->gso_max_segs = dev->gso_max_segs;
+ ipvlan->dev->gso_min_segs = dev->gso_min_segs;
netdev_features_change(ipvlan->dev);
}
break;
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 2bcf1f3..72991e9 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -1534,6 +1534,7 @@ static int macvlan_device_event(struct notifier_block *unused,
list_for_each_entry(vlan, &port->vlans, list) {
vlan->dev->gso_max_size = dev->gso_max_size;
vlan->dev->gso_max_segs = dev->gso_max_segs;
+ vlan->dev->gso_min_segs = dev->gso_min_segs;
netdev_update_features(vlan->dev);
}
break;
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index a1e273a..01a4de1 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -312,6 +312,7 @@ static void vlan_transfer_features(struct net_device *dev,
vlandev->gso_max_size = dev->gso_max_size;
vlandev->gso_max_segs = dev->gso_max_segs;
+ vlandev->gso_min_segs = dev->gso_min_segs;
if (vlan_hw_offload_capable(dev->features, vlan->vlan_proto))
vlandev->hard_header_len = dev->hard_header_len;
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index e7e6257..752263d 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -552,6 +552,7 @@ static int vlan_dev_init(struct net_device *dev)
NETIF_F_GSO_SOFTWARE;
dev->gso_max_size = real_dev->gso_max_size;
dev->gso_max_segs = real_dev->gso_max_segs;
+ dev->gso_min_segs = real_dev->gso_min_segs;
if (dev->features & NETIF_F_VLAN_FEATURES)
netdev_warn(real_dev, "VLAN features are set incorrectly. Q-in-Q configurations may not work correctly.\n");
--
1.8.3.1
^ permalink raw reply related
* [PATCH] gre: fix return value of gre_rcv
From: Haishuang Yan @ 2016-03-23 1:34 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris, Patrick McHardy
Cc: netdev, linux-kernel, Haishuang Yan
Dropped skb's should be documented by an appropriate return value.
Use the correct NET_RX_DROP and NET_RX_SUCCESS values for that reason.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/ipv4/ip_gre.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 31936d3..1dc0cdb 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -432,12 +432,12 @@ static int gre_rcv(struct sk_buff *skb)
goto drop;
if (ipgre_rcv(skb, &tpi) == PACKET_RCVD)
- return 0;
+ return NET_RX_SUCCESS;
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
drop:
kfree_skb(skb);
- return 0;
+ return NET_RX_DROP;
}
static __sum16 gre_checksum(struct sk_buff *skb)
--
1.8.3.1
^ 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