* Re: [PATCH v2 2/6] ethernet/intel: Use eth_skb_pad and skb_put_padto helpers
From: Jeff Kirsher @ 2014-12-03 19:25 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, davem
In-Reply-To: <20141203161739.9223.52060.stgit@ahduyck-vm-fedora20>
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
On Wed, 2014-12-03 at 08:17 -0800, Alexander Duyck wrote:
> Update the Intel Ethernet drivers to use eth_skb_pad() and
> skb_put_padto
> instead of doing their own implementations of the function.
>
> Also this cleans up two other spots where skb_pad was called but the
> length
> and tail pointers were being manipulated directly instead of just
> having
> the padding length added via __skb_put.
>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> ---
> drivers/net/ethernet/intel/e1000/e1000_main.c | 8 ++------
> drivers/net/ethernet/intel/e1000e/netdev.c | 8 ++------
> drivers/net/ethernet/intel/fm10k/fm10k_main.c | 11 +++--------
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 8 ++------
> drivers/net/ethernet/intel/igb/igb_main.c | 19
> +++++--------------
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 19
> +++++--------------
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 11 +++--------
> 7 files changed, 22 insertions(+), 62 deletions(-)
Since this is a part of a series, no need to break it up, by having me
only pull in this one patch.
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* pull request: wireless 2014-12-03
From: John W. Linville @ 2014-12-03 20:34 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 5864 bytes --]
Dave,
One last(?) batch of fixes hoping to make 3.18...
In this episode, we have another trio of rtlwifi fixes
repairing a little more damage from the major update of the
rtlwifi-family of drivers. These editing mistakes caused some
memory corruption and missed a flag critical to proper interrupt
handling. Together, these fix the kernel regression reported at
https://bugzilla.kernel.org/show_bug.cgi?id=88951 by Catalin Iacob.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 7d63a5f9b25ba6b130da8eb2d32a72b1462d0249:
rtlwifi: Change order in device startup (2014-11-25 14:22:22 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git tags/master-2014-12-01
for you to fetch changes up to 87141db0848aa20c43d453f5545efc8f390d4372:
rtlwifi: rtl8192ce: Fix missing interrupt ready flag (2014-12-01 15:22:02 -0500)
----------------------------------------------------------------
Larry Finger (3):
rtlwifi: rtl8192ce: Fix editing error that causes silent memory corruption
rtlwifi: rtl8192ce: Fix kernel crashes due to missing callback entry
rtlwifi: rtl8192ce: Fix missing interrupt ready flag
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 3 ++-
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 3 +++
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 24 ++++++++++++++++++++----
drivers/net/wireless/rtlwifi/rtl8192ce/trx.h | 2 ++
4 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index 55357d69397a..d2ec5160bbf0 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -1287,6 +1287,7 @@ void rtl92ce_enable_interrupt(struct ieee80211_hw *hw)
rtl_write_dword(rtlpriv, REG_HIMR, rtlpci->irq_mask[0] & 0xFFFFFFFF);
rtl_write_dword(rtlpriv, REG_HIMRE, rtlpci->irq_mask[1] & 0xFFFFFFFF);
+ rtlpci->irq_enabled = true;
}
void rtl92ce_disable_interrupt(struct ieee80211_hw *hw)
@@ -1296,7 +1297,7 @@ void rtl92ce_disable_interrupt(struct ieee80211_hw *hw)
rtl_write_dword(rtlpriv, REG_HIMR, IMR8190_DISABLED);
rtl_write_dword(rtlpriv, REG_HIMRE, IMR8190_DISABLED);
- synchronize_irq(rtlpci->pdev->irq);
+ rtlpci->irq_enabled = false;
}
static void _rtl92ce_poweroff_adapter(struct ieee80211_hw *hw)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
index 46ea07605eb4..dd5aa089126a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
@@ -228,6 +228,7 @@ static struct rtl_hal_ops rtl8192ce_hal_ops = {
.led_control = rtl92ce_led_control,
.set_desc = rtl92ce_set_desc,
.get_desc = rtl92ce_get_desc,
+ .is_tx_desc_closed = rtl92ce_is_tx_desc_closed,
.tx_polling = rtl92ce_tx_polling,
.enable_hw_sec = rtl92ce_enable_hw_security_config,
.set_key = rtl92ce_set_key,
@@ -271,6 +272,8 @@ static struct rtl_hal_cfg rtl92ce_hal_cfg = {
.maps[MAC_RCR_ACRC32] = ACRC32,
.maps[MAC_RCR_ACF] = ACF,
.maps[MAC_RCR_AAP] = AAP,
+ .maps[MAC_HIMR] = REG_HIMR,
+ .maps[MAC_HIMRE] = REG_HIMRE,
.maps[EFUSE_TEST] = REG_EFUSE_TEST,
.maps[EFUSE_CTRL] = REG_EFUSE_CTRL,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
index dc3d20b17a26..e88dcd0e0af1 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c
@@ -720,16 +720,15 @@ u32 rtl92ce_get_desc(u8 *p_desc, bool istx, u8 desc_name)
break;
}
} else {
- struct rx_desc_92c *pdesc = (struct rx_desc_92c *)p_desc;
switch (desc_name) {
case HW_DESC_OWN:
- ret = GET_RX_DESC_OWN(pdesc);
+ ret = GET_RX_DESC_OWN(p_desc);
break;
case HW_DESC_RXPKT_LEN:
- ret = GET_RX_DESC_PKT_LEN(pdesc);
+ ret = GET_RX_DESC_PKT_LEN(p_desc);
break;
case HW_DESC_RXBUFF_ADDR:
- ret = GET_RX_STATUS_DESC_BUFF_ADDR(pdesc);
+ ret = GET_RX_DESC_BUFF_ADDR(p_desc);
break;
default:
RT_ASSERT(false, "ERR rxdesc :%d not process\n",
@@ -740,6 +739,23 @@ u32 rtl92ce_get_desc(u8 *p_desc, bool istx, u8 desc_name)
return ret;
}
+bool rtl92ce_is_tx_desc_closed(struct ieee80211_hw *hw,
+ u8 hw_queue, u16 index)
+{
+ struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
+ struct rtl8192_tx_ring *ring = &rtlpci->tx_ring[hw_queue];
+ u8 *entry = (u8 *)(&ring->desc[ring->idx]);
+ u8 own = (u8)rtl92ce_get_desc(entry, true, HW_DESC_OWN);
+
+ /*beacon packet will only use the first
+ *descriptor defautly,and the own may not
+ *be cleared by the hardware
+ */
+ if (own)
+ return false;
+ return true;
+}
+
void rtl92ce_tx_polling(struct ieee80211_hw *hw, u8 hw_queue)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
index 9a39ec4204dd..4bec4b07e3e0 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
@@ -723,6 +723,8 @@ bool rtl92ce_rx_query_desc(struct ieee80211_hw *hw,
void rtl92ce_set_desc(struct ieee80211_hw *hw, u8 *pdesc, bool istx,
u8 desc_name, u8 *val);
u32 rtl92ce_get_desc(u8 *pdesc, bool istx, u8 desc_name);
+bool rtl92ce_is_tx_desc_closed(struct ieee80211_hw *hw,
+ u8 hw_queue, u16 index);
void rtl92ce_tx_polling(struct ieee80211_hw *hw, u8 hw_queue);
void rtl92ce_tx_fill_cmddesc(struct ieee80211_hw *hw, u8 *pdesc,
bool b_firstseg, bool b_lastseg,
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
From: Pravin Shelar @ 2014-12-03 19:45 UTC (permalink / raw)
To: Joe Stringer; +Cc: Linux Kernel, dev@openvswitch.org, Linux Netdev List
In-Reply-To: <CANr6G5z-kokWkBs3bb=bXrBmBUhaqHKH1QfeXycFWxSNf00qFw@mail.gmail.com>
On Wed, Dec 3, 2014 at 10:47 AM, Joe Stringer <joestringer@nicira.com> wrote:
> I forgot to mention that this is the first post based against net-next.
>
> On 2 December 2014 at 18:56, Joe Stringer <joestringer@nicira.com> wrote:
>> <....snip...>
>> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
>> index a8b30f3..7f31dbf 100644
>> --- a/net/openvswitch/flow.h
>> +++ b/net/openvswitch/flow.h
>> @@ -197,6 +197,13 @@ struct sw_flow_match {
>> struct sw_flow_mask *mask;
>> };
>>
>> +#define MAX_UFID_LENGTH 256
>> +
>> +struct sw_flow_id {
>> + u32 ufid_len;
>> + u32 ufid[MAX_UFID_LENGTH / 4];
>> +};
>> +
>> struct sw_flow_actions {
>> struct rcu_head rcu;
>> u32 actions_len;
>
> Pravin, I changed the 'struct sw_flow_id' to the above after feedback
> from the previous round, but it doesn't seem quite right. Is this what
> you meant? Given that current ovs-vswitchd userspace only generates
> 128bit UFIDs, it seems wasteful to be allocating so much for this. Did
> you have in mind for this to be united with the unmasked_key?
I am fine with 128bits of ufid, we can extend it later if we need it.
But what do you mean by united unmasked key? Can you define the struct
here?
^ permalink raw reply
* Re: [PATCH net-next] tc_act: export uapi header file
From: Jiri Pirko @ 2014-12-03 19:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jamal Hadi Salim, David Miller, netdev
In-Reply-To: <20141203093317.3c482872@urahara>
Wed, Dec 03, 2014 at 06:33:17PM CET, stephen@networkplumber.org wrote:
>This file is used by iproute2 and should be exported.
>
>Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Jiri Pirko <jiri@resnulli.us>
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Jesse Gross @ 2014-12-03 19:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Thomas Graf, Du, Fan, Jason Wang, netdev@vger.kernel.org,
davem@davemloft.net, fw@strlen.de, dev@openvswitch.org,
Pravin Shelar
In-Reply-To: <20141203183859.GB16447@redhat.com>
On Wed, Dec 3, 2014 at 10:38 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, Dec 03, 2014 at 10:07:42AM -0800, Jesse Gross wrote:.
>> ICMP can't be the complete solution in any case because it only works
>> for IP traffic.
>
> Let's be specific please. What protocols do you most care about? IPX?
>
>> I think there are only two full solutions: find a way
>> to adjust the guest MTU to the minimum MTU that its traffic could hit
>> in an L2 domain or fragmentation. ICMP could be a possible
>> optimization in the fragmentation case.
>
> Both approaches seem strange. You are sending 1 packet an hour to
> some destination behind 100 tunnels. Why would you want to
> cut down your MTU for all packets? On the other hand,
> doubling the amount of packets because your MTU is off
> by a couple of bytes will hurt performance significantly.
>
> Still, if you want to cut down the MTU within guest,
> that's only an ifconfig away.
> Most people would not want to bother, I think it's a good
> idea to make PMTU work properly for them.
I care about correctness first, which means that an Ethernet link
being exposed to the guest should behave like Ethernet. So, yes, IPX
should work if somebody chooses to do that.
Your comments are about performance optimization. That's fine but
without a correct base to start from it seems like putting the cart
before the horse and is hard to reason about.
^ permalink raw reply
* Re: [PATCHv11 net-next 1/2] openvswitch: Refactor ovs_nla_fill_match().
From: Pravin Shelar @ 2014-12-03 19:37 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev, LKML, dev@openvswitch.org
In-Reply-To: <1417575363-13770-1-git-send-email-joestringer@nicira.com>
On Tue, Dec 2, 2014 at 6:56 PM, Joe Stringer <joestringer@nicira.com> wrote:
> Refactor the ovs_nla_fill_match() function into separate netlink
> serialization functions ovs_nla_put_{unmasked_key,masked_key,mask}().
> Modify ovs_nla_put_flow() to handle attribute nesting and expose the
> 'is_mask' parameter - all callers need to nest the flow, and callers
> have better knowledge about whether it is serializing a mask or not.
> The next patch will be the first user of ovs_nla_put_masked_key().
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
Thanks for the refactoring. code looks better now.
> ---
> v11: Shift netlink serialization of key/mask to flow_netlink.c
> Add put_{unmasked_key,key,mask} helpers.
> Perform nesting in ovs_nla_put_flow().
> v10: First post.
> ---
> net/openvswitch/datapath.c | 41 ++++++------------------------------
> net/openvswitch/flow_netlink.c | 45 +++++++++++++++++++++++++++++++++++++---
> net/openvswitch/flow_netlink.h | 8 +++++--
> 3 files changed, 54 insertions(+), 40 deletions(-)
>
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 332b5a0..b2a3796 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -462,10 +462,8 @@ static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb,
> 0, upcall_info->cmd);
> upcall->dp_ifindex = dp_ifindex;
>
> - nla = nla_nest_start(user_skb, OVS_PACKET_ATTR_KEY);
> - err = ovs_nla_put_flow(key, key, user_skb);
> + err = ovs_nla_put_flow(key, key, OVS_PACKET_ATTR_KEY, false, user_skb);
We need different name here, since it does not operate on flow. maybe
__ovs_nla_put_key(). we can move the function definition to
flow_netlink.h
> BUG_ON(err);
> - nla_nest_end(user_skb, nla);
>
> if (upcall_info->userdata)
> __nla_put(user_skb, OVS_PACKET_ATTR_USERDATA,
> @@ -676,37 +674,6 @@ static size_t ovs_flow_cmd_msg_size(const struct sw_flow_actions *acts)
> }
>
> /* Called with ovs_mutex or RCU read lock. */
> -static int ovs_flow_cmd_fill_match(const struct sw_flow *flow,
> - struct sk_buff *skb)
> -{
> - struct nlattr *nla;
> - int err;
> -
> - /* Fill flow key. */
> - nla = nla_nest_start(skb, OVS_FLOW_ATTR_KEY);
> - if (!nla)
> - return -EMSGSIZE;
> -
> - err = ovs_nla_put_flow(&flow->unmasked_key, &flow->unmasked_key, skb);
> - if (err)
> - return err;
> -
> - nla_nest_end(skb, nla);
> -
> - /* Fill flow mask. */
> - nla = nla_nest_start(skb, OVS_FLOW_ATTR_MASK);
> - if (!nla)
> - return -EMSGSIZE;
> -
> - err = ovs_nla_put_flow(&flow->key, &flow->mask->key, skb);
> - if (err)
> - return err;
> -
> - nla_nest_end(skb, nla);
> - return 0;
> -}
> -
> -/* Called with ovs_mutex or RCU read lock. */
> static int ovs_flow_cmd_fill_stats(const struct sw_flow *flow,
> struct sk_buff *skb)
> {
> @@ -787,7 +754,11 @@ static int ovs_flow_cmd_fill_info(const struct sw_flow *flow, int dp_ifindex,
>
> ovs_header->dp_ifindex = dp_ifindex;
>
> - err = ovs_flow_cmd_fill_match(flow, skb);
> + err = ovs_nla_put_unmasked_key(flow, skb);
> + if (err)
> + goto error;
> +
> + err = ovs_nla_put_mask(flow, skb);
> if (err)
> goto error;
>
> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> index df3c7f2..7bb571f 100644
> --- a/net/openvswitch/flow_netlink.c
> +++ b/net/openvswitch/flow_netlink.c
> @@ -1131,12 +1131,12 @@ int ovs_nla_get_flow_metadata(const struct nlattr *attr,
> return metadata_from_nlattrs(&match, &attrs, a, false, log);
> }
>
> -int ovs_nla_put_flow(const struct sw_flow_key *swkey,
> - const struct sw_flow_key *output, struct sk_buff *skb)
> +int __ovs_nla_put_flow(const struct sw_flow_key *swkey,
> + const struct sw_flow_key *output, bool is_mask,
> + struct sk_buff *skb)
> {
> struct ovs_key_ethernet *eth_key;
> struct nlattr *nla, *encap;
> - bool is_mask = (swkey != output);
>
> if (nla_put_u32(skb, OVS_KEY_ATTR_RECIRC_ID, output->recirc_id))
> goto nla_put_failure;
> @@ -1346,6 +1346,45 @@ nla_put_failure:
> return -EMSGSIZE;
> }
>
> +int ovs_nla_put_flow(const struct sw_flow_key *swkey,
> + const struct sw_flow_key *output, int attr, bool is_mask,
> + struct sk_buff *skb)
> +{
> + int err;
> + struct nlattr *nla;
> +
> + nla = nla_nest_start(skb, attr);
> + if (!nla)
> + return -EMSGSIZE;
> + err = __ovs_nla_put_flow(swkey, output, is_mask, skb);
> + if (err)
> + return err;
> + nla_nest_end(skb, nla);
> +
> + return 0;
> +}
> +
> +/* Called with ovs_mutex or RCU read lock. */
> +int ovs_nla_put_unmasked_key(const struct sw_flow *flow, struct sk_buff *skb)
> +{
> + return ovs_nla_put_flow(&flow->unmasked_key, &flow->unmasked_key,
> + OVS_FLOW_ATTR_KEY, false, skb);
> +}
> +
> +/* Called with ovs_mutex or RCU read lock. */
> +int ovs_nla_put_masked_key(const struct sw_flow *flow, struct sk_buff *skb)
> +{
> + return ovs_nla_put_flow(&flow->mask->key, &flow->key,
> + OVS_FLOW_ATTR_KEY, false, skb);
> +}
> +
> +/* Called with ovs_mutex or RCU read lock. */
> +int ovs_nla_put_mask(const struct sw_flow *flow, struct sk_buff *skb)
> +{
> + return ovs_nla_put_flow(&flow->key, &flow->mask->key,
> + OVS_FLOW_ATTR_MASK, true, skb);
> +}
> +
> #define MAX_ACTIONS_BUFSIZE (32 * 1024)
>
> static struct sw_flow_actions *nla_alloc_flow_actions(int size, bool log)
> diff --git a/net/openvswitch/flow_netlink.h b/net/openvswitch/flow_netlink.h
> index 577f12b..ea54564 100644
> --- a/net/openvswitch/flow_netlink.h
> +++ b/net/openvswitch/flow_netlink.h
> @@ -43,11 +43,15 @@ size_t ovs_key_attr_size(void);
> void ovs_match_init(struct sw_flow_match *match,
> struct sw_flow_key *key, struct sw_flow_mask *mask);
>
> -int ovs_nla_put_flow(const struct sw_flow_key *,
> - const struct sw_flow_key *, struct sk_buff *);
> +int ovs_nla_put_flow(const struct sw_flow_key *, const struct sw_flow_key *,
> + int attr, bool is_mask, struct sk_buff *);
> int ovs_nla_get_flow_metadata(const struct nlattr *, struct sw_flow_key *,
> bool log);
>
> +int ovs_nla_put_unmasked_key(const struct sw_flow *flow, struct sk_buff *skb);
> +int ovs_nla_put_masked_key(const struct sw_flow *flow, struct sk_buff *skb);
> +int ovs_nla_put_mask(const struct sw_flow *flow, struct sk_buff *skb);
> +
> int ovs_nla_get_match(struct sw_flow_match *, const struct nlattr *key,
> const struct nlattr *mask, bool log);
> int ovs_nla_put_egress_tunnel_key(struct sk_buff *,
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net-next v3] rtnetlink: delay RTM_DELLINK notification until after ndo_uninit()
From: Mahesh Bandewar @ 2014-12-03 19:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, David Miller, Eric Dumazet, Roopa Prabhu, Toshiaki Makita
In-Reply-To: <1417592357.5303.130.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Dec 2, 2014 at 11:39 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-12-02 at 23:24 -0800, Mahesh Bandewar wrote:
>
>> +EXPORT_SYMBOL(rtmsg_ifinfo_build_skb);
>> +
>> +void rtmsg_ifinfo_send(struct sk_buff *skb, struct net_device *dev, gfp_t flags)
>> +{
>> + struct net *net = dev_net(dev);
>> +
>> + rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL, flags);
>> +}
>> +EXPORT_SYMBOL(rtmsg_ifinfo_send);
>> +
>> +void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change,
>> + gfp_t flags)
>> +{
>> + struct sk_buff *skb;
>> +
>> + skb = rtmsg_ifinfo_build_skb(type, dev, change, flags);
>> + if (skb)
>> + rtmsg_ifinfo_send(skb, dev, flags);
>> }
>> EXPORT_SYMBOL(rtmsg_ifinfo);
>
> One last point :
>
> Only rtmsg_ifinfo() needs the EXPORT_SYMBOL(...)
>
> rtmsg_ifinfo_build_skb() and rtmsg_ifinfo_send() are used from core networking stack,
> not a module.
>
Thanks Eric. If we ever need that in a module in the future, we can
add that later. Will remove them.
>
>
^ permalink raw reply
* Re: [PATCH v2 5/6] myri10ge: use eth_skb_pad helper
From: Sergei Shtylyov @ 2014-12-03 18:56 UTC (permalink / raw)
To: Alexander Duyck, netdev; +Cc: Hyong-Youb Kim, davem
In-Reply-To: <20141203161758.9223.85476.stgit@ahduyck-vm-fedora20>
Hello.
On 12/03/2014 07:17 PM, Alexander Duyck wrote:
> Update myri10ge to use eth_skb_pad helper. This also corrects a minor
> issue as the driver was updating length without updating the tail pointer.
> Cc: Hyong-Youb Kim <hykim@myri.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> ---
> drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
> diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
> index 9e7e3f1..af09905 100644
> --- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
> +++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
> @@ -2913,16 +2913,11 @@ again:
> flags |= MXGEFW_FLAGS_SMALL;
>
> /* pad frames to at least ETH_ZLEN bytes */
> - if (unlikely(skb->len < ETH_ZLEN)) {
> - if (skb_padto(skb, ETH_ZLEN)) {
> - /* The packet is gone, so we must
> - * return 0 */
> - ss->stats.tx_dropped += 1;
> - return NETDEV_TX_OK;
> - }
> - /* adjust the len to account for the zero pad
> - * so that the nic can know how long it is */
> - skb->len = ETH_ZLEN;
> + if (eth_skb_pad(skb)) {
> + /* The packet is gone, so we must
> + * return 0 */
Time to fix the comment style, perhaps? The preferred one for the
networking code is:
/* bla
* bla
*/
> + ss->stats.tx_dropped += 1;
Hm, why not 'ss->stats.tx_dropped++'?
> + return NETDEV_TX_OK;
> }
> }
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Rick Jones @ 2014-12-03 18:56 UTC (permalink / raw)
To: Michael S. Tsirkin, Jesse Gross
Cc: Thomas Graf, Du, Fan, Jason Wang, netdev@vger.kernel.org,
davem@davemloft.net, fw@strlen.de, dev@openvswitch.org,
Pravin Shelar
In-Reply-To: <20141203183859.GB16447@redhat.com>
Trying to "fake-out" an ICMP message to paper-over "devices" in the
"middle" of same Layer2 network having different MTUs from the ends goes
back to at least the days when people started joining FDDI networks to
Ethernet networks with bridges rather than routers. Perhaps back even
further. It had problems them (including not all traffic being IP), I
doubt today would be any different.
All devices in a Layer2 network must have the same MTU. (*)
The only exception to that which does not lead one down a rathole is
that you can have the MTU at the "edges" of the Layer 2 network be
smaller than the MTU in the "middle." And then only if the middle
"never" tries to talk itself to the edges directly.
rick jones
(*) Or at least any communicating device must be kept ignorant of what
one does to have a smaller MTU in there somewhere.
^ permalink raw reply
* Re: [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
From: Joe Stringer @ 2014-12-03 18:47 UTC (permalink / raw)
To: Pravin Shelar; +Cc: Linux Kernel, dev@openvswitch.org, Linux Netdev List
In-Reply-To: <1417575363-13770-2-git-send-email-joestringer@nicira.com>
I forgot to mention that this is the first post based against net-next.
On 2 December 2014 at 18:56, Joe Stringer <joestringer@nicira.com> wrote:
> <....snip...>
> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
> index a8b30f3..7f31dbf 100644
> --- a/net/openvswitch/flow.h
> +++ b/net/openvswitch/flow.h
> @@ -197,6 +197,13 @@ struct sw_flow_match {
> struct sw_flow_mask *mask;
> };
>
> +#define MAX_UFID_LENGTH 256
> +
> +struct sw_flow_id {
> + u32 ufid_len;
> + u32 ufid[MAX_UFID_LENGTH / 4];
> +};
> +
> struct sw_flow_actions {
> struct rcu_head rcu;
> u32 actions_len;
Pravin, I changed the 'struct sw_flow_id' to the above after feedback
from the previous round, but it doesn't seem quite right. Is this what
you meant? Given that current ovs-vswitchd userspace only generates
128bit UFIDs, it seems wasteful to be allocating so much for this. Did
you have in mind for this to be united with the unmasked_key?
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Michael S. Tsirkin @ 2014-12-03 18:38 UTC (permalink / raw)
To: Jesse Gross
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Wang,
Du, Fan, fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <CAEP_g=9C+D3gbjJ4n1t6xuyjqEAMYi4ZfqPoe92UAoQJH-UsKg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Dec 03, 2014 at 10:07:42AM -0800, Jesse Gross wrote:
> On Wed, Dec 3, 2014 at 1:03 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Tue, Dec 02, 2014 at 10:12:04AM -0800, Jesse Gross wrote:
> >> On Tue, Dec 2, 2014 at 9:41 AM, Thomas Graf <tgraf@suug.ch> wrote:
> >> > On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote:
> >> >> On Tue, Dec 02, 2014 at 05:09:27PM +0000, Thomas Graf wrote:
> >> >> > On 12/02/14 at 01:48pm, Flavio Leitner wrote:
> >> >> > > What about containers or any other virtualization environment that
> >> >> > > doesn't use Virtio?
> >> >> >
> >> >> > The host can dictate the MTU in that case for both veth or OVS
> >> >> > internal which would be primary container plumbing techniques.
> >> >>
> >> >> It typically can't do this easily for VMs with emulated devices:
> >> >> real ethernet uses a fixed MTU.
> >> >>
> >> >> IMHO it's confusing to suggest MTU as a fix for this bug, it's
> >> >> an unrelated optimization.
> >> >> ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED is the right fix here.
> >> >
> >> > PMTU discovery only resolves the issue if an actual IP stack is
> >> > running inside the VM. This may not be the case at all.
> >>
> >> It's also only really a correct thing to do if the ICMP packet is
> >> coming from an L3 node. If you are doing straight bridging then you
> >> have to resort to hacks like OVS had before, which I agree are not
> >> particularly desirable.
> >
> > The issue seems to be that fundamentally, this is
> > bridging interfaces with variable MTUs (even if MTU values
> > on devices don't let us figure this out)-
> > that is already not straight bridging, and
> > I would argue sending ICMPs back is the right thing to do.
>
> How do you deal with the fact that there is no host IP stack inside
> the tunnel? And isn't this exactly the same as the former OVS
> implementation that you said you didn't like?
I was talking about the high level requirement, not the implementation
here. I agree it's not at all trivial, we need to propagate this across
tunnels.
But let's agree on what we are trying to accomplish first.
> >> > I agree that exposing an MTU towards the guest is not applicable
> >> > in all situations, in particular because it is difficult to decide
> >> > what MTU to expose. It is a relatively elegant solution in a lot
> >> > of virtualization host cases hooked up to an orchestration system
> >> > though.
> >>
> >> I also think this is the right thing to do as a common case
> >> optimization and I know other platforms (such as Hyper-V) do it. It's
> >> not a complete solution so we still need the original patch in this
> >> thread to handle things transparently.
> >
> > Well, as I believe David (and independently Jason) is saying, it looks like
> > the ICMPs we are sending back after applying the original patch have the
> > wrong MTU.
>
> The problem is actually that the ICMP messages won't even go to the
> sending VM because the host IP stack and the VM are isolated from each
> other and there is no route.
Exactly.
But all this is talking about implementation.
Let's agree on what we want to do first.
And in my mind, we typically want originator to adjust its PMTU,
just for a given destination.
Sending ICMP to originating VM will typically accomplish this.
> > And if I understand what David is saying here, IP is also the wrong place to
> > do it.
>
> ICMP can't be the complete solution in any case because it only works
> for IP traffic.
Let's be specific please. What protocols do you most care about? IPX?
> I think there are only two full solutions: find a way
> to adjust the guest MTU to the minimum MTU that its traffic could hit
> in an L2 domain or fragmentation. ICMP could be a possible
> optimization in the fragmentation case.
Both approaches seem strange. You are sending 1 packet an hour to
some destination behind 100 tunnels. Why would you want to
cut down your MTU for all packets? On the other hand,
doubling the amount of packets because your MTU is off
by a couple of bytes will hurt performance significantly.
Still, if you want to cut down the MTU within guest,
that's only an ifconfig away.
Most people would not want to bother, I think it's a good
idea to make PMTU work properly for them.
--
MST
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: bcmgenet: add support for new GENET PHY revision scheme
From: Sergei Shtylyov @ 2014-12-03 18:12 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: davem
In-Reply-To: <547F4E4E.5030906@gmail.com>
Hello.
On 12/03/2014 08:54 PM, Florian Fainelli wrote:
>>> Starting with GPHY revision G0, the GENET register layout has changed to
>>> use the same numbering scheme as the Starfighter 2 switch. This means
>>> that GPHY major revision is in bits 15:12, minor in bits 11:8 and patch
>>> level is in bits 7:4.
>>> Introduce a small heuristic which checks for the old scheme first, tests
>>> for the new scheme and finally attempts to catch reserved values and
>>> aborts.
>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>> ---
>>> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 24
>>> +++++++++++++++++++++++-
>>> 1 file changed, 23 insertions(+), 1 deletion(-)
>>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>> b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>> index f2fadb053d52..23e283174c4e 100644
>>> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>>> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> [...]
>>> @@ -2551,8 +2552,29 @@ static void bcmgenet_set_hw_params(struct
[...]
>>> + if ((gphy_rev & 0xf0) != 0)
>>> + priv->gphy_rev = gphy_rev << 8;
>>> +
>>> + /* This is the new scheme, GPHY major rolls over with 0x10 = rev
>>> G0 */
>>> + else if ((gphy_rev & 0xff00) != 0)
>>> + priv->gphy_rev = gphy_rev;
>>> +
>>> + /* This is reserved so should require special treatment */
>>> + else if (gphy_rev == 0 || gphy_rev == 0x01ff) {
>>> + pr_warn("Invalid GPHY revision detected: 0x%04x\n", gphy_rev);
>>> + return;
>>> + }
>>
>> Hm, {} are needed on all *if* branches.
> checkpatch.pl did not complain about that.
It probably still doesn't. Nevertheless, refer to
Documentation/CodingStyle, chapter 3.
>> [...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Jesse Gross @ 2014-12-03 18:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Thomas Graf, Du, Fan, Jason Wang, netdev@vger.kernel.org,
davem@davemloft.net, fw@strlen.de, dev@openvswitch.org,
Pravin Shelar
In-Reply-To: <20141203090339.GA9299@redhat.com>
On Wed, Dec 3, 2014 at 1:03 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Dec 02, 2014 at 10:12:04AM -0800, Jesse Gross wrote:
>> On Tue, Dec 2, 2014 at 9:41 AM, Thomas Graf <tgraf@suug.ch> wrote:
>> > On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote:
>> >> On Tue, Dec 02, 2014 at 05:09:27PM +0000, Thomas Graf wrote:
>> >> > On 12/02/14 at 01:48pm, Flavio Leitner wrote:
>> >> > > What about containers or any other virtualization environment that
>> >> > > doesn't use Virtio?
>> >> >
>> >> > The host can dictate the MTU in that case for both veth or OVS
>> >> > internal which would be primary container plumbing techniques.
>> >>
>> >> It typically can't do this easily for VMs with emulated devices:
>> >> real ethernet uses a fixed MTU.
>> >>
>> >> IMHO it's confusing to suggest MTU as a fix for this bug, it's
>> >> an unrelated optimization.
>> >> ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED is the right fix here.
>> >
>> > PMTU discovery only resolves the issue if an actual IP stack is
>> > running inside the VM. This may not be the case at all.
>>
>> It's also only really a correct thing to do if the ICMP packet is
>> coming from an L3 node. If you are doing straight bridging then you
>> have to resort to hacks like OVS had before, which I agree are not
>> particularly desirable.
>
> The issue seems to be that fundamentally, this is
> bridging interfaces with variable MTUs (even if MTU values
> on devices don't let us figure this out)-
> that is already not straight bridging, and
> I would argue sending ICMPs back is the right thing to do.
How do you deal with the fact that there is no host IP stack inside
the tunnel? And isn't this exactly the same as the former OVS
implementation that you said you didn't like?
>> > I agree that exposing an MTU towards the guest is not applicable
>> > in all situations, in particular because it is difficult to decide
>> > what MTU to expose. It is a relatively elegant solution in a lot
>> > of virtualization host cases hooked up to an orchestration system
>> > though.
>>
>> I also think this is the right thing to do as a common case
>> optimization and I know other platforms (such as Hyper-V) do it. It's
>> not a complete solution so we still need the original patch in this
>> thread to handle things transparently.
>
> Well, as I believe David (and independently Jason) is saying, it looks like
> the ICMPs we are sending back after applying the original patch have the
> wrong MTU.
The problem is actually that the ICMP messages won't even go to the
sending VM because the host IP stack and the VM are isolated from each
other and there is no route.
> And if I understand what David is saying here, IP is also the wrong place to
> do it.
ICMP can't be the complete solution in any case because it only works
for IP traffic. I think there are only two full solutions: find a way
to adjust the guest MTU to the minimum MTU that its traffic could hit
in an L2 domain or fragmentation. ICMP could be a possible
optimization in the fragmentation case.
^ permalink raw reply
* Re: [PATCH] bpf: arm64: lift restriction on last instruction
From: Will Deacon @ 2014-12-03 18:04 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Zi Shen Lim, David S. Miller, Catalin Marinas, Daniel Borkmann,
Network Development, linux-arm-kernel@lists.infradead.org, LKML
In-Reply-To: <CAMEtUuwJHC2eyOh3pD=qDXw1YbfJqx1a7W0o65n5Ur_B_TvNOA@mail.gmail.com>
On Wed, Dec 03, 2014 at 03:54:32PM +0000, Alexei Starovoitov wrote:
> On Wed, Dec 3, 2014 at 12:38 AM, Zi Shen Lim <zlim.lnx@gmail.com> wrote:
> > Earlier implementation assumed last instruction is BPF_EXIT.
> > Since this is no longer a restriction in eBPF, we remove this
> > limitation.
> >
> > Per Alexei Starovoitov [1]:
> >> classic BPF has a restriction that last insn is always BPF_RET.
> >> eBPF doesn't have BPF_RET instruction and this restriction.
> >> It has BPF_EXIT insn which can appear anywhere in the program
> >> one or more times and it doesn't have to be last insn.
> >
> > [1] https://lkml.org/lkml/2014/11/27/2
> >
> > Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler")
> > Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
>
> yours is cleaner than my own attempt to fix it.
> Thanks!
> Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Cheers, I've applied this for 3.19.
Will
^ permalink raw reply
* [PATCH net-next v2 2/2] net: phy: bcm7xxx: add an explicit version check for GPHY rev G0
From: Florian Fainelli @ 2014-12-03 17:57 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
In-Reply-To: <1417629420-31146-1-git-send-email-f.fainelli@gmail.com>
GPHY revision G0 has its version rolled over to 0x10, introduce an
explicit check for that revision and invoke the proper workaround
function for it.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/bcm7xxx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index 7a53af4346e4..974ec4515269 100644
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -252,6 +252,8 @@ static int bcm7xxx_28nm_config_init(struct phy_device *phydev)
break;
case 0xe0:
case 0xf0:
+ /* Rev G0 introduces a roll over */
+ case 0x10:
ret = bcm7xxx_28nm_e0_plus_afe_config_init(phydev);
break;
default:
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v2 1/2] net: bcmgenet: add support for new GENET PHY revision scheme
From: Florian Fainelli @ 2014-12-03 17:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
In-Reply-To: <1417629420-31146-1-git-send-email-f.fainelli@gmail.com>
Starting with GPHY revision G0, the GENET register layout has changed to
use the same numbering scheme as the Starfighter 2 switch. This means
that GPHY major revision is in bits 15:12, minor in bits 11:8 and patch
level is in bits 7:4.
Introduce a small heuristic which checks for the old scheme first, tests
for the new scheme and finally attempts to catch reserved values and
aborts.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- remove unnecessary parenthesis
- add missing "is" in paragraph about the scheme
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index f2fadb053d52..410c22bc655a 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2503,6 +2503,7 @@ static void bcmgenet_set_hw_params(struct bcmgenet_priv *priv)
struct bcmgenet_hw_params *params;
u32 reg;
u8 major;
+ u16 gphy_rev;
if (GENET_IS_V4(priv)) {
bcmgenet_dma_regs = bcmgenet_dma_regs_v3plus;
@@ -2551,8 +2552,29 @@ static void bcmgenet_set_hw_params(struct bcmgenet_priv *priv)
* to pass this information to the PHY driver. The PHY driver expects
* to find the PHY major revision in bits 15:8 while the GENET register
* stores that information in bits 7:0, account for that.
+ *
+ * On newer chips, starting with PHY revision G0, a new scheme is
+ * deployed similar to the Starfighter 2 switch with GPHY major
+ * revision in bits 15:8 and patch level in bits 7:0. Major revision 0
+ * is reserved as well as special value 0x01ff, we have a small
+ * heuristic to check for the new GPHY revision and re-arrange things
+ * so the GPHY driver is happy.
*/
- priv->gphy_rev = (reg & 0xffff) << 8;
+ gphy_rev = reg & 0xffff;
+
+ /* This is the good old scheme, just GPHY major, no minor nor patch */
+ if ((gphy_rev & 0xf0) != 0)
+ priv->gphy_rev = gphy_rev << 8;
+
+ /* This is the new scheme, GPHY major rolls over with 0x10 = rev G0 */
+ else if ((gphy_rev & 0xff00) != 0)
+ priv->gphy_rev = gphy_rev;
+
+ /* This is reserved so should require special treatment */
+ else if (gphy_rev == 0 || gphy_rev == 0x01ff) {
+ pr_warn("Invalid GPHY revision detected: 0x%04x\n", gphy_rev);
+ return;
+ }
#ifdef CONFIG_PHYS_ADDR_T_64BIT
if (!(params->flags & GENET_HAS_40BITS))
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v2 0/2] net: bcmgenet: support for new GPHY revision scheme
From: Florian Fainelli @ 2014-12-03 17:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
Hi David,
These two patches update the GENET GPHY revision logic to account for some
of our newer designs starting with GPHY rev G0.
Florian Fainelli (2):
net: bcmgenet: add support for new GENET PHY revision scheme
net: phy: bcm7xxx: add an explicit version check for GPHY rev G0
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 24 +++++++++++++++++++++++-
drivers/net/phy/bcm7xxx.c | 2 ++
2 files changed, 25 insertions(+), 1 deletion(-)
--
2.1.0
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request
From: vadim4j @ 2014-12-03 17:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20141203095123.40429f4c@urahara>
On Wed, Dec 03, 2014 at 09:51:23AM -0800, Stephen Hemminger wrote:
> On Wed, 3 Dec 2014 19:20:10 +0200
> vadim4j@gmail.com wrote:
>
> > On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> > > On Tue, 2 Dec 2014 16:53:04 +0200
> > > Vadim Kochan <vadim4j@gmail.com> wrote:
> > >
> > > > Replaced handling netlink messages by rtnl_dump_filter
> > > > from lib/libnetlink.c, also:
> > > >
> > > > - removed unused dump_fp arg;
> > > > - added MAGIC_SEQ #define for 123456 seq id
> > > >
> > > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> > >
> > > This doesn't work correctly.
> > >
> > > Simple test
> > > $ misc/ss >/dev/null
> > > RTNETLINK answers: No such file or directory
> > > RTNETLINK answers: No such file or directory
> > > RTNETLINK answers: No such file or directory
> >
> > Just tried, I did not get such errors.
>
> I have OpenVPN running.
Hm, it is reproduced only with this patch ?
If so I will try to setup OpenVPN ... can't imagine how it can be
related ...
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: bcmgenet: add support for new GENET PHY revision scheme
From: Florian Fainelli @ 2014-12-03 17:54 UTC (permalink / raw)
To: Sergei Shtylyov, netdev; +Cc: davem
In-Reply-To: <547EF2BC.60504@cogentembedded.com>
On 03/12/14 03:23, Sergei Shtylyov wrote:
> Hello.
>
> On 12/3/2014 2:28 AM, Florian Fainelli wrote:
>
>> Starting with GPHY revision G0, the GENET register layout has changed to
>> use the same numbering scheme as the Starfighter 2 switch. This means
>> that GPHY major revision is in bits 15:12, minor in bits 11:8 and patch
>> level is in bits 7:4.
>
>> Introduce a small heuristic which checks for the old scheme first, tests
>> for the new scheme and finally attempts to catch reserved values and
>> aborts.
>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 24
>> +++++++++++++++++++++++-
>> 1 file changed, 23 insertions(+), 1 deletion(-)
>
>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> index f2fadb053d52..23e283174c4e 100644
>> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> [...]
>> @@ -2551,8 +2552,29 @@ static void bcmgenet_set_hw_params(struct
>> bcmgenet_priv *priv)
>> * to pass this information to the PHY driver. The PHY driver
>> expects
>> * to find the PHY major revision in bits 15:8 while the GENET
>> register
>> * stores that information in bits 7:0, account for that.
>> + *
>> + * On newer chips, starting with PHY revision G0, a new scheme is
>> + * deployed similar to the Starfighter 2 switch with GPHY major
>> + * revision in bits 15:8 and patch level in bits 7:0. Major
>> revision 0
>> + * is reserved as well as special value 0x01ff, we have a small
>> + * heuristic to check for the new GPHY revision and re-arrange
>> things
>> + * so the GPHY driver is happy.
>> */
>> - priv->gphy_rev = (reg & 0xffff) << 8;
>> + gphy_rev = (reg & 0xffff);
>
> Parens not needed anymore.
>
>> +
>> + /* This the good old scheme, just GPHY major, no minor nor patch */
>
> Missing "is" after "This"?
Alright, I will resubmit...
>
>> + if ((gphy_rev & 0xf0) != 0)
>> + priv->gphy_rev = gphy_rev << 8;
>> +
>> + /* This is the new scheme, GPHY major rolls over with 0x10 = rev
>> G0 */
>> + else if ((gphy_rev & 0xff00) != 0)
>> + priv->gphy_rev = gphy_rev;
>> +
>> + /* This is reserved so should require special treatment */
>> + else if (gphy_rev == 0 || gphy_rev == 0x01ff) {
>> + pr_warn("Invalid GPHY revision detected: 0x%04x\n", gphy_rev);
>> + return;
>> + }
>
> Hm, {} are needed on all *if* branches.
checkpatch.pl did not complain about that.
>
> [...]
>
> WBR, Sergei
>
^ permalink raw reply
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
From: vadim4j @ 2014-12-03 17:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20141203094731.4d310fc5@urahara>
On Wed, Dec 03, 2014 at 09:47:31AM -0800, Stephen Hemminger wrote:
> On Wed, 3 Dec 2014 19:11:26 +0200
> vadim4j@gmail.com wrote:
>
> > I think it was caused by RTM_NEWNDUSEROPT which was sent by router.
> > So in this case the message will be skipped with printed timestamp.
>
> Can that be decoded? it might be useful.
Sorry, you mean how it can be reproduced by clean scenario?
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request
From: Stephen Hemminger @ 2014-12-03 17:51 UTC (permalink / raw)
To: vadim4j; +Cc: netdev
In-Reply-To: <20141203172010.GA8639@angus-think.wlc.globallogic.com>
On Wed, 3 Dec 2014 19:20:10 +0200
vadim4j@gmail.com wrote:
> On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> > On Tue, 2 Dec 2014 16:53:04 +0200
> > Vadim Kochan <vadim4j@gmail.com> wrote:
> >
> > > Replaced handling netlink messages by rtnl_dump_filter
> > > from lib/libnetlink.c, also:
> > >
> > > - removed unused dump_fp arg;
> > > - added MAGIC_SEQ #define for 123456 seq id
> > >
> > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> >
> > This doesn't work correctly.
> >
> > Simple test
> > $ misc/ss >/dev/null
> > RTNETLINK answers: No such file or directory
> > RTNETLINK answers: No such file or directory
> > RTNETLINK answers: No such file or directory
>
> Just tried, I did not get such errors.
I have OpenVPN running.
^ permalink raw reply
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
From: Stephen Hemminger @ 2014-12-03 17:47 UTC (permalink / raw)
To: vadim4j; +Cc: netdev
In-Reply-To: <20141203171126.GA7381@angus-think.wlc.globallogic.com>
On Wed, 3 Dec 2014 19:11:26 +0200
vadim4j@gmail.com wrote:
> I think it was caused by RTM_NEWNDUSEROPT which was sent by router.
> So in this case the message will be skipped with printed timestamp.
Can that be decoded? it might be useful.
^ permalink raw reply
* Re: [PATCH Iproute2 next v2] ip link: Add ipvlan support to the iproute2/ip util
From: Stephen Hemminger @ 2014-12-03 17:38 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: netdev, Eric Dumazet, Maciej Zenczykowski, Laurent Chavey,
Tim Hockin, David Miller, Brandon Philips, Pavel Emelianov
In-Reply-To: <1416794771-11193-1-git-send-email-maheshb@google.com>
On Sun, 23 Nov 2014 18:06:11 -0800
Mahesh Bandewar <maheshb@google.com> wrote:
> Adding basic support to create virtual devices using 'ip'
> utility. Following is the syntax -
>
> ip link add link <master> <virtual> type ipvlan mode [ l2 | l3 ]
> e.g. ip link add link eth0 ipvl0 type ipvlan mode l3
>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Maciej Żenczykowski <maze@google.com>
> Cc: Laurent Chavey <chavey@google.com>
> Cc: Tim Hockin <thockin@google.com>
> Cc: Brandon Philips <brandon.philips@coreos.com>
> Cc: Pavel Emelianov <xemul@parallels.com>
Applied to net-next branch.
^ permalink raw reply
* Re: [patch iproute2 v4] tc: add support for vlan tc action
From: Stephen Hemminger @ 2014-12-03 17:35 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, pshelar, therbert, edumazet, willemb,
dborkman, mst, fw, Paul.Durrant, tgraf, cwang
In-Reply-To: <1416402506-31852-1-git-send-email-jiri@resnulli.us>
On Wed, 19 Nov 2014 14:08:26 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Reviewed-by: Cong Wang <cwang@twopensource.com>
Applied to net-next branch.
^ permalink raw reply
* Re: [PATCH v2 4/7] fs/proc/task_mmu.c: shift mm_access() from m_start() to proc_maps_open()
From: Oleg Nesterov @ 2014-12-03 17:34 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: David S. Miller, Linus Torvalds, Andrew Morton, Alexander Viro,
Cyrill Gorcunov, David Howells, Eric W. Biederman,
Kirill A. Shutemov, Peter Zijlstra, Sasha Levin, linux-fsdevel,
linux-kernel, Alexey Dobriyan, netdev
In-Reply-To: <20141203141433.GA25683@node.dhcp.inet.fi>
On 12/03, Kirill A. Shutemov wrote:
>
> On Tue, Aug 05, 2014 at 09:46:55PM +0200, Oleg Nesterov wrote:
> > A simple test-case from Kirill Shutemov
> >
> > cat /proc/self/maps >/dev/null
> > chmod +x /proc/self/net/packet
> > exec /proc/self/net/packet
> >
> > makes lockdep unhappy, cat/exec take seq_file->lock + cred_guard_mutex in
> > the opposite order.
>
> Oleg, I see it again with almost the same test-case:
>
> cat /proc/self/stack >/dev/null
> chmod +x /proc/self/net/packet
> exec /proc/self/net/packet
Yes, there are more lock_trace/mm_access (ab)users. Fortunately, they
are much simpler than proc/pid/maps (which also asked for other cleanups
and fixes).
I'll try to take a look, thanks for reminding.
And I agree with Eric, chmod+x probably makes no sense. Still I think
this code deserves some cleanups regardless. To the point I think that
lock_trace() should probably die.
Thanks!
Oleg.
^ 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