* Re: [PATCH] net/ieee802154/6lowpan: Fix initialization for fragment offset
From: Alan Ott @ 2013-03-13 15:45 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
Linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <D859EF9A-19A9-4F74-B59D-28FADBCE338A-G+tS6SCNB47quOJu9mQKZg@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1280 bytes --]
On 03/13/2013 10:40 AM, Wolf-Bastian Pöttner wrote:
> Nope. The patch fixes a problem in code that is not in mainline yet. However, people on the linux-zigbee mailing list found it a good idea to commit this change to mainline to avoid the problem from arising.
>
> I see, you disagree. Nevermind. ;)
Hi David,
This is my fault. I must have been looking the wrong tree when I
recommended a push to mainline.
Sorry for the noise.
Alan.
> Am 13.03.2013 um 15:38 schrieb David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>:
>> > From: Wolf-Bastian Pöttner <poettner-G+tS6SCNB47quOJu9mQKZg@public.gmane.org>
>> > Date: Wed, 13 Mar 2013 08:50:54 +0100
>> >
>>> >> offset has to be initialized, otherwise the *first* fragment will
>>> >> be discarded and reassembly cannot happen.
>>> >>
>>> >> Reviewed-by: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
>> >
>> > 'offset' is never used unless lowpan_fetch_skb_u8(skb, &offset)
>> > succeeds, in which case it will be initialized properly. Otherwise we
>> > unlock and drop the SKB and make no references whatsoever to 'offset'.
>> >
>> > I suspect you saw some compiler warning about 'offset' being
>> > uninitialized, and are just blindly trying to shut this warning up.
>
[-- Attachment #1.2: Type: text/html, Size: 3615 bytes --]
[-- Attachment #2: Type: text/plain, Size: 238 bytes --]
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
[-- Attachment #3: Type: text/plain, Size: 213 bytes --]
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
^ permalink raw reply
* Re: [PATCH net-next 0/4] Allow bridge to function in non-promisc mode
From: Vlad Yasevich @ 2013-03-13 15:45 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
Oleg A. Arkhangelsky
In-Reply-To: <20130313083932.6483876f@nehalam.linuxnetplumber.net>
On 03/13/2013 11:39 AM, Stephen Hemminger wrote:
> On Wed, 13 Mar 2013 08:12:29 -0400
> Vlad Yasevich <vyasevic@redhat.com> wrote:
>
>> On 03/13/2013 02:22 AM, "Oleg A. Arkhangelsky" wrote:
>>>
>>>
>>> 13.03.2013, 05:45, "Vlad Yasevich" <vyasevic@redhat.com>:
>>>
>>>> The series adds an ability for the bridge to function in non-promiscuous mode.
>>>
>>> What is the practical applications for such setup? In other words,
>>> in which cases I would want to put bridge into non-promiscuous
>>> mode and specify some uplink ports?
>>>
>>
>> On of the applications would be when bridge is an edge device servicing
>> a VM deployment. Each of the VMs knows the mac address that the guest
>> has and may program that mac onto the uplinks.
>
> Why wouldn't that environment just use macvlan?
> Is it because changing libvirt is harder than changing the kernel?
>
No, because macvlan has a drawback that it doesn't easily let guests
talk to the host. Bridge is still most commonly used for just that reason.
-vlad
^ permalink raw reply
* Re: [PATCH net-next 1/4] bridge: Add sysfs interface to control promisc mode
From: Vlad Yasevich @ 2013-03-13 15:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, bridge
In-Reply-To: <20130313083843.411b3a6c@nehalam.linuxnetplumber.net>
On 03/13/2013 11:38 AM, Stephen Hemminger wrote:
> On Tue, 12 Mar 2013 21:45:23 -0400
> Vlad Yasevich <vyasevic@redhat.com> wrote:
>
>> Add an sysfs interface to turn promiscusous mode on and off on
>> the bridge. By default all interfaces in the bridge
>> are in promisc mode. When promisc mode is turned off, it is
>> turned off on all bridge ports and the bridge turns on IFF_ALLMULTI
>> to handle multicast traffic.
>>
>> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
>> ---
>> net/bridge/br_device.c | 41 +++++++++++++++++++++++++++++++++++++++++
>> net/bridge/br_if.c | 22 +++++++++++++++++-----
>> net/bridge/br_private.h | 2 ++
>> net/bridge/br_sysfs_br.c | 17 +++++++++++++++++
>> 4 files changed, 77 insertions(+), 5 deletions(-)
>>
>
> All attribute changes must also be available through netlink, and changes
> to attributes should cause a notification to applications listening for
> netlink events on that bridge.
>
There is currently no attribute for promisc vs non-promisc in the
bridge. Are you suggesting that this patch should add one?
-vlad
^ permalink raw reply
* RE: [PATCH net-next 05/22] cxgb4: Add T5 write combining support
From: David Laight @ 2013-03-13 15:43 UTC (permalink / raw)
To: Vipul Pandya, Steve Wise
Cc: David Miller, netdev, linux-rdma, linux-scsi, roland, JBottomley,
Dimitrios Michailidis, Casey Leedom, Naresh Kumar Inna,
Divy Le Ray, Santosh Rastapur, Arvind Bhushan, Abhishek Agrawal
In-Reply-To: <51408ED4.40400@chelsio.com>
> >>> + writel(n, adap->bar2 + q->udb + 8);
> >>> +#if defined(CONFIG_X86_32) || defined(CONFIG_X86_64)
> >>> + asm volatile("sfence" : : : "memory");
> >>> +#endif
> >> There is absolutely no way I'm letting anyone put crap like this
> >> into a driver.
> >>
> >> Use a portable inteface, and if one does not exist create one.
> >
> > I guess you'll have to add a wc_wmb() function for all the hw platforms
> > supported by the kernel. I see libibverbs defines this for the user
> > side in include/infiniband/arch.h, and that could be used as the meat of
> > the hw platform-specific implementations.
> >
> I see that normal wmb() code for x86_64 architecture is same as what
> above #ifdef condition is doing. To be more clear I looked at the
> assembly code for wmb and find that it is converted into 'sfence'
> instruction. So, I think above code should be replaced with wmb call
> which will also take care of portability on different architecture. I
> will submit the series again soon.
>From my recollection of the x86 architecture, the memory barriers
are hardly ever needed, certainly not in the places where, for example
a ppc needs them. I'd actually suspect that the normal wmb() for
x86 should be a nop.
About the only place where any on the fence instructions are needed
are in relation to write combining accesses.
In particular I don't believe they are ever needed to synchronise
uncached accesses with each other, or with cached accesses (which
are snooped).
David
^ permalink raw reply
* Re: [PATCH] rtnetlink: Mask the rta_type when range checking
From: Vlad Yasevich @ 2013-03-13 15:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem
In-Reply-To: <20130313083654.01d9c924@nehalam.linuxnetplumber.net>
On 03/13/2013 11:36 AM, Stephen Hemminger wrote:
> On Wed, 13 Mar 2013 10:18:58 -0400
> Vlad Yasevich <vyasevic@redhat.com> wrote:
>
>> Range/validity checks on rta_type in rtnetlink_rcv_msg() do
>> not account for flags that may be set. This causes the function
>> to return -EINVAL when flags are set on the type (for example
>> NLA_F_NESTED).
>>
>> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
>> ---
>> net/core/rtnetlink.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index 1868625..dc5edf1 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -2538,7 +2538,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
>> struct rtattr *attr = (void *)nlh + NLMSG_ALIGN(min_len);
>>
>> while (RTA_OK(attr, attrlen)) {
>> - unsigned int flavor = attr->rta_type;
>> + unsigned int flavor = attr->rta_type & NLA_TYPE_MASK;
>> if (flavor) {
>> if (flavor > rta_max[sz_idx])
>> return -EINVAL;
>
> No. This is effectively an ABI change. It adds nothing.
>
It makes nested IFLA_PROTINFO work that the bridge code expects.
Without this change, sending a nested IFLA_PROTINFO causes a EIVNAL
return.
-vlad
> The NLA_F_NESTED attribute wasn't in the first generation version of netlink
> (before my time with Linux). It doesn't make sense to all of sudden start
> accepting it on requests. Also, then you would expect the query to set
> the NESTED flag as well, and that would be another ABI change.
>
^ permalink raw reply
* Re: [PATCH net-next 0/4] Allow bridge to function in non-promisc mode
From: Stephen Hemminger @ 2013-03-13 15:39 UTC (permalink / raw)
To: vyasevic
Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
Oleg A. Arkhangelsky
In-Reply-To: <51406D2D.30703@redhat.com>
On Wed, 13 Mar 2013 08:12:29 -0400
Vlad Yasevich <vyasevic@redhat.com> wrote:
> On 03/13/2013 02:22 AM, "Oleg A. Arkhangelsky" wrote:
> >
> >
> > 13.03.2013, 05:45, "Vlad Yasevich" <vyasevic@redhat.com>:
> >
> >> The series adds an ability for the bridge to function in non-promiscuous mode.
> >
> > What is the practical applications for such setup? In other words,
> > in which cases I would want to put bridge into non-promiscuous
> > mode and specify some uplink ports?
> >
>
> On of the applications would be when bridge is an edge device servicing
> a VM deployment. Each of the VMs knows the mac address that the guest
> has and may program that mac onto the uplinks.
Why wouldn't that environment just use macvlan?
Is it because changing libvirt is harder than changing the kernel?
^ permalink raw reply
* Re: [PATCH net-next 1/4] bridge: Add sysfs interface to control promisc mode
From: Stephen Hemminger @ 2013-03-13 15:38 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, bridge
In-Reply-To: <1363139126-13396-2-git-send-email-vyasevic@redhat.com>
On Tue, 12 Mar 2013 21:45:23 -0400
Vlad Yasevich <vyasevic@redhat.com> wrote:
> Add an sysfs interface to turn promiscusous mode on and off on
> the bridge. By default all interfaces in the bridge
> are in promisc mode. When promisc mode is turned off, it is
> turned off on all bridge ports and the bridge turns on IFF_ALLMULTI
> to handle multicast traffic.
>
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
> ---
> net/bridge/br_device.c | 41 +++++++++++++++++++++++++++++++++++++++++
> net/bridge/br_if.c | 22 +++++++++++++++++-----
> net/bridge/br_private.h | 2 ++
> net/bridge/br_sysfs_br.c | 17 +++++++++++++++++
> 4 files changed, 77 insertions(+), 5 deletions(-)
>
All attribute changes must also be available through netlink, and changes
to attributes should cause a notification to applications listening for
netlink events on that bridge.
^ permalink raw reply
* [git pull] firewire net: resource management improvements
From: Stefan Richter @ 2013-03-13 15:37 UTC (permalink / raw)
To: David Miller; +Cc: yoshfuji, linux1394-devel, netdev
In-Reply-To: <20130313.102448.1103259275832948992.davem@davemloft.net>
David,
please pull from the tag "firewire-net-resource-mgt" at
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git firewire-net-resource-mgt
to receive the following firewire-net driver changes:
- fix memory leak and kmap leak at shutdown
- release IR DMA context already at ifdown rather than shutdown
(many controllers have got only 4 of them, so let's not hold it
longer than strictly necessary)
- misc startup/shutdown changes which prepare for later addition
of IPv6-over-1394 support
YOSHIFUJI Hideaki (11):
firewire net: No need to reset dev->local_fifo after failure of fw_core_add_address_handler().
firewire net: Introduce fwnet_fifo_{start, stop}() helpers.
firewire net: Setup broadcast and local fifo independently.
firewire net: Check dev->broadcast_state inside fwnet_broadcast_start().
firewire net: Fix memory leakage in fwnet_remove().
firewire net: Clear dev->broadcast_rcv_context and dev->broadcast_state after destruction of context.
firewire net: Omit checking dev->broadcast_rcv_context in fwnet_broadcast_start().
firewire net: Fix leakage of kmap for broadcast receive buffer.
firewire net: Allocate dev->broadcast_rcv_buffer_ptrs early.
firewire net: Introduce fwnet_broadcast_stop() to destroy broadcast resources.
firewire net: Release broadcast/fifo resources on ifdown.
drivers/firewire/net.c | 177 +++++++++++++++++++--------------
1 file changed, 105 insertions(+), 72 deletions(-)
Thanks,
--
Stefan Richter
-=====-===-= --== -==-=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH] rtnetlink: Mask the rta_type when range checking
From: Stephen Hemminger @ 2013-03-13 15:36 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, davem
In-Reply-To: <1363184338-15781-1-git-send-email-vyasevic@redhat.com>
On Wed, 13 Mar 2013 10:18:58 -0400
Vlad Yasevich <vyasevic@redhat.com> wrote:
> Range/validity checks on rta_type in rtnetlink_rcv_msg() do
> not account for flags that may be set. This causes the function
> to return -EINVAL when flags are set on the type (for example
> NLA_F_NESTED).
>
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
> ---
> net/core/rtnetlink.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 1868625..dc5edf1 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2538,7 +2538,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
> struct rtattr *attr = (void *)nlh + NLMSG_ALIGN(min_len);
>
> while (RTA_OK(attr, attrlen)) {
> - unsigned int flavor = attr->rta_type;
> + unsigned int flavor = attr->rta_type & NLA_TYPE_MASK;
> if (flavor) {
> if (flavor > rta_max[sz_idx])
> return -EINVAL;
No. This is effectively an ABI change. It adds nothing.
The NLA_F_NESTED attribute wasn't in the first generation version of netlink
(before my time with Linux). It doesn't make sense to all of sudden start
accepting it on requests. Also, then you would expect the query to set
the NESTED flag as well, and that would be another ABI change.
^ permalink raw reply
* Re: [PATCH net,stable-3.8] net: qmi_wwan: set correct altsetting for Gobi 1K devices
From: David Miller @ 2013-03-13 15:34 UTC (permalink / raw)
To: dcbw-H+wXaHxf7aLQT0dZR+AlfA
Cc: bjorn-yOkvZcmFvRU, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1363182216.1415.5.camel-wKZy7rqYPVb5EHUCmHmTqw@public.gmane.org>
From: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Wed, 13 Mar 2013 08:43:36 -0500
> On Wed, 2013-03-13 at 13:25 +0100, Bjørn Mork wrote:
>> commit bd877e4 ("net: qmi_wwan: use a single bind function for
>> all device types") made Gobi 1K devices fail probing.
>>
>> Using the number of endpoints in the default altsetting to decide
>> whether the function use one or two interfaces is wrong. Other
>> altsettings may provide more endpoints.
>>
>> With Gobi 1K devices, USB interface #3's altsetting is 0 by default, but
>> altsetting 0 only provides one interrupt endpoint and is not sufficent
>> for QMI. Altsetting 1 provides all 3 endpoints required for qmi_wwan
>> and works with QMI. Gobi 1K layout for intf#3 is:
>>
>> Interface Descriptor: 255/255/255
>> bInterfaceNumber 3
>> bAlternateSetting 0
>> Endpoint Descriptor: Interrupt IN
>> Interface Descriptor: 255/255/255
>> bInterfaceNumber 3
>> bAlternateSetting 1
>> Endpoint Descriptor: Interrupt IN
>> Endpoint Descriptor: Bulk IN
>> Endpoint Descriptor: Bulk OUT
>>
>> Prior to commit bd877e4, we would call usbnet_get_endpoints
>> before giving up finding enough endpoints. Removing the early
>> endpoint number test and the strict functional descriptor
>> requirement allow qmi_wwan_bind to continue until
>> usbnet_get_endpoints has made the final attempt to collect
>> endpoints. This restores the behaviour from before commit
>> bd877e4 without losing the added benefit of using a single bind
>> function.
>>
>> The driver has always required a CDC Union functional descriptor
>> for two-interface functions. Using the existence of this
>> descriptor to detect two-interface functions is the logically
>> correct method.
>>
>> Reported-by: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> Signed-off-by: Bjørn Mork
>
> Works on my UML290, Gobi3K, Gobi1K, Gobi2K, and E362.
>
> Tested-by: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Applied and queued up for -stable.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] Rate should be u64 to avoid integer overflow at high speeds (>= ~35Gbit)
From: Stephen Hemminger @ 2013-03-13 15:34 UTC (permalink / raw)
To: Bill Fink
Cc: Eric Dumazet, Thomas Graf, Chris Friesen, Vimal, netdev,
shemminger
In-Reply-To: <20130313112950.f3a4a332.billfink@mindspring.com>
On Wed, 13 Mar 2013 11:29:50 -0400
Bill Fink <billfink@mindspring.com> wrote:
> On Wed, 13 Mar 2013, Eric Dumazet wrote:
>
> > On Wed, 2013-03-13 at 02:01 -0400, Bill Fink wrote:
> >
> > > The last time this was discussed appears to be (on 2011-03-28):
> > >
> > > http://marc.info/?l=linux-netdev&m=130128741907282&w=2
> > >
> > > where Maciej Żenczykowski argued that creating a new 64-bit
> > > Netlink attribute for this would be much more complex than for
> > > the IFLA_STATS64 support. There was no reply.
> > >
> > > Providing a new multiplier/shift parameter would be a simple
> > > way to extend support for higher rates, and would not break
> > > existing user space that doesn't require the higher rates.
> > > I imagine the user would not explicitly specify the multiplier/
> > > shift parameter, but would just normally specify the desired
> > > rate, and a newer tc would figure out what multiplier/shift
> > > to use if a high enough rate demanded it. To maintain user
> > > space compatibility, the kernel should report back the same
> > > rate and multiplier/shift it was given, and the newer tc would
> > > convert it back to the user's originally specified rate. Older
> > > user space that was fine with the ~34 Gbps rate limitation would
> > > always have the default multiplier of 1 or shift of 0 bits, and
> > > would see the exact same unmultiplied/unshifted rate it always
> > > did.
> >
> > We already said no to such a hack. Maybe its not clear enough ?
> >
> > netlink allows us to a proper way, and Thomas Graf explained how we
> > expect the thing to be done.
> >
> > Yes, this is not a one liner patch, its a bit more of work, and its how
> > it will be done when someone does the job.
>
> I've no problem with that since it is a cleaner solution, but
> one that requires significantly more work. I was only arguing
> that the multiplier/shift approach was also a workable solution
> and should be simpler to implement. But since there appears to
> be developer consensus that it's not a desired method, I'm fine
> with going along with that expert opinion.
>
> -Bill
As others have said the multiplier shift approach is a not a workable
solution because it is likely to cause too many compatibility surprises.
Older kernels would ignore the multiplier and therefore not give the users
the effective rate they wanted.
^ permalink raw reply
* Re: [PATCH] tuntap: remove unused variable in __tun_detach()
From: David Miller @ 2013-03-13 15:33 UTC (permalink / raw)
To: weiyj.lk; +Cc: jasowang, mst, edumazet, nhorman, yongjun_wei, netdev
In-Reply-To: <CAPgLHd-v-daRHrDqoencJOTTvxLU_RD44BWzvdHd6j5Qrr8J5Q@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 13 Mar 2013 21:03:58 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> The variable dev is initialized but never used
> otherwise, so remove the unused variable.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH -next] sfc: remove duplicated include from efx.c
From: David Miller @ 2013-03-13 15:32 UTC (permalink / raw)
To: weiyj.lk; +Cc: linux-net-drivers, bhutchings, yongjun_wei, netdev
In-Reply-To: <CAPgLHd-iidouP5+3R1vgVQ8s3Ad-=10m92aGvGwJ1epeF0ob9A@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 13 Mar 2013 21:02:20 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Remove duplicated include.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* RE: igb_poll - device driver failed to check map error
From: Wyborny, Carolyn @ 2013-03-13 15:30 UTC (permalink / raw)
To: christoph.paasch@uclouvain.be, Kirsher, Jeffrey T,
Brandeburg, Jesse, Allan, Bruce W, Duyck, Alexander H,
Eric Dumazet
Cc: netdev@vger.kernel.org
In-Reply-To: <7974689.msj0QTRKPV@cpaasch-mac>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Christoph Paasch
> Sent: Tuesday, March 12, 2013 2:31 AM
> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Duyck, Alexander H;
> Eric Dumazet
> Cc: netdev@vger.kernel.org
> Subject: igb_poll - device driver failed to check map error
>
> Hello,
>
> I'm seeing a warning while booting my machine when DMA_API_DEBUG is set:
>
> [ 36.402824] ------------[ cut here ]------------
> [ 36.458070] WARNING: at /home/cpaasch/builder/net-next/lib/dma-
> debug.c:934
> check_unmap+0x648/0x702()
> [ 36.567377] Hardware name: ProLiant DL165 G7
> [ 36.618452] igb 0000:04:00.0: DMA-API: device driver failed to check map
> error[device address=0x0000000233d9b232] [size=154 bytes] [mapped as
> single]
> [ 36.776640] Modules linked in:
> [ 36.815446] Pid: 0, comm: swapper/7 Not tainted 3.9.0-rc1-mptcp+ #101
> [ 36.892515] Call Trace:
> [ 36.921745] <IRQ> [<ffffffff8102ad7f>] warn_slowpath_common+0x80/0x9a
> [ 37.001023] [<ffffffff8102ae2d>] warn_slowpath_fmt+0x41/0x43
> [ 37.069771] [<ffffffff811db17f>] check_unmap+0x648/0x702
> [ 37.134363] [<ffffffff811db3e9>] debug_dma_unmap_page+0x50/0x52
> [ 37.206234] [<ffffffff8136676a>] igb_poll+0x144/0xf7c
> [ 37.267706] [<ffffffff8104dd19>] ? sched_clock_cpu+0x46/0xd1
> [ 37.336456] [<ffffffff814458ce>] net_rx_action+0xa7/0x1d0
> [ 37.402085] [<ffffffff81030b65>] __do_softirq+0xb4/0x16f
> [ 37.466673] [<ffffffff81030c90>] irq_exit+0x40/0x87
> [ 37.526067] [<ffffffff81002db1>] do_IRQ+0x98/0xaf
> [ 37.583378] [<ffffffff815210aa>] common_interrupt+0x6a/0x6a
> [ 37.651086] <EOI> [<ffffffff8105d4be>] ?
> __tick_nohz_idle_enter+0x116/0x31f
> [ 37.736595] [<ffffffff81008a04>] ? default_idle+0x24/0x39
> [ 37.802224] [<ffffffff81008c62>] cpu_idle+0x68/0xa4
> [ 37.861616] [<ffffffff81519f78>] start_secondary+0x1a9/0x1ad
> [ 37.930364] ---[ end trace 01b5bb0fd75a464c ]---
>
>
> It happens shortly after mounting the NFS-root filesystem.
>
> I tried to understand what is going on, but I am now at my wit's end.
>
> By adding some print-statements, here is what I found out (not sure if this is
> anyhow helpful):
>
> The difference between tx_buffer->time_stamp and the current 'jiffies' is up to
> 2000 jiffies (HZ==1000) at the first time the above warning happens (this seems
> too much for me). From then on, I see my print 3-4 times appear but without
> such a big difference between the timestamps (difference around 1 and
> 2 jiffies).
>
> Some other stuff, I printed:
> tx_buffer->skb: ffff880235054c80
> tx_buffer->bytecount: 154
> tx_buffer->gso_segs: 1
> tx_buffer->protocol: 8
> tx_buffer->tx_flags 0x20
>
>
> One last thing:
> Am I right that after each call to dma_map_single/page a call to
> dma_mapping_error is needed? If that's the case, I have some patches that add
> this statement at missing places in the e1000, e1000e and ixgb driver. But these
> patches do not fix my above problem.
>
>
> Thanks for your help,
> Christoph
>
> --
> IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel -
> -- http://multipath-tcp.org UCLouvain
> --
> --
> 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
Thanks Christoph,
We'll take a look at this also.
Carolyn
Carolyn Wyborny
Linux Development
Networking Division
Intel Corporation
^ permalink raw reply
* Re: [PATCH] Rate should be u64 to avoid integer overflow at high speeds (>= ~35Gbit)
From: Bill Fink @ 2013-03-13 15:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Thomas Graf, Chris Friesen, Vimal, netdev, shemminger
In-Reply-To: <1363155195.13690.48.camel@edumazet-glaptop>
On Wed, 13 Mar 2013, Eric Dumazet wrote:
> On Wed, 2013-03-13 at 02:01 -0400, Bill Fink wrote:
>
> > The last time this was discussed appears to be (on 2011-03-28):
> >
> > http://marc.info/?l=linux-netdev&m=130128741907282&w=2
> >
> > where Maciej Żenczykowski argued that creating a new 64-bit
> > Netlink attribute for this would be much more complex than for
> > the IFLA_STATS64 support. There was no reply.
> >
> > Providing a new multiplier/shift parameter would be a simple
> > way to extend support for higher rates, and would not break
> > existing user space that doesn't require the higher rates.
> > I imagine the user would not explicitly specify the multiplier/
> > shift parameter, but would just normally specify the desired
> > rate, and a newer tc would figure out what multiplier/shift
> > to use if a high enough rate demanded it. To maintain user
> > space compatibility, the kernel should report back the same
> > rate and multiplier/shift it was given, and the newer tc would
> > convert it back to the user's originally specified rate. Older
> > user space that was fine with the ~34 Gbps rate limitation would
> > always have the default multiplier of 1 or shift of 0 bits, and
> > would see the exact same unmultiplied/unshifted rate it always
> > did.
>
> We already said no to such a hack. Maybe its not clear enough ?
>
> netlink allows us to a proper way, and Thomas Graf explained how we
> expect the thing to be done.
>
> Yes, this is not a one liner patch, its a bit more of work, and its how
> it will be done when someone does the job.
I've no problem with that since it is a cleaner solution, but
one that requires significantly more work. I was only arguing
that the multiplier/shift approach was also a workable solution
and should be simpler to implement. But since there appears to
be developer consensus that it's not a desired method, I'm fine
with going along with that expert opinion.
-Bill
^ permalink raw reply
* Re: [libvirt] if_bridge.h: include in6.h for struct in6_addr use
From: Kumar Gala @ 2013-03-13 15:17 UTC (permalink / raw)
To: Eric Blake
Cc: Thomas Backlund, netdev, linux-kernel@vger.kernel.org list,
libvirt-list, stephen, Zhenhua Luo
In-Reply-To: <50F49B7E.50906@redhat.com>
On Jan 14, 2013, at 5:57 PM, Eric Blake wrote:
> On 01/13/2013 01:05 PM, Thomas Backlund wrote:
>> Thomas Backlund skrev 13.1.2013 20:38:
>>> patch both inline and attached as thunderbird tends to mess up ...
>>
>>> -----
>>>
>>> if_bridge.h uses struct in6_addr ip6; but does not include the in6.h
>>> header.
>>>
>>> Found by trying to build libvirt and connman against 3.8-rc3 headers.
>>>
>>
>> Ok,
>> ignore this patch, it's not the correct fix as it introduces
>> redefinitions...
>>
>> Btw, the error that I hit that made me suggest this fix was libvirt
>> config check bailing out:
>>
>> config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has
>> incomplete type
>
> Hmm, just now noticing this thread, after independently hitting and and
> having to work around the same problem in libvirt:
> https://www.redhat.com/archives/libvir-list/2013-January/msg00930.html
> https://bugzilla.redhat.com/show_bug.cgi?id=895141
>
>>> --- linux-3.8-rc3/include/uapi/linux/if_bridge.h 2013-01-13
>>> 20:09:54.257271755 +0200
>>> +++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h 2013-01-13
>>> 20:15:04.153676151 +0200
>>> @@ -14,6 +14,7 @@
>>> #define _UAPI_LINUX_IF_BRIDGE_H
>>>
>>> #include <linux/types.h>
>>> +#include <linux/in6.h>
>>>
Did this ever get resolved ?
- k
^ permalink raw reply
* linux-3.6+, gre+ipsec+forwarding = IP fragmentation broken
From: Timo Teras @ 2013-03-13 15:14 UTC (permalink / raw)
To: netdev
In the typical DMVPN setup with IPv4-ESP-GRE-IPv4 stack, it seems that
IPv4 fragmentation got broke around 3.6 for forwarded packets.
It would seem that fragmentation works for locally generated packets.
Also PMTU (DF set) seems to work for both forwarded and locally
generated packets. But forwarded packets to gre device that gets IPsec
encrypted do not get fragmented properly.
3.4.x kernels work, 3.6 and 3.8 series tested and fail similarly.
I was going through the changelog and it seems that MTU is now handled
in nexthop exceptions and one needs to produce the full flow info to
update it. I'm wonding if this does not hold true in my code path as
ip_gre rewraps the forwarded packet and creates new IP header - when it
next goes to the xfrm code (which sends the ICMP error) the inner iphdr
is no longer accessible. Would this cause the breakage that I'm seeing?
Or the forward flow's mtu still updated somehow?
- Timo
^ permalink raw reply
* Re: [PATCH] Revert "ip_gre: make ipgre_tunnel_xmit() not parse network header as IP unconditionally"
From: Isaku Yamahata @ 2013-03-13 15:05 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev, Eric Dumazet, David S. Miller
In-Reply-To: <1363178269-27553-1-git-send-email-timo.teras@iki.fi>
Hi.
On Wed, Mar 13, 2013 at 02:37:49PM +0200, Timo Teräs wrote:
> This reverts commit 412ed94744d16806fbec3bd250fd94e71cde5a1f.
>
> The commit is wrong as tiph points to the outer IPv4 header which is
> installed at ipgre_header() and not the inner one which is protocol dependant.
>
> This commit broke succesfully opennhrp which use PF_PACKET socket with
> ETH_P_NHRP protocol. Additionally ssl_addr is set to the link-layer
> IPv4 address. This address is written by ipgre_header() to the skb
> earlier, and this is the IPv4 header tiph should point to - regardless
> of the inner protocol payload.
Is this the case only for ETH_P_HNRP?
I wrote the patch having MPLS over GRE in mind.
Should it be something like this?
if (protocol == htons(ETH_P_IP) || protocol == htons(ETH_P_NHRP))
....
thanks,
>
> Signed-off-by: Timo Teräs <timo.teras@iki.fi>
> ---
> net/ipv4/ip_gre.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> This commit appeared in 3.8.x. So should go to 3.8.x-stable.
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index d0ef0e6..91d66db 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -798,10 +798,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
>
> if (dev->header_ops && dev->type == ARPHRD_IPGRE) {
> gre_hlen = 0;
> - if (skb->protocol == htons(ETH_P_IP))
> - tiph = (const struct iphdr *)skb->data;
> - else
> - tiph = &tunnel->parms.iph;
> + tiph = (const struct iphdr *)skb->data;
> } else {
> gre_hlen = tunnel->hlen;
> tiph = &tunnel->parms.iph;
> --
> 1.8.1.5
>
--
yamahata
^ permalink raw reply
* Re: [PATCH v2 1/1] ipv4: fix definition of FIB_TABLE_HASHSZ
From: David Miller @ 2013-03-13 15:01 UTC (permalink / raw)
To: den; +Cc: netdev, tingw.liu, kuznet
In-Reply-To: <1363170255-11769-1-git-send-email-den@openvz.org>
From: "Denis V. Lunev" <den@openvz.org>
Date: Wed, 13 Mar 2013 14:24:15 +0400
> From: "Denis V. Lunev" <den@openvz.org>
>
> a long time ago by the commit
>
> commit 93456b6d7753def8760b423ac6b986eb9d5a4a95
> Author: Denis V. Lunev <den@openvz.org>
> Date: Thu Jan 10 03:23:38 2008 -0800
>
> [IPV4]: Unify access to the routing tables.
>
> the defenition of FIB_HASH_TABLE size has obtained wrong dependency:
> it should depend upon CONFIG_IP_MULTIPLE_TABLES (as was in the original
> code) but it was depended from CONFIG_IP_ROUTE_MULTIPATH
>
> This patch returns the situation to the original state.
>
> The problem was spotted by Tingwei Liu.
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/ieee802154/6lowpan: Fix initialization for fragment offset
From: Wolf-Bastian Pöttner @ 2013-03-13 14:40 UTC (permalink / raw)
To: David Miller
Cc: Linux-zigbee-devel, alex.bluesman.smirnov, dbaryshkov, netdev
In-Reply-To: <20130313.103830.247889330240632952.davem@davemloft.net>
Hi!
Nope. The patch fixes a problem in code that is not in mainline yet. However, people on the linux-zigbee mailing list found it a good idea to commit this change to mainline to avoid the problem from arising.
I see, you disagree. Nevermind. ;)
Bastian
--
Wolf-Bastian Pöttner Institut für Betriebssysteme & Rechnerverbund
Tel.: +49-531-391-3265 Mühlenpfordtstrasse 23
Fax.: +49-531-391-5936 TU Braunschweig D-38106 Braunschweig
Am 13.03.2013 um 15:38 schrieb David Miller <davem@davemloft.net>:
> From: Wolf-Bastian Pöttner <poettner@ibr.cs.tu-bs.de>
> Date: Wed, 13 Mar 2013 08:50:54 +0100
>
>> offset has to be initialized, otherwise the *first* fragment will
>> be discarded and reassembly cannot happen.
>>
>> Reviewed-by: Alan Ott <alan@signal11.us>
>
> 'offset' is never used unless lowpan_fetch_skb_u8(skb, &offset)
> succeeds, in which case it will be initialized properly. Otherwise we
> unlock and drop the SKB and make no references whatsoever to 'offset'.
>
> I suspect you saw some compiler warning about 'offset' being
> uninitialized, and are just blindly trying to shut this warning up.
^ permalink raw reply
* Re: [PATCH] net/core: another bug fix related to dst_neigh_lookup/dst_neigh_lookup_skb
From: David Miller @ 2013-03-13 14:39 UTC (permalink / raw)
To: zhouzhouyi; +Cc: netdev, stable, trivial
In-Reply-To: <CAABZP2xsVauGarKa1yfWOHAmi9Z+B+Au3ZYa-QkM1hA4b4PypA@mail.gmail.com>
From: Zhouyi Zhou <zhouzhouyi@gmail.com>
Date: Wed, 13 Mar 2013 16:40:49 +0800
> I do a
> /home/zzy/linux-stable#find . -name "*.c"|xargs grep -A 2 dst_neigh_lookup
> and find that there are two places in drivers/infiniband/hw/cxgb4/cm.c
> do not treat the error return of dst_neigh_lookup/dst_neigh_lookup_skb
This patch is also corrupted by your email client.
>
> Signed-off-by: Zhouyi Zhou <zhouzhouyi <at> gmail.com>
Do not write your email address in your signoff in this way,
you use real email address with a real "@" character rather
than this " <at> " thing.
^ permalink raw reply
* Re: [PATCH] net/ieee802154/6lowpan: Fix initialization for fragment offset
From: David Miller @ 2013-03-13 14:38 UTC (permalink / raw)
To: poettner; +Cc: Linux-zigbee-devel, alex.bluesman.smirnov, dbaryshkov, netdev
In-Reply-To: <1363161054-13471-1-git-send-email-poettner@ibr.cs.tu-bs.de>
From: Wolf-Bastian Pöttner <poettner@ibr.cs.tu-bs.de>
Date: Wed, 13 Mar 2013 08:50:54 +0100
> offset has to be initialized, otherwise the *first* fragment will
> be discarded and reassembly cannot happen.
>
> Reviewed-by: Alan Ott <alan@signal11.us>
'offset' is never used unless lowpan_fetch_skb_u8(skb, &offset)
succeeds, in which case it will be initialized properly. Otherwise we
unlock and drop the SKB and make no references whatsoever to 'offset'.
I suspect you saw some compiler warning about 'offset' being
uninitialized, and are just blindly trying to shut this warning up.
^ permalink raw reply
* Re: [PATCH net-next 05/22] cxgb4: Add T5 write combining support
From: Vipul Pandya @ 2013-03-13 14:36 UTC (permalink / raw)
To: Steve Wise
Cc: David Miller, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org,
JBottomley-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org,
Dimitrios Michailidis, Casey Leedom, Naresh Kumar Inna,
Divy Le Ray, Santosh Rastapur, Arvind Bhushan, Abhishek Agrawal
In-Reply-To: <513F3EBD.5020504-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
On 12-03-2013 20:12, Steve Wise wrote:
> On 3/12/2013 7:19 AM, David Miller wrote:
>> From: Vipul Pandya <vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
>> Date: Tue, 12 Mar 2013 17:16:17 +0530
>>
>>> + writel(n, adap->bar2 + q->udb + 8);
>>> +#if defined(CONFIG_X86_32) || defined(CONFIG_X86_64)
>>> + asm volatile("sfence" : : : "memory");
>>> +#endif
>> There is absolutely no way I'm letting anyone put crap like this
>> into a driver.
>>
>> Use a portable inteface, and if one does not exist create one.
>
> I guess you'll have to add a wc_wmb() function for all the hw platforms
> supported by the kernel. I see libibverbs defines this for the user
> side in include/infiniband/arch.h, and that could be used as the meat of
> the hw platform-specific implementations.
>
I see that normal wmb() code for x86_64 architecture is same as what
above #ifdef condition is doing. To be more clear I looked at the
assembly code for wmb and find that it is converted into 'sfence'
instruction. So, I think above code should be replaced with wmb call
which will also take care of portability on different architecture. I
will submit the series again soon.
I would like to request RDMA/cxgb4 and csiostor driver maintainer to
review the series if it has not been done already. It would be great If
I can include review comments from them in my next version of series.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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/core: fixing dst_neigh_lookup/dst_neigh_lookup_skb caused kernel panic
From: David Miller @ 2013-03-13 14:33 UTC (permalink / raw)
To: zhouzhouyi; +Cc: netdev, stable, trivial
In-Reply-To: <CAABZP2yznP5jD6Og=-ZxgAh23VpfM1BGX4OJsOb00KDeyV-jyA@mail.gmail.com>
From: Zhouyi Zhou <zhouzhouyi@gmail.com>
Date: Wed, 13 Mar 2013 12:00:34 +0800
> when neighbour table is full, dst_neigh_lookup/dst_neigh_lookup_skb
> will return -ENOBUFS which
> is absolutely non zero, while all the code in kernel which use above
> functions assume failure only
> on zero return (I did a grep), which will cause kernel panic. (for
> example: https://bugzilla.kernel.org/show_bug.cgi?id=54731)
>
> This patch corrects above error with smallest changes to kernel source code.
> Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
Your patch was corrupted by your email client.
Fix this, and only resend this patch once you are able to send a test
patch to yourself and cleanly apply the patch you receive.
^ permalink raw reply
* Re: [PATCH net-next] packet: packet fanout rollover during socket overload
From: Eric Dumazet @ 2013-03-13 14:25 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: netdev, davem, edumazet
In-Reply-To: <1363102664-5174-1-git-send-email-willemb@google.com>
On Tue, 2013-03-12 at 11:37 -0400, Willem de Bruijn wrote:
> Minimize packet drop in a fanout group. If one socket is full,
> roll over packets to another from the group. The intended use is
> to maintain flow affinity during normal load using an rxhash or
> cpu fanout policy, while dispersing unexpected traffic storms that
> hit a single cpu, such as spoofed-source DoS flows. This mechanism
> breaks affinity for flows arriving at saturated sockets during
> those conditions.
>
> The patch adds a fanout policy ROLLOVER that rotates between sockets,
> filling each socket before moving to the next. It also adds a fanout
> flag ROLLOVER. If passed along with any other fanout policy, the
> primary policy is applied until the chosen socket is full. Then,
> rollover selects another socket, to delay packet drop until the
> entire system is saturated.
>
> Probing sockets is not free. Selecting the last used socket, as
> rollover does, is a greedy approach that maximizes chance of
> success, at the cost of extreme load imbalance. In practice, with
> sufficiently long queues to handle rate, sockets are drained in
> parallel and load balance looks uniform in `top`.
>
> To avoid contention, scales counters with number of sockets and
> accesses them lockfree. Values are bounds checked to ensure
> correctness. An alternative would be to use atomic rr_cur.
>
> Tested using an application with 9 threads pinned to CPUs, one socket
> per thread and sufficient busywork per packet operation to limits each
> thread to handling 32 Kpps. When sent 500 Kpps single UDP stream
> packets, a FANOUT_CPU setup processes 32 Kpps in total without this
> patch, 270 Kpps with the patch. Tested with read() and with a packet
> ring (V1).
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> ---
> include/linux/if_packet.h | 2 +
> net/packet/af_packet.c | 112 ++++++++++++++++++++++++++++++++++++----------
> 2 files changed, 90 insertions(+), 24 deletions(-)
> -static struct sock *fanout_demux_cpu(struct packet_fanout *f, struct sk_buff *skb, unsigned int num)
> +static unsigned int fanout_demux_rollover(struct packet_fanout *f,
> + struct sk_buff *skb,
> + unsigned int idx, unsigned int skip,
> + unsigned int num)
> {
> - unsigned int cpu = smp_processor_id();
> + unsigned int i, j;
>
> - return f->arr[cpu % num];
> + i = j = min(f->next[idx], (int) f->num_members - 1);
min_t(int, f->next[idx], f->num_members - 1);
BTW, num_members can be 0
You really should do
int members = ACCESS_ONCE(f->num_members) - 1;
if (members < 0)
return idx;
and only use members in your loop.
> + do {
> + if (i != skip && packet_rcv_has_room(pkt_sk(f->arr[i]), skb)) {
> + if (i != j)
> + f->next[idx] = i;
> + return i;
> + }
> + if (++i >= f->num_members)
> + i = 0;
> + } while (i != j && idx < f->num_members);
> +
> + return idx;
> +}
> +
^ 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