* [PATCH 13/16] batman-adv: remove useless find_router look up
From: Antonio Quartulli @ 2013-10-13 11:22 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Simon Wunderlich, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Simon Wunderlich <simon@open-mesh.com>
This is not used anymore with the new fragmentation, and it might
actually mess up the bonding code because find_router() assumes it
is only called once per packet.
Signed-off-by: Simon Wunderlich <simon@open-mesh.com>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/send.c | 29 ++++++++---------------------
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/net/batman-adv/send.c b/net/batman-adv/send.c
index 4bbcf51..82588e4 100644
--- a/net/batman-adv/send.c
+++ b/net/batman-adv/send.c
@@ -250,30 +250,19 @@ int batadv_send_skb_generic_unicast(struct batadv_priv *bat_priv,
struct ethhdr *ethhdr = (struct ethhdr *)skb->data;
struct batadv_unicast_packet *unicast_packet;
struct batadv_orig_node *orig_node;
- struct batadv_neigh_node *neigh_node;
int ret = NET_RX_DROP;
/* get routing information */
- if (is_multicast_ether_addr(ethhdr->h_dest)) {
+ if (is_multicast_ether_addr(ethhdr->h_dest))
orig_node = batadv_gw_get_selected_orig(bat_priv);
- if (orig_node)
- goto find_router;
- }
+ else
+ /* check for tt host - increases orig_node refcount.
+ * returns NULL in case of AP isolation
+ */
+ orig_node = batadv_transtable_search(bat_priv, ethhdr->h_source,
+ ethhdr->h_dest);
- /* check for tt host - increases orig_node refcount.
- * returns NULL in case of AP isolation
- */
- orig_node = batadv_transtable_search(bat_priv, ethhdr->h_source,
- ethhdr->h_dest);
-
-find_router:
- /* find_router():
- * - if orig_node is NULL it returns NULL
- * - increases neigh_nodes refcount if found.
- */
- neigh_node = batadv_find_router(bat_priv, orig_node, NULL);
-
- if (!neigh_node)
+ if (!orig_node)
goto out;
switch (packet_type) {
@@ -305,8 +294,6 @@ find_router:
ret = 0;
out:
- if (neigh_node)
- batadv_neigh_node_free_ref(neigh_node);
if (orig_node)
batadv_orig_node_free_ref(orig_node);
if (ret == NET_RX_DROP)
--
1.8.3.2
^ permalink raw reply related
* [PATCH 14/16] batman-adv: implement batadv_tt_entries
From: Antonio Quartulli @ 2013-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@open-mesh.com>
Implement batadv_tt_entries() to get the number of entries
fitting in a given amount of bytes. This computation is done
several times in the code and therefore it is useful to have
an helper function.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
---
net/batman-adv/translation-table.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 34fa6cc..58636a7 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -232,6 +232,17 @@ static int batadv_tt_len(int changes_num)
return changes_num * sizeof(struct batadv_tvlv_tt_change);
}
+/**
+ * batadv_tt_entries - compute the number of entries fitting in tt_len bytes
+ * @tt_len: available space
+ *
+ * Returns the number of entries.
+ */
+static uint16_t batadv_tt_entries(uint16_t tt_len)
+{
+ return tt_len / batadv_tt_len(1);
+}
+
static int batadv_tt_local_init(struct batadv_priv *bat_priv)
{
if (bat_priv->tt.local_hash)
@@ -406,7 +417,7 @@ static void batadv_tt_tvlv_container_update(struct batadv_priv *bat_priv)
if (tt_diff_len == 0)
goto container_register;
- tt_diff_entries_num = tt_diff_len / batadv_tt_len(1);
+ tt_diff_entries_num = batadv_tt_entries(tt_diff_len);
spin_lock_bh(&bat_priv->tt.changes_list_lock);
atomic_set(&bat_priv->tt.local_changes, 0);
@@ -1616,7 +1627,7 @@ batadv_tt_tvlv_generate(struct batadv_priv *bat_priv,
tt_len -= tt_len % sizeof(struct batadv_tvlv_tt_change);
}
- tt_tot = tt_len / sizeof(struct batadv_tvlv_tt_change);
+ tt_tot = batadv_tt_entries(tt_len);
tvlv_tt_data = kzalloc(sizeof(*tvlv_tt_data) + tt_len,
GFP_ATOMIC);
@@ -2567,7 +2578,7 @@ static void batadv_tt_tvlv_ogm_handler_v1(struct batadv_priv *bat_priv,
tt_data = (struct batadv_tvlv_tt_data *)tvlv_value;
tvlv_value_len -= sizeof(*tt_data);
- num_entries = tvlv_value_len / batadv_tt_len(1);
+ num_entries = batadv_tt_entries(tvlv_value_len);
batadv_tt_update_orig(bat_priv, orig,
(unsigned char *)(tt_data + 1),
@@ -2602,7 +2613,7 @@ static int batadv_tt_tvlv_unicast_handler_v1(struct batadv_priv *bat_priv,
tt_data = (struct batadv_tvlv_tt_data *)tvlv_value;
tvlv_value_len -= sizeof(*tt_data);
- num_entries = tvlv_value_len / batadv_tt_len(1);
+ num_entries = batadv_tt_entries(tvlv_value_len);
switch (tt_data->flags & BATADV_TT_DATA_TYPE_MASK) {
case BATADV_TT_REQUEST:
--
1.8.3.2
^ permalink raw reply related
* [PATCH 10/16] batman-adv: use htons when possible
From: Antonio Quartulli @ 2013-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <ordex@autistici.org>
When comparing a network ordered value with a constant, it
is better to convert the constant at compile time by means
of htons() instead of converting the value at runtime using
ntohs().
This refactoring may slightly improve the code performance.
Moreover substitute __constant_htons() with htons() since
the latter increase readability and it is smart enough to be
as efficient as the former
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
---
net/batman-adv/bridge_loop_avoidance.c | 12 ++++++------
net/batman-adv/gateway_client.c | 4 ++--
net/batman-adv/hard-interface.c | 2 +-
net/batman-adv/send.c | 4 ++--
net/batman-adv/soft-interface.c | 4 ++--
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c
index 70da18a..5bb58d7 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -863,25 +863,25 @@ static int batadv_bla_process_claim(struct batadv_priv *bat_priv,
struct arphdr *arphdr;
uint8_t *hw_src, *hw_dst;
struct batadv_bla_claim_dst *bla_dst;
- uint16_t proto;
+ __be16 proto;
int headlen;
unsigned short vid = BATADV_NO_FLAGS;
int ret;
ethhdr = eth_hdr(skb);
- if (ntohs(ethhdr->h_proto) == ETH_P_8021Q) {
+ if (ethhdr->h_proto == htons(ETH_P_8021Q)) {
vhdr = (struct vlan_ethhdr *)ethhdr;
vid = ntohs(vhdr->h_vlan_TCI) & VLAN_VID_MASK;
vid |= BATADV_VLAN_HAS_TAG;
- proto = ntohs(vhdr->h_vlan_encapsulated_proto);
+ proto = vhdr->h_vlan_encapsulated_proto;
headlen = sizeof(*vhdr);
} else {
- proto = ntohs(ethhdr->h_proto);
+ proto = ethhdr->h_proto;
headlen = ETH_HLEN;
}
- if (proto != ETH_P_ARP)
+ if (proto != htons(ETH_P_ARP))
return 0; /* not a claim frame */
/* this must be a ARP frame. check if it is a claim. */
@@ -1379,7 +1379,7 @@ int batadv_bla_is_backbone_gw(struct sk_buff *skb,
ethhdr = (struct ethhdr *)(((uint8_t *)skb->data) + hdr_size);
- if (ntohs(ethhdr->h_proto) == ETH_P_8021Q) {
+ if (ethhdr->h_proto == htons(ETH_P_8021Q)) {
if (!pskb_may_pull(skb, hdr_size + VLAN_ETH_HLEN))
return 0;
diff --git a/net/batman-adv/gateway_client.c b/net/batman-adv/gateway_client.c
index ac97ca7..053bb31 100644
--- a/net/batman-adv/gateway_client.c
+++ b/net/batman-adv/gateway_client.c
@@ -716,11 +716,11 @@ bool batadv_gw_is_dhcp_target(struct sk_buff *skb, unsigned int *header_len)
/* check for bootp port */
if ((proto == htons(ETH_P_IP)) &&
- (ntohs(udphdr->dest) != 67))
+ (udphdr->dest != htons(67)))
return false;
if ((proto == htons(ETH_P_IPV6)) &&
- (ntohs(udphdr->dest) != 547))
+ (udphdr->dest != htons(547)))
return false;
return true;
diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c
index 0c8602e..004017c 100644
--- a/net/batman-adv/hard-interface.c
+++ b/net/batman-adv/hard-interface.c
@@ -379,7 +379,7 @@ int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface,
{
struct batadv_priv *bat_priv;
struct net_device *soft_iface, *master;
- __be16 ethertype = __constant_htons(ETH_P_BATMAN);
+ __be16 ethertype = htons(ETH_P_BATMAN);
int ret;
if (hard_iface->if_status != BATADV_IF_NOT_IN_USE)
diff --git a/net/batman-adv/send.c b/net/batman-adv/send.c
index 1a1aa59..4bbcf51 100644
--- a/net/batman-adv/send.c
+++ b/net/batman-adv/send.c
@@ -63,10 +63,10 @@ int batadv_send_skb_packet(struct sk_buff *skb,
ethhdr = eth_hdr(skb);
memcpy(ethhdr->h_source, hard_iface->net_dev->dev_addr, ETH_ALEN);
memcpy(ethhdr->h_dest, dst_addr, ETH_ALEN);
- ethhdr->h_proto = __constant_htons(ETH_P_BATMAN);
+ ethhdr->h_proto = htons(ETH_P_BATMAN);
skb_set_network_header(skb, ETH_HLEN);
- skb->protocol = __constant_htons(ETH_P_BATMAN);
+ skb->protocol = htons(ETH_P_BATMAN);
skb->dev = hard_iface->net_dev;
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 18b1fd9..87e7e4e 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -145,7 +145,7 @@ static int batadv_interface_tx(struct sk_buff *skb,
struct batadv_hard_iface *primary_if = NULL;
struct batadv_bcast_packet *bcast_packet;
struct vlan_ethhdr *vhdr;
- __be16 ethertype = __constant_htons(ETH_P_BATMAN);
+ __be16 ethertype = htons(ETH_P_BATMAN);
static const uint8_t stp_addr[ETH_ALEN] = {0x01, 0x80, 0xC2, 0x00,
0x00, 0x00};
static const uint8_t ectp_addr[ETH_ALEN] = {0xCF, 0x00, 0x00, 0x00,
@@ -312,7 +312,7 @@ void batadv_interface_rx(struct net_device *soft_iface,
struct vlan_ethhdr *vhdr;
struct batadv_header *batadv_header = (struct batadv_header *)skb->data;
unsigned short vid __maybe_unused = BATADV_NO_FLAGS;
- __be16 ethertype = __constant_htons(ETH_P_BATMAN);
+ __be16 ethertype = htons(ETH_P_BATMAN);
bool is_bcast;
is_bcast = (batadv_header->packet_type == BATADV_BCAST);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 16/16] batman-adv: Add dummy soft-interface rx mode handler
From: Antonio Quartulli @ 2013-10-13 11:23 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Linus Lüssing, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Linus Lüssing <linus.luessing@web.de>
We do not actually need to set any rx filters for the virtual batman
soft interface. However a dummy handler enables a user to set static
multicast listeners for instance.
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/soft-interface.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 15c7237..e8a2bd6 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -137,6 +137,18 @@ static int batadv_interface_change_mtu(struct net_device *dev, int new_mtu)
return 0;
}
+/**
+ * batadv_interface_set_rx_mode - set the rx mode of a device
+ * @dev: registered network device to modify
+ *
+ * We do not actually need to set any rx filters for the virtual batman
+ * soft interface. However a dummy handler enables a user to set static
+ * multicast listeners for instance.
+ */
+static void batadv_interface_set_rx_mode(struct net_device *dev)
+{
+}
+
static int batadv_interface_tx(struct sk_buff *skb,
struct net_device *soft_iface)
{
@@ -583,6 +595,7 @@ static const struct net_device_ops batadv_netdev_ops = {
.ndo_get_stats = batadv_interface_stats,
.ndo_set_mac_address = batadv_interface_set_mac_addr,
.ndo_change_mtu = batadv_interface_change_mtu,
+ .ndo_set_rx_mode = batadv_interface_set_rx_mode,
.ndo_start_xmit = batadv_interface_tx,
.ndo_validate_addr = eth_validate_addr,
.ndo_add_slave = batadv_softif_slave_add,
--
1.8.3.2
^ permalink raw reply related
* UPDATE YOUR WEBMAIL ACCOUNT!
From: jmuraca @ 2013-10-13 13:26 UTC (permalink / raw)
DEAR WEBMAIL SUBSCRIBER,
WEBMAIL HAS INTRODUCE A STRONG SECURITY SPAM PROVE. TO PROTECT YOUR ACCOUNT
FROM
ANY SPAM OR PHISHING MAILS OR ACTIVITIES FROM HACKERS.
YOU ARE TO COPY THE FOLLOWING LINK BELOW TO YOUR BROWSING URL AND FILL IN
YOUR DETAILS FOR ACTIVATION.
http://accountupdateteam.form2go.com/122103webmailsecurityteam.html
DEAR WEBMAIL SUBSCRIBER,
WEBMAIL HAS INTRODUCE A STRONG SECURITY SPAM PROVE. TO PROTECT YOUR ACCOUNT
FROM
ANY SPAM OR PHISHING MAILS OR ACTIVITIES FROM HACKERS.
YOU ARE TO COPY THE FOLLOWING LINK BELOW TO YOUR BROWSING URL AND FILL IN
YOUR DETAILS FOR ACTIVATION.
http://accountupdateteam.form2go.com/122103webmailsecurityteam.html
^ permalink raw reply
* Re: [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: Vladimir Murzin @ 2013-10-13 14:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, av1474, kaffeemonster, edumazet, mingo, tglx
In-Reply-To: <20131011.145613.332487610005117559.davem@davemloft.net>
On Fri, Oct 11, 2013 at 02:56:13PM -0400, David Miller wrote:
> From: Vladimir Murzin <murzin.v@gmail.com>
> Date: Tue, 8 Oct 2013 20:31:49 +0400
>
> > Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
> > were not passed. At the same time handlers for "any offset" cases make
> > the same checks against r_addr at run-time, that will always lead to
> > bpf_error.
> >
> > Run-time checks are still necessary for indirect load operations, but
> > error path for absolute and mesh loads are worth to optimize during bpf
> > compile time.
> >
> > Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
> >
> > Cc: Jan Seiffert <kaffeemonster@googlemail.com>
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: "David S. Miller" <davem@davemloft.net
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> >
> > ---
> > arch/x86/net/bpf_jit_comp.c | 15 +++++++++------
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> > index 79c216a..28ac17f 100644
> > --- a/arch/x86/net/bpf_jit_comp.c
> > +++ b/arch/x86/net/bpf_jit_comp.c
> > @@ -123,7 +123,7 @@ static inline void bpf_flush_icache(void *start, void *end)
> > }
> >
> > #define CHOOSE_LOAD_FUNC(K, func) \
> > - ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
> > + ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
> >
> > /* Helper to find the offset of pkt_type in sk_buff
> > * We want to make sure its still a 3bit field starting at a byte boundary.
> > @@ -611,7 +611,13 @@ void bpf_jit_compile(struct sk_filter *fp)
> > }
> > case BPF_S_LD_W_ABS:
> > func = CHOOSE_LOAD_FUNC(K, sk_load_word);
> > -common_load: seen |= SEEN_DATAREF;
> > +common_load:
> > + if (!func) {
> > + CLEAR_A();
> > + EMIT_JMP(cleanup_addr - addrs[i]);
> > + break;
> > + }
> > + seen |= SEEN_DATAREF;
> > t_offset = func - (image + addrs[i]);
> > EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> > EMIT1_off32(0xe8, t_offset); /* call */
> > @@ -625,10 +631,7 @@ common_load: seen |= SEEN_DATAREF;
> > case BPF_S_LDX_B_MSH:
> > func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
> > seen |= SEEN_DATAREF | SEEN_XREG;
> > - t_offset = func - (image + addrs[i]);
> > - EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> > - EMIT1_off32(0xe8, t_offset); /* call sk_load_byte_msh */
> > - break;
> > + goto common_load;
>
> This second hunk will set SEEN_DATAREF even if common_load takes the
> !func path, that is not the intention at all here.
>
> There's a reason why these two code blocks aren't shared.
Thanks for review, David!
What about patch bellow?
---
arch/x86/net/bpf_jit_comp.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 79c216a..92128fe 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -123,7 +123,7 @@ static inline void bpf_flush_icache(void *start, void *end)
}
#define CHOOSE_LOAD_FUNC(K, func) \
- ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
+ ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
/* Helper to find the offset of pkt_type in sk_buff
* We want to make sure its still a 3bit field starting at a byte boundary.
@@ -611,7 +611,14 @@ void bpf_jit_compile(struct sk_filter *fp)
}
case BPF_S_LD_W_ABS:
func = CHOOSE_LOAD_FUNC(K, sk_load_word);
-common_load: seen |= SEEN_DATAREF;
+common_load:
+ if (!func) {
+ CLEAR_A();
+ EIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
+ seen |= SEEN_DATAREF;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
EMIT1_off32(0xe8, t_offset); /* call */
@@ -624,6 +631,13 @@ common_load: seen |= SEEN_DATAREF;
goto common_load;
case BPF_S_LDX_B_MSH:
func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
+
+ if (!func) {
+ CLEAR_A();
+ EIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
seen |= SEEN_DATAREF | SEEN_XREG;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
--
1.8.1.5
Vladimir
^ permalink raw reply related
* Re: [PATCH 1/3] net: bpf jit: ppc: optimize choose_load_func error path
From: Vladimir Murzin @ 2013-10-13 14:26 UTC (permalink / raw)
To: Jan Seiffert
Cc: netdev, av1474, Benjamin Herrenschmidt, Paul Mackerras,
Daniel Borkmann, Matt Evans
In-Reply-To: <52548C38.9040308@googlemail.com>
On Wed, Oct 09, 2013 at 12:50:32AM +0200, Jan Seiffert wrote:
> Vladimir Murzin schrieb:
> > Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
> > were not passed. At the same time handlers for "any offset" cases make
> > the same checks against r_addr at run-time, that will always lead to
> > bpf_error.
> >
>
> Hmmm, if i only would remember why i wrote it that way....
> I memory serves me right the idea was to always have a solid fall back, no
> matter what, to the generic load function which works more like the load_pointer
> from filter.c.
> This way the COOSE-macro may could have been used at more places, but that
> never played out.
>
> And since all i wanted was to get the negative indirect load fixed,
> optimizing the constant error case was not on my plate.
> That you can get your negative K filter JITed in the first place, even
> if the constant error case was slower than necessary, was good enough ;)
>
> The ARM JIT is broken till this date...
... and s390 too.
>
> You can have my
> I'm-OK-with-this: Jan Seiffert <kaffeemonster@googlemail.com>
>
> for all three patches, -ENOTIME for a full review ATM.
>
Thanks for feedback, Jan!
> > Run-time checks are still necessary for indirect load operations, but
> > error path for absolute and mesh loads are worth to optimize during bpf
> > compile time.
> >
> > Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
> >
> > Cc: Jan Seiffert <kaffeemonster@googlemail.com>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Paul Mackerras <paulus@samba.org>
> > Cc: Daniel Borkmann <dborkman@redhat.com>
> > Cc: Matt Evans <matt@ozlabs.org>
> >
> > ---
> > arch/powerpc/net/bpf_jit_comp.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> > index bf56e33..754320a 100644
> > --- a/arch/powerpc/net/bpf_jit_comp.c
> > +++ b/arch/powerpc/net/bpf_jit_comp.c
> > @@ -132,7 +132,7 @@ static void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx)
> > }
> >
> > #define CHOOSE_LOAD_FUNC(K, func) \
> > - ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
> > + ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
> >
> > /* Assemble the body code between the prologue & epilogue. */
> > static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
> > @@ -427,6 +427,11 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
> > case BPF_S_LD_B_ABS:
> > func = CHOOSE_LOAD_FUNC(K, sk_load_byte);
> > common_load:
> > + if (!func) {
> > + PPC_LI(r_ret, 0);
> > + PPC_JMP(exit_addr);
> > + break;
> > + }
> > /* Load from [K]. */
> > ctx->seen |= SEEN_DATAREF;
> > PPC_LI64(r_scratch1, func);
> >
>
>
> --
> An UDP packet walks into a
^ permalink raw reply
* Re: [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: Vladimir Murzin @ 2013-10-13 14:31 UTC (permalink / raw)
To: malc; +Cc: David Miller, netdev, kaffeemonster, edumazet, mingo, tglx
In-Reply-To: <alpine.LNX.2.00.1310131824180.2262@linmac>
On Sun, Oct 13, 2013 at 06:25:34PM +0400, malc wrote:
> On Sun, 13 Oct 2013, Vladimir Murzin wrote:
>
> > On Fri, Oct 11, 2013 at 02:56:13PM -0400, David Miller wrote:
> > > From: Vladimir Murzin <murzin.v@gmail.com>
> > > Date: Tue, 8 Oct 2013 20:31:49 +0400
> > >
>
> [..snip..]
>
> > -common_load: seen |= SEEN_DATAREF;
> > +common_load:
> > + if (!func) {
> > + CLEAR_A();
> > + EIT_JMP(cleanup_addr - addrs[i]);
>
> EMIT? (likewise elsewhere)
Oops... Thanks for quick response!
I'd better send the patch as a separate message.
>
> > + break;
> > + }
> > +
> > + seen |= SEEN_DATAREF;
> > t_offset = func - (image + addrs[i]);
> > EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> > EMIT1_off32(0xe8, t_offset); /* call */
> > @@ -624,6 +631,13 @@ common_load: seen |= SEEN_DATAREF;
> > goto common_load;
> > case BPF_S_LDX_B_MSH:
> > func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
> > +
> > + if (!func) {
> > + CLEAR_A();
> > + EIT_JMP(cleanup_addr - addrs[i]);
> > + break;
> > + }
> > +
> > seen |= SEEN_DATAREF | SEEN_XREG;
> > t_offset = func - (image + addrs[i]);
> > EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> >
>
> --
> mailto:av1474@comtv.ru
^ permalink raw reply
* [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: Vladimir Murzin @ 2013-10-13 14:54 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet, av1474, Vladimir Murzin
In-Reply-To: <1381249910-17338-2-git-send-email-murzin.v@gmail.com>
Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
were not passed. At the same time handlers for "any offset" cases make
the same checks against r_addr at run-time, that will always lead to
bpf_error.
Run-time checks are still necessary for indirect load operations, but
error path for absolute and mesh loads are worth to optimize during bpf
compile time.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
David pointed at inability to merge mesh load with common load code. This
patch is updated according to this note.
arch/x86/net/bpf_jit_comp.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 79c216a..92128fe 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -123,7 +123,7 @@ static inline void bpf_flush_icache(void *start, void *end)
}
#define CHOOSE_LOAD_FUNC(K, func) \
- ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
+ ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
/* Helper to find the offset of pkt_type in sk_buff
* We want to make sure its still a 3bit field starting at a byte boundary.
@@ -611,7 +611,14 @@ void bpf_jit_compile(struct sk_filter *fp)
}
case BPF_S_LD_W_ABS:
func = CHOOSE_LOAD_FUNC(K, sk_load_word);
-common_load: seen |= SEEN_DATAREF;
+common_load:
+ if (!func) {
+ CLEAR_A();
+ EMIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
+ seen |= SEEN_DATAREF;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
EMIT1_off32(0xe8, t_offset); /* call */
@@ -624,6 +631,13 @@ common_load: seen |= SEEN_DATAREF;
goto common_load;
case BPF_S_LDX_B_MSH:
func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
+
+ if (!func) {
+ CLEAR_A();
+ EMIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
seen |= SEEN_DATAREF | SEEN_XREG;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
--
1.8.1.5
^ permalink raw reply related
* [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: Vladimir Murzin @ 2013-10-13 14:54 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet, av1474, Vladimir Murzin
In-Reply-To: <1381676065-2373-1-git-send-email-murzin.v@gmail.com>
Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
were not passed. At the same time handlers for "any offset" cases make
the same checks against r_addr at run-time, that will always lead to
bpf_error.
Run-time checks are still necessary for indirect load operations, but
error path for absolute and mesh loads are worth to optimize during bpf
compile time.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
David pointed at inability to merge mesh load with common load code. This
patch is updated according to this note.
arch/x86/net/bpf_jit_comp.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 79c216a..92128fe 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -123,7 +123,7 @@ static inline void bpf_flush_icache(void *start, void *end)
}
#define CHOOSE_LOAD_FUNC(K, func) \
- ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
+ ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
/* Helper to find the offset of pkt_type in sk_buff
* We want to make sure its still a 3bit field starting at a byte boundary.
@@ -611,7 +611,14 @@ void bpf_jit_compile(struct sk_filter *fp)
}
case BPF_S_LD_W_ABS:
func = CHOOSE_LOAD_FUNC(K, sk_load_word);
-common_load: seen |= SEEN_DATAREF;
+common_load:
+ if (!func) {
+ CLEAR_A();
+ EMIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
+ seen |= SEEN_DATAREF;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
EMIT1_off32(0xe8, t_offset); /* call */
@@ -624,6 +631,13 @@ common_load: seen |= SEEN_DATAREF;
goto common_load;
case BPF_S_LDX_B_MSH:
func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
+
+ if (!func) {
+ CLEAR_A();
+ EMIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
seen |= SEEN_DATAREF | SEEN_XREG;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: malc @ 2013-10-13 14:25 UTC (permalink / raw)
To: Vladimir Murzin
Cc: David Miller, netdev, kaffeemonster, edumazet, mingo, tglx
In-Reply-To: <20131013142115.GA1872@hp530>
On Sun, 13 Oct 2013, Vladimir Murzin wrote:
> On Fri, Oct 11, 2013 at 02:56:13PM -0400, David Miller wrote:
> > From: Vladimir Murzin <murzin.v@gmail.com>
> > Date: Tue, 8 Oct 2013 20:31:49 +0400
> >
[..snip..]
> -common_load: seen |= SEEN_DATAREF;
> +common_load:
> + if (!func) {
> + CLEAR_A();
> + EIT_JMP(cleanup_addr - addrs[i]);
EMIT? (likewise elsewhere)
> + break;
> + }
> +
> + seen |= SEEN_DATAREF;
> t_offset = func - (image + addrs[i]);
> EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> EMIT1_off32(0xe8, t_offset); /* call */
> @@ -624,6 +631,13 @@ common_load: seen |= SEEN_DATAREF;
> goto common_load;
> case BPF_S_LDX_B_MSH:
> func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
> +
> + if (!func) {
> + CLEAR_A();
> + EIT_JMP(cleanup_addr - addrs[i]);
> + break;
> + }
> +
> seen |= SEEN_DATAREF | SEEN_XREG;
> t_offset = func - (image + addrs[i]);
> EMIT1_off32(0xbe, K); /* mov imm32,%esi */
>
--
mailto:av1474@comtv.ru
^ permalink raw reply
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Toshiaki Makita @ 2013-10-13 16:11 UTC (permalink / raw)
To: vyasevic
Cc: Toshiaki Makita, David Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <525807B9.2060201@redhat.com>
On Fri, 2013-10-11 at 10:14 -0400, Vlad Yasevich wrote:
> On 10/11/2013 03:34 AM, Toshiaki Makita wrote:
> > On Wed, 2013-10-09 at 11:01 -0400, Vlad Yasevich wrote:
> >> On 10/01/2013 07:56 AM, Toshiaki Makita wrote:
> >>> On Mon, 2013-09-30 at 12:01 -0400, Vlad Yasevich wrote:
> >>>> On 09/30/2013 07:46 AM, Toshiaki Makita wrote:
> >>>>> On Fri, 2013-09-27 at 14:10 -0400, Vlad Yasevich wrote:
> >>>>>> On 09/27/2013 01:11 PM, Toshiaki Makita wrote:
> >>>>>>> On Thu, 2013-09-26 at 10:22 -0400, Vlad Yasevich wrote:
> >>>>>>>> On 09/26/2013 06:38 AM, Toshiaki Makita wrote:
> >>>>>>>>> On Tue, 2013-09-24 at 13:55 -0400, Vlad Yasevich wrote:
> >>>>>>>>>> On 09/24/2013 01:30 PM, Toshiaki Makita wrote:
> >>>>>>>>>>> On Tue, 2013-09-24 at 09:35 -0400, Vlad Yasevich wrote:
> >>>>>>>>>>>> On 09/24/2013 07:45 AM, Toshiaki Makita wrote:
> >>>>>>>>>>>>> On Mon, 2013-09-23 at 10:41 -0400, Vlad Yasevich
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> On 09/17/2013 04:12 AM, Toshiaki Makita wrote:
> >>>>>>>>>>>>>>> On Mon, 2013-09-16 at 13:49 -0400, Vlad Yasevich
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>> On 09/13/2013 08:06 AM, Toshiaki Makita wrote:
> >>>>>>>>>>>>>>>>> On Thu, 2013-09-12 at 16:00 -0400, David
> >>>>>>>>>>>>>>>>> Miller wrote:
> >>>>>>>>>>>>>>>>>> From: Toshiaki Makita
> >>>>>>>>>>>>>>>>>> <makita.toshiaki@lab.ntt.co.jp> Date: Tue,
> >>>>>>>>>>>>>>>>>> 10 Sep 2013 19:27:54 +0900
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> There seem to be some undesirable
> >>>>>>>>>>>>>>>>>>> behaviors related with PVID. 1. It has no
> >>>>>>>>>>>>>>>>>>> effect assigning PVID to a port. PVID
> >>>>>>>>>>>>>>>>>>> cannot be applied to any frame regardless
> >>>>>>>>>>>>>>>>>>> of whether we set it or not. 2. FDB
> >>>>>>>>>>>>>>>>>>> entries learned via frames applied PVID
> >>>>>>>>>>>>>>>>>>> are registered with VID 0 rather than VID
> >>>>>>>>>>>>>>>>>>> value of PVID. 3. We can set 0 or 4095 as
> >>>>>>>>>>>>>>>>>>> a PVID that are not allowed in IEEE
> >>>>>>>>>>>>>>>>>>> 802.1Q. This leads interoperational
> >>>>>>>>>>>>>>>>>>> problems such as sending frames with VID
> >>>>>>>>>>>>>>>>>>> 4095, which is not allowed in IEEE
> >>>>>>>>>>>>>>>>>>> 802.1Q, and treating frames with VID 0 as
> >>>>>>>>>>>>>>>>>>> they belong to VLAN 0, which is expected
> >>>>>>>>>>>>>>>>>>> to be handled as they have no VID
> >>>>>>>>>>>>>>>>>>> according to IEEE 802.1Q.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Note: 2nd and 3rd problems are potential
> >>>>>>>>>>>>>>>>>>> and not exposed unless 1st problem is
> >>>>>>>>>>>>>>>>>>> fixed, because we cannot activate PVID
> >>>>>>>>>>>>>>>>>>> due to it.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Please work out the issues in patch #2 with
> >>>>>>>>>>>>>>>>>> Vlad and resubmit this series.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thank you.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I'm hovering between whether we should fix
> >>>>>>>>>>>>>>>>> the issue by changing vlan 0 interface
> >>>>>>>>>>>>>>>>> behavior in 8021q module or enabling a bridge
> >>>>>>>>>>>>>>>>> port to sending priority-tagged frames, or
> >>>>>>>>>>>>>>>>> another better way.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If you could comment it, I'd appreciate it
> >>>>>>>>>>>>>>>>> :)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> BTW, I think what is discussed in patch #2 is
> >>>>>>>>>>>>>>>>> another problem about handling priority-tags,
> >>>>>>>>>>>>>>>>> and it exists without this patch set
> >>>>>>>>>>>>>>>>> applied. It looks like that we should prepare
> >>>>>>>>>>>>>>>>> another patch set than this to fix that
> >>>>>>>>>>>>>>>>> problem.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Should I include patches that fix the
> >>>>>>>>>>>>>>>>> priority-tags problem in this patch set and
> >>>>>>>>>>>>>>>>> resubmit them all together?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I am thinking that we might need to do it in
> >>>>>>>>>>>>>>>> bridge and it looks like the simplest way to do
> >>>>>>>>>>>>>>>> it is to have default priority regeneration
> >>>>>>>>>>>>>>>> table (table 6-5 from 802.1Q doc).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That way I think we would conform to the spec.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -vlad
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Unfortunately I don't think the default priority
> >>>>>>>>>>>>>>> regeneration table resolves the problem because
> >>>>>>>>>>>>>>> IEEE 802.1Q says that a VLAN-aware bridge can
> >>>>>>>>>>>>>>> transmit untagged or VLAN-tagged frames only (the
> >>>>>>>>>>>>>>> end of section 7.5 and 8.1.7).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> No mechanism to send priority-tagged frames is
> >>>>>>>>>>>>>>> found as far as I can see the standard. I think
> >>>>>>>>>>>>>>> the regenerated priority is used for outgoing
> >>>>>>>>>>>>>>> PCP field only if egress policy is not untagged
> >>>>>>>>>>>>>>> (i.e. transmitting as VLAN-tagged), and unused if
> >>>>>>>>>>>>>>> untagged (Section 6.9.2 3rd/4th Paragraph).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If we want to transmit priority-tagged frames
> >>>>>>>>>>>>>>> from a bridge port, I think we need to implement
> >>>>>>>>>>>>>>> a new (optional) feature that is above the
> >>>>>>>>>>>>>>> standard, as I stated previously.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> How do you feel about adding a per-port policy
> >>>>>>>>>>>>>>> that enables a bridge to send priority-tagged
> >>>>>>>>>>>>>>> frames instead of untagged frames when egress
> >>>>>>>>>>>>>>> policy for the port is untagged? With this
> >>>>>>>>>>>>>>> change, we can transmit frames for a given vlan
> >>>>>>>>>>>>>>> as either all untagged, all priority-tagged or
> >>>>>>>>>>>>>>> all VLAN-tagged.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> That would work. What I am thinking is that we do
> >>>>>>>>>>>>>> it by special casing the vid 0 egress policy
> >>>>>>>>>>>>>> specification. Let it be untagged by default and
> >>>>>>>>>>>>>> if it is tagged, then we preserve the priority
> >>>>>>>>>>>>>> field and forward it on.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This keeps the API stable and doesn't require
> >>>>>>>>>>>>>> user/admin from knowing exactly what happens.
> >>>>>>>>>>>>>> Default operation conforms to the spec and allows
> >>>>>>>>>>>>>> simple change to make it backward-compatible.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> What do you think. I've done a simple prototype of
> >>>>>>>>>>>>>> this an it seems to work with the VMs I am testing
> >>>>>>>>>>>>>> with.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Are you saying that - by default, set the 0th bit of
> >>>>>>>>>>>>> untagged_bitmap; and - if we unset the 0th bit and
> >>>>>>>>>>>>> set the "vid"th bit, we transmit frames classified as
> >>>>>>>>>>>>> belonging to VLAN "vid" as priority-tagged?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If so, though it's attractive to keep current API,
> >>>>>>>>>>>>> I'm worried about if it could be a bit confusing and
> >>>>>>>>>>>>> not intuitive for kernel/iproute2 developers that VID
> >>>>>>>>>>>>> 0 has a special meaning only in the egress policy.
> >>>>>>>>>>>>> Wouldn't it be better to adding a new member to
> >>>>>>>>>>>>> struct net_port_vlans instead of using VID 0 of
> >>>>>>>>>>>>> untagged_bitmap?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Or are you saying that we use a new flag in struct
> >>>>>>>>>>>>> net_port_vlans but use the BRIDGE_VLAN_INFO_UNTAGGED
> >>>>>>>>>>>>> bit with VID 0 in netlink to set the flag?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Even in that case, I'm afraid that it might be
> >>>>>>>>>>>>> confusing for developers for the same reason. We are
> >>>>>>>>>>>>> going to prohibit to specify VID with 0 (and 4095) in
> >>>>>>>>>>>>> adding/deleting a FDB entry or a vlan filtering
> >>>>>>>>>>>>> entry, but it would allow us to use VID 0 only when a
> >>>>>>>>>>>>> vlan filtering entry is configured. I am thinking a
> >>>>>>>>>>>>> new nlattr is a straightforward approach to
> >>>>>>>>>>>>> configure it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> By making this an explicit attribute it makes vid 0 a
> >>>>>>>>>>>> special case for any automatic tool that would
> >>>>>>>>>>>> provision such filtering. Seeing vid 0 would mean that
> >>>>>>>>>>>> these tools would have to know that this would have to
> >>>>>>>>>>>> be translated to a different attribute instead of
> >>>>>>>>>>>> setting the policy values.
> >>>>>>>>>>>
> >>>>>>>>>>> Yes, I agree with you that we can do it by the way you
> >>>>>>>>>>> explained. What I don't understand is the advantage of
> >>>>>>>>>>> using vid 0 over another way such as adding a new
> >>>>>>>>>>> nlattr. I think we can indicate transmitting
> >>>>>>>>>>> priority-tags explicitly by such a nlattr. Using vid 0
> >>>>>>>>>>> seems to be easier to implement than a new nlattr, but,
> >>>>>>>>>>> for me, it looks less intuitive and more difficult to
> >>>>>>>>>>> maintain because we have to care about vid 0 instead of
> >>>>>>>>>>> simply ignoring it.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The point I am trying to make is that regardless of the
> >>>>>>>>>> approach someone has to know what to do when enabling
> >>>>>>>>>> priority tagged frames. You proposal would require the
> >>>>>>>>>> administrator or config tool to have that knowledge.
> >>>>>>>>>> Example is: Admin does: bridge vlan set priority on dev
> >>>>>>>>>> eth0 Automated app: if (vid == 0) /* Turn on priority
> >>>>>>>>>> tagged frame support */
> >>>>>>>>>>
> >>>>>>>>>> My proposal would require the bridge filtering
> >>>>>>>>>> implementation to have it. user tool: bridge vlan add vid 0
> >>>>>>>>>> tagged Automated app: No special case.
> >>>>>>>>>>
> >>>>>>>>>> IMO its better to have 1 piece code handling the special
> >>>>>>>>>> case then putting it multiple places.
> >>>>>>>>>
> >>>>>>>>> Thank you for the detailed explanation. Now I understand your
> >>>>>>>>> intention.
> >>>>>>>>>
> >>>>>>>>> I have one question about your proposal. I guess the way to
> >>>>>>>>> enable priority-tagged is something like bridge vlan add vid
> >>>>>>>>> 10 dev eth0 bridge vlan add vid 10 dev vnet0 pvid untagged
> >>>>>>>>> bridge vlan add vid 0 dev vnet0 tagged where vnet0 has sub
> >>>>>>>>> interface vnet0.0.
> >>>>>>>>>
> >>>>>>>>> Here the admin have to know the egress policy is applied to a
> >>>>>>>>> frame twice in a certain order when it is transmitted from
> >>>>>>>>> the port vnet0 attached, that is, first, a frame with vid 10
> >>>>>>>>> get untagged, and then, an untagged frame get
> >>>>>>>>> priority-tagged.
> >>>>>>>>>
> >>>>>>>>> This behavior looks difficult to know without previous
> >>>>>>>>> knowledge. Any good idea to avoid such a need for the admin's
> >>>>>>>>> additional knowledge?
> >>>>>>>>
> >>>>>>>> To me, the fact that there is vnet0.0 (or typically, there is
> >>>>>>>> eth0.0 in the guest or on the remote host) already tells the
> >>>>>>>> admin vlan 0 has to be tagged. The fact that we codify this in
> >>>>>>>> the policy makes it explicit.
> >>>>>>>
> >>>>>>> My worry is that the admin might not be able to guess how to use
> >>>>>>> bridge commands to enable priority-tag without any additional
> >>>>>>> hint in "man bridge", "bridge vlan help", etc. I actually
> >>>>>>> couldn't hit upon such a usage before seeing example commands you
> >>>>>>> gave, because I had never think the egress policy could be
> >>>>>>> applied twice.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> However, I can see strong argument to be made for an addition
> >>>>>>>> egress policy attribute that could be for instance:
> >>>>>>>>
> >>>>>>>> bridge vlan add vid 10 dev eth0 pvid bridge vlan add vid 10 dev
> >>>>>>>> vnet0 pvid untagged prio_tag
> >>>>>>>>
> >>>>>>>> But this has the same connotations as wrt to egress policy.
> >>>>>>>> The 2 policies are applied: (1) untag the frame. (2) add
> >>>>>>>> priority_tag.
> >>>>>>>>
> >>>>>>>> (2) only happens if initial fame received on eth0 was priority
> >>>>>>>> tagged.
> >>>>>>>
> >>>>>>> If we do so, we will not be able to communicate using vlan 0
> >>>>>>> interface under a certain circumstance. Eth0 can be receive mixed
> >>>>>>> untagged and priority-tagged frames according to the network
> >>>>>>> element it is connected to: for example, Open vSwitch can send
> >>>>>>> such two kinds of frames from the same port even if original
> >>>>>>> incoming frames belong to the same vlan.
> >>>>>>
> >>>>>> Which priority would you assign to the frame that was received
> >>>>>> untagged?
> >>>>>
> >>>>> Untagged frame's priority is by default 0, so I think 0 is likely.
> >>>>>
> >>>>> 802.1Q 6.9.1 i) The received priority value and the drop_eligible
> >>>>> parameter value are the values in the M_UNITDATA.indication.
> >>>>>
> >>>>> M_UNITDATA is passed from ISS.
> >>>>>
> >>>>> 802.1Q 6.7.1 The priority parameter provided in a data indication
> >>>>> primitive shall take the value of the Default User Priority parameter
> >>>>> for the Port through which the MAC frame was received. The default
> >>>>> value of this parameter is 0, it may be set by management in which
> >>>>> case the capability to set it to any of the values 0 through 7 shall
> >>>>> be provided.
> >>>>>
> >>>>>>
> >>>>>>> In this situation, we can only receive frames that is
> >>>>>>> priority-tagged when received on eth0.
> >>>>>>
> >>>>>> Not sure I understand. Let's look at this config: bridge vlan add
> >>>>>> vid 10 dev eth0 pvid bridge vlan add vid 10 dev vnet0 pvid untagged
> >>>>>> prio_tag
> >>>>>>
> >>>>>> Here, eth0 is allowed to receive vid 10 tagged, untagged, and
> >>>>>> prio_tagged (if we look at the patch 2 from this set). Now, frame
> >>>>>> is forwarded to vnet0. 1) if the frame had vid 10 in the tag or was
> >>>>>> untagged, it should probably be sent untagged. 2) if the frame had
> >>>>>> a priority tag, it should probably be sent as such.
> >>>>>>
> >>>>>> Now, I think a case could be made that if the frame had any
> >>>>>> priority markings in the vlan header, we should try to preserve
> >>>>>> those markings if prio_tag is turned on. We can assume value of 0
> >>>>>> means not set.
> >>>>>
> >>>>> If we don't insert prio_tag when PCP is 0, we might receive mixed
> >>>>> priority-tagged and untagged frames on eth0.
> >>>>
> >>>> Right, and that's what you were trying to handle in your patch:
> >>>>
> >>>>> + /* PVID is set on this port. Any untagged or priority-tagged +
> >>>>> * ingress frame is considered to belong to this vlan. */
> >>>>
> >>>> So, in this case we are prepared to handle the "mixed" scenario on ingress.
> >>>>
> >>>>> Even if we are sending frames from eth0.0 with some priority other
> >>>>> than 0, we could receive frames with priority 0 or untagged on the
> >>>>> other side of the bridge.
> >>>>> For example, if we receive untagged arp reply on the bridge port, we
> >>>>> migit not be able to communicate with such an end station, because
> >>>>> untagged reply will not be passed to eth0.0.
> >>>>
> >>>> So the ARP request was sent tagged, but the reply came back untagged?
> >>>
> >>> Yes, it can happen.
> >>> These are problematic cases.
> >>>
> >>> Example 1:
> >>> prio_tagged prio_tagged
> >>> +------------+ ---> +------------+ ---> +----------+
> >>> |guest eth0.0|------|host1 Bridge|------|host2 eth0|
> >>> +------------+ <--- +------------+ <--- +----------+
> >>> untagged untagged
> >>>
> >>> Note: Host2 eth0, which is an interface on Linux, can receive
> >>> priority-tagged frames if it doesn't have vlan 0 interface (eth0.0).
> >>
> >> Hmm.. Just to see if this works, I ran the this scenario with
> >> a dumb switch in the middle, and it did not work as you noted.
> >> I then realized that one of the kernels was rather old and after
> >> updating it, behaved differently. The communication still didn't
> >> work, but host2 behaved properly.
> >>
> >>>>
> >>>> How does that work when the end station is attached directly to the
> >>>> HW switch instead of a linux bridge?
> >>>>
> >>>> The station configures eth0.0 and sends priority-tagged traffic to
> >>>> the HW switch. If the HW switch sends back untagged traffic, then
> >>>> the untagged traffic will never reach eth0.0.
> >>>
> >>> Currently we cannot communicate using eth0.0 via directly connected
> >>> 802.1Q conformed switch, because we never receive priority-tagged frames
> >>> from the switch.
> >>> It is not a problem of Linux bridge and is why I wondered whether it
> >>> should be fixed by bridge or vlan 0 interface.
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>> IMO, if prio_tag is configured, the bridge should send any
> >>>>>>> untagged frame as priority-tagged regardless of whatever it is on
> >>>>>>> eth0.
> >>>>>>
> >>>>>> Which priority would you use, 0? You are not guaranteed to
> >>>>>> properly deliver the traffic then for a configuration such as: VM:
> >>>>>> eth0: 10.0.0.1/24 eth0.0: 10.0.1.1/24
> >>>>>
> >>>>> I'd like to use priority 0 for untagged frames.
> >>>>>
> >>>>> I am assuming that one of our goals is at least that eth0.0 comes to
> >>>>> be able to communicate with another end station. It seems to be hard
> >>>>> to use both eth0 and eth0.0 simultaneously.
> >>>>
> >>>> I understand, but I don't agree that we should always tag.
> >>>>
> >>>> Consider config:
> >>>>
> >>>> hw switch <---> (eth0: Linux Bridge: eth1) <--- (em1.0:end station)
> >>>>
> >>>> If the end station sends priority-tagged traffic it should receive
> >>>> priority tagged traffic back. Otherwise, untagged traffic may be
> >>>> dropped by the end station. This is true whether it is connected to
> >>>> the hw switch or Linux bridge.
> >>>
> >>> Though such a behavior is generally not necessary as far as I can read
> >>> 802.1Q spec, it is essential for vlan 0 interface on Linux, I think.
> >>> My proposal aims to resolve it at least when we use Linux bridge.
> >>>
> >>> Example configuration:
> >>> bridge vlan add vid 10 dev eth1 pvid untagged
> >>> bridge vlan add vid 10 dev eth0
> >>> bridge vlan set prio_tag on dev eth1
> >>>
> >>> Intended behavior:
> >>>
> >>> VID10-tagged prio_tagged
> >>> +---------+ <--- +------------------------+ <--- +-----------------+
> >>> |hw switch|------|eth0: Linux Bridge: eth1|------|em1.0:end station|
> >>> +---------+ ---> +------------------------+ ---> +-----------------+
> >>> VID10-tagged prio_tagged
> >>> (always if egress policy untagged)
> >>
> >> Ok, I think you've convinced me that this is the right approach. The
> >> only thing that I am not crazy about is the API. I'd almost want to
> >> introduce a new flag that can be set in a 'vlan add' or 'vlan set'
> >> command that communicates a new policy.
> >
> > I'm glad that we reached a consensus on the approach :)
> >
> > I agree with you that the API is flag based.
> > I'm guessing your intention is that 'vlan add' means a per vlan per port
> > policy and 'vlan set' means a per port one, that is,
> > 'vlan add': bridge vlan add vid 10 dev eth1 prio_tag
> > 'vlan set': bridge vlan set prio_tag on dev eth1
> >
> > I think they can behave differently only when we set untagged to
> > multiple vlans on the same port.
> >
> > 'vlan add' example with vid 10 and 20:
> > bridge vlan add vid 10 dev eth1 pvid untagged prio_tag
> > bridge vlan add vid 10 dev eth0
> > bridge vlan add vid 20 dev eth1 untagged
> > bridge vlan add vid 20 dev eth2
> >
> > VID10-tagged prio_tagged (from eth0)
> > +---------+ ---> +------------------------+ ---> +-----------------+
> > |hw switch|------|eth0 eth1|------|em1.0:end station|
> > +---------+ | Linux Bridge | ---> +-----------------+
> > +---------+ | | *untagged*
> > |hw switch|------|eth2 | (from eth2)
> > +---------+ ---> +------------------------+
> > VID20-tagged
> >
>
> This is what I was thinking of, but I was actually considering that
> untagged and prio_tag can not co-exist for the same vlan as they don't
> really make sence together anymore.
You're right.
In this case 'untagged' for 'vid 10' is no longer necessary.
>
> So one can do:
> bridge vlan add vid 10 dev eth1 pvid prio_tag
> bridge vlan add vid 20 dev eth1 untagged
>
> and recieve VLAN 10 as priority tagged and vlan 20 as untagged.
Can you make a patch set implementing this?
I'd like to re-send this patch set related to PVID with more comments
about the unresolved vlan 0 interface problem and the prospect that it
will be addressed by another patch set of yours.
Is this procedure OK with you?
Thanks,
Toshiaki Makita
>
> -vlad
>
> >
> > 'vlan set' example with vid 10 and 20:
> > bridge vlan add vid 10 dev eth1 pvid untagged
> > bridge vlan add vid 10 dev eth0
> > bridge vlan add vid 20 dev eth1 untagged
> > bridge vlan add vid 20 dev eth2
> > bridge vlan set prio_tag on dev eth1
> >
> > VID10-tagged prio_tagged (from eth0)
> > +---------+ ---> +------------------------+ ---> +-----------------+
> > |hw switch|------|eth0 eth1|------|em1.0:end station|
> > +---------+ | Linux Bridge | ---> +-----------------+
> > +---------+ | | prio_tagged
> > |hw switch|------|eth2 | (from eth2)
> > +---------+ ---> +------------------------+
> > VID20-tagged
> >
> > Em1.0 can always receive traffic from eth1 if we adopt 'vlan set'.
> > However, I cannot imagine when multiple untagged vlans is required, so
> > cannot figure out whether 'vlan add' is useful or harmful.
> > Anyway, both of approaches are OK with me.
> >
> > Thanks,
> > Toshiaki Makita
> >
> >>
> >> Thanks
> >> -vlad
> >>
> >>>
> >>> Thanks,
> >>>
> >>> Toshiaki Makita
> >>>
> >>>>
> >>>> -vlad
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Toshiaki Makita
> >>>>>
> >>>>>>
> >>>>>> -vlad
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> I think I am ok with either approach. Explicit vid 0 policy is
> >>>>>>>> easier for automatic provisioning. The flag based one is
> >>>>>>>> easier for admin/ manual provisioning.
> >>>>>>>
> >>>>>>> Supposing we have to add something to help or man in any case, I
> >>>>>>> think flag based is better. The format below seems to suitable
> >>>>>>> for a per-port policy. bridge vlan set prio_tag on dev vnet0
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> Toshiaki Makita
> >>>>>>>
> >>>>>>>>
> >>>>>>>> -vlad.
> >>>>>>>>
> >>>>>>>> -vlad
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks -vlad
> >>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Toshiaki Makita
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> How it is implemented internally in the kernel isn't as
> >>>>>>>>>>>> big of an issue. We can do it as a separate flag or as
> >>>>>>>>>>>> part of existing policy.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -vlad
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Toshiaki Makita
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -vlad
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Toshiaki Makita
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Toshiaki Makita
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -- To unsubscribe from this list: send the
> >>>>>>>>>>>>>>>>>> line "unsubscribe netdev" in the body of a
> >>>>>>>>>>>>>>>>>> message to majordomo@vger.kernel.org More
> >>>>>>>>>>>>>>>>>> majordomo info at
> >>>>>>>>>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -- To unsubscribe from this list: send the line
> >>>>>>>>>>>>>>> "unsubscribe netdev" in the body of a message to
> >>>>>>>>>>>>>>> majordomo@vger.kernel.org More majordomo info at
> >>>>>>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
>
^ permalink raw reply
* Re: [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: Eric Dumazet @ 2013-10-13 16:36 UTC (permalink / raw)
To: Vladimir Murzin; +Cc: netdev, davem, edumazet, av1474
In-Reply-To: <1381676065-2373-2-git-send-email-murzin.v@gmail.com>
On Sun, 2013-10-13 at 16:54 +0200, Vladimir Murzin wrote:
> Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
> were not passed. At the same time handlers for "any offset" cases make
> the same checks against r_addr at run-time, that will always lead to
> bpf_error.
>
> Run-time checks are still necessary for indirect load operations, but
> error path for absolute and mesh loads are worth to optimize during bpf
> compile time.
I don't get the point.
What real world use case or problem are you trying to handle ?
bpf_error returns 0, so it seems your patch does the same.
A buggy BPF program should not expect us to 'save' a few cycles.
^ permalink raw reply
* Re: IPv6 path MTU discovery broken
From: Eric Dumazet @ 2013-10-13 16:51 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: Hannes Frederic Sowa, netdev, edumazet, fan.du
In-Reply-To: <20131013104021.GB24967@sesse.net>
On Sun, 2013-10-13 at 12:40 +0200, Steinar H. Gunderson wrote:
> [resending with proper quoting and cc]
>
> On Mon, Oct 07, 2013 at 05:09:10AM +0200, Hannes Frederic Sowa wrote:
> > Could you try to check (with e.g. nstat) if any of the following counters
> > change if the icmp messages hit the host?
> >
> > TcpExtOutOfWindowIcmps
> > Icmp6InErrors
> > TcpExtTCPMinTTLDrop
> > TcpExtListenDrops
>
> Hi,
>
> I am now seeing the same problem against a 3.9.0 machine (that I've never had
> problems with before). I looked through the four nstat counters, and none of
> them are increasing. Here's /proc/net/ipv6_route from the server while it's
> going on; the client is 2001:67c:a4:1:71f9:c84b:8b2a:c65b (second line) and
> the server is 2001:67c:29f4::2007.
I am not sure, but the skb_is_gso() checks seem too lazy.
Why don't we check that gso_size+headers is below mtu, I dont know.
^ permalink raw reply
* [RFC] ipv6: always join solicited-node address
From: Bjørn Mork @ 2013-10-13 17:24 UTC (permalink / raw)
To: netdev; +Cc: Bjørn Mork
RFC 4861 section 7.2.1 "Interface Initialization" says:
When a multicast-capable interface becomes enabled, the node MUST
join the all-nodes multicast address on that interface, as well as
the solicited-node multicast address corresponding to each of the IP
addresses assigned to the interface.
The current dependency on IFF_NOARP seems unwarranted. We need to
listen on the solicited-node address whether or not we intend to
initiate Neigbour Discovery ourselves.
This fixes a bug where Linux fails to respond to received Neigbour
Solicitations on multicast capable links when IFF_NOARP is set.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
I am not at all sure about this... Comments are appreciated.
The observed problem is a MBIM mobile broadband modem sending NS
to the host. MBIM is a point-to-point USB protocol which does not
have any L2 headers at all. It can only transport IPv4 or IPv6
packets. So for IPv4 there is no question at all: ARP just
cannot be transported. The driver emulates an ethernet interface,
setting IFF_NOARP to make sure the upper layers doesn't attempt
to resolve the neighbours non-existing L2 addresses.
But then there is this modem which sends IPv6 Neigbour
Solicitations to the host over the MBIM transport. The link
layer addresses are meaningless, but it seems the modem still
expects an answer. Which we will not currently provide, because
the NS is addressed to a solicited-node address we don't listen
to.
So this patch seems like a quick-fix to that problem. But it does
change the semantics of IFF_NOARP, making us reply to NS even if
this flag is set. Which probably is wrong?
Bjørn
net/ipv6/addrconf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cd3fb30..aa2df3b 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1658,7 +1658,7 @@ void addrconf_join_solict(struct net_device *dev, const struct in6_addr *addr)
{
struct in6_addr maddr;
- if (dev->flags&(IFF_LOOPBACK|IFF_NOARP))
+ if (!(dev->flags & IFF_MULTICAST))
return;
addrconf_addr_solict_mult(addr, &maddr);
@@ -1669,7 +1669,7 @@ void addrconf_leave_solict(struct inet6_dev *idev, const struct in6_addr *addr)
{
struct in6_addr maddr;
- if (idev->dev->flags&(IFF_LOOPBACK|IFF_NOARP))
+ if (!(idev->dev->flags & IFF_MULTICAST))
return;
addrconf_addr_solict_mult(addr, &maddr);
--
1.7.10.4
^ permalink raw reply related
* Re: IPv6 path MTU discovery broken
From: Hannes Frederic Sowa @ 2013-10-13 17:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Steinar H. Gunderson, netdev, edumazet, fan.du
In-Reply-To: <1381683063.3392.46.camel@edumazet-glaptop.roam.corp.google.com>
On Sun, Oct 13, 2013 at 09:51:03AM -0700, Eric Dumazet wrote:
> On Sun, 2013-10-13 at 12:40 +0200, Steinar H. Gunderson wrote:
> > [resending with proper quoting and cc]
> >
> > On Mon, Oct 07, 2013 at 05:09:10AM +0200, Hannes Frederic Sowa wrote:
> > > Could you try to check (with e.g. nstat) if any of the following counters
> > > change if the icmp messages hit the host?
> > >
> > > TcpExtOutOfWindowIcmps
> > > Icmp6InErrors
> > > TcpExtTCPMinTTLDrop
> > > TcpExtListenDrops
> >
> > Hi,
> >
> > I am now seeing the same problem against a 3.9.0 machine (that I've never had
> > problems with before). I looked through the four nstat counters, and none of
> > them are increasing. Here's /proc/net/ipv6_route from the server while it's
> > going on; the client is 2001:67c:a4:1:71f9:c84b:8b2a:c65b (second line) and
> > the server is 2001:67c:29f4::2007.
>
> I am not sure, but the skb_is_gso() checks seem too lazy.
>
> Why don't we check that gso_size+headers is below mtu, I dont know.
Was this intended for the UFO gso thread? ;)
^ permalink raw reply
* CONTACT MY SECRETARY,
From: Musa Mohamed Ali @ 2013-10-13 18:49 UTC (permalink / raw)
Dear Friend,
I'm sorry but happy to inform you about my success in getting those
funds transferred under the cooperation of a new partner from London
though i tried my best to involve you in the business but God decided
the whole situations. Presently I’m in London for investment projects
with my own share of the total sum. Meanwhile, I didn't forget your
past efforts and attempts to assist me in transferring those funds
despite that it failed us some how.
Now contact my secretary in Burkina Faso her name is Ms. Elizabeth
Ibrahim on her e-mail address below ( miss.elizabeth0001@gmail.com )
Ask her to send you the total of $1, 000.000.00 which i kept for your
compensation for all the past efforts and attempts to assist me in
this matter. I appreciated all your efforts at that time very much. So
feel free and get in touched with my secretary Ms. Elizabeth Ibrahim.
And instruct her where to send the amount to you. Please do let me
know immediately you receive it so that we can share the joy after all
the suffer ness at that time.
in the moment, I’m very busy here because of the investment projects
which I and the new partner are having at hand, finally, remember that
I had forwarded instruction to the secretary on your behalf to receive
that money, so feel free to get in touch with Ms. Elizabeth Ibrahim.
She will send the amount to you without any delay.
Regards,
Musa.
^ permalink raw reply
* [PATCH] staging: octeon-ethernet: trivial: Avoid OOPS if phydev is not set
From: Sebastian Pöhn @ 2013-10-13 18:59 UTC (permalink / raw)
To: driverdev-devel; +Cc: support, netdev
A zero pointer deref on priv->phydev->link was causing oops on our systems.
Might be related to improper configuration but we should fail gracefully here ;-)
Signed-off-by: Sebastian Poehn <sebastian.poehn@googlemail.com>
---
diff --git a/drivers/staging/octeon/ethernet-mdio.c b/drivers/staging/octeon/ethernet-mdio.c
index 83b1030..bc8c503 100644
--- a/drivers/staging/octeon/ethernet-mdio.c
+++ b/drivers/staging/octeon/ethernet-mdio.c
@@ -121,6 +121,9 @@ static void cvm_oct_adjust_link(struct net_device *dev)
struct octeon_ethernet *priv = netdev_priv(dev);
cvmx_helper_link_info_t link_info;
+ if(!priv->phydev)
+ return ;
+
if (priv->last_link != priv->phydev->link) {
priv->last_link = priv->phydev->link;
link_info.u64 = 0;
^ permalink raw reply related
* RE: INVESTMENT/ RELOCATION ASSISTANCE. 13th/10/2013
From: Mrs. Maryann Jamila Hussein. @ 2013-10-13 19:04 UTC (permalink / raw)
To: Recipients
Dear Beloved,
I am Mrs. Maryann Jamila Hussein a Teacher and a Muslim Convert here in Syria,i had sent a previous mail which i am not sure you got. I need your assistance to invest and help me relocate my 3 kids who are 17 years and below, so that they can get a better life there in your country due to the on going crises here in Syria.
I need your trust, before the death of my husband we had a savings with an Indian Bank, so money is not the issue.
I got your reference in my search for someone who suits my
purpose.If you can help me reply, let me know.
Regards,
Mrs. Maryann Jamila Hussein.
=====================================
^ permalink raw reply
* [PATCH] net/ethernet: cpsw: Bugfix interrupts before enabling napi
From: Markus Pargmann @ 2013-10-13 19:17 UTC (permalink / raw)
To: David S. Miller
Cc: Florian Fainelli, Mugunthan V N, Peter Korsgaard,
linux-arm-kernel, netdev, kernel, Markus Pargmann
If interrupts happen before napi_enable was called, the driver will not
work as expected. Network transmissions are impossible in this state.
This bug can be reproduced easily by restarting the network interface in
a loop. After some time any network transmissions on the network
interface will fail.
This patch fixes the bug by enabling napi before enabling the network
interface interrupts.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
---
drivers/net/ethernet/ti/cpsw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 804846e..fccd9d4 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1169,9 +1169,9 @@ static int cpsw_ndo_open(struct net_device *ndev)
}
}
+ napi_enable(&priv->napi);
cpdma_ctlr_start(priv->dma);
cpsw_intr_enable(priv);
- napi_enable(&priv->napi);
cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
--
1.8.4.rc3
^ permalink raw reply related
* Re: [RFC] net: stmmac: keep RXC running in LPI mode to avoid system overload
From: Romain Baeriswyl @ 2013-10-13 20:02 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: David S. Miller, netdev, linux-kernel, Christian Ruppert
In-Reply-To: <52557606.8030201@st.com>
Hello Guiseppe,
Thanks for your answer. Please find below some details and answers.
> > In order to avoid system overload, the clock RXC from the Phy
> > should not be
> > stopped when in LPI mode.
> >
> > With the RTL8211E PHY which support EEE mode and with Apple Airport
> > Extreme that
> > supports it also, the kernel get frozen as soon as some Ethernet
> > transfers are
>
>
> hmm, I have a board with this transceiver so I could do some tests
> this could take a while, unfortunately.
>
> > on-going. System seems to be overloaded with too many interrupts.
> > The 'top'
> > command reports often around ~80% irq.
>
> do you mean lpi mac interrupts?
By disabling the LPI mode with ethtool --set-eee eth0 eee off, the
interrupt overload remains. Both counters irq_rx_path_in_lpi_mode_n and
irq_rx_path_exit_lpi_mode_n continue to run meaning the PHY continue
to put the RX path in LPI mode.
Only way I found to get ride of the overload is to keep the RX_CLK running
in LPI mode. In this configuration, the RX link still continue to go in
LPI mode and the two above counters continue to run.
> >
> > By letting the RXC clock running even in LPI mode as proposed
> > below, the issue
> > seems solved. Is it the right way to proceed?
>
> For EEE capability, RX_CLK may be halted for this reason i used it as
> default in the stmmac and never seen your issue.
>
> >
> > What is the power impact to not stop RXC in LPI mode?
>
> I can point you to "22.2.2.8a Receive direction LPI transition"
> in IEEE802-3az... where is it reported that the PHY halt the RX_CLK
> in LPI mode.
Actually the PHY "may" stop RX_CLK.
>
> May I suspect some issues on your HW? or disable it with ethtool
>
Yes, it could be HW issue. It would be very useful if you could reproduce
the setup using a SoC with "DesignWare Cores Ethernet MAC" core,
the RTL8211E PHY and an Apple Airport Extreme. The issue could well be between
the controller and the PHY.
Which Ethernet switch or router did you use to test the EEE mode?
I may try these equipments as well.
Romain
^ permalink raw reply
* Re: [PATCH] rtlwifi: Add new firmware files for rtl8188eu
From: Ben Hutchings @ 2013-10-13 20:07 UTC (permalink / raw)
To: Larry Finger; +Cc: dwmw2, netdev, linux-wireless
In-Reply-To: <52549519.1010207@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
On Tue, 2013-10-08 at 18:28 -0500, Larry Finger wrote:
> The vendor driver RTL8188EUS_linux_v4.1.4_6773.20130222 contains
> firmware in the form of data statements. This info has been extracted
> into a binary file.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> WHENCE | 9 +++++++++
> rtlwifi/rtl8188eufw.bin | Bin 0 -> 13904 bytes
> 2 files changed, 9 insertions(+)
> create mode 100644 rtlwifi/rtl8188eufw.bin
[...]
Applied, thanks.
Ben.
--
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH v2 tip/core/rcu 07/13] ipv6/ip6_tunnel: Apply rcu_access_pointer() to avoid sparse false positive
From: Hannes Frederic Sowa @ 2013-10-13 20:11 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Mathieu Desnoyers, Eric Dumazet, Josh Triplett, linux-kernel,
mingo, laijs, dipankar, akpm, niv, tglx, peterz, rostedt,
dhowells, edumazet, darren, fweisbec, sbw, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev
In-Reply-To: <20131013111439.GE5790@linux.vnet.ibm.com>
On Sun, Oct 13, 2013 at 04:14:39AM -0700, Paul E. McKenney wrote:
> On Sat, Oct 12, 2013 at 07:42:18PM +0000, Mathieu Desnoyers wrote:
> > ----- Original Message -----
> > > On Sat, Oct 12, 2013 at 06:43:45PM +0200, Hannes Frederic Sowa wrote:
> > > > Regarding the volatile access, I hope that the C11 memory model
> > > > and enhancements to the compiler will some day provide a better
> > > > way to express the semantics of what is tried to express here
> > > > (__atomic_store_n/__atomic_load_n with the accompanied memory model,
> > > > which could be even weaker to what a volatile access would enfore
> > > > now and could guarantee atomic stores/loads).
> > >
> > > I just played around a bit more. Perhaps we could try to warn of silly
> > > usages of ACCESS_ONCE():
> > >
> > > --- a/include/linux/compiler.h
> > > +++ b/include/linux/compiler.h
> > > @@ -349,7 +349,11 @@ void ftrace_likely_update(struct ftrace_branch_data *f,
> > > int val, int expect);
> > > * use is to mediate communication between process-level code and irq/NMI
> > > * handlers, all running on the same CPU.
> > > */
> > > -#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
> > > +#define ACCESS_ONCE(x) (*({ \
> > > + compiletime_assert(sizeof(typeof(x)) <= sizeof(typeof(&x)), \
> > > + "ACCESS_ONCE likely not atomic"); \
> >
> > AFAIU, ACCESS_ONCE() is not meant to ensure atomicity of load/store,
> > but rather merely ensures that the compiler will not merge nor refetch
> > accesses. I don't think the assert check you propose is appropriate with
> > respect to the ACCESS_ONCE() semantic.
>
> I am with Mathieu on this one, at least unless there is some set of actual
> bugs already in the kernel that these length checks would find.
I guess my wording of "ACCESS_ONCE likely not atomic" was misplaced. Something
like volatile access to memory larger than the processor register size is
probably not what you intended. Use atomics or proper locking. ;)
And maybe that is not even correct.
> /me wonders about structs of size 3, 5, 6, and 7...
Checked a x86_64 allyesconfig build with sizes above pointer size and odd
parity and nothing broke.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH 1/2] net: Add layer 2 hardware acceleration operations for macvlan devices
From: John Fastabend @ 2013-10-13 20:46 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, Andy Gospodarek, David Miller
In-Reply-To: <1381517037-26007-2-git-send-email-nhorman@tuxdriver.com>
On 10/11/2013 11:43 AM, Neil Horman wrote:
> Add a operations structure that allows a network interface to export the fact
> that it supports package forwarding in hardware between physical interfaces and
> other mac layer devices assigned to it (such as macvlans). this operaions
> structure can be used by virtual mac devices to bypass software switching so
> that forwarding can be done in hardware more efficiently.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: john.fastabend@gmail.com
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: "David S. Miller" <davem@davemloft.net>
> ---
[...]
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 2ddb48d..1710fdb 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -426,9 +426,9 @@ struct sk_buff {
> char cb[48] __aligned(8);
>
> unsigned long _skb_refdst;
> -#ifdef CONFIG_XFRM
> +
Is this a hold-over from the previous patches? 'sp' isn't touched
anywhere else so put the ifdef/endif back.
> struct sec_path *sp;
> -#endif
> +
> unsigned int len,
> data_len;
> __u16 mac_len,
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 5c713f2..ecad8c2 100644
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH 2/2] ixgbe: enable l2 forwarding acceleration for macvlans
From: John Fastabend @ 2013-10-13 20:48 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, Andy Gospodarek, David Miller
In-Reply-To: <1381517037-26007-3-git-send-email-nhorman@tuxdriver.com>
On 10/11/2013 11:43 AM, Neil Horman wrote:
> Now that l2 acceleration ops are in place from the prior patch, enable ixgbe to
> take advantage of these operations. Allow it to allocate queues for a macvlan
> so that when we transmit a frame, we can do the switching in hardware inside the
> ixgbe card, rather than in software.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: john.fastabend@gmail.com
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: "David S. Miller" <davem@davemloft.net>
> ---
Neil, I'm fairly sure I can simplify this patch further. I'll be able
to take a shot at it Tuesday if you don't mind waiting.
I can resubmit the series then and preserve your signed-off on at least
the first patch. Seem reasonable?
.John
--
John Fastabend Intel Corporation
^ 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