* Re: [PATCH stable 3.9+] can: add destructor for self generated skbs
From: David Miller @ 2014-01-31 0:27 UTC (permalink / raw)
To: socketcan; +Cc: eric.dumazet, nautsch2, netdev, linux-can
In-Reply-To: <52EA1740.2010108@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 30 Jan 2014 10:11:28 +0100
> Self generated skbuffs in net/can/bcm.c are setting a skb->sk reference but
> no explicit destructor which is enforced since Linux 3.11 with commit
> 376c7311bdb6 (net: add a temporary sanity check in skb_orphan()).
>
> This patch adds some helper functions to make sure that a destructor is
> properly defined when a sock reference is assigned to a CAN related skb.
> To create an unshared skb owned by the original sock a common helper function
> has been introduced to replace open coded functions to create CAN echo skbs.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> Tested-by: Andre Naujoks <nautsch2@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] e100: Fix "disabling already-disabled device" warning
From: David Miller @ 2014-01-31 0:27 UTC (permalink / raw)
To: michele; +Cc: netdev, e1000-devel, idirectscm
In-Reply-To: <1391079064-18411-1-git-send-email-michele@acksyn.org>
From: Michele Baldessari <michele@acksyn.org>
Date: Thu, 30 Jan 2014 10:51:04 +0000
> In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and
> https://bugzilla.redhat.com/show_bug.cgi?id=970480 we
> received different reports of e100 throwing the following
> warning:
...
> This patch removes pci_disable_device() from __e100_shutdown().
> pci_clear_master() is enough.
>
> Signed-off-by: Michele Baldessari <michele@acksyn.org>
> Tested-by: Mark Harig <idirectscm@aim.com>
Can I get some Intel folks to review/ack this?
Thanks.
^ permalink raw reply
* Re: [PATCH] net: set default DEVTYPE for all ethernet based devices
From: David Miller @ 2014-01-31 0:28 UTC (permalink / raw)
To: teg
Cc: netdev, linux-kernel, stephen, avi.kp.137, mchehab, horms, marcel,
gregkh, kay
In-Reply-To: <1391088002-15650-1-git-send-email-teg@jklm.no>
From: Tom Gundersen <teg@jklm.no>
Date: Thu, 30 Jan 2014 14:20:02 +0100
> In systemd's networkd and udevd, we would like to give the administrator a
> simple way to filter net devices by their DEVTYPE [0][1]. Other software
> such as ConnMan and NetworkManager uses a similar filtering already.
>
> Currently, plain ethernet devices have DEVTYPE=(null). This patch sets the
> devtype to "ethernet" instead. This avoids the need for special-casing the
> DEVTYPE=(null) case in userspace, and also avoids false positives, as there
> are several other types of netdevs that also have DEVTYPE=(null).
>
> Notice that this is done, as suggested by Marcel, in alloc_etherdev_mqs(),
> and as best I can tell it will not give any false positives. I considered
> doing it in ether_setup() instead as that seemed more intuitive, but that
> would give a lot of false positives indeed.
>
> [0]: <http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html#Type>
> [1]: <http://www.freedesktop.org/software/systemd/man/udev.html#Type>
>
> Signed-off-by: Tom Gundersen <teg@jklm.no>
Assuming that all users of alloc_etherdev*() are ethernet devices is
really not going to work.
^ permalink raw reply
* Re: [PATCH] 9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers
From: David Miller @ 2014-01-31 0:29 UTC (permalink / raw)
To: ryao
Cc: ericvh, rminnich, lucho, v9fs-developer, netdev, linux-kernel,
kernel, aneesh.kumar, will.deacon, cov, behlendorf1, mthode
In-Reply-To: <1391104968-10258-2-git-send-email-ryao@gentoo.org>
From: Richard Yao <ryao@gentoo.org>
Date: Thu, 30 Jan 2014 13:02:48 -0500
> The 9p-virtio transport does zero copy on things larger than 1024 bytes
> in size. It accomplishes this by returning the physical addresses of
> pages to the virtio-pci device. At present, the translation is usually a
> bit shift.
>
> However, that approach produces an invalid page address when we
> read/write to vmalloc buffers, such as those used for Linux kernle
> modules. This causes QEMU to die printing:
>
> qemu-system-x86_64: virtio: trying to map MMIO memory
>
> This patch enables 9p-virtio to correctly handle this case. This not
> only enables us to load Linux kernel modules off virtfs, but also
> enables ZFS file-based vdevs on virtfs to be used without killing QEMU.
>
> Also, special thanks to both Avi Kivity and Alexander Graf for their
> interpretation of QEMU backtraces. Without their guidence, tracking down
> this bug would have taken much longer.
>
> Signed-off-by: Richard Yao <ryao@gentoo.org>
> Acked-by: Alexander Graf <agraf@suse.de>
> Reviewed-by: Will Deacon <will.deacon@arm.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] The maintainer needs to be updated.
From: David Miller @ 2014-01-31 0:29 UTC (permalink / raw)
To: venkat.x.venkatsubra; +Cc: netdev, rds-devel, chien.yen
In-Reply-To: <1391117327-10420-1-git-send-email-venkat.x.venkatsubra@oracle.com>
From: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Date: Thu, 30 Jan 2014 13:28:47 -0800
> Signed-off-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Applied.
^ permalink raw reply
* [RFC PATCH] net: core: move core networking work to power efficient workqueue
From: Zoran Markovic @ 2014-01-31 0:33 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Shaibal Dutta, David S. Miller, Jiri Pirko,
YOSHIFUJI Hideaki, Eric Dumazet, Julian Anastasov, Flavio Leitner,
Neil Horman, Patrick McHardy, John Fastabend, Amerigo Wang,
Joe Perches, Jason Wang, Antonio Quartulli, Simon Horman,
Nikolay Aleksandrov, Zoran Markovic
From: Shaibal Dutta <shaibal.dutta@broadcom.com>
This patch moves the following work to the power efficient workqueue:
- Transmit work of netpoll
- Destination cache garbage collector work
- Link watch event handler work
In general, assignment of CPUs to pending work could be deferred to
the scheduler in order to extend idle residency time and improve
power efficiency. I would value community's opinion on the migration
of this work to the power efficient workqueue, with an emphasis on
migration of netpoll's transmit work.
This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: Flavio Leitner <fbl@redhat.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: John Fastabend <john.r.fastabend@intel.com>
Cc: Amerigo Wang <amwang@redhat.com>
Cc: Joe Perches <joe@perches.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Antonio Quartulli <antonio@meshcoding.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Nikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com>
[zoran.markovic@linaro.org: Rebased to latest kernel version. Edited
calls to mod_delayed_work to reference power efficient workqueue.
Added commit message.]
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
---
net/core/dst.c | 5 +++--
net/core/link_watch.c | 5 +++--
net/core/netpoll.c | 6 ++++--
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/net/core/dst.c b/net/core/dst.c
index ca4231e..cc28352 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -135,7 +135,8 @@ loop:
*/
if (expires > 4*HZ)
expires = round_jiffies_relative(expires);
- schedule_delayed_work(&dst_gc_work, expires);
+ queue_delayed_work(system_power_efficient_wq,
+ &dst_gc_work, expires);
}
spin_unlock_bh(&dst_garbage.lock);
@@ -223,7 +224,7 @@ void __dst_free(struct dst_entry *dst)
if (dst_garbage.timer_inc > DST_GC_INC) {
dst_garbage.timer_inc = DST_GC_INC;
dst_garbage.timer_expires = DST_GC_MIN;
- mod_delayed_work(system_wq, &dst_gc_work,
+ mod_delayed_work(system_power_efficient_wq, &dst_gc_work,
dst_garbage.timer_expires);
}
spin_unlock_bh(&dst_garbage.lock);
diff --git a/net/core/link_watch.c b/net/core/link_watch.c
index 9c3a839..0ae3994 100644
--- a/net/core/link_watch.c
+++ b/net/core/link_watch.c
@@ -135,9 +135,10 @@ static void linkwatch_schedule_work(int urgent)
* override the existing timer.
*/
if (test_bit(LW_URGENT, &linkwatch_flags))
- mod_delayed_work(system_wq, &linkwatch_work, 0);
+ mod_delayed_work(system_power_efficient_wq, &linkwatch_work, 0);
else
- schedule_delayed_work(&linkwatch_work, delay);
+ queue_delayed_work(system_power_efficient_wq,
+ &linkwatch_work, delay);
}
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index c03f3de..2c8f839 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -101,7 +101,8 @@ static void queue_process(struct work_struct *work)
__netif_tx_unlock(txq);
local_irq_restore(flags);
- schedule_delayed_work(&npinfo->tx_work, HZ/10);
+ queue_delayed_work(system_power_efficient_wq,
+ &npinfo->tx_work, HZ/10);
return;
}
__netif_tx_unlock(txq);
@@ -423,7 +424,8 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
if (status != NETDEV_TX_OK) {
skb_queue_tail(&npinfo->txq, skb);
- schedule_delayed_work(&npinfo->tx_work,0);
+ queue_delayed_work(system_power_efficient_wq,
+ &npinfo->tx_work, 0);
}
}
EXPORT_SYMBOL(netpoll_send_skb_on_dev);
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH net] e100: Fix "disabling already-disabled device" warning
From: Brown, Aaron F @ 2014-01-31 0:40 UTC (permalink / raw)
To: David Miller, michele@acksyn.org
Cc: netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net,
idirectscm@aim.com
In-Reply-To: <20140130.162745.1556632155972070897.davem@davemloft.net>
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of David Miller
> Sent: Thursday, January 30, 2014 4:28 PM
> To: michele@acksyn.org
> Cc: netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net;
> idirectscm@aim.com
> Subject: Re: [PATCH net] e100: Fix "disabling already-disabled device"
> warning
>
> From: Michele Baldessari <michele@acksyn.org>
> Date: Thu, 30 Jan 2014 10:51:04 +0000
>
> > In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and
> > https://bugzilla.redhat.com/show_bug.cgi?id=970480 we received
> > different reports of e100 throwing the following
> > warning:
> ...
> > This patch removes pci_disable_device() from __e100_shutdown().
> > pci_clear_master() is enough.
> >
> > Signed-off-by: Michele Baldessari <michele@acksyn.org>
> > Tested-by: Mark Harig <idirectscm@aim.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
Sorry if it's a duplicate, one I sent out earlier did not seem to hit netdev.
>
> Can I get some Intel folks to review/ack this?
>
> Thanks.
> --
> 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
^ permalink raw reply
* Re: [PATCH] 9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers
From: David Miller @ 2014-01-31 0:44 UTC (permalink / raw)
To: ryao
Cc: ericvh, rminnich, lucho, v9fs-developer, netdev, linux-kernel,
kernel, aneesh.kumar, will.deacon, cov, behlendorf1, mthode
In-Reply-To: <20140130.162926.561686911250624301.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 30 Jan 2014 16:29:26 -0800 (PST)
> From: Richard Yao <ryao@gentoo.org>
> Date: Thu, 30 Jan 2014 13:02:48 -0500
>
>> The 9p-virtio transport does zero copy on things larger than 1024 bytes
>> in size. It accomplishes this by returning the physical addresses of
>> pages to the virtio-pci device. At present, the translation is usually a
>> bit shift.
>>
>> However, that approach produces an invalid page address when we
>> read/write to vmalloc buffers, such as those used for Linux kernle
>> modules. This causes QEMU to die printing:
>>
>> qemu-system-x86_64: virtio: trying to map MMIO memory
>>
>> This patch enables 9p-virtio to correctly handle this case. This not
>> only enables us to load Linux kernel modules off virtfs, but also
>> enables ZFS file-based vdevs on virtfs to be used without killing QEMU.
>>
>> Also, special thanks to both Avi Kivity and Alexander Graf for their
>> interpretation of QEMU backtraces. Without their guidence, tracking down
>> this bug would have taken much longer.
>>
>> Signed-off-by: Richard Yao <ryao@gentoo.org>
>> Acked-by: Alexander Graf <agraf@suse.de>
>> Reviewed-by: Will Deacon <will.deacon@arm.com>
>
> Applied, thanks.
Actually I had to revert, is_vmalloc_or_malloc_addr() is not exported to
modules, so this change breaks the build.
^ permalink raw reply
* Re: [PATCH net] e100: Fix "disabling already-disabled device" warning
From: David Miller @ 2014-01-31 0:45 UTC (permalink / raw)
To: aaron.f.brown; +Cc: michele, netdev, e1000-devel, idirectscm
In-Reply-To: <309B89C4C689E141A5FF6A0C5FB2118B7314C041@ORSMSX101.amr.corp.intel.com>
From: "Brown, Aaron F" <aaron.f.brown@intel.com>
Date: Fri, 31 Jan 2014 00:40:16 +0000
>> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>> On Behalf Of David Miller
>> Sent: Thursday, January 30, 2014 4:28 PM
>> To: michele@acksyn.org
>> Cc: netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net;
>> idirectscm@aim.com
>> Subject: Re: [PATCH net] e100: Fix "disabling already-disabled device"
>> warning
>>
>> From: Michele Baldessari <michele@acksyn.org>
>> Date: Thu, 30 Jan 2014 10:51:04 +0000
>>
>> > In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and
>> > https://bugzilla.redhat.com/show_bug.cgi?id=970480 we received
>> > different reports of e100 throwing the following
>> > warning:
>> ...
>> > This patch removes pci_disable_device() from __e100_shutdown().
>> > pci_clear_master() is enough.
>> >
>> > Signed-off-by: Michele Baldessari <michele@acksyn.org>
>> > Tested-by: Mark Harig <idirectscm@aim.com>
>
> Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
>
> Sorry if it's a duplicate, one I sent out earlier did not seem to hit netdev.
I think this patch was posted twice, once without netdev properly
CC:'d and you replied to that copy.
Thanks Aaron, I'll apply this.
^ permalink raw reply
* Re: [RFC PATCH] net: core: move core networking work to power efficient workqueue
From: Antonio Quartulli @ 2014-01-31 0:48 UTC (permalink / raw)
To: Zoran Markovic, linux-kernel
Cc: netdev, Shaibal Dutta, David S. Miller, Jiri Pirko,
YOSHIFUJI Hideaki, Eric Dumazet, Julian Anastasov, Flavio Leitner,
Neil Horman, Patrick McHardy, John Fastabend, Amerigo Wang,
Joe Perches, Jason Wang, Simon Horman, Nikolay Aleksandrov
In-Reply-To: <1391128402-10725-1-git-send-email-zoran.markovic@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]
On 31/01/14 01:33, Zoran Markovic wrote:
> From: Shaibal Dutta <shaibal.dutta@broadcom.com>
[...]
> - schedule_delayed_work(&linkwatch_work, delay);
> + queue_delayed_work(system_power_efficient_wq,
> + &linkwatch_work, delay);
before talking about technical details, here and in other spots of this
patch the alignment is wrong. I think checkpatch should have said
something about it. The first parameter on the new line should be
aligned up to the column after the opening parenthesis.
Regards,
> }
>
>
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index c03f3de..2c8f839 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -101,7 +101,8 @@ static void queue_process(struct work_struct *work)
> __netif_tx_unlock(txq);
> local_irq_restore(flags);
>
> - schedule_delayed_work(&npinfo->tx_work, HZ/10);
> + queue_delayed_work(system_power_efficient_wq,
> + &npinfo->tx_work, HZ/10);
> return;
> }
> __netif_tx_unlock(txq);
> @@ -423,7 +424,8 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
>
> if (status != NETDEV_TX_OK) {
> skb_queue_tail(&npinfo->txq, skb);
> - schedule_delayed_work(&npinfo->tx_work,0);
> + queue_delayed_work(system_power_efficient_wq,
> + &npinfo->tx_work, 0);
> }
> }
> EXPORT_SYMBOL(netpoll_send_skb_on_dev);
>
--
Antonio Quartulli
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: pull-request: can 2014-01-29
From: David Miller @ 2014-01-31 0:49 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <1391029863-23099-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 29 Jan 2014 22:11:00 +0100
> this is a pull request with three fixes for net/master, for the current release
> cycle.
>
> Arnd Bergmann provides a fix for the flexcan driver, enabling compilation on
> all combinations of big and little endian on ARM and PowerPc. A patch by Ira W.
> Snyder fixes uninitialized variable warnings in the janz-ican3 driver.
> Rostislav Lisovy contributes a patch to propagate the SO_PRIORITY of raw
> sockets to skbs.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [PATCH] net: set default DEVTYPE for all ethernet based devices
From: Tom Gundersen @ 2014-01-31 0:54 UTC (permalink / raw)
To: Veaceslav Falico
Cc: netdev, LKML, Stephen Hemminger, Avinash Kumar, Simon Horman,
Marcel Holtmann, Greg KH, Kay Sievers
In-Reply-To: <20140130150503.GA29607@redhat.com>
Hi Veaceslav,
Thanks for your quick reply.
On Thu, Jan 30, 2014 at 4:05 PM, Veaceslav Falico <vfalico@redhat.com> wrote:
> On Thu, Jan 30, 2014 at 02:20:02PM +0100, Tom Gundersen wrote:
>>
>> In systemd's networkd and udevd, we would like to give the administrator a
>> simple way to filter net devices by their DEVTYPE [0][1]. Other software
>> such as ConnMan and NetworkManager uses a similar filtering already.
>>
>> Currently, plain ethernet devices have DEVTYPE=(null). This patch sets the
>> devtype to "ethernet" instead. This avoids the need for special-casing the
>> DEVTYPE=(null) case in userspace, and also avoids false positives, as
>> there
>> are several other types of netdevs that also have DEVTYPE=(null).
>
>
> There are quite a few users at least in usb and wireless drivers:
>
> net#git grep alloc_etherdev drivers/net/wireless/ drivers/net/usb | wc -l
> 18
>
> In usb, though, there might be some false positives of this grep, as
> there are a few devices which might be considered ethernet.
Ah, yes I missed the #define of alloc_etherdev(). Looking through
these, it shouldn't be too hard to keep this patch and additionally
fix up the false positives to opt-out of setting the DEVTYPE. Does
that sound like something that would be acceptable?
Cheers,
Tom
^ permalink raw reply
* Re: [RFC PATCH] net: core: move core networking work to power efficient workqueue
From: Joe Perches @ 2014-01-31 0:55 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: Zoran Markovic, linux-kernel, netdev
In-Reply-To: <52EAF2E5.8090403@meshcoding.com>
On Fri, 2014-01-31 at 01:48 +0100, Antonio Quartulli wrote:
> On 31/01/14 01:33, Zoran Markovic wrote:
> > From: Shaibal Dutta <shaibal.dutta@broadcom.com>
>
> [...]
>
> > - schedule_delayed_work(&linkwatch_work, delay);
> > + queue_delayed_work(system_power_efficient_wq,
> > + &linkwatch_work, delay);
>
> before talking about technical details, here and in other spots of this
> patch the alignment is wrong. I think checkpatch should have said
> something about it. The first parameter on the new line should be
> aligned up to the column after the opening parenthesis.
Using "scripts/checkpatch.pl --strict" would emit an
alignment message, otherwise not.
^ permalink raw reply
* Re: [PATCH] rtnetlink: return the newly created link in response to newlink
From: Tom Gundersen @ 2014-01-31 0:57 UTC (permalink / raw)
To: Thomas Graf
Cc: netdev, LKML, John Fastabend, Nicolas Dichtel, Vlad Yasevich,
Marcel Holtmann, David S. Miller
In-Reply-To: <20140130142740.GC2185@casper.infradead.org>
Hi Thomas,
Thanks for your reply.
On Thu, Jan 30, 2014 at 3:27 PM, Thomas Graf <tgraf@suug.ch> wrote:
> On 01/30/14 at 02:05pm, Tom Gundersen wrote:
>> Userspace needs to reliably know the ifindex of the netdevs it creates,
>> as we cannot rely on the ifname staying unchanged.
>>
>> Earlier, a simlpe NLMSG_ERROR would be returned, but this returns the
>> corresponding RTM_NEWLINK on success instead.
>
> This breaks existing Netlink applications in user space. User space
> apps are not prepared to receive both a RTM_NEWLINK reply _and_
> the ACK unless they have set NLM_F_ECHO in the original request.
>
> You can already reliably retrieve the ifindex by listening to
> RTNLGRP_LINK messages and be notified about the link created
> including all follow-up renames.
Ok, we'll keep doing this instead.
Cheers,
Tom
^ permalink raw reply
* Re: [PATCH] 9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers
From: Richard Yao @ 2014-01-31 1:02 UTC (permalink / raw)
To: David Miller
Cc: ericvh@gmail.com, rminnich@sandia.gov, lucho@ionkov.net,
v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel@gentoo.org,
aneesh.kumar@linux.vnet.ibm.com, will.deacon@arm.com,
cov@codeaurora.org, behlendorf1@llnl.gov, mthode@mthode.org
In-Reply-To: <20140130.164451.873520736572570393.davem@davemloft.net>
On Jan 30, 2014, at 7:44 PM, David Miller <davem@davemloft.net> wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 30 Jan 2014 16:29:26 -0800 (PST)
>
>> From: Richard Yao <ryao@gentoo.org>
>> Date: Thu, 30 Jan 2014 13:02:48 -0500
>>
>>> The 9p-virtio transport does zero copy on things larger than 1024 bytes
>>> in size. It accomplishes this by returning the physical addresses of
>>> pages to the virtio-pci device. At present, the translation is usually a
>>> bit shift.
>>>
>>> However, that approach produces an invalid page address when we
>>> read/write to vmalloc buffers, such as those used for Linux kernle
>>> modules. This causes QEMU to die printing:
>>>
>>> qemu-system-x86_64: virtio: trying to map MMIO memory
>>>
>>> This patch enables 9p-virtio to correctly handle this case. This not
>>> only enables us to load Linux kernel modules off virtfs, but also
>>> enables ZFS file-based vdevs on virtfs to be used without killing QEMU.
>>>
>>> Also, special thanks to both Avi Kivity and Alexander Graf for their
>>> interpretation of QEMU backtraces. Without their guidence, tracking down
>>> this bug would have taken much longer.
>>>
>>> Signed-off-by: Richard Yao <ryao@gentoo.org>
>>> Acked-by: Alexander Graf <agraf@suse.de>
>>> Reviewed-by: Will Deacon <will.deacon@arm.com>
>>
>> Applied, thanks.
>
> Actually I had to revert, is_vmalloc_or_malloc_addr() is not exported to
> modules, so this change breaks the build.
Thanks for catching that. I had originally used is_vmalloc_addr() instead of is_vmalloc_or_malloc_addr(), but changed it after realizing this did not correct the problem on all architectures. The is_vmalloc_addr() lives in headers. I will send out a patch to get that symbol exported and resubmit this after it is merged.
^ permalink raw reply
* Re: kmem_cache_alloc panic in 3.10+
From: Eric Dumazet @ 2014-01-31 2:16 UTC (permalink / raw)
To: dormando; +Cc: netdev, linux-kernel, Alexei Starovoitov
In-Reply-To: <alpine.DEB.2.02.1401292301070.5905@dtop>
On Wed, 2014-01-29 at 23:05 -0800, dormando wrote:
> We hit the routing code fairly hard. Any hints for what to look at or how
> to instrument it? Or if it's fixed already? It's a real pain to iterate
> since it takes ~30 days to crash, usually. Sometimes.
I really wonder... it looks like a possible in SLUB. (might be already
fixed)
Could you try using SLAB instead ?
^ permalink raw reply
* Re: Help testing for USB ethernet/xHCI regression
From: Mark Lord @ 2014-01-31 2:32 UTC (permalink / raw)
To: Sarah Sharp
Cc: Paul Zimmerman, David Laight, renevant@internode.on.net,
linux-usb@vger.kernel.org, Greg Kroah-Hartman,
netdev@vger.kernel.org
In-Reply-To: <20140130232629.GF14228@xanatos>
On 14-01-30 06:26 PM, Sarah Sharp wrote:
> On Thu, Jan 30, 2014 at 05:20:40PM -0500, Mark Lord wrote:
>> On 14-01-30 04:41 PM, Sarah Sharp wrote:
>>>
>>> Mark and David, can you pull the 3.13-td-changes-reverted branch again,
>>> and see if the latest patch fixes your issue? It disables scatter
>>> gather for the ax88179_178a device, but only when it's operating at USB
>>> 3.0 speeds.
>>
>> As expected, this works just fine.
>
> Did it work when plugged into a USB 2.0 hub?
Curiosity, NO. Dies almost immediately when run at USB 2.0 Hi-Speed.
With a USB 2.0 hub, with a USB 2.0 port on a USB 3.0 hub,
and with a USB 2.0 extension cable in place of a hub.
Near instant hangs.
Plugged directly to the USB 3.0 port, it works fine.
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
* Re: kmem_cache_alloc panic in 3.10+
From: Alexei Starovoitov @ 2014-01-31 3:46 UTC (permalink / raw)
To: Eric Dumazet
Cc: dormando, netdev, linux-kernel@vger.kernel.org,
Alexei Starovoitov
In-Reply-To: <1391134615.28432.83.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Jan 30, 2014 at 6:16 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2014-01-29 at 23:05 -0800, dormando wrote:
>
>> We hit the routing code fairly hard. Any hints for what to look at or how
>> to instrument it? Or if it's fixed already? It's a real pain to iterate
>> since it takes ~30 days to crash, usually. Sometimes.
sounds like adding mdelay() didn't help to crash it sooner. Then I don't
see how my dst fix was causing it to crash more often. Something odd.
fyi just to check it more thoroughly I've been running with mdelay()
and config_slub_debug_on for a week without issues.
> I really wonder... it looks like a possible in SLUB. (might be already
> fixed)
>
> Could you try using SLAB instead ?
try config_slub_debug_on=y ? it should catch double free and other things.
^ permalink raw reply
* Re: kmem_cache_alloc panic in 3.10+
From: dormando @ 2014-01-31 3:52 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Eric Dumazet, netdev, linux-kernel@vger.kernel.org,
Alexei Starovoitov
In-Reply-To: <CAADnVQ+vCikFY-te2U8wD+ustNW-o6Cqs8ye5ZfyNcU6vPQzNA@mail.gmail.com>
> On Thu, Jan 30, 2014 at 6:16 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Wed, 2014-01-29 at 23:05 -0800, dormando wrote:
> >
> >> We hit the routing code fairly hard. Any hints for what to look at or how
> >> to instrument it? Or if it's fixed already? It's a real pain to iterate
> >> since it takes ~30 days to crash, usually. Sometimes.
>
> sounds like adding mdelay() didn't help to crash it sooner. Then I don't
> see how my dst fix was causing it to crash more often. Something odd.
> fyi just to check it more thoroughly I've been running with mdelay()
> and config_slub_debug_on for a week without issues.
Sorry, I'm actually trying to deal with two separate crashes at once :/
One is this 3.10.15 one, and one was the regression in 3.10.23 - I haven't
had time to attempt the mdelay test yet. The two crashes have fairly
distinct traces.
For what it's worth though the machines I have with that one patch
reverted are still running fine.
> > I really wonder... it looks like a possible in SLUB. (might be already
> > fixed)
> >
> > Could you try using SLAB instead ?
>
> try config_slub_debug_on=y ? it should catch double free and other things.
>
Any slowdowns/issues with that?
^ permalink raw reply
* [PATCH 1/2] rtl8192ce is disabling for too long the irqs
From: Olivier Langlois @ 2014-01-31 5:16 UTC (permalink / raw)
To: Larry.Finger, linville, chaoming_li
Cc: linux-wireless, netdev, linux-kernel, stable, Olivier Langlois
rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans
The observable symptoms in dmesg can be:
- underruns from ALSA playback
- clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled):
[ 250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100
[ 250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable
[ 250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10
[ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[ 250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32)
[ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0
[ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc
[ 250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!!
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x40000000, ofdm_index=0xc
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <===
[ 250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1
[ 250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3
[ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[ 250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore
[ 251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505)
The exact code flow that causes that is:
1. wpa_supplicant send a start_scan request to the nl80211 driver
2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE
3. rtl_ips_nic_on is called which disable local irqs
4. rtl92c_phy_set_rf_power_state() is called
5. rtl_ps_enable_nic() is called and hw_init()is executed and then the interrupts on the device are enabled
A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled
but a quick and dirty solution that has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
---
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index a82b30a..2eb0b38 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -937,14 +937,26 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
bool is92c;
int err;
u8 tmp_u1b;
+ unsigned long flags;
rtlpci->being_init_adapter = true;
+
+ /* Since this function can take a very long time (up to 350 ms)
+ * and can be called with irqs disabled, reenable the irqs
+ * to let the other devices continue being serviced.
+ *
+ * It is safe doing so since our own interrupts will only be enabled
+ * in a subsequent step.
+ */
+ local_save_flags(flags);
+ local_irq_enable();
+
rtlpriv->intf_ops->disable_aspm(hw);
rtstatus = _rtl92ce_init_mac(hw);
if (!rtstatus) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Init MAC failed\n");
err = 1;
- return err;
+ goto exit;
}
err = rtl92c_download_fw(hw);
@@ -952,7 +964,7 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
RT_TRACE(rtlpriv, COMP_ERR, DBG_WARNING,
"Failed to download FW. Init HW without FW now..\n");
err = 1;
- return err;
+ goto exit;
}
rtlhal->last_hmeboxnum = 0;
@@ -1032,6 +1044,8 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE, "under 1.5V\n");
}
rtl92c_dm_init(hw);
+exit:
+ local_irq_restore(flags);
rtlpci->being_init_adapter = false;
return err;
}
--
1.8.5.2
^ permalink raw reply related
* [PATCH 2/2] retry hw init when it fails
From: Olivier Langlois @ 2014-01-31 5:16 UTC (permalink / raw)
To: Larry.Finger, linville, chaoming_li
Cc: linux-wireless, netdev, linux-kernel, stable, Olivier Langlois
In-Reply-To: <1391145383-18652-1-git-send-email-olivier@trillion01.com>
rtl_ps_enable_nic() is called from loops that will loop until this function returns true or a
maximum number of retries is performed.
hw_init() returns non-zero on error. In that situation return false to
restore the original design intent to retry hw init when it fails.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
---
drivers/net/wireless/rtlwifi/ps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/ps.c b/drivers/net/wireless/rtlwifi/ps.c
index 0d81f76..a56e9b3 100644
--- a/drivers/net/wireless/rtlwifi/ps.c
+++ b/drivers/net/wireless/rtlwifi/ps.c
@@ -48,7 +48,7 @@ bool rtl_ps_enable_nic(struct ieee80211_hw *hw)
/*<2> Enable Adapter */
if (rtlpriv->cfg->ops->hw_init(hw))
- return 1;
+ return false;
RT_CLEAR_PS_LEVEL(ppsc, RT_RF_OFF_LEVL_HALT_NIC);
/*<3> Enable Interrupt */
--
1.8.5.2
^ permalink raw reply related
* Re: [PATCH] rtl8192ce is disabling the irqs for too long
From: Olivier Langlois @ 2014-01-31 5:16 UTC (permalink / raw)
To: Larry Finger
Cc: linville, chaoming_li, linux-wireless, netdev, linux-kernel,
mlang45
In-Reply-To: <52EAB3E6.2060809@lwfinger.net>
On Thu, 2014-01-30 at 14:19 -0600, Larry Finger wrote:
> On 01/30/2014 12:22 AM, Olivier Langlois wrote:
> > Signed-off-by: Olivier Langlois <olivier@trillion01.com>
> > ---
> > drivers/net/wireless/rtlwifi/ps.c | 2 +-
> > drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18 ++++++++++++++++--
> > 2 files changed, 17 insertions(+), 3 deletions(-)
>
> Olivier,
>
> I like the fact that you have proposed a solution that has minimal effect on the
> other PCI drivers under rtlwifi. That certainly decreases the amount of testing
> needed. Of course, all of them may need the same kind of fix.
This has been done on purpose. I knew that you would appreciate. The
problem is probably present with the other cards but since I could not
validate or test the patch with them, I have left them unchanged. If you
were to determine that it apply to all of them then maybe the patch
could be moved to ps.c to wrap hw_init() call.
>
> The changes are certainly minimal; however, I do need to test them before giving
> my Ack.
>
> As the problem(s) fixed by this patch will affect stable kernels, you should add
> a "Cc: Stable <stable@vger.kernel.org>" patch.
>
> Originally, I was going to have you add a comment to the commit message on why
> you were changing the return value in rtl_ps_enable_nic(), but now I am thinking
> that this should be a separate commit as it fixes a totally different bug. Yes
> it is involved with the callback to hw_init, but the bug is independent.
done. I am about to resend the patch splitted into 2 commits.
>
> Good work on finding this problem.
>
my pleasure. it has been fun and gratifying.
^ permalink raw reply
* Re: [PATCH 2/2] retry hw init when it fails
From: Greg KH @ 2014-01-31 5:29 UTC (permalink / raw)
To: Olivier Langlois
Cc: Larry.Finger, linville, chaoming_li, linux-wireless, netdev,
linux-kernel, stable
In-Reply-To: <1391145383-18652-2-git-send-email-olivier@trillion01.com>
On Fri, Jan 31, 2014 at 12:16:23AM -0500, Olivier Langlois wrote:
> rtl_ps_enable_nic() is called from loops that will loop until this function returns true or a
> maximum number of retries is performed.
>
> hw_init() returns non-zero on error. In that situation return false to
> restore the original design intent to retry hw init when it fails.
>
> Signed-off-by: Olivier Langlois <olivier@trillion01.com>
> ---
> drivers/net/wireless/rtlwifi/ps.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
Same goes for aptch 1/2 as well...
^ permalink raw reply
* [PATCH v2 0/4] OpenCores 10/100 MAC ethtool operations
From: Max Filippov @ 2014-01-31 5:41 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Ben Hutchings, Florian Fainelli, Marc Gauthier,
Max Filippov
Hello David, Ben, Florian and everybody,
this series implements ethtool callbacks for the ethoc driver as was
requested by Florian.
Changes v1->v2:
- fix {get,set}_settings return code in case there's no PHY;
- fix set_ringparam: check ring sizes, change ring sizes on the fly.
Max Filippov (4):
net: ethoc: implement basic ethtool operations
net: ethoc: implement ethtool get/set settings
net: ethoc: implement ethtool get registers
net: ethoc: implement ethtool get/set ring parameters
drivers/net/ethernet/ethoc.c | 101 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 101 insertions(+)
--
1.8.1.4
^ permalink raw reply
* [PATCH v2 2/4] net: ethoc: implement ethtool get/set settings
From: Max Filippov @ 2014-01-31 5:41 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Ben Hutchings, Florian Fainelli, Marc Gauthier,
Max Filippov
In-Reply-To: <1391146867-30508-1-git-send-email-jcmvbkbc@gmail.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
Changes v1->v2:
- fix {get,set}_settings return code in case there's no PHY.
drivers/net/ethernet/ethoc.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 0623c20..779d3c3 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -890,7 +890,31 @@ out:
return NETDEV_TX_OK;
}
+static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct ethoc *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phy;
+
+ if (!phydev)
+ return -EOPNOTSUPP;
+
+ return phy_ethtool_gset(phydev, cmd);
+}
+
+static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct ethoc *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phy;
+
+ if (!phydev)
+ return -EOPNOTSUPP;
+
+ return phy_ethtool_sset(phydev, cmd);
+}
+
const struct ethtool_ops ethoc_ethtool_ops = {
+ .get_settings = ethoc_get_settings,
+ .set_settings = ethoc_set_settings,
.get_link = ethtool_op_get_link,
.get_ts_info = ethtool_op_get_ts_info,
};
--
1.8.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox