* 728915 netdev
From: momofr @ 2016-10-10 8:30 UTC (permalink / raw)
To: netdev
[-- Attachment #1: EMAIL_7265575145931_netdev.zip --]
[-- Type: application/zip, Size: 5471 bytes --]
^ permalink raw reply
* Re: [PATCH 10/10] net: mdio-sam: Add device tree documentation for SAM MDIO
From: Florian Fainelli @ 2016-10-10 8:50 UTC (permalink / raw)
To: Pantelis Antoniou, Lee Jones
Cc: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
Frank Rowand, Wolfram Sang, David Woodhouse, Brian Norris,
Wim Van Sebroeck, Peter Rosin, Debjit Ghosh, Georgi Vlaev,
Guenter Roeck, Maryam Seraj, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1475853518-22264-11-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
On 10/07/2016 08:18 AM, Pantelis Antoniou wrote:
> From: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
>
> Add device tree bindings document for the SAM MDIO block
> present in Juniper's SAM FPGA.
>
> Signed-off-by: Georgi Vlaev <gvlaev-3r7Miqu9kMnR7s880joybQ@public.gmane.org>
> [Ported from Juniper kernel]
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/mdio-sam.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/mdio-sam.txt
>
> diff --git a/Documentation/devicetree/bindings/net/mdio-sam.txt b/Documentation/devicetree/bindings/net/mdio-sam.txt
> new file mode 100644
> index 0000000..7d354e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/mdio-sam.txt
> @@ -0,0 +1,48 @@
> +Juniper SAM FPGA MFD MDIO bus properties.
> +
> +Required properties:
> +- compatible : "jnx,mdio-sam"
> +- reg : The start offset of the MDIO bus range
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +
> +Optional properties:
> +
> +Required properties for child nodes:
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +- reg : The MDIO bus offset within the MDIO range.
I would just refer to Documentation/devicetree/bindings/net/phy.txt for
the child node properties.
Other than that:
Reviewed-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--
Florian
--
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 net] xen-netback: (re-)create a debugfs node for hash information
From: Paul Durrant @ 2016-10-10 8:30 UTC (permalink / raw)
To: netdev, xen-devel; +Cc: Paul Durrant, Paul Durrant, Wei Liu, David S. Miller
From: Paul Durrant <Paul.Durrant@citrix.com>
It is useful to be able to see the hash configuration when running tests.
This patch adds a debugfs node for that purpose.
The original version of this patch (commit c0c64c152389) was reverted due
to build failures caused by a conflict with commit 0364a8824c02
("xen-netback: switch to threaded irq for control ring"). This new version
of the patch is nearly identical to the original, the only difference
being that creation of the debugfs node is predicated on 'ctrl_irq' being
non-zero rather then the now non-existent 'ctrl_task'.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: David S. Miller <davem@davemloft.net>
---
drivers/net/xen-netback/common.h | 4 +++
drivers/net/xen-netback/hash.c | 68 ++++++++++++++++++++++++++++++++++++++++
drivers/net/xen-netback/xenbus.c | 37 ++++++++++++++++++++--
3 files changed, 107 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index cf68149..3ce1f7d 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -407,4 +407,8 @@ u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, u32 len,
void xenvif_set_skb_hash(struct xenvif *vif, struct sk_buff *skb);
+#ifdef CONFIG_DEBUG_FS
+void xenvif_dump_hash_info(struct xenvif *vif, struct seq_file *m);
+#endif
+
#endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/hash.c b/drivers/net/xen-netback/hash.c
index 613bac0..e8c5ddd 100644
--- a/drivers/net/xen-netback/hash.c
+++ b/drivers/net/xen-netback/hash.c
@@ -360,6 +360,74 @@ u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, u32 len,
return XEN_NETIF_CTRL_STATUS_SUCCESS;
}
+#ifdef CONFIG_DEBUG_FS
+void xenvif_dump_hash_info(struct xenvif *vif, struct seq_file *m)
+{
+ unsigned int i;
+
+ switch (vif->hash.alg) {
+ case XEN_NETIF_CTRL_HASH_ALGORITHM_TOEPLITZ:
+ seq_puts(m, "Hash Algorithm: TOEPLITZ\n");
+ break;
+
+ case XEN_NETIF_CTRL_HASH_ALGORITHM_NONE:
+ seq_puts(m, "Hash Algorithm: NONE\n");
+ /* FALLTHRU */
+ default:
+ return;
+ }
+
+ if (vif->hash.flags) {
+ seq_puts(m, "\nHash Flags:\n");
+
+ if (vif->hash.flags & XEN_NETIF_CTRL_HASH_TYPE_IPV4)
+ seq_puts(m, "- IPv4\n");
+ if (vif->hash.flags & XEN_NETIF_CTRL_HASH_TYPE_IPV4_TCP)
+ seq_puts(m, "- IPv4 + TCP\n");
+ if (vif->hash.flags & XEN_NETIF_CTRL_HASH_TYPE_IPV6)
+ seq_puts(m, "- IPv6\n");
+ if (vif->hash.flags & XEN_NETIF_CTRL_HASH_TYPE_IPV6_TCP)
+ seq_puts(m, "- IPv6 + TCP\n");
+ }
+
+ seq_puts(m, "\nHash Key:\n");
+
+ for (i = 0; i < XEN_NETBK_MAX_HASH_KEY_SIZE; ) {
+ unsigned int j, n;
+
+ n = 8;
+ if (i + n >= XEN_NETBK_MAX_HASH_KEY_SIZE)
+ n = XEN_NETBK_MAX_HASH_KEY_SIZE - i;
+
+ seq_printf(m, "[%2u - %2u]: ", i, i + n - 1);
+
+ for (j = 0; j < n; j++, i++)
+ seq_printf(m, "%02x ", vif->hash.key[i]);
+
+ seq_puts(m, "\n");
+ }
+
+ if (vif->hash.size != 0) {
+ seq_puts(m, "\nHash Mapping:\n");
+
+ for (i = 0; i < vif->hash.size; ) {
+ unsigned int j, n;
+
+ n = 8;
+ if (i + n >= vif->hash.size)
+ n = vif->hash.size - i;
+
+ seq_printf(m, "[%4u - %4u]: ", i, i + n - 1);
+
+ for (j = 0; j < n; j++, i++)
+ seq_printf(m, "%4u ", vif->hash.mapping[i]);
+
+ seq_puts(m, "\n");
+ }
+ }
+}
+#endif /* CONFIG_DEBUG_FS */
+
void xenvif_init_hash(struct xenvif *vif)
{
if (xenvif_hash_cache_size == 0)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 7056404..8674e18 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -165,7 +165,7 @@ xenvif_write_io_ring(struct file *filp, const char __user *buf, size_t count,
return count;
}
-static int xenvif_dump_open(struct inode *inode, struct file *filp)
+static int xenvif_io_ring_open(struct inode *inode, struct file *filp)
{
int ret;
void *queue = NULL;
@@ -179,13 +179,35 @@ static int xenvif_dump_open(struct inode *inode, struct file *filp)
static const struct file_operations xenvif_dbg_io_ring_ops_fops = {
.owner = THIS_MODULE,
- .open = xenvif_dump_open,
+ .open = xenvif_io_ring_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
.write = xenvif_write_io_ring,
};
+static int xenvif_read_ctrl(struct seq_file *m, void *v)
+{
+ struct xenvif *vif = m->private;
+
+ xenvif_dump_hash_info(vif, m);
+
+ return 0;
+}
+
+static int xenvif_ctrl_open(struct inode *inode, struct file *filp)
+{
+ return single_open(filp, xenvif_read_ctrl, inode->i_private);
+}
+
+static const struct file_operations xenvif_dbg_ctrl_ops_fops = {
+ .owner = THIS_MODULE,
+ .open = xenvif_ctrl_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
static void xenvif_debugfs_addif(struct xenvif *vif)
{
struct dentry *pfile;
@@ -210,6 +232,17 @@ static void xenvif_debugfs_addif(struct xenvif *vif)
pr_warn("Creation of io_ring file returned %ld!\n",
PTR_ERR(pfile));
}
+
+ if (vif->ctrl_irq) {
+ pfile = debugfs_create_file("ctrl",
+ S_IRUSR,
+ vif->xenvif_dbg_root,
+ vif,
+ &xenvif_dbg_ctrl_ops_fops);
+ if (IS_ERR_OR_NULL(pfile))
+ pr_warn("Creation of ctrl file returned %ld!\n",
+ PTR_ERR(pfile));
+ }
} else
netdev_warn(vif->dev,
"Creation of vif debugfs dir returned %ld!\n",
--
2.1.4
^ permalink raw reply related
* igb driver can cause cache invalidation of non-owned memory?
From: Nikita Yushchenko @ 2016-10-10 8:52 UTC (permalink / raw)
To: Jeff Kirsher, intel-wired-lan, netdev, linux-kernel; +Cc: Chris Healy
Hi
DMA mapping scheme introduced in commit cbc8e55f6fda ('igb: Map entire
page and sync half instead of mapping and unmapping half pages') back in
2012, and used up to now, can probably cause breakage of unrelated code
on archs with non-coherent caches.
With this scheme, page used for Rx is completely dma_map()ed at
allocation time, split into two buffers, and individual buffer is
sync_to_cpu()ed AND PASSED TO NETWORK STACK via skb_add_rx_frag() -
while driver driver still uses other buffer. Later, when driver decides
to no longer use this page, it will dma_unmap() it completely - which on
archs with non-coherent caches means cache invalidation. This cache
invalidation will include area that is already passed elsewhere. If
external code has performed any writes to that area and writes still are
in cache only, cache invalidation will cause writes to be lost.
I'm not sure if this breakage is indeed possible. I did not face it,
just found while checking how things work.
Code in question is in kernel already for 4 years. However, since (1)
igb is mostly used on x86 where caches are coherent, and (2) Rx buffers
are normally not written to, it could stay unnoticed all that time.
Could somebody please comment on this?
Nikita Yushchenko
^ permalink raw reply
* Re: igb driver can cause cache invalidation of non-owned memory?
From: David Miller @ 2016-10-10 9:01 UTC (permalink / raw)
To: nikita.yoush
Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel, cphealy
In-Reply-To: <0b57cbe2-84f7-6c0a-904a-d166571234b5@cogentembedded.com>
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Date: Mon, 10 Oct 2016 11:52:06 +0300
> With this scheme, page used for Rx is completely dma_map()ed at
> allocation time, split into two buffers, and individual buffer is
> sync_to_cpu()ed AND PASSED TO NETWORK STACK via skb_add_rx_frag() -
> while driver driver still uses other buffer. Later, when driver decides
> to no longer use this page, it will dma_unmap() it completely - which on
> archs with non-coherent caches means cache invalidation. This cache
> invalidation will include area that is already passed elsewhere.
This should happen only if the device wrote into that piece of the
memory which it absolutely should not.
When the dma sync occurs, no dirty data should be in the caches for
the portion of the page any more, and therefore nothing should be
written back unless the device illegally wrote to that part of the
page again.
If something is causing data to be written back even if the device
doesn't write into that area again, it's a bug.
And FWIW the swiommu code has this bug. It should never (re-)copy
back into the mapped area after a sync unless the device wrote into
that area in the time between the sync and the unmap.
^ permalink raw reply
* Re: [RFC v3 3/3] phy,leds: add support for led triggers on phy link state change
From: Florian Fainelli @ 2016-10-10 9:03 UTC (permalink / raw)
To: Zach Brown
Cc: mlindner, stephen, netdev, linux-kernel, devel,
florian.c.schilhabel, Larry.Finger, gregkh, rpurdie, j.anaszewski,
linux-leds, Andrew Lunn
In-Reply-To: <1475874897-29720-4-git-send-email-zach.brown@ni.com>
On 10/07/2016 02:14 PM, Zach Brown wrote:
> From: Josh Cartwright <josh.cartwright@ni.com>
>
> Create an option CONFIG_LED_TRIGGER_PHY (default n), which will
> create a set of led triggers for each instantiated PHY device. There is
> one LED trigger per link-speed, per-phy.
>
> This allows for a user to configure their system to allow a set of LEDs
> to represent link state changes on the phy.
Seems like we are past the RFC state now, so you might want to prefix
your patches with [PATCH ..] now. Also, the typical prefix used for
PHYLIB changes is net: phy: foo
Other than that:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Andrew, are you happy with this implementation?
[snip]
> +
> +#ifdef CONFIG_LED_TRIGGER_PHY
> +
> +#include <linux/leds.h>
> +#include <linux/phy.h>
> +
> +#define PHY_LINK_LED_MAX_TRIGGERS 5
> +#define PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE 7
> +#define PHY_MII_BUS_ID_SIZE (20 - 3)
This particular constant may be something worth moving to
include/linux/phy.h eventually.
--
Florian
^ permalink raw reply
* Re: [PATCH net] xen-netback: (re-)create a debugfs node for hash information
From: Wei Liu @ 2016-10-10 9:41 UTC (permalink / raw)
To: Paul Durrant; +Cc: netdev, Wei Liu, David S. Miller, xen-devel
In-Reply-To: <1476088253-10685-1-git-send-email-paul.durrant@citrix.com>
On Mon, Oct 10, 2016 at 09:30:53AM +0100, Paul Durrant wrote:
> From: Paul Durrant <Paul.Durrant@citrix.com>
>
> It is useful to be able to see the hash configuration when running tests.
> This patch adds a debugfs node for that purpose.
>
> The original version of this patch (commit c0c64c152389) was reverted due
> to build failures caused by a conflict with commit 0364a8824c02
> ("xen-netback: switch to threaded irq for control ring"). This new version
> of the patch is nearly identical to the original, the only difference
> being that creation of the debugfs node is predicated on 'ctrl_irq' being
> non-zero rather then the now non-existent 'ctrl_task'.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: David S. Miller <davem@davemloft.net>
Acked-by: Wei Liu <wei.liu2@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: igb driver can cause cache invalidation of non-owned memory?
From: Nikita Yushchenko @ 2016-10-10 9:51 UTC (permalink / raw)
To: David Miller
Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel, cphealy
In-Reply-To: <20161010.050125.1981283393312167625.davem@davemloft.net>
>> With this scheme, page used for Rx is completely dma_map()ed at
>> allocation time, split into two buffers, and individual buffer is
>> sync_to_cpu()ed AND PASSED TO NETWORK STACK via skb_add_rx_frag() -
>> while driver driver still uses other buffer. Later, when driver decides
>> to no longer use this page, it will dma_unmap() it completely - which on
>> archs with non-coherent caches means cache invalidation. This cache
>> invalidation will include area that is already passed elsewhere.
>
> This should happen only if the device wrote into that piece of the
> memory which it absolutely should not.
Hmm... I'm not about device writing to memory.
Sequence in igb driver is:
dma_map(full_page)
<device writes here>
sync_to_cpu(half_page);
skb_add_rx_frag(skb, half_page);
napi_gro_receive(skb);
...
dma_unmap(full_page)
What I'm concerned about is - same area is first passed up to network
stack, and _later_ dma_unmap()ed. Is this indeed safe?
Nikita
^ permalink raw reply
* [PATCH net 1/2] conntrack: remove obsolete sysctl (nf_conntrack_events_retry_timeout)
From: Nicolas Dichtel @ 2016-10-10 10:18 UTC (permalink / raw)
To: davem, pablo; +Cc: netdev, netfilter-devel, fw, Nicolas Dichtel
In-Reply-To: <1476094704-17452-1-git-send-email-nicolas.dichtel@6wind.com>
This entry has been removed in commit 9500507c6138.
Fixes: 9500507c6138 ("netfilter: conntrack: remove timer from ecache extension")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
Documentation/networking/nf_conntrack-sysctl.txt | 18 ------------------
1 file changed, 18 deletions(-)
diff --git a/Documentation/networking/nf_conntrack-sysctl.txt b/Documentation/networking/nf_conntrack-sysctl.txt
index 4fb51d32fccc..399e4e866a9c 100644
--- a/Documentation/networking/nf_conntrack-sysctl.txt
+++ b/Documentation/networking/nf_conntrack-sysctl.txt
@@ -33,24 +33,6 @@ nf_conntrack_events - BOOLEAN
If this option is enabled, the connection tracking code will
provide userspace with connection tracking events via ctnetlink.
-nf_conntrack_events_retry_timeout - INTEGER (seconds)
- default 15
-
- This option is only relevant when "reliable connection tracking
- events" are used. Normally, ctnetlink is "lossy", that is,
- events are normally dropped when userspace listeners can't keep up.
-
- Userspace can request "reliable event mode". When this mode is
- active, the conntrack will only be destroyed after the event was
- delivered. If event delivery fails, the kernel periodically
- re-tries to send the event to userspace.
-
- This is the maximum interval the kernel should use when re-trying
- to deliver the destroy event.
-
- A higher number means there will be fewer delivery retries and it
- will take longer for a backlog to be processed.
-
nf_conntrack_expect_max - INTEGER
Maximum size of expectation table. Default value is
nf_conntrack_buckets / 256. Minimum is 1.
--
2.8.1
^ permalink raw reply related
* [PATCH net 2/2] conntrack: enable to tune gc parameters
From: Nicolas Dichtel @ 2016-10-10 10:18 UTC (permalink / raw)
To: davem, pablo; +Cc: netdev, netfilter-devel, fw, Nicolas Dichtel
In-Reply-To: <1476094704-17452-1-git-send-email-nicolas.dichtel@6wind.com>
After commit b87a2f9199ea ("netfilter: conntrack: add gc worker to remove
timed-out entries"), netlink conntrack deletion events may be sent with a
huge delay. It could be interesting to let the user tweak gc parameters
depending on its use case.
CC: Florian Westphal <fw@strlen.de>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
Documentation/networking/nf_conntrack-sysctl.txt | 17 +++++++++++
include/net/netfilter/nf_conntrack_core.h | 5 ++++
net/netfilter/nf_conntrack_core.c | 17 +++++------
net/netfilter/nf_conntrack_standalone.c | 36 ++++++++++++++++++++++++
4 files changed, 67 insertions(+), 8 deletions(-)
diff --git a/Documentation/networking/nf_conntrack-sysctl.txt b/Documentation/networking/nf_conntrack-sysctl.txt
index 399e4e866a9c..5b6ace93521d 100644
--- a/Documentation/networking/nf_conntrack-sysctl.txt
+++ b/Documentation/networking/nf_conntrack-sysctl.txt
@@ -37,6 +37,23 @@ nf_conntrack_expect_max - INTEGER
Maximum size of expectation table. Default value is
nf_conntrack_buckets / 256. Minimum is 1.
+nf_conntrack_gc_interval - INTEGER
+ Maximum interval in second between two run of the conntrack gc. This
+ gc is in charge of removing stale entries. It also impacts the delay
+ before notifying the userland a conntrack deletion.
+ This sysctl is only writeable in the initial net namespace.
+
+nf_conntrack_gc_max_buckets - INTEGER
+nf_conntrack_gc_max_buckets_div - INTEGER
+ During a run, the conntrack gc processes at maximum
+ nf_conntrack_buckets/nf_conntrack_gc_max_buckets_div (and never more
+ than nf_conntrack_gc_max_buckets) entries.
+ These sysctl are only writeable in the initial net namespace.
+
+nf_conntrack_gc_max_evicts - INTEGER
+ The maximum number of entries to be evicted during a run of gc.
+ This sysctl is only writeable in the initial net namespace.
+
nf_conntrack_frag6_high_thresh - INTEGER
default 262144
diff --git a/include/net/netfilter/nf_conntrack_core.h b/include/net/netfilter/nf_conntrack_core.h
index 62e17d1319ff..2a5ed368fb71 100644
--- a/include/net/netfilter/nf_conntrack_core.h
+++ b/include/net/netfilter/nf_conntrack_core.h
@@ -86,4 +86,9 @@ void nf_conntrack_lock(spinlock_t *lock);
extern spinlock_t nf_conntrack_expect_lock;
+extern unsigned int nf_ct_gc_interval;
+extern unsigned int nf_ct_gc_max_buckets_div;
+extern unsigned int nf_ct_gc_max_buckets;
+extern unsigned int nf_ct_gc_max_evicts;
+
#endif /* _NF_CONNTRACK_CORE_H */
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index ba6a1d421222..435b431e3449 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -83,10 +83,10 @@ static __read_mostly spinlock_t nf_conntrack_locks_all_lock;
static __read_mostly DEFINE_SPINLOCK(nf_conntrack_locks_all_lock);
static __read_mostly bool nf_conntrack_locks_all;
-#define GC_MAX_BUCKETS_DIV 64u
-#define GC_MAX_BUCKETS 8192u
-#define GC_INTERVAL (5 * HZ)
-#define GC_MAX_EVICTS 256u
+unsigned int nf_ct_gc_interval = 5 * HZ;
+unsigned int nf_ct_gc_max_buckets = 8192;
+unsigned int nf_ct_gc_max_buckets_div = 64;
+unsigned int nf_ct_gc_max_evicts = 256;
static struct conntrack_gc_work conntrack_gc_work;
@@ -936,13 +936,14 @@ static noinline int early_drop(struct net *net, unsigned int _hash)
static void gc_worker(struct work_struct *work)
{
unsigned int i, goal, buckets = 0, expired_count = 0;
- unsigned long next_run = GC_INTERVAL;
+ unsigned long next_run = nf_ct_gc_interval;
unsigned int ratio, scanned = 0;
struct conntrack_gc_work *gc_work;
gc_work = container_of(work, struct conntrack_gc_work, dwork.work);
- goal = min(nf_conntrack_htable_size / GC_MAX_BUCKETS_DIV, GC_MAX_BUCKETS);
+ goal = min(nf_conntrack_htable_size / nf_ct_gc_max_buckets_div,
+ nf_ct_gc_max_buckets);
i = gc_work->last_bucket;
do {
@@ -977,7 +978,7 @@ static void gc_worker(struct work_struct *work)
rcu_read_unlock();
cond_resched_rcu_qs();
} while (++buckets < goal &&
- expired_count < GC_MAX_EVICTS);
+ expired_count < nf_ct_gc_max_evicts);
if (gc_work->exiting)
return;
@@ -1885,7 +1886,7 @@ int nf_conntrack_init_start(void)
nf_ct_untracked_status_or(IPS_CONFIRMED | IPS_UNTRACKED);
conntrack_gc_work_init(&conntrack_gc_work);
- schedule_delayed_work(&conntrack_gc_work.dwork, GC_INTERVAL);
+ schedule_delayed_work(&conntrack_gc_work.dwork, nf_ct_gc_interval);
return 0;
diff --git a/net/netfilter/nf_conntrack_standalone.c b/net/netfilter/nf_conntrack_standalone.c
index 5f446cd9f3fd..c5310fb35eca 100644
--- a/net/netfilter/nf_conntrack_standalone.c
+++ b/net/netfilter/nf_conntrack_standalone.c
@@ -445,6 +445,8 @@ static void nf_conntrack_standalone_fini_proc(struct net *net)
/* Sysctl support */
#ifdef CONFIG_SYSCTL
+static int one = 1;
+static int int_max = INT_MAX;
/* Log invalid packets of a given protocol */
static int log_invalid_proto_min __read_mostly;
static int log_invalid_proto_max __read_mostly = 255;
@@ -517,6 +519,40 @@ static struct ctl_table nf_ct_sysctl_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
+ {
+ .procname = "nf_conntrack_gc_interval",
+ .data = &nf_ct_gc_interval,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_jiffies,
+ },
+ {
+ .procname = "nf_conntrack_gc_max_buckets",
+ .data = &nf_ct_gc_max_buckets,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &one,
+ .extra2 = &int_max,
+ },
+ {
+ .procname = "nf_conntrack_gc_max_buckets_div",
+ .data = &nf_ct_gc_max_buckets_div,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &one,
+ .extra2 = &int_max,
+ },
+ {
+ .procname = "nf_conntrack_gc_max_evicts",
+ .data = &nf_ct_gc_max_evicts,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &one,
+ .extra2 = &int_max,
+ },
{ }
};
--
2.8.1
^ permalink raw reply related
* [PATCH net 0/2] conntrack update
From: Nicolas Dichtel @ 2016-10-10 10:18 UTC (permalink / raw)
To: davem, pablo; +Cc: netdev, netfilter-devel, fw
The first patch is a small documentation fix.
The second patch adds more flexibility to configure the conntrack gc. I target
it specifically to net and not net-next because the removal of the conntrack
timer has just land into net.
Documentation/networking/nf_conntrack-sysctl.txt | 35 +++++++++++------------
include/net/netfilter/nf_conntrack_core.h | 5 ++++
net/netfilter/nf_conntrack_core.c | 17 +++++------
net/netfilter/nf_conntrack_standalone.c | 36 ++++++++++++++++++++++++
4 files changed, 67 insertions(+), 26 deletions(-)
Comments are welcomed,
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH v5 3/4] cfg80211: configure multicast to unicast for AP interfaces
From: Johannes Berg @ 2016-10-10 10:28 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan, netdev
In-Reply-To: <1475865574-5384-3-git-send-email-michael-dev@fami-braun.de>
> *
> + * @NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED: Multicast packets
> should be
> + * send out as unicast to all stations.
You should document what type of attribute is expected. You probably
wanted a flag attribute, but ...
> + [NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type =
> NLA_U8, },
have u8 in the policy, yet
> + enabled = nla_get_flag(nla);
actually use as a flag :)
In addition to that, I think you should clarify the "per-BSS" comment
in nl80211, and also clarify (at the same place) what kind of
functionality is expected from this.
johannes
^ permalink raw reply
* [PATCH] doc: fix wrongly referencing dev->skb_mark
From: Ryota Ozaki @ 2016-10-10 11:15 UTC (permalink / raw)
To: netdev
Section "Flooding L2 domain" says, to avoid duplicated flooding, if
skb->offload_fwd_mark is matched with dev->skb_mark, the kernel will
drop the packet. However, the relevant code in __dev_queue_xmit
compares skb->offload_fwd_mark with dev->offload_fwd_mark, not
dev->skb_mark. I guess the text is wrong.
Signed-off-by: Ryota Ozaki <ozaki.ryota@gmail.com>
---
Documentation/networking/switchdev.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
index 31c3911..d4124a0 100644
--- a/Documentation/networking/switchdev.txt
+++ b/Documentation/networking/switchdev.txt
@@ -286,8 +286,8 @@ otherwise there will be duplicate packets on the wire.
To avoid duplicate packets, the device/driver should mark a packet as already
forwarded using skb->offload_fwd_mark. The same mark is set on the device
ports in the domain using dev->offload_fwd_mark. If the skb->offload_fwd_mark
-is non-zero and matches the forwarding egress port's dev->skb_mark, the kernel
-will drop the skb right before transmit on the egress port, with the
+is non-zero and matches the forwarding egress port's dev->offload_fwd_mark,
+the kernel will drop the skb right before transmit on the egress port, with the
understanding that the device already forwarded the packet on same egress port.
The driver can use switchdev_port_fwd_mark_set() to set a globally unique mark
for port's dev->offload_fwd_mark, based on the port's parent ID (switch ID) and
--
2.7.4
^ permalink raw reply related
* Re: tg3 BUG: spinlock lockup suspected
From: Siva Reddy Kallam @ 2016-10-10 11:51 UTC (permalink / raw)
To: Meelis Roos; +Cc: Linux Netdev List, sparclinux, Linux Kernel list
On Sun, Oct 9, 2016 at 12:35 AM, Meelis Roos <mroos@linux.ee> wrote:
>> > That did not go well - bisect found the following commit but that does
>> > not seem to be related at all. So probably the reproducibility is not
>> > 100% but more random.
>>
>> Now I reproduced the bug even with 4.7-rc1 so it is older than 4.7. Will
>> test further.
>
> It gets stranger and stranger - my old 4.7 image worked fine, freshly
> compiled 4.7 exhibits the same problem.
>
> Toolchain has not changed, that I know for sure.
>
> What may have changed is kernel .config. My old conf was with whatever I
> had during 4.7. Then I upgraded to 4.8-rc3 and then 4.8 and selected
> values for "make oldconfig" new entries. Then went back to 4.7-rc1 and
> then to 4.7 with this config, answering quiestion about new options when
> any appeared. Diff is not available since I do not have the old configs
> archived.
>
> Any ideas where to continue from here?
Probably, You can do fresh system installation if possible.
Any way, I will try to reproduce with 4.7 and 4.8 kernel versions.
Will let you know my response in 1-2 days.
>
>>
>> >
>> >
>> > 4c5773f9f5462dcb372857813918bbfe8c0cdcdd is the first bad commit
>> > commit 4c5773f9f5462dcb372857813918bbfe8c0cdcdd
>> > Author: Krzysztof Kozlowski <krzk@kernel.org>
>> > Date: Sat May 28 11:54:12 2016 +0200
>> >
>> > dt-bindings: clock: Add license and reformat Exynos5410 clock IDs
>> >
>> > Add license and copyrights (file introduced in 2014) to header with
>> > Exynos5410 clock IDs. Additionally reformat it to improve readability.
>> >
>> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>> > Acked-by: Stephen Boyd <sboyd@codeaurora.org>
>> > Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> > Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> >
>> > :040000 040000 acbd432e11366a8eb8775942bc7b8caa476226e2 08e3a3f98c3d4fa2a93123c3f21b2847c06b4665 M include
>> >
>> >
>> > The whiole bisect log seems to dig around in unrelated places so at best
>> > it just narrows the window by adding some known-bad data points.
>> >
>> > git bisect start
>> > # good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
>> > git bisect good 523d939ef98fd712632d93a5a2b588e477a7565e
>> > # bad: [ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea] Merge tag 'arc-4.8-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
>> > git bisect bad ef0e1ea8856bed6ff8394d3dfe77f2cab487ecea
>> > # good: [e0b3f595d13b3e9ce9cdf53935e7f304c04b5b2b] affs ->d_compare(): don't bother with ->d_inode
>> > git bisect good e0b3f595d13b3e9ce9cdf53935e7f304c04b5b2b
>> > # bad: [77a87824ed676ca8ff8482e4157d3adb284fd381] clocksource/drivers/clps_711x: fixup for "ARM: clps711x:
>> > git bisect bad 77a87824ed676ca8ff8482e4157d3adb284fd381
>> > # bad: [27acbec338113a75b9d72aeb53149a3538031dda] Merge git://www.linux-watchdog.org/linux-watchdog
>> > git bisect bad 27acbec338113a75b9d72aeb53149a3538031dda
>> > # bad: [7f155c702677d057d03b192ce652311de5434697] Merge tag 'nfs-for-4.8-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
>> > git bisect bad 7f155c702677d057d03b192ce652311de5434697
>> > # good: [797cee982eef9195736afc5e7f3b8f613c41d19a] Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit
>> > git bisect good 797cee982eef9195736afc5e7f3b8f613c41d19a
>> > # bad: [1056c9bd2702ea1bb79abf9bd1e78c578589d247] Merge tag 'clk-for-linus-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
>> > git bisect bad 1056c9bd2702ea1bb79abf9bd1e78c578589d247
>> > # bad: [1ff435d3571199a799ba6ccfe05544dcd21b9fb3] Merge branch 'clk-st-critical' into clk-next
>> > git bisect bad 1ff435d3571199a799ba6ccfe05544dcd21b9fb3
>> > # bad: [0e4504470667d355b53ca3c9802fdd2120c9f946] clk: samsung: exynos5433: Add CLK_IGNORE_UNUSED flag to PCIE device
>> > git bisect bad 0e4504470667d355b53ca3c9802fdd2120c9f946
>> > # bad: [880c81b3b6604a004d56b5975c8bed47276e8bf6] clk: samsung: exynos5440: Constify all clock initializers
>> > git bisect bad 880c81b3b6604a004d56b5975c8bed47276e8bf6
>> > # bad: [b3a96eed8e84780d300b79b58047ea277ba358b7] clk: samsung: exynos3250: Move platform driver and of_device_id to init section
>> > git bisect bad b3a96eed8e84780d300b79b58047ea277ba358b7
>> > # bad: [4528dd8ed477bf202bd33ee48d38d656672d37f8] dt-bindings: clock: Add watchdog and SSS clock IDs to Exynos5410
>> > git bisect bad 4528dd8ed477bf202bd33ee48d38d656672d37f8
>> > # bad: [5cd3535a27a7cf8fc4070b499d66e419e7e72b61] dt-bindings: clock: Add PWM and USB clock IDs to Exynos5410
>> > git bisect bad 5cd3535a27a7cf8fc4070b499d66e419e7e72b61
>> > # bad: [4c5773f9f5462dcb372857813918bbfe8c0cdcdd] dt-bindings: clock: Add license and reformat Exynos5410 clock IDs
>> > git bisect bad 4c5773f9f5462dcb372857813918bbfe8c0cdcdd
>> > # first bad commit: [4c5773f9f5462dcb372857813918bbfe8c0cdcdd] dt-bindings: clock: Add license and reformat Exynos5410 clock IDs
>> >
>> >
>> > >
>> > > [ 74.123859] tg3.c:v3.137 (May 11, 2014)
>> > > [ 74.123880] PCI: Enabling device: (0000:00:02.0), cmd 2
>> > > [ 74.315794] tg3 0000:00:02.0 (unnamed net_device) (uninitialized): Cannot get nvram lock, tg3_nvram_init failed
>> > > [ 74.656152] tg3 0000:00:02.0 eth0: Tigon3 [partno(none) rev 2003] (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:85
>> > > [ 74.656160] tg3 0000:00:02.0 eth0: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
>> > > [ 74.656167] tg3 0000:00:02.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
>> > > [ 74.656172] tg3 0000:00:02.0 eth0: dma_rwctrl[763f0000] dma_mask[32-bit]
>> > > [ 74.656322] PCI: Enabling device: (0000:00:02.1), cmd 2
>> > > [ 74.845325] tg3 0000:00:02.1 (unnamed net_device) (uninitialized): Cannot get nvram lock, tg3_nvram_init failed
>> > > [ 75.184539] tg3 0000:00:02.1 eth1: Tigon3 [partno(none) rev 2003] (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:86
>> > > [ 75.184546] tg3 0000:00:02.1 eth1: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
>> > > [ 75.184551] tg3 0000:00:02.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
>> > > [ 75.184557] tg3 0000:00:02.1 eth1: dma_rwctrl[763f0000] dma_mask[32-bit]
>> > > [ 75.184708] PCI: Enabling device: (0003:00:02.0), cmd 2
>> > > [ 75.375322] tg3 0003:00:02.0 (unnamed net_device) (uninitialized): Cannot get nvram lock, tg3_nvram_init failed
>> > > [ 75.714681] tg3 0003:00:02.0 eth2: Tigon3 [partno(none) rev 2003] (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:87
>> > > [ 75.714688] tg3 0003:00:02.0 eth2: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
>> > > [ 75.714694] tg3 0003:00:02.0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
>> > > [ 75.714699] tg3 0003:00:02.0 eth2: dma_rwctrl[763f0000] dma_mask[32-bit]
>> > > [ 75.714819] PCI: Enabling device: (0003:00:02.1), cmd 2
>> > > [ 75.905278] tg3 0003:00:02.1 (unnamed net_device) (uninitialized): Cannot get nvram lock, tg3_nvram_init failed
>> > > [ 76.244470] tg3 0003:00:02.1 eth3: Tigon3 [partno(none) rev 2003] (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:88
>> > > [ 76.244477] tg3 0003:00:02.1 eth3: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
>> > > [ 76.244482] tg3 0003:00:02.1 eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
>> > > [ 76.244488] tg3 0003:00:02.1 eth3: dma_rwctrl[763f0000] dma_mask[32-bit]
>> > > [ 83.643317] tg3 0000:00:02.0 eth0: No firmware running
>> > > [...]
>> > > [ 83.716570] BUG: spinlock lockup suspected on CPU#0, dhclient/1014
>> > > [ 83.797819] lock: 0xfff000123c8e4a08, .magic: dead4ead, .owner: ip/1001, .owner_cpu: 1
>> > > [ 83.903130] CPU: 0 PID: 1014 Comm: dhclient Not tainted 4.8.0 #4
>> > > [ 83.982129] Call Trace:
>> > > [ 84.014160] [00000000004b7220] spin_dump+0x60/0xa0
>> > > [ 84.078203] [00000000004b73a0] do_raw_spin_lock+0xa0/0x120
>> > > [ 84.106344] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> > > [ 84.107193] ip (1001) used greatest stack depth: 2168 bytes left
>> > > [ 84.306955] [000000000092c0d0] _raw_spin_lock_bh+0x30/0x40
>> > > [ 84.380188] [00000000100822cc] tg3_get_stats64+0xc/0x80 [tg3]
>> > > [ 84.456885] [00000000007fac8c] dev_get_stats+0x2c/0xc0
>> > > [ 84.525506] [000000000081a4e8] dev_seq_printf_stats+0x8/0xe0
>> > > [ 84.600986] [000000000081a5e4] dev_seq_show+0x24/0x40
>> > > [ 84.668467] [00000000005cb6c4] seq_read+0x2c4/0x440
>> > > [ 84.733656] [000000000060b97c] proc_reg_read+0x3c/0x80
>> > > [ 84.802282] [00000000005a219c] __vfs_read+0x1c/0x140
>> > > [ 84.868613] [00000000005a2310] vfs_read+0x50/0x100
>> > > [ 84.932662] [00000000005a265c] SyS_read+0x3c/0xa0
>> > > [ 84.995573] [00000000004061d4] linux_sparc_syscall32+0x34/0x60
>> > > [ 85.073748] * CPU[ 0]: TSTATE[00000044f0001a22] TPC[00000000f79a16b0] TNPC[00000000f79a16b4] TASK[dhclient:1014]
>> > > [ 85.208732] TPC[f79a16b0] O7[f79405c8] I7[0] RPC[0]
>> > > [ 85.287633] CPU[ 1]: TSTATE[0000004480001605] TPC[00000000004b26f0] TNPC[00000000004d0b0c] TASK[swapper/1:0]
>> > > [ 85.420338] TPC[trace_hardirqs_off+0x10/0x20] O7[rcu_idle_enter+0x64/0xa0] I7[cpu_startup_entry+0x1b0/0x240] RPC[rest_init+0x178/0x1a0]
>> > > [ 85.664600] tg3 0000:00:02.0 eth0: Link is up at 100 Mbps, full duplex
>> > > [ 85.750515] tg3 0000:00:02.0 eth0: Flow control is off for TX and off for RX
>> > > [ 85.843994] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>> > >
>> > >
>> >
>> >
>>
>>
>
> --
> Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: igb driver can cause cache invalidation of non-owned memory?
From: David Miller @ 2016-10-10 11:57 UTC (permalink / raw)
To: nikita.yoush
Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel, cphealy
In-Reply-To: <10474d19-df1a-3b09-917e-70659be3a56c@cogentembedded.com>
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Date: Mon, 10 Oct 2016 12:51:28 +0300
> Hmm... I'm not about device writing to memory.
This absolutely is about whether the device wrote into the
area or not.
> Sequence in igb driver is:
>
> dma_map(full_page)
> <device writes here>
> sync_to_cpu(half_page);
> skb_add_rx_frag(skb, half_page);
> napi_gro_receive(skb);
> ...
> dma_unmap(full_page)
>
> What I'm concerned about is - same area is first passed up to network
> stack, and _later_ dma_unmap()ed. Is this indeed safe?
dma_unmap() should never write anything unless the device has
meanwhile written to that chunk of memory.
If the device made no intervening writes into the area, dma_unmap()
should not cause any data to be written to that area, period.
In your example above, consider the case where the device never
writes into the memory area after sync_to_cpu(). In that case
there is nothing that dma_unmap() can possibly write. All the
data has been synced, and no device writes into the memory are
have occurred.
^ permalink raw reply
* [PATCH] qed: fix old-style function definition
From: Arnd Bergmann @ 2016-10-10 11:59 UTC (permalink / raw)
To: Yuval Mintz, Ariel Elior, everest-linux-l2
Cc: Arnd Bergmann, Ram Amrani, David S. Miller, netdev, linux-kernel
The definition of qed_get_rdma_ops() is not a prototype unless
we add 'void' here, as indicated by this W=1 warning:
drivers/net/ethernet/qlogic/qed/qed_roce.c: In function ‘qed_get_rdma_ops’:
drivers/net/ethernet/qlogic/qed/qed_roce.c:2950:28: error: old-style function definition [-Werror=old-style-definition]
Fixes: abd49676c707 ("qed: Add RoCE ll2 & GSI support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/qlogic/qed/qed_roce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_roce.c b/drivers/net/ethernet/qlogic/qed/qed_roce.c
index 23430059471c..76831a398bed 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_roce.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_roce.c
@@ -2947,7 +2947,7 @@ static const struct qed_rdma_ops qed_rdma_ops_pass = {
.roce_ll2_stats = &qed_roce_ll2_stats,
};
-const struct qed_rdma_ops *qed_get_rdma_ops()
+const struct qed_rdma_ops *qed_get_rdma_ops(void)
{
return &qed_rdma_ops_pass;
}
--
2.9.0
^ permalink raw reply related
* Re: kernel v4.8: iptables logs are truncated with the 4.8 kernel?
From: Liping Zhang @ 2016-10-10 12:21 UTC (permalink / raw)
To: Chris Caputo
Cc: Vishwanath Pai, Pablo Neira Ayuso, Justin Piszcz, linux-kernel,
Linux Kernel Network Developers
In-Reply-To: <Pine.LNX.4.64.1610100627230.28174@nacho.alt.net>
Hi Chris,
2016-10-10 15:02 GMT+08:00 Chris Caputo <ccaputo@alt.net>:
> On Tue, 4 Oct 2016, Justin Piszcz wrote:
>> kernel 4.8 with ulogd-2.0.5- IPs are no longer logged:
>>
>> Oct 4 17:51:30 atom INPUT_BLOCK IN=eth1 OUT=
>> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
>> TTL=0 ID=0 PROTO=0 MARK=0
>> Oct 4 17:51:31 atom INPUT_BLOCK IN=eth1 OUT=
>> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
>> TTL=0 ID=0 PROTO=0 MARK=0
>> Oct 4 17:51:32 atom INPUT_BLOCK IN=eth1 OUT=
>> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
>> TTL=0 ID=0 PROTO=0 MARK=0
>>
>> (reboot back to kernel 4.7, works fine)
>>
>> kernel 4.7 with ulogd-2.0.5:
>> Oct 4 17:56:44 atom INPUT_BLOCK IN=eth1 OUT=
>> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 SRC=74.125.22.125
>> DST=1.2.3.4 LEN=397 TOS=00 PREC=0x00 TTL=48 ID=58093 PROTO=TCP
>> SPT=5222 DPT=19804 SEQ=2032644254 ACK=2273184383 WINDOW=55272 ACK PSH
>> URGP=0 MARK=0
>> Oct 4 17:56:45 atom INPUT_BLOCK IN=eth1 OUT=
>> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 SRC=74.125.22.125
>> DST=1.2.3.4 LEN=397 TOS=00 PREC=0x00 TTL=48 ID=58725 PROTO=TCP
>> SPT=5222 DPT=19804 SEQ=2032644254 ACK=2273184383 WINDOW=55272 ACK PSH
>> URGP=0 MARK=0
>>
>> Looks like there were some changes in the 4.8 kernel regarding ulogd,
>> has anyone else run into this problem?
>
> For me, kernel 4.8.1 results in segfaults in ulogd-2.0.5 at:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff65fd18a in _interp_iphdr (pi=0x617f50, len=0) at ulogd_raw2packet_BASE.c:720
>
> 715 static int _interp_iphdr(struct ulogd_pluginstance *pi, uint32_t len)
> 716 {
> 717 struct ulogd_key *ret = pi->output.keys;
> 718 struct iphdr *iph =
> 719 ikey_get_ptr(&pi->input.keys[INKEY_RAW_PCKT]);
> 720 void *nexthdr = (uint32_t *)iph + iph->ihl;
>
> I believe 7643507fe8b5bd8ab7522f6a81058cc1209d2585 changed previous
> behavior by not always copying IP header data to user space.
>
> On my machine IPv4 log packets result in a ulogd segfault while IPv6
> packets do not. I'm not sure of the cause of the difference.
>
> The corresponding userspace commit for the 209d2585 kernel change is:
>
> https://git.netfilter.org/iptables/commit/?id=7070b1f3c88a0c3d4e315c00cca61f05b0fbc882
>
> This adds --nflog-size to iptables. When --nflog-size is used with my
> iptables NFLOG lines, the ulogd-2.0.5 segfaults cease.
What numbers did you specify after --nflog-size option?
--nflog-size 0 or ...? If you want log the whole packet to
the ulogd, please do not specify this nflog-size option.
>
> I'm surprised to see a kernel change cause unexpected userspace segfaults,
> so further investigation into a kernel fix would seem a good idea.
According to the original user's manual, nflog-range option was
designed to be the number of bytes copied to userspace, but
unfortunately there's a bug from the beginning and it never works,
i.e. in kernel, it just ignored this option.
Try to change the current nflog-range option's semantics may
cause unexpected results(maybe like this ulogd crash) ...
In order to keep compatibility, Vishwanath introduce a new
nflog-size option and keep nflog-range unchanged. If you just
upgrade the kernel, and do not change iptables rules, this
problem will not happen.
So I think this is ulogd's bug, in _interp_iphdr, it try to
dereference the iphdr pointer before validation check, meanwhile
this problem does not exist in ipv6 path. Can you try this patch:
diff --git a/filter/raw2packet/ulogd_raw2packet_BASE.c
b/filter/raw2packet/ulogd_raw2packet_BASE.c
index 8a6180c..fd2665a 100644
--- a/filter/raw2packet/ulogd_raw2packet_BASE.c
+++ b/filter/raw2packet/ulogd_raw2packet_BASE.c
@@ -717,7 +717,7 @@ static int _interp_iphdr(struct ulogd_pluginstance
*pi, uint32_t len)
struct ulogd_key *ret = pi->output.keys;
struct iphdr *iph =
ikey_get_ptr(&pi->input.keys[INKEY_RAW_PCKT]);
- void *nexthdr = (uint32_t *)iph + iph->ihl;
+ void *nexthdr;
if (len < sizeof(struct iphdr) || len <= (uint32_t)(iph->ihl * 4))
return ULOGD_IRET_OK;
@@ -734,6 +734,7 @@ static int _interp_iphdr(struct ulogd_pluginstance
*pi, uint32_t len)
okey_set_u16(&ret[KEY_IP_ID], ntohs(iph->id));
okey_set_u16(&ret[KEY_IP_FRAGOFF], ntohs(iph->frag_off));
+ nexthdr = (uint32_t *)iph + iph->ihl;
switch (iph->protocol) {
case IPPROTO_TCP:
_interp_tcp(pi, nexthdr, len);
Thanks
> Having to add the likes of "--nflog-size 200" (200 simply being what I am
> using) to every NFLOG line in firewall configs is a significant burden for
> many.
>
> Putting out a new release of iptables may help ease this transition if the
> kernel is not patched to fix this. I had to use the git code since 1.6.0
> doesn't have it.
>
> Chris
^ permalink raw reply related
* Re: igb driver can cause cache invalidation of non-owned memory?
From: Nikita Yushchenko @ 2016-10-10 12:27 UTC (permalink / raw)
To: David Miller
Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel, cphealy
In-Reply-To: <20161010.075731.2449861168238706.davem@davemloft.net>
>> Hmm... I'm not about device writing to memory.
>
> This absolutely is about whether the device wrote into the
> area or not.
Not only.
>> Sequence in igb driver is:
>>
>> dma_map(full_page)
>> <device writes here>
>> sync_to_cpu(half_page);
>> skb_add_rx_frag(skb, half_page);
>> napi_gro_receive(skb);
>> ...
>> dma_unmap(full_page)
>>
>> What I'm concerned about is - same area is first passed up to network
>> stack, and _later_ dma_unmap()ed. Is this indeed safe?
>
> dma_unmap() should never write anything unless the device has
> meanwhile written to that chunk of memory.
dma_unmap() for DMA_FROM_DEVICE never writes whatever to memory,
regardless of what device did.
dma_unmap() for DMA_FROM_DEVICE ensures that data written to memory
by device (if any) is visible to CPU. Cache may contain stale data
for that memory region. To drop that from cache, dma_unmap() for
DMA_FROM_DEVICE does cache invalidation.
static void arm_dma_unmap_page(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir, unsigned long attrs)
{
if ((attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_page_dev_to_cpu(pfn_to_page(dma_to_pfn(dev, handle)),
handle & ~PAGE_MASK, size, dir);
}
static void __dma_page_dev_to_cpu(struct page *page, unsigned long off,
size_t size, enum dma_data_direction dir)
{
...
if (dir != DMA_TO_DEVICE) {
outer_inv_range(paddr, paddr + size);
dma_cache_maint_page(page, off, size, dir, dmac_unmap_area);
}
...
}
> If the device made no intervening writes into the area, dma_unmap()
> should not cause any data to be written to that area, period.
I'm not about writing.
I'm about just the opposite - dropping not-written data from cache.
- napi_gro_receive(skb) passes area to upper layers of the network stack,
- something in those layers - perhaps packet mangling or such - writes
to the area,
- this write enters cache but does not end into memory immediately,
- at this moment, igb does dma_unmap(),
- write that was in cache but not yet in memory gets lost.
> In your example above, consider the case where the device never
> writes into the memory area after sync_to_cpu(). In that case
> there is nothing that dma_unmap() can possibly write.
> All the data has been synced
Non-synced data is write done by CPU executing upper layers of network stack,
Nikita
^ permalink raw reply
* Re: [PATCH v4 03/10] ARM: sun8i: dt: Add DT bindings documentation for Allwinner sun8i-emac
From: Maxime Ripard @ 2016-10-10 12:30 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, andrew, f.fainelli, devicetree, netdev, linux,
linux-kernel, wens, robh+dt, davem, linux-arm-kernel
In-Reply-To: <1475828757-926-4-git-send-email-clabbe.montjoie@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3375 bytes --]
On Fri, Oct 07, 2016 at 10:25:50AM +0200, Corentin Labbe wrote:
> This patch adds documentation for Device-Tree bindings for the
> Allwinner sun8i-emac driver.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> .../bindings/net/allwinner,sun8i-emac.txt | 70 ++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
>
> diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
> new file mode 100644
> index 0000000..92e4ef3b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
> @@ -0,0 +1,70 @@
> +* Allwinner sun8i EMAC ethernet controller
> +
> +Required properties:
> +- compatible: should be one of the following string:
> + "allwinner,sun8i-a83t-emac"
> + "allwinner,sun8i-h3-emac"
> + "allwinner,sun50i-a64-emac"
> +- reg: address and length of the register for the device.
> +- syscon: A phandle to the syscon of the SoC
> +- interrupts: interrupt for the device
> +- clocks: A phandle to the reference clock for this device
> +- clock-names: should be "ahb"
> +- resets: A phandle to the reset control for this device
> +- reset-names: should be "ahb"
> +- phy-mode: See ethernet.txt
> +- phy-handle: See ethernet.txt
> +- #address-cells: shall be 1
> +- #size-cells: shall be 0
> +
> +Optional properties:
> +- allwinner,tx-delay: TX clock delay chain value. Range value is 0-0x07. Default is 0)
> +- allwinner,rx-delay: RX clock delay chain value. Range value is 0-0x1F. Default is 0)
> +Both delay properties does not have units, there are arbitrary value.
> +The TX/RX clock delay chain settings are board specific and could be found
> +in vendor FEX files.
> +
> +Optional properties for "allwinner,sun8i-h3-emac":
> +- allwinner,leds-active-low: EPHY LEDs are active low
> +
> +Required child node of emac:
> +- mdio bus node: should be named mdio
> +
> +Required properties of the mdio node:
> +- #address-cells: shall be 1
> +- #size-cells: shall be 0
> +
> +The device node referenced by "phy" or "phy-handle" should be a child node
> +of the mdio node. See phy.txt for the generic PHY bindings.
> +
> +Required properties of the phy node with "allwinner,sun8i-h3-emac":
> +- clocks: an extra phandle to the reference clock for the EPHY
> +- resets: an extra phandle to the reset control for the EPHY
> +
> +Example:
> +
> +emac: ethernet@01c0b000 {
> + compatible = "allwinner,sun8i-h3-emac";
> + syscon = <&syscon>;
> + reg = <0x01c0b000 0x104>;
> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
> + resets = <&ccu RST_BUS_EMAC>;
> + reset-names = "ahb";
> + clocks = <&ccu CLK_BUS_EMAC>;
> + clock-names = "ahb";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy = <&int_mii_phy>;
> + phy-mode = "mii";
> + allwinner,leds-active-low;
> + mdio: mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + int_mii_phy: ethernet-phy@1 {
> + reg = <1>;
> + clocks = <&ccu CLK_BUS_EPHY>;
> + resets = <&ccu RST_BUS_EPHY>;
That works for me, let's see how the DT maintainers feel about it.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 10/10] ARM: sunxi: Enable sun8i-emac driver on multi_v7_defconfig
From: Maxime Ripard @ 2016-10-10 12:30 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, andrew, f.fainelli, devicetree, netdev, linux,
linux-kernel, wens, robh+dt, davem, linux-arm-kernel
In-Reply-To: <1475828757-926-11-git-send-email-clabbe.montjoie@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 807 bytes --]
On Fri, Oct 07, 2016 at 10:25:57AM +0200, Corentin Labbe wrote:
> Enable the sun8i-emac driver in the multi_v7 default configuration
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> arch/arm/configs/multi_v7_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 5845910..f44d633 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -229,6 +229,7 @@ CONFIG_NETDEVICES=y
> CONFIG_VIRTIO_NET=y
> CONFIG_HIX5HD2_GMAC=y
> CONFIG_SUN4I_EMAC=y
> +CONFIG_SUN8I_EMAC=y
Any reason to build it statically?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: igb driver can cause cache invalidation of non-owned memory?
From: Nikita Yushchenko @ 2016-10-10 12:31 UTC (permalink / raw)
To: David Miller
Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel, cphealy
In-Reply-To: <f75cf1e1-d7e8-e044-188a-987f05f321a5@cogentembedded.com>
>> All the data has been synced
>
> Non-synced data is write done by CPU executing upper layers of network stack,
Upper layers shall never get area that is still dma_map()ed and will be
dma_unmap()ed in future. But with igb, this is exactly what happens.
^ permalink raw reply
* Re: [PATCH v4 04/10] ARM: dts: sun8i-h3: Add dt node for the syscon control module
From: Maxime Ripard @ 2016-10-10 12:31 UTC (permalink / raw)
To: Corentin Labbe
Cc: robh+dt, mark.rutland, wens, linux, davem, f.fainelli, andrew,
netdev, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1475828757-926-5-git-send-email-clabbe.montjoie@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]
Hi,
On Fri, Oct 07, 2016 at 10:25:51AM +0200, Corentin Labbe wrote:
> This patch add the dt node for the syscon register present on the
> Allwinner H3.
>
> Only two register are present in this syscon and the only one useful is
> the one dedicated to EMAC clock.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 8a95e36..1101d2f 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -140,6 +140,11 @@
> #size-cells = <1>;
> ranges;
>
> + syscon: syscon@01c00000 {
> + compatible = "syscon";
It would be great to have a more specific compatible here in addition
to the syscon, like "allwinner,sun8i-h3-system-controller".
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4 10/10] ARM: sunxi: Enable sun8i-emac driver on multi_v7_defconfig
From: LABBE Corentin @ 2016-10-10 12:35 UTC (permalink / raw)
To: Maxime Ripard
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
andrew-g2DYL2Zd6BY, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161010123046.GH3462@lukather>
On Mon, Oct 10, 2016 at 02:30:46PM +0200, Maxime Ripard wrote:
> On Fri, Oct 07, 2016 at 10:25:57AM +0200, Corentin Labbe wrote:
> > Enable the sun8i-emac driver in the multi_v7 default configuration
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > arch/arm/configs/multi_v7_defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> > index 5845910..f44d633 100644
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
> > @@ -229,6 +229,7 @@ CONFIG_NETDEVICES=y
> > CONFIG_VIRTIO_NET=y
> > CONFIG_HIX5HD2_GMAC=y
> > CONFIG_SUN4I_EMAC=y
> > +CONFIG_SUN8I_EMAC=y
>
> Any reason to build it statically?
>
No, just copied the same than CONFIG_SUN4I_EMAC that probably do not need it also.
Regards
Corentin Labbe
--
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] tlan: avoid unused label with PCI=n
From: Arnd Bergmann @ 2016-10-10 12:41 UTC (permalink / raw)
To: Samuel Chessman
Cc: Arnd Bergmann, David S. Miller, Mugunthan V N, Ivan Vecera,
Antonio Quartulli, Florian Westphal, netdev, linux-kernel
While build testing with randconfig on x86, I ran into this warning
that appears to have been around forever
drivers/net/ethernet/ti/tlan.c: In function ‘tlan_probe1’:
drivers/net/ethernet/ti/tlan.c:614:1: error: label ‘err_out’ defined but not used [-Werror=unused-label]
This can be trivially avoided by just moving the label into the
existing #ifdef.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/ti/tlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index ece0ea0f6b38..6c7ec1ddd475 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -610,8 +610,8 @@ static int tlan_probe1(struct pci_dev *pdev, long ioaddr, int irq, int rev,
#ifdef CONFIG_PCI
if (pdev)
pci_release_regions(pdev);
-#endif
err_out:
+#endif
if (pdev)
pci_disable_device(pdev);
return rc;
--
2.9.0
^ permalink raw reply related
* Re: [PATCH net-next v3 0/6] openvswitch: make vlan handling consistent
From: Jiri Benc @ 2016-10-10 12:46 UTC (permalink / raw)
To: Pravin Shelar; +Cc: Linux Kernel Network Developers, Eric Garver
In-Reply-To: <CAOrHB_BTJecjrUsJVzhO4W-edX1V8U7_sn3AHa_Mo+v50n4ycQ@mail.gmail.com>
On Fri, 7 Oct 2016 12:59:08 -0700, Pravin Shelar wrote:
> On Fri, Oct 7, 2016 at 9:07 AM, Jiri Benc <jbenc@redhat.com> wrote:
> > Always keep the first vlan tag "accelerated", i.e. in skb->vlan_tci.
> >
> > Unfortunately, with all the changes since v2, this patchset no longer has
> > the nice deletions > insertions diffstat. I still think it's worth it, as it
> > makes things more consistent overall.
> >
> After looking at the changes, I am not sure about the value. These
> patches are making code bit complicated by processing vlan header
> twice rather than once in current code.
Yes, this is a trade-off. A bit more complexity on packet ingress, less
complexity on packet processing.
My main motivation was L3 packets where the code in packet_length
became more complicated than I'd like to to cover all possible cases.
Normalizing the vlan tags looked as a pretty obvious improvement. But
I'm not that thrilled with what it evolved into. I think it's slightly
better than what we have now but I can understand how you may think
opposite.
I'll rip the fixes (patches 3 and 6) off this patchset and send them
separately.
> As far as patch 6 is concerned I think we could do MTU checks similar
> to the rest of networking stack (for example is_skb_forwardable()).
> That would simplify things here.
Fixing the current code is not that hard. The real problem is the added
complexity with L3 packets. I'll look more into the possible solutions
for the L3 patchset.
Jiri
^ 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