* Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method
From: chetan loke @ 2012-03-26 15:07 UTC (permalink / raw)
To: Richard Cochran
Cc: Keller, Jacob E, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net, Kirsher, Jeffrey T,
Ronciak, John, john.stultz@linaro.org, tglx@linutronix.de
In-Reply-To: <20120324065147.GB2201@netboy.at.omicron.at>
On Sat, Mar 24, 2012 at 2:51 AM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Fri, Mar 23, 2012 at 03:39:08PM -0400, chetan loke wrote:
>>
>> So, how is it working today? Because we could have tx and rx
>> completions on different CPUs. Is it not possible to have the
>> following race today - between timecompare_update->timecompare_offset
>> -> timecounter_readdelta of say Rx and timecounter_cyc2time from Tx?
>
> I works (in the igb) because of the spinlock. You know, that thing
> that you are so against using.
>
I meant, was there a lock before the PHC functionality in igb?
>
>> How about rate limiting at the PHC class driver level? And then it
>> will work across the board for all the adapters at the device level.
>
> No, don't go there. Enough bikeshedding already. If you have a serious
can a user without root privileges use get/adj/set time ioctls for the
PHC functionality?
> Thanks,
> Richard
Chetan
^ permalink raw reply
* Re: [PATCH 1/2] wimax: i2400m - prevent a possible kernel bug due to missing fw_name string
From: Ben Hutchings @ 2012-03-26 14:57 UTC (permalink / raw)
To: Phil Sutter; +Cc: David Miller, netdev, inaky.perez-gonzalez
In-Reply-To: <1332761036-8913-1-git-send-email-phil.sutter@viprinet.com>
On Mon, 2012-03-26 at 13:23 +0200, Phil Sutter wrote:
> This happened on a machine with a custom hotplug script calling nameif,
> probably due to slow firmware loading. At the time nameif uses ethtool
> to gather interface information, i2400m->fw_name is zero and so a null
> pointer dereference occurs from within i2400m_get_drvinfo().
>
> Signed-off-by: Phil Sutter <phil.sutter@viprinet.com>
> ---
> drivers/net/wimax/i2400m/netdev.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wimax/i2400m/netdev.c b/drivers/net/wimax/i2400m/netdev.c
> index 64a1106..020bd8d 100644
> --- a/drivers/net/wimax/i2400m/netdev.c
> +++ b/drivers/net/wimax/i2400m/netdev.c
> @@ -607,7 +607,8 @@ static void i2400m_get_drvinfo(struct net_device *net_dev,
> struct i2400m *i2400m = net_dev_to_i2400m(net_dev);
>
> strncpy(info->driver, KBUILD_MODNAME, sizeof(info->driver) - 1);
> - strncpy(info->fw_version, i2400m->fw_name, sizeof(info->fw_version) - 1);
> + strncpy(info->fw_version,
> + i2400m->fw_name ? : "N/A", sizeof(info->fw_version) - 1);
Use an empty string, not "N/A".
Ben.
> if (net_dev->dev.parent)
> strncpy(info->bus_info, dev_name(net_dev->dev.parent),
> sizeof(info->bus_info) - 1);
--
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: [Question] Kernel preemption of BH handler
From: Ben Hutchings @ 2012-03-26 14:56 UTC (permalink / raw)
To: Erik Hugne; +Cc: netdev@vger.kernel.org
In-Reply-To: <4F7034EB.8010707@ericsson.com>
On Mon, 2012-03-26 at 11:20 +0200, Erik Hugne wrote:
> I have a BH handler that processes packets received from a netdevice.
>
> my_bh_handler() {
> spin_lock_bh(my_lock);
> /*do stuff*/
> spin_unlock_bh(my_lock);
> /*do more stuff*/
> }
spin_lock_bh() means 'spin lock with contending soft-interrupts' and not
'spin lock from a soft-interrupt'. You probably need to use it in
process context but not here.
> First packet is received, and my_bh_handler() is currently processing it.
> Now a new packet is received by the NIC and my_bh_handler() is preempted
> after my_lock have been released.
You don't explain how this handler is invoked, but normally it would be
scheduled to run a second time and would not preempt the first call.
Ben.
> Is it possible that the second invocation of the BH routine is allowed
> to finish before the first?
--
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] netdev: fix compile issues for !CONFIG_PCI in 3c59x
From: Sergei Shtylyov @ 2012-03-26 14:55 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: klassert, netdev, linux-mips, Paul Gortmaker
In-Reply-To: <CAP=VYLpOJOueFfzxFGCu5cKQ9--F8CqC5JWjBxej7u=8z3K0xQ@mail.gmail.com>
Hello.
On 03/26/2012 05:38 PM, Paul Gortmaker wrote:
>> I hate to add in more #ifdef CONFIG_PCI but there are already
>> quite a few in this driver, and it seems like it hasn't been
>> built with CONFIG_PCI set to off in quite some time.
> Actually, please scrap this patch. The uglyness of more ifdefs
> made me look at it again. It should be do-able in a cleaner way
> with stubs, and it appears this may even be similar to an old fail
> from the past:
> http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00109.html
Also, see this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0da0ead90122578ef6e4afba9ba4bcd3455fd8e8
The driver patch this was done for is still in the -mm tree after all these
years.:-)
> I'll dig into it some more and follow up.
I thought I addressed all issues with compilation of this driver with
CONFIG_PCI=n. Apparently not, and some seem to have accumulated over time...
> Thanks,
> Paul.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH V2 4/7] net/mlx4_en: Set max rate-limit for a TC
From: Ben Hutchings @ 2012-03-26 14:46 UTC (permalink / raw)
To: Amir Vadai
Cc: David S. Miller, netdev, Roland Dreier, Yevgeny Petrilin,
Oren Duer, Amir Vadai
In-Reply-To: <1332752874-8086-5-git-send-email-amirv@mellanox.com>
On Mon, 2012-03-26 at 11:07 +0200, Amir Vadai wrote:
> Set max rate-limit using sysfs file /sys/class/net/<interface>/ratelimit/tc<n>
> Values in Mbps units.
>
> For example, to set ratelimit of 5G to TC3 issue:
> echo 5000 > /sys/class/net/eth2/ratelimit/tc3
This looks the wrong way round; wouldn't a tc be an object with a
ratelimit as attribute?
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> ---
>
> We used sysfs since max bw isn't part of the ETS / DCBX NL support, and we're
> open to other suggestions to add generic support for max bw, e.g add call to
> the DCBX NL API.
[...]
netlink interfaces are generally easily extensible and it doesn't make
sense to me to augment such an interface through sysfs. Perhaps you're
concerned that netlink extensions won't be supported in older kernel
versions running your OOT driver? That's unfortunate, but let's not
standardise an ugly interface based on a temporary problem like that.
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
* [PATCH] USB: Add Motorola Rokr E6 Id to the USBNet driver "zaurus"
From: Guan Xin @ 2012-03-26 14:11 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Dave Jones, Guan Xin
From: Guan Xin <guanx.bac@gmail.com>
Added Vendor/Device Id of Motorola Rokr E6 (22b8:6027) so it can be
recognized by the "zaurus" USBNet driver.
Applies to Linux 3.2.13 and 2.6.39.4.
Signed-off-by: Guan Xin <guanx.bac@gmail.com>
---
--- a/drivers/net/usb/zaurus.c 2012-03-26 15:28:43.964244583 +0200
+++ b/drivers/net/usb/zaurus.c 2012-03-26 15:02:16.860801959 +0200
@@ -332,6 +332,11 @@ static const struct usb_device_id produc
.driver_info = ZAURUS_PXA_INFO,
},
{
+ /* Motorola Rokr E6 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x6027, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &bogus_mdlm_info,
+}, {
/* Motorola MOTOMAGX phones */
USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x6425, USB_CLASS_COMM,
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
^ permalink raw reply
* Re: [PATCH] net/garp: avoid infinite loop if attribute already exists
From: Ward, David - 0663 - MITLL @ 2012-03-26 14:11 UTC (permalink / raw)
To: jorge@dti2.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <4F7051B6.1030205@dti2.net>
[-- Attachment #1: Type: text/plain, Size: 3746 bytes --]
On 26/03/12 07:23, Jorge Boncompte [DTI2] wrote:
> El 26/03/2012 0:43, David Ward escribió:
>> An infinite loop occurred if garp_attr_create was called with the
>> values of an existing attribute. Return -EEXIST instead.
> I should have sent this some months ago but others things keep me from doing it.
> Anyway, I think that the right thing to do it's reuse the attribute to not
> disturb the switch/network. Also, returning an error it's pointless because
> nobody checks vlan_gvrp_request_join() return and you'll end up in a state where
> the VLAN device has the GVRP flag but it's not announcing the attribute.
I think what you are saying is that if we try to create an attribute
that already exists, we should leave the old attribute alone. I agree
with that, and the patch I sent does that. I also think the fact that
the attribute existed would likely indicate a bug in the GARP
application, in which we are not withdrawing an existing attribute when
we should. Your patch warns on this condition.
Our patches are mostly the same. One thing I notice with your patch is
that for new attributes, it now traverses the RB tree twice. And it
doesn't free the memory for a new attribute if it wasn't inserted into
the RB tree. So, what if instead I modified my patch to add
"WARN_ON(err)" to either garp_request_join or vlan_gvrp_request_join?
This would also warn us on -ENOMEM.
David
>
> Please take a look at the conversation I had with Patrick in the patch commit log.
>
> If you agree, I'm fine with you redoing your patch or David using mine if he
> thinks it's ok.
>
> Regards,
> Jorge
>
>> Signed-off-by: David Ward<david.ward@ll.mit.edu>
>> ---
>> net/802/garp.c | 18 +++++++++++++-----
>> 1 files changed, 13 insertions(+), 5 deletions(-)
>>
>> diff --git a/net/802/garp.c b/net/802/garp.c
>> index 8e21b6d..bb5015e 100644
>> --- a/net/802/garp.c
>> +++ b/net/802/garp.c
>> @@ -167,7 +167,7 @@ static struct garp_attr *garp_attr_lookup(const struct garp_applicant *app,
>> return NULL;
>> }
>>
>> -static void garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
>> +static int garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
>> {
>> struct rb_node *parent = NULL, **p =&app->gid.rb_node;
>> struct garp_attr *attr;
>> @@ -181,24 +181,32 @@ static void garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
>> p =&parent->rb_left;
>> else if (d> 0)
>> p =&parent->rb_right;
>> + else
>> + return -EEXIST;
>> }
>> rb_link_node(&new->node, parent, p);
>> rb_insert_color(&new->node,&app->gid);
>> + return 0;
>> }
>>
>> static struct garp_attr *garp_attr_create(struct garp_applicant *app,
>> const void *data, u8 len, u8 type)
>> {
>> struct garp_attr *attr;
>> + int err;
>>
>> attr = kmalloc(sizeof(*attr) + len, GFP_ATOMIC);
>> if (!attr)
>> - return attr;
>> + return PTR_ERR(-ENOMEM);
>> attr->state = GARP_APPLICANT_VO;
>> attr->type = type;
>> attr->dlen = len;
>> memcpy(attr->data, data, len);
>> - garp_attr_insert(app, attr);
>> + err = garp_attr_insert(app, attr);
>> + if (err< 0) {
>> + kfree(attr);
>> + return PTR_ERR(err);
>> + }
>> return attr;
>> }
>>
>> @@ -353,9 +361,9 @@ int garp_request_join(const struct net_device *dev,
>>
>> spin_lock_bh(&app->lock);
>> attr = garp_attr_create(app, data, len, type);
>> - if (!attr) {
>> + if (IS_ERR(attr)) {
>> spin_unlock_bh(&app->lock);
>> - return -ENOMEM;
>> + return ERR_PTR(attr);
>> }
>> garp_attr_event(app, attr, GARP_EVENT_REQ_JOIN);
>> spin_unlock_bh(&app->lock);
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4558 bytes --]
^ permalink raw reply
* Re: [PATCH] net/vlan: withdraw VLAN ID attribute from GVRP on VLAN device stop
From: Ward, David - 0663 - MITLL @ 2012-03-26 13:38 UTC (permalink / raw)
To: jorge@dti2.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <4F705329.10208@dti2.net>
On 26/03/12 07:29, Jorge Boncompte [DTI2] wrote:
> El 26/03/2012 0:43, David Ward escribió:
>> When a VLAN device is stopped which has VLAN_FLAG_GVRP set, the VLAN
>> ID attribute that was previously declared by GVRP must be withdrawn.
>>
> Hmm, maybe I am missing something but I think it only makes sense to withdrawn
> the attribute when you delete the interface, and vlan_dev_stop() it's called if
> you just put the interface down. It's better for the network convergence to not
> signal the switches just for this. IMHO.
If I bring a VLAN interface down, then I stop participating in the
VLAN. If my NIC still receives traffic for the VLAN, I drop it. So to
remove unnecessary load on the (potentially shared) network link and
remove unnecessary local processing by the kernel of packets I know I am
going to drop, I should tell the switch that I am no longer interested
in receiving the VLAN traffic. Which is the whole point of GVRP. Right?
In any case, we currently register the attribute when the interface is
brought up, not when it is created. However we do it, the attribute
declaration/withdrawal should be symmetric.
>
>> Signed-off-by: David Ward<david.ward@ll.mit.edu>
>> ---
>> net/8021q/vlan_dev.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
>> index 9988d4a..df86dd0 100644
>> --- a/net/8021q/vlan_dev.c
>> +++ b/net/8021q/vlan_dev.c
>> @@ -319,6 +319,9 @@ static int vlan_dev_stop(struct net_device *dev)
>> struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
>> struct net_device *real_dev = vlan->real_dev;
>>
>> + if (vlan->flags& VLAN_FLAG_GVRP)
>> + vlan_gvrp_request_leave(dev);
>> +
>> dev_mc_unsync(real_dev, dev);
>> dev_uc_unsync(real_dev, dev);
>> if (dev->flags& IFF_ALLMULTI)
^ permalink raw reply
* Re: [PATCH] netdev: fix compile issues for !CONFIG_PCI in 3c59x
From: Paul Gortmaker @ 2012-03-26 13:38 UTC (permalink / raw)
To: klassert; +Cc: netdev, linux-mips, Paul Gortmaker
In-Reply-To: <1332724306-8799-1-git-send-email-paul.gortmaker@windriver.com>
On Sun, Mar 25, 2012 at 9:11 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> I hate to add in more #ifdef CONFIG_PCI but there are already
> quite a few in this driver, and it seems like it hasn't been
> built with CONFIG_PCI set to off in quite some time.
Actually, please scrap this patch. The uglyness of more ifdefs
made me look at it again. It should be do-able in a cleaner way
with stubs, and it appears this may even be similar to an old fail
from the past:
http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00109.html
I'll dig into it some more and follow up.
Thanks,
Paul.
> The
> MIPS allmodconfig (ISA/EISA based) doesn't set CONFIG_PCI
> and that is why we are here looking at this, even though any
> modern platform has had PCI since 1995 or so.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> diff --git a/drivers/net/ethernet/3com/3c59x.c b/drivers/net/ethernet/3com/3c59x.c
> index e463d10..36ad150 100644
> --- a/drivers/net/ethernet/3com/3c59x.c
> +++ b/drivers/net/ethernet/3com/3c59x.c
> @@ -999,6 +999,7 @@ static int __init vortex_eisa_init(void)
> return vortex_cards_found - orig_cards_found + eisa_found;
> }
>
> +#ifdef CONFIG_PCI
> /* returns count (>= 0), or negative on error */
> static int __devinit vortex_init_one(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> @@ -1045,6 +1046,7 @@ static int __devinit vortex_init_one(struct pci_dev *pdev,
> out:
> return rc;
> }
> +#endif
>
> static const struct net_device_ops boomrang_netdev_ops = {
> .ndo_open = vortex_open,
> @@ -1177,6 +1179,7 @@ static int __devinit vortex_probe1(struct device *gendev,
> compaq_net_device = dev;
> }
>
> +#ifdef CONFIG_PCI
> /* PCI-only startup logic */
> if (pdev) {
> /* EISA resources already marked, so only PCI needs to do this here */
> @@ -1204,6 +1207,7 @@ static int __devinit vortex_probe1(struct device *gendev,
> }
> }
> }
> +#endif
>
> spin_lock_init(&vp->lock);
> spin_lock_init(&vp->mii_lock);
> @@ -1321,7 +1325,7 @@ static int __devinit vortex_probe1(struct device *gendev,
> step, (eeprom[4]>>5) & 15, eeprom[4] & 31, eeprom[4]>>9);
> }
>
> -
> +#ifdef CONFIG_PCI
> if (pdev && vci->drv_flags & HAS_CB_FNS) {
> unsigned short n;
>
> @@ -1348,6 +1352,7 @@ static int __devinit vortex_probe1(struct device *gendev,
> window_write16(vp, 0x0800, 0, 0);
> }
> }
> +#endif
>
> /* Extract our information from the EEPROM data. */
> vp->info1 = eeprom[13];
> @@ -3222,6 +3227,7 @@ static void acpi_set_WOL(struct net_device *dev)
> }
>
>
> +#ifdef CONFIG_PCI
> static void __devexit vortex_remove_one(struct pci_dev *pdev)
> {
> struct net_device *dev = pci_get_drvdata(pdev);
> @@ -3269,6 +3275,7 @@ static struct pci_driver vortex_driver = {
> .id_table = vortex_pci_tbl,
> .driver.pm = VORTEX_PM_OPS,
> };
> +#endif
>
>
> static int vortex_have_pci;
> @@ -3277,9 +3284,13 @@ static int vortex_have_eisa;
>
> static int __init vortex_init(void)
> {
> - int pci_rc, eisa_rc;
> + int eisa_rc;
> +#ifdef CONFIG_PCI
> + int pci_rc = pci_register_driver(&vortex_driver);
> +#else
> + int pci_rc = -ENODEV;
> +#endif
>
> - pci_rc = pci_register_driver(&vortex_driver);
> eisa_rc = vortex_eisa_init();
>
> if (pci_rc == 0)
> @@ -3318,8 +3329,10 @@ static void __exit vortex_eisa_cleanup(void)
>
> static void __exit vortex_cleanup(void)
> {
> +#ifdef CONFIG_PCI
> if (vortex_have_pci)
> pci_unregister_driver(&vortex_driver);
> +#endif
> if (vortex_have_eisa)
> vortex_eisa_cleanup();
> }
> --
> 1.7.9.4
>
>
^ permalink raw reply
* RE: [PATCH linux-next] dmaengine: add context parameter fixups
From: Bounine, Alexandre @ 2012-03-26 13:14 UTC (permalink / raw)
To: Vinod Koul, Mark Brown
Cc: Fabio Estevam, paul.gortmaker@windriver.com,
dan.j.williams@intel.com, samuel@sortiz.org, lrg@ti.com,
perex@perex.cz, tiwai@suse.de, linux-kernel@vger.kernel.org,
linux-next@vger.kernel.org, netdev@vger.kernel.org,
fabio.estevam@freescale.com, alsa-devel@alsa-project.org
In-Reply-To: <1332755670.19804.91.camel@vkoul-udesk3>
On Mon, March 26, 2012 at 5:55 AM, Vinod Koul wrote:
> Subject: Re: [PATCH linux-next] dmaengine: add context parameter fixups
>
> On Mon, 2012-03-26 at 10:42 +0100, Mark Brown wrote:
> > On Mon, Mar 26, 2012 at 11:04:42AM +0530, Vinod Koul wrote:
> > > On Sat, 2012-03-24 at 12:23 -0300, Fabio Estevam wrote:
> >
> > > > http://permalink.gmane.org/gmane.linux.alsa.devel/96215
> >
> > > And this seems to be linux-next.
> >
> > > Mark, Is this part of the sound updates that went to Linus?
> >
> > No, not yet - it was only sent after the merge window. Quite why
> nobody
> > managed to notice it before then I don't know. It'll go to him soon,
> or
> > at least to Takashi, but don't know if it'll make -rc1 or not.
> I should have noticed that sound needs update as well :(
>
> Now either I drop these from 3.4 or merge Linus's tree and apply
> Alexandre's fix (as that is the right fix rather than one in asoc tree)
> And since this was required for RIO patches which are still WIP, I
> think
> I am leaning towards former.
>
I do not see any sense in dropping these API changes now.
Some audio files have been missed form the original patch because I did
not have them in the code tree when patch was built.
For those who was not in the list for original patches here is a link to
the patch details: https://lkml.org/lkml/2012/3/8/373
If we drop the API changes now we will need redo these changes again later.
We already dragged these changes long enough since original discussion in October.
I will send new inline wrapper for RapidIO today.
Alex.
^ permalink raw reply
* [PATCH 2/2] wimax: i2400m-usb - use a private struct ethtool_ops
From: Phil Sutter @ 2012-03-26 11:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, inaky.perez-gonzalez
In-Reply-To: <1332761036-8913-1-git-send-email-phil.sutter@viprinet.com>
This way the USB variant of the driver uses usb_make_path in order to
provide bus-info compatible to other USB drivers (like e.g. asix.c).
Signed-off-by: Phil Sutter <phil.sutter@viprinet.com>
---
drivers/net/wimax/i2400m/usb.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wimax/i2400m/usb.c b/drivers/net/wimax/i2400m/usb.c
index 2c1b8b6..096a228 100644
--- a/drivers/net/wimax/i2400m/usb.c
+++ b/drivers/net/wimax/i2400m/usb.c
@@ -339,6 +339,23 @@ int i2400mu_bus_reset(struct i2400m *i2400m, enum i2400m_reset_type rt)
return result;
}
+static void i2400mu_get_drvinfo(struct net_device *net_dev,
+ struct ethtool_drvinfo *info)
+{
+ struct i2400m *i2400m = net_dev_to_i2400m(net_dev);
+ struct i2400mu *i2400mu = container_of(i2400m, struct i2400mu, i2400m);
+ struct usb_device *udev = i2400mu->usb_dev;
+
+ strncpy(info->driver, KBUILD_MODNAME, sizeof(info->driver) - 1);
+ strncpy(info->fw_version,
+ i2400m->fw_name ? : "N/A", sizeof(info->fw_version) - 1);
+ usb_make_path(udev, info->bus_info, sizeof(info->bus_info));
+}
+
+static const struct ethtool_ops i2400mu_ethtool_ops = {
+ .get_drvinfo = i2400mu_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+};
static
void i2400mu_netdev_setup(struct net_device *net_dev)
@@ -347,6 +364,7 @@ void i2400mu_netdev_setup(struct net_device *net_dev)
struct i2400mu *i2400mu = container_of(i2400m, struct i2400mu, i2400m);
i2400mu_init(i2400mu);
i2400m_netdev_setup(net_dev);
+ net_dev->ethtool_ops = &i2400mu_ethtool_ops;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2] wimax: i2400m - prevent a possible kernel bug due to missing fw_name string
From: Phil Sutter @ 2012-03-26 11:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, inaky.perez-gonzalez
This happened on a machine with a custom hotplug script calling nameif,
probably due to slow firmware loading. At the time nameif uses ethtool
to gather interface information, i2400m->fw_name is zero and so a null
pointer dereference occurs from within i2400m_get_drvinfo().
Signed-off-by: Phil Sutter <phil.sutter@viprinet.com>
---
drivers/net/wimax/i2400m/netdev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wimax/i2400m/netdev.c b/drivers/net/wimax/i2400m/netdev.c
index 64a1106..020bd8d 100644
--- a/drivers/net/wimax/i2400m/netdev.c
+++ b/drivers/net/wimax/i2400m/netdev.c
@@ -607,7 +607,8 @@ static void i2400m_get_drvinfo(struct net_device *net_dev,
struct i2400m *i2400m = net_dev_to_i2400m(net_dev);
strncpy(info->driver, KBUILD_MODNAME, sizeof(info->driver) - 1);
- strncpy(info->fw_version, i2400m->fw_name, sizeof(info->fw_version) - 1);
+ strncpy(info->fw_version,
+ i2400m->fw_name ? : "N/A", sizeof(info->fw_version) - 1);
if (net_dev->dev.parent)
strncpy(info->bus_info, dev_name(net_dev->dev.parent),
sizeof(info->bus_info) - 1);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] net/vlan: withdraw VLAN ID attribute from GVRP on VLAN device stop
From: Jorge Boncompte [DTI2] @ 2012-03-26 11:29 UTC (permalink / raw)
To: david.ward; +Cc: netdev
In-Reply-To: <1332715437-16278-2-git-send-email-david.ward@ll.mit.edu>
El 26/03/2012 0:43, David Ward escribió:
> When a VLAN device is stopped which has VLAN_FLAG_GVRP set, the VLAN
> ID attribute that was previously declared by GVRP must be withdrawn.
>
Hmm, maybe I am missing something but I think it only makes sense to withdrawn
the attribute when you delete the interface, and vlan_dev_stop() it's called if
you just put the interface down. It's better for the network convergence to not
signal the switches just for this. IMHO.
> Signed-off-by: David Ward <david.ward@ll.mit.edu>
> ---
> net/8021q/vlan_dev.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> index 9988d4a..df86dd0 100644
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -319,6 +319,9 @@ static int vlan_dev_stop(struct net_device *dev)
> struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
> struct net_device *real_dev = vlan->real_dev;
>
> + if (vlan->flags & VLAN_FLAG_GVRP)
> + vlan_gvrp_request_leave(dev);
> +
> dev_mc_unsync(real_dev, dev);
> dev_uc_unsync(real_dev, dev);
> if (dev->flags & IFF_ALLMULTI)
^ permalink raw reply
* Re: [PATCH] net/garp: avoid infinite loop if attribute already exists
From: Jorge Boncompte [DTI2] @ 2012-03-26 11:23 UTC (permalink / raw)
To: david.ward; +Cc: netdev
In-Reply-To: <1332715437-16278-1-git-send-email-david.ward@ll.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]
El 26/03/2012 0:43, David Ward escribió:
> An infinite loop occurred if garp_attr_create was called with the
> values of an existing attribute. Return -EEXIST instead.
I should have sent this some months ago but others things keep me from doing it.
Anyway, I think that the right thing to do it's reuse the attribute to not
disturb the switch/network. Also, returning an error it's pointless because
nobody checks vlan_gvrp_request_join() return and you'll end up in a state where
the VLAN device has the GVRP flag but it's not announcing the attribute.
Please take a look at the conversation I had with Patrick in the patch commit log.
If you agree, I'm fine with you redoing your patch or David using mine if he
thinks it's ok.
Regards,
Jorge
>
> Signed-off-by: David Ward <david.ward@ll.mit.edu>
> ---
> net/802/garp.c | 18 +++++++++++++-----
> 1 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/net/802/garp.c b/net/802/garp.c
> index 8e21b6d..bb5015e 100644
> --- a/net/802/garp.c
> +++ b/net/802/garp.c
> @@ -167,7 +167,7 @@ static struct garp_attr *garp_attr_lookup(const struct garp_applicant *app,
> return NULL;
> }
>
> -static void garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
> +static int garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
> {
> struct rb_node *parent = NULL, **p = &app->gid.rb_node;
> struct garp_attr *attr;
> @@ -181,24 +181,32 @@ static void garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
> p = &parent->rb_left;
> else if (d > 0)
> p = &parent->rb_right;
> + else
> + return -EEXIST;
> }
> rb_link_node(&new->node, parent, p);
> rb_insert_color(&new->node, &app->gid);
> + return 0;
> }
>
> static struct garp_attr *garp_attr_create(struct garp_applicant *app,
> const void *data, u8 len, u8 type)
> {
> struct garp_attr *attr;
> + int err;
>
> attr = kmalloc(sizeof(*attr) + len, GFP_ATOMIC);
> if (!attr)
> - return attr;
> + return PTR_ERR(-ENOMEM);
> attr->state = GARP_APPLICANT_VO;
> attr->type = type;
> attr->dlen = len;
> memcpy(attr->data, data, len);
> - garp_attr_insert(app, attr);
> + err = garp_attr_insert(app, attr);
> + if (err < 0) {
> + kfree(attr);
> + return PTR_ERR(err);
> + }
> return attr;
> }
>
> @@ -353,9 +361,9 @@ int garp_request_join(const struct net_device *dev,
>
> spin_lock_bh(&app->lock);
> attr = garp_attr_create(app, data, len, type);
> - if (!attr) {
> + if (IS_ERR(attr)) {
> spin_unlock_bh(&app->lock);
> - return -ENOMEM;
> + return ERR_PTR(attr);
> }
> garp_attr_event(app, attr, GARP_EVENT_REQ_JOIN);
> spin_unlock_bh(&app->lock);
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-PATCH-garp-fix-livelock-on-link-bouncing.patch --]
[-- Type: text/x-patch; name="0001-PATCH-garp-fix-livelock-on-link-bouncing.patch", Size: 5776 bytes --]
>From 9570dd1bd728399bf47722a9e966ace42d6441fa Mon Sep 17 00:00:00 2001
From: "Jorge Boncompte [DTI2]" <jorge@dti2.net>
Date: Mon, 26 Mar 2012 12:52:13 +0200
Subject: [PATCH] [PATCH] garp: fix livelock on link bouncing
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Fixes a bug in the GARP code when a VLAN interface changes from down
to up state quickly.
The tree insertion routine doesn't check that the attr it's still on
the tree and enters and infinite loop (livelocks).
Instead of returning an error we just reuse the existing attr to not
disturb the switch in front of us.
Conversation with Patrick follows...
El 30/11/2011 14:02, Patrick McHardy escribió:
> On 11/29/2011 06:01 PM, Jorge Boncompte [DTI2] wrote:
>> El 29/11/2011 14:50, Patrick McHardy escribió:
>>> On 11/28/2011 04:39 PM, Jorge Boncompte [DTI2] wrote:
>>>> El 28/11/2011 16:11, Patrick McHardy escribió:
>>>>> On 25.11.2011 18:13, Jorge Boncompte [DTI2] wrote:
>>>>>> Patrick, could you take a look at the attached patch? It fixes
>>>>>> a bug in the GARP code when you put a VLAN interface down/up in a
>>>>>> quick sucession. I've noticed it because some of my boxes where
>>>>>> hanging when moving interfaces between netns's.
>>>>> I'm not sure I understand the condition leading to this.
>>>>> Basically the GVRP join should only happen under the
>>>>> RTNL mutex, so I don't see how we can race during that.
>>>> It has nothing to do with the RTNL, the problem is that
>>>> garp_request_leave() arms the timer and the leave packet it's not sent
>>>> inmediately and the attribute it's still on the tree when the new
>>>> garp_request_join() happens, for example moving a VLAN interface from
>>>> netns or by a quick down/up sucession.
>>>> garp_attr_insert() doesn't handle the condition that the attr exists
>>>> already and livelocks in the while loop.
>>>>
>>>> So, instead of sending the leave packet synchronously from the
>>>> leave path I have opted for reinitializing the already existing
>>>> attribute that should not disturb the switch where we're attached.
>>> Yes, that seems like the better option. But I don't think this is fully
>>> correct (might be missing something though, it has been quite a while
>>> since I last worked on this code). If the applicant is in
>>> GARP_APPLICANT_LA state and a GARP_EVENT_TRANSMIT_PDU event is
>>> generated, the action will be GARP_ACTION_S_LEAVE_EMPTY, after which
>>> the attribute is destroyed immediately. Since we skip insertion with
>>> your patch, the attribute will incorrectly be gone. So I think what we
>>> need is either refcounting on the attribute to handle this case or
>>> alternatively send the message immediately.
>>>
>>> Does that make sense?
>> What you describe happens from the timer, after garp_request_leave()
>> has moved the applicant to _LA state and _REQ_LEAVE event. That's what
>> happens in the normal case when you put the interface down for example.
>>
>> In the case I describe the garp_request_join() comes betweeen the
>> call to garp_request_leave() and before the timer fires. The attr is
>> still on the tree so without my fix you livelock. With my changes
>> garp_request_join() calls garp_attr_create() that founds and return the
>> existing attr, and then calls garp_attr_event() with the _REQ_JOIN event.
>> This moves the attr from the _LA state to the _VA one. After that the
>> timer fires and founds the attr in the _VA state instead of _LA and so
>> the attr is not destroyed (and no need to refcount it).
>>
>> All this happens under the app->lock so the timer sees the attr on
>> the _LA state or on the VA state and in either case it does the right
>> thing from my POV. I am no expert on GARP but I've researched a bit the
>> protocol and the state transition from _LA to _VA looks ok to me.
>>
>> Here you have some output of a my patch with some test printk()'s
>> in case you can understand it better that my non-native english :)
>
> OK, this seems fine to me. If you change the WARN_ON to a
> WARN_ON(err) with err = garp_attr_insert(...) you can add
> my Acked-by: Patrick McHardy <kaber@trash.net>.
>
> Thanks!
Signed-off-by: Jorge Boncompte [DTI2] <jorge@dti2.net>
Acked-by: Patrick McHardy <kaber@trash.net>
---
net/802/garp.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/net/802/garp.c b/net/802/garp.c
index 8e21b6d..ad72ac4 100644
--- a/net/802/garp.c
+++ b/net/802/garp.c
@@ -167,7 +167,7 @@ static struct garp_attr *garp_attr_lookup(const struct garp_applicant *app,
return NULL;
}
-static void garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
+static int garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
{
struct rb_node *parent = NULL, **p = &app->gid.rb_node;
struct garp_attr *attr;
@@ -181,15 +181,24 @@ static void garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
p = &parent->rb_left;
else if (d > 0)
p = &parent->rb_right;
+ else
+ return -EEXIST;
}
rb_link_node(&new->node, parent, p);
rb_insert_color(&new->node, &app->gid);
+
+ return 0;
}
static struct garp_attr *garp_attr_create(struct garp_applicant *app,
const void *data, u8 len, u8 type)
{
struct garp_attr *attr;
+ int err;
+
+ attr = garp_attr_lookup(app, data, len, type);
+ if (attr)
+ return attr;
attr = kmalloc(sizeof(*attr) + len, GFP_ATOMIC);
if (!attr)
@@ -198,7 +207,10 @@ static struct garp_attr *garp_attr_create(struct garp_applicant *app,
attr->type = type;
attr->dlen = len;
memcpy(attr->data, data, len);
- garp_attr_insert(app, attr);
+ err = garp_attr_insert(app, attr);
+
+ WARN_ON(err);
+
return attr;
}
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Vinod Koul @ 2012-03-26 11:07 UTC (permalink / raw)
To: Mark Brown
Cc: fabio.estevam, alsa-devel, samuel, paul.gortmaker, tiwai, netdev,
linux-kernel, Alexandre Bounine, linux-next, dan.j.williams,
Fabio Estevam, lrg
In-Reply-To: <20120326110149.GL3098@opensource.wolfsonmicro.com>
On Mon, 2012-03-26 at 12:01 +0100, Mark Brown wrote:
> On Mon, Mar 26, 2012 at 04:18:26PM +0530, Vinod Koul wrote:
>
> > But we don't want the clients to use this additional parameter or be
> > exposed to it if not required. Every client is expected to use the
> > dmaengine wrappers for prepare and not invoke .device_ callbacks.
>
> Are those wrappers present in what's gone to Linus' tree, and can
> someone please send a patch to convert to using them?
Yes that are already there :-)
I will send sound specific update now
--
~Vinod
^ permalink raw reply
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Mark Brown @ 2012-03-26 11:01 UTC (permalink / raw)
To: Vinod Koul
Cc: fabio.estevam, alsa-devel, samuel, paul.gortmaker, tiwai, netdev,
linux-kernel, Alexandre Bounine, linux-next, dan.j.williams,
Fabio Estevam, lrg
In-Reply-To: <1332758906.19804.97.camel@vkoul-udesk3>
[-- Attachment #1.1: Type: text/plain, Size: 390 bytes --]
On Mon, Mar 26, 2012 at 04:18:26PM +0530, Vinod Koul wrote:
> But we don't want the clients to use this additional parameter or be
> exposed to it if not required. Every client is expected to use the
> dmaengine wrappers for prepare and not invoke .device_ callbacks.
Are those wrappers present in what's gone to Linus' tree, and can
someone please send a patch to convert to using them?
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Vinod Koul @ 2012-03-26 10:48 UTC (permalink / raw)
To: Mark Brown
Cc: fabio.estevam, alsa-devel, samuel, paul.gortmaker, tiwai, netdev,
linux-kernel, Alexandre Bounine, linux-next, dan.j.williams,
Fabio Estevam, lrg
In-Reply-To: <20120326103354.GD3098@opensource.wolfsonmicro.com>
On Mon, 2012-03-26 at 11:33 +0100, Mark Brown wrote:
> On Mon, Mar 26, 2012 at 03:24:30PM +0530, Vinod Koul wrote:
>
> > Now either I drop these from 3.4 or merge Linus's tree and apply
> > Alexandre's fix (as that is the right fix rather than one in asoc tree)
> > And since this was required for RIO patches which are still WIP, I think
> > I am leaning towards former.
>
> Gah, WTF is going on here? Has this API change not been sent to Linus
> already, and what is wrong with the changes which Fabio sent? I've
> already applied Fabio's change on the understanding that this API change
> done and dusted.
>
> It seems better to do a minimal fix at this point rather than churning
> things again...
The change is technically correct, so don't worry it wont break
anything, and API is frozen and not changing.
But we don't want the clients to use this additional parameter or be
exposed to it if not required. Every client is expected to use the
dmaengine wrappers for prepare and not invoke .device_ callbacks.
--
~Vinod
^ permalink raw reply
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Mark Brown @ 2012-03-26 10:33 UTC (permalink / raw)
To: Vinod Koul
Cc: Fabio Estevam, Alexandre Bounine, paul.gortmaker, dan.j.williams,
samuel, lrg, perex, tiwai, linux-kernel, linux-next, netdev,
fabio.estevam, alsa-devel
In-Reply-To: <1332755670.19804.91.camel@vkoul-udesk3>
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
On Mon, Mar 26, 2012 at 03:24:30PM +0530, Vinod Koul wrote:
> Now either I drop these from 3.4 or merge Linus's tree and apply
> Alexandre's fix (as that is the right fix rather than one in asoc tree)
> And since this was required for RIO patches which are still WIP, I think
> I am leaning towards former.
Gah, WTF is going on here? Has this API change not been sent to Linus
already, and what is wrong with the changes which Fabio sent? I've
already applied Fabio's change on the understanding that this API change
done and dusted.
It seems better to do a minimal fix at this point rather than churning
things again...
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* (From: Mrs. Mary kumba, Family Business Assistance Tel:+27-737535133 )
From: Tony Kumba @ 2012-03-26 10:07 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 31 bytes --]
Please view the attached letter
[-- Attachment #2: KUMBA`S FAMILY FROM ZIMBABWE.pdf --]
[-- Type: application/pdf, Size: 29531 bytes --]
^ permalink raw reply
* [PATCH] ppp: Don't stop and restart queue on every TX packet
From: David Woodhouse @ 2012-03-26 10:03 UTC (permalink / raw)
To: David Miller, Paul Mackerras; +Cc: netdev
In-Reply-To: <20120325.173635.1909319488008466320.davem@davemloft.net>
For every transmitted packet, ppp_start_xmit() will stop the netdev
queue and then, if appropriate, restart it. This causes the TX softirq
to run, entirely gratuitously.
This is "only" a waste of CPU time in the normal case, but it's actively
harmful when the PPP device is a TEQL slave — the wakeup will cause the
offending device to receive the next TX packet from the TEQL queue, when
it *should* have gone to the next slave in the list. We end up seeing
large bursts of packets on just *one* slave device, rather than using
the full available bandwidth over all slaves.
This patch fixes the problem by *not* unconditionally stopping the queue
in ppp_start_xmit(). It adds a return value from ppp_xmit_process()
which indicates whether the queue should be stopped or not.
It *doesn't* remove the call to netif_wake_queue() from
ppp_xmit_process(), because other code paths (especially from
ppp_output_wakeup()) need it there and it's messy to push it out to the
other callers to do it based on the return value. So we leave it in
place — it's a no-op in the case where the queue wasn't stopped, so it's
harmless in the TX path.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
--- drivers/net/ppp/ppp_generic.c~ 2012-01-26 00:39:32.000000000 +0000
+++ drivers/net/ppp/ppp_generic.c 2012-03-26 10:32:31.286744147 +0100
@@ -235,7 +235,7 @@ struct ppp_net {
/* Prototypes. */
static int ppp_unattached_ioctl(struct net *net, struct ppp_file *pf,
struct file *file, unsigned int cmd, unsigned long arg);
-static void ppp_xmit_process(struct ppp *ppp);
+static int ppp_xmit_process(struct ppp *ppp);
static void ppp_send_frame(struct ppp *ppp, struct sk_buff *skb);
static void ppp_push(struct ppp *ppp);
static void ppp_channel_push(struct channel *pch);
@@ -968,9 +968,9 @@ ppp_start_xmit(struct sk_buff *skb, stru
proto = npindex_to_proto[npi];
put_unaligned_be16(proto, pp);
- netif_stop_queue(dev);
skb_queue_tail(&ppp->file.xq, skb);
- ppp_xmit_process(ppp);
+ if (!ppp_xmit_process(ppp))
+ netif_stop_queue(dev);
return NETDEV_TX_OK;
outf:
@@ -1048,10 +1048,11 @@ static void ppp_setup(struct net_device
* Called to do any work queued up on the transmit side
* that can now be done.
*/
-static void
+static int
ppp_xmit_process(struct ppp *ppp)
{
struct sk_buff *skb;
+ int ret = 0;
ppp_xmit_lock(ppp);
if (!ppp->closing) {
@@ -1061,10 +1062,13 @@ ppp_xmit_process(struct ppp *ppp)
ppp_send_frame(ppp, skb);
/* If there's no work left to do, tell the core net
code that we can accept some more. */
- if (!ppp->xmit_pending && !skb_peek(&ppp->file.xq))
+ if (!ppp->xmit_pending && !skb_peek(&ppp->file.xq)) {
netif_wake_queue(ppp->dev);
+ ret = 1;
+ }
}
ppp_xmit_unlock(ppp);
+ return ret;
}
static inline struct sk_buff *
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Vinod Koul @ 2012-03-26 9:54 UTC (permalink / raw)
To: Mark Brown
Cc: Fabio Estevam, Alexandre Bounine, paul.gortmaker, dan.j.williams,
samuel, lrg, perex, tiwai, linux-kernel, linux-next, netdev,
fabio.estevam, alsa-devel
In-Reply-To: <20120326094200.GA3098@opensource.wolfsonmicro.com>
On Mon, 2012-03-26 at 10:42 +0100, Mark Brown wrote:
> On Mon, Mar 26, 2012 at 11:04:42AM +0530, Vinod Koul wrote:
> > On Sat, 2012-03-24 at 12:23 -0300, Fabio Estevam wrote:
>
> > > http://permalink.gmane.org/gmane.linux.alsa.devel/96215
>
> > And this seems to be linux-next.
>
> > Mark, Is this part of the sound updates that went to Linus?
>
> No, not yet - it was only sent after the merge window. Quite why nobody
> managed to notice it before then I don't know. It'll go to him soon, or
> at least to Takashi, but don't know if it'll make -rc1 or not.
I should have noticed that sound needs update as well :(
Now either I drop these from 3.4 or merge Linus's tree and apply
Alexandre's fix (as that is the right fix rather than one in asoc tree)
And since this was required for RIO patches which are still WIP, I think
I am leaning towards former.
--
~Vinod
^ permalink raw reply
* Re: [STRAW MAN PATCH] sch_teql doesn't load-balance ppp(oatm) slaves
From: David Woodhouse @ 2012-03-26 9:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1332750757.2379.38.camel@shinybook.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]
On Mon, 2012-03-26 at 09:32 +0100, David Woodhouse wrote:
> It does indeed stop the queue. I think it then wakes it right back up
> again in ppp_xmit_process(), *before* returning NETDEV_TX_OK. So the
> offending calls to skb_dequeue() which are putting it back to the front
> of the list are going to be from the softirq trying to feed the device.
A WARN_ON() in teql_dequeue() confirms that.
> I'll confirm that, then try fixing the PPP code so it doesn't stop and
> immediately restart the queue. If it only stops the queue
> *conditionally*, that may well fix the problem.
Yes, this gives me my full upload bandwidth by spreading packets over
both lines correctly, without touching sch_teql.c.
It returns a value from ppp_xmit_process() which indicates whether the
queue should be stopped. It doesn't actually *remove* the call to
netif_wake_queue(), because other code paths (especially from
ppp_output_wakeup()) still need it to be there. But if the queue wasn't
stopped anyway, it's a no-op. So we just make ppp_start_xmit() stop the
queue based on the return value of ppp_xmit_process(), and it all works
nicely without any of the gratuitous softirq invocations which are a
waste of time in the normal case, and actively harmful with teql.
--- drivers/net/ppp/ppp_generic.c~ 2012-01-26 00:39:32.000000000 +0000
+++ drivers/net/ppp/ppp_generic.c 2012-03-26 10:32:31.286744147 +0100
@@ -235,7 +235,7 @@ struct ppp_net {
/* Prototypes. */
static int ppp_unattached_ioctl(struct net *net, struct ppp_file *pf,
struct file *file, unsigned int cmd, unsigned long arg);
-static void ppp_xmit_process(struct ppp *ppp);
+static int ppp_xmit_process(struct ppp *ppp);
static void ppp_send_frame(struct ppp *ppp, struct sk_buff *skb);
static void ppp_push(struct ppp *ppp);
static void ppp_channel_push(struct channel *pch);
@@ -968,9 +968,9 @@ ppp_start_xmit(struct sk_buff *skb, stru
proto = npindex_to_proto[npi];
put_unaligned_be16(proto, pp);
- netif_stop_queue(dev);
skb_queue_tail(&ppp->file.xq, skb);
- ppp_xmit_process(ppp);
+ if (!ppp_xmit_process(ppp))
+ netif_stop_queue(dev);
return NETDEV_TX_OK;
outf:
@@ -1048,10 +1048,11 @@ static void ppp_setup(struct net_device
* Called to do any work queued up on the transmit side
* that can now be done.
*/
-static void
+static int
ppp_xmit_process(struct ppp *ppp)
{
struct sk_buff *skb;
+ int ret = 0;
ppp_xmit_lock(ppp);
if (!ppp->closing) {
@@ -1061,10 +1062,13 @@ ppp_xmit_process(struct ppp *ppp)
ppp_send_frame(ppp, skb);
/* If there's no work left to do, tell the core net
code that we can accept some more. */
- if (!ppp->xmit_pending && !skb_peek(&ppp->file.xq))
+ if (!ppp->xmit_pending && !skb_peek(&ppp->file.xq)) {
netif_wake_queue(ppp->dev);
+ ret = 1;
+ }
}
ppp_xmit_unlock(ppp);
+ return ret;
}
static inline struct sk_buff *
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5818 bytes --]
^ permalink raw reply
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Mark Brown @ 2012-03-26 9:42 UTC (permalink / raw)
To: Vinod Koul
Cc: Fabio Estevam, Alexandre Bounine, paul.gortmaker, dan.j.williams,
samuel, lrg, perex, tiwai, linux-kernel, linux-next, netdev,
fabio.estevam, alsa-devel
In-Reply-To: <1332740082.19804.15.camel@vkoul-udesk3>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On Mon, Mar 26, 2012 at 11:04:42AM +0530, Vinod Koul wrote:
> On Sat, 2012-03-24 at 12:23 -0300, Fabio Estevam wrote:
> > http://permalink.gmane.org/gmane.linux.alsa.devel/96215
> And this seems to be linux-next.
> Mark, Is this part of the sound updates that went to Linus?
No, not yet - it was only sent after the merge window. Quite why nobody
managed to notice it before then I don't know. It'll go to him soon, or
at least to Takashi, but don't know if it'll make -rc1 or not.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [Question] Kernel preemption of BH handler
From: Erik Hugne @ 2012-03-26 9:20 UTC (permalink / raw)
To: netdev@vger.kernel.org
I have a BH handler that processes packets received from a netdevice.
my_bh_handler() {
spin_lock_bh(my_lock);
/*do stuff*/
spin_unlock_bh(my_lock);
/*do more stuff*/
}
First packet is received, and my_bh_handler() is currently processing it.
Now a new packet is received by the NIC and my_bh_handler() is preempted
after my_lock have been released.
Is it possible that the second invocation of the BH routine is allowed
to finish before the first?
//E
^ permalink raw reply
* [PATCH V2 7/7] IB/rdma_cm: TOS <=> UP mapping for IBoE
From: Amir Vadai @ 2012-03-26 9:07 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Roland Dreier, Yevgeny Petrilin, Oren Duer, Amir Vadai,
Amir Vadai, Sean Hefty
In-Reply-To: <1332752874-8086-1-git-send-email-amirv@mellanox.com>
Both tagged traffic and untagged traffic use tc tool mapping.
Treat RDMA TOS same as IP TOS when mapping to SL
Signed-off-by: Amir Vadai <amirv@mellanox.com>
CC: Sean Hefty <sean.hefty@intel.com>
---
drivers/infiniband/core/cma.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index e3e470f..59fbd70 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -42,6 +42,7 @@
#include <linux/inetdevice.h>
#include <linux/slab.h>
#include <linux/module.h>
+#include <net/route.h>
#include <net/tcp.h>
#include <net/ipv6.h>
@@ -1826,7 +1827,10 @@ static int cma_resolve_iboe_route(struct rdma_id_private *id_priv)
route->path_rec->reversible = 1;
route->path_rec->pkey = cpu_to_be16(0xffff);
route->path_rec->mtu_selector = IB_SA_EQ;
- route->path_rec->sl = id_priv->tos >> 5;
+ route->path_rec->sl = netdev_get_prio_tc_map(
+ ndev->priv_flags & IFF_802_1Q_VLAN ?
+ vlan_dev_real_dev(ndev) : ndev,
+ rt_tos2priority(id_priv->tos));
route->path_rec->mtu = iboe_get_mtu(ndev->mtu);
route->path_rec->rate_selector = IB_SA_EQ;
--
1.7.8.2
^ 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