* 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Ben Greear @ 2013-01-21 21:07 UTC (permalink / raw)
To: netdev, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
I posted about this a few days ago, but this time the patches applied
are minimal and there are no out-of-tree kernel modules loaded.
I have to have the NFS patches (see below) for this test case to run
at all.
Test case is 2500 macvlans, each with a file-IO process running
on it doing writing on it's own mountpoint. This is using NFSv4,
O_DIRECT, and 10k write() calls (and each file is 10k long, so
open/close file operations as well. Smaller files and write sizes
showed the problem as well.
The bug is most easily hit during my application's restart, where interfaces
are being (re)configured and the file-io processes are being
started. This includes changes to: IP addrs, routes, ip routing rules,
mount/unmount operations, etc.
I suspect it may be some sort of race between tearing down the IP protocol
and having traffic currently being received on that
interface. I have not been able to hit this using HTTP traffic,
but perhaps that is just part of the race and not a particular
problem with NFS.
The patches applied on top of 3.7.3 are some NFS crash fixes Trond posted
last Friday and my own patches I just posted to linux-nfs:
http://www.spinics.net/lists/linux-nfs/msg34811.html
If anyone has any suggestions for how to further debug this,
please let me know.
All of the crashes are in the same place, but the value of
the bad address changes...sometimes appears as if NULL were
dereferenced...
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/greearb/kernel/2.6/linux-3.7.x64/vmlinux...done.
(gdb) l *(ip_rcv_finish+0x2b7)
0xffffffff8149c783 is in ip_rcv_finish (/home/greearb/git/linux-3.7.dev.y/net/ipv4/ip_input.c:373).
368 skb->len);
369 } else if (rt->rt_type == RTN_BROADCAST)
370 IP_UPD_PO_STATS_BH(dev_net(rt->dst.dev), IPSTATS_MIB_INBCAST,
371 skb->len);
372
373 return dst_input(skb);
374
375 drop:
376 kfree_skb(skb);
377 return NET_RX_DROP;
(gdb) quit
IPv6: ADDRCONF(NETDEV_CHANGE): eth2#903: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): eth2#923: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): eth2#943: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): eth2#963: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): eth2#983: link becomes ready
kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
BUG: unable to handle kernel paging request at ffff88040d7d8000
IP: [<ffff88040d7d8000>] 0xffff88040d7d7fff
PGD 1a0c063 PUD df78e067 PMD 800000040d6001e3
Oops: 0011 [#1] PREEMPT SMP
Modules linked in: macvlan pktgen lockd sunrpc uinput coretemp hwmon kvm_intel kvm gpio_ich iTCO_wdt iTCO_vendor_support microcode pcspkr lpc_ich i2c_i801
e1000e ioatdma igb i7core_edac edac_core ptp pps_core dca ipv6 mgag200 i2c_algo_bit drm_kms_helper ttm drm i2c_core
CPU 6
Pid: 47, comm: ksoftirqd/6 Tainted: G C 3.7.3+ #37 Iron Systems Inc. EE2610R/X8ST3
RIP: 0010:[<ffff88040d7d8000>] [<ffff88040d7d8000>] 0xffff88040d7d7fff
RSP: 0018:ffff88040d75bc00 EFLAGS: 00010282
RAX: ffff88040435cd80 RBX: ffff8803dd83e300 RCX: ffff8803dd83e300
RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8803dd83e300
RBP: ffff88040d75bc28 R08: ffffffff8149c4cc R09: ffff88040d75bbf0
R10: dead000000200200 R11: dead000000100100 R12: ffff8803e10c88fc
R13: ffff8803dd83e300 R14: ffff88040d38e000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88041fcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff88040d7d8000 CR3: 0000000001a0b000 CR4: 00000000000007e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ksoftirqd/6 (pid: 47, threadinfo ffff88040d75a000, task ffff88040d751730)
Stack:
ffffffff8149c783 ffff8803dd83e300 ffffffff8149c4cc ffff8803dd83e300
ffff88040d38e000 ffff88040d75bc58 ffffffff8149cae8 0000000080000000
0000000000000001 ffff8803dd83e300 ffff88040d38e000 ffff88040d75bc88
Call Trace:
[<ffffffff8149c783>] ? ip_rcv_finish+0x2b7/0x2cf
[<ffffffff8149c4cc>] ? inet_del_protocol+0x37/0x37
[<ffffffff8149cae8>] NF_HOOK.clone.1+0x4c/0x53
[<ffffffff8149cd73>] ip_rcv+0x237/0x268
[<ffffffff81468c46>] __netif_receive_skb+0x487/0x530
[<ffffffff81468de5>] process_backlog+0xf6/0x1d7
[<ffffffff8146b19b>] net_rx_action+0xad/0x20c
[<ffffffff8108d292>] __do_softirq+0x9c/0x161
[<ffffffff8108d37a>] run_ksoftirqd+0x23/0x42
[<ffffffff810a6f3b>] smpboot_thread_fn+0x253/0x258
[<ffffffff810a6ce8>] ? test_ti_thread_flag.clone.0+0x11/0x11
[<ffffffff8109ff60>] kthread+0xbf/0xc7
[<ffffffff8109fea1>] ? __init_kthread_worker+0x37/0x37
[<ffffffff815292bc>] ret_from_fork+0x7c/0xb0
[<ffffffff8109fea1>] ? __init_kthread_worker+0x37/0x37
Code: 36 a4 36 6a ea 6a ea 6a ea 6a ea e9 81 e9 81 e9 81 e9 81 71 48 71 48 71 48 71 48 ea 50 ea 50 ea 50 ea 50 f7 e4 f7 e4 f7 e4 f7 e4 <22> 22 00 00 ad 4e ad de
ff ff ff ff 00 00 00 00 ff ff ff ff ff
RIP [<ffff88040d7d8000>] 0xffff88040d7d7fff
RSP <ffff88040d75bc00>
CR2: ffff88040d7d8000
---[ end trace 1c131533c1de5e8b ]---
Thanks,
Ben
--
Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v3] net, wireless: overwrite default_ethtool_ops
From: David Miller @ 2013-01-21 21:04 UTC (permalink / raw)
To: mcgrof
Cc: sgruszka, bhutchings, netdev, edumazet, greearb, bjorn,
linux-wireless, mirqus, johannes
In-Reply-To: <CAB=NE6XjvupJ5XO0EN0HVwdy61ECWL=Ey0g1gsNm+v8Sen=nsQ@mail.gmail.com>
It's queued up for -stable already as is clearly seen at:
http://patchwork.ozlabs.org/user/bundle/2566/?state=*
^ permalink raw reply
* Re: Sparse Warnings: net/ipv6/route.c:521:17: sparse: context imbalance in 'rt6_probe' - different lock contexts for basic block
From: Peter Hüwe @ 2013-01-21 20:56 UTC (permalink / raw)
To: David Miller; +Cc: yoshfuji, fengguang.wu, netdev
In-Reply-To: <20130121.154803.1415897555788515730.davem@davemloft.net>
Hi David,
Am Montag, 21. Januar 2013, 21:48:03 schrieb David Miller:
> From: Peter Hüwe <PeterHuewe@gmx.de>
> Date: Mon, 21 Jan 2013 21:03:17 +0100
>
> > Hi YOSHIFUJI,
> >
> > FYI, there are new sparse warnings show up in
> >
> > tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> > branch: master
> > head: 887c95cc1da53f66a5890fdeab13414613010097
> > commit: 2152caea719657579daa3a1a57a5425a3db6d612 [185/189] ipv6: Do not
> > depend on rt->n in rt6_probe().
> >
> >>> net/ipv6/route.c:521:17: sparse: context imbalance in 'rt6_probe' -
> >
> > different lock contexts for basic block
> >
> > On latest net-next/master it's
> > net/ipv6/route.c:500:17: warning: context imbalance in 'rt6_probe' -
> > different lock contexts for basic block
> >
> >
> > Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> > Reported-by: Peter Huewe <peterhuewe@gmx.de>
>
> This is fixed by:
>
> commit b820bb6b996966d93a5442b5fbf803ea58e7f487
> Author: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
> Date: Mon Jan 21 09:58:50 2013 +0000
Great! Thanks.
Wasn't online a few minutes ago when I checked, so sorry for the noise.
Sparse warning is gone.
Thanks
PeterH
^ permalink raw reply
* Re: [PATCH v3] net, wireless: overwrite default_ethtool_ops
From: Luis R. Rodriguez @ 2013-01-21 20:52 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: bhutchings, netdev, edumazet, greearb, bjorn, linux-wireless,
mirqus, johannes, David Miller
In-Reply-To: <20130111.155936.1799008114956712424.davem@davemloft.net>
On Fri, Jan 11, 2013 at 3:59 PM, David Miller <davem@davemloft.net> wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Fri, 11 Jan 2013 20:00:32 +0000
>
>> On Fri, 2013-01-11 at 10:19 +0100, Stanislaw Gruszka wrote:
>>> Since:
>>>
>>> commit 2c60db037034d27f8c636403355d52872da92f81
>>> Author: Eric Dumazet <edumazet@google.com>
>>> Date: Sun Sep 16 09:17:26 2012 +0000
>>>
>>> net: provide a default dev->ethtool_ops
>>>
>>> wireless core does not correctly assign ethtool_ops.
>>>
>>> After alloc_netdev*() call, some cfg80211 drivers provide they own
>>> ethtool_ops, but some do not. For them, wireless core provide generic
>>> cfg80211_ethtool_ops, which is assigned in NETDEV_REGISTER notify call:
>>>
>>> if (!dev->ethtool_ops)
>>> dev->ethtool_ops = &cfg80211_ethtool_ops;
>>>
>>> But after Eric's commit, dev->ethtool_ops is no longer NULL (on cfg80211
>>> drivers without custom ethtool_ops), but points to &default_ethtool_ops.
>>>
>>> In order to fix the problem, provide function which will overwrite
>>> default_ethtool_ops and use it by wireless core.
>>>
>>> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
>> [...]
>>
>> Acked-by: Ben Hutchings <bhutchings@solarflare.com>
>
> Applied.
Stanislaw, I see Eric's patch went in on v3.7-rc1 as such I suspect
this needs to be submitted as a stable fix for v3.7.5. Its already on
v3.8-rc4.
mcgrof@frijol ~/linux-stable (git::linux-3.7.y)$ git describe
--contains 2c60db037034d27f8c636403355d52872da92f81
v3.7-rc1~145^2~142
Luis
^ permalink raw reply
* Re: Sparse Warnings: net/ipv6/route.c:521:17: sparse: context imbalance in 'rt6_probe' - different lock contexts for basic block
From: David Miller @ 2013-01-21 20:48 UTC (permalink / raw)
To: PeterHuewe; +Cc: yoshfuji, fengguang.wu, netdev
In-Reply-To: <201301212103.18066.PeterHuewe@gmx.de>
From: Peter Hüwe <PeterHuewe@gmx.de>
Date: Mon, 21 Jan 2013 21:03:17 +0100
> Hi YOSHIFUJI,
>
> FYI, there are new sparse warnings show up in
>
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> branch: master
> head: 887c95cc1da53f66a5890fdeab13414613010097
> commit: 2152caea719657579daa3a1a57a5425a3db6d612 [185/189] ipv6: Do not depend
> on rt->n in rt6_probe().
>
>>> net/ipv6/route.c:521:17: sparse: context imbalance in 'rt6_probe' -
> different lock contexts for basic block
>
> On latest net-next/master it's
> net/ipv6/route.c:500:17: warning: context imbalance in 'rt6_probe' - different
> lock contexts for basic block
>
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Reported-by: Peter Huewe <peterhuewe@gmx.de>
This is fixed by:
commit b820bb6b996966d93a5442b5fbf803ea58e7f487
Author: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Date: Mon Jan 21 09:58:50 2013 +0000
ndisc: Do not try to update "updated" time if neighbour has already gone.
Commit 2152caea ("ipv6: Do not depend on rt->n in rt6_probe().")
introduce a bug to try to update "updated" time in neighbour
structure.
Update the "updated" time only if neighbour is available.
Bug was found by Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 2d94d5a..f3328bc 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -492,10 +492,10 @@ static void rt6_probe(struct rt6_info *rt)
struct in6_addr mcaddr;
struct in6_addr *target;
- neigh->updated = jiffies;
-
- if (neigh)
+ if (neigh) {
+ neigh->updated = jiffies;
write_unlock(&neigh->lock);
+ }
target = (struct in6_addr *)&rt->rt6i_gateway;
addrconf_addr_solict_mult(target, &mcaddr);
^ permalink raw reply related
* Re: [PATCH 01/21] NTB: correct missing readq/writeq errors
From: Greg KH @ 2013-01-21 20:47 UTC (permalink / raw)
To: Ben Hutchings
Cc: Jon Mason, linux-kernel, netdev, Dave Jiang, Nicholas Bellinger
In-Reply-To: <1358800493.3758.10.camel@bwh-desktop.uk.solarflarecom.com>
On Mon, Jan 21, 2013 at 08:34:53PM +0000, Ben Hutchings wrote:
> On Mon, 2013-01-21 at 10:23 -0800, Greg KH wrote:
> > On Mon, Jan 21, 2013 at 10:38:18AM -0700, Jon Mason wrote:
> > > On Sun, Jan 20, 2013 at 03:40:05PM -0800, Greg KH wrote:
> > > > On Sat, Jan 19, 2013 at 02:02:15AM -0700, Jon Mason wrote:
> > > > > Atomic readq and writeq do not exist by default on some 32bit
> > > > > architectures, thus causing compile errors due to non-existent symbols.
> > > > > In those cases, use the definitions of those symbols from
> > > > > include/asm-generic/io-64-nonatomic-hi-lo.h
> > > > >
> > > > > Signed-off-by: Jon Mason <jon.mason@intel.com>
> > > > > ---
> > > > > drivers/ntb/ntb_hw.c | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> > > > > index 4c71b17..0b46fef 100644
> > > > > --- a/drivers/ntb/ntb_hw.c
> > > > > +++ b/drivers/ntb/ntb_hw.c
> > > > > @@ -45,6 +45,7 @@
> > > > > * Contact Information:
> > > > > * Jon Mason <jon.mason@intel.com>
> > > > > */
> > > > > +#include <asm-generic/io-64-nonatomic-hi-lo.h>
> > > >
> > > > Really? This seems really odd. Usually we just don't build the code
> > > > for any platform that doesn't have readq/writeq. Otherwise, shouldn't
> > > > those arches just include this file themselves to keep everything
> > > > working? Individual drivers shouldn't have to do this.
> > >
> > > There is no readq/writeq for 32bit x86. I was using this header file
> > > to get around that. I freely admit that I have done 0 testing on
> > > 32bit, but it should work. If you prefer I modify the Kconfig to only
> > > enable this for x86_64 until such time as I test on x86_32, I will
> > > happily submit that patch.
> >
> > No, other drivers on 32bit x86 also use readq,
>
> I don't think so, because it's not defined for CONFIG_X86_32.
Ah, you are right, I was confused by drivers/char/hpet.c, which used
readq, but only on 64bit processors.
Jon, as you say you never tested this on 32bit processors, I'd recommend
just making the Kconfig file enforce that and only build on x86-64 for
now.
thanks,
greg k-h
^ permalink raw reply
* Re: [Patch net-next] net: move rx and tx hash functions to net/core/flow_dissector.c
From: David Miller @ 2013-01-21 20:46 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, edumazet, bhutchings
In-Reply-To: <1358764764-3533-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 21 Jan 2013 18:39:24 +0800
> From: Cong Wang <xiyou.wangcong@gmail.com>
>
> __skb_tx_hash() and __skb_get_rxhash() are all for calculating hash
> value based by some fields in skb, mostly used for selecting queues
> by device drivers.
>
> Meanwhile, net/core/dev.c is bloating.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Ben Hutchings <bhutchings@solarflare.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 4/15] drivers/net/ethernet/sfc/ptp.c: adjust duplicate test
From: David Miller @ 2013-01-21 20:45 UTC (permalink / raw)
To: Julia.Lawall
Cc: linux-net-drivers, kernel-janitors, bhutchings, netdev,
linux-kernel
In-Reply-To: <1358773378-4700-5-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Mon, 21 Jan 2013 14:02:48 +0100
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Delete successive tests to the same location. rc was previously tested and
> not subsequently updated. efx_phc_adjtime can return an error code, so the
> call is updated so that is tested instead.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied to net-next, thanks.
^ permalink raw reply
* Re: Rate Limitation of Router Reachability Probing for possible dead routers (is Re: ipv6: Do not depend on rt->n in rt6_probe().)
From: David Miller @ 2013-01-21 20:44 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <50FD96E4.1020607@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Tue, 22 Jan 2013 04:28:36 +0900
> Ok, fix is easy, but in fact, we have broken router reachability
> probing.
>
> Here rt->n was neighbour entry for (unreachable) router.
> The specification says, we SHOUDLD probe such router, but we
> should have some rate limit (once per minute, or so).
>
> We used "rt->n->updated" for this purpose, but now, if NS failed,
> we may immediately removes neighbour entry for it. So,
> we might continue sending NS to dead router every 1 second.
>
> Any ideas?
I don't see exactly how looking up the neigh on demand is different
from using a cached one in this context.
In both cases there should be a neigh entry in nd_tbl, why would
there not be one?
If necessary, you can decide to mark entries in such a way that
they would have a lower priority for neigh GC purging if that
is the issue.
^ permalink raw reply
* Re: [PATCH net-next] ndisc: Do not try to update "updated" time if neighbour has already gone.
From: David Miller @ 2013-01-21 20:42 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, dan.carpenter
In-Reply-To: <50FD9DFA.6090001@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Tue, 22 Jan 2013 04:58:50 +0900
> Commit 2152caea ("ipv6: Do not depend on rt->n in rt6_probe().")
> introduce a bug to try to update "updated" time in neighbour
> structure.
> Update the "updated" time only if neighbour is available.
>
> Bug was found by Dan Carpenter <dan.carpenter@oracle.com>
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] dsa: bug fixes
From: David Miller @ 2013-01-21 20:41 UTC (permalink / raw)
To: florian; +Cc: netdev, buytenh, konszert
In-Reply-To: <1358798331-13055-1-git-send-email-florian@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Mon, 21 Jan 2013 20:58:49 +0100
> These two patches are non-critical bugfixes based on net-next which I
> stumbled upon while working on Device Tree bindings for DSA (will comme
> as a separate patch later).
>
> Florian Fainelli (2):
> dsa: use an unique and non conflicting bus name for the slave MII bus
> dsa: make dsa_switch_setup check for valid port names
This looks fine to me, all applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 01/21] NTB: correct missing readq/writeq errors
From: Ben Hutchings @ 2013-01-21 20:34 UTC (permalink / raw)
To: Greg KH; +Cc: Jon Mason, linux-kernel, netdev, Dave Jiang, Nicholas Bellinger
In-Reply-To: <20130121182345.GC5499@kroah.com>
On Mon, 2013-01-21 at 10:23 -0800, Greg KH wrote:
> On Mon, Jan 21, 2013 at 10:38:18AM -0700, Jon Mason wrote:
> > On Sun, Jan 20, 2013 at 03:40:05PM -0800, Greg KH wrote:
> > > On Sat, Jan 19, 2013 at 02:02:15AM -0700, Jon Mason wrote:
> > > > Atomic readq and writeq do not exist by default on some 32bit
> > > > architectures, thus causing compile errors due to non-existent symbols.
> > > > In those cases, use the definitions of those symbols from
> > > > include/asm-generic/io-64-nonatomic-hi-lo.h
> > > >
> > > > Signed-off-by: Jon Mason <jon.mason@intel.com>
> > > > ---
> > > > drivers/ntb/ntb_hw.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> > > > index 4c71b17..0b46fef 100644
> > > > --- a/drivers/ntb/ntb_hw.c
> > > > +++ b/drivers/ntb/ntb_hw.c
> > > > @@ -45,6 +45,7 @@
> > > > * Contact Information:
> > > > * Jon Mason <jon.mason@intel.com>
> > > > */
> > > > +#include <asm-generic/io-64-nonatomic-hi-lo.h>
> > >
> > > Really? This seems really odd. Usually we just don't build the code
> > > for any platform that doesn't have readq/writeq. Otherwise, shouldn't
> > > those arches just include this file themselves to keep everything
> > > working? Individual drivers shouldn't have to do this.
> >
> > There is no readq/writeq for 32bit x86. I was using this header file
> > to get around that. I freely admit that I have done 0 testing on
> > 32bit, but it should work. If you prefer I modify the Kconfig to only
> > enable this for x86_64 until such time as I test on x86_32, I will
> > happily submit that patch.
>
> No, other drivers on 32bit x86 also use readq,
I don't think so, because it's not defined for CONFIG_X86_32.
> and do not include this
> asm header file. So there is a proper way to do this, just dig through
> the header file include mess to determine the proper one to include.
> You should never have to include asm-generic file directly, that's the
> issue here.
Different devices can have different requirements for the order of
access to 32-bit halves of a 64-bit register. Only the driver knows
which is right.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net 0/3] cdc_ncm and cdc_mbim fixes for 3.8
From: Alexey Orishko @ 2013-01-21 20:34 UTC (permalink / raw)
To: Bjørn Mork
Cc: Alexey ORISHKO, David Miller, netdev@vger.kernel.org,
linux-usb@vger.kernel.org, gsuarez@smithmicro.com,
oneukum@suse.de
In-Reply-To: <f47edcc4-cda9-4349-9590-ee8572b139ca@email.android.com>
On Mon, Jan 21, 2013 at 9:16 PM, Bjørn Mork <bjorn@mork.no> wrote:
> Alexey ORISHKO <alexey.orishko@stericsson.com> wrote:
>
>
> There are still a couple of questions I am wondering about though. The most important one: what is Windows 8 doing different from us? Does anyone know? I do not have a Windows 8 system myself and I wouldn't know how to snoop on it either.
>
Are you talking about bulk data? They have their own bugs :-) looks
like can't handle divisor/remainder in NTB right.
If you want, I can send you Ellisys log.
Regards,
Alexey
^ permalink raw reply
* Re: [PATCH 20/33] net: Convert to devm_ioremap_resource()
From: David Miller @ 2013-01-21 20:29 UTC (permalink / raw)
To: thierry.reding
Cc: linux-kernel, gregkh, dmitry.torokhov, arnd, w.sang, netdev
In-Reply-To: <1358762966-20791-21-git-send-email-thierry.reding@avionic-design.de>
From: Thierry Reding <thierry.reding@avionic-design.de>
Date: Mon, 21 Jan 2013 11:09:13 +0100
> Convert all uses of devm_request_and_ioremap() to the newly introduced
> devm_ioremap_resource() which provides more consistent error handling.
>
> devm_ioremap_resource() provides its own error messages so all explicit
> error messages can be removed from the failure code paths.
>
> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
This won't compile if I apply it.
You really have to be clear when you submit patches like this.
Since you only CC:'d the networking developers for this one
patch, there is _ZERO_ context for us to work with to understand
what's going on.
You have to also CC: us on the other relevant changes and your
"[PATCH 00/33]" posting that explains what is happening.
^ permalink raw reply
* RE: [PATCH net 0/3] cdc_ncm and cdc_mbim fixes for 3.8
From: Bjørn Mork @ 2013-01-21 20:16 UTC (permalink / raw)
To: Alexey ORISHKO, David Miller
Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org,
gsuarez@smithmicro.com, oneukum@suse.de, Alexey Orishko
In-Reply-To: <2AC7D4AD8BA1C640B4C60C61C8E520154A8EE17D99@EXDCVYMBSTM006.EQ1STM.local>
Alexey ORISHKO <alexey.orishko@stericsson.com> wrote:
>> -----Original Message-----
>> From: David Miller [mailto:davem@davemloft.net]
>> Sent: Monday, January 21, 2013 8:23 PM
>> To: bjorn@mork.no
>> Cc: netdev@vger.kernel.org; linux-usb@vger.kernel.org;
>> gsuarez@smithmicro.com; Alexey ORISHKO; oneukum@suse.de
>> Subject: Re: [PATCH net 0/3] cdc_ncm and cdc_mbim fixes for 3.8
>>
>> From: Bjørn Mork <bjorn@mork.no>
>> Date: Mon, 21 Jan 2013 16:50:37 +0100
>>
>> > The 2 first patches in this series are required to make the Sierra
>> > Wireless MC7710 card work in MBIM mode. They may also be required
>> for
>> > other Qualcomm firmware based MBIM devices.
>> >
>> > Patch #1 was previously posted as a standalone patch. This version
>> is
>> > a replacement, removing a theoretical NULL pointer exception.
>> >
>> > Patch #3 fixes a bug I introduced in v3.7
>>
>> All applied, thanks.
>
>Hi David,
>
>It was way too fast... I don't think we concluded on patch#2 since it
>will damage existing devices :-(
Yes, that was even faster than expected. But it's no problem really. I'll prepare a fixup patch reducing it to be device specific.
There are still a couple of questions I am wondering about though. The most important one: what is Windows 8 doing different from us? Does anyone know? I do not have a Windows 8 system myself and I wouldn't know how to snoop on it either.
Bjørn
^ permalink raw reply
* [PATCH 1/2] dsa: use an unique and non conflicting bus name for the slave MII bus
From: Florian Fainelli @ 2013-01-21 19:58 UTC (permalink / raw)
To: netdev; +Cc: buytenh, konszert, davem, Florian Fainelli
In-Reply-To: <1358798331-13055-1-git-send-email-florian@openwrt.org>
The slave MII bus registered by the DSA code is using the parent MII bus
as part of its name (ds->master_mii_bus_id), in case the parent MII bus
name is already 16 characters long (such as d0072004.mdio-mi) we will
get the following WARN_ON in dsa_switch_setup() when calling
mdiobus_register():
[ 79.088782] ------------[ cut here ]------------
[ 79.093448] WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0x80/0xa0()
[ 79.099831] sysfs: cannot create duplicate filename
'/class/mdio_bus/d0072004.mdio-mi'
This is a genuine warning, because the DSA slave MII bus will also be
named d0072004.mdio-mi, and since MII_BUS_ID_SIZE is 17 characters long
(with null-terminator) the following will truncate the slave MII bus id:
snprintf(ds->slave_mii_bus->id, MII_BUS_ID_SIZE, "%s-%d:%.2x",
ds->master_mii_bus->id, ds->pd->sw_addr);
Fix this by using dsa-<switch index->:<sw_add> which is guaranteed to be
unique.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
net/dsa/slave.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index f434558..6ebd8fb 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -41,8 +41,8 @@ void dsa_slave_mii_bus_init(struct dsa_switch *ds)
ds->slave_mii_bus->name = "dsa slave smi";
ds->slave_mii_bus->read = dsa_slave_phy_read;
ds->slave_mii_bus->write = dsa_slave_phy_write;
- snprintf(ds->slave_mii_bus->id, MII_BUS_ID_SIZE, "%s:%.2x",
- ds->master_mii_bus->id, ds->pd->sw_addr);
+ snprintf(ds->slave_mii_bus->id, MII_BUS_ID_SIZE, "dsa-%d:%.2x",
+ ds->index, ds->pd->sw_addr);
ds->slave_mii_bus->parent = &ds->master_mii_bus->dev;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] dsa: make dsa_switch_setup check for valid port names
From: Florian Fainelli @ 2013-01-21 19:58 UTC (permalink / raw)
To: netdev; +Cc: buytenh, konszert, davem, Florian Fainelli
In-Reply-To: <1358798331-13055-1-git-send-email-florian@openwrt.org>
This patch changes dsa_switch_setup() to ensure that at least one valid
valid port name is specified and will bail out with an error in case we
walked the maximum number of port with a valid port name found.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
net/dsa/dsa.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 45295ca..2bc62ea 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -80,6 +80,7 @@ dsa_switch_setup(struct dsa_switch_tree *dst, int index,
int ret;
char *name;
int i;
+ bool valid_name_found = false;
/*
* Probe for switch model.
@@ -131,8 +132,13 @@ dsa_switch_setup(struct dsa_switch_tree *dst, int index,
} else {
ds->phys_port_mask |= 1 << i;
}
+ valid_name_found = true;
}
+ if (!valid_name_found && i == DSA_MAX_PORTS) {
+ ret = -EINVAL;
+ goto out;
+ }
/*
* If the CPU connects to this switch, set the switch tree
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] dsa: bug fixes
From: Florian Fainelli @ 2013-01-21 19:58 UTC (permalink / raw)
To: netdev; +Cc: buytenh, konszert, davem, Florian Fainelli
Hello David, Lennert,
These two patches are non-critical bugfixes based on net-next which I
stumbled upon while working on Device Tree bindings for DSA (will comme
as a separate patch later).
Florian Fainelli (2):
dsa: use an unique and non conflicting bus name for the slave MII bus
dsa: make dsa_switch_setup check for valid port names
net/dsa/dsa.c | 6 ++++++
net/dsa/slave.c | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
--
1.7.10.4
^ permalink raw reply
* Sparse Warnings: net/ipv6/route.c:521:17: sparse: context imbalance in 'rt6_probe' - different lock contexts for basic block
From: Peter Hüwe @ 2013-01-21 20:03 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: Fengguang Wu, netdev
Hi YOSHIFUJI,
FYI, there are new sparse warnings show up in
tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
branch: master
head: 887c95cc1da53f66a5890fdeab13414613010097
commit: 2152caea719657579daa3a1a57a5425a3db6d612 [185/189] ipv6: Do not depend
on rt->n in rt6_probe().
>> net/ipv6/route.c:521:17: sparse: context imbalance in 'rt6_probe' -
different lock contexts for basic block
On latest net-next/master it's
net/ipv6/route.c:500:17: warning: context imbalance in 'rt6_probe' - different
lock contexts for basic block
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Peter Huewe <peterhuewe@gmx.de>
Thanks,
Peter
^ permalink raw reply
* [PATCH net-next] ndisc: Do not try to update "updated" time if neighbour has already gone.
From: YOSHIFUJI Hideaki @ 2013-01-21 19:58 UTC (permalink / raw)
To: davem; +Cc: yoshfuji, netdev, Dan Carpenter
Commit 2152caea ("ipv6: Do not depend on rt->n in rt6_probe().")
introduce a bug to try to update "updated" time in neighbour
structure.
Update the "updated" time only if neighbour is available.
Bug was found by Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
net/ipv6/route.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 2d94d5a..f3328bc 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -492,10 +492,10 @@ static void rt6_probe(struct rt6_info *rt)
struct in6_addr mcaddr;
struct in6_addr *target;
- neigh->updated = jiffies;
-
- if (neigh)
+ if (neigh) {
+ neigh->updated = jiffies;
write_unlock(&neigh->lock);
+ }
target = (struct in6_addr *)&rt->rt6i_gateway;
addrconf_addr_solict_mult(target, &mcaddr);
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
From: YOSHIFUJI Hideaki @ 2013-01-21 19:57 UTC (permalink / raw)
To: stephan.gatzka
Cc: Stefan Richter, netdev, linux1394-devel, David Miller,
YOSHIFUJI Hideaki
In-Reply-To: <50FD962B.8020500@gmail.com>
Stephan Gatzka wrote:
>
>> Two net_device instances on one 1394 card would be awkward: They would
>> have to share one instance of isochronous reception context (for reception
>> of asynchronous 1394 streams; those are used for broadcasts and
>> multicasts). Such a sharing is surely possible, but if double net_device
>> instantiation can be avoided, then avoid it.
>>
>> Not to mention the user interface problem of having two netifs, one which
>> only supports IPv4 and another one which only supports IPv6. So far I
>> never had IPv6 configured into a Linux kernel, but I suppose that folks
>> are used to be able to use eth0 etc. for both protocols.
>
> Full ack. And that's the reason why I feel very uncomfortable with a Yoshifujis hardware address extensions by fifo_addr, spd, and max_rec.
>
> This seems possible with a single netdevice for IPv4/6 only if we _always_ use the same fifo address for both IPv4 and IPv6. Do we all agree on that?
I do not understand what "that" and "this" mean here.
Do you want to have different FIFO on single net_device? If yes, for what?
--yoshfuji
^ permalink raw reply
* Re: [PATCH 4/15] drivers/net/ethernet/sfc/ptp.c: adjust duplicate test
From: Ben Hutchings @ 2013-01-21 19:47 UTC (permalink / raw)
To: Julia Lawall
Cc: Solarflare linux maintainers, kernel-janitors, netdev,
linux-kernel
In-Reply-To: <1358773378-4700-5-git-send-email-Julia.Lawall@lip6.fr>
On Mon, 2013-01-21 at 14:02 +0100, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Delete successive tests to the same location. rc was previously tested and
> not subsequently updated. efx_phc_adjtime can return an error code, so the
> call is updated so that is tested instead.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @s exists@
> local idexpression y;
> expression x,e;
> @@
>
> *if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
> { ... when forall
> return ...; }
> ... when != \(y = e\|y += e\|y -= e\|y |= e\|y &= e\|y++\|y--\|&y\)
> when != \(XT_GETPAGE(...,y)\|WMI_CMD_BUF(...)\)
> *if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
> { ... when forall
> return ...; }
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> Not tested. I'm not familiar with this function, so I don't know whether it
> is desirable to test its result.
Yes, the result should be tested. Thanks.
Ben.
> drivers/net/ethernet/sfc/ptp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/sfc/ptp.c b/drivers/net/ethernet/sfc/ptp.c
> index 0767043..3f93624 100644
> --- a/drivers/net/ethernet/sfc/ptp.c
> +++ b/drivers/net/ethernet/sfc/ptp.c
> @@ -1439,7 +1439,7 @@ static int efx_phc_settime(struct ptp_clock_info *ptp,
>
> delta = timespec_sub(*e_ts, time_now);
>
> - efx_phc_adjtime(ptp, timespec_to_ns(&delta));
> + rc = efx_phc_adjtime(ptp, timespec_to_ns(&delta));
> if (rc != 0)
> return rc;
>
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [PATCH net 0/3] cdc_ncm and cdc_mbim fixes for 3.8
From: Alexey ORISHKO @ 2013-01-21 19:42 UTC (permalink / raw)
To: David Miller, bjorn@mork.no
Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org,
gsuarez@smithmicro.com, oneukum@suse.de, Alexey Orishko
In-Reply-To: <20130121.142242.2240250911008731906.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, January 21, 2013 8:23 PM
> To: bjorn@mork.no
> Cc: netdev@vger.kernel.org; linux-usb@vger.kernel.org;
> gsuarez@smithmicro.com; Alexey ORISHKO; oneukum@suse.de
> Subject: Re: [PATCH net 0/3] cdc_ncm and cdc_mbim fixes for 3.8
>
> From: Bjørn Mork <bjorn@mork.no>
> Date: Mon, 21 Jan 2013 16:50:37 +0100
>
> > The 2 first patches in this series are required to make the Sierra
> > Wireless MC7710 card work in MBIM mode. They may also be required
> for
> > other Qualcomm firmware based MBIM devices.
> >
> > Patch #1 was previously posted as a standalone patch. This version
> is
> > a replacement, removing a theoretical NULL pointer exception.
> >
> > Patch #3 fixes a bug I introduced in v3.7
>
> All applied, thanks.
Hi David,
It was way too fast... I don't think we concluded on patch#2 since it
will damage existing devices :-(
Regards,
alexey
^ permalink raw reply
* Rate Limitation of Router Reachability Probing for possible dead routers (is Re: ipv6: Do not depend on rt->n in rt6_probe().)
From: YOSHIFUJI Hideaki @ 2013-01-21 19:28 UTC (permalink / raw)
To: David Miller; +Cc: YOSHIFUJI Hideaki, netdev
In-Reply-To: <50FD8BC6.1030509@linux-ipv6.org>
(2013年01月22日 03:41), YOSHIFUJI Hideaki wrote:
> (2013年01月22日 03:28), Dan Carpenter wrote:
>> Hello YOSHIFUJI Hideaki / 吉藤英明,
>>
>> This is a semi-automatic email about new static checker warnings.
>>
>> The patch 2152caea7196: "ipv6: Do not depend on rt->n in
>> rt6_probe()." from Jan 17, 2013, leads to the following Smatch
>> complaint:
>>
>> net/ipv6/route.c:495 rt6_probe()
>> error: we previously assumed 'neigh' could be null (see line 490)
>>
>> net/ipv6/route.c
>> 489
>> 490 if (!neigh ||
>> ^^^^^
>> New test.
>>
>> 491 time_after(jiffies, neigh->updated + rt->rt6i_idev->cnf.rtr_probe_interval)) {
>> 492 struct in6_addr mcaddr;
>> 493 struct in6_addr *target;
>> 494
>> 495 neigh->updated = jiffies;
>> ^^^^^^^^^^^^^^
>> Old dereference.
>>
>> 496
>> 497 if (neigh)
>> ^^^^^
>> Another new test.
>
> Oh, right, I'll fix. Thanks!
Ok, fix is easy, but in fact, we have broken router reachability
probing.
Here rt->n was neighbour entry for (unreachable) router.
The specification says, we SHOUDLD probe such router, but we
should have some rate limit (once per minute, or so).
We used "rt->n->updated" for this purpose, but now, if NS failed,
we may immediately removes neighbour entry for it. So,
we might continue sending NS to dead router every 1 second.
Any ideas?
--yoshfuji
^ permalink raw reply
* Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
From: Stephan Gatzka @ 2013-01-21 19:25 UTC (permalink / raw)
To: Stefan Richter; +Cc: YOSHIFUJI Hideaki, netdev, linux1394-devel, David Miller
In-Reply-To: <20130121083957.6e2c5a68@stein>
> Two net_device instances on one 1394 card would be awkward: They would
> have to share one instance of isochronous reception context (for reception
> of asynchronous 1394 streams; those are used for broadcasts and
> multicasts). Such a sharing is surely possible, but if double net_device
> instantiation can be avoided, then avoid it.
>
> Not to mention the user interface problem of having two netifs, one which
> only supports IPv4 and another one which only supports IPv6. So far I
> never had IPv6 configured into a Linux kernel, but I suppose that folks
> are used to be able to use eth0 etc. for both protocols.
Full ack. And that's the reason why I feel very uncomfortable with a
Yoshifujis hardware address extensions by fifo_addr, spd, and max_rec.
This seems possible with a single netdevice for IPv4/6 only if we
_always_ use the same fifo address for both IPv4 and IPv6. Do we all
agree on that?
Stephan
^ 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