* [PATCH net-next v3 1/3] net: ethernet: mediatek: get the chip id by ETHDMASYS registers
From: Nelson Chang @ 2016-10-06 11:44 UTC (permalink / raw)
To: john-Pj+rj9U5foFAfugRpC6u6w, davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, nbd-p3rKhJxN3npAfugRpC6u6w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nelsonch.tw-Re5JQEeQqe8AvxtiuMwx3w, Nelson Chang
In-Reply-To: <1475754243-12557-1-git-send-email-nelson.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7 registers
in mtk_probe().
Signed-off-by: Nelson Chang <nelson.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 29 +++++++++++++++++++++++++++++
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 5 +++++
2 files changed, 34 insertions(+)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ad4ab97..0c67ab1 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2323,6 +2323,31 @@ free_netdev:
return err;
}
+static int mtk_get_chip_id(struct mtk_eth *eth, u32 *chip_id)
+{
+ u32 val[2], id[4];
+
+ regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, &val[0]);
+ regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, &val[1]);
+
+ id[3] = ((val[0] >> 16) & 0xff) - '0';
+ id[2] = ((val[0] >> 24) & 0xff) - '0';
+ id[1] = (val[1] & 0xff) - '0';
+ id[0] = ((val[1] >> 8) & 0xff) - '0';
+
+ *chip_id = (id[3] * 1000) + (id[2] * 100) +
+ (id[1] * 10) + id[0];
+
+ if (!(*chip_id)) {
+ dev_err(eth->dev, "failed to get chip id\n");
+ return -ENODEV;
+ }
+
+ dev_info(eth->dev, "chip id = %d\n", *chip_id);
+
+ return 0;
+}
+
static int mtk_probe(struct platform_device *pdev)
{
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -2388,6 +2413,10 @@ static int mtk_probe(struct platform_device *pdev)
if (err)
return err;
+ err = mtk_get_chip_id(eth, ð->chip_id);
+ if (err)
+ return err;
+
for_each_child_of_node(pdev->dev.of_node, mac_np) {
if (!of_device_is_compatible(mac_np,
"mediatek,eth-mac"))
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 3003195..a5b422b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -342,6 +342,10 @@
#define GPIO_BIAS_CTRL 0xed0
#define GPIO_DRV_SEL10 0xf00
+/* ethernet subsystem chip id register */
+#define ETHSYS_CHIPID0_3 0x0
+#define ETHSYS_CHIPID4_7 0x4
+
/* ethernet subsystem config register */
#define ETHSYS_SYSCFG0 0x14
#define SYSCFG0_GE_MASK 0x3
@@ -534,6 +538,7 @@ struct mtk_eth {
unsigned long sysclk;
struct regmap *ethsys;
struct regmap *pctl;
+ u32 chip_id;
bool hwlro;
atomic_t dma_refcnt;
struct mtk_tx_ring tx_ring;
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v3 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi
From: Nelson Chang @ 2016-10-06 11:44 UTC (permalink / raw)
To: john-Pj+rj9U5foFAfugRpC6u6w, davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, nbd-p3rKhJxN3npAfugRpC6u6w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nelsonch.tw-Re5JQEeQqe8AvxtiuMwx3w, Nelson Chang
In-Reply-To: <1475754243-12557-1-git-send-email-nelson.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Because hw lro started to be supported from MT7623, the proper way to check if
the feature is capable is to judge by the chip id instead of by the dtsi.
Signed-off-by: Nelson Chang <nelson.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 14 ++++++++++++--
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 0c67ab1..4a62ffd 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2348,6 +2348,16 @@ static int mtk_get_chip_id(struct mtk_eth *eth, u32 *chip_id)
return 0;
}
+static bool mtk_is_hwlro_supported(struct mtk_eth *eth)
+{
+ switch (eth->chip_id) {
+ case MT7623_ETH:
+ return true;
+ }
+
+ return false;
+}
+
static int mtk_probe(struct platform_device *pdev)
{
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -2387,8 +2397,6 @@ static int mtk_probe(struct platform_device *pdev)
return PTR_ERR(eth->pctl);
}
- eth->hwlro = of_property_read_bool(pdev->dev.of_node, "mediatek,hwlro");
-
for (i = 0; i < 3; i++) {
eth->irq[i] = platform_get_irq(pdev, i);
if (eth->irq[i] < 0) {
@@ -2417,6 +2425,8 @@ static int mtk_probe(struct platform_device *pdev)
if (err)
return err;
+ eth->hwlro = mtk_is_hwlro_supported(eth);
+
for_each_child_of_node(pdev->dev.of_node, mac_np) {
if (!of_device_is_compatible(mac_np,
"mediatek,eth-mac"))
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index a5b422b..99b1c8e 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -345,6 +345,7 @@
/* ethernet subsystem chip id register */
#define ETHSYS_CHIPID0_3 0x0
#define ETHSYS_CHIPID4_7 0x4
+#define MT7623_ETH 7623
/* ethernet subsystem config register */
#define ETHSYS_SYSCFG0 0x14
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v3 3/3] net: ethernet: mediatek: remove hwlro property in the device tree
From: Nelson Chang @ 2016-10-06 11:44 UTC (permalink / raw)
To: john-Pj+rj9U5foFAfugRpC6u6w, davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, nbd-p3rKhJxN3npAfugRpC6u6w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nelsonch.tw-Re5JQEeQqe8AvxtiuMwx3w, Nelson Chang
In-Reply-To: <1475754243-12557-1-git-send-email-nelson.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Since the proper way to check the hw lro capability is by the chip id,
hwlro property in the device tree should be removed.
Signed-off-by: Nelson Chang <nelson.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
Documentation/devicetree/bindings/net/mediatek-net.txt | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
index f095257..c010faf 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -24,7 +24,6 @@ Required properties:
Optional properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
-- mediatek,hwlro: the capability if the hardware supports LRO functions
* Ethernet MAC node
@@ -54,7 +53,6 @@ eth: ethernet@1b100000 {
reset-names = "eth";
mediatek,ethsys = <ðsys>;
mediatek,pctl = <&syscfg_pctl_a>;
- mediatek,hwlro;
#address-cells = <1>;
#size-cells = <0>;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 3/3] mac80211: multicast to unicast conversion
From: michael-dev @ 2016-10-06 11:53 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
projekt-wlan-3kN+8DYepx7zMJDuovMtMLNAH6kLmebB, netdev
In-Reply-To: <1475668688.4994.46.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Am 05.10.2016 13:58, schrieb Johannes Berg:
>
> Anyway, perhaps this needs to change to take DMS/per-station into
> account?
>
> Then again, this kind of setting - global multicast-to-unicast -
> fundamentally *cannot* be done on a per-station basis, since if you
> enable it for one station and not for another, the first station that
> has it enabled would get the packets twice...
as I see it, that is exactly how DMS is standarized.
IEEE 802.11-2012 section 10.23.15 DMS procedures:
"If the requested DMS is accepted by the AP, the AP shall send
subsequent group addressed MSDUs that
match the frame classifier specified in the DMS Descriptors to the
requesting STA as A-MSDU subframes
within an individually addressed A-MSDU frame (see 8.3.2.2 and 9.11)."
-> so the multicast packets shall go out as unicast A-MSDU frames to
stations that requested this
"The AP shall continue to transmit the matching frames as group
addressed frames (see 9.3.6, and 10.2.1.16) if at least one associated
STA has not requested DMS for these frames."
-> so it will continue to send it as multicast frames as well.
As with DMS the station requested DMS for a specific multicast address,
it could then drop multicast frames addressed to the multicast address
it registered for DMS.
Regards,
M. Braun
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: multicast to unicast conversion
From: Johannes Berg @ 2016-10-06 11:55 UTC (permalink / raw)
To: michael-dev; +Cc: linux-wireless, projekt-wlan, netdev
In-Reply-To: <199ae52e4e3000456d8d65b81500d874@fami-braun.de>
On Thu, 2016-10-06 at 13:53 +0200, michael-dev wrote:
> Am 05.10.2016 13:58, schrieb Johannes Berg:
> >
> >
> > Anyway, perhaps this needs to change to take DMS/per-station into
> > account?
> >
> > Then again, this kind of setting - global multicast-to-unicast -
> > fundamentally *cannot* be done on a per-station basis, since if you
> > enable it for one station and not for another, the first station
> > that has it enabled would get the packets twice...
>
> as I see it, that is exactly how DMS is standarized.
>
> IEEE 802.11-2012 section 10.23.15 DMS procedures:
>
> "If the requested DMS is accepted by the AP, the AP shall send
> subsequent group addressed MSDUs that
> match the frame classifier specified in the DMS Descriptors to the
> requesting STA as A-MSDU subframes
> within an individually addressed A-MSDU frame (see 8.3.2.2 and
> 9.11)."
>
> -> so the multicast packets shall go out as unicast A-MSDU frames
> to stations that requested this
Correct.
> "The AP shall continue to transmit the matching frames as group
> addressed frames (see 9.3.6, and 10.2.1.16) if at least one
> associated
> STA has not requested DMS for these frames."
>
> -> so it will continue to send it as multicast frames as well.
>
> As with DMS the station requested DMS for a specific multicast
> address, it could then drop multicast frames addressed to the
> multicast address it registered for DMS.
Yes, the DMS spec tells it to do this. However, we can't implement non-
DMS similarly, because then the station won't request it and won't drop
the duplicates.
So for this non-standard multicast-to-unicast, it's all or nothing, it
can't be done for some stations only.
johannes
^ permalink raw reply
* web.upgrades
From: Sistemas administrador @ 2016-10-06 12:16 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que
vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación:666690opp4r56 es: 006524
Correo Soporte Técnico © 2016
¡gracias
Sistemas administrador
^ permalink raw reply
* RE: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel
From: David Laight @ 2016-10-06 13:00 UTC (permalink / raw)
To: 'Joe Perches', Pavel Machek
Cc: Marcel Holtmann, trivial@kernel.org, Gustavo F. Padovan,
Johan Hedberg, David S. Miller, linux-bluetooth@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1475753929.1914.2.camel@perches.com>
From: Joe Perches
> Sent: 06 October 2016 12:39
> On Thu, 2016-10-06 at 09:41 +0000, David Laight wrote:
> > From: Joe Perches
> > > No worries, and bool is the same ,size as u8.
> > That is not guaranteed at all.
> > One of the ARM ABI defined bool to be the size of int.
>
> Really? What kernel has sizeof(_Bool) != 1 ?
Probably none, but I know systems have used larger bool.
I found this:
> with egcs-2.90.29 980515 (egcs-1.0.3 release) on alphaev56-dec-osf4.0d
> bool = 8
> short = 2
> int = 4
> long = 8
I'm pretty sure something newer than an old alpha ABI used 4 byte bool.
David
^ permalink raw reply
* Re: [PATCH v3 net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Shmulik Ladkani @ 2016-10-06 13:30 UTC (permalink / raw)
To: Cong Wang, David Miller
Cc: Jamal Hadi Salim, Eric Dumazet, Daniel Borkmann,
Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <CAM_iQpWwPqbiJ7tjbHqvYfyRL5fh+oXGVFFPmW3wLUCGbK-b4Q@mail.gmail.com>
Hi,
On Mon, Oct 3, 2016 at 12:45 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Sep 29, 2016 at 4:03 AM, Shmulik Ladkani
> <shmulik.ladkani@gmail.com> wrote:
>> skb2->skb_iif = skb->dev->ifindex;
>> skb2->dev = dev;
>> - err = dev_queue_xmit(skb2);
>> + if (tcf_mirred_act_direction(m_eaction) & AT_EGRESS)
>> + err = dev_queue_xmit(skb2);
>> + else
>> + netif_receive_skb(skb2);
>
> Any reason why not check the return value here?
Rationale: netif_receive_skb returns err if there was no protocol
handler to deliver the skb to.
If skb is not caught by any protocol handler, this should not be
considered an "ingress redirect" error. The redirect action should be
considered successful.
^ permalink raw reply
* Re: [PATCH net-next 11/14] rxrpc: Make rxrpc_send_packet() take a connection not a transport [ver #2]
From: Geert Uytterhoeven @ 2016-10-06 13:34 UTC (permalink / raw)
To: David Howells
Cc: David S. Miller, netdev@vger.kernel.org, linux-afs,
linux-kernel@vger.kernel.org
In-Reply-To: <146661145065.15011.7115489407328614610.stgit@warthog.procyon.org.uk>
Hi David,
On Wed, Jun 22, 2016 at 6:04 PM, David Howells <dhowells@redhat.com> wrote:
> Make rxrpc_send_packet() take a connection not a transport as part of the
> phasing out of the rxrpc_transport struct.
>
> Whilst we're at it, rename the function to rxrpc_send_data_packet() to
> differentiate it from the other packet sending functions.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
This is now upstream commit 985a5c824a52e9f7
> --- a/net/rxrpc/output.c
> +++ b/net/rxrpc/output.c
> @@ -338,7 +338,7 @@ EXPORT_SYMBOL(rxrpc_kernel_abort_call);
> /*
> * send a packet through the transport endpoint
> */
> -int rxrpc_send_packet(struct rxrpc_transport *trans, struct sk_buff *skb)
> +int rxrpc_send_data_packet(struct rxrpc_connection *conn, struct sk_buff *skb)
> {
> struct kvec iov[1];
> struct msghdr msg;
> @@ -349,30 +349,30 @@ int rxrpc_send_packet(struct rxrpc_transport *trans, struct sk_buff *skb)
net/rxrpc/output.c: In function ‘rxrpc_send_data_packet’:
net/rxrpc/output.c:252: warning: ‘ret’ may be used uninitialized in
this function
(line number is from current mainline)
> iov[0].iov_base = skb->head;
> iov[0].iov_len = skb->len;
>
> - msg.msg_name = &trans->peer->srx.transport.sin;
> - msg.msg_namelen = sizeof(trans->peer->srx.transport.sin);
> + msg.msg_name = &conn->params.peer->srx.transport;
> + msg.msg_namelen = conn->params.peer->srx.transport_len;
> msg.msg_control = NULL;
> msg.msg_controllen = 0;
> msg.msg_flags = 0;
>
> /* send the packet with the don't fragment bit set if we currently
> * think it's small enough */
> - if (skb->len - sizeof(struct rxrpc_wire_header) < trans->peer->maxdata) {
> - down_read(&trans->local->defrag_sem);
> + if (skb->len - sizeof(struct rxrpc_wire_header) < conn->params.peer->maxdata) {
> + down_read(&conn->params.local->defrag_sem);
If this branch is not taken...
> /* send the packet by UDP
> * - returns -EMSGSIZE if UDP would have to fragment the packet
> * to go out of the interface
> * - in which case, we'll have processed the ICMP error
> * message and update the peer record
> */
> - ret = kernel_sendmsg(trans->local->socket, &msg, iov, 1,
> + ret = kernel_sendmsg(conn->params.local->socket, &msg, iov, 1,
> iov[0].iov_len);
>
> - up_read(&trans->local->defrag_sem);
> + up_read(&conn->params.local->defrag_sem);
> if (ret == -EMSGSIZE)
> goto send_fragmentable;
>
> - _leave(" = %d [%u]", ret, trans->peer->maxdata);
> + _leave(" = %d [%u]", ret, conn->params.peer->maxdata);
> return ret;
> }
>
> @@ -380,21 +380,28 @@ send_fragmentable:
> /* attempt to send this message with fragmentation enabled */
> _debug("send fragment");
>
> - down_write(&trans->local->defrag_sem);
> - opt = IP_PMTUDISC_DONT;
> - ret = kernel_setsockopt(trans->local->socket, SOL_IP, IP_MTU_DISCOVER,
> - (char *) &opt, sizeof(opt));
> - if (ret == 0) {
> - ret = kernel_sendmsg(trans->local->socket, &msg, iov, 1,
> - iov[0].iov_len);
> -
> - opt = IP_PMTUDISC_DO;
> - kernel_setsockopt(trans->local->socket, SOL_IP,
> - IP_MTU_DISCOVER, (char *) &opt, sizeof(opt));
> + down_write(&conn->params.local->defrag_sem);
> +
> + switch (conn->params.local->srx.transport.family) {
> + case AF_INET:
> + opt = IP_PMTUDISC_DONT;
> + ret = kernel_setsockopt(conn->params.local->socket,
> + SOL_IP, IP_MTU_DISCOVER,
> + (char *)&opt, sizeof(opt));
> + if (ret == 0) {
> + ret = kernel_sendmsg(conn->params.local->socket, &msg, iov, 1,
> + iov[0].iov_len);
> +
> + opt = IP_PMTUDISC_DO;
> + kernel_setsockopt(conn->params.local->socket, SOL_IP,
> + IP_MTU_DISCOVER,
> + (char *)&opt, sizeof(opt));
> + }
> + break;
... and none of the cases (current upstream also has AF_INET6 if
CONFIG_AF_RXRPC_IPV6 is enabled) match ...
> }
>
> - up_write(&trans->local->defrag_sem);
> - _leave(" = %d [frag %u]", ret, trans->peer->maxdata);
> + up_write(&conn->params.local->defrag_sem);
> + _leave(" = %d [frag %u]", ret, conn->params.peer->maxdata);
> return ret;
... then ret is not initialized.
I didn't create a patch, as I'm not sure this is a false positive or not.
Is it possible that none of the cases match?
> }
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* [PATCH] netfilter: xt_hashlimit: Add missing ULL suffixes for 64-bit constants
From: Geert Uytterhoeven @ 2016-10-06 13:40 UTC (permalink / raw)
To: Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller, Vishwanath Pai, Joshua Hunt
Cc: netfilter-devel, coreteam, netdev, linux-kernel,
Geert Uytterhoeven
On 32-bit (e.g. with m68k-linux-gnu-gcc-4.1):
net/netfilter/xt_hashlimit.c: In function ‘user2credits’:
net/netfilter/xt_hashlimit.c:476: warning: integer constant is too large for ‘long’ type
...
net/netfilter/xt_hashlimit.c:478: warning: integer constant is too large for ‘long’ type
...
net/netfilter/xt_hashlimit.c:480: warning: integer constant is too large for ‘long’ type
...
net/netfilter/xt_hashlimit.c: In function ‘rateinfo_recalc’:
net/netfilter/xt_hashlimit.c:513: warning: integer constant is too large for ‘long’ type
Fixes: 11d5f15723c9f39d ("netfilter: xt_hashlimit: Create revision 2 to support higher pps rates")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
net/netfilter/xt_hashlimit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 2fab0c65aa94b666..b89b688e9d01a2d1 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -431,7 +431,7 @@ static void htable_put(struct xt_hashlimit_htable *hinfo)
CREDITS_PER_JIFFY*HZ*60*60*24 < 2^32 ie.
*/
#define MAX_CPJ_v1 (0xFFFFFFFF / (HZ*60*60*24))
-#define MAX_CPJ (0xFFFFFFFFFFFFFFFF / (HZ*60*60*24))
+#define MAX_CPJ (0xFFFFFFFFFFFFFFFFULL / (HZ*60*60*24))
/* Repeated shift and or gives us all 1s, final shift and add 1 gives
* us the power of 2 below the theoretical max, so GCC simply does a
@@ -473,7 +473,7 @@ static u64 user2credits(u64 user, int revision)
return div64_u64(user * HZ * CREDITS_PER_JIFFY_v1,
XT_HASHLIMIT_SCALE);
} else {
- if (user > 0xFFFFFFFFFFFFFFFF / (HZ*CREDITS_PER_JIFFY))
+ if (user > 0xFFFFFFFFFFFFFFFFULL / (HZ*CREDITS_PER_JIFFY))
return div64_u64(user, XT_HASHLIMIT_SCALE_v2)
* HZ * CREDITS_PER_JIFFY;
--
1.9.1
^ permalink raw reply related
* [PATCH] strparser: Propagate correct error code in strp_recv()
From: Geert Uytterhoeven @ 2016-10-06 13:41 UTC (permalink / raw)
To: David S. Miller, Tom Herbert; +Cc: netdev, linux-kernel, Geert Uytterhoeven
With m68k-linux-gnu-gcc-4.1:
net/strparser/strparser.c: In function ‘strp_recv’:
net/strparser/strparser.c:98: warning: ‘err’ may be used uninitialized in this function
Pass "len" (which is an error code when negative) instead of the
uninitialized "err" variable to fix this.
Fixes: 43a0c6751a322847 ("strparser: Stream parser for messages")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
Compile-tested only.
---
net/strparser/strparser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/strparser/strparser.c b/net/strparser/strparser.c
index 5c7549b5b92cd23c..41adf362936d7dc4 100644
--- a/net/strparser/strparser.c
+++ b/net/strparser/strparser.c
@@ -246,7 +246,7 @@ static int strp_recv(read_descriptor_t *desc, struct sk_buff *orig_skb,
} else {
strp->rx_interrupted = 1;
}
- strp_parser_err(strp, err, desc);
+ strp_parser_err(strp, len, desc);
break;
} else if (len > strp->sk->sk_rcvbuf) {
/* Message length exceeds maximum allowed */
--
1.9.1
^ permalink raw reply related
* Re: 4.9-rc0: nf_hooks_ingress missing, breaking compilation
From: Aaron Conole @ 2016-10-06 13:54 UTC (permalink / raw)
To: Pavel Machek; +Cc: kernel list, Netdev list, pablo
In-Reply-To: <20161006065844.GA27024@amd>
Pavel Machek <pavel@ucw.cz> writes:
> Hi!
Hi Pavel,
> In kernel based on edadd0e, I get plenty of errors such as:
In this case, I screwed up - sincere apologies.
Enabling CONFIG_NETFILTER_INGRESS will work around this error for the
time being, while the fix makes it way through the various trees.
> net/netfilter/core.c:96:3: note: in expansion of macro ‘rcu_assign_pointer’
> rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry);
> ^
> In file included from ./include/linux/linkage.h:4:0,
> from ./include/linux/kernel.h:6,
> from net/netfilter/core.c:10:
> net/netfilter/core.c:96:30: error: ‘struct net_device’ has no member named ‘nf_hooks_ingress’
> rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry);
> ^
>
> Config is attached.
>
> [Ok, I guess testing -rc0 is "a bit too brave" :-)]
>
> Best regards,
> Pavel
^ permalink raw reply
* [PATCH] ethernet: qualcomm: QCOM_EMAC should depend on HAS_DMA
From: Geert Uytterhoeven @ 2016-10-06 13:57 UTC (permalink / raw)
To: David S. Miller, Timur Tabi; +Cc: netdev, linux-kernel, Geert Uytterhoeven
If NO_DMA=y:
drivers/built-in.o: In function `emac_probe':
emac.c:(.text+0x3780b8): undefined reference to `bad_dma_ops'
emac.c:(.text+0x3780e2): undefined reference to `bad_dma_ops'
emac.c:(.text+0x378112): undefined reference to `bad_dma_ops'
emac.c:(.text+0x378146): undefined reference to `bad_dma_ops'
emac.c:(.text+0x37816e): undefined reference to `bad_dma_ops'
drivers/built-in.o:emac.c:(.text+0x37819a): more undefined references to `bad_dma_ops' follow
Add a dependency on HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/net/ethernet/qualcomm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/qualcomm/Kconfig b/drivers/net/ethernet/qualcomm/Kconfig
index 9ba568db576fb0e6..fe94d2baeaf26aa6 100644
--- a/drivers/net/ethernet/qualcomm/Kconfig
+++ b/drivers/net/ethernet/qualcomm/Kconfig
@@ -26,6 +26,7 @@ config QCA7000
config QCOM_EMAC
tristate "Qualcomm Technologies, Inc. EMAC Gigabit Ethernet support"
+ depends on HAS_DMA
select CRC32
select PHYLIB
---help---
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] ethernet: qualcomm: QCOM_EMAC should depend on HAS_DMA
From: Timur Tabi @ 2016-10-06 14:06 UTC (permalink / raw)
To: Geert Uytterhoeven, David S. Miller; +Cc: netdev, linux-kernel
In-Reply-To: <1475762253-16759-1-git-send-email-geert@linux-m68k.org>
Geert Uytterhoeven wrote:
> config QCOM_EMAC
> tristate "Qualcomm Technologies, Inc. EMAC Gigabit Ethernet support"
> + depends on HAS_DMA
I think it needs to depend on HAS_IOMEM as well, to fix this error in
arch/um:
drivers/net/ethernet/qualcomm/emac/emac.c: In function 'emac_remove':
>> drivers/net/ethernet/qualcomm/emac/emac.c:727:3: error: implicit
declaration of function 'iounmap' [-Werror=implicit-function-declaration]
iounmap(adpt->phy.digital);
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH] ethernet: qualcomm: QCOM_EMAC should depend on HAS_DMA
From: Geert Uytterhoeven @ 2016-10-06 14:10 UTC (permalink / raw)
To: Timur Tabi
Cc: David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <57F65A73.7020701@codeaurora.org>
On Thu, Oct 6, 2016 at 4:06 PM, Timur Tabi <timur@codeaurora.org> wrote:
> Geert Uytterhoeven wrote:
>>
>> config QCOM_EMAC
>> tristate "Qualcomm Technologies, Inc. EMAC Gigabit Ethernet
>> support"
>> + depends on HAS_DMA
>
>
> I think it needs to depend on HAS_IOMEM as well, to fix this error in
> arch/um:
>
> drivers/net/ethernet/qualcomm/emac/emac.c: In function 'emac_remove':
>>> drivers/net/ethernet/qualcomm/emac/emac.c:727:3: error: implicit
>>> declaration of function 'iounmap' [-Werror=implicit-function-declaration]
> iounmap(adpt->phy.digital);
Probably, I don't do UML allmodconfig builds.
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH] ethernet: qualcomm: QCOM_EMAC should depend on HAS_DMA
From: Timur Tabi @ 2016-10-06 14:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdUGB6__ExtGTCpxOBXBG_=L9GNy1-g10VuCtqZvWRV5Tg@mail.gmail.com>
Geert Uytterhoeven wrote:
> Probably, I don't do UML allmodconfig builds.
>
> Gr{oetje,eeting}s,
Would you mind submitting another version of your patch that includes
HAS_DMA and HAS_IOMEM, so that both build breaks can be fixed in one shot?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2] ethernet: qualcomm: QCOM_EMAC should depend on HAS_DMA and HAS_IOMEM
From: Geert Uytterhoeven @ 2016-10-06 14:44 UTC (permalink / raw)
To: David S. Miller, Timur Tabi; +Cc: netdev, linux-kernel, Geert Uytterhoeven
If NO_DMA=y:
drivers/built-in.o: In function `emac_probe':
emac.c:(.text+0x3780b8): undefined reference to `bad_dma_ops'
emac.c:(.text+0x3780e2): undefined reference to `bad_dma_ops'
emac.c:(.text+0x378112): undefined reference to `bad_dma_ops'
emac.c:(.text+0x378146): undefined reference to `bad_dma_ops'
emac.c:(.text+0x37816e): undefined reference to `bad_dma_ops'
drivers/built-in.o:emac.c:(.text+0x37819a): more undefined references to `bad_dma_ops' follow
If NO_IOMEM=y:
drivers/net/ethernet/qualcomm/emac/emac.c: In function ‘emac_remove’:
drivers/net/ethernet/qualcomm/emac/emac.c:736:3: error: implicit declaration of function ‘iounmap’ [-Werror=implicit-function-declaration]
iounmap(adpt->phy.digital);
^
Add dependencies on HAS_DMA and HAS_IOMEM to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
v2:
- Add dependency on HAS_IOMEM for UML.
---
drivers/net/ethernet/qualcomm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/qualcomm/Kconfig b/drivers/net/ethernet/qualcomm/Kconfig
index 9ba568db576fb0e6..d7720bf92d49658a 100644
--- a/drivers/net/ethernet/qualcomm/Kconfig
+++ b/drivers/net/ethernet/qualcomm/Kconfig
@@ -26,6 +26,7 @@ config QCA7000
config QCOM_EMAC
tristate "Qualcomm Technologies, Inc. EMAC Gigabit Ethernet support"
+ depends on HAS_DMA && HAS_IOMEM
select CRC32
select PHYLIB
---help---
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] ethernet: qualcomm: QCOM_EMAC should depend on HAS_DMA
From: Geert Uytterhoeven @ 2016-10-06 14:45 UTC (permalink / raw)
To: Timur Tabi
Cc: David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <57F65BB3.3090602@codeaurora.org>
On Thu, Oct 6, 2016 at 4:12 PM, Timur Tabi <timur@codeaurora.org> wrote:
> Geert Uytterhoeven wrote:
>>
>> Probably, I don't do UML allmodconfig builds.
>>
>> Gr{oetje,eeting}s,
>
>
> Would you mind submitting another version of your patch that includes
> HAS_DMA and HAS_IOMEM, so that both build breaks can be fixed in one shot?
Done.
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH v2] ethernet: qualcomm: QCOM_EMAC should depend on HAS_DMA and HAS_IOMEM
From: Timur Tabi @ 2016-10-06 14:48 UTC (permalink / raw)
To: Geert Uytterhoeven, David S. Miller; +Cc: netdev, linux-kernel
In-Reply-To: <1475765093-15536-1-git-send-email-geert@linux-m68k.org>
Geert Uytterhoeven wrote:
> Add dependencies on HAS_DMA and HAS_IOMEM to fix this.
>
> Signed-off-by: Geert Uytterhoeven<geert@linux-m68k.org>
Acked-by: Timur Tabi <timur@codeaurora.org>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH net] xen-netback: make sure that hashes are not send to unaware frontends
From: Paul Durrant @ 2016-10-06 14:47 UTC (permalink / raw)
To: netdev, xen-devel; +Cc: Paul Durrant, Wei Liu
In the case when a frontend only negotiates a single queue with xen-
netback it is possible for a skbuff with a s/w hash to result in a
hash extra_info segment being sent to the frontend even when no hash
algorithm has been configured. (The ndo_select_queue() entry point makes
sure the hash is not set if no algorithm is configured, but this entry
point is not called when there is only a single queue). This can result
in a frontend that isunable to handle extra_info segments being given
such a segment, causing it to crash.
This patch fixes the problem by gating whether the extra_info is sent
not only on the presence of a s/w hash, but also on whether the hash
algorithm has been configured.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
drivers/net/xen-netback/interface.c | 13 ++-----------
drivers/net/xen-netback/netback.c | 23 ++++++++++++++---------
2 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index fb50c6d..1034139 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -149,17 +149,8 @@ static u16 xenvif_select_queue(struct net_device *dev, struct sk_buff *skb,
struct xenvif *vif = netdev_priv(dev);
unsigned int size = vif->hash.size;
- if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE) {
- u16 index = fallback(dev, skb) % dev->real_num_tx_queues;
-
- /* Make sure there is no hash information in the socket
- * buffer otherwise it would be incorrectly forwarded
- * to the frontend.
- */
- skb_clear_hash(skb);
-
- return index;
- }
+ if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE)
+ return fallback(dev, skb) % dev->real_num_tx_queues;
xenvif_set_skb_hash(vif, skb);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3d0c989..2cd4a8e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -168,6 +168,10 @@ static bool xenvif_rx_ring_slots_available(struct xenvif_queue *queue)
needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
if (skb_is_gso(skb))
needed++;
+ /* Assume the frontend is capable of handling the hash
+ * extra_info at this point. This will only ever lead to an
+ * accurate value or over-estimation.
+ */
if (skb->sw_hash)
needed++;
@@ -378,9 +382,8 @@ static void xenvif_gop_frag_copy(struct xenvif_queue *queue, struct sk_buff *skb
.npo = npo,
.head = *head,
.gso_type = XEN_NETIF_GSO_TYPE_NONE,
- /* xenvif_set_skb_hash() will have either set a s/w
- * hash or cleared the hash depending on
- * whether the the frontend wants a hash for this skb.
+ /* xenvif_rx_action() will have cleared any hash if
+ * the frontend is not capable of handling it.
*/
.hash_present = skb->sw_hash,
};
@@ -593,6 +596,14 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
&& (skb = xenvif_rx_dequeue(queue)) != NULL) {
queue->last_rx_time = jiffies;
+ /* If there is no hash algorithm configured make sure
+ * there is no hash information in the socket buffer
+ * otherwise it would be incorrectly forwarded to the
+ * frontend.
+ */
+ if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE)
+ skb_clear_hash(skb);
+
XENVIF_RX_CB(skb)->meta_slots_used = xenvif_gop_skb(skb, &npo, queue);
__skb_queue_tail(&rxq, skb);
@@ -667,12 +678,6 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
}
if (skb->sw_hash) {
- /* Since the skb got here via xenvif_select_queue()
- * we know that the hash has been re-calculated
- * according to a configuration set by the frontend
- * and therefore we know that it is legitimate to
- * pass it to the frontend.
- */
if (resp->flags & XEN_NETRXF_extra_info)
extra->flags |= XEN_NETIF_EXTRA_FLAG_MORE;
else
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel
From: Joe Perches @ 2016-10-06 15:41 UTC (permalink / raw)
To: David Laight, Pavel Machek
Cc: Marcel Holtmann, trivial@kernel.org, Gustavo F. Padovan,
Johan Hedberg, David S. Miller, linux-bluetooth@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB01E4056@AcuExch.aculab.com>
On Thu, 2016-10-06 at 13:00 +0000, David Laight wrote:
> From: Joe Perches
> > Sent: 06 October 2016 12:39
> > On Thu, 2016-10-06 at 09:41 +0000, David Laight wrote:
> > > From: Joe Perches
> > > > No worries, and bool is the same ,size as u8.
> > > That is not guaranteed at all.
> > > One of the ARM ABI defined bool to be the size of int.
> > Really? What kernel has sizeof(_Bool) != 1 ?
> Probably none, but I know systems have used larger bool.
> I found this:
> > with egcs-2.90.29 980515 (egcs-1.0.3 release) on alphaev56-dec-osf4.0d
> > bool = 8
> > short = 2
> > int = 4
> > long = 8
It's likely there are probably DSPs and old TOPS-20/CDC-6400
systems where sizeof(u16) isn't 2 as well.
I think linux isn't likely to be ported successfully to
those platforms.
No matter. If bool isn't desired because some future
expansion to this is likely and memory needs to be conserved,
fine, use a bitfield.
It can be slower than bool because it can be RMW.
cheers, Joe
^ permalink raw reply
* Duplicate MDIO_XGENE Kconfig entries
From: Laura Abbott @ 2016-10-06 16:01 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli
Cc: David S. Miller, netdev, Linux Kernel Mailing List
Hi,
While working on the Fedora tree today, I noticed that there
seem to be two entries for CONFIG_MDIO_XGENE. It looks like
this might have been fall out from d75b4a22b255 ("net: phy:
Sort Makefile and Kconfig"). I can submit the following if
this isn't fixed up elsewhere already
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 5078a0d..fe064ba 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -141,6 +141,7 @@ config MDIO_THUNDER
device.
config MDIO_XGENE
+ depends on ARCH_XGENE || COMPILE_TEST
tristate "APM X-Gene SoC MDIO bus controller"
help
This module provides a driver for the MDIO busses found in the
@@ -320,13 +321,6 @@ config XILINX_GMII2RGMII
the Reduced Gigabit Media Independent Interface(RGMII) between
Ethernet physical media devices and the Gigabit Ethernet controller.
-config MDIO_XGENE
- tristate "APM X-Gene SoC MDIO bus controller"
- depends on ARCH_XGENE || COMPILE_TEST
- help
- This module provides a driver for the MDIO busses found in the
- APM X-Gene SoC's.
-
endif # PHYLIB
config MICREL_KS8995MA
^ permalink raw reply related
* Re: Duplicate MDIO_XGENE Kconfig entries
From: Andrew Lunn @ 2016-10-06 16:37 UTC (permalink / raw)
To: Laura Abbott
Cc: Florian Fainelli, David S. Miller, netdev,
Linux Kernel Mailing List
In-Reply-To: <5fed0550-56d1-d019-86bf-2a882c0bf457@redhat.com>
On Thu, Oct 06, 2016 at 09:01:27AM -0700, Laura Abbott wrote:
> Hi,
>
> While working on the Fedora tree today, I noticed that there
> seem to be two entries for CONFIG_MDIO_XGENE. It looks like
> this might have been fall out from d75b4a22b255 ("net: phy:
> Sort Makefile and Kconfig"). I can submit the following if
> this isn't fixed up elsewhere already
Hi Laura
I don't remember seeing a fix for this going by. Please do submit a
follow up.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] netfilter: xt_hashlimit: Add missing ULL suffixes for 64-bit constants
From: Vishwanath Pai @ 2016-10-06 16:40 UTC (permalink / raw)
To: Geert Uytterhoeven, Pablo Neira Ayuso
Cc: Patrick McHardy, Jozsef Kadlecsik, David S. Miller, Joshua Hunt,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <1475761214-13387-1-git-send-email-geert@linux-m68k.org>
On 10/06/2016 09:40 AM, Geert Uytterhoeven wrote:
> diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
> index 2fab0c65aa94b666..b89b688e9d01a2d1 100644
> --- a/net/netfilter/xt_hashlimit.c
> +++ b/net/netfilter/xt_hashlimit.c
> @@ -431,7 +431,7 @@ static void htable_put(struct xt_hashlimit_htable *hinfo)
> CREDITS_PER_JIFFY*HZ*60*60*24 < 2^32 ie.
> */
> #define MAX_CPJ_v1 (0xFFFFFFFF / (HZ*60*60*24))
> -#define MAX_CPJ (0xFFFFFFFFFFFFFFFF / (HZ*60*60*24))
> +#define MAX_CPJ (0xFFFFFFFFFFFFFFFFULL / (HZ*60*60*24))
>
> /* Repeated shift and or gives us all 1s, final shift and add 1 gives
> * us the power of 2 below the theoretical max, so GCC simply does a
> @@ -473,7 +473,7 @@ static u64 user2credits(u64 user, int revision)
> return div64_u64(user * HZ * CREDITS_PER_JIFFY_v1,
> XT_HASHLIMIT_SCALE);
> } else {
> - if (user > 0xFFFFFFFFFFFFFFFF / (HZ*CREDITS_PER_JIFFY))
> + if (user > 0xFFFFFFFFFFFFFFFFULL / (HZ*CREDITS_PER_JIFFY))
> return div64_u64(user, XT_HASHLIMIT_SCALE_v2)
> * HZ * CREDITS_PER_JIFFY;
>
> -- 1.9.1
Thanks for fixing this.
Acked-by: Vishwanath Pai <vpai@akamai.com>
^ permalink raw reply
* Re: [PATCH v3 net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Cong Wang @ 2016-10-06 17:30 UTC (permalink / raw)
To: Shmulik Ladkani
Cc: David Miller, Jamal Hadi Salim, Eric Dumazet, Daniel Borkmann,
Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <CAOrmypK=TZ=cDCDwy=wJgCsMgJWaMfr5dudEwHNnQzpeYJRfHw@mail.gmail.com>
On Thu, Oct 6, 2016 at 6:30 AM, Shmulik Ladkani
<shmulik.ladkani@gmail.com> wrote:
> Hi,
>
> On Mon, Oct 3, 2016 at 12:45 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Thu, Sep 29, 2016 at 4:03 AM, Shmulik Ladkani
>> <shmulik.ladkani@gmail.com> wrote:
>>> skb2->skb_iif = skb->dev->ifindex;
>>> skb2->dev = dev;
>>> - err = dev_queue_xmit(skb2);
>>> + if (tcf_mirred_act_direction(m_eaction) & AT_EGRESS)
>>> + err = dev_queue_xmit(skb2);
>>> + else
>>> + netif_receive_skb(skb2);
>>
>> Any reason why not check the return value here?
>
> Rationale: netif_receive_skb returns err if there was no protocol
> handler to deliver the skb to.
> If skb is not caught by any protocol handler, this should not be
> considered an "ingress redirect" error. The redirect action should be
> considered successful.
A quick grep shows there are many places returning NET_RX_DROP:
E.g.
net/ipv4/arp.c: return NET_RX_DROP;
net/ipv4/arp.c: return NET_RX_DROP;
net/ipv4/gre_demux.c: return NET_RX_DROP;
net/ipv4/ip_forward.c: return NET_RX_DROP;
net/ipv4/ip_input.c: return NET_RX_DROP;
net/ipv4/ip_input.c: return NET_RX_DROP;
net/ipv4/ipconfig.c: return NET_RX_DROP;
net/ipv4/ipconfig.c: return NET_RX_DROP;
net/ipv4/raw.c: return NET_RX_DROP;
net/ipv4/raw.c: return NET_RX_DROP;
net/ipv4/xfrm4_input.c: return NET_RX_DROP;
net/ipv6/ip6_input.c: return NET_RX_DROP;
net/ipv6/ip6_input.c: return NET_RX_DROP;
net/ipv6/ip6_input.c: return NET_RX_DROP;
net/ipv6/raw.c: return NET_RX_DROP;
net/ipv6/raw.c: return NET_RX_DROP;
net/ipv6/raw.c: return NET_RX_DROP;
net/ipv6/raw.c: return NET_RX_DROP;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox