* Re: [PATCH] can: pcan_usb: fix wrong memcpy() bytes length
From: David Miller @ 2013-08-12 4:52 UTC (permalink / raw)
To: mkl; +Cc: netdev, kernel, linux-can, s.grosjean, stable
In-Reply-To: <1376041446-24058-2-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 9 Aug 2013 11:44:06 +0200
> From: Stephane Grosjean <s.grosjean@peak-system.com>
>
> Fix possibly wrong memcpy() bytes length since some CAN records received from
> PCAN-USB could define a DLC field in range [9..15].
> In that case, the real DLC value MUST be used to move forward the record pointer
> but, only 8 bytes max. MUST be copied into the data field of the struct
> can_frame object of the skb given to the network core.
>
> Cc: linux-stable <stable@vger.kernel.org>
> Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] macvtap: fix two races
From: David Miller @ 2013-08-12 4:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: thuth, netdev, vyasevic
In-Reply-To: <1375974374.4004.103.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 08 Aug 2013 08:06:14 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Since commit ac4e4af1e59e1 ("macvtap: Consistently use rcu functions"),
> Thomas gets two different warnings :
...
> And
...
> In the first case, macvtap_put_user() calls macvlan_count_rx()
> in a preempt-able context, and this is not allowed.
>
> In the second case, macvtap_get_user() calls
> macvlan_start_xmit() with BH enabled, and this is not allowed.
>
> Reported-by: Thomas Huth <thuth@linux.vnet.ibm.com>
> Bisected-by: Thomas Huth <thuth@linux.vnet.ibm.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Tested-by: Thomas Huth <thuth@linux.vnet.ibm.com>
> Cc: Vlad Yasevich <vyasevic@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v5] net: Add MOXA ART SoCs ethernet driver
From: David Miller @ 2013-08-12 4:38 UTC (permalink / raw)
To: jonas.jensen
Cc: netdev, linux-doc, devicetree, linux-arm-kernel, linux-kernel,
arm, florian, joe, mark.rutland
In-Reply-To: <1375961694-5375-1-git-send-email-jonas.jensen@gmail.com>
From: Jonas Jensen <jonas.jensen@gmail.com>
Date: Thu, 8 Aug 2013 13:34:54 +0200
> The MOXA UC-711X hardware(s) has an ethernet controller that seem
> to be developed internally. The IC used is "RTL8201CP".
>
> Since there is no public documentation, this driver is mostly the
> one published by MOXA that has been heavily cleaned up / ported
> from linux 2.6.9.
>
> Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH v2 3.11] genetlink: fix family dump race
From: David Miller @ 2013-08-12 4:29 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, tgraf-G/eBtMaohhA,
andrei.otcheretianski-ral2JQCrhuEAvxtiuMwx3w,
ilan.peer-ral2JQCrhuEAvxtiuMwx3w,
johannes.berg-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <1375879163-2116-1-git-send-email-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Wed, 7 Aug 2013 14:39:23 +0200
> When dumping generic netlink families, only the first dump call
> is locked with genl_lock(), which protects the list of families,
> and thus subsequent calls can access the data without locking,
> racing against family addition/removal. This can cause a crash.
> Fix it - the locking needs to be conditional because the first
> time around it's already locked.
>
> BUG: unable to handle kernel paging request at f8467360
> IP: [<c14c56bb>] ctrl_dumpfamily+0x6b/0xe0
> EIP: 0060:[<c14c56bb>] EFLAGS: 00210297 CPU: 2
> EIP is at ctrl_dumpfamily+0x6b/0xe0
> EAX: f8467378 EBX: f8467340 ECX: 00000000 EDX: ec1610c4
> ESI: 00000001 EDI: c2077cc0 EBP: c46c3c00 ESP: c46c3bd4
> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> CR0: 80050033 CR2: f8467360 CR3: 26e54000 CR4: 001407d0
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: ffff0ff0 DR7: 00000400
> Process wpa_supplicant (pid: 20081, ti=c46c2000 task=c44640b0 task.ti=c46c2000)
> Call Trace:
> [<c14c20bc>] netlink_dump+0x5c/0x200
> [<c14c3450>] __netlink_dump_start+0x140/0x160
> [<c14c5172>] genl_rcv_msg+0x102/0x270
> [<c14c4b5e>] netlink_rcv_skb+0x8e/0xb0
> [<c14c505c>] genl_rcv+0x1c/0x30
> [<c14c456b>] netlink_unicast+0x17b/0x1c0
> [<c14c47d4>] netlink_sendmsg+0x224/0x370
> [<c1485adf>] sock_sendmsg+0xff/0x120
I completely agree with your analysis that we need locking here, but
the crash OOPS backtrace doesn't make any sense to me.
The bug should trigger when we enter the dump continuation path, which
would look like:
ctrl_dumpfamily()
netlink_dump()
netlink_recvmsg()
...
Since this is the only way we get into ctrl_dumpfamily() without
holding genl_lock().
But in your trace we're going through genl_rcv() which means this is
the first call of the dump, and genl_rcv() takes the necessary locks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* Re: [PATCH net-next] net: documentation update for IGMP/MLD unsolicited report interval knobs
From: David Miller @ 2013-08-12 4:08 UTC (permalink / raw)
To: hannes; +Cc: xiyou.wangcong, netdev, william.manley, bcrl
In-Reply-To: <20130812033358.GA15405@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon, 12 Aug 2013 05:33:58 +0200
> Joined documentation update for IPv4 and IPv6 MLD/IGMP
> unsolicited_report_interval procfs knobs.
>
> Cc: Cong Wang <xiyou.wangcong@gmail.com>
> Cc: William Manley <william.manley@youview.com>
> Cc: Benjamin LaHaise <bcrl@kvack.org>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Update your ipv6 patch to include these changes, don't make them
seperately.
^ permalink raw reply
* [PATCH net-next] net: documentation update for IGMP/MLD unsolicited report interval knobs
From: Hannes Frederic Sowa @ 2013-08-12 3:33 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, william.manley, bcrl
In-Reply-To: <ku9gvg$27t$1@ger.gmane.org>
Joined documentation update for IPv4 and IPv6 MLD/IGMP
unsolicited_report_interval procfs knobs.
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: William Manley <william.manley@youview.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
Documentation/networking/ip-sysctl.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 36be26b..debfe85 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1039,7 +1039,15 @@ disable_policy - BOOLEAN
disable_xfrm - BOOLEAN
Disable IPSEC encryption on this interface, whatever the policy
+igmpv2_unsolicited_report_interval - INTEGER
+ The interval in milliseconds in which the next unsolicited
+ IGMPv1 or IGMPv2 report retransmit will take place.
+ Default: 10000 (10 seconds)
+igmpv3_unsolicited_report_interval - INTEGER
+ The interval in milliseconds in which the next unsolicited
+ IGMPv3 report retransmit will take place.
+ Default: 1000 (1 seconds)
tag - INTEGER
Allows you to write a number, which can be used as required.
@@ -1331,6 +1339,16 @@ ndisc_notify - BOOLEAN
1 - Generate unsolicited neighbour advertisements when device is brought
up or hardware address changes.
+mldv1_unsolicited_report_interval - INTEGER
+ The interval in milliseconds in which the next unsolicited
+ MLDv1 report retransmit will take place.
+ Default: 10000 (10 seconds)
+
+mldv2_unsolicited_report_interval - INTEGER
+ The interval in milliseconds in which the next unsolicited
+ MLDv2 report retransmit will take place.
+ Default: 1000 (1 second)
+
icmp/*:
ratelimit - INTEGER
Limit the maximal rates for sending ICMPv6 packets.
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next] ipv6: make unsolicited report intervals configurable for mld
From: Cong Wang @ 2013-08-12 2:23 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130812014859.GA13886@order.stressinduktion.org>
On Mon, 12 Aug 2013 at 01:48 GMT, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> Commit cab70040dfd95ee32144f02fade64f0cb94f31a0 ("net: igmp:
> Reduce Unsolicited report interval to 1s when using IGMPv3") and
> 2690048c01f32bf45d1c1e1ab3079bc10ad2aea7 ("net: igmp: Allow user-space
> configuration of igmp unsolicited report interval") by William Manley made
> igmp unsolicited report intervals configurable per interface and corrected
> the interval of unsolicited igmpv3 report messages resendings to 1s.
>
> Same needs to be done for IPv6:
>
> MLDv1 (RFC2710 7.10.): 10 seconds
> MLDv2 (RFC3810 9.11.): 1 second
>
> Both intervals are configurable via new procfs knobs
> mldv1_unsolicited_report_interval and mldv2_unsolicited_report_interval.
>
Please update the doc as well.
^ permalink raw reply
* linux-next: manual merge of the cgroup tree with the net-next tree
From: Stephen Rothwell @ 2013-08-12 2:21 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-next, linux-kernel, Joe Perches, David Miller, netdev
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
Hi Tejun,
Today's linux-next merge of the cgroup tree got a conflict in
include/net/netprio_cgroup.h between commit 378307217ed9 ("cls_cgroup.h
netprio_cgroup.h: Remove extern from function prototypes") from the
net-next tree and commit 6d37b97428d2 ("netprio_cgroup: pass around @css
instead of @cgroup and kill struct cgroup_netprio_state") from the cgroup
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/net/netprio_cgroup.h
index 379dd5d,a24f8bb..0000000
--- a/include/net/netprio_cgroup.h
+++ b/include/net/netprio_cgroup.h
@@@ -25,11 -25,7 +25,7 @@@ struct netprio_map
u32 priomap[];
};
- struct cgroup_netprio_state {
- struct cgroup_subsys_state css;
- };
-
-extern void sock_update_netprioidx(struct sock *sk);
+void sock_update_netprioidx(struct sock *sk);
#if IS_BUILTIN(CONFIG_NETPRIO_CGROUP)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH net-next] ipv6: make unsolicited report intervals configurable for mld
From: Hannes Frederic Sowa @ 2013-08-12 1:48 UTC (permalink / raw)
To: netdev; +Cc: william.manley, bcrl, yoshfuji
Commit cab70040dfd95ee32144f02fade64f0cb94f31a0 ("net: igmp:
Reduce Unsolicited report interval to 1s when using IGMPv3") and
2690048c01f32bf45d1c1e1ab3079bc10ad2aea7 ("net: igmp: Allow user-space
configuration of igmp unsolicited report interval") by William Manley made
igmp unsolicited report intervals configurable per interface and corrected
the interval of unsolicited igmpv3 report messages resendings to 1s.
Same needs to be done for IPv6:
MLDv1 (RFC2710 7.10.): 10 seconds
MLDv2 (RFC3810 9.11.): 1 second
Both intervals are configurable via new procfs knobs
mldv1_unsolicited_report_interval and mldv2_unsolicited_report_interval.
Cc: William Manley <william.manley@youview.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/linux/ipv6.h | 2 ++
include/uapi/linux/ipv6.h | 2 ++
net/ipv6/addrconf.c | 25 +++++++++++++++++++++++++
net/ipv6/mcast.c | 17 ++++++++++++++---
4 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 850e95b..77a4784 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -19,6 +19,8 @@ struct ipv6_devconf {
__s32 rtr_solicit_interval;
__s32 rtr_solicit_delay;
__s32 force_mld_version;
+ __s32 mldv1_unsolicited_report_interval;
+ __s32 mldv2_unsolicited_report_interval;
#ifdef CONFIG_IPV6_PRIVACY
__s32 use_tempaddr;
__s32 temp_valid_lft;
diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
index 4bda4cf..315f133 100644
--- a/include/uapi/linux/ipv6.h
+++ b/include/uapi/linux/ipv6.h
@@ -147,6 +147,8 @@ enum {
DEVCONF_MAX_DESYNC_FACTOR,
DEVCONF_MAX_ADDRESSES,
DEVCONF_FORCE_MLD_VERSION,
+ DEVCONF_MLDV1_UNSOLICITED_REPORT_INTERVAL,
+ DEVCONF_MLDV2_UNSOLICITED_REPORT_INTERVAL,
DEVCONF_ACCEPT_RA_DEFRTR,
DEVCONF_ACCEPT_RA_PINFO,
DEVCONF_ACCEPT_RA_RTR_PREF,
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 7fd8572..158c5e1 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -177,6 +177,8 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
.accept_redirects = 1,
.autoconf = 1,
.force_mld_version = 0,
+ .mldv1_unsolicited_report_interval = 10*HZ,
+ .mldv2_unsolicited_report_interval = HZ,
.dad_transmits = 1,
.rtr_solicits = MAX_RTR_SOLICITATIONS,
.rtr_solicit_interval = RTR_SOLICITATION_INTERVAL,
@@ -211,6 +213,9 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
.accept_ra = 1,
.accept_redirects = 1,
.autoconf = 1,
+ .force_mld_version = 0,
+ .mldv1_unsolicited_report_interval = 10*HZ,
+ .mldv2_unsolicited_report_interval = HZ,
.dad_transmits = 1,
.rtr_solicits = MAX_RTR_SOLICITATIONS,
.rtr_solicit_interval = RTR_SOLICITATION_INTERVAL,
@@ -4179,6 +4184,10 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
array[DEVCONF_RTR_SOLICIT_DELAY] =
jiffies_to_msecs(cnf->rtr_solicit_delay);
array[DEVCONF_FORCE_MLD_VERSION] = cnf->force_mld_version;
+ array[DEVCONF_MLDV1_UNSOLICITED_REPORT_INTERVAL] =
+ jiffies_to_msecs(cnf->mldv1_unsolicited_report_interval);
+ array[DEVCONF_MLDV2_UNSOLICITED_REPORT_INTERVAL] =
+ jiffies_to_msecs(cnf->mldv2_unsolicited_report_interval);
#ifdef CONFIG_IPV6_PRIVACY
array[DEVCONF_USE_TEMPADDR] = cnf->use_tempaddr;
array[DEVCONF_TEMP_VALID_LFT] = cnf->temp_valid_lft;
@@ -4862,6 +4871,22 @@ static struct addrconf_sysctl_table
.mode = 0644,
.proc_handler = proc_dointvec,
},
+ {
+ .procname = "mldv1_unsolicited_report_interval",
+ .data =
+ &ipv6_devconf.mldv1_unsolicited_report_interval,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_ms_jiffies,
+ },
+ {
+ .procname = "mldv2_unsolicited_report_interval",
+ .data =
+ &ipv6_devconf.mldv2_unsolicited_report_interval,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_ms_jiffies,
+ },
#ifdef CONFIG_IPV6_PRIVACY
{
.procname = "use_tempaddr",
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index db25b8e..6c76df9 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -108,7 +108,6 @@ static int ip6_mc_leave_src(struct sock *sk, struct ipv6_mc_socklist *iml,
struct inet6_dev *idev);
-#define IGMP6_UNSOLICITED_IVAL (10*HZ)
#define MLD_QRV_DEFAULT 2
#define MLD_V1_SEEN(idev) (dev_net((idev)->dev)->ipv6.devconf_all->force_mld_version == 1 || \
@@ -129,6 +128,18 @@ int sysctl_mld_max_msf __read_mostly = IPV6_MLD_MAX_MSF;
pmc != NULL; \
pmc = rcu_dereference(pmc->next))
+static int unsolicited_report_interval(struct inet6_dev *idev)
+{
+ int iv;
+
+ if (MLD_V1_SEEN(idev))
+ iv = idev->cnf.mldv1_unsolicited_report_interval;
+ else
+ iv = idev->cnf.mldv2_unsolicited_report_interval;
+
+ return iv > 0 ? iv : 1;
+}
+
int ipv6_sock_mc_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
{
struct net_device *dev = NULL;
@@ -2158,7 +2169,7 @@ static void igmp6_join_group(struct ifmcaddr6 *ma)
igmp6_send(&ma->mca_addr, ma->idev->dev, ICMPV6_MGM_REPORT);
- delay = net_random() % IGMP6_UNSOLICITED_IVAL;
+ delay = net_random() % unsolicited_report_interval(ma->idev);
spin_lock_bh(&ma->mca_lock);
if (del_timer(&ma->mca_timer)) {
@@ -2325,7 +2336,7 @@ void ipv6_mc_init_dev(struct inet6_dev *idev)
setup_timer(&idev->mc_dad_timer, mld_dad_timer_expire,
(unsigned long)idev);
idev->mc_qrv = MLD_QRV_DEFAULT;
- idev->mc_maxdelay = IGMP6_UNSOLICITED_IVAL;
+ idev->mc_maxdelay = unsolicited_report_interval(idev);
idev->mc_v1_seen = 0;
write_unlock_bh(&idev->lock);
}
--
1.8.3.1
^ permalink raw reply related
* Re: locating the 'tc actions' hook
From: Jamal Hadi Salim @ 2013-08-12 0:55 UTC (permalink / raw)
To: John Fastabend
Cc: John Fastabend, Stephen Hemminger, Eric Dumazet, Tom Herbert,
netdev
In-Reply-To: <51FFCEB3.3010404@gmail.com>
On 13-08-05 12:11 PM, John Fastabend wrote:
> Actually in the first case here I was considering egress traffic.
>
[..]
> Separating the classifier chain from the qdisc allows using the
> classifiers to pick a qdisc via queue_mapping because qdisc's are
> attached to queues when using sch_mq.
>
[..]
> Sorry I mucked two examples one egress and one ingress together without
> clearly stating it. The second case here was ingress the first egress.
>
Ok. Still fine; if a tag of some form exists, the driver should be
able to inherit it and pass it down to the hardware.
There's akready precedence on such offloading, this should just
follow in the same spirit.
> But currently we have a situation on egress where multiqueue devices
> use mq or mqprio which aligns qdisc's with queues. This fixes the
> performance penalties but you lose the ability to have state across
> multiple queues and the ability to bind flows to queues.
>
If the goal is to share resources, there's no way to avoid locks.
You have to update resource usage state which is a write operation.
Dont even bother with rcu.
> For example a SW rate limiter that applies to a set of queues or a set
> of tuned low latency queues. To fix this we can attach a qdisc (htb,
> whatever) to the netdev but this has performance penalties. So we are
> left with a trade off between functionality and performance.
>
> On the ingress side we may have many queues but as soon as we add a
> qdisc/classifier/action we have a single lock.
>
[..]
> Thanks. I'll see if I can draw up what I'm thinking here a bit more
> clearly and send it your way.
I think that would help me. Maybe we should take it offline and sync up.
cheers,
jamal
^ permalink raw reply
* [RFC][PATCH 2/2] bgmac: pass received packet to the netif instead of copying it
From: Rafał Miłecki @ 2013-08-11 17:49 UTC (permalink / raw)
To: netdev, openwrt-devel, Hauke Mehrtens, Florian Fainelli,
Jonas Gorski, Robert Bradley
Cc: Rafał Miłecki
In-Reply-To: <1376243355-5740-1-git-send-email-zajec5@gmail.com>
It makes more sense to allocate new (empty) skb and pass it to the
hardware. That way we avoid copying whole packet into new skb which
should result in better performance.
---
drivers/net/ethernet/broadcom/bgmac.c | 74 ++++++++++++++++++++++++---------
1 file changed, 54 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index e70ee43..425fe81 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -304,9 +304,9 @@ static int bgmac_dma_rx_read(struct bgmac *bgmac, struct bgmac_dma_ring *ring,
struct device *dma_dev = bgmac->core->dma_dev;
struct bgmac_slot_info *slot = &ring->slots[ring->start];
struct sk_buff *skb = slot->skb;
- struct sk_buff *new_skb;
struct bgmac_rx_header *rx;
u16 len, flags;
+ bool resync_skb = true;
/* Unmap buffer to make it accessible to the CPU */
dma_sync_single_for_cpu(dma_dev, slot->dma_addr,
@@ -317,36 +317,70 @@ static int bgmac_dma_rx_read(struct bgmac *bgmac, struct bgmac_dma_ring *ring,
len = le16_to_cpu(rx->len);
flags = le16_to_cpu(rx->flags);
- /* Check for poison and drop or pass the packet */
- if (len == 0xdead && flags == 0xbeef) {
- bgmac_err(bgmac, "Found poisoned packet at slot %d, DMA issue!\n",
- ring->start);
- } else {
+ do {
+ /* Check for poisoned packet */
+ if (len == 0xdead && flags == 0xbeef) {
+ bgmac_err(bgmac, "Found poisoned packet at slot %d, DMA issue!\n",
+ ring->start);
+ break;
+ }
+
/* Omit CRC. */
len -= ETH_FCS_LEN;
- new_skb = netdev_alloc_skb_ip_align(bgmac->net_dev, len);
- if (new_skb) {
+ /* Use skb_copy for small packets only */
+ if (len > 1) {
+ dma_addr_t old_dma_addr = slot->dma_addr;
+ int err;
+
+ /* Prepare new skb for further packets */
+ err = bgmac_dma_rx_skb_for_slot(bgmac, slot);
+ if (err) {
+ bgmac_err(bgmac, "Couldn't allocate new skb for slot %d!\n",
+ ring->start);
+ bgmac->net_dev->stats.rx_dropped++;
+ break;
+ }
+ bgmac_dma_rx_setup_desc(bgmac, ring,
+ ring->start);
+
+ /* Unmap old skb, we'll pass it to the netfif */
+ dma_unmap_single(dma_dev, old_dma_addr,
+ BGMAC_RX_BUF_SIZE,
+ DMA_FROM_DEVICE);
+ resync_skb = false;
+
+ skb_put(skb, BGMAC_RX_FRAME_OFFSET + len);
+ skb_pull(skb, BGMAC_RX_FRAME_OFFSET);
+ } else {
+ struct sk_buff *new_skb;
+
+ /* Poison the old skb */
+ rx->len = cpu_to_le16(0xdead);
+ rx->flags = cpu_to_le16(0xbeef);
+
+ new_skb = netdev_alloc_skb_ip_align(bgmac->net_dev, len);
+ if (!new_skb) {
+ bgmac_err(bgmac, "Allocation of skb for copying packet failed!\n");
+ bgmac->net_dev->stats.rx_dropped++;
+ break;
+ }
+
skb_put(new_skb, len);
skb_copy_from_linear_data_offset(skb, BGMAC_RX_FRAME_OFFSET,
new_skb->data,
len);
- skb_checksum_none_assert(skb);
- new_skb->protocol =
- eth_type_trans(new_skb, bgmac->net_dev);
- netif_receive_skb(new_skb);
- handled++;
- } else {
- bgmac->net_dev->stats.rx_dropped++;
- bgmac_err(bgmac, "Allocation of skb for copying packet failed!\n");
+ skb = new_skb;
}
- /* Poison the old skb */
- rx->len = cpu_to_le16(0xdead);
- rx->flags = cpu_to_le16(0xbeef);
- }
+ skb_checksum_none_assert(skb);
+ skb->protocol = eth_type_trans(skb, bgmac->net_dev);
+ netif_receive_skb(skb);
+ handled++;
+ } while (0);
/* Make it back accessible to the hardware */
+ if (resync_skb)
dma_sync_single_for_device(dma_dev, slot->dma_addr,
BGMAC_RX_BUF_SIZE, DMA_FROM_DEVICE);
--
1.7.10.4
^ permalink raw reply related
* [RFC][PATCH 1/2] bgmac: separate RX desc setup code into new function
From: Rafał Miłecki @ 2013-08-11 17:49 UTC (permalink / raw)
To: netdev, openwrt-devel, Hauke Mehrtens, Florian Fainelli,
Jonas Gorski, Robert Bradley
---
drivers/net/ethernet/broadcom/bgmac.c | 41 ++++++++++++++++++---------------
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 1b8e7a3..e70ee43 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -268,6 +268,26 @@ static int bgmac_dma_rx_skb_for_slot(struct bgmac *bgmac,
return 0;
}
+static void bgmac_dma_rx_setup_desc(struct bgmac *bgmac,
+ struct bgmac_dma_ring *ring, int desc_idx)
+{
+ struct bgmac_dma_desc *dma_desc = ring->cpu_base + desc_idx;
+ u32 ctl0 = 0, ctl1 = 0;
+
+ if (desc_idx == ring->num_slots - 1)
+ ctl0 |= BGMAC_DESC_CTL0_EOT;
+ ctl1 |= BGMAC_RX_BUF_SIZE & BGMAC_DESC_CTL1_LEN;
+ /* Is there any BGMAC device that requires extension? */
+ /* ctl1 |= (addrext << B43_DMA64_DCTL1_ADDREXT_SHIFT) &
+ * B43_DMA64_DCTL1_ADDREXT_MASK;
+ */
+
+ dma_desc->addr_low = cpu_to_le32(lower_32_bits(ring->slots[desc_idx].dma_addr));
+ dma_desc->addr_high = cpu_to_le32(upper_32_bits(ring->slots[desc_idx].dma_addr));
+ dma_desc->ctl0 = cpu_to_le32(ctl0);
+ dma_desc->ctl1 = cpu_to_le32(ctl1);
+}
+
static int bgmac_dma_rx_read(struct bgmac *bgmac, struct bgmac_dma_ring *ring,
int weight)
{
@@ -484,8 +504,6 @@ err_dma_free:
static void bgmac_dma_init(struct bgmac *bgmac)
{
struct bgmac_dma_ring *ring;
- struct bgmac_dma_desc *dma_desc;
- u32 ctl0, ctl1;
int i;
for (i = 0; i < BGMAC_MAX_TX_RINGS; i++) {
@@ -514,23 +532,8 @@ static void bgmac_dma_init(struct bgmac *bgmac)
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_RX_RINGHI,
upper_32_bits(ring->dma_base));
- for (j = 0, dma_desc = ring->cpu_base; j < ring->num_slots;
- j++, dma_desc++) {
- ctl0 = ctl1 = 0;
-
- if (j == ring->num_slots - 1)
- ctl0 |= BGMAC_DESC_CTL0_EOT;
- ctl1 |= BGMAC_RX_BUF_SIZE & BGMAC_DESC_CTL1_LEN;
- /* Is there any BGMAC device that requires extension? */
- /* ctl1 |= (addrext << B43_DMA64_DCTL1_ADDREXT_SHIFT) &
- * B43_DMA64_DCTL1_ADDREXT_MASK;
- */
-
- dma_desc->addr_low = cpu_to_le32(lower_32_bits(ring->slots[j].dma_addr));
- dma_desc->addr_high = cpu_to_le32(upper_32_bits(ring->slots[j].dma_addr));
- dma_desc->ctl0 = cpu_to_le32(ctl0);
- dma_desc->ctl1 = cpu_to_le32(ctl1);
- }
+ for (j = 0; j < ring->num_slots; j++)
+ bgmac_dma_rx_setup_desc(bgmac, ring, j);
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_RX_INDEX,
ring->num_slots * sizeof(struct bgmac_dma_desc));
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net] net: sctp: sctp_assoc_control_transport: fix MTU size in SCTP_PF state
From: Neil Horman @ 2013-08-11 16:16 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, kheiss, netdev, linux-sctp
In-Reply-To: <1376053748-31783-1-git-send-email-dborkman@redhat.com>
On Fri, Aug 09, 2013 at 03:09:08PM +0200, Daniel Borkmann wrote:
> The SCTP Quick failover draft [1] section 5.1, point 5 says that the cwnd
> should be 1 MTU. So, instead of 1, set it to 1 MTU.
>
> [1] https://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
>
> Reported-by: Karl Heiss <kheiss@gmail.com>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> ---
> net/sctp/associola.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index bce5b79..ab67efc 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -846,12 +846,12 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
> else
> spc_state = SCTP_ADDR_AVAILABLE;
> /* Don't inform ULP about transition from PF to
> - * active state and set cwnd to 1, see SCTP
> + * active state and set cwnd to 1 MTU, see SCTP
> * Quick failover draft section 5.1, point 5
> */
> if (transport->state == SCTP_PF) {
> ulp_notify = false;
> - transport->cwnd = 1;
> + transport->cwnd = asoc->pathmtu;
> }
> transport->state = SCTP_ACTIVE;
> break;
> --
> 1.7.11.7
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: question about netif_rx
From: Julia Lawall @ 2013-08-11 16:12 UTC (permalink / raw)
To: Francois Romieu
Cc: Julia Lawall, grant.likely, rob.herring, netdev, linux-kernel,
devicetree
In-Reply-To: <20130811155640.GA10070@electric-eye.fr.zoreil.com>
On Sun, 11 Aug 2013, Francois Romieu wrote:
> Julia Lawall <julia.lawall@lip6.fr> :
> > To my limited understanding, in a NAPI polling function, one should use
> > netif_receive_skb, rather than netif_rx.
>
> Nit: or napi_gro_receive (+ napi_gro_flush with __napi_complete) when the
> device offers some checksum offloading features.
OK, thanks for the information. I am just trying to understand these
functions...
> > However, the via-velocity driver defines the NAPI polling function
> > velocity_poll, which is the only caller of velocity_rx_srv, which
> > is the only caller of velocity_receive_frame, which calls netif_rx.
> > The call to netif_rx seems to predate the introduction of NAPI in
> > this driver. Is this correct?
>
> You are right. It's a leftover of the NAPI changes in this driver.
>
> Can you send a netif_receive_skb replacement patch for it ?
Just to be sure, I just replace netif_rx by netif_receive_skb, nothing
else?
thanks,
julia
^ permalink raw reply
* Re: question about netif_rx
From: Francois Romieu @ 2013-08-11 15:56 UTC (permalink / raw)
To: Julia Lawall; +Cc: grant.likely, rob.herring, netdev, linux-kernel, devicetree
In-Reply-To: <alpine.DEB.2.02.1308111151210.2072@localhost6.localdomain6>
Julia Lawall <julia.lawall@lip6.fr> :
> To my limited understanding, in a NAPI polling function, one should use
> netif_receive_skb, rather than netif_rx.
Nit: or napi_gro_receive (+ napi_gro_flush with __napi_complete) when the
device offers some checksum offloading features.
> However, the via-velocity driver defines the NAPI polling function
> velocity_poll, which is the only caller of velocity_rx_srv, which
> is the only caller of velocity_receive_frame, which calls netif_rx.
> The call to netif_rx seems to predate the introduction of NAPI in
> this driver. Is this correct?
You are right. It's a leftover of the NAPI changes in this driver.
Can you send a netif_receive_skb replacement patch for it ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH 1/2 net-next] af_unix: improve STREAM behavior with fragmented memory
From: Eric Dumazet @ 2013-08-11 14:42 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: David Miller, David Rientjes, netdev
In-Reply-To: <20130811143715.GA3699@order.stressinduktion.org>
On Sun, 2013-08-11 at 16:37 +0200, Hannes Frederic Sowa wrote:
> On Sun, Aug 11, 2013 at 07:32:33AM -0700, Eric Dumazet wrote:
> > On Sun, 2013-08-11 at 16:06 +0200, Hannes Frederic Sowa wrote:
> >
> > > I am sorry to report that I had to revert both these patches to have a working
> > > systemd again.
> >
> > Hi Hannes
> >
> > If you revert only the second patch, the problem is still there, right ?
>
> Exactly, only reverting 2/2 did not help.
I wonder if the consumed field (part of skb->cb{}) would not be zero ?
I assumed it was. I have to check.
^ permalink raw reply
* Re: [PATCH 1/2 net-next] af_unix: improve STREAM behavior with fragmented memory
From: Hannes Frederic Sowa @ 2013-08-11 14:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, David Rientjes, netdev
In-Reply-To: <1376231553.3291.0.camel@edumazet-glaptop>
On Sun, Aug 11, 2013 at 07:32:33AM -0700, Eric Dumazet wrote:
> On Sun, 2013-08-11 at 16:06 +0200, Hannes Frederic Sowa wrote:
>
> > I am sorry to report that I had to revert both these patches to have a working
> > systemd again.
>
> Hi Hannes
>
> If you revert only the second patch, the problem is still there, right ?
Exactly, only reverting 2/2 did not help.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH 1/2 net-next] af_unix: improve STREAM behavior with fragmented memory
From: Eric Dumazet @ 2013-08-11 14:32 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: David Miller, David Rientjes, netdev
In-Reply-To: <20130811140605.GA5666@order.stressinduktion.org>
On Sun, 2013-08-11 at 16:06 +0200, Hannes Frederic Sowa wrote:
> I am sorry to report that I had to revert both these patches to have a working
> systemd again.
Hi Hannes
If you revert only the second patch, the problem is still there, right ?
^ permalink raw reply
* Re: [PATCH 1/2 net-next] af_unix: improve STREAM behavior with fragmented memory
From: Hannes Frederic Sowa @ 2013-08-11 14:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, David Rientjes, netdev
In-Reply-To: <1375997852.4004.130.camel@edumazet-glaptop>
On Thu, Aug 08, 2013 at 02:37:32PM -0700, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> unix_stream_sendmsg() currently uses order-2 allocations,
> and we had numerous reports this can fail.
>
> The __GFP_REPEAT flag present in sock_alloc_send_pskb() is
> not helping.
>
> This patch extends the work done in commit eb6a24816b247c
> ("af_unix: reduce high order page allocations) for
> datagram sockets.
>
> This opens the possibility of zero copy IO (splice() and
> friends)
>
> The trick is to not use skb_pull() anymore in recvmsg() path,
> and instead add a @consumed field in UNIXCB() to track amount
> of already read payload in the skb.
>
> There is a performance regression for large sends
> because of extra page allocations that will be addressed
> in a follow-up patch, allowing sock_alloc_send_pskb()
> to attempt high order page allocations.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: David Rientjes <rientjes@google.com>
I am sorry to report that I had to revert both these patches to have a working
systemd again.
This is the af_unix stream server side:
$ strace -e network -p 1
Process 1 attached
accept4(9, {sa_family=AF_LOCAL, NULL}, [2], SOCK_CLOEXEC) = 15
getsockname(15, {sa_family=AF_LOCAL, sun_path="/run/systemd/private"}, [23]) = 0
recvmsg(15, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}], msg_controllen=0, msg_flags=0}, 0) = 1
getsockopt(15, SOL_SOCKET, SO_PEERCRED, {pid=515, uid=0, gid=0}, [12]) = 0
sendto(15, "OK cfd216826810ecc1c17014b052079"..., 37, MSG_NOSIGNAL, NULL, 0) = 37
sendto(15, "AGREE_UNIX_FD\r\n", 15, MSG_NOSIGNAL, NULL, 0) = 15
getsockopt(15, SOL_SOCKET, SO_PEERSEC, "unconfined_u:unconfined_r:unconf"..., [54]) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 28
connect(28, {sa_family=AF_LOCAL, sun_path="/var/run/setrans/.setrans-unix"}, 110) = -1 ENOENT (No such file or directory)
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 28
connect(28, {sa_family=AF_LOCAL, sun_path="/var/run/setrans/.setrans-unix"}, 110) = -1 ENOENT (No such file or directory)
getsockopt(15, SOL_SOCKET, SO_PEERCRED, {pid=515, uid=0, gid=0}, [12]) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 28
connect(28, {sa_family=AF_LOCAL, sun_path="/var/run/setrans/.setrans-unix"}, 110) = -1 ENOENT (No such file or directory)
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 28
connect(28, {sa_family=AF_LOCAL, sun_path="/var/run/setrans/.setrans-unix"}, 110) = -1 ENOENT (No such file or directory)
sendmsg(15, {msg_name(0)=NULL, msg_iov(2)=[{"l\2\1\0018\233\0\0\1\0\0\0\33\0\0\0\5\1u\0\1\0\0\0\10\1g\0\ra(s"..., 48}, {"0\233\0\0\0\0\0\0\20\0\0\0ebtables.service\0\0\0\0"..., 39736}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 39784
recvmsg(15, {msg_name(0)=NULL, msg_iov(1)=[{"", 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 0
This the af_unix stream client side:
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/private"}, 22) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
sendto(3, "\0", 1, MSG_NOSIGNAL, NULL, 0) = 1
sendto(3, "AUTH EXTERNAL 30\r\n", 18, MSG_NOSIGNAL, NULL, 0) = 18
sendto(3, "NEGOTIATE_UNIX_FD\r\n", 19, MSG_NOSIGNAL, NULL, 0) = 19
sendto(3, "BEGIN\r\n", 7, MSG_NOSIGNAL, NULL, 0) = 7
sendmsg(3, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\1\0\0\0\222\0\0\0\1\1o\0\31\0\0\0/org/fre"..., 168}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 168
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\0018\233\0\0\1\0\0\0\33\0\0\0\5\1u\0\1\0\0\0\10\1g\0\ra(s"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"rget\0\0\0\0$\0\0\0systemd-update-utmp-"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"/systemd1/unit/systemd_2duser_2d"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"ed\0\0\10\0\0\0inactive\0\0\0\0\4\0\0\0dead\0\0\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"emd-random-seed-load.service\0\0\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"\4\0\0\0dead\0\0\0\0\0\0\0\0\0\0\0\0B\0\0\0/org/fre"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"\6\0\0\0exited\0\0\0\0\0\0\0\0\0\0009\0\0\0/org/fre"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"ode\0\6\0\0\0loaded\0\0\10\0\0\0inactive\0\0\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"4\0\0\0/org/freedesktop/systemd1/un"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"up_2etarget\0\0\0\0\0\0\0\0\0\0\0\0\0;\0\0\0/org"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"art Card Daemon\0\6\0\0\0loaded\0\0\10\0\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"inactive\0\0\0\0\4\0\0\0dead\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{".swap\0\0\0006\0\0\0/dev/disk/by-uuid/3b"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"ice\0\0\0\0\0\0\0\0\0\0\0\0\0K\0\0\0/org/freedes"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"s_2dclean_2etimer\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"8250_2dtty_2dttyS1_2edevice\0\0\0\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{".device\0003\0\0\0/org/freedesktop/sys"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"dblock_2dvda_2edevice\0\0\0\16\0\0\0dev-"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{")\0\0\0SYSV: Initializes network co"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 2048
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"emd-random-seed-save.service\0\0\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 872
Failed to issue method call: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=516, si_status=0, si_utime=0, si_stime=0} ---
Total bytes consumed here is 19 * 2048 + 872 = 39784 which corresponds to
number of bytes send from the server.
Strange, all this looks normal even if I compare the results to a working
systemctl -a.
When stracing with -s40000 I see that the last string send is
'\0\0/org/freedesktop/systemd1/unit/polkit_2eservice\0' but on the receiver
side I get a '0\0\0/\0\0\0/org/freedesktop/systemd1/unit/prefd'. Which is
actually payload from the second recvmsg on the client side. The rest of the
payload matches up, too.
Maybe you could have a look?
Greetings,
Hannes
^ permalink raw reply
* Re: mlx4 interrupt coalescing not important for small packets?
From: Amir Vadai @ 2013-08-11 13:23 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: netdev, Amir Vadai
In-Reply-To: <20130809170637.GA5258@sbohrermbp13-local.rgmadvisors.com>
On 09/08/2013 20:06, Shawn Bohrer wrote:
> I was looking at the adaptive interrupt coalescing algorithm for
> mlx4_en which contains the following snippet:
>
> /* Apply auto-moderation only when packet rate
> * exceeds a rate that it matters */
> if (rate > (MLX4_EN_RX_RATE_THRESH / priv->rx_ring_num) &&
> avg_pkt_size > MLX4_EN_AVG_PKT_SMALL) {
> if (rate < priv->pkt_rate_low)
> moder_time = priv->rx_usecs_low;
> else if (rate > priv->pkt_rate_high)
> moder_time = priv->rx_usecs_high;
> else
> moder_time = (rate - priv->pkt_rate_low) *
> (priv->rx_usecs_high - priv->rx_usecs_low) /
> (priv->pkt_rate_high - priv->pkt_rate_low) +
> priv->rx_usecs_low;
> } else {
> moder_time = priv->rx_usecs_low;
> }
>
> In this case MLX4_EN_AVG_PKT_SMALL is 256 bytes. Can someone explain
> to me why interrupt coalescing is not important for small packets
> regardless of the incoming packet rate?
>
> Thanks,
> Shawn
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
The idea was that for small packets, should enter "latency mode"
regardless the packet rate.
Amir
^ permalink raw reply
* question about netif_rx
From: Julia Lawall @ 2013-08-11 9:56 UTC (permalink / raw)
To: romieu, grant.likely, rob.herring, netdev, linux-kernel,
devicetree
To my limited understanding, in a NAPI polling function, one should use
netif_receive_skb, rather than netif_rx. However, the via-velocity driver
defines the NAPI polling function velocity_poll, which is the only caller
of velocity_rx_srv, which is the only caller of velocity_receive_frame,
which calls netif_rx. The call to netif_rx seems to predate the
introduction of NAPI in this driver. Is this correct?
thanks,
julia
^ permalink raw reply
* Re: [PATCH v2 net-next] net: Add low-latency/polling support for UDP multicast
From: Eliezer Tamir @ 2013-08-11 7:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Shawn Bohrer, davem, netdev, Amir Vadai, tomk
In-Reply-To: <1376006114.4004.141.camel@edumazet-glaptop>
On 09/08/2013 02:55, Eric Dumazet wrote:
> On Thu, 2013-08-08 at 11:46 +0300, Eliezer Tamir wrote:
>> On 07/08/2013 23:22, Eric Dumazet wrote:
>>> sk_mark_napi_id() in UDP are wrong IMHO.
>>>
>>> It should be guarded by the following test in
>>> __udp_queue_rcv_skb()
>>>
>>> if (inet_sk(sk)->inet_daddr) {
>>> sock_rps_save_rxhash(sk, skb);
>>> sk_mark_napi_id(sk, skb);
>>> }
>>>
>>> (To occur only for connected UDP sockets, where we are 100% sure all
>>> packets will use this same rxhash/rx queue)
>>
>> This would also be safe if there is only one NIC and said NIC was
>> programmed to always place this socket's data on the same queue.
>>
>> I don't have a good suggestion on how to detect this.
>
> Well, this stuff relies on flows being correctly steered.
>
> TCP stack performs much better if we avoid reorders ;)
Let's limit the discussion to UDP for now.
If you are getting packets on multiple queues for a TCP socket,
it's hard to see how you can avoid caused reordering.
Maybe it would be enough to have a socket option that the user
can set to tell the stack "I know what I'm doing, please allow busy
polling on this UDP socket, even though it's not bound".
^ permalink raw reply
* [PATCH] ping: remove excessive punctuation in flood warning
From: Benjamin Kerensa @ 2013-08-11 7:05 UTC (permalink / raw)
To: netdev; +Cc: yoshfuji
ping_common.c has excessive punctuation and this patches cleans that up.
Signed-off-by: Benjamin Kerensa <bkerensa@ubuntu.com>
---
ping_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ping_common.c b/ping_common.c
index 8d6b145..28128b0 100644
--- a/ping_common.c
+++ b/ping_common.c
@@ -608,7 +608,7 @@ void setup(int icmp_sock)
interval = 0;
if (uid && interval < MINUSERINTERVAL) {
- fprintf(stderr, "ping: cannot flood; minimal interval, allowed for
user, is %dms\n", MINUSERINTERVAL);
+ fprintf(stderr, "ping: cannot flood; minimal interval allowed for
user is %dms\n", MINUSERINTERVAL);
exit(2);
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH net] skge: dma_sync the whole receive buffer
From: poma @ 2013-08-11 4:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20130810150207.37432299@nehalam.linuxnetplumber.net>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
On 11.08.2013 00:02, Stephen Hemminger wrote:
> The DMA sync should sync the whole receive buffer, not just
> part of it. Fixes log messages dma_sync_check.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> --- a/drivers/net/ethernet/marvell/skge.c 2013-08-10 14:54:13.184737163 -0700
> +++ b/drivers/net/ethernet/marvell/skge.c 2013-08-10 14:54:54.908099676 -0700
> @@ -3077,11 +3077,13 @@ static struct sk_buff *skge_rx_get(struc
>
> pci_dma_sync_single_for_cpu(skge->hw->pdev,
> dma_unmap_addr(e, mapaddr),
> - len, PCI_DMA_FROMDEVICE);
> + dma_unmap_len(e, maplen),
> + PCI_DMA_FROMDEVICE);
> skb_copy_from_linear_data(e->skb, skb->data, len);
> pci_dma_sync_single_for_device(skge->hw->pdev,
> dma_unmap_addr(e, mapaddr),
> - len, PCI_DMA_FROMDEVICE);
> + dma_unmap_len(e, maplen),
> + PCI_DMA_FROMDEVICE);
> skge_rx_reuse(e, skge->rx_buf_size);
> } else {
> struct sk_buff *nskb;
>
Apart from all these warnings, oopses and kernel crashes, via skge iface
there is no traffic initiated starting from the fourth layer up i.e.
ssh, whatsoever.
Counting from the first patch - 'skge-add-dma_mapping-check.patch'.
Attached are readings after the third patch -
'skge-fix-log-messages-dma_sync_check.patch',
- 'dmesg-t-3.11.0-0.rc4.git4.1.fc20.x86_64-nmap.txt'
- 'dmesg-t-3.11.0-0.rc4.git4.1.fc20.x86_64-modprobe.txt'
Anyway thanks for the effort.
poma
[-- Attachment #2: dmesg-t-3.11.0-0.rc4.git4.1.fc20.x86_64-modprobe.txt --]
[-- Type: text/plain, Size: 16792 bytes --]
skge 0000:01:09.0 enp1s9: disabling interface
------------[ cut here ]------------
WARNING: CPU: 1 PID: 2111 at lib/dma-debug.c:877 check_unmap+0x837/0x930()
skge 0000:01:09.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x000000007fd60040] [size=1536 bytes]
Modules linked in: skge(OF-) raid1 nouveau video mxm_wmi i2c_algo_bit drm_kms_helper ttm drm i2c_core wmi
CPU: 1 PID: 2111 Comm: modprobe Tainted: GF O 3.11.0-0.rc4.git4.1.fc20.x86_64 #1
Hardware name: Gigabyte Technology Co., Ltd. M720-US3/M720-US3, BIOS F7n 09/07/2010
0000000000000009 ffff8800c0d85a68 ffffffff81723ef6 ffff8800c0d85ab0
ffff8800c0d85aa0 ffffffff8107462d ffff88012837c2b0 0000000000000600
000000007fd60040 000000007fd60040 0000000000000600 ffff8800c0d85b00
Call Trace:
[<ffffffff81723ef6>] dump_stack+0x54/0x74
[<ffffffff8107462d>] warn_slowpath_common+0x7d/0xa0
[<ffffffff8107469c>] warn_slowpath_fmt+0x4c/0x50
[<ffffffff81391bbc>] ? debug_dma_mapping_error+0x7c/0x90
[<ffffffff81393a07>] check_unmap+0x837/0x930
[<ffffffff811312e7>] ? rcu_irq_exit+0x77/0xc0
[<ffffffff8172d933>] ? retint_restore_args+0x13/0x13
[<ffffffff81393b5f>] debug_dma_unmap_page+0x5f/0x70
[<ffffffffa01bdc4c>] skge_rx_clean+0x7c/0xf0 [skge]
[<ffffffffa01bf315>] skge_down+0x505/0x7c0 [skge]
[<ffffffff815e7275>] __dev_close_many+0x95/0xe0
[<ffffffff815e73a8>] dev_close_many+0x88/0x100
[<ffffffff815e84b0>] rollback_registered_many+0xb0/0x220
[<ffffffff815e8651>] rollback_registered+0x31/0x40
[<ffffffff815e98e8>] unregister_netdevice_queue+0x48/0x90
[<ffffffff815e994c>] unregister_netdev+0x1c/0x30
[<ffffffffa01ba3d9>] skge_remove+0x59/0x120 [skge]
[<ffffffff813a34db>] pci_device_remove+0x3b/0xb0
[<ffffffff8148741f>] __device_release_driver+0x7f/0xf0
[<ffffffff81487dd8>] driver_detach+0xc8/0xd0
[<ffffffff81487021>] bus_remove_driver+0x91/0x120
[<ffffffff814884c2>] driver_unregister+0x62/0xa0
[<ffffffff813a25ca>] pci_unregister_driver+0x2a/0x80
[<ffffffffa01c0b70>] skge_cleanup_module+0x10/0x4a0 [skge]
[<ffffffff810f55ed>] SyS_delete_module+0x16d/0x300
[<ffffffff810e6bbd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[<ffffffff8137b24e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff81736dd9>] system_call_fastpath+0x16/0x1b
---[ end trace 02aebf528f817f06 ]---
=============================================================================
BUG skbuff_head_cache (Tainted: GF W O): Poison overwritten
=============================================================================
BUG skbuff_head_cache (Tainted: GF W O): Poison overwritten
-----------------------------------------------------------------------------
Disabling lock debugging due to kernel taint
INFO: 0xffff8801219952ec-0xffff8801219952ec. First byte 0x6a instead of 0x6b
INFO: Allocated in __alloc_skb+0x4e/0x2b0 age=157381 cpu=3 pid=1340
__slab_alloc+0x45f/0x526
kmem_cache_alloc_node+0xd8/0x3d0
__alloc_skb+0x4e/0x2b0
netlink_sendmsg+0x36a/0x750
sock_sendmsg+0x99/0xd0
SYSC_sendto+0x124/0x1d0
SyS_sendto+0xe/0x10
system_call_fastpath+0x16/0x1b
INFO: Freed in kfree_skbmem+0x37/0x90 age=157381 cpu=3 pid=1340
__slab_free+0x3a/0x382
kmem_cache_free+0x38a/0x3a0
kfree_skbmem+0x37/0x90
consume_skb+0x38/0x150
netlink_unicast+0xe5/0x190
netlink_sendmsg+0x329/0x750
sock_sendmsg+0x99/0xd0
SYSC_sendto+0x124/0x1d0
SyS_sendto+0xe/0x10
system_call_fastpath+0x16/0x1b
INFO: Slab 0xffffea0004866500 objects=28 used=28 fp=0x (null) flags=0x2ffc0000004080
INFO: Object 0xffff880121995200 @offset=4608 fp=0xffff880121996880
Bytes b4 ffff8801219951f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Object ffff880121995200: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880121995210: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880121995220: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880121995230: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880121995240: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880121995250: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880121995260: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880121995270: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880121995280: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880121995290: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8801219952a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8801219952b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8801219952c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8801219952d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8801219952e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b a5 kkkkkkkkkkkkjkk.
Redzone ffff8801219952f0: bb bb bb bb bb bb bb bb ........
Padding ffff880121995430: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
CPU: 1 PID: 1186 Comm: NetworkManager Tainted: GF B W O 3.11.0-0.rc4.git4.1.fc20.x86_64 #1
Hardware name: Gigabyte Technology Co., Ltd. M720-US3/M720-US3, BIOS F7n 09/07/2010
ffff880121995200 ffff880108e37960 ffffffff81723ef6 ffff880128ad5200
ffff880108e379a0 ffffffff811cbebd 0000000000000010 ffff880100000001
ffff8801219952ed ffff880128ad5200 000000000000006b ffff880121995200
Call Trace:
[<ffffffff81723ef6>] dump_stack+0x54/0x74
[<ffffffff811cbebd>] print_trailer+0x14d/0x200
[<ffffffff811cc0af>] check_bytes_and_report+0xcf/0x110
[<ffffffff811ccfd7>] check_object+0x1d7/0x250
[<ffffffff815db49e>] ? __alloc_skb+0x4e/0x2b0
[<ffffffff8172168d>] alloc_debug_processing+0x76/0x118
[<ffffffff81722362>] __slab_alloc+0x45f/0x526
[<ffffffff810218b9>] ? sched_clock+0x9/0x10
[<ffffffff815db49e>] ? __alloc_skb+0x4e/0x2b0
[<ffffffff815db49e>] ? __alloc_skb+0x4e/0x2b0
[<ffffffff811d0168>] kmem_cache_alloc_node+0xd8/0x3d0
[<ffffffff810e346d>] ? trace_hardirqs_off+0xd/0x10
[<ffffffff815db49e>] __alloc_skb+0x4e/0x2b0
[<ffffffff815d798e>] sock_alloc_send_pskb+0x27e/0x400
[<ffffffff8172cb47>] ? _raw_spin_unlock+0x27/0x40
[<ffffffff816b40c3>] unix_dgram_sendmsg+0x163/0x620
[<ffffffff81021845>] ? native_sched_clock+0x15/0x80
[<ffffffff815d0d79>] sock_sendmsg+0x99/0xd0
[<ffffffff810218b9>] ? sched_clock+0x9/0x10
[<ffffffff810b7845>] ? sched_clock_cpu+0xb5/0x100
[<ffffffff810e346d>] ? trace_hardirqs_off+0xd/0x10
[<ffffffff815d12d4>] SYSC_sendto+0x124/0x1d0
[<ffffffff81736e05>] ? sysret_check+0x22/0x5d
[<ffffffff810e6bbd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[<ffffffff8137b24e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff815d243e>] SyS_sendto+0xe/0x10
[<ffffffff81736dd9>] system_call_fastpath+0x16/0x1b
FIX skbuff_head_cache: Restoring 0xffff8801219952ec-0xffff8801219952ec=0x6b
FIX skbuff_head_cache: Marking all objects used
-----------------------------------------------------------------------------
INFO: 0xffff8800cf9d9bec-0xffff8800cf9d9bec. First byte 0x69 instead of 0x6b
INFO: Allocated in __alloc_skb+0x4e/0x2b0 age=131154 cpu=3 pid=2031
__slab_alloc+0x45f/0x526
kmem_cache_alloc_node+0xd8/0x3d0
__alloc_skb+0x4e/0x2b0
netlink_sendmsg+0x36a/0x750
sock_sendmsg+0x99/0xd0
___sys_sendmsg+0x39e/0x3b0
__sys_sendmsg+0x42/0x80
SyS_sendmsg+0x12/0x20
system_call_fastpath+0x16/0x1b
INFO: Freed in kfree_skbmem+0x37/0x90 age=131158 cpu=3 pid=2031
__slab_free+0x3a/0x382
kmem_cache_free+0x38a/0x3a0
kfree_skbmem+0x37/0x90
consume_skb+0x38/0x150
netlink_unicast+0xe5/0x190
netlink_sendmsg+0x329/0x750
sock_sendmsg+0x99/0xd0
___sys_sendmsg+0x39e/0x3b0
__sys_sendmsg+0x42/0x80
SyS_sendmsg+0x12/0x20
system_call_fastpath+0x16/0x1b
INFO: Slab 0xffffea00033e7600 objects=28 used=27 fp=0xffff8800cf9d98c0 flags=0x1ffc0000004080
INFO: Object 0xffff8800cf9d9b00 @offset=6912 fp=0xffff8800cf9d9f80
Bytes b4 ffff8800cf9d9af0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Object ffff8800cf9d9b00: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9b10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9b20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9b30: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9b40: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9b50: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9b60: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9b70: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9b80: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9b90: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9ba0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9bb0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9bc0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9bd0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cf9d9be0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 69 6b 6b a5 kkkkkkkkkkkkikk.
Redzone ffff8800cf9d9bf0: bb bb bb bb bb bb bb bb ........
Padding ffff8800cf9d9d30: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
CPU: 0 PID: 2111 Comm: modprobe Tainted: GF B W O 3.11.0-0.rc4.git4.1.fc20.x86_64 #1
Hardware name: Gigabyte Technology Co., Ltd. M720-US3/M720-US3, BIOS F7n 09/07/2010
ffff8800cf9d9b00 ffff8800c0d858b0 ffffffff81723ef6 ffff880128ad5200
ffff8800c0d858f0 ffffffff811cbebd 0000000000000010 ffff880000000001
ffff8800cf9d9bed ffff880128ad5200 000000000000006b ffff8800cf9d9b00
Call Trace:
[<ffffffff81723ef6>] dump_stack+0x54/0x74
[<ffffffff811cbebd>] print_trailer+0x14d/0x200
[<ffffffff811cc0af>] check_bytes_and_report+0xcf/0x110
[<ffffffff811ccfd7>] check_object+0x1d7/0x250
[<ffffffff815db49e>] ? __alloc_skb+0x4e/0x2b0
[<ffffffff8172168d>] alloc_debug_processing+0x76/0x118
[<ffffffff81722362>] __slab_alloc+0x45f/0x526
[<ffffffff815db49e>] ? __alloc_skb+0x4e/0x2b0
[<ffffffff810e3c77>] ? add_lock_to_list.isra.27.constprop.45+0x77/0xb0
[<ffffffff810e8280>] ? __lock_acquire+0x12b0/0x1b20
[<ffffffff815db49e>] ? __alloc_skb+0x4e/0x2b0
[<ffffffff811d0168>] kmem_cache_alloc_node+0xd8/0x3d0
[<ffffffff81021845>] ? native_sched_clock+0x15/0x80
[<ffffffff815db49e>] __alloc_skb+0x4e/0x2b0
[<ffffffff815f829f>] __neigh_notify+0x3f/0xe0
[<ffffffff815f969b>] neigh_cleanup_and_release+0x2b/0x50
[<ffffffff815f9da2>] neigh_flush_dev+0x1e2/0x270
[<ffffffff815f9ead>] neigh_ifdown+0x3d/0xf0
[<ffffffff8166a688>] arp_ifdown+0x18/0x20
[<ffffffff8167c0d6>] fib_disable_ip+0x36/0x40
[<ffffffff8167e112>] fib_netdev_event+0xc2/0x130
[<ffffffff81731d86>] notifier_call_chain+0x66/0x150
[<ffffffff810a7656>] raw_notifier_call_chain+0x16/0x20
[<ffffffff815e7135>] call_netdevice_notifiers_info+0x35/0x60
[<ffffffff815e73db>] dev_close_many+0xbb/0x100
[<ffffffff815e84b0>] rollback_registered_many+0xb0/0x220
[<ffffffff815e8651>] rollback_registered+0x31/0x40
[<ffffffff815e98e8>] unregister_netdevice_queue+0x48/0x90
[<ffffffff815e994c>] unregister_netdev+0x1c/0x30
[<ffffffffa01ba3d9>] skge_remove+0x59/0x120 [skge]
[<ffffffff813a34db>] pci_device_remove+0x3b/0xb0
[<ffffffff8148741f>] __device_release_driver+0x7f/0xf0
[<ffffffff81487dd8>] driver_detach+0xc8/0xd0
[<ffffffff81487021>] bus_remove_driver+0x91/0x120
[<ffffffff814884c2>] driver_unregister+0x62/0xa0
[<ffffffff813a25ca>] pci_unregister_driver+0x2a/0x80
[<ffffffffa01c0b70>] skge_cleanup_module+0x10/0x4a0 [skge]
[<ffffffff810f55ed>] SyS_delete_module+0x16d/0x300
[<ffffffff810e6bbd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[<ffffffff8137b24e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff81736dd9>] system_call_fastpath+0x16/0x1b
FIX skbuff_head_cache: Restoring 0xffff8800cf9d9bec-0xffff8800cf9d9bec=0x6b
FIX skbuff_head_cache: Marking all objects used
=============================================================================
BUG skbuff_head_cache (Tainted: GF B W O): Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xffff8800cfa947ac-0xffff8800cfa947ac. First byte 0x6a instead of 0x6b
INFO: Allocated in skb_clone+0x49/0xb0 age=157080 cpu=0 pid=82
__slab_alloc+0x45f/0x526
kmem_cache_alloc+0x2ff/0x380
skb_clone+0x49/0xb0
netlink_trim+0x7e/0xe0
netlink_unicast+0x46/0x190
kauditd_send_skb+0x2b/0x80
kauditd_thread+0xb9/0x1f0
kthread+0xed/0x100
ret_from_fork+0x7c/0xb0
INFO: Freed in kfree_skbmem+0x37/0x90 age=157083 cpu=1 pid=980
__slab_free+0x3a/0x382
kmem_cache_free+0x38a/0x3a0
kfree_skbmem+0x37/0x90
consume_skb+0x38/0x150
skb_free_datagram+0x15/0x40
netlink_recvmsg+0x147/0x390
sock_recvmsg+0xa8/0xe0
SYSC_recvfrom+0xe2/0x160
SyS_recvfrom+0xe/0x10
system_call_fastpath+0x16/0x1b
INFO: Slab 0xffffea00033ea500 objects=28 used=28 fp=0x (null) flags=0x1ffc0000004080
INFO: Object 0xffff8800cfa946c0 @offset=1728 fp=0xffff8800cfa97840
Bytes b4 ffff8800cfa946b0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Object ffff8800cfa946c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa946d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa946e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa946f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa94700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa94710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa94720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa94730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa94740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa94750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa94760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa94770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa94780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa94790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8800cfa947a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b a5 kkkkkkkkkkkkjkk.
Redzone ffff8800cfa947b0: bb bb bb bb bb bb bb bb ........
Padding ffff8800cfa948f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
CPU: 2 PID: 2112 Comm: systemd-udevd Tainted: GF B W O 3.11.0-0.rc4.git4.1.fc20.x86_64 #1
Hardware name: Gigabyte Technology Co., Ltd. M720-US3/M720-US3, BIOS F7n 09/07/2010
ffff8800cfa946c0 ffff8800cf81b8d0 ffffffff81723ef6 ffff880128ad5200
ffff8800cf81b910 ffffffff811cbebd 0000000000000010 ffff880000000001
ffff8800cfa947ad ffff880128ad5200 000000000000006b ffff8800cfa946c0
Call Trace:
[<ffffffff81723ef6>] dump_stack+0x54/0x74
[<ffffffff811cbebd>] print_trailer+0x14d/0x200
[<ffffffff811cc0af>] check_bytes_and_report+0xcf/0x110
[<ffffffff811ccfd7>] check_object+0x1d7/0x250
[<ffffffff815dc289>] ? skb_clone+0x49/0xb0
[<ffffffff8172168d>] alloc_debug_processing+0x76/0x118
[<ffffffff81722362>] __slab_alloc+0x45f/0x526
[<ffffffff810e6c8d>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff815dc289>] ? skb_clone+0x49/0xb0
[<ffffffff815d9747>] ? kfree_skbmem+0x37/0x90
[<ffffffff815dc289>] ? skb_clone+0x49/0xb0
[<ffffffff811cf49f>] kmem_cache_alloc+0x2ff/0x380
[<ffffffff815dc289>] skb_clone+0x49/0xb0
[<ffffffff8161eb81>] netlink_broadcast_filtered+0x2c1/0x370
[<ffffffff816208f8>] netlink_sendmsg+0x648/0x750
[<ffffffff815d0d79>] sock_sendmsg+0x99/0xd0
[<ffffffff811ae3cb>] ? page_add_file_rmap+0x1b/0x1a0
[<ffffffff815d119e>] ___sys_sendmsg+0x39e/0x3b0
[<ffffffff811a4385>] ? handle_mm_fault+0x2a5/0x5c0
[<ffffffff810a5b4f>] ? up_read+0x1f/0x40
[<ffffffff811fca82>] ? final_putname+0x22/0x50
[<ffffffff8120feac>] ? fget_light+0x28c/0x510
[<ffffffff815d2702>] __sys_sendmsg+0x42/0x80
[<ffffffff815d2752>] SyS_sendmsg+0x12/0x20
[<ffffffff81736dd9>] system_call_fastpath+0x16/0x1b
FIX skbuff_head_cache: Restoring 0xffff8800cfa947ac-0xffff8800cfa947ac=0x6b
FIX skbuff_head_cache: Marking all objects used
[-- Attachment #3: dmesg-t-3.11.0-0.rc4.git4.1.fc20.x86_64-nmap.txt --]
[-- Type: text/plain, Size: 2676 bytes --]
IPv6: ADDRCONF(NETDEV_CHANGE): enp1s9: link becomes ready
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2183 at lib/dma-debug.c:986 check_sync+0x4bc/0x580()
skge 0000:01:09.0: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x00000000ce550040] [size=1536 bytes]
Modules linked in: skge(OF) raid1 nouveau video mxm_wmi i2c_algo_bit drm_kms_helper ttm drm i2c_core wmi
CPU: 0 PID: 2183 Comm: nmap Tainted: GF O 3.11.0-0.rc4.git4.1.fc20.x86_64 #1
Hardware name: Gigabyte Technology Co., Ltd. M720-US3/M720-US3, BIOS F7n 09/07/2010
0000000000000009 ffff88012a603c88 ffffffff81723ef6 ffff88012a603cd0
ffff88012a603cc0 ffffffff8107462d ffff88012837c2b0 0000000000000600
ffff880128363470 00000000ce550040 ffff8800c0fb3a80 ffff88012a603d20
Call Trace:
<IRQ> [<ffffffff81723ef6>] dump_stack+0x54/0x74
[<ffffffff8107462d>] warn_slowpath_common+0x7d/0xa0
[<ffffffff8107469c>] warn_slowpath_fmt+0x4c/0x50
[<ffffffff81392d7c>] check_sync+0x4bc/0x580
[<ffffffff81392e8b>] debug_dma_sync_single_for_cpu+0x4b/0x50
[<ffffffff811cf2ad>] ? kmem_cache_alloc+0x10d/0x380
[<ffffffff810e6b6c>] ? trace_hardirqs_on_caller+0xac/0x1c0
[<ffffffff815d97d0>] ? build_skb+0x30/0x1d0
[<ffffffff815db789>] ? __netdev_alloc_skb+0x89/0xf0
[<ffffffffa01bfe1e>] skge_poll+0x39e/0x9d0 [skge]
[<ffffffff815edf81>] ? net_rx_action+0xa1/0x380
[<ffffffff815ee052>] net_rx_action+0x172/0x380
[<ffffffff8107b4a7>] __do_softirq+0x107/0x410
[<ffffffff8173873c>] call_softirq+0x1c/0x30
<EOI> [<ffffffff8101ba75>] do_softirq+0x85/0xc0
[<ffffffff81635586>] ? ip_finish_output+0x2f6/0x800
[<ffffffff8107a29b>] local_bh_enable+0xdb/0xf0
[<ffffffff81635586>] ip_finish_output+0x2f6/0x800
[<ffffffff816353c8>] ? ip_finish_output+0x138/0x800
[<ffffffff8163720c>] ip_output+0x5c/0x100
[<ffffffff81661a78>] raw_sendmsg+0x8d8/0xc50
[<ffffffff8130278d>] ? avc_has_perm_flags+0x16d/0x350
[<ffffffff81302649>] ? avc_has_perm_flags+0x29/0x350
[<ffffffff810b797f>] ? local_clock+0x5f/0x70
[<ffffffff810e3fcf>] ? lock_release_holdtime.part.28+0xf/0x1a0
[<ffffffff816727e7>] inet_sendmsg+0x117/0x230
[<ffffffff816726d5>] ? inet_sendmsg+0x5/0x230
[<ffffffff815d0d79>] sock_sendmsg+0x99/0xd0
[<ffffffff810e346d>] ? trace_hardirqs_off+0xd/0x10
[<ffffffff810e9738>] ? lock_release_non_nested+0x308/0x350
[<ffffffff815d12d4>] SYSC_sendto+0x124/0x1d0
[<ffffffff81736e05>] ? sysret_check+0x22/0x5d
[<ffffffff810e6bbd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[<ffffffff8137b24e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff815d243e>] SyS_sendto+0xe/0x10
[<ffffffff81736dd9>] system_call_fastpath+0x16/0x1b
---[ end trace 9007da55b42056f7 ]---
^ permalink raw reply
* Re: pull request for net: batman-adv 2013-08-10
From: David Miller @ 2013-08-10 22:39 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1376168881-4079-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Sat, 10 Aug 2013 23:08:00 +0200
> here you have one fix intended for net/linux-3.11.
>
> To avoid kernel paging errors, this patch takes care of re-assigning the value
> of skb->data to the related pointers after that the skb has been re-allocated.
>
> Please pull or let me know of any problem!
Pulled, thanks.
^ 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