* [PATCH 1/6] batman-adv: Start new development cycle
From: Simon Wunderlich @ 2017-08-02 14:23 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20170802142322.13376-1-sw-2YrNx6rUIHYiY0qSoAWiAoQuADTiUCJX@public.gmane.org>
Signed-off-by: Simon Wunderlich <sw-2YrNx6rUIHYiY0qSoAWiAoQuADTiUCJX@public.gmane.org>
---
net/batman-adv/main.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h
index 2be8f1f46529..05cc7637c064 100644
--- a/net/batman-adv/main.h
+++ b/net/batman-adv/main.h
@@ -24,7 +24,7 @@
#define BATADV_DRIVER_DEVICE "batman-adv"
#ifndef BATADV_SOURCE_VERSION
-#define BATADV_SOURCE_VERSION "2017.2"
+#define BATADV_SOURCE_VERSION "2017.3"
#endif
/* B.A.T.M.A.N. parameters */
--
2.11.0
^ permalink raw reply related
* [PATCH 0/6] pull request for net-next: batman-adv 2017-08-02
From: Simon Wunderlich @ 2017-08-02 14:23 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Hi David,
here is a small feature/cleanup pull request of batman-adv to go into net-next.
Please pull or let me know of any problem!
Thank you,
Simon
The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:
Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batadv-next-for-davem-20170802
for you to fetch changes up to e45eba2467bd64fd196dc6f8b50ff5e59c0058da:
batman-adv: Convert batman-adv.txt to reStructuredText (2017-07-29 09:51:28 +0200)
----------------------------------------------------------------
This feature/cleanup patchset includes the following patches:
- bump version strings, by Simon Wunderlich
- Remove unnecessary length qualifier, by Joe Perches
- Remove too short %pM field width, by Sven Eckelmann
- Remove return value handling from skb_put_data, by Sven Eckelmann
- Spelling fixes, by Colin Ian King
- Convert batman-adv.txt to reStructuredText, by Sven Eckelmann
----------------------------------------------------------------
Colin Ian King (1):
batman-adv: fix various spelling mistakes
Joe Perches (1):
batman-adv: Remove unnecessary length qualifier in %14pM
Simon Wunderlich (1):
batman-adv: Start new development cycle
Sven Eckelmann (3):
batman-adv: Remove too short %pM printk field width
batman-adv: Remove variable deprecated by skb_put_data
batman-adv: Convert batman-adv.txt to reStructuredText
Documentation/networking/00-INDEX | 2 -
Documentation/networking/batman-adv.rst | 220 ++++++++++++++++++++++++++++++++
Documentation/networking/batman-adv.txt | 215 -------------------------------
Documentation/networking/index.rst | 1 +
MAINTAINERS | 2 +-
net/batman-adv/bat_iv_ogm.c | 6 +-
net/batman-adv/bat_v_ogm.c | 16 +--
net/batman-adv/distributed-arp-table.c | 2 +-
net/batman-adv/main.h | 2 +-
net/batman-adv/send.c | 2 +-
10 files changed, 235 insertions(+), 233 deletions(-)
create mode 100644 Documentation/networking/batman-adv.rst
delete mode 100644 Documentation/networking/batman-adv.txt
^ permalink raw reply
* Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default
From: Timur Tabi @ 2017-08-02 14:21 UTC (permalink / raw)
To: David Laight, David S. Miller, netdev@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD00490C0@AcuExch.aculab.com>
On 8/2/17 8:48 AM, David Laight wrote:
> If the nearby switches cannot handle pause frames, then the MAC shouldn't
> be sending them at all.
There's no way for me to know whether the switches can handle the pause
frames or not. You would think that sending one multicast pause frame
ever 33ms would not overload a switch, but in our lab it does.
This is why I changed the default to disable sending pause frames.
> They
>
> I suspect that they should only ever be sent if the phy autonegotiation
> indicates that they are supported.
Or if you manually enable them. That's why I changed to default: the
MAC is now configured by default to accept pause frames but not send them.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
^ permalink raw reply
* [PATCH 1/1] batman-adv: fix TT sync flag inconsistencies
From: Simon Wunderlich @ 2017-08-02 14:15 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20170802141542.13059-1-sw-2YrNx6rUIHYiY0qSoAWiAoQuADTiUCJX@public.gmane.org>
From: Linus Lüssing <linus.luessing-djzkFPsfvsizQB+pC5nmwQ@public.gmane.org>
This patch fixes an issue in the translation table code potentially
leading to a TT Request + Response storm. The issue may occur for nodes
involving BLA and an inconsistent configuration of the batman-adv AP
isolation feature. However, since the new multicast optimizations, a
single, malformed packet may lead to a mesh-wide, persistent
Denial-of-Service, too.
The issue occurs because nodes are currently OR-ing the TT sync flags of
all originators announcing a specific MAC address via the
translation table. When an intermediate node now receives a TT Request
and wants to answer this on behalf of the destination node, then this
intermediate node now responds with an altered flag field and broken
CRC. The next OGM of the real destination will lead to a CRC mismatch
and triggering a TT Request and Response again.
Furthermore, the OR-ing is currently never undone as long as at least
one originator announcing the according MAC address remains, leading to
the potential persistency of this issue.
This patch fixes this issue by storing the flags used in the CRC
calculation on a a per TT orig entry basis to be able to respond with
the correct, original flags in an intermediate TT Response for one
thing. And to be able to correctly unset sync flags once all nodes
announcing a sync flag vanish for another.
Fixes: e9c00136a475 ("batman-adv: fix tt_global_entries flags update")
Signed-off-by: Linus Lüssing <linus.luessing-djzkFPsfvsizQB+pC5nmwQ@public.gmane.org>
Acked-by: Antonio Quartulli <a@unstable.cc>
[sw: typo in commit message]
Signed-off-by: Simon Wunderlich <sw-2YrNx6rUIHYiY0qSoAWiAoQuADTiUCJX@public.gmane.org>
---
net/batman-adv/translation-table.c | 60 ++++++++++++++++++++++++++++++++------
net/batman-adv/types.h | 2 ++
2 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index e1133bc634b5..8a3ce79b1307 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -1549,9 +1549,41 @@ batadv_tt_global_entry_has_orig(const struct batadv_tt_global_entry *entry,
return found;
}
+/**
+ * batadv_tt_global_sync_flags - update TT sync flags
+ * @tt_global: the TT global entry to update sync flags in
+ *
+ * Updates the sync flag bits in the tt_global flag attribute with a logical
+ * OR of all sync flags from any of its TT orig entries.
+ */
+static void
+batadv_tt_global_sync_flags(struct batadv_tt_global_entry *tt_global)
+{
+ struct batadv_tt_orig_list_entry *orig_entry;
+ const struct hlist_head *head;
+ u16 flags = BATADV_NO_FLAGS;
+
+ rcu_read_lock();
+ head = &tt_global->orig_list;
+ hlist_for_each_entry_rcu(orig_entry, head, list)
+ flags |= orig_entry->flags;
+ rcu_read_unlock();
+
+ flags |= tt_global->common.flags & (~BATADV_TT_SYNC_MASK);
+ tt_global->common.flags = flags;
+}
+
+/**
+ * batadv_tt_global_orig_entry_add - add or update a TT orig entry
+ * @tt_global: the TT global entry to add an orig entry in
+ * @orig_node: the originator to add an orig entry for
+ * @ttvn: translation table version number of this changeset
+ * @flags: TT sync flags
+ */
static void
batadv_tt_global_orig_entry_add(struct batadv_tt_global_entry *tt_global,
- struct batadv_orig_node *orig_node, int ttvn)
+ struct batadv_orig_node *orig_node, int ttvn,
+ u8 flags)
{
struct batadv_tt_orig_list_entry *orig_entry;
@@ -1561,7 +1593,8 @@ batadv_tt_global_orig_entry_add(struct batadv_tt_global_entry *tt_global,
* was added during a "temporary client detection"
*/
orig_entry->ttvn = ttvn;
- goto out;
+ orig_entry->flags = flags;
+ goto sync_flags;
}
orig_entry = kmem_cache_zalloc(batadv_tt_orig_cache, GFP_ATOMIC);
@@ -1573,6 +1606,7 @@ batadv_tt_global_orig_entry_add(struct batadv_tt_global_entry *tt_global,
batadv_tt_global_size_inc(orig_node, tt_global->common.vid);
orig_entry->orig_node = orig_node;
orig_entry->ttvn = ttvn;
+ orig_entry->flags = flags;
kref_init(&orig_entry->refcount);
spin_lock_bh(&tt_global->list_lock);
@@ -1582,6 +1616,8 @@ batadv_tt_global_orig_entry_add(struct batadv_tt_global_entry *tt_global,
spin_unlock_bh(&tt_global->list_lock);
atomic_inc(&tt_global->orig_list_count);
+sync_flags:
+ batadv_tt_global_sync_flags(tt_global);
out:
if (orig_entry)
batadv_tt_orig_list_entry_put(orig_entry);
@@ -1703,10 +1739,10 @@ static bool batadv_tt_global_add(struct batadv_priv *bat_priv,
}
/* the change can carry possible "attribute" flags like the
- * TT_CLIENT_WIFI, therefore they have to be copied in the
+ * TT_CLIENT_TEMP, therefore they have to be copied in the
* client entry
*/
- common->flags |= flags;
+ common->flags |= flags & (~BATADV_TT_SYNC_MASK);
/* If there is the BATADV_TT_CLIENT_ROAM flag set, there is only
* one originator left in the list and we previously received a
@@ -1723,7 +1759,8 @@ static bool batadv_tt_global_add(struct batadv_priv *bat_priv,
}
add_orig_entry:
/* add the new orig_entry (if needed) or update it */
- batadv_tt_global_orig_entry_add(tt_global_entry, orig_node, ttvn);
+ batadv_tt_global_orig_entry_add(tt_global_entry, orig_node, ttvn,
+ flags & BATADV_TT_SYNC_MASK);
batadv_dbg(BATADV_DBG_TT, bat_priv,
"Creating new global tt entry: %pM (vid: %d, via %pM)\n",
@@ -1946,6 +1983,7 @@ batadv_tt_global_dump_subentry(struct sk_buff *msg, u32 portid, u32 seq,
struct batadv_tt_orig_list_entry *orig,
bool best)
{
+ u16 flags = (common->flags & (~BATADV_TT_SYNC_MASK)) | orig->flags;
void *hdr;
struct batadv_orig_node_vlan *vlan;
u8 last_ttvn;
@@ -1975,7 +2013,7 @@ batadv_tt_global_dump_subentry(struct sk_buff *msg, u32 portid, u32 seq,
nla_put_u8(msg, BATADV_ATTR_TT_LAST_TTVN, last_ttvn) ||
nla_put_u32(msg, BATADV_ATTR_TT_CRC32, crc) ||
nla_put_u16(msg, BATADV_ATTR_TT_VID, common->vid) ||
- nla_put_u32(msg, BATADV_ATTR_TT_FLAGS, common->flags))
+ nla_put_u32(msg, BATADV_ATTR_TT_FLAGS, flags))
goto nla_put_failure;
if (best && nla_put_flag(msg, BATADV_ATTR_FLAG_BEST))
@@ -2589,6 +2627,7 @@ static u32 batadv_tt_global_crc(struct batadv_priv *bat_priv,
unsigned short vid)
{
struct batadv_hashtable *hash = bat_priv->tt.global_hash;
+ struct batadv_tt_orig_list_entry *tt_orig;
struct batadv_tt_common_entry *tt_common;
struct batadv_tt_global_entry *tt_global;
struct hlist_head *head;
@@ -2627,8 +2666,9 @@ static u32 batadv_tt_global_crc(struct batadv_priv *bat_priv,
/* find out if this global entry is announced by this
* originator
*/
- if (!batadv_tt_global_entry_has_orig(tt_global,
- orig_node))
+ tt_orig = batadv_tt_global_orig_entry_find(tt_global,
+ orig_node);
+ if (!tt_orig)
continue;
/* use network order to read the VID: this ensures that
@@ -2640,10 +2680,12 @@ static u32 batadv_tt_global_crc(struct batadv_priv *bat_priv,
/* compute the CRC on flags that have to be kept in sync
* among nodes
*/
- flags = tt_common->flags & BATADV_TT_SYNC_MASK;
+ flags = tt_orig->flags;
crc_tmp = crc32c(crc_tmp, &flags, sizeof(flags));
crc ^= crc32c(crc_tmp, tt_common->addr, ETH_ALEN);
+
+ batadv_tt_orig_list_entry_put(tt_orig);
}
rcu_read_unlock();
}
diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h
index ea43a6449247..a62795868794 100644
--- a/net/batman-adv/types.h
+++ b/net/batman-adv/types.h
@@ -1260,6 +1260,7 @@ struct batadv_tt_global_entry {
* struct batadv_tt_orig_list_entry - orig node announcing a non-mesh client
* @orig_node: pointer to orig node announcing this non-mesh client
* @ttvn: translation table version number which added the non-mesh client
+ * @flags: per orig entry TT sync flags
* @list: list node for batadv_tt_global_entry::orig_list
* @refcount: number of contexts the object is used
* @rcu: struct used for freeing in an RCU-safe manner
@@ -1267,6 +1268,7 @@ struct batadv_tt_global_entry {
struct batadv_tt_orig_list_entry {
struct batadv_orig_node *orig_node;
u8 ttvn;
+ u8 flags;
struct hlist_node list;
struct kref refcount;
struct rcu_head rcu;
--
2.11.0
^ permalink raw reply related
* [PATCH 0/1] pull request for net: batman-adv 2017-08-02
From: Simon Wunderlich @ 2017-08-02 14:15 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Hi David,
here is a bugfix which we would like to see integrated into net.
Please pull or let me know of any problem!
Thank you,
Simon
The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:
Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batadv-net-for-davem-20170802
for you to fetch changes up to 54e22f265e872ae140755b3318521d400a094605:
batman-adv: fix TT sync flag inconsistencies (2017-07-31 11:17:38 +0200)
----------------------------------------------------------------
Here is a batman-adv bugfix:
- fix TT sync flag inconsistency problems, which can lead to excess packets,
by Linus Luessing
----------------------------------------------------------------
Linus Lüssing (1):
batman-adv: fix TT sync flag inconsistencies
net/batman-adv/translation-table.c | 60 ++++++++++++++++++++++++++++++++------
net/batman-adv/types.h | 2 ++
2 files changed, 53 insertions(+), 9 deletions(-)
^ permalink raw reply
* RE: [PATCH] Adding Agile-SD TCP module and modifying Kconfig and Makefile
From: David Laight @ 2017-08-02 14:09 UTC (permalink / raw)
To: 'mohamedalrshah', davem@davemloft.net
Cc: netdev@vger.kernel.org, torvalds@linux-foundation.org,
linux-kernel@vger.kernel.org, mohamed.a.alrshah@ieee.org
In-Reply-To: <20170802044349.27582-1-mohamed.asnd@gmail.com>
From: mohamedalrshah
> Sent: 02 August 2017 05:44
> Published:
> Alrshah, M.A., Othman, M., Ali, B. and Hanapi, Z.M., 2015. Agile-SD: a Linux-based
> TCP congestion control algorithm for supporting high-speed and short-distance networks.
> Journal of Network and Computer Applications, 55, pp.181-190.
>
> Agile-SD is a new loss-based and RTT-independent TCP congestion
> control algorithm designed to support high-speed and Short-Distance (SD)
> networks. It mainly contributes the agility factor mechanism, which allows
> Agile-SD to deal with small buffer sizes while reducing its sensitivity to
> packet loss. Due to the use of this mechanism, Agile-SD improves the
> throughput of TCP up to 50% compared to Cubic-TCP and Compound-TCP. Its
> performance was evaluated using the well-known NS2 simulator to measure
> the average throughput, loss ratio and fairness.
>
> Agile-SD is designed and implemented by Mohamed A. Alrshah et al. (2015) as
> a Linux kernel module in the real Linux operating system (openSUSE 42.1 Leap),
> which is implemented at the Network, Parallel and Distributed Computing Laboratory,
> A2.10, second floor, Block A, Faculty of Computer Science and Information Technology,
> Universiti Putra Malaysia, over real PCs connected to the Internet for daily uses and
> evaluation purposes.
>
> The main motivation behind Agile-SD is to support the short-distance networks such
> as local area networks and data center networks in order to increase the bandwidth
> utilization over high-speed networks. Moreover, Agile-SD is introduced in support
> of the open source community, where it can be used under the OpenGL agreement.
What a pile of bullshit ...
David
^ permalink raw reply
* Re: [RFC PATCH v2 1/2] net: ethernet: nb8800: Reset HW block in ndo_open
From: Andrew Lunn @ 2017-08-02 13:54 UTC (permalink / raw)
To: Mason; +Cc: Mans Rullgard, netdev, Florian Fainelli, David Miller, Linux ARM
In-Reply-To: <ef36cd4a-b1b5-7505-34d1-250c736d6731@free.fr>
> > Finally, you still haven't explained why the hw needs to be reset in
> > ndo_open(). Whatever is causing your lockup can almost certainly be
> > triggered in some other way too. I will not accept this side-stepping
> > of the issue.
>
> (I was not aware that you were the final authority on which
> patches are accepted upstream.)
./scripts/get_maintainer.pl -f drivers/net/ethernet/aurora/nb8800.c
"David S. Miller" <davem@davemloft.net> (commit_signer:6/6=100%)
Mans Rullgard <mans@mansr.com> (commit_signer:2/6=33%)
Jarod Wilson <jarod@redhat.com> (commit_signer:1/6=17%,authored:1/6=17%,removed_lines:1/17=6%)
Stephen Hemminger <stephen@networkplumber.org> (commit_signer:1/6=17%)
Florian Fainelli <f.fainelli@gmail.com> (commit_signer:1/6=17%,added_lines:1/14=7%,removed_lines:11/17=65%)
Javier Martinez Canillas <javier@osg.samsung.com> (authored:1/6=17%,added_lines:1/14=7%)
Johan Hovold <johan@kernel.org> (authored:1/6=17%,added_lines:7/14=50%,removed_lines:2/17=12%)
Johannes Berg <johannes.berg@intel.com> (authored:1/6=17%,added_lines:2/14=14%,removed_lines:2/17=12%)
Wei Yongjun <weiyongjun1@huawei.com> (authored:1/6=17%,added_lines:3/14=21%,removed_lines:1/17=6%)
David is very likely to listen to Mans's recommendations, since Mans
has done most of the review work for this driver.
Andrew
^ permalink raw reply
* Re: repost: af_packet vs virtio (was packed ring layout proposal v2)
From: Michael S. Tsirkin @ 2017-08-02 13:50 UTC (permalink / raw)
To: Steven Luong
Cc: john.fastabend, alexei.starovoitov, netdev, virtio-dev,
virtualization, kvm
In-Reply-To: <CAJR92jnV1VgBs567QNjO1fHKDgMX=1j1aJJ2gK-TqMB5E1=fvw@mail.gmail.com>
On Tue, Aug 01, 2017 at 08:54:27PM -0700, Steven Luong wrote:
> * Descriptor ring:
>
> Guest adds descriptors with unique index values and DESC_HW set in flags.
> Host overwrites used descriptors with correct len, index, and DESC_HW
> clear. Flags are always set/cleared last.
>
> #define DESC_HW 0x0080
>
> struct desc {
> __le64 addr;
> __le32 len;
> __le16 index;
> __le16 flags;
> };
>
> When DESC_HW is set, descriptor belongs to device. When it is clear,
> it belongs to the driver.
>
> We can use 1 bit to set direction
> /* This marks a buffer as write-only (otherwise read-only). */
> #define VRING_DESC_F_WRITE 2
>
> * Scatter/gather support
>
> We can use 1 bit to chain s/g entries in a request, same as virtio 1.0:
>
> /* This marks a buffer as continuing via the next field. */
>
>
> This comment here is confusing to me. In 1.0, virtq_desc has the next field.
> When the flag VRING_DESC_F_NEXT is set, the next entry to continue is specified
> in the next field.
>
> Here in 1.1, struct desc does not have the next field, only addr, len, index,
> and flags. So when VRING_DESC_F_NEXT is set in struct desc's flags field, where
> is the next entry to continue the current descriptor, the entry immediately
> following the current entry? ie, if the current entry is at index 10 in the
> descriptor table and its flags is set for VRING_DESC_F_NEXT, is the entry
> continuing the current entry in index 11?
>
> Steven
Exactly, you got it right.
^ permalink raw reply
* RE: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default
From: David Laight @ 2017-08-02 13:48 UTC (permalink / raw)
To: 'Timur Tabi', David S. Miller, netdev@vger.kernel.org
In-Reply-To: <1501623460-3575-2-git-send-email-timur@codeaurora.org>
From: Timur Tabi
> Sent: 01 August 2017 22:38
> The EMAC has a curious qwirk when RX flow control is enabled and the
> kernel hangs. With the kernel hung, the EMAC's RX queue soon fills.
> If RX flow control is enabled, the EMAC will then send a non-stop
> stream of pause frames until the system is reset. The EMAC does not
> have a built-in watchdog.
>
> In various tests, the pause frame stream sometimes overloads nearby
> switches, effectively disabling the network.
...
If the nearby switches cannot handle pause frames, then the MAC shouldn't
be sending them at all.
They
I suspect that they should only ever be sent if the phy autonegotiation
indicates that they are supported.
You might want to avoid sending them even if allowed, or advertise
non-support on hardware that could support them, but sending them
anyway is likely to cause grief.
This is similar to the problems that arise when the 'speed' is forced
instead of limiting the advertised speed to one value.
David
^ permalink raw reply
* Re: [PATCH v3 01/11] net: phy: Add rockchip phy driver support
From: Andrew Lunn @ 2017-08-02 13:21 UTC (permalink / raw)
To: David Wu
Cc: davem, heiko, f.fainelli, robh+dt, mark.rutland, catalin.marinas,
will.deacon, olof, linux, arnd, peppe.cavallaro, alexandre.torgue,
huangtao, hwg, netdev, linux-arm-kernel, linux-rockchip,
devicetree, linux-kernel
In-Reply-To: <1501654546-17292-2-git-send-email-david.wu@rock-chips.com>
> +static struct phy_driver rockchip_phy_driver[] = {
> +{
> + .phy_id = 0x1234d400,
> + .phy_id_mask = 0xfffffff0,
> + .name = "Rockchip internal EPHY",
> + .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
> + | SUPPORTED_Asym_Pause),
Please take a look at Documentation/networking/phy.txt and
Fixes: 529ed1275263 ("net: phy: phy drivers should not set SUPPORTED_[Asym_]Pause")
Pause frames / flow control
The PHY does not participate directly in flow control/pause frames except by
making sure that the SUPPORTED_Pause and SUPPORTED_AsymPause bits are set in
MII_ADVERTISE to indicate towards the link partner that the Ethernet MAC
controller supports such a thing. Since flow control/pause frames generation
involves the Ethernet MAC driver, it is recommended that this driver takes care
of properly indicating advertisement and support for such features by setting
the SUPPORTED_Pause and SUPPORTED_AsymPause bits accordingly. This can be done
either before or after phy_connect() and/or as a result of implementing the
ethtool::set_pauseparam feature.
Andrew
^ permalink raw reply
* Re: net-next virtio_net merge...
From: Michael S. Tsirkin @ 2017-08-02 13:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jasowang
In-Reply-To: <20170801.151220.241719275238287015.davem@davemloft.net>
On Tue, Aug 01, 2017 at 03:12:20PM -0700, David Miller wrote:
>
> I just merged net into net-next and one of the conflicts had to do with
> the truesize bug fix in 'net' conflicting with the changes in 'net-next'
> which encode the headroom into the contexts for mergeable buffers.
>
> I did my best to resolve this, but if you two would take a closer
> look and test out the result I would really appreciate it!
>
> Thanks.
Looks good to me. Will test later today or tomorrow.
--
MST
^ permalink raw reply
* [iproute PATCH] bpf: Make bytecode-file reading a little more robust
From: Phil Sutter @ 2017-08-02 12:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Daniel Borkmann
bpf_parse_string() will now correctly handle:
- Extraneous whitespace,
- OPs on multiple lines and
- overlong file names.
The added feature of allowing to have OPs on multiple lines (like e.g.
tcpdump prints them) is rather a side effect of fixing detection of
malformed bytecode files having random content on a second line, like
e.g.:
| 4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0
| foobar
Cc: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
lib/bpf.c | 32 ++++++++++++++++++++++++--------
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/lib/bpf.c b/lib/bpf.c
index e7a4d12fdf2f9..4f52ad4a8f023 100644
--- a/lib/bpf.c
+++ b/lib/bpf.c
@@ -208,11 +208,11 @@ static int bpf_parse_string(char *arg, bool from_file, __u16 *bpf_len,
if (from_file) {
size_t tmp_len, op_len = sizeof("65535 255 255 4294967295,");
- char *tmp_string, *last;
+ char *tmp_string, *pos, c, c_prev = ' ';
FILE *fp;
tmp_len = sizeof("4096,") + BPF_MAXINSNS * op_len;
- tmp_string = calloc(1, tmp_len);
+ tmp_string = pos = calloc(1, tmp_len);
if (tmp_string == NULL)
return -ENOMEM;
@@ -223,17 +223,33 @@ static int bpf_parse_string(char *arg, bool from_file, __u16 *bpf_len,
return -ENOENT;
}
- if (!fgets(tmp_string, tmp_len, fp)) {
+ while ((c = fgetc(fp)) != EOF) {
+ switch (c) {
+ case '\n':
+ if (c_prev != ',')
+ *(pos++) = ',';
+ break;
+ case ' ':
+ case '\t':
+ if (c_prev != ' ')
+ *(pos++) = c;
+ break;
+ default:
+ *(pos++) = c;
+ }
+ if (pos - tmp_string == tmp_len)
+ break;
+ c_prev = c;
+ }
+
+ if (!feof(fp)) {
free(tmp_string);
fclose(fp);
- return -EIO;
+ return -E2BIG;
}
fclose(fp);
-
- last = &tmp_string[strlen(tmp_string) - 1];
- if (*last == '\n')
- *last = 0;
+ *pos = 0;
*need_release = true;
*bpf_string = tmp_string;
--
2.13.1
^ permalink raw reply related
* Re: [PATCH net-next v1 1/3] gtp: refactor to support flow-based gtp encap and decap
From: Pablo Neira Ayuso @ 2017-08-02 12:52 UTC (permalink / raw)
To: Andreas Schultz, g
Cc: Jiannan Ouyang, osmocom-net-gprs, netdev, dev, laforge, pshelar,
wieger ijntema tno, yi y yang, joe, Amar Padmanabhan
In-Reply-To: <1825145503.799984.1501485696720.JavaMail.zimbra@tpip.net>
On Mon, Jul 31, 2017 at 09:21:36AM +0200, Andreas Schultz wrote:
> Hi Jiannan,
>
> ----- On Jul 13, 2017, at 2:44 AM, Jiannan Ouyang ouyangj@fb.com wrote:
>
> [...]
>
> > -static int gtp_rx(struct pdp_ctx *pctx, struct sk_buff *skb,
> > - unsigned int hdrlen, unsigned int role)
> > +static int gtp_rx(struct gtp_dev *gtp, struct sk_buff *skb,
> > + unsigned int hdrlen, struct sock *sk,
> > + struct metadata_dst *tun_dst)
>
> Some time ago, there was an extensive discussion about the relation
> of PDP context and network devices. You are basically reverting one
> of the changes that was made in that context. I think it is wrong to
> couple GTP devices and PDP context the way you do here (there are
> people that disagree, though).
>
> The GTP network device of one of two structures owning the PDP context,
> the other is the GTP socket. GTP network devices and GTP sockets should
> be strictly separated.
>
> The GTP network device owns the IP given to the MS, handles mapping
> IP's into GTP tunnels (peer GSN + TEIDs) and hands the resulting GTP
> packets of to the GTP socket for sending. The GTP socket decaps the GTP
> packet, find the right context and based on information therein passes
> it to the GTP network device.
>
> By separating is that way, you can have MS with overlapping or colliding
> IP's on the same GTP socket as long as they belong to different GTP network
> devices.
>
> We had a length discussion about whether the above scenario makes sense.
> I'm not sure if we reached a final verdict, but the 3GPP specifications
> clearly permit such a setup.
We need a netlink interface to retrieve GTP information accordingly,
this includes a top-level APN object to represent what you need. That
would allow to accomodate all usecases.
^ permalink raw reply
* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
From: crow @ 2017-08-02 12:39 UTC (permalink / raw)
To: Jerome Brunet; +Cc: Andrew Lunn, netdev, open list:ARM/Amlogic Meson...
In-Reply-To: <1501097541.2401.35.camel@baylibre.com>
Hi Jerome,
On Wed, Jul 26, 2017 at 9:32 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Tue, 2017-07-25 at 18:56 +0200, crow wrote:
>> Hi,
>> Today I did test on ArchLinuxArm the Kernel v4.13-rc2. On downloading
>> the linux git source the network will eventually get stalled. Here are
>> the information
>>
>> Over SSH (network works).
>>
>> [root@alarm ~]# uname -a
>> Linux alarm 4.13.0-rc2-1-ARCH #1 SMP Mon Jul 24 20:02:50 MDT 2017
>> aarch64 GNU/Linux
>> [root@alarm ~]# mii-tool -vvv eth0
>> Using SIOCGMIIPHY=0x8947
>> eth0: negotiated 1000baseT-HD flow-control, link ok
>
> [Replying again on the last thread :) ]
> This 1000BaseT Half Duplex looks suspucious if the PHY is supposed to be a
> 10/100Mbps
[Resending without HTML]
I am not sure about that nor I can you answer on that. Today I used
buildroot provided by amlogic (compiled by Khadas Stuff) and there
seems no problem with the network. Here are test Report:
# uname -a
Linux buildroot 3.14.29 #1 SMP PREEMPT Tue Aug 1 15:13:51 CST 2017
aarch64 GNU/Linux
After enabling eth0 I get this information
[ 2729.827557] libphy: set driving length c
[ 2729.827667] libphy: set PLL minimum jitter
[ 2729.907553] libphy: set driving length c
[ 2729.907669] libphy: set PLL minimum jitter
[ 2731.334314] libphy: stmmac-0:08 - Link is Up - 100/Full
[ 2881.916512] tx queueing
[ 2943.916674] tx queueing
[ 3073.916713] tx queueing
[ 3083.916897] tx queueing
[ 3097.916686] tx queueing
[ 3105.916744] tx queueing
[ 3127.916700] tx queueing
(this tx queueing comes all time in Serial Console also during git
clone from linux kernel repository. After stoping traffic over ssh no
this message anymore.)
this info is before opening ssh connection to box and doing git clone.
# ethtool -S eth0
NIC statistics:
mmc_tx_octetcount_gb: 0
mmc_tx_framecount_gb: 0
mmc_tx_broadcastframe_g: 0
mmc_tx_multicastframe_g: 0
mmc_tx_64_octets_gb: 0
mmc_tx_65_to_127_octets_gb: 0
mmc_tx_128_to_255_octets_gb: 0
mmc_tx_256_to_511_octets_gb: 0
mmc_tx_512_to_1023_octets_gb: 0
mmc_tx_1024_to_max_octets_gb: 0
mmc_tx_unicast_gb: 0
mmc_tx_multicast_gb: 0
mmc_tx_broadcast_gb: 0
mmc_tx_underflow_error: 0
mmc_tx_singlecol_g: 0
mmc_tx_multicol_g: 0
mmc_tx_deferred: 0
mmc_tx_latecol: 0
mmc_tx_exesscol: 0
mmc_tx_carrier_error: 0
mmc_tx_octetcount_g: 0
mmc_tx_framecount_g: 0
mmc_tx_excessdef: 0
mmc_tx_pause_frame: 0
mmc_tx_vlan_frame_g: 0
mmc_rx_framecount_gb: 27
mmc_rx_octetcount_gb: 3864
mmc_rx_octetcount_g: 3864
mmc_rx_broadcastframe_g: 5
mmc_rx_multicastframe_g: 0
mmc_rx_crc_errror: 0
mmc_rx_align_error: 0
mmc_rx_run_error: 0
mmc_rx_jabber_error: 0
mmc_rx_undersize_g: 0
mmc_rx_oversize_g: 0
mmc_rx_64_octets_gb: 7
mmc_rx_65_to_127_octets_gb: 5
mmc_rx_128_to_255_octets_gb: 12
mmc_rx_256_to_511_octets_gb: 3
mmc_rx_512_to_1023_octets_gb: 0
mmc_rx_1024_to_max_octets_gb: 0
mmc_rx_unicast_g: 22
mmc_rx_length_error: 0
mmc_rx_autofrangetype: 0
mmc_rx_pause_frames: 0
mmc_rx_fifo_overflow: 0
mmc_rx_vlan_frames_gb: 0
mmc_rx_watchdog_error: 0
mmc_rx_ipc_intr_mask: 1073692671
mmc_rx_ipc_intr: 0
mmc_rx_ipv4_gd: 17
mmc_rx_ipv4_hderr: 0
mmc_rx_ipv4_nopay: 0
mmc_rx_ipv4_frag: 0
mmc_rx_ipv4_udsbl: 0
mmc_rx_ipv4_gd_octets: 2816
mmc_rx_ipv4_hderr_octets: 0
mmc_rx_ipv4_nopay_octets: 0
mmc_rx_ipv4_frag_octets: 0
mmc_rx_ipv4_udsbl_octets: 0
mmc_rx_ipv6_gd_octets: 240
mmc_rx_ipv6_hderr_octets: 0
mmc_rx_ipv6_nopay_octets: 0
mmc_rx_ipv6_gd: 3
mmc_rx_ipv6_hderr: 0
mmc_rx_ipv6_nopay: 0
mmc_rx_udp_gd: 15
mmc_rx_udp_err: 0
mmc_rx_tcp_gd: 0
mmc_rx_tcp_err: 0
mmc_rx_icmp_gd: 5
mmc_rx_icmp_err: 0
mmc_rx_udp_gd_octets: 2348
mmc_rx_udp_err_octets: 0
mmc_rx_tcp_gd_octets: 0
mmc_rx_tcp_err_octets: 0
mmc_rx_icmp_gd_octets: 248
mmc_rx_icmp_err_octets: 0
tx_underflow: 0
tx_carrier: 0
tx_losscarrier: 0
vlan_tag: 0
tx_deferred: 0
tx_vlan: 0
tx_jabber: 0
tx_frame_flushed: 0
tx_payload_error: 0
tx_ip_header_error: 0
rx_desc: 0
sa_filter_fail: 0
overflow_error: 0
ipc_csum_error: 0
rx_collision: 0
rx_crc: 0
dribbling_bit: 0
rx_length: 0
rx_mii: 0
rx_multicast: 0
rx_gmac_overflow: 0
rx_watchdog: 0
da_rx_filter_fail: 0
sa_rx_filter_fail: 0
rx_missed_cntr: 0
rx_overflow_cntr: 0
rx_vlan: 0
tx_undeflow_irq: 0
tx_process_stopped_irq: 0
tx_jabber_irq: 0
rx_overflow_irq: 0
rx_buf_unav_irq: 0
rx_process_stopped_irq: 0
rx_watchdog_irq: 0
tx_early_irq: 0
fatal_bus_error_irq: 0
rx_early_irq: 0
threshold: 64
tx_pkt_n: 31
rx_pkt_n: 27
normal_irq_n: 27
rx_normal_irq_n: 27
napi_poll: 27
tx_normal_irq_n: 0
tx_clean: 46
tx_reset_ic_bit: 31
irq_receive_pmt_irq_n: 0
mmc_tx_irq_n: 0
mmc_rx_irq_n: 0
mmc_rx_csum_offload_irq_n: 0
irq_tx_path_in_lpi_mode_n: 0
irq_tx_path_exit_lpi_mode_n: 0
irq_rx_path_in_lpi_mode_n: 0
irq_rx_path_exit_lpi_mode_n: 0
phy_eee_wakeup_error_n: 0
ip_hdr_err: 0
ip_payload_err: 0
ip_csum_bypassed: 0
ipv4_pkt_rcvd: 0
ipv6_pkt_rcvd: 0
rx_msg_type_ext_no_ptp: 0
rx_msg_type_sync: 0
rx_msg_type_follow_up: 0
rx_msg_type_delay_req: 0
rx_msg_type_delay_resp: 0
rx_msg_type_pdelay_req: 0
rx_msg_type_pdelay_resp: 0
rx_msg_type_pdelay_follow_up: 0
ptp_frame_type: 0
ptp_ver: 0
timestamp_dropped: 0
av_pkt_rcvd: 0
av_tagged_pkt_rcvd: 0
vlan_tag_priority_val: 0
l3_filter_match: 0
l4_filter_match: 0
l3_l4_filter_no_match: 0
irq_pcs_ane_n: 0
irq_pcs_link_n: 0
irq_rgmii_n: 0
# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
registers for MII PHY 8:
1000 782d 0181 4400 01e1 c1e1 000f 2001
ffff ffff ffff ffff ffff ffff ffff ffff
0040 0082 40e8 5400 0d80 1000 0000 6400
fff0 ffff 0000 110a 1407 0000 0e50 105a
>> registers for MII PHY 8:
>> 1000 782d 0181 4400 01e1 c1e1 000f 2001
>> ffff ffff ffff ffff ffff ffff ffff ffff
>> 0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>> fff0 ffff 0000 000a 1407 004a 0000 105a
>> product info: vendor 00:60:51, model 0 rev 0
>> basic mode: autonegotiation enabled
>> basic status: autonegotiation complete, link ok
>> capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>> advertising: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>> link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>> [root@alarm ~]# ethtool -S eth0
>> NIC statistics:
>> mmc_tx_octetcount_gb: 0
>> mmc_tx_framecount_gb: 0
>> mmc_tx_broadcastframe_g: 0
>> mmc_tx_multicastframe_g: 0
>> mmc_tx_64_octets_gb: 0
>> mmc_tx_65_to_127_octets_gb: 0
>> mmc_tx_128_to_255_octets_gb: 0
>> mmc_tx_256_to_511_octets_gb: 0
>> mmc_tx_512_to_1023_octets_gb: 0
>> mmc_tx_1024_to_max_octets_gb: 0
>> mmc_tx_unicast_gb: 0
>> mmc_tx_multicast_gb: 0
>> mmc_tx_broadcast_gb: 0
>> mmc_tx_underflow_error: 0
>> mmc_tx_singlecol_g: 0
>> mmc_tx_multicol_g: 0
>> mmc_tx_deferred: 0
>> mmc_tx_latecol: 0
>> mmc_tx_exesscol: 0
>> mmc_tx_carrier_error: 0
>> mmc_tx_octetcount_g: 0
>> mmc_tx_framecount_g: 0
>> mmc_tx_excessdef: 0
>> mmc_tx_pause_frame: 0
>> mmc_tx_vlan_frame_g: 0
>> mmc_rx_framecount_gb: 133
>> mmc_rx_octetcount_gb: 16646
>> mmc_rx_octetcount_g: 16646
>> mmc_rx_broadcastframe_g: 9
>> mmc_rx_multicastframe_g: 22
>> mmc_rx_crc_error: 0
>> mmc_rx_align_error: 0
>> mmc_rx_run_error: 0
>> mmc_rx_jabber_error: 0
>> mmc_rx_undersize_g: 0
>> mmc_rx_oversize_g: 0
>> mmc_rx_64_octets_gb: 45
>> mmc_rx_65_to_127_octets_gb: 64
>> mmc_rx_128_to_255_octets_gb: 13
>> mmc_rx_256_to_511_octets_gb: 7
>> mmc_rx_512_to_1023_octets_gb: 4
>> mmc_rx_1024_to_max_octets_gb: 0
>> mmc_rx_unicast_g: 102
>> mmc_rx_length_error: 0
>> mmc_rx_autofrangetype: 0
>> mmc_rx_pause_frames: 0
>> mmc_rx_fifo_overflow: 0
>> mmc_rx_vlan_frames_gb: 0
>> mmc_rx_watchdog_error: 0
>> mmc_rx_ipc_intr_mask: 1073692671
>> mmc_rx_ipc_intr: 0
>> mmc_rx_ipv4_gd: 117
>> mmc_rx_ipv4_hderr: 0
>> mmc_rx_ipv4_nopay: 0
>> mmc_rx_ipv4_frag: 0
>> mmc_rx_ipv4_udsbl: 0
>> mmc_rx_ipv4_gd_octets: 12585
>> mmc_rx_ipv4_hderr_octets: 0
>> mmc_rx_ipv4_nopay_octets: 0
>> mmc_rx_ipv4_frag_octets: 0
>> mmc_rx_ipv4_udsbl_octets: 0
>> mmc_rx_ipv6_gd_octets: 104
>> mmc_rx_ipv6_hderr_octets: 0
>> mmc_rx_ipv6_nopay_octets: 0
>> mmc_rx_ipv6_gd: 1
>> mmc_rx_ipv6_hderr: 0
>> mmc_rx_ipv6_nopay: 0
>> mmc_rx_udp_gd: 31
>> mmc_rx_udp_err: 0
>> mmc_rx_tcp_gd: 85
>> mmc_rx_tcp_err: 0
>> mmc_rx_icmp_gd: 2
>> mmc_rx_icmp_err: 0
>> mmc_rx_udp_gd_octets: 2963
>> mmc_rx_udp_err_octets: 0
>> mmc_rx_tcp_gd_octets: 7254
>> mmc_rx_tcp_err_octets: 0
>> mmc_rx_icmp_gd_octets: 92
>> mmc_rx_icmp_err_octets: 0
>> tx_underflow: 0
>> tx_carrier: 0
>> tx_losscarrier: 0
>> vlan_tag: 0
>> tx_deferred: 0
>> tx_vlan: 0
>> tx_jabber: 0
>> tx_frame_flushed: 0
>> tx_payload_error: 0
>> tx_ip_header_error: 0
>> rx_desc: 0
>> sa_filter_fail: 0
>> overflow_error: 0
>> ipc_csum_error: 0
>> rx_collision: 0
>> rx_crc_errors: 0
>> dribbling_bit: 0
>> rx_length: 0
>> rx_mii: 0
>> rx_multicast: 0
>> rx_gmac_overflow: 0
>> rx_watchdog: 0
>> da_rx_filter_fail: 0
>> sa_rx_filter_fail: 0
>> rx_missed_cntr: 0
>> rx_overflow_cntr: 0
>> rx_vlan: 0
>> tx_undeflow_irq: 0
>> tx_process_stopped_irq: 0
>> tx_jabber_irq: 0
>> rx_overflow_irq: 0
>> rx_buf_unav_irq: 0
>> rx_process_stopped_irq: 0
>> rx_watchdog_irq: 0
>> tx_early_irq: 0
>> fatal_bus_error_irq: 0
>> rx_early_irq: 0
>> threshold: 1
>> tx_pkt_n: 83
>> rx_pkt_n: 133
>> normal_irq_n: 130
>> rx_normal_irq_n: 129
>> napi_poll: 130
>> tx_normal_irq_n: 1
>> tx_clean: 192
>> tx_set_ic_bit: 1
>> irq_receive_pmt_irq_n: 0
>> mmc_tx_irq_n: 0
>> mmc_rx_irq_n: 0
>> mmc_rx_csum_offload_irq_n: 0
>> irq_tx_path_in_lpi_mode_n: 72
>> irq_tx_path_exit_lpi_mode_n: 72
>> irq_rx_path_in_lpi_mode_n: 0
>> irq_rx_path_exit_lpi_mode_n: 0
>> phy_eee_wakeup_error_n: 65535
>> ip_hdr_err: 0
>> ip_payload_err: 0
>> ip_csum_bypassed: 0
>> ipv4_pkt_rcvd: 0
>> ipv6_pkt_rcvd: 0
>> no_ptp_rx_msg_type_ext: 0
>> ptp_rx_msg_type_sync: 0
>> ptp_rx_msg_type_follow_up: 0
>> ptp_rx_msg_type_delay_req: 0
>> ptp_rx_msg_type_delay_resp: 0
>> ptp_rx_msg_type_pdelay_req: 0
>> ptp_rx_msg_type_pdelay_resp: 0
>> ptp_rx_msg_type_pdelay_follow_up: 0
>> ptp_rx_msg_type_announce: 0
>> ptp_rx_msg_type_management: 0
>> ptp_rx_msg_pkt_reserved_type: 0
>> ptp_frame_type: 0
>> ptp_ver: 0
>> timestamp_dropped: 0
>> av_pkt_rcvd: 0
>> av_tagged_pkt_rcvd: 0
>> vlan_tag_priority_val: 0
>> l3_filter_match: 0
>> l4_filter_match: 0
>> l3_l4_filter_no_match: 0
>> irq_pcs_ane_n: 0
>> irq_pcs_link_n: 0
>> irq_rgmii_n: 0
>> mtl_tx_status_fifo_full: 0
>> mtl_tx_fifo_not_empty: 0
>> mmtl_fifo_ctrl: 0
>> mtl_tx_fifo_read_ctrl_write: 0
>> mtl_tx_fifo_read_ctrl_wait: 0
>> mtl_tx_fifo_read_ctrl_read: 0
>> mtl_tx_fifo_read_ctrl_idle: 0
>> mac_tx_in_pause: 0
>> mac_tx_frame_ctrl_xfer: 0
>> mac_tx_frame_ctrl_idle: 0
>> mac_tx_frame_ctrl_wait: 0
>> mac_tx_frame_ctrl_pause: 0
>> mac_gmii_tx_proto_engine: 0
>> mtl_rx_fifo_fill_level_full: 0
>> mtl_rx_fifo_fill_above_thresh: 0
>> mtl_rx_fifo_fill_below_thresh: 0
>> mtl_rx_fifo_fill_level_empty: 0
>> mtl_rx_fifo_read_ctrl_flush: 0
>> mtl_rx_fifo_read_ctrl_read_data: 0
>> mtl_rx_fifo_read_ctrl_status: 0
>> mtl_rx_fifo_read_ctrl_idle: 0
>> mtl_rx_fifo_ctrl_active: 0
>> mac_rx_frame_ctrl_fifo: 0
>> mac_gmii_rx_proto_engine: 0
>> tx_tso_frames: 0
>> tx_tso_nfrags: 0
>> [root@alarm ~]#
>>
>>
>>
>>
>> [root@alarm opt]# git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>> Cloning into 'linux-stable'...
>> remote: Counting objects: 6071472, done.
>> remote: Compressing objects: 100% (961861/961861), done.
>> Receiving objects: 0% (22798/6071472), 9.12 MiB | 3.47 MiB/s
>>
>>
>>
>> Over serial console:
>> journalctl -f
>> alarm systemd-timesyncd[256]: Timed out waiting for reply from
>> 144.76.197.108:123 (2.arch.pool.ntp.org).
>>
>> [root@alarm ~]# ping -c3 8.8.8.8
>> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
>> From 10.8.8.6 icmp_seq=1 Destination Host Unreachable
>> From 10.8.8.6 icmp_seq=2 Destination Host Unreachable
>> From 10.8.8.6 icmp_seq=3 Destination Host Unreachable
>>
>> --- 8.8.8.8 ping statistics ---
>> 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2047ms
>> pipe 3
>> [root@alarm ~]#
>> [root@alarm ~]# mii-tool -vvv eth0
>> Using SIOCGMIIPHY=0x8947
>> eth0: negotiated 1000baseT-HD flow-control, link ok
>> registers for MII PHY 8:
>> 1000 782d 0181 4400 01e1 c1e1 000d 2001
>> ffff ffff ffff ffff ffff ffff ffff ffff
>> 0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>> fff0 ffff 0000 000a 1407 0000 0000 105a
>> product info: vendor 00:60:51, model 0 rev 0
>> basic mode: autonegotiation enabled
>> basic status: autonegotiation complete, link ok
>> capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>> advertising: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>> link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>> [root@alarm ~]# ethtool -S eth0
>> NIC statistics:
>> mmc_tx_octetcount_gb: 0
>> mmc_tx_framecount_gb: 0
>> mmc_tx_broadcastframe_g: 0
>> mmc_tx_multicastframe_g: 0
>> mmc_tx_64_octets_gb: 0
>> mmc_tx_65_to_127_octets_gb: 0
>> mmc_tx_128_to_255_octets_gb: 0
>> mmc_tx_256_to_511_octets_gb: 0
>> mmc_tx_512_to_1023_octets_gb: 0
>> mmc_tx_1024_to_max_octets_gb: 0
>> mmc_tx_unicast_gb: 0
>> mmc_tx_multicast_gb: 0
>> mmc_tx_broadcast_gb: 0
>> mmc_tx_underflow_error: 0
>> mmc_tx_singlecol_g: 0
>> mmc_tx_multicol_g: 0
>> mmc_tx_deferred: 0
>> mmc_tx_latecol: 0
>> mmc_tx_exesscol: 0
>> mmc_tx_carrier_error: 0
>> mmc_tx_octetcount_g: 0
>> mmc_tx_framecount_g: 0
>> mmc_tx_excessdef: 0
>> mmc_tx_pause_frame: 0
>> mmc_tx_vlan_frame_g: 0
>> mmc_rx_framecount_gb: 14959
>> mmc_rx_octetcount_gb: 20761536
>> mmc_rx_octetcount_g: 20761536
>> mmc_rx_broadcastframe_g: 22
>> mmc_rx_multicastframe_g: 64
>> mmc_rx_crc_error: 0
>> mmc_rx_align_error: 0
>> mmc_rx_run_error: 0
>> mmc_rx_jabber_error: 0
>> mmc_rx_undersize_g: 0
>> mmc_rx_oversize_g: 0
>> mmc_rx_64_octets_gb: 495
>> mmc_rx_65_to_127_octets_gb: 658
>> mmc_rx_128_to_255_octets_gb: 73
>> mmc_rx_256_to_511_octets_gb: 63
>> mmc_rx_512_to_1023_octets_gb: 124
>> mmc_rx_1024_to_max_octets_gb: 13546
>> mmc_rx_unicast_g: 14873
>> mmc_rx_length_error: 0
>> mmc_rx_autofrangetype: 0
>> mmc_rx_pause_frames: 0
>> mmc_rx_fifo_overflow: 0
>> mmc_rx_vlan_frames_gb: 0
>> mmc_rx_watchdog_error: 0
>> mmc_rx_ipc_intr_mask: 2147385342
>> mmc_rx_ipc_intr: 0
>> mmc_rx_ipv4_gd: 14725
>> mmc_rx_ipv4_hderr: 0
>> mmc_rx_ipv4_nopay: 0
>> mmc_rx_ipv4_frag: 0
>> mmc_rx_ipv4_udsbl: 0
>> mmc_rx_ipv4_gd_octets: 20476749
>> mmc_rx_ipv4_hderr_octets: 0
>> mmc_rx_ipv4_nopay_octets: 0
>> mmc_rx_ipv4_frag_octets: 0
>> mmc_rx_ipv4_udsbl_octets: 0
>> mmc_rx_ipv6_gd_octets: 312
>> mmc_rx_ipv6_hderr_octets: 0
>> mmc_rx_ipv6_nopay_octets: 0
>> mmc_rx_ipv6_gd: 3
>> mmc_rx_ipv6_hderr: 0
>> mmc_rx_ipv6_nopay: 0
>> mmc_rx_udp_gd: 51
>> mmc_rx_udp_err: 0
>> mmc_rx_tcp_gd: 14673
>> mmc_rx_tcp_err: 0
>> mmc_rx_icmp_gd: 4
>> mmc_rx_icmp_err: 0
>> mmc_rx_udp_gd_octets: 3924
>> mmc_rx_udp_err_octets: 0
>> mmc_rx_tcp_gd_octets: 20178297
>> mmc_rx_tcp_err_octets: 0
>> mmc_rx_icmp_gd_octets: 220
>> mmc_rx_icmp_err_octets: 0
>> tx_underflow: 0
>> tx_carrier: 0
>> tx_losscarrier: 0
>> vlan_tag: 0
>> tx_deferred: 0
>> tx_vlan: 0
>> tx_jabber: 0
>> tx_frame_flushed: 0
>> tx_payload_error: 0
>> tx_ip_header_error: 0
>> rx_desc: 0
>> sa_filter_fail: 0
>> overflow_error: 0
>> ipc_csum_error: 0
>> rx_collision: 0
>> rx_crc_errors: 0
>> dribbling_bit: 0
>> rx_length: 0
>> rx_mii: 0
>> rx_multicast: 0
>> rx_gmac_overflow: 0
>> rx_watchdog: 0
>> da_rx_filter_fail: 0
>> sa_rx_filter_fail: 0
>> rx_missed_cntr: 0
>> rx_overflow_cntr: 0
>> rx_vlan: 0
>> tx_undeflow_irq: 0
>> tx_process_stopped_irq: 0
>> tx_jabber_irq: 0
>> rx_overflow_irq: 0
>> rx_buf_unav_irq: 0
>> rx_process_stopped_irq: 0
>> rx_watchdog_irq: 0
>> tx_early_irq: 0
>> fatal_bus_error_irq: 0
>> rx_early_irq: 6
>> threshold: 1
>> tx_pkt_n: 3709
>> rx_pkt_n: 12926
>> normal_irq_n: 4594
>> rx_normal_irq_n: 4537
>> napi_poll: 4597
>> tx_normal_irq_n: 57
>> tx_clean: 5109
>> tx_set_ic_bit: 59
>> irq_receive_pmt_irq_n: 0
>> mmc_tx_irq_n: 0
>> mmc_rx_irq_n: 0
>> mmc_rx_csum_offload_irq_n: 0
>> irq_tx_path_in_lpi_mode_n: 2921
>> irq_tx_path_exit_lpi_mode_n: 2920
>> irq_rx_path_in_lpi_mode_n: 0
>> irq_rx_path_exit_lpi_mode_n: 0
>> phy_eee_wakeup_error_n: 65535
>> ip_hdr_err: 0
>> ip_payload_err: 0
>> ip_csum_bypassed: 0
>> ipv4_pkt_rcvd: 0
>> ipv6_pkt_rcvd: 0
>> no_ptp_rx_msg_type_ext: 0
>> ptp_rx_msg_type_sync: 0
>> ptp_rx_msg_type_follow_up: 0
>> ptp_rx_msg_type_delay_req: 0
>> ptp_rx_msg_type_delay_resp: 0
>> ptp_rx_msg_type_pdelay_req: 0
>> ptp_rx_msg_type_pdelay_resp: 0
>> ptp_rx_msg_type_pdelay_follow_up: 0
>> ptp_rx_msg_type_announce: 0
>> ptp_rx_msg_type_management: 0
>> ptp_rx_msg_pkt_reserved_type: 0
>> ptp_frame_type: 0
>> ptp_ver: 0
>> timestamp_dropped: 0
>> av_pkt_rcvd: 0
>> av_tagged_pkt_rcvd: 0
>> vlan_tag_priority_val: 0
>> l3_filter_match: 0
>> l4_filter_match: 0
>> l3_l4_filter_no_match: 0
>> irq_pcs_ane_n: 0
>> irq_pcs_link_n: 0
>> irq_rgmii_n: 0
>> mtl_tx_status_fifo_full: 0
>> mtl_tx_fifo_not_empty: 0
>> mmtl_fifo_ctrl: 0
>> mtl_tx_fifo_read_ctrl_write: 0
>> mtl_tx_fifo_read_ctrl_wait: 0
>> mtl_tx_fifo_read_ctrl_read: 0
>> mtl_tx_fifo_read_ctrl_idle: 0
>> mac_tx_in_pause: 0
>> mac_tx_frame_ctrl_xfer: 0
>> mac_tx_frame_ctrl_idle: 0
>> mac_tx_frame_ctrl_wait: 0
>> mac_tx_frame_ctrl_pause: 0
>> mac_gmii_tx_proto_engine: 0
>> mtl_rx_fifo_fill_level_full: 0
>> mtl_rx_fifo_fill_above_thresh: 0
>> mtl_rx_fifo_fill_below_thresh: 0
>> mtl_rx_fifo_fill_level_empty: 0
>> mtl_rx_fifo_read_ctrl_flush: 0
>> mtl_rx_fifo_read_ctrl_read_data: 0
>> mtl_rx_fifo_read_ctrl_status: 0
>> mtl_rx_fifo_read_ctrl_idle: 0
>> mtl_rx_fifo_ctrl_active: 0
>> mac_rx_frame_ctrl_fifo: 0
>> mac_gmii_rx_proto_engine: 0
>> tx_tso_frames: 0
>> tx_tso_nfrags: 0
>> [root@alarm ~]#
>> [root@alarm ~]# ifconfig eth0 down && ifconfig eth0 up
>> Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL
>> Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
>> meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
>> meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow
>> control off
>> [root@alarm ~]#
>>
>>
>>
>> whole dmesg [1]. there are some messages like: mdio-mux-mmioreg
>> c883455c.eth-phy-mux: failed to register mdio-mux bus
>> /soc/periphs@c8834000/eth-phy-mux
>>
>> [1] https://defuse.ca/b/s2NpyJlw
>>
>> Regards,
>>
>>
>> On Tue, Jun 27, 2017 at 7:14 PM, crow <crow@linux.org.ba> wrote:
>> > Hi,
>> > There are other user reporting same issue while using mainline kernel
>> > but using Ubuntu, so this is for sure not Distribution related. For me
>> > see the [0]. I hope someone would get time after 4.12 release to try
>> > fix this issue.
>> >
>> > Regards,
>> >
>> > [0] http://forum.khadas.com/t/ubuntu-server-rom-linux-mainline-v170624-pre-a
>> > lpha-version-emmc-installation/803/12
>> >
>> > On Thu, Jun 15, 2017 at 4:40 PM, crow <crow@linux.org.ba> wrote:
>> > > Hi,
>> > >
>> > > On Sun, Jun 11, 2017 at 7:03 PM, crow <crow@linux.org.ba> wrote:
>> > > > Hi Andrew,
>> > > >
>> > > > On Sun, Jun 11, 2017 at 5:21 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > > > > > Thank your for the suggestion, and thanks Martin to explaining me
>> > > > > > over
>> > > > > > IRC what actually I should do.
>> > > > > >
>> > > > > > I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
>> > > > > > replaced drivers/net/phy/meson-gxl.c with
>> > > > > > https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethe
>> > > > > > rnet/phy/amlogic.c
>> > > > > >
>> > > > > > But this did not solve the issue. As soon as i start git clone i
>> > > > > > lose
>> > > > > > network connection to device (no session timeout/disconnect this
>> > > > > > time,
>> > > > > > but I am unable to reconnect over SSH or to get OK ping replay
>> > > > > > back).
>> > > >
>> > > > 1) First problem reported I can't reproduce anymore, every reboot/cold
>> > > > boot with mainline kernel the Ethernet speed is detected as
>> > > > "100Mbps/Full" , but as seen in first post there was this issue.
>> > >
>> > > Once I did setup u-boot to have network in u-boot and did just an ping
>> > > to activate network. And after boot Ethernet was detected as 10Mbps.
>> > > But again was not able to reproduce it. I double check that I have 5E
>> > > cable.
>> > >
>> > > in u-boot Ethernet is detected as below
>> > > kvim#ping x.x.x.x
>> > > Speed: 100, full duplex
>> > > Using dwmac.c9410000 device
>> > > host x.x.x.x is alive
>> > > kvim#
>> > >
>> > > then I let ArchLinuxArm to boot and found out I can't connect to
>> > > device over SSH. Check over serial console and found:
>> > >
>> > > # dmesg | tail -n 10
>> > > [ 8.334790] meson8b-dwmac c9410000.ethernet eth0: device MAC
>> > > address 00:15:18:01:81:31
>> > > [ 8.436668] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
>> > > driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
>> > > irq=-1)
>> > > [ 8.535171] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by
>> > > HW
>> > > [ 10.225264] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
>> > > wl0: Mar 1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
>> > > [ 10.635703] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
>> > > 10Mbps/Half - flow control off
>> > > # uname -a
>> > > Linux khadasvimpro 4.12.0-rc4-3-ARCH #1 SMP Thu Jun 8 00:17:20 CEST
>> > > 2017 aarch64 GNU/Linux
>> > > #
>> > > # mii-tool -vvv eth0
>> > > Using SIOCGMIIPHY=0x8947
>> > > eth0: no autonegotiation,, link ok
>> > > registers for MII PHY 8:
>> > > 1000 782d 0181 4400 01e1 0001 0005 2001
>> > > ffff ffff ffff ffff ffff ffff ffff ffff
>> > > 0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>> > > fff0 ffff 0000 000a 1407 0040 0000 105a
>> > > product info: vendor 00:60:51, model 0 rev 0
>> > > basic mode: autonegotiation enabled
>> > > basic status: autonegotiation complete, link ok
>> > > capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> > > 10baseT-FD 10baseT-HD
>> > > advertising: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> > > 10baseT-FD 10baseT-HD
>> > > #
>> > > # ifconfig eth0 down && ifconfig eth0 up
>> > > [ 1972.596690] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
>> > > driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
>> > > irq=-1)
>> > > [ 1972.704156] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by
>> > > HW
>> > > [ 1974.795698] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
>> > > 100Mbps/Full - flow control off
>> > > #
>> > > # mii-tool -vvv eth0
>> > > Using SIOCGMIIPHY=0x8947
>> > > eth0: negotiated 1000baseT-HD flow-control, link ok
>> > > registers for MII PHY 8:
>> > > 1000 782d 0181 4400 01e1 c1e1 000f 2001
>> > > ffff ffff ffff ffff ffff ffff ffff ffff
>> > > 0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>> > > fff0 ffff 0000 020a 1407 00ca 0000 105a
>> > > product info: vendor 00:60:51, model 0 rev 0
>> > > basic mode: autonegotiation enabled
>> > > basic status: autonegotiation complete, link ok
>> > > capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> > > 10baseT-FD 10baseT-HD
>> > > advertising: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> > > 10baseT-FD 10baseT-HD
>> > > link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> > > 10baseT-FD 10baseT-HD
>> > > #
>> > >
>> > > 2) see below
>> > > > 2) see below
>> > > >
>> > > > > So this shows it is more than a PHY problem. The Ethernet MAC driver
>> > > > > is probably also part of the problem.
>> > > >
>> > > > There are some stmmac fixes [1] in soon to be rc5, compiled current
>> > > > master (without amlogic.c) with the fixes but for me the issue still
>> > > > persist. I will compile once released rc5 with amlogic.c and report
>> > > > back.
>> > > >
>> > > > > Are there any mainline kernels which work O.K?
>> > > >
>> > > > Khadas VIM support was added in 4.12-rc1. And I did test all four rc's
>> > > > but without success.
>> > >
>> > > I did test many Kernel builds but all test have failed when
>> > > downloading bigger files / doing git clone.
>> > > As Martin Blumenstingl suggested I start with first commit where
>> > > Khadas VIM support was added [0]. Then also Neil Armstrong suggested
>> > > [1]. Then all 4.12-rc1 - rc5.
>> > > Martin Blumenstingl have also found himself that: "I can reproduce the
>> > > Ethernet problem (tried downloading a 1GiB test file from leaseweb,
>> > > network got stuck after downloading ~70 MiB)". He suggested that I
>> > > should "play with the settings on your switch (disable jumbo frames,
>> > > etc.) to rule out the "exotic" stuff?". Well other device (x86_64)
>> > > connected on this same Switch port does not have any problem
>> > > downloading big files or doing git clone, as well as Khadas VIM with
>> > > Amlogic kernel. Also jumbo frames are not enabled, switch does have
>> > > only standard settings.
>> > >
>> > > I also get questioned which qdisc I use:
>> > > And it seems I am already using fq_codel (ArchLinuxArm uses systemd):
>> > > $ tc -s -p qdisc
>> > > qdisc noqueue 0: dev lo root refcnt 2
>> > > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> > > backlog 0b 0p requeues 0
>> > > qdisc mq 0: dev eth0 root
>> > > Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
>> > > backlog 0b 0p requeues 18
>> > > qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum
>> > > 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
>> > > Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
>> > > backlog 0b 0p requeues 18
>> > > maxpacket 54 drop_overlimit 0 new_flow_count 14 ecn_mark 0
>> > > new_flows_len 0 old_flows_len 0
>> > > $ pacman -Qi systemd
>> > > Name : systemd
>> > > Version : 232-8
>> > > Description : system and service manager
>> > > Architecture : aarch64
>> > > ...
>> > > $
>> > >
>> > >
>> > > Regards,
>> > >
>> > > > > Andrew
>> > > >
>> > > > [1] https://github.com/torvalds/linux/commit/426849e6611f2092553f8d53372
>> > > > ae310818a6292
>> > >
>> > > [0] https://github.com/torvalds/linux/commit/e15d2774b8c096f116bf7192b37e8
>> > > 652da71369e
>> > > [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/khilman/linux
>> > > -amlogic/+/v4.12/integ
>>
Regards,
^ permalink raw reply
* Re: [PATCH] net: ethernet: stmmac: properly set PS bit in MII configurations during reset
From: Giuseppe CAVALLARO @ 2017-08-02 12:33 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Corentin Labbe, Alexandre Torgue, netdev, stable
In-Reply-To: <20170729215440.1ee341d9@windsurf.lan>
Hi Thomas
On 7/29/2017 9:54 PM, Thomas Petazzoni wrote:
> Hello Giuseppe,
>
> On Wed, 28 Jun 2017 16:40:51 +0200, Giuseppe CAVALLARO wrote:
>
>> I do not want to change a critical reset function shared among
>> different platforms where
>> this problem has never met but you are right that we have to find a
>> way to proceed in order
>> to finalize your work. Let me elaborate your initial patch and I try
>> to give you a proposal asap.
>> In my mind, we should have a dedicated spear_dma_reset for your case
>> that should be used on
>> SPEAr platform driver (or by using st,spear600-gmac compatibility).
>> Also your patch did not consider the RMII and (R)GMII cases.
> Have you had the chance to cook a different proposal? Alternatively, do
> you have some specific hints to give me to make a new proposal that
> would be acceptable for you ?
yes you are right and I had no chance to enter in this topic. :-(
We could follow one of the following approaches:
- add a new small platform driver where you can add ad-hoc code for
SPEAr.
Today there is a compatibility for st,spear600-gmac inside the
dwmac-generic.c
- introduce a new DT parameter to set the PS bit when resetting the HW.
The latter should be quite easy to implement starting from your original
patch,
this approach is not intrusive and can help others in case of the same
behavior is found.
What do you think?
Regards
Peppe
>
> Thanks a lot,
>
> Thomas Petazzoni
^ permalink raw reply
* Re: [PATCH nf-next] netfilter: constify nf_loginfo structures
From: Pablo Neira Ayuso @ 2017-08-02 12:24 UTC (permalink / raw)
To: Julia Lawall
Cc: David S. Miller, kernel-janitors, linux-kernel, netdev, coreteam,
netfilter-devel, Florian Westphal, Jozsef Kadlecsik,
Alexey Kuznetsov, Hideaki YOSHIFUJI
In-Reply-To: <1501584483-999-1-git-send-email-Julia.Lawall@lip6.fr>
On Tue, Aug 01, 2017 at 12:48:03PM +0200, Julia Lawall wrote:
> The nf_loginfo structures are only passed as the seventh argument to
> nf_log_trace, which is declared as const or stored in a local const
> variable. Thus the nf_loginfo structures themselves can be const.
>
> Done with the help of Coccinelle.
>
> // <smpl>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct nf_loginfo i@p = { ... };
>
> @ok1@
> identifier r.i;
> expression list[6] es;
> position p;
> @@
> nf_log_trace(es,&i@p,...)
>
> @ok2@
> identifier r.i;
> const struct nf_loginfo *e;
> position p;
> @@
> e = &i@p
>
> @bad@
> position p != {r.p,ok1.p,ok2.p};
> identifier r.i;
> struct nf_loginfo e;
> @@
> e@i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
> struct nf_loginfo i = { ... };
> // </smpl>
Applied, thanks Julia.
^ permalink raw reply
* Re: [PATCH 1/1 v3 nf-next] netfilter: constify nf_conntrack_l3/4proto parameters
From: Pablo Neira Ayuso @ 2017-08-02 12:23 UTC (permalink / raw)
To: Julia Lawall
Cc: David S. Miller, kernel-janitors, Jozsef Kadlecsik,
Florian Westphal, netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <1501583101-14188-2-git-send-email-Julia.Lawall@lip6.fr>
On Tue, Aug 01, 2017 at 12:25:01PM +0200, Julia Lawall wrote:
> When a nf_conntrack_l3/4proto parameter is not on the left hand side
> of an assignment, its address is not taken, and it is not passed to a
> function that may modify its fields, then it can be declared as const.
>
> This change is useful from a documentation point of view, and can
> possibly facilitate making some nf_conntrack_l3/4proto structures const
> subsequently.
>
> Done with the help of Coccinelle.
Applied, thanks Julia.
^ permalink raw reply
* Re: [PATCH net-next 1/2] bpf: add support for sys_{enter|exit}_* tracepoints
From: Peter Zijlstra @ 2017-08-02 12:07 UTC (permalink / raw)
To: Yonghong Song; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20170802063005.3220186-2-yhs@fb.com>
On Tue, Aug 01, 2017 at 11:30:04PM -0700, Yonghong Song wrote:
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 426c2ff..623c977 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -8050,7 +8050,7 @@ static void perf_event_free_bpf_handler(struct perf_event *event)
>
> static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
> {
> - bool is_kprobe, is_tracepoint;
> + bool is_cap_any, is_kprobe, is_tracepoint;
> struct bpf_prog *prog;
>
> if (event->attr.type != PERF_TYPE_TRACEPOINT)
> @@ -8059,9 +8059,11 @@ static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
> if (event->tp_event->prog)
> return -EEXIST;
>
> + /* currently, CAP_ANY only for sys_enter_* and sys_exit_* tracepoints */
> + is_cap_any = event->tp_event->flags & TRACE_EVENT_FL_CAP_ANY;
> is_kprobe = event->tp_event->flags & TRACE_EVENT_FL_UKPROBE;
> is_tracepoint = event->tp_event->flags & TRACE_EVENT_FL_TRACEPOINT;
> - if (!is_kprobe && !is_tracepoint)
> + if (!is_cap_any && !is_kprobe && !is_tracepoint)
> /* bpf programs can only be attached to u/kprobe or tracepoint */
> return -EINVAL;
>
> @@ -8070,7 +8072,8 @@ static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
> return PTR_ERR(prog);
>
> if ((is_kprobe && prog->type != BPF_PROG_TYPE_KPROBE) ||
> - (is_tracepoint && prog->type != BPF_PROG_TYPE_TRACEPOINT)) {
> + (is_tracepoint && prog->type != BPF_PROG_TYPE_TRACEPOINT) ||
> + (is_cap_any && prog->type != BPF_PROG_TYPE_TRACEPOINT)) {
> /* valid fd, but invalid bpf program type */
> bpf_prog_put(prog);
> return -EINVAL;
This looks wrong. FL_CAP_ANY is a privilege thing, not something that
identifies syscall hooks (it just so happens only those now have the bit
set, but that's an accident more than anything else).
^ permalink raw reply
* Re: [PATCH 6/6] [net-next]net: i40e: Enable cloud filters in i40e via tc/flower classifier
From: Jamal Hadi Salim @ 2017-08-02 12:02 UTC (permalink / raw)
To: Nambiar, Amritha, intel-wired-lan, jeffrey.t.kirsher
Cc: alexander.h.duyck, kiran.patil, netdev, mitch.a.williams,
alexander.duyck, neerav.parikh, sridhar.samudrala,
carolyn.wyborny, Or Gerlitz
In-Reply-To: <30cd59b5-4175-8641-f288-a2373475837d@intel.com>
On 17-08-01 10:13 PM, Nambiar, Amritha wrote:
>
> On 8/1/2017 3:56 AM, Jamal Hadi Salim wrote:
>> On 17-07-31 08:38 PM, Amritha Nambiar wrote:
>>> This patch enables tc-flower based hardware offloads. tc/flower
>>> filter provided by the kernel is configured as driver specific
>>> cloud filter. The patch implements functions and admin queue
>>> commands needed to support cloud filters in the driver and
>>> adds cloud filters to configure these tc-flower filters.
>>>
>>> The only action supported is to redirect packets to a traffic class
>>> on the same device.
>>>
>>> # tc qdisc add dev eth0 ingress
>>> # ethtool -K eth0 hw-tc-offload on
>>>
>>> # tc filter add dev eth0 protocol ip parent ffff:\
>>> prio 1 flower dst_mac 3c:fd:fe:a0:d6:70 skip_sw indev eth0\
>>> action mirred ingress redirect dev eth0 tc 0
>>>
>>
>> Out of curiosity - did you need to say "indev eth0" there?
>
> It looks like I don't need to specify "indev eth0". I will need to look
> up how this part is offloaded and probably validate in the driver when
> this is specified.
>
>> Also: Is it possible to add an skbmark? Example something like
>> these that directs two flows to the same queue but different
>> skb marks:
>>
>> # tc filter add dev eth0 protocol ip parent ffff: \
>> prio 2 flower dst_ip 192.168.3.5/32 \
>> ip_proto udp dst_port 2a skip_sw \
>> action skbedit mark 11 \
>> action mirred ingress redirect dev eth0 tcqueue 1
>>
>> # tc filter add dev eth0 protocol ip parent ffff: \
>> prio 1 flower dst_mac 3c:fd:fe:a0:d6:70 skip_sw \
>> action skbedit mark 12 \
>> action mirred ingress redirect dev eth0 tcqueue 1
>>
>
> It is possible to support the skbedit mark action for the first rule
> here (L3 and L4) which I can take up in a subsequent patch, but this
> cannot be supported on our device for L2 based match in the second rule.
>
Ok, thanks. So the issue is one of hardware limitation?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next RFC 0/6] Configure cloud filters in i40e via tc/flower classifier
From: Jamal Hadi Salim @ 2017-08-02 12:01 UTC (permalink / raw)
To: Nambiar, Amritha, intel-wired-lan, jeffrey.t.kirsher
Cc: alexander.h.duyck, kiran.patil, netdev, mitch.a.williams,
alexander.duyck, neerav.parikh, sridhar.samudrala,
carolyn.wyborny, Or Gerlitz
In-Reply-To: <78fbc08d-f846-a3e4-ffbd-f0cba43780e3@intel.com>
On 17-08-01 08:57 PM, Nambiar, Amritha wrote:
>
> On 8/1/2017 3:15 AM, Jamal Hadi Salim wrote:
>> On 17-07-31 08:36 PM, Amritha Nambiar wrote:
>>>
>>> # tc filter add dev eth0 protocol ip parent ffff: prio 1 flower\
>>> dst_ip 192.168.1.1/32 ip_proto udp dst_port 22\
>>> skip_sw indev eth0 action mirred ingress redirect dev eth0 tc 1
>>>
>>
>> I think "queue 1" sounds better than "tc 1".
>> "tc" is already a keyword in a few places (even within that declaration
>> above).
>
> The idea is to redirect to a traffic class that has queues assigned to
> it and not a single queue i.e. these are actually queue groups and not a
> single queue. So may be "qgroup 1" or "tcqgroup 1" fits better.
>
Can you describe how this works? So the specific memeber of a
a tcgroups show up on a specific rx DMA ring? If you only have
16 and 512 RX DMA rings - how does that work?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next] mdio_bus: Remove unneeded gpiod NULL check
From: Linus Walleij @ 2017-08-02 11:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: Fabio Estevam, Sergei Shtylyov, David S. Miller, Florian Fainelli,
netdev@vger.kernel.org, Fabio Estevam
In-Reply-To: <20170718133209.GB32757@lunn.ch>
On Tue, Jul 18, 2017 at 3:32 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, Jul 18, 2017 at 09:52:51AM -0300, Fabio Estevam wrote:
>> On Tue, Jul 18, 2017 at 9:48 AM, Sergei Shtylyov
>> <sergei.shtylyov@cogentembedded.com> wrote:
>> > On 07/18/2017 03:39 PM, Fabio Estevam wrote:
>> >
>> >>> Won't this result in kernel WARNING when GPIO is disabled?
>> >
>> >
>> > GPIO support, I was going to type...
>> >
>> >> Not sure if I understood your point, but gpiod_set_value_cansleep() is
>> >> a no-op when the gpiod is NULL.
>> >
>> >
>> > Look at the stub in <linux/gpio/consumer.h>, it has WARN_ON(1).
>>
>> This patch does not alter the behavior of the driver with respect to
>> GPIO being disabled, so I still do not understand your concern.
>
> http://elixir.free-electrons.com/linux/latest/source/include/linux/gpio/consumer.h#L345
> static inline void gpiod_set_value_cansleep(struct gpio_desc *desc, int value)
> {
> /* GPIO can never have been requested */
> WARN_ON(1);
> }
>
> But i would say this is a gpio problem. If GPIO enabled does not care,
> GPIO disabled should also not care.
If someone is using GPIO descriptors with GPIO disabled, i.e. calling
gpiod_get() and friends, this is very likely to be a bug, and what
the driver wants to do is:
depends on GPIOLIB
or
select GPIOLIB
in Kconfig. The whole optional thing is mainly a leftover from when it
was possible to have a local implementation of the GPIOLIB API in
some custom header file, noone sane should be doing that anymore,
and if they do, they can very well face the warnings.
If someone is facing a lot of WARN_ON() messages to this, it is a clear
indication that they need to fix their Kconfig and in that case it is proper.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [RFC PATCH v2 1/2] net: ethernet: nb8800: Reset HW block in ndo_open
From: Mason @ 2017-08-02 11:54 UTC (permalink / raw)
To: Mans Rullgard; +Cc: Florian Fainelli, David Miller, netdev, Linux ARM
In-Reply-To: <yw1xbmnyi660.fsf@mansr.com>
On 02/08/2017 13:02, Måns Rullgård wrote:
> Mason wrote:
>
>> Move all HW initializations to nb8800_init.
>> This provides the basis for suspend/resume support.
>> ---
>> drivers/net/ethernet/aurora/nb8800.c | 50 +++++++++++++++++-------------------
>> drivers/net/ethernet/aurora/nb8800.h | 1 +
>> 2 files changed, 25 insertions(+), 26 deletions(-)
>
> You're still not doing anything to preserve flow control and multicast
> configuration, and those are probably not the only ones.
I did handle flow control (as far as I can tell).
The current settings are stored in:
priv->pause_aneg, priv->pause_rx, priv->pause_tx
and nb8800_pause_config() is called from nb8800_link_reconfigure()
I'll take a closer look at multicast settings.
> Worse, you're now never tearing down dma properly, which means the
> hardware can be left with active pointers to memory no longer allocated
> to it.
You're making it sound like there is a risk those pointers
might be used somehow. There is no such risk AFAICT.
The PHY is disconnected, NAPI is stopped, RX and TX have
been disabled, and the ISR has been removed.
I have considered putting the HW block in reset (clock gated)
at the end of nb8800_stop() to save power, which would make
the issue you point out moot.
The reason I removed nb8800_dma_stop() in nb8800_stop()
is because it hangs when called from nb8800_suspend().
(It requires interrupts to make progress, and interrupts
seem to be disabled when nb8800_suspend() is called.)
Broader question for netdev:
I've been wondering about costly close operations.
If closing a device is complex (in terms of code), at which
point does it become simpler to just reset the block, and
avoid writing/maintaining/debugging the code performing
said close operation?
> Finally, you still haven't explained why the hw needs to be reset in
> ndo_open(). Whatever is causing your lockup can almost certainly be
> triggered in some other way too. I will not accept this side-stepping
> of the issue.
(I was not aware that you were the final authority on which
patches are accepted upstream.)
FWIW, I have placed a formal request for the HW dev to
investigate, as I could not reproduce on tango4, despite
several days wasted on this issue.
In the mean time, the driver in its current form does not
support suspend/resume. How would *you* implement it?
(IMO, my way is great in its simplicity and code reuse.)
Regards.
^ permalink raw reply
* Re: [PATCH v3 10/11] ARM64: dts: rockchip: Add gmac2phy node support for rk3328
From: Sergei Shtylyov @ 2017-08-02 11:49 UTC (permalink / raw)
To: David Wu, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
heiko-4mtYJXux2i+zQB+pC5nmwQ, andrew-g2DYL2Zd6BY,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, olof-nZhT3qVonbNeoWH0uzbU5w,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, arnd-r2nGTMty4D4
Cc: peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
huangtao-TNX95d0MmH7DzftRWevZcw, hwg-TNX95d0MmH7DzftRWevZcw,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1501655097-21054-1-git-send-email-david.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hello!
On 08/02/2017 09:24 AM, David Wu wrote:
> The gmac2phy controller of rk3328 is connected to internal phy
> directly inside, add the node for the internal phy support.
>
> Signed-off-by: David Wu <david.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> arch/arm64/boot/dts/rockchip/rk3328.dtsi | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index 0be96ce..51c8c66 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
[...]
> @@ -424,6 +426,29 @@
> status = "disabled";
> };
>
> + gmac2phy: eth@ff550000 {
The standardized name is ethernet@...
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH iproute2 2/2] actions: update the man page to describe the "since" time filter
From: Jamal Hadi Salim @ 2017-08-02 11:46 UTC (permalink / raw)
To: stephen
Cc: netdev, jiri, xiyou.wangcong, eric.dumazet, dsahern,
Jamal Hadi Salim
In-Reply-To: <1501674387-15001-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
man/man8/tc-actions.8 | 31 +++++++++++++++++++++++++++----
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/man/man8/tc-actions.8 b/man/man8/tc-actions.8
index 51f43af..f46166e 100644
--- a/man/man8/tc-actions.8
+++ b/man/man8/tc-actions.8
@@ -1,4 +1,4 @@
-.TH "actions in tc" 8 "4 Jul 2017" "iproute2" "Linux"
+.TH "actions in tc" 8 "1 Aug 2017" "iproute2" "Linux"
.SH NAME
actions \- independently defined actions in tc
@@ -33,6 +33,9 @@ actions \- independently defined actions in tc
.B actions
.BR ls " | " list
.I ACTNAMESPEC
+[
+.I ACTFILTER
+]
.in +8
.I ACTSPEC
@@ -60,6 +63,10 @@ ACTNAME
:=
.BI index " INDEX"
+.I ACTFILTER
+:=
+.BI since " MSTIME"
+
.I COOKIESPEC
:=
.BI cookie " COOKIE"
@@ -71,9 +78,8 @@ ACTNAME
.I ACTNAME
may be any valid action type: gact, mirred, bpf, connmark, csum, police, etc.
-.I ACTPARAMS
-are the action-specific parameters; see the man page for the specific action
-type to be used for details.
+.I MSTIME
+Time since last update.
.I CONTROL
:= {
@@ -132,6 +138,10 @@ List all the actions in the specified table. When combined with the
option for
.BR tc ","
display the statistics for all actions in the specified table.
+When combined with the option
+.B since
+allows doing a millisecond time-filter since the last time an
+action was used in the datapath.
.TP
.B flush
Delete all actions stored in the specified table.
@@ -177,6 +187,19 @@ The value to be stored is completely arbitrary and does not require a specific
format. It is stored inside the action structure itself.
.TP
+.BI since " MSTIME"
+When dumping large number of actions, a millisecond time-filter can be
+specified
+.IR MSTIME "."
+The
+.I MSTIME
+is a millisecond count since last time a packet hit the action.
+As an example specifying "since 20000" implies to dump all actions
+that have seen packets in the last 20 seconds. This option is useful
+when the kernel has a large number of actions and you are only interested
+in recently used actions.
+
+.TP
.I CONTROL
The
.I CONTROL
--
1.9.1
^ permalink raw reply related
* [PATCH iproute2 1/2] tc actions: Improved batching and time filtered dumping
From: Jamal Hadi Salim @ 2017-08-02 11:46 UTC (permalink / raw)
To: stephen
Cc: netdev, jiri, xiyou.wangcong, eric.dumazet, dsahern,
Jamal Hadi Salim
From: Jamal Hadi Salim <jhs@mojatatu.com>
dump more than TCA_ACT_MAX_PRIO actions per batch when the kernel
supports it.
Introduced keyword "since" for time based filtering of actions.
Some example (we have 400 actions bound to 400 filters); at
installation time. Using updated when tc setting the time of
interest to 120 seconds earlier (we see 400 actions):
prompt$ hackedtc actions ls action gact since 120000| grep index | wc -l
400
go get some coffee and wait for > 120 seconds and try again:
prompt$ hackedtc actions ls action gact since 120000 | grep index | wc -l
0
Lets see a filter bound to one of these actions:
....
filter pref 10 u32
filter pref 10 u32 fh 800: ht divisor 1
filter pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 2 success 1)
match 7f000002/ffffffff at 12 (success 1 )
action order 1: gact action pass
random type none pass val 0
index 23 ref 2 bind 1 installed 1145 sec used 802 sec
Action statistics:
Sent 84 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
...
that coffee took long, no? It was good.
Now lets ping -c 1 127.0.0.2, then run the actions again:
prompt$ hackedtc actions ls action gact since 120 | grep index | wc -l
1
More details please:
prompt$ hackedtc -s actions ls action gact since 120000
action order 0: gact action pass
random type none pass val 0
index 23 ref 2 bind 1 installed 1270 sec used 30 sec
Action statistics:
Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
And the filter?
filter pref 10 u32
filter pref 10 u32 fh 800: ht divisor 1
filter pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 4 success 2)
match 7f000002/ffffffff at 12 (success 2 )
action order 1: gact action pass
random type none pass val 0
index 23 ref 2 bind 1 installed 1324 sec used 84 sec
Action statistics:
Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
tc/f_basic.c | 2 +-
tc/f_bpf.c | 2 +-
tc/f_cgroup.c | 2 +-
tc/f_flow.c | 2 +-
tc/f_flower.c | 2 +-
tc/f_fw.c | 2 +-
tc/f_matchall.c | 2 +-
tc/f_route.c | 2 +-
tc/f_rsvp.c | 2 +-
tc/f_tcindex.c | 2 +-
tc/f_u32.c | 2 +-
tc/m_action.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++-----------
tc/tc_util.h | 2 +-
13 files changed, 72 insertions(+), 26 deletions(-)
diff --git a/tc/f_basic.c b/tc/f_basic.c
index d663668..8370ea6 100644
--- a/tc/f_basic.c
+++ b/tc/f_basic.c
@@ -135,7 +135,7 @@ static int basic_print_opt(struct filter_util *qu, FILE *f,
}
if (tb[TCA_BASIC_ACT]) {
- tc_print_action(f, tb[TCA_BASIC_ACT]);
+ tc_print_action(f, tb[TCA_BASIC_ACT], 0);
}
return 0;
diff --git a/tc/f_bpf.c b/tc/f_bpf.c
index 2f8d12a..c115409 100644
--- a/tc/f_bpf.c
+++ b/tc/f_bpf.c
@@ -239,7 +239,7 @@ static int bpf_print_opt(struct filter_util *qu, FILE *f,
}
if (tb[TCA_BPF_ACT])
- tc_print_action(f, tb[TCA_BPF_ACT]);
+ tc_print_action(f, tb[TCA_BPF_ACT], 0);
return 0;
}
diff --git a/tc/f_cgroup.c b/tc/f_cgroup.c
index ecf9909..633700e 100644
--- a/tc/f_cgroup.c
+++ b/tc/f_cgroup.c
@@ -102,7 +102,7 @@ static int cgroup_print_opt(struct filter_util *qu, FILE *f,
}
if (tb[TCA_CGROUP_ACT])
- tc_print_action(f, tb[TCA_CGROUP_ACT]);
+ tc_print_action(f, tb[TCA_CGROUP_ACT], 0);
return 0;
}
diff --git a/tc/f_flow.c b/tc/f_flow.c
index 09ddcaa..b157104 100644
--- a/tc/f_flow.c
+++ b/tc/f_flow.c
@@ -347,7 +347,7 @@ static int flow_print_opt(struct filter_util *fu, FILE *f, struct rtattr *opt,
tc_print_police(f, tb[TCA_FLOW_POLICE]);
if (tb[TCA_FLOW_ACT]) {
fprintf(f, "\n");
- tc_print_action(f, tb[TCA_FLOW_ACT]);
+ tc_print_action(f, tb[TCA_FLOW_ACT], 0);
}
return 0;
}
diff --git a/tc/f_flower.c b/tc/f_flower.c
index 5be693a..934832e 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -1316,7 +1316,7 @@ static int flower_print_opt(struct filter_util *qu, FILE *f,
}
if (tb[TCA_FLOWER_ACT])
- tc_print_action(f, tb[TCA_FLOWER_ACT]);
+ tc_print_action(f, tb[TCA_FLOWER_ACT], 0);
return 0;
}
diff --git a/tc/f_fw.c b/tc/f_fw.c
index 790bef9..c39789b 100644
--- a/tc/f_fw.c
+++ b/tc/f_fw.c
@@ -160,7 +160,7 @@ static int fw_print_opt(struct filter_util *qu, FILE *f, struct rtattr *opt, __u
if (tb[TCA_FW_ACT]) {
fprintf(f, "\n");
- tc_print_action(f, tb[TCA_FW_ACT]);
+ tc_print_action(f, tb[TCA_FW_ACT], 0);
}
return 0;
}
diff --git a/tc/f_matchall.c b/tc/f_matchall.c
index 5a51e75..d78660e 100644
--- a/tc/f_matchall.c
+++ b/tc/f_matchall.c
@@ -145,7 +145,7 @@ static int matchall_print_opt(struct filter_util *qu, FILE *f,
}
if (tb[TCA_MATCHALL_ACT])
- tc_print_action(f, tb[TCA_MATCHALL_ACT]);
+ tc_print_action(f, tb[TCA_MATCHALL_ACT], 0);
return 0;
}
diff --git a/tc/f_route.c b/tc/f_route.c
index 30514c4..e88313f 100644
--- a/tc/f_route.c
+++ b/tc/f_route.c
@@ -168,7 +168,7 @@ static int route_print_opt(struct filter_util *qu, FILE *f, struct rtattr *opt,
if (tb[TCA_ROUTE4_POLICE])
tc_print_police(f, tb[TCA_ROUTE4_POLICE]);
if (tb[TCA_ROUTE4_ACT])
- tc_print_action(f, tb[TCA_ROUTE4_ACT]);
+ tc_print_action(f, tb[TCA_ROUTE4_ACT], 0);
return 0;
}
diff --git a/tc/f_rsvp.c b/tc/f_rsvp.c
index 94bfbef..65caeb4 100644
--- a/tc/f_rsvp.c
+++ b/tc/f_rsvp.c
@@ -402,7 +402,7 @@ static int rsvp_print_opt(struct filter_util *qu, FILE *f, struct rtattr *opt, _
}
if (tb[TCA_RSVP_ACT]) {
- tc_print_action(f, tb[TCA_RSVP_ACT]);
+ tc_print_action(f, tb[TCA_RSVP_ACT], 0);
}
if (tb[TCA_RSVP_POLICE])
tc_print_police(f, tb[TCA_RSVP_POLICE]);
diff --git a/tc/f_tcindex.c b/tc/f_tcindex.c
index 784c890..dd1cb47 100644
--- a/tc/f_tcindex.c
+++ b/tc/f_tcindex.c
@@ -173,7 +173,7 @@ static int tcindex_print_opt(struct filter_util *qu, FILE *f,
}
if (tb[TCA_TCINDEX_ACT]) {
fprintf(f, "\n");
- tc_print_action(f, tb[TCA_TCINDEX_ACT]);
+ tc_print_action(f, tb[TCA_TCINDEX_ACT], 0);
}
return 0;
}
diff --git a/tc/f_u32.c b/tc/f_u32.c
index b272c2c..5815be9 100644
--- a/tc/f_u32.c
+++ b/tc/f_u32.c
@@ -1337,7 +1337,7 @@ static int u32_print_opt(struct filter_util *qu, FILE *f, struct rtattr *opt,
}
if (tb[TCA_U32_ACT])
- tc_print_action(f, tb[TCA_U32_ACT]);
+ tc_print_action(f, tb[TCA_U32_ACT], 0);
return 0;
}
diff --git a/tc/m_action.c b/tc/m_action.c
index 6ebe85e..50d16b4 100644
--- a/tc/m_action.c
+++ b/tc/m_action.c
@@ -346,21 +346,25 @@ tc_print_action_flush(FILE *f, const struct rtattr *arg)
}
int
-tc_print_action(FILE *f, const struct rtattr *arg)
+tc_print_action(FILE *f, const struct rtattr *arg, unsigned short tot_acts)
{
int i;
- struct rtattr *tb[TCA_ACT_MAX_PRIO + 1];
if (arg == NULL)
return 0;
- parse_rtattr_nested(tb, TCA_ACT_MAX_PRIO, arg);
+ if (!tot_acts)
+ tot_acts = TCA_ACT_MAX_PRIO;
+
+ struct rtattr *tb[tot_acts + 1];
+
+ parse_rtattr_nested(tb, tot_acts, arg);
if (tab_flush && NULL != tb[0] && NULL == tb[1])
return tc_print_action_flush(f, tb[0]);
- for (i = 0; i < TCA_ACT_MAX_PRIO; i++) {
+ for (i = 0; i < tot_acts; i++) {
if (tb[i]) {
fprintf(f, "\n\taction order %d: ", i);
if (tc_print_one_action(f, tb[i]) < 0) {
@@ -380,7 +384,8 @@ int print_action(const struct sockaddr_nl *who,
FILE *fp = (FILE *)arg;
struct tcamsg *t = NLMSG_DATA(n);
int len = n->nlmsg_len;
- struct rtattr *tb[TCAA_MAX+1];
+ __u32 *tot_acts = NULL;
+ struct rtattr *tb[TCA_ROOT_MAX+1];
len -= NLMSG_LENGTH(sizeof(*t));
@@ -389,8 +394,12 @@ int print_action(const struct sockaddr_nl *who,
return -1;
}
- parse_rtattr(tb, TCAA_MAX, TA_RTA(t), len);
+ parse_rtattr(tb, TCA_ROOT_MAX, TA_RTA(t), len);
+
+ if (tb[TCA_ROOT_COUNT])
+ tot_acts = RTA_DATA(tb[TCA_ROOT_COUNT]);
+ fprintf(fp, "total acts %d\n", tot_acts ? *tot_acts:0);
if (tb[TCA_ACT_TAB] == NULL) {
if (n->nlmsg_type != RTM_GETACTION)
fprintf(stderr, "print_action: NULL kind\n");
@@ -414,7 +423,9 @@ int print_action(const struct sockaddr_nl *who,
fprintf(fp, "Replaced action ");
}
}
- tc_print_action(fp, tb[TCA_ACT_TAB]);
+
+
+ tc_print_action(fp, tb[TCA_ACT_TAB], tot_acts ? *tot_acts:0);
return 0;
}
@@ -427,7 +438,7 @@ static int tc_action_gd(int cmd, unsigned int flags, int *argc_p, char ***argv_p
char **argv = *argv_p;
int prio = 0;
int ret = 0;
- __u32 i;
+ __u32 i = 0;
struct rtattr *tail;
struct rtattr *tail2;
struct nlmsghdr *ans = NULL;
@@ -498,7 +509,8 @@ static int tc_action_gd(int cmd, unsigned int flags, int *argc_p, char ***argv_p
tail2 = NLMSG_TAIL(&req.n);
addattr_l(&req.n, MAX_MSG, ++prio, NULL, 0);
addattr_l(&req.n, MAX_MSG, TCA_ACT_KIND, k, strlen(k) + 1);
- addattr32(&req.n, MAX_MSG, TCA_ACT_INDEX, i);
+ if (i > 0)
+ addattr32(&req.n, MAX_MSG, TCA_ACT_INDEX, i);
tail2->rta_len = (void *) NLMSG_TAIL(&req.n) - (void *) tail2;
}
@@ -561,12 +573,16 @@ static int tc_action_modify(int cmd, unsigned int flags, int *argc_p, char ***ar
return ret;
}
-static int tc_act_list_or_flush(int argc, char **argv, int event)
+static int tc_act_list_or_flush(int *argc_p, char ***argv_p, int event)
{
+ struct rtattr *tail, *tail2, *tail3, *tail4;
int ret = 0, prio = 0, msg_size = 0;
- char k[16];
- struct rtattr *tail, *tail2;
struct action_util *a = NULL;
+ struct nla_bitfield32 flag_select = { 0 };
+ char **argv = *argv_p;
+ __u32 msec_since = 0;
+ int argc = *argc_p;
+ char k[16];
struct {
struct nlmsghdr n;
struct tcamsg t;
@@ -597,11 +613,31 @@ static int tc_act_list_or_flush(int argc, char **argv, int event)
}
strncpy(k, *argv, sizeof(k) - 1);
+ argc -= 1;
+ argv += 1;
+
+ if (argc && (strcmp(*argv, "since") == 0)) {
+ NEXT_ARG();
+ if (get_u32(&msec_since, *argv, 0))
+ invarg("dump time \"since\" is invalid", *argv);
+ }
+
addattr_l(&req.n, MAX_MSG, ++prio, NULL, 0);
addattr_l(&req.n, MAX_MSG, TCA_ACT_KIND, k, strlen(k) + 1);
tail2->rta_len = (void *) NLMSG_TAIL(&req.n) - (void *) tail2;
tail->rta_len = (void *) NLMSG_TAIL(&req.n) - (void *) tail;
+ tail3 = NLMSG_TAIL(&req.n);
+ flag_select.value |= TCA_FLAG_LARGE_DUMP_ON;
+ flag_select.selector |= TCA_FLAG_LARGE_DUMP_ON;
+ addattr_l(&req.n, MAX_MSG, TCA_ROOT_FLAGS, &flag_select,
+ sizeof(struct nla_bitfield32));
+ tail3->rta_len = (void *) NLMSG_TAIL(&req.n) - (void *) tail3;
+ if (msec_since) {
+ tail4 = NLMSG_TAIL(&req.n);
+ addattr32(&req.n, MAX_MSG, TCA_ROOT_TIME_DELTA, msec_since);
+ tail4->rta_len = (void *) NLMSG_TAIL(&req.n) - (void *) tail4;
+ }
msg_size = NLMSG_ALIGN(req.n.nlmsg_len) - NLMSG_ALIGN(sizeof(struct nlmsghdr));
if (event == RTM_GETACTION) {
@@ -626,6 +662,8 @@ static int tc_act_list_or_flush(int argc, char **argv, int event)
bad_val:
+ *argc_p = argc;
+ *argv_p = argv;
return ret;
}
@@ -655,13 +693,21 @@ int do_action(int argc, char **argv)
act_usage();
return -1;
}
- return tc_act_list_or_flush(argc-2, argv+2, RTM_GETACTION);
+
+ argc -= 2;
+ argv += 2;
+ return tc_act_list_or_flush(&argc, &argv,
+ RTM_GETACTION);
} else if (matches(*argv, "flush") == 0) {
if (argc <= 2) {
act_usage();
return -1;
}
- return tc_act_list_or_flush(argc-2, argv+2, RTM_DELACTION);
+
+ argc -= 2;
+ argv += 2;
+ return tc_act_list_or_flush(&argc, &argv,
+ RTM_DELACTION);
} else if (matches(*argv, "help") == 0) {
act_usage();
return -1;
diff --git a/tc/tc_util.h b/tc/tc_util.h
index 5c54ad3..583a21a 100644
--- a/tc/tc_util.h
+++ b/tc/tc_util.h
@@ -113,7 +113,7 @@ int act_parse_police(struct action_util *a, int *argc_p,
char ***argv_p, int tca_id, struct nlmsghdr *n);
int print_police(struct action_util *a, FILE *f, struct rtattr *tb);
int police_print_xstats(struct action_util *a, FILE *f, struct rtattr *tb);
-int tc_print_action(FILE *f, const struct rtattr *tb);
+int tc_print_action(FILE *f, const struct rtattr *tb, unsigned short tot_acts);
int tc_print_ipt(FILE *f, const struct rtattr *tb);
int parse_action(int *argc_p, char ***argv_p, int tca_id, struct nlmsghdr *n);
void print_tm(FILE *f, const struct tcf_t *tm);
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox