* Re: RX/close vcc race with solos/atmtcp/usbatm/he
From: David Woodhouse @ 2010-05-28 13:33 UTC (permalink / raw)
To: David Miller; +Cc: linux-atm-general, netdev, nathan
In-Reply-To: <20100528.034628.200383563.davem@davemloft.net>
On Fri, 2010-05-28 at 03:46 -0700, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Wed, 26 May 2010 12:16:24 +0100
>
> > Can anyone see a better approach -- short of rewriting the whole ATM
> > layer to make the locking saner?
>
> There is no doubt in my mind that these VCC objects need to be
> refcounted when used like this.
Perhaps. Although in the general case they're tied to the 'struct sock'
and don't need to outlive it. These drivers which look up the VCC to
feed incoming packets to it are the only exception to that rule that I'm
aware of.
> The only other alternative is to make use of something like RCU.
I agree. In fact the use of tasklet_unlock_wait() in my patch is what I
settled on when I went looking for 'something like RCU' to solve this
particular case. I was _going_ to add RCU stuff, but realised that this
was sufficient.
In the close() path we clear the READY bit in the VCC, wait for the
tasklet to finish using it, and only then do we destroy the VCC.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH v3] can: Add driver for esd CAN-USB/2 device
From: Matthias Fuchs @ 2010-05-28 14:19 UTC (permalink / raw)
To: Oliver Neukum
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201005261547.34596.oneukum-l3A5Bk7waGM@public.gmane.org>
On Wednesday 26 May 2010 15:47, Oliver Neukum wrote:
> Am Mittwoch, 26. Mai 2010 11:14:03 schrieb Matthias Fuchs:
> > + netdev->trans_start = jiffies;
> > +
> > + /* Slow down tx path */
> > + if (atomic_read(&priv->active_tx_jobs) >= MAX_TX_URBS)
> > + netif_stop_queue(netdev);
>
> Where is the queue started again?
>
> Regards
> Oliver
This is done in the ack-patch for sent messages:
static void esd_usb2_tx_done_msg(struct esd_usb2_net_priv *priv,
struct esd_usb2_msg *msg)
{
...
atomic_dec(&priv->active_tx_jobs);
netif_wake_queue(netdev);
}
Matthias
^ permalink raw reply
* Re: [PATCH] netdev/fec: fix ifconfig eth0 down hang issue
From: Wolfram Sang @ 2010-05-28 14:45 UTC (permalink / raw)
To: Bryan Wu
Cc: davem, afleming, s.hauer, gerg, amit.kucheria, netdev,
linux-kernel
In-Reply-To: <1275037685-14555-1-git-send-email-bryan.wu@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
On Fri, May 28, 2010 at 05:08:05PM +0800, Bryan Wu wrote:
> BugLink: http://bugs.launchpad.net/bugs/559065
>
> In fec open/close function, we need to use phy_connect and phy_disconnect
> operation before we start/stop phy. Otherwise it will cause system hang.
>
> Only call fec_enet_mii_probe() in open function, because the first open
> action will cause NULL pointer error.
>
> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
We use this patch for 1 month now and didn't encounter any flaws so far.
Tested-by: Wolfram Sang <w.sang@pengutronix.de>
Oops, too late... well, one for the comfortable feeling ;)
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* MDNS is broken in latest -git
From: Maxim Levitsky @ 2010-05-28 15:02 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; +Cc: linux-wireless
On latest git, it became impossible to use hostname.local alias to
access my network hosts.
In fact when I look at 'avahi-discover' I see nothing but local
services.
I did a bisect, but unfortunely ended with merge commit, although
bisection seem to be normal (and I didn't do any shortcuts).
I own a iwl3945 wireless card.
The bisection log:
git bisect start
# good: [537b60d17894b7c19a6060feae40299d7109d6e7] Merge branch 'x86-uv-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect good 537b60d17894b7c19a6060feae40299d7109d6e7
# bad: [d515e86e639890b33a09390d062b0831664f04a2] Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-udf-2.6
git bisect bad d515e86e639890b33a09390d062b0831664f04a2
# good: [a26272e5200765691e67d6780e52b32498fdb659] Merge branch 'docs-next' of git://git.lwn.net/linux-2.6
git bisect good a26272e5200765691e67d6780e52b32498fdb659
# good: [10fc51b9953112ade61e33ff2f6f005f005a2361] skge: use the DMA state API instead of the pci equivalents
git bisect good 10fc51b9953112ade61e33ff2f6f005f005a2361
# bad: [c316ba3b518bc35ce5aef5421135220389f4eb98] Merge branch 'linux-next' of git://git.infradead.org/ubi-2.6
git bisect bad c316ba3b518bc35ce5aef5421135220389f4eb98
# bad: [7a9b149212f3716c598afe973b6261fd58453b7a] Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6
git bisect bad 7a9b149212f3716c598afe973b6261fd58453b7a
# good: [726ef428af41b1fbdf569772ab73de0844c4e0f2] USB: belkin_sa: minor clean-ups
git bisect good 726ef428af41b1fbdf569772ab73de0844c4e0f2
# good: [6fe70aae0d128339febfabc073ba4c4a03de4f45] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem
git bisect good 6fe70aae0d128339febfabc073ba4c4a03de4f45
# bad: [57b610805ce92dbd79fc97509f80fa5391b99623] net: Add netlink support for virtual port management (was iovnl)
git bisect bad 57b610805ce92dbd79fc97509f80fa5391b99623
# good: [78ad38923094a479453f5b02b37a012377a36f34] qlcnic: fix internal loopback test
git bisect good 78ad38923094a479453f5b02b37a012377a36f34
# good: [e1bc7eedbafe0415cdfd82e17e6f65bb3369239d] atm: select FW_LOADER in Kconfig for solos-pci
git bisect good e1bc7eedbafe0415cdfd82e17e6f65bb3369239d
# bad: [eedf042a63ffef050ebc015de19b52dc065e830b] ipv6: fix the bug of address check
git bisect bad eedf042a63ffef050ebc015de19b52dc065e830b
# good: [99bf236612801351834b441314379bc5304d62ce] drivers/net/usb: Use kmemdup
git bisect good 99bf236612801351834b441314379bc5304d62ce
# good: [380fefb2ddabd4cd5f14dbe090481f0544e65078] dm9000: fix "BUG: spinlock recursion"
git bisect good 380fefb2ddabd4cd5f14dbe090481f0544e65078
# bad: [820ae8a80eb59962aefbbd4908dfe144ec0f9edb] Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
git bisect bad 820ae8a80eb59962aefbbd4908dfe144ec0f9edb
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] workqueue: Add an API to create a singlethread workqueue attached to the current task's cgroup
From: Michael S. Tsirkin @ 2010-05-28 15:08 UTC (permalink / raw)
To: Tejun Heo
Cc: Oleg Nesterov, Sridhar Samudrala, netdev, lkml,
kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev, Jiri Kosina,
Thomas Gleixner, Ingo Molnar, Andi Kleen
In-Reply-To: <4BFEE216.2070807@kernel.org>
On Thu, May 27, 2010 at 11:20:22PM +0200, Tejun Heo wrote:
> Hello, Michael.
>
> On 05/27/2010 07:32 PM, Michael S. Tsirkin wrote:
> > Well, this is why I proposed adding a new API for creating
> > workqueue within workqueue.c, rather than exposing the task
> > and attaching it to cgroups in our driver: so that workqueue
> > maintainers can fix the implementation if it ever changes.
> >
> > And after all, it's an internal API, we can always change
> > it later if we need.
> ...
> > Well, yes but we are using APIs like flush_work etc. These are very
> > handy. It seems much easier than rolling our own queue on top of kthread.
>
> The thing is that this kind of one-off usage becomes problemetic when
> you're trying to change the implementation detail. All current
> workqueue users don't care which thread they run on and they shouldn't
> as each work owns the context only for the duration the work is
> executing. If this sort of fundamental guidelines are followed, the
> implementation can be improved in pretty much transparent way but when
> you start depending on specific implementation details, things become
> messy pretty quickly.
>
> If this type of usage were more common, adding proper way to account
> work usage according to cgroups would make sense but that's not the
> case here and I removed the only exception case recently while trying
> to implement cmwq and if this is added. So, this would be the only
> one which makes such extra assumptions in the whole kernel. One way
> or the other, workqueue needs to be improved and I don't really think
> adding the single exception at this point is a good idea.
>
> The thing I realized after stop_machine conversion was that there was
> no reason to use workqueue there at all. There already are more than
> enough not-too-difficult synchronization constructs and if you're
> using a thread for dedicated purposes, code complexity isn't that
> different either way. Plus, it would also be clearer that dedicated
> threads are required there for what reason. So, I strongly suggest
> using a kthread. If there are issues which are noticeably difficult
> to solve with kthread, we can definitely talk about that and think
> about things again.
>
> Thank you.
Well, we have create_singlethread_workqueue, right?
This is not very different ... is it?
Just copying structures and code from workqueue.c,
adding vhost_ in front of it will definitely work:
there is nothing magic about the workqueue library.
But this just involves cut and paste which might be best avoided.
One final idea before we go the cut and paste way: how about
'create_workqueue_from_task' that would get a thread and have workqueue
run there?
> --
> tejun
^ permalink raw reply
* Re: [PATCH] netdev/fec: fix ifconfig eth0 down hang issue
From: Bryan Wu @ 2010-05-28 15:13 UTC (permalink / raw)
To: Wolfram Sang
Cc: davem, afleming, s.hauer, gerg, amit.kucheria, netdev,
linux-kernel
In-Reply-To: <20100528144506.GB13777@pengutronix.de>
On 05/28/2010 10:45 PM, Wolfram Sang wrote:
> On Fri, May 28, 2010 at 05:08:05PM +0800, Bryan Wu wrote:
>> BugLink: http://bugs.launchpad.net/bugs/559065
>>
>> In fec open/close function, we need to use phy_connect and phy_disconnect
>> operation before we start/stop phy. Otherwise it will cause system hang.
>>
>> Only call fec_enet_mii_probe() in open function, because the first open
>> action will cause NULL pointer error.
>>
>> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
>
> We use this patch for 1 month now and didn't encounter any flaws so far.
>
> Tested-by: Wolfram Sang <w.sang@pengutronix.de>
>
> Oops, too late... well, one for the comfortable feeling ;)
>
Thanks a lot, Wolfram. You are real helpful here.
Because my babbage board has broken for several weeks, I don't have hardware to
test my FEC patches.
The performance drop issue still hangs in my brain. As soon as I have a new
patch, could you please help to test? Or do you guys found any performance drop
solution on your hardware? IIRC, you reported similar issue as us.
Best regards,
--
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer +86.138-1617-6545 Mobile
Ubuntu Kernel Team | Hardware Enablement Team
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
^ permalink raw reply
* Re: [PATCH v3] can: Add driver for esd CAN-USB/2 device
From: Matthias Fuchs @ 2010-05-28 15:25 UTC (permalink / raw)
To: Viral Mehta
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <70376CA23424B34D86F1C7DE6B9973430254343AD9-fVvhrSDAkVjuuPCCJ6VnObSn4PsL5ZDKvpI+GvaZM4lBDgjK7y7TUQ@public.gmane.org>
Hi Viral,
thanks for review. Please see some comments below.
On Wednesday 26 May 2010 13:31, Viral Mehta wrote:
> Hi,
> >________________________________________
> >From: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Matthias Fuchs [matthias.fuchs-iOnpLzIbIdM@public.gmane.org]
> >Sent: Wednesday, May 26, 2010 2:44 PM
> >To: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >Subject: [PATCH v3] can: Add driver for esd CAN-USB/2 device
> >+
> >+ BUG_ON(!context);
>
> It is preferred to used WARN_ON and avoid using BUG_ON and thus dont kill the whole system....
Really? Even when next line will reference a NULL pointer in this case? Ok. Will be changed.
> [...]
> >+
> >+ priv = context->priv;
> >+ netdev = priv->netdev;
> >+ dev = priv->usb2;
> >+ err = usb_submit_urb(urb, GFP_ATOMIC);
> >+ if (err) {
> >+ can_free_echo_skb(netdev, context->echo_index);
> >+
> >+ atomic_dec(&priv->active_tx_jobs);
> >+ usb_unanchor_urb(urb);
> >+
> >+ stats->tx_dropped++;
> >+
> >+ if (err == -ENODEV)
> >+ netif_device_detach(netdev);
> >+ else
> >+ dev_warn(netdev->dev.parent, "failed tx_urb %d\n", err);
> >+
> >+ goto releasebuf;
>
> You probably want to set "ret" here or do you really want to return NETDEV_TX_OK
As far as I can see netword device drivers xmit_start() return NETDEV_TX_OK or _BUSY.
There are no real alternatives. But please correct me when I am wrong.
Your other comments will be fixed by version 4 of my patch.
Matthias
^ permalink raw reply
* Re: [PATCH v3] can: Add driver for esd CAN-USB/2 device
From: Oliver Neukum @ 2010-05-28 15:26 UTC (permalink / raw)
To: Matthias Fuchs; +Cc: netdev, Socketcan-core, linux-usb
In-Reply-To: <201005281619.33845.matthias.fuchs@esd.eu>
Am Freitag, 28. Mai 2010 16:19:33 schrieb Matthias Fuchs:
> On Wednesday 26 May 2010 15:47, Oliver Neukum wrote:
> > Am Mittwoch, 26. Mai 2010 11:14:03 schrieb Matthias Fuchs:
> > > + netdev->trans_start = jiffies;
> > > +
> > > + /* Slow down tx path */
> > > + if (atomic_read(&priv->active_tx_jobs) >= MAX_TX_URBS)
> > > + netif_stop_queue(netdev);
> >
> > Where is the queue started again?
> >
> > Regards
> > Oliver
>
> This is done in the ack-patch for sent messages:
>
> static void esd_usb2_tx_done_msg(struct esd_usb2_net_priv *priv,
> struct esd_usb2_msg *msg)
> {
> ...
> atomic_dec(&priv->active_tx_jobs);
>
> netif_wake_queue(netdev);
> }
Oh, I see. I am afraid this is a race. You have no guarantee that
esd_usb2_tx_done_msg() runs after you stop the queue. If you do
it that way you must stop the queue before you submit the URB
due to which you want to stop it (and do the error handling)
Regards
Oliver
^ permalink raw reply
* Re: [PATCH 1/2] Export firmware assigned labels of network devices to sysfs
From: Greg KH @ 2010-05-28 15:40 UTC (permalink / raw)
To: K, Narendra
Cc: netdev@vger.kernel.org, linux-hotplug@vger.kernel.org,
linux-pci@vger.kernel.org, Domsch, Matt, Hargrave, Jordan,
Rose, Charles, Nijhawan, Vijay
In-Reply-To: <20100528115520.GA24114@littleblue.us.dell.com>
On Fri, May 28, 2010 at 06:55:21AM -0500, K, Narendra wrote:
> Please refer to the PCI-SIG Draft ECN
> "PCIe Device Labeling under Operating Systems Draft ECN" at this link -
> http://www.pcisig.com/specifications/pciexpress/review_zone/.
>
> It would be great to know your views on this ECN. Please let us know if you have
> have any suggestions or changes.
Note that only members of the PCI-SIG can do this, which pretty much
rules out any "normal" Linux kernel developer :(
Care to post a public version of this for us to review?
> --- /dev/null
> +++ b/drivers/pci/pci-label.c
> @@ -0,0 +1,242 @@
> +/*
> + * File: drivers/pci/pci-label.c
This line is not needed, we know the file name :)
> + * Purpose: Export the firmware label associated with a pci network interface
> + * device to sysfs
> + * Copyright (C) 2010 Dell Inc.
> + * by Narendra K <Narendra_K@dell.com>, Jordan Hargrave <Jordan_Hargrave@dell.com>
> + *
> + * This code checks if the pci network device has a related ACPI _DSM. If
> + * available, the code calls the _DSM to retrieve the index and string and
> + * exports them to sysfs. If the ACPI _DSM is not available, it falls back on
> + * SMBIOS. SMBIOS defines type 41 for onboard pci devices. This code retrieves
> + * strings associated with the type 41 and exports it to sysfs.
> + *
> + * Please see http://linux.dell.com/wiki/index.php/Oss/libnetdevname for more
> + * information.
> + */
> +
> +#include <linux/pci-label.h>
Why is this file in include/linux/ ? Who needs it there? Can't it just
be in in the drivers/pci/ directory? Actually all you need is 2
functions in there, so it could go into the internal pci.h file in that
directory without a problem, right?
> +
> +static ssize_t
> +smbiosname_string_exists(struct device *dev, char *buf)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> + const struct dmi_device *dmi;
> + struct dmi_devslot *dslot;
> + int bus;
> + int devfn;
> +
> + bus = pdev->bus->number;
> + devfn = pdev->devfn;
> +
> + dmi = NULL;
> + while ((dmi = dmi_find_device(DMI_DEV_TYPE_DEVSLOT, NULL, dmi)) != NULL) {
> + dslot = dmi->device_data;
> + if (dslot && dslot->bus == bus && dslot->devfn == devfn) {
> + if (buf)
> + return scnprintf(buf, PAGE_SIZE, "%s\n", dmi->name);
> + return strlen(dmi->name);
> + }
> + }
> +
> + return 0;
> +}
> +
> +static ssize_t
> +smbiosname_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + return smbiosname_string_exists(dev, buf);
> +}
> +
> +struct smbios_attribute smbios_attr_label = {
> + .attr = {.name = __stringify(label), .mode = 0444, .owner = THIS_MODULE},
Can't you just put "label" as the name?
> + .show = smbiosname_show,
> + .test = smbiosname_string_exists,
> +};
> +
> +static int
> +pci_create_smbiosname_file(struct pci_dev *pdev)
> +{
> + if (smbios_attr_label.test && smbios_attr_label.test(&pdev->dev, NULL)) {
> + sysfs_create_file(&pdev->dev.kobj, &smbios_attr_label.attr);
> + return 0;
> + }
> + return -1;
> +}
> +
> +static int
> +pci_remove_smbiosname_file(struct pci_dev *pdev)
> +{
> + if (smbios_attr_label.test && smbios_attr_label.test(&pdev->dev, NULL)) {
> + sysfs_remove_file(&pdev->dev.kobj, &smbios_attr_label.attr);
> + return 0;
> + }
> + return -1;
> +}
> +
> +static const char dell_dsm_uuid[] = {
Um, a dell specific uuid in a generic file? What happens when we need
to support another manufacturer?
> + 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
> + 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
> +};
> +
> +
> +static int
> +dsm_get_label(acpi_handle handle, int func,
> + struct acpi_buffer *output,
> + char *buf, char *attribute)
> +{
> + struct acpi_object_list input;
> + union acpi_object params[4];
> + union acpi_object *obj;
> + int len = 0;
> +
> + int err;
> +
> + input.count = 4;
> + input.pointer = params;
> + params[0].type = ACPI_TYPE_BUFFER;
> + params[0].buffer.length = sizeof(dell_dsm_uuid);
> + params[0].buffer.pointer = (char *)dell_dsm_uuid;
> + params[1].type = ACPI_TYPE_INTEGER;
> + params[1].integer.value = 0x02;
> + params[2].type = ACPI_TYPE_INTEGER;
> + params[2].integer.value = func;
> + params[3].type = ACPI_TYPE_PACKAGE;
> + params[3].package.count = 0;
> + params[3].package.elements = NULL;
> +
> + err = acpi_evaluate_object(handle, "_DSM", &input, output);
> + if (err) {
> + printk(KERN_INFO "failed to evaulate _DSM\n");
> + return -1;
> + }
> +
> + obj = (union acpi_object *)output->pointer;
> +
> + switch (obj->type) {
> + case ACPI_TYPE_PACKAGE:
> + if (obj->package.count == 2) {
> + len = obj->package.elements[0].integer.value;
> + if (buf) {
> + if (!strncmp(attribute, "index", strlen(attribute)))
> + scnprintf(buf, PAGE_SIZE, "%lu\n",
> + obj->package.elements[0].integer.value);
> + else
> + scnprintf(buf, PAGE_SIZE, "%s\n",
> + obj->package.elements[1].string.pointer);
> + kfree(output->pointer);
> + return strlen(buf);
> + }
> + }
> + kfree(output->pointer);
> + return len;
> + break;
> + default:
> + return -1;
> + }
> +}
> +
> +static ssize_t
> +acpi_index_string_exist(struct device *dev, char *buf, char *attribute)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
> + acpi_handle handle;
> + int length;
> + int is_addin_card = 0;
> +
> + if ((pdev->class >> 16) != PCI_BASE_CLASS_NETWORK)
> + return -1;
> +
> + handle = DEVICE_ACPI_HANDLE(dev);
> +
> + if (!handle) {
> + /*
> + * The device is an add-in network controller and does have
> + * a valid handle. Try until we get the handle for the parent
> + * bridge
> + */
> + struct pci_bus *pbus;
> + for (pbus = pdev->bus; pbus; pbus = pbus->parent) {
> + handle = DEVICE_ACPI_HANDLE(&(pbus->self->dev));
> + if (handle)
> + break;
> +
> + }
> + }
> +
> + if ((length = dsm_get_label(handle, DELL_DSM_NETWORK,
> + &output, buf, attribute)) < 0)
> + return -1;
> +
> + return length;
> +}
> +
> +static ssize_t
> +acpilabel_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + return acpi_index_string_exist(dev, buf, "label");
> +}
> +
> +static ssize_t
> +acpiindex_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + return acpi_index_string_exist(dev, buf, "index");
> +}
> +
> +struct acpi_attribute acpi_attr_label = {
> + .attr = {.name = __stringify(label), .mode = 0444, .owner = THIS_MODULE},
> + .show = acpilabel_show,
> + .test = acpi_index_string_exist,
> +};
> +
> +struct acpi_attribute acpi_attr_index = {
> + .attr = {.name = __stringify(index), .mode = 0444, .owner = THIS_MODULE},
> + .show = acpiindex_show,
> + .test = acpi_index_string_exist,
> +};
> +
> +static int
> +pci_create_acpi_index_label_files(struct pci_dev *pdev)
> +{
> + if (acpi_attr_label.test && acpi_attr_label.test(&pdev->dev, NULL) > 0) {
> + sysfs_create_file(&pdev->dev.kobj, &acpi_attr_label.attr);
> + sysfs_create_file(&pdev->dev.kobj, &acpi_attr_index.attr);
> + return 0;
> + }
> + return -1;
> +}
> +
> +static int
> +pci_remove_acpi_index_label_files(struct pci_dev *pdev)
> +{
> + if (acpi_attr_label.test && acpi_attr_label.test(&pdev->dev, NULL) > 0) {
> + sysfs_remove_file(&pdev->dev.kobj, &acpi_attr_label.attr);
> + sysfs_remove_file(&pdev->dev.kobj, &acpi_attr_index.attr);
> + return 0;
> + }
> + return -1;
> +}
> +
> +int pci_create_acpi_attr_files(struct pci_dev *pdev)
> +{
> + if (!pci_create_acpi_index_label_files(pdev))
> + return 0;
> + if (!pci_create_smbiosname_file(pdev))
> + return 0;
> + return -ENODEV;
> +}
> +EXPORT_SYMBOL(pci_create_acpi_attr_files);
EXPORT_SYMBOL_GPL?
Wait, why does this need to be exported at all? What module is ever
going to call this function?
> +int pci_remove_acpi_attr_files(struct pci_dev *pdev)
> +{
> + if (!pci_remove_acpi_index_label_files(pdev))
> + return 0;
> + if (!pci_remove_smbiosname_file(pdev))
> + return 0;
> + return -ENODEV;
> +
> +}
> +EXPORT_SYMBOL(pci_remove_acpi_attr_files);
Same here, what module will call this?
> +++ b/include/linux/pci-label.h
As discussed above, this whole file does not need to exist.
> +extern int pci_create_acpi_attr_files(struct pci_dev *pdev);
> +extern int pci_remove_acpi_attr_files(struct pci_dev *pdev);
Just put these two functions in the drivers/pci/pci.h file.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] dmi: save OEM defined slot information
From: Alex Chiang @ 2010-05-28 15:42 UTC (permalink / raw)
To: K, Narendra
Cc: netdev@vger.kernel.org, linux-hotplug@vger.kernel.org,
linux-pci@vger.kernel.org, Domsch, Matt, Hargrave, Jordan,
Rose, Charles, Nijhawan, Vijay
In-Reply-To: <20100528120644.GB24114@littleblue.us.dell.com>
* K, Narendra <Narendra_K@dell.com>:
>
> This patch from Alex Chiang exports onboard device information
> as defined by SMBIOS type 209 for HP Proliants systems.
Hi,
Not sure if it really matters, but I'm no longer at HP and thus
my email address below is dead.
> From: Alex Chiang <achiang@hp.com>
>
> Some legacy platforms provide onboard device information in an
> SMBIOS OEM- defined field, notably HP Proliants.
[snip]
> Signed-off-by: Alex Chiang <achiang@hp.com>
I wrote this code when I was still at HP, so I suppose they
should get the git commit "credit" for it, unless there's already
a well-known convention of what to do when an email address
changes.
Thanks,
/ac
^ permalink raw reply
* Re: [PATCH 2/3] workqueue: Add an API to create a singlethread workqueue attached to the current task's cgroup
From: Tejun Heo @ 2010-05-28 15:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Oleg Nesterov, Sridhar Samudrala, netdev, lkml,
kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev, Jiri Kosina,
Thomas Gleixner, Ingo Molnar, Andi Kleen
In-Reply-To: <20100528150830.GB21880@redhat.com>
Hello,
On 05/28/2010 05:08 PM, Michael S. Tsirkin wrote:
> Well, we have create_singlethread_workqueue, right?
> This is not very different ... is it?
>
> Just copying structures and code from workqueue.c,
> adding vhost_ in front of it will definitely work:
Sure it will, but you'll probably be able to get away with much less.
> there is nothing magic about the workqueue library.
> But this just involves cut and paste which might be best avoided.
What I'm saying is that some magic needs to be added to workqueue and
if you add this single(!) exception, it will have to be backed out
pretty soon, so it would be better to do it properly now.
> One final idea before we go the cut and paste way: how about
> 'create_workqueue_from_task' that would get a thread and have workqueue
> run there?
You can currently depend on that implementation detail but it's not
the workqueue interface is meant to do. The single threadedness is
there as execution ordering and concurrency specification and it
doesn't (or rather won't) necessarily mean that a specific single
thread is bound to certain workqueue.
Can you please direct me to have a look at the code. I'll be happy to
do the conversion for you.
Thanks.
--
tejun
^ permalink raw reply
* Re: MDNS is broken in latest -git
From: Maxim Levitsky @ 2010-05-28 17:09 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; +Cc: linux-wireless
In-Reply-To: <1275058948.2754.7.camel@maxim-laptop>
On Fri, 2010-05-28 at 18:02 +0300, Maxim Levitsky wrote:
> On latest git, it became impossible to use hostname.local alias to
> access my network hosts.
>
> In fact when I look at 'avahi-discover' I see nothing but local
> services.
>
> I did a bisect, but unfortunely ended with merge commit, although
> bisection seem to be normal (and I didn't do any shortcuts).
Since starting 'wireshark' magicly temporarly fixes this, I suspect that
mulicast packets don't get through.
This smells like iwl3945 bug.
I use linus' master tree now.
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts (was: Re: drivers/net/mac8390.c: Remove useless memcpy casting)
From: Finn Thain @ 2010-05-28 17:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Joe Perches, David S. Miller, netdev, Linux Kernel Mailing List,
Linux/m68k
In-Reply-To: <AANLkTikexlmuunBQ-ydNaD8fkKcLmrsfJSEgvyMJdNqU@mail.gmail.com>
On Sun, 23 May 2010, Geert Uytterhoeven wrote:
> >> But here's a better solution. I do not have the hardware to test it,
> >> though. Finn, does it {look OK,work}?
> >
> > It looks fine. I can't test it right now, but I will do so when I get
> > the opportunity.
>
> Any news from the test front?
This is commit ba0f916ca7ac79356e2ed32a85c3aa8255b104e7, right?
If so, it tests OK here.
Finn
>
> Gr{oetje,eeting}s,
>
> Geert
^ permalink raw reply
* [PATCH] mac8390: change an error return code and some cleanup, take 4
From: Finn Thain @ 2010-05-28 17:29 UTC (permalink / raw)
To: David Miller; +Cc: joe, p_gortmaker, netdev, linux-kernel, linux-m68k
In-Reply-To: <20100421.163041.158540277.davem@davemloft.net>
Propagate the request_irq() return code. Also promote the log level of the
failure message. Likewise some other KERN_INFO messages.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Index: linux-2.6.34/drivers/net/mac8390.c
===================================================================
--- linux-2.6.34.orig/drivers/net/mac8390.c 2010-05-28 00:27:30.000000000 +1000
+++ linux-2.6.34/drivers/net/mac8390.c 2010-05-28 00:27:32.000000000 +1000
@@ -556,7 +556,7 @@ static int __init mac8390_initdev(struct
case MAC8390_APPLE:
switch (mac8390_testio(dev->mem_start)) {
case ACCESS_UNKNOWN:
- pr_info("Don't know how to access card memory!\n");
+ pr_err("Don't know how to access card memory!\n");
return -ENODEV;
break;
@@ -643,10 +643,13 @@ static int __init mac8390_initdev(struct
static int mac8390_open(struct net_device *dev)
{
+ int err;
+
__ei_open(dev);
- if (request_irq(dev->irq, __ei_interrupt, 0, "8390 Ethernet", dev)) {
- pr_info("%s: unable to get IRQ %d.\n", dev->name, dev->irq);
- return -EAGAIN;
+ err = request_irq(dev->irq, __ei_interrupt, 0, "8390 Ethernet", dev);
+ if (err) {
+ pr_err("%s: unable to get IRQ %d\n", dev->name, dev->irq);
+ return err;
}
return 0;
}
@@ -662,7 +665,7 @@ static void mac8390_no_reset(struct net_
{
ei_status.txing = 0;
if (ei_debug > 1)
- pr_info("reset not supported\n");
+ printk(KERN_DEBUG pr_fmt("reset not supported\n"));
return;
}
@@ -670,7 +673,7 @@ static void interlan_reset(struct net_de
{
unsigned char *target = nubus_slot_addr(IRQ2SLOT(dev->irq));
if (ei_debug > 1)
- pr_info("Need to reset the NS8390 t=%lu...", jiffies);
+ printk(KERN_DEBUG pr_fmt("Need to reset the NS8390 t=%lu..."), jiffies);
ei_status.txing = 0;
target[0xC0000] = 0;
if (ei_debug > 1)
@@ -871,5 +874,3 @@ static void word_memcpy_fromcard(void *t
while (count--)
*to++ = *from++;
}
-
-
^ permalink raw reply
* Re: [REGRESSION,BISECTED] MIPv6 support broken by f4f914b58019f0
From: Brian Haley @ 2010-05-28 17:59 UTC (permalink / raw)
To: Arnaud Ebalard
Cc: Scott C Otto, David Miller,
YOSHIFUJI Hideaki / 吉藤英明, Jiri Olsa,
netdev
In-Reply-To: <87hblss92x.fsf@small.ssi.corp>
On 05/28/2010 04:51 AM, Arnaud Ebalard wrote:
>>> The below might actually be what was actually intended, triggering
>>> on what the user forced, rather than assuming all callers require
>>> strict behavior.
>>>
>>> -Brian
>>>
>>>
>>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>>> index 294cbe8..252d761 100644
>>> --- a/net/ipv6/route.c
>>> +++ b/net/ipv6/route.c
>>> @@ -814,7 +814,7 @@ struct dst_entry * ip6_route_output(struct net *net, struct sock *sk,
>>> {
>>> int flags = 0;
>>>
>>> - if (fl->oif || rt6_need_strict(&fl->fl6_dst))
>>> + if ((sk && sk->sk_bound_dev_if) || rt6_need_strict(&fl->fl6_dst))
>>> flags |= RT6_LOOKUP_F_IFACE;
>>>
>>> if (!ipv6_addr_any(&fl->fl6_src))
>
> Brian, I tested the patch on my Mobile Node: it fixes the regression. I
> also updated the kernel on my Home Agent to a 2.6.34 with that fix and
> everything works as expected. *For that aspect* and fwiw, you get my
>
> Tested-by: Arnaud Ebalard <arno@natisbad.org>
Ok, thanks for testing, I'll send out an updated patch, with the caveat
there still might be a DCCP regression, see below.
> For the SO_BINDTODEVICE aspect, I don't have code at hand to test if the
> fix works as expected. We should also double check that this will not
> break other paths which use the sk->sk_bound_dev_if with a different
> semantic:
> net/ieee802154/raw.c: sk->sk_bound_dev_if = dev->ifindex;
Isn't AF_INET6, OK.
> net/core/sock.c: sk->sk_bound_dev_if = index;
The actual setsockopt() call, OK.
> net/ipv6/datagram.c: sk->sk_bound_dev_if = usin->sin6_scope_id;
> net/ipv6/datagram.c: sk->sk_bound_dev_if = np->mcast_oif;
> net/ipv6/af_inet6.c: sk->sk_bound_dev_if = addr->sin6_scope_id;
> net/ipv6/tcp_ipv6.c: sk->sk_bound_dev_if = usin->sin6_scope_id;
> net/ipv6/tcp_ipv6.c: newsk->sk_bound_dev_if = treq->iif;
> net/ipv6/raw.c: sk->sk_bound_dev_if = addr->sin6_scope_id;
This are all in link-local or multicast code, caller passing-in scopeid,
would trigger rt6_need_strict() regardless, so are OK.
> net/sctp/socket.c: newsk->sk_bound_dev_if = sk->sk_bound_dev_if;
SCTP peeling-off a socket, cloning parent, OK.
> net/ipv4/ip_output.c: sk->sk_bound_dev_if = arg->bound_dev_if;
> net/ipv4/udp.c: sk->sk_bound_dev_if = 0;
IPv4, shouldn't be affected by an IPv6 route change, OK.
> net/dccp/ipv6.c: newsk->sk_bound_dev_if = ireq6->iif;
This is the only mystery in this list. Looks like the DCCP accept()
codepath, and it's getting bound to the interface the request was
received on. I'm not sure if the intention here was to force this
strict behavior or not.
> net/dccp/ipv6.c: sk->sk_bound_dev_if = usin->sin6_scope_id;
In link-local code, caller passing-in scopeid, would trigger
rt6_need_strict() regardless, so OK.
-Brian
^ permalink raw reply
* [PATCH]: vxge: Fix checkstack warning in vxge_probe()
From: Prarit Bhargava @ 2010-05-28 18:01 UTC (permalink / raw)
To: netdev, mschmidt; +Cc: Prarit Bhargava
Linux 2.6.33 reports this checkstack warning:
drivers/net/vxge/vxge-main.c: In function 'vxge_probe':
drivers/net/vxge/vxge-main.c:4409: warning: the frame size of 1028 bytes is larger than 1024 bytes
This warning does not occur in the latest linux-2.6 or linux-next, however,
when I do a 'make -j32 CONFIG_FRAME_WARN=512' instead of 1024 I see
drivers/net/vxge/vxge-main.c: In function ‘vxge_probe’:
drivers/net/vxge/vxge-main.c:4423: warning: the frame size of 1024 bytes is larger than 512 bytes
This patch moves the large vxge_config struct off the stack.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
diff --git a/drivers/net/vxge/vxge-main.c b/drivers/net/vxge/vxge-main.c
index 2bab364..b955802 100644
--- a/drivers/net/vxge/vxge-main.c
+++ b/drivers/net/vxge/vxge-main.c
@@ -4016,7 +4016,7 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
int high_dma = 0;
u64 vpath_mask = 0;
struct vxgedev *vdev;
- struct vxge_config ll_config;
+ struct vxge_config *ll_config = NULL;
struct vxge_hw_device_config *device_config = NULL;
struct vxge_hw_device_attr attr;
int i, j, no_of_vpath = 0, max_vpath_supported = 0;
@@ -4075,17 +4075,24 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
goto _exit0;
}
- memset(&ll_config, 0, sizeof(struct vxge_config));
- ll_config.tx_steering_type = TX_MULTIQ_STEERING;
- ll_config.intr_type = MSI_X;
- ll_config.napi_weight = NEW_NAPI_WEIGHT;
- ll_config.rth_steering = RTH_STEERING;
+ ll_config = kzalloc(sizeof(*ll_config), GFP_KERNEL);
+ if (!ll_config) {
+ ret = -ENOMEM;
+ vxge_debug_init(VXGE_ERR,
+ "ll_config : malloc failed %s %d",
+ __FILE__, __LINE__);
+ goto _exit0;
+ }
+ ll_config->tx_steering_type = TX_MULTIQ_STEERING;
+ ll_config->intr_type = MSI_X;
+ ll_config->napi_weight = NEW_NAPI_WEIGHT;
+ ll_config->rth_steering = RTH_STEERING;
/* get the default configuration parameters */
vxge_hw_device_config_default_get(device_config);
/* initialize configuration parameters */
- vxge_device_config_init(device_config, &ll_config.intr_type);
+ vxge_device_config_init(device_config, &ll_config->intr_type);
ret = pci_enable_device(pdev);
if (ret) {
@@ -4138,7 +4145,7 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
(unsigned long long)pci_resource_start(pdev, 0));
status = vxge_hw_device_hw_info_get(attr.bar0,
- &ll_config.device_hw_info);
+ &ll_config->device_hw_info);
if (status != VXGE_HW_OK) {
vxge_debug_init(VXGE_ERR,
"%s: Reading of hardware info failed."
@@ -4147,7 +4154,7 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
goto _exit3;
}
- if (ll_config.device_hw_info.fw_version.major !=
+ if (ll_config->device_hw_info.fw_version.major !=
VXGE_DRIVER_FW_VERSION_MAJOR) {
vxge_debug_init(VXGE_ERR,
"%s: Incorrect firmware version."
@@ -4157,7 +4164,7 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
goto _exit3;
}
- vpath_mask = ll_config.device_hw_info.vpath_mask;
+ vpath_mask = ll_config->device_hw_info.vpath_mask;
if (vpath_mask == 0) {
vxge_debug_ll_config(VXGE_TRACE,
"%s: No vpaths available in device", VXGE_DRIVER_NAME);
@@ -4169,10 +4176,10 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
"%s:%d Vpath mask = %llx", __func__, __LINE__,
(unsigned long long)vpath_mask);
- function_mode = ll_config.device_hw_info.function_mode;
- host_type = ll_config.device_hw_info.host_type;
+ function_mode = ll_config->device_hw_info.function_mode;
+ host_type = ll_config->device_hw_info.host_type;
is_privileged = __vxge_hw_device_is_privilaged(host_type,
- ll_config.device_hw_info.func_id);
+ ll_config->device_hw_info.func_id);
/* Check how many vpaths are available */
for (i = 0; i < VXGE_HW_MAX_VIRTUAL_PATHS; i++) {
@@ -4186,7 +4193,7 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
/* Enable SRIOV mode, if firmware has SRIOV support and if it is a PF */
if (is_sriov(function_mode) && (max_config_dev > 1) &&
- (ll_config.intr_type != INTA) &&
+ (ll_config->intr_type != INTA) &&
(is_privileged == VXGE_HW_OK)) {
ret = pci_enable_sriov(pdev, ((max_config_dev - 1) < num_vfs)
? (max_config_dev - 1) : num_vfs);
@@ -4199,7 +4206,7 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
* Configure vpaths and get driver configured number of vpaths
* which is less than or equal to the maximum vpaths per function.
*/
- no_of_vpath = vxge_config_vpaths(device_config, vpath_mask, &ll_config);
+ no_of_vpath = vxge_config_vpaths(device_config, vpath_mask, ll_config);
if (!no_of_vpath) {
vxge_debug_ll_config(VXGE_ERR,
"%s: No more vpaths to configure", VXGE_DRIVER_NAME);
@@ -4234,21 +4241,21 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
/* set private device info */
pci_set_drvdata(pdev, hldev);
- ll_config.gro_enable = VXGE_GRO_ALWAYS_AGGREGATE;
- ll_config.fifo_indicate_max_pkts = VXGE_FIFO_INDICATE_MAX_PKTS;
- ll_config.addr_learn_en = addr_learn_en;
- ll_config.rth_algorithm = RTH_ALG_JENKINS;
- ll_config.rth_hash_type_tcpipv4 = VXGE_HW_RING_HASH_TYPE_TCP_IPV4;
- ll_config.rth_hash_type_ipv4 = VXGE_HW_RING_HASH_TYPE_NONE;
- ll_config.rth_hash_type_tcpipv6 = VXGE_HW_RING_HASH_TYPE_NONE;
- ll_config.rth_hash_type_ipv6 = VXGE_HW_RING_HASH_TYPE_NONE;
- ll_config.rth_hash_type_tcpipv6ex = VXGE_HW_RING_HASH_TYPE_NONE;
- ll_config.rth_hash_type_ipv6ex = VXGE_HW_RING_HASH_TYPE_NONE;
- ll_config.rth_bkt_sz = RTH_BUCKET_SIZE;
- ll_config.tx_pause_enable = VXGE_PAUSE_CTRL_ENABLE;
- ll_config.rx_pause_enable = VXGE_PAUSE_CTRL_ENABLE;
-
- if (vxge_device_register(hldev, &ll_config, high_dma, no_of_vpath,
+ ll_config->gro_enable = VXGE_GRO_ALWAYS_AGGREGATE;
+ ll_config->fifo_indicate_max_pkts = VXGE_FIFO_INDICATE_MAX_PKTS;
+ ll_config->addr_learn_en = addr_learn_en;
+ ll_config->rth_algorithm = RTH_ALG_JENKINS;
+ ll_config->rth_hash_type_tcpipv4 = VXGE_HW_RING_HASH_TYPE_TCP_IPV4;
+ ll_config->rth_hash_type_ipv4 = VXGE_HW_RING_HASH_TYPE_NONE;
+ ll_config->rth_hash_type_tcpipv6 = VXGE_HW_RING_HASH_TYPE_NONE;
+ ll_config->rth_hash_type_ipv6 = VXGE_HW_RING_HASH_TYPE_NONE;
+ ll_config->rth_hash_type_tcpipv6ex = VXGE_HW_RING_HASH_TYPE_NONE;
+ ll_config->rth_hash_type_ipv6ex = VXGE_HW_RING_HASH_TYPE_NONE;
+ ll_config->rth_bkt_sz = RTH_BUCKET_SIZE;
+ ll_config->tx_pause_enable = VXGE_PAUSE_CTRL_ENABLE;
+ ll_config->rx_pause_enable = VXGE_PAUSE_CTRL_ENABLE;
+
+ if (vxge_device_register(hldev, ll_config, high_dma, no_of_vpath,
&vdev)) {
ret = -EINVAL;
goto _exit4;
@@ -4279,7 +4286,7 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
vdev->vpaths[j].vdev = vdev;
vdev->vpaths[j].max_mac_addr_cnt = max_mac_vpath;
memcpy((u8 *)vdev->vpaths[j].macaddr,
- (u8 *)ll_config.device_hw_info.mac_addrs[i],
+ ll_config->device_hw_info.mac_addrs[i],
ETH_ALEN);
/* Initialize the mac address list header */
@@ -4300,18 +4307,18 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
macaddr = (u8 *)vdev->vpaths[0].macaddr;
- ll_config.device_hw_info.serial_number[VXGE_HW_INFO_LEN - 1] = '\0';
- ll_config.device_hw_info.product_desc[VXGE_HW_INFO_LEN - 1] = '\0';
- ll_config.device_hw_info.part_number[VXGE_HW_INFO_LEN - 1] = '\0';
+ ll_config->device_hw_info.serial_number[VXGE_HW_INFO_LEN - 1] = '\0';
+ ll_config->device_hw_info.product_desc[VXGE_HW_INFO_LEN - 1] = '\0';
+ ll_config->device_hw_info.part_number[VXGE_HW_INFO_LEN - 1] = '\0';
vxge_debug_init(VXGE_TRACE, "%s: SERIAL NUMBER: %s",
- vdev->ndev->name, ll_config.device_hw_info.serial_number);
+ vdev->ndev->name, ll_config->device_hw_info.serial_number);
vxge_debug_init(VXGE_TRACE, "%s: PART NUMBER: %s",
- vdev->ndev->name, ll_config.device_hw_info.part_number);
+ vdev->ndev->name, ll_config->device_hw_info.part_number);
vxge_debug_init(VXGE_TRACE, "%s: Neterion %s Server Adapter",
- vdev->ndev->name, ll_config.device_hw_info.product_desc);
+ vdev->ndev->name, ll_config->device_hw_info.product_desc);
vxge_debug_init(VXGE_TRACE, "%s: MAC ADDR: %pM",
vdev->ndev->name, macaddr);
@@ -4321,11 +4328,11 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
vxge_debug_init(VXGE_TRACE,
"%s: Firmware version : %s Date : %s", vdev->ndev->name,
- ll_config.device_hw_info.fw_version.version,
- ll_config.device_hw_info.fw_date.date);
+ ll_config->device_hw_info.fw_version.version,
+ ll_config->device_hw_info.fw_date.date);
if (new_device) {
- switch (ll_config.device_hw_info.function_mode) {
+ switch (ll_config->device_hw_info.function_mode) {
case VXGE_HW_FUNCTION_MODE_SINGLE_FUNCTION:
vxge_debug_init(VXGE_TRACE,
"%s: Single Function Mode Enabled", vdev->ndev->name);
@@ -4348,7 +4355,7 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
vxge_print_parm(vdev, vpath_mask);
/* Store the fw version for ethttool option */
- strcpy(vdev->fw_version, ll_config.device_hw_info.fw_version.version);
+ strcpy(vdev->fw_version, ll_config->device_hw_info.fw_version.version);
memcpy(vdev->ndev->dev_addr, (u8 *)vdev->vpaths[0].macaddr, ETH_ALEN);
memcpy(vdev->ndev->perm_addr, vdev->ndev->dev_addr, ETH_ALEN);
@@ -4387,7 +4394,7 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
* present to prevent such a failure.
*/
- if (ll_config.device_hw_info.function_mode ==
+ if (ll_config->device_hw_info.function_mode ==
VXGE_HW_FUNCTION_MODE_MULTI_FUNCTION)
if (vdev->config.intr_type == INTA)
vxge_hw_device_unmask_all(hldev);
@@ -4399,6 +4406,7 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
VXGE_COPY_DEBUG_INFO_TO_LL(vdev, vxge_hw_device_error_level_get(hldev),
vxge_hw_device_trace_level_get(hldev));
+ kfree(ll_config);
return 0;
_exit5:
@@ -4416,6 +4424,7 @@ _exit2:
_exit1:
pci_disable_device(pdev);
_exit0:
+ kfree(ll_config);
kfree(device_config);
driver_config->config_dev_cnt--;
pci_set_drvdata(pdev, NULL);
^ permalink raw reply related
* pull request: wireless-2.6 2010-05-28
From: John W. Linville @ 2010-05-28 18:09 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here are a few small fixes intended for 2.6.35. Included are a null
pointer dereference fix, and a use-after-free fix, as well as some more
minor stuff. It also include the revert of a earlier patch that I
inadvertantly merged out of order, effectively creating a bug rather
than fixing one. The reverted patch will now be pointed at 2.6.36
instead.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 045de01a174d9f0734f657eb4b3313d89b4fd5ad:
Scott Feldman (1):
netlink: bug fix: wrong size was calculated for vfinfo list blob
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Christian Lamparter (1):
ar9170usb: fix read from freed driver context
Christoph Fritz (1):
ssb: fix NULL ptr deref when pcihost_wrapper is used
Johannes Berg (1):
mac80211: make a function static
John W. Linville (1):
Revert "rt2x00: Fix rt2800usb TX descriptor writing."
Justin P. Mattock (1):
ath9k: Fix ath_print in xmit for hardware reset.
Prarit Bhargava (1):
libertas: fix uninitialized variable warning
Vasanthakumar Thiagarajan (1):
ath9k: Fix bug in the way "bf_tx_aborted" of struct ath_buf is used
drivers/net/wireless/ath/ar9170/usb.c | 14 ++++++++++++--
drivers/net/wireless/ath/ath9k/xmit.c | 6 ++++--
drivers/net/wireless/libertas/rx.c | 5 ++---
drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
drivers/ssb/pci.c | 9 ++++++---
drivers/ssb/sprom.c | 1 +
net/mac80211/chan.c | 2 +-
7 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ar9170/usb.c b/drivers/net/wireless/ath/ar9170/usb.c
index 82ab532..a93dc18 100644
--- a/drivers/net/wireless/ath/ar9170/usb.c
+++ b/drivers/net/wireless/ath/ar9170/usb.c
@@ -739,17 +739,27 @@ err_out:
static void ar9170_usb_firmware_failed(struct ar9170_usb *aru)
{
struct device *parent = aru->udev->dev.parent;
+ struct usb_device *udev;
+
+ /*
+ * Store a copy of the usb_device pointer locally.
+ * This is because device_release_driver initiates
+ * ar9170_usb_disconnect, which in turn frees our
+ * driver context (aru).
+ */
+ udev = aru->udev;
complete(&aru->firmware_loading_complete);
/* unbind anything failed */
if (parent)
device_lock(parent);
- device_release_driver(&aru->udev->dev);
+
+ device_release_driver(&udev->dev);
if (parent)
device_unlock(parent);
- usb_put_dev(aru->udev);
+ usb_put_dev(udev);
}
static void ar9170_usb_firmware_finish(const struct firmware *fw, void *context)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 3db1917..859aa4a 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
int r;
ath_print(common, ATH_DBG_FATAL,
- "Unable to stop TxDMA. Reset HAL!\n");
+ "Failed to stop TX DMA. Resetting hardware!\n");
spin_lock_bh(&sc->sc_resetlock);
r = ath9k_hw_reset(ah, sc->sc_ah->curchan, false);
@@ -1728,6 +1728,8 @@ static int ath_tx_setup_buffer(struct ieee80211_hw *hw, struct ath_buf *bf,
} else
bf->bf_isnullfunc = false;
+ bf->bf_tx_aborted = false;
+
return 0;
}
@@ -1989,7 +1991,7 @@ static int ath_tx_num_badfrms(struct ath_softc *sc, struct ath_buf *bf,
int nbad = 0;
int isaggr = 0;
- if (bf->bf_tx_aborted)
+ if (bf->bf_lastbf->bf_tx_aborted)
return 0;
isaggr = bf_isaggr(bf);
diff --git a/drivers/net/wireless/libertas/rx.c b/drivers/net/wireless/libertas/rx.c
index a115bfa..7a377f5 100644
--- a/drivers/net/wireless/libertas/rx.c
+++ b/drivers/net/wireless/libertas/rx.c
@@ -329,9 +329,8 @@ static int process_rxed_802_11_packet(struct lbs_private *priv,
/* create the exported radio header */
/* radiotap header */
- radiotap_hdr.hdr.it_version = 0;
- /* XXX must check this value for pad */
- radiotap_hdr.hdr.it_pad = 0;
+ memset(&radiotap_hdr, 0, sizeof(radiotap_hdr));
+ /* XXX must check radiotap_hdr.hdr.it_pad for pad */
radiotap_hdr.hdr.it_len = cpu_to_le16 (sizeof(struct rx_radiotap_hdr));
radiotap_hdr.hdr.it_present = cpu_to_le32 (RX_RADIOTAP_PRESENT);
radiotap_hdr.rate = convert_mv_rate_to_radiotap(prxpd->rx_rate);
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 6991613..0f8b84b 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -413,7 +413,7 @@ static void rt2800usb_write_tx_desc(struct rt2x00_dev *rt2x00dev,
*/
rt2x00_desc_read(txi, 0, &word);
rt2x00_set_field32(&word, TXINFO_W0_USB_DMA_TX_PKT_LEN,
- skb->len - TXINFO_DESC_SIZE);
+ skb->len + TXWI_DESC_SIZE);
rt2x00_set_field32(&word, TXINFO_W0_WIV,
!test_bit(ENTRY_TXD_ENCRYPT_IV, &txdesc->flags));
rt2x00_set_field32(&word, TXINFO_W0_QSEL, 2);
diff --git a/drivers/ssb/pci.c b/drivers/ssb/pci.c
index 989e275..6dcda86 100644
--- a/drivers/ssb/pci.c
+++ b/drivers/ssb/pci.c
@@ -625,9 +625,12 @@ static int ssb_pci_sprom_get(struct ssb_bus *bus,
ssb_printk(KERN_ERR PFX "No SPROM available!\n");
return -ENODEV;
}
-
- bus->sprom_offset = (bus->chipco.dev->id.revision < 31) ?
- SSB_SPROM_BASE1 : SSB_SPROM_BASE31;
+ if (bus->chipco.dev) { /* can be unavailible! */
+ bus->sprom_offset = (bus->chipco.dev->id.revision < 31) ?
+ SSB_SPROM_BASE1 : SSB_SPROM_BASE31;
+ } else {
+ bus->sprom_offset = SSB_SPROM_BASE1;
+ }
buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
if (!buf)
diff --git a/drivers/ssb/sprom.c b/drivers/ssb/sprom.c
index 007bc3a..4f7cc8d 100644
--- a/drivers/ssb/sprom.c
+++ b/drivers/ssb/sprom.c
@@ -185,6 +185,7 @@ bool ssb_is_sprom_available(struct ssb_bus *bus)
/* this routine differs from specs as we do not access SPROM directly
on PCMCIA */
if (bus->bustype == SSB_BUSTYPE_PCI &&
+ bus->chipco.dev && /* can be unavailible! */
bus->chipco.dev->id.revision >= 31)
return bus->chipco.capabilities & SSB_CHIPCO_CAP_SPROM;
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 5d218c5..32be11e 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -5,7 +5,7 @@
#include <linux/nl80211.h>
#include "ieee80211_i.h"
-enum ieee80211_chan_mode
+static enum ieee80211_chan_mode
__ieee80211_get_channel_mode(struct ieee80211_local *local,
struct ieee80211_sub_if_data *ignore)
{
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH 1/2] Export firmware assigned labels of network devices to sysfs
From: Matt Domsch @ 2010-05-28 18:11 UTC (permalink / raw)
To: Greg KH
Cc: K, Narendra, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Hargrave, Jordan, Rose, Charles, Nijhawan, Vijay
In-Reply-To: <20100528154041.GA27186@kroah.com>
On Fri, May 28, 2010 at 08:40:41AM -0700, Greg KH wrote:
> On Fri, May 28, 2010 at 06:55:21AM -0500, K, Narendra wrote:
> > +static const char dell_dsm_uuid[] = {
>
> Um, a dell specific uuid in a generic file? What happens when we need
> to support another manufacturer?
>
> > + 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
> > + 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
> > +};
This simply needs to be renamed. It's defined in the ECN, so will be
part of the spec, and is not vendor-unique, but defined once for all
implementations. It separates this _DSM function from others.
Thanks for the quick feedback.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* [PATCH] IPv6: fix Mobile IPv6 regression
From: Brian Haley @ 2010-05-28 18:17 UTC (permalink / raw)
To: David Miller
Cc: Arnaud Ebalard, Scott C Otto,
YOSHIFUJI Hideaki / 吉藤英明, Jiri Olsa,
netdev
In-Reply-To: <4C00047D.3010404@hp.com>
Commit f4f914b5 (net: ipv6 bind to device issue) caused
a regression with Mobile IPv6 when it changed the meaning
of fl->oif to become a strict requirement of the route
lookup. Instead, only force strict mode when
sk->sk_bound_dev_if is set on the calling socket, getting
the intended behavior and fixing the regression.
Tested-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Brian Haley <brian.haley@hp.com>
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 294cbe8..252d761 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -814,7 +814,7 @@ struct dst_entry * ip6_route_output(struct net *net, struct sock *sk,
{
int flags = 0;
- if (fl->oif || rt6_need_strict(&fl->fl6_dst))
+ if ((sk && sk->sk_bound_dev_if) || rt6_need_strict(&fl->fl6_dst))
flags |= RT6_LOOKUP_F_IFACE;
if (!ipv6_addr_any(&fl->fl6_src))
^ permalink raw reply related
* Re: [REGRESSION,BISECTED] MIPv6 support broken by f4f914b58019f0
From: YOSHIFUJI Hideaki @ 2010-05-28 18:40 UTC (permalink / raw)
To: Arnaud Ebalard
Cc: Brian Haley, David Miller, Jiri Olsa, Scott Otto, netdev,
YOSHIFUJI Hideaki
In-Reply-To: <87sk5d2h4u.fsf@small.ssi.corp>
Hello.
(2010/05/28 6:01), Arnaud Ebalard wrote:
> Hi,
>
> Brian Haley<brian.haley@hp.com> writes:
>
>>> In previous debug outputs, the content of the fl->oif is ok, i.e. it is
>>> set to the interface on which the CoA is configured, i.e. the output
>>> interface. But the commit results in flags |= RT6_LOOKUP_F_IFACE.
>>> Later, in rt6_score_route(), the call to rt6_check_dev() returns 0
>>> (dev->ifindex is ip6tnl1 but oif is wlan0). Because of the change to flags
>>> flags, we quickly return -1 in rt6_score_route():
>>
>> Ok, so the call to ip6_route_output() was from the tunnel code, which is
>> using it's cached flowi, which has oif set to the tunnel. The XFRM code
>> swaps the addresses, which should invalidate the oif, but it doesn't.
>>
>>> static int rt6_score_route(struct rt6_info *rt, int oif,
>>> int strict)
>>> {
>>> int m, n;
>>>
>>> m = rt6_check_dev(rt, oif);
>>> if (!m&& (strict& RT6_LOOKUP_F_IFACE))
>>> return -1;
>>> ...
>>>
>>> Now, I wonder if the following is correct. Don't hesitate to correct me
>>> if I am wrong:
>>>
>>> Initially (before f4f914b58019f0), the purpose of the test using
>>> rt6_need_strict() in ip6_route_output() (introduced by c71099ac) was to
>>> allow the multiple routing table logic to be applied to all global
>>> addresses but to preserve the addresses for which it would not make
>>> sense (link-local, multicast, ). The change introduced by f4f914b58019f0
>>> basically reduces the ability to route traffic as you want and forces
>>> the traffic to leave the device by the interface on which it is
>>> configured (if fl->oif is set).
>>
>> The problem is we assumed the caller's would only set fl->oif if they
>> wanted it enforced (multicast, link-local, SO_BINDTODEVICE), but it
>> didn't take into account the tunnel code. I guess the easy answer
>> would be to revert this until we can fix it correctly.
>
> Nothing against it but maybe Jiri or David have other ideas.
>
>
>>> From my (very limited and possibly wrong) understanding, the change
>>> introduced by f4f914b58019f0 looks like a workaround for the
>>> SO_BINDTODEVICE issue. Looking at the code, there is something I don't
>>> understand: if SO_BINDTODEVICE has been used on a socket, the socket
>>> should have its sk_bound_dev_if attribute set to the correct ifindex
>>> value. Hence the following (naive) question: why is that information not
>>> used to inflect the selection of the route cached for the socket? And
>>> why would the fix be at the adress level instead of being at the
>>> interface level (ifindex)?
>>
>> I guess I always believed setting SO_BINDTODEVICE should always force
>> traffic out that interface, but from Yoshifuji's email it seems that
>> maybe wasn't the intention, at least for things that don't meet
>> the rt_need_strict() criteria like globals. I don't know the history
>> behind the setsockopt.
>
> The behavior I would expect from a combination of RFC 4191 and
> SO_BINDTODEVICE sockopt would be the use of the interface as outgoing
> interface and then the use of the best router (using router preference
> info, reachability, ...) available on the subnet. IIRC, the router
> preference info is per default router list in the RFC, i.e. per
> interface.
Good point.
Whatever our original intention/thought was,
current RFC says that we should honor outgoing interface
specified by user (by IPV6_PKTINFO etc.), as we do for
SO_BINDTODEVICE in IPv4 as well.
In this sense, checking sk->sk_bound_dev_if in
ip6_route_output() is not enough because we need to
take outgoing interface specified in ancillary data
into account, which is set to fl->oif.
How about adding additional "flags" parameter
for ip6_route_output()?
Thoughts?
--yoshfuji
^ permalink raw reply
* Re: [v5 Patch 1/3] netpoll: add generic support for bridge and bonding devices
From: Flavio Leitner @ 2010-05-28 19:40 UTC (permalink / raw)
To: Cong Wang
Cc: linux-kernel, Matt Mackall, netdev, bridge, Andy Gospodarek,
Neil Horman, Jeff Moyer, Stephen Hemminger, bonding-devel,
Jay Vosburgh, David Miller
In-Reply-To: <4BFF2EA5.9090008@redhat.com>
On Fri, May 28, 2010 at 10:47:01AM +0800, Cong Wang wrote:
> On 05/28/10 02:05, Flavio Leitner wrote:
> >
> >Hi guys!
> >
> >I finally could test this to see if an old problem reported on bugzilla[1] was
> >fixed now, but unfortunately it is still there.
> >
> >The ticket is private I guess, but basically the problem happens when bonding
> >driver tries to print something after it had taken the write_lock (monitor
> >functions, enslave/de-enslave), so the printk() will pass through netpoll, then
> >on bonding again which no matter what mode you use, it will try to read_lock()
> >the lock again. The result is a deadlock and the entire system hangs.
>
>
> This is true, I already fixed some similar issues.
>
> >
> >I manage to get a fresh backtrace with mode 1, see below:
> >
> >
> >[ 93.167079] Call Trace:
> >[ 93.167079] [<ffffffff81034cf9>] warn_slowpath_common+0x77/0x8f
> >[ 93.167079] [<ffffffff81034d5e>] warn_slowpath_fmt+0x3c/0x3e
> >[ 93.167079] [<ffffffff81366aef>] ? _raw_read_trylock+0x11/0x4b
> >[ 93.167079] [<ffffffffa02a2c42>] ? bond_start_xmit+0x12b/0x401 [bonding]
> >-> read_lock fails
> >[ 93.167079] [<ffffffffa02a2c9f>] bond_start_xmit+0x188/0x401 [bonding]
> >[ 93.167079] [<ffffffff81055b37>] ? trace_hardirqs_off+0xd/0xf
> >[ 93.167079] [<ffffffff812dfdb9>] netpoll_send_skb+0xbd/0x1f3
> >[ 93.167079] [<ffffffff812e00ed>] netpoll_send_udp+0x1fe/0x20d
> >[ 93.167079] [<ffffffffa02c017c>] write_msg+0x89/0xcd [netconsole]
> >[ 93.167079] [<ffffffff81034e65>] __call_console_drivers+0x67/0x79
> >[ 93.167079] [<ffffffff81034ed0>] _call_console_drivers+0x59/0x5d
> >[ 93.167079] [<ffffffff810352d3>] release_console_sem+0x121/0x1d7
> >[ 93.167079] [<ffffffff8103590a>] vprintk+0x35d/0x393
> >[ 93.167079] [<ffffffff8103f947>] ? add_timer+0x17/0x19
> >[ 93.167079] [<ffffffff81046ddf>] ? queue_delayed_work_on+0xa2/0xa9
> >[ 93.167079] [<ffffffff81363bb8>] printk+0x3c/0x44
> >[ 93.167079] [<ffffffffa02a3b17>] bond_select_active_slave+0x105/0x109 [bonding]
> >-> write_locked
> >[ 93.167079] [<ffffffffa02a4798>] bond_mii_monitor+0x479/0x4ed [bonding]
> >[ 93.167079] [<ffffffff81046009>] worker_thread+0x1ef/0x2e2
> >
> >In this case, the message should be
> > "bonding: bond0: making interface eth0 the new active one"
>
>
> Hmm, you triggered a warning here, let me check the source code
> and try to reproduce it here.
Okay, just pull the cable from one slave or both slaves.
> >I did the following patch to discard the packet if it was IN_NETPOLL
> >and the read_lock() fails, so I could go ahead testing it:
> >
> >diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> >index 5e12462..a3b8bad 100644
> >--- a/drivers/net/bonding/bond_main.c
> >+++ b/drivers/net/bonding/bond_main.c
> >@@ -4258,8 +4258,19 @@ static int bond_xmit_activebackup(struct sk_buff *skb, struct net_device *bond_d
> > struct bonding *bond = netdev_priv(bond_dev);
> > int res = 1;
> >
> >- read_lock(&bond->lock);
> >- read_lock(&bond->curr_slave_lock);
> >+ if (read_trylock(&bond->lock) == 0&&
> >+ (bond_dev->flags& IFF_IN_NETPOLL)) {
> >+ dev_kfree_skb(skb);
> >+ return NETDEV_TX_OK;
> >+ }
> >+
> >+ if (read_trylock(&bond->curr_slave_lock) == 0&&
> >+ (bond_dev->flags& IFF_IN_NETPOLL)) {
> >+ read_unlock(&bond->lock);
> >+ dev_kfree_skb(skb);
> >+ return NETDEV_TX_OK;
> >+ }
> >+
> >
> > if (!BOND_IS_OK(bond))
> > goto out;
> >
>
>
> This looks like a workaround, not a fix. :)
No, it's a debugging patch, otherwise I couldn't see anything on
serial console when it deadlocks or to keep testing it. :)
> >and I found another problem. The function netpoll_send_skb() checks
> >if the npinfo's queue length is zero and if it's not, it will queue
> >the packet to make sure it's in order and then schedule the thread
> >to run. Later, the thread wakes up running queue_process() which disables
> >interrupts before calling ndo_start_xmit(). However, dev_queue_xmit()
> >uses rcu_*_bh() and before return, it will enable the interrupts again,
> >spitting this:
> >
> >------------[ cut here ]------------
> >WARNING: at kernel/softirq.c:143 local_bh_enable+0x3c/0x86()
> >Hardware name: Precision WorkStation 490
> >Modules linked in: netconsole bonding sunrpc ip6t_REJECT xt_tcpudp nf_conntrack_ipv6]
> >Pid: 17, comm: events/2 Not tainted 2.6.34-04700-gd938a70 #21
> >Call Trace:
> > [<ffffffff810381d6>] warn_slowpath_common+0x77/0x8f
> > [<ffffffff810381fd>] warn_slowpath_null+0xf/0x11
> > [<ffffffff8103d691>] local_bh_enable+0x3c/0x86
> > [<ffffffff812e4d85>] dev_queue_xmit+0x462/0x493
> > [<ffffffffa018805f>] bond_dev_queue_xmit+0x1bd/0x1e3 [bonding]
> > [<ffffffffa01881dd>] bond_start_xmit+0x158/0x37b [bonding]
> >-> interrupts disabled
> > [<ffffffff812f3fca>] queue_process+0x9d/0xf9
> > [<ffffffff8104d022>] worker_thread+0x19d/0x224
> > [<ffffffff812f3f2d>] ? queue_process+0x0/0xf9
> > [<ffffffff81050819>] ? autoremove_wake_function+0x0/0x34
> > [<ffffffff8104ce85>] ? worker_thread+0x0/0x224
> > [<ffffffff8105040b>] kthread+0x7a/0x82
> > [<ffffffff810036d4>] kernel_thread_helper+0x4/0x10
> > [<ffffffff81050391>] ? kthread+0x0/0x82
> > [<ffffffff810036d0>] ? kernel_thread_helper+0x0/0x10
> >---[ end trace 74e3904503fdb632 ]---
> >
> >kernel/softirq.c:
> >141 static inline void _local_bh_enable_ip(unsigned long ip)
> >142 {
> >143 WARN_ON_ONCE(in_irq() || irqs_disabled());
> >144 #ifdef CONFIG_TRACE_IRQFLAGS
> >145 local_irq_disable();
> >146 #endif
> >147 /*
> >148 * Are softirqs going to be turned on now:
> >149 */
> >
> >
>
> I am wondering if this was caused by the previous issue.
Yeah, the first problem can help to trigger this.
The spinlock target_list_lock in write_msg() seems to serialize
this, but I'm not sure yet if the queue will always be empty by
the time another call to write_msg() is made because the
netpoll_send_skb() will queue the packet if it fails to send.
> >The git is updated up to:
> > d938a70 be2net: increase POST timeout for EEH recovery
> >
> >Two slave interfaces, bonding mode 1, netconsole over bond0.
> >
> >[1] https://bugzilla.redhat.com/show_bug.cgi?id=248374#c5
>
> How did you reproduce this?
> I will check that BZ to see if I can find how to reproduce 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
--
Flavio
^ permalink raw reply
* Choppy TCP send performance
From: Ivan Novick @ 2010-05-28 20:38 UTC (permalink / raw)
To: netdev; +Cc: Tim Heath
Hello,
I am using RHEL5 and have 1 Gigabit NIC cards.
When doing a loop sending 128 KB blocks of data using TCP. I am using
system tap to debug the performance and finding that:
90% of the send calls take about 100 micro seconds and 10% of the send
calls take about 10 miliseconds. The average send time is about 1
milisecond
The 10% of the calls taking about 10 milliseconds seem to be
correlated with "sk_stream_wait_memory" calls in the kernel.
sk_stream_wait_memory seems to be called when the send buffer is full
and the next send call does not complete until the send buffer
utilization goes down from 4,194,304 bytes to 2,814,968 bytes.
This implies that the send that blocks on a full send buffer will not
complete until there is 1 meg of free space in the send buffer even
though the send could be accepted into the OS with only 128KB of free
space.
Do you think I am misinterpreting this data or is there a way to even
out the send calls so that they they are more even in duration: approx
1 milisecond per call. Is there a parameter to reduce how much space
needs to be free in the send buffer before a blocking send call can
complete from user space?
Cheers,
Ivan
^ permalink raw reply
* Re: [v5 Patch 1/3] netpoll: add generic support for bridge and bonding devices
From: Flavio Leitner @ 2010-05-28 20:42 UTC (permalink / raw)
To: Cong Wang
Cc: linux-kernel, Matt Mackall, netdev, bridge, Andy Gospodarek,
Neil Horman, Jeff Moyer, Stephen Hemminger, bonding-devel,
Jay Vosburgh, David Miller
In-Reply-To: <4BFF7BE2.6020503@redhat.com>
On Fri, May 28, 2010 at 04:16:34PM +0800, Cong Wang wrote:
> On 05/28/10 02:05, Flavio Leitner wrote:
> >
> >Hi guys!
> >
> >I finally could test this to see if an old problem reported on bugzilla[1] was
> >fixed now, but unfortunately it is still there.
> >
> >The ticket is private I guess, but basically the problem happens when bonding
> >driver tries to print something after it had taken the write_lock (monitor
> >functions, enslave/de-enslave), so the printk() will pass through netpoll, then
> >on bonding again which no matter what mode you use, it will try to read_lock()
> >the lock again. The result is a deadlock and the entire system hangs.
> >
>
> Does the attached patch fix this hang?
I got another issue now:
[ 89.523062] bonding: bond0: enslaving eth0 as a backup interface with a down link.
[ 89.580746] bonding: bond0: enslaving eth2 as a backup interface with a down link.
[ 91.198527] e1000: eth2 NIC Link is Up 100 Mbps Half Duplex, Flow Control: None
[ 91.238245] bonding: bond0: link status definitely up for interface eth2.
[ 91.245381] BUG: scheduling while atomic: bond0/2716/0x10000100
[ 91.251565] 5 locks held by bond0/2716:
[ 91.255663] #0: ((bond_dev->name)){+.+.+.}, at: [<ffffffff81045fb4>] worker_thread+0x19a/0x2e2
[ 91.265179] #1: ((&(&bond->mii_work)->work)){+.+.+.}, at: [<ffffffff81045fb4>] worker_thread+0x19a/0x2e2
[ 91.275554] #2: (rtnl_mutex){+.+.+.}, at: [<ffffffff812daf38>] rtnl_lock+0x12/0x14
[ 91.284018] #3: (&bond->lock){++.+.+}, at: [<ffffffffa029e06a>] bond_mii_monitor+0x2a2/0x4ed [bonding]
[ 91.294230] #4: (&bond->curr_slave_lock){+...+.}, at: [<ffffffffa029e239>] bond_mii_monitor+0x471/0x4ed [bonding]
[ 91.305387] Modules linked in: bonding sunrpc ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 dm_mirror dm_region_hash dm_log dm_multipath uinput snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ppdev parport_pc parport rtc_cmos snd_timer tg3 snd ide_cd_mod i5000_edac i2c_i801 libphy rtc_core rtc_lib edac_core pcspkr e1000 dcdbas uhci_hcd tulip shpchp i2c_core cdrom serio_raw soundcore sg snd_page_alloc raid0 sd_mod button [last unloaded: mperf]
[ 91.357735] Pid: 2716, comm: bond0 Not tainted 2.6.34-04700-gd938a70-dirty #36
[ 91.371112] Call Trace:
[ 91.373825] [<ffffffff81056002>] ? __debug_show_held_locks+0x22/0x24
[ 91.380530] [<ffffffff8102e4a2>] __schedule_bug+0x6d/0x72
[ 91.386284] [<ffffffff81363f6e>] schedule+0xc9/0x791
[ 91.391600] [<ffffffff81032540>] __cond_resched+0x25/0x30
[ 91.397350] [<ffffffff81364757>] _cond_resched+0x27/0x32
[ 91.403013] [<ffffffff810ab243>] kmem_cache_alloc+0x2b/0xac
[ 91.408936] [<ffffffff812c61fd>] skb_clone+0x42/0x5d
[ 91.414253] [<ffffffff812ec696>] netlink_broadcast+0x192/0x369
[ 91.420436] [<ffffffff812ecdc3>] nlmsg_notify+0x43/0x89
[ 91.426012] [<ffffffff812dabc7>] rtnl_notify+0x2b/0x2d
[ 91.431501] [<ffffffff812dacbc>] rtmsg_ifinfo+0xf3/0x118
[ 91.437165] [<ffffffff812dad0c>] rtnetlink_event+0x2b/0x2f
[ 91.443003] [<ffffffff81369fe4>] notifier_call_chain+0x32/0x5e
[ 91.449188] [<ffffffff8104d618>] raw_notifier_call_chain+0xf/0x11
[ 91.455634] [<ffffffff812cfc73>] call_netdevice_notifiers+0x45/0x4a
[ 91.462253] [<ffffffff812d04f7>] netdev_bonding_change+0x12/0x14
[ 91.468614] [<ffffffffa029d589>] bond_select_active_slave+0xe8/0x123 [bonding]
[ 91.476408] [<ffffffffa029e241>] bond_mii_monitor+0x479/0x4ed [bonding]
[ 91.483375] [<ffffffff81046009>] worker_thread+0x1ef/0x2e2
[ 91.489212] [<ffffffff81045fb4>] ? worker_thread+0x19a/0x2e2
[ 91.495227] [<ffffffffa029ddc8>] ? bond_mii_monitor+0x0/0x4ed [bonding]
[ 91.502192] [<ffffffff81049c71>] ? autoremove_wake_function+0x0/0x34
[ 91.508897] [<ffffffff81045e1a>] ? worker_thread+0x0/0x2e2
[ 91.514734] [<ffffffff810498bb>] kthread+0x7a/0x82
[ 91.519878] [<ffffffff81003714>] kernel_thread_helper+0x4/0x10
[ 91.526060] [<ffffffff81366ffc>] ? restore_args+0x0/0x30
[ 91.531723] [<ffffffff81049841>] ? kthread+0x0/0x82
[ 91.536953] [<ffffffff81003710>] ? kernel_thread_helper+0x0/0x10
[ 91.543343] bonding: bond0: making interface eth2 the new active one.
[ 91.550554] bonding: bond0: first active interface up!
[ 91.556859] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
No other patch applied. Just started netconsole over bonding, so no need
to pull the cable from slaves. Reproduced twice, one I got the
backtrace above, and on the other one the system hangs completely
after the BUG: scheduling message.
fbl
>
> Thanks!
>
> ----------------------->
>
> We should notify netconsole that bond is changing its slaves
> when we use active-backup mode.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
>
> ----
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 5e12462..9494c02 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1199,6 +1199,7 @@ void bond_select_active_slave(struct bonding *bond)
>
> best_slave = bond_find_best_slave(bond);
> if (best_slave != bond->curr_active_slave) {
> + netdev_bonding_change(bond->dev, NETDEV_BONDING_DESLAVE);
> bond_change_active_slave(bond, best_slave);
> rv = bond_set_carrier(bond);
> if (!rv)
> @@ -2154,6 +2155,7 @@ static int bond_ioctl_change_active(struct net_device *bond_dev, struct net_devi
> (old_active) &&
> (new_active->link == BOND_LINK_UP) &&
> IS_UP(new_active->dev)) {
> + netdev_bonding_change(bond->dev, NETDEV_BONDING_DESLAVE);
> write_lock_bh(&bond->curr_slave_lock);
> bond_change_active_slave(bond, new_active);
> write_unlock_bh(&bond->curr_slave_lock);
--
Flavio
^ permalink raw reply
* Re: [v5 Patch 1/3] netpoll: add generic support for bridge and bonding devices
From: Jay Vosburgh @ 2010-05-28 21:03 UTC (permalink / raw)
To: Flavio Leitner
Cc: Cong Wang, linux-kernel, Matt Mackall, netdev, bridge,
Andy Gospodarek, Neil Horman, Jeff Moyer, Stephen Hemminger,
bonding-devel, David Miller
In-Reply-To: <20100528204229.GD2345@sysclose.org>
Flavio Leitner <fbl@sysclose.org> wrote:
>On Fri, May 28, 2010 at 04:16:34PM +0800, Cong Wang wrote:
>> On 05/28/10 02:05, Flavio Leitner wrote:
>> >
>> >Hi guys!
>> >
>> >I finally could test this to see if an old problem reported on bugzilla[1] was
>> >fixed now, but unfortunately it is still there.
>> >
>> >The ticket is private I guess, but basically the problem happens when bonding
>> >driver tries to print something after it had taken the write_lock (monitor
>> >functions, enslave/de-enslave), so the printk() will pass through netpoll, then
>> >on bonding again which no matter what mode you use, it will try to read_lock()
>> >the lock again. The result is a deadlock and the entire system hangs.
>> >
>>
>> Does the attached patch fix this hang?
>
>I got another issue now:
>
>[ 89.523062] bonding: bond0: enslaving eth0 as a backup interface with a down link.
>[ 89.580746] bonding: bond0: enslaving eth2 as a backup interface with a down link.
>[ 91.198527] e1000: eth2 NIC Link is Up 100 Mbps Half Duplex, Flow Control: None
>[ 91.238245] bonding: bond0: link status definitely up for interface eth2.
>
>[ 91.245381] BUG: scheduling while atomic: bond0/2716/0x10000100
>[ 91.251565] 5 locks held by bond0/2716:
>[ 91.255663] #0: ((bond_dev->name)){+.+.+.}, at: [<ffffffff81045fb4>] worker_thread+0x19a/0x2e2
>[ 91.265179] #1: ((&(&bond->mii_work)->work)){+.+.+.}, at: [<ffffffff81045fb4>] worker_thread+0x19a/0x2e2
>[ 91.275554] #2: (rtnl_mutex){+.+.+.}, at: [<ffffffff812daf38>] rtnl_lock+0x12/0x14
>[ 91.284018] #3: (&bond->lock){++.+.+}, at: [<ffffffffa029e06a>] bond_mii_monitor+0x2a2/0x4ed [bonding]
>[ 91.294230] #4: (&bond->curr_slave_lock){+...+.}, at: [<ffffffffa029e239>] bond_mii_monitor+0x471/0x4ed [bonding]
>[ 91.305387] Modules linked in: bonding sunrpc ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 dm_mirror dm_region_hash dm_log dm_multipath uinput snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ppdev parport_pc parport rtc_cmos snd_timer tg3 snd ide_cd_mod i5000_edac i2c_i801 libphy rtc_core rtc_lib edac_core pcspkr e1000 dcdbas uhci_hcd tulip shpchp i2c_core cdrom serio_raw soundcore sg snd_page_alloc raid0 sd_mod button [last unloaded: mperf]
>[ 91.357735] Pid: 2716, comm: bond0 Not tainted 2.6.34-04700-gd938a70-dirty #36
>[ 91.371112] Call Trace:
>[ 91.373825] [<ffffffff81056002>] ? __debug_show_held_locks+0x22/0x24
>[ 91.380530] [<ffffffff8102e4a2>] __schedule_bug+0x6d/0x72
>[ 91.386284] [<ffffffff81363f6e>] schedule+0xc9/0x791
>[ 91.391600] [<ffffffff81032540>] __cond_resched+0x25/0x30
>[ 91.397350] [<ffffffff81364757>] _cond_resched+0x27/0x32
>[ 91.403013] [<ffffffff810ab243>] kmem_cache_alloc+0x2b/0xac
>[ 91.408936] [<ffffffff812c61fd>] skb_clone+0x42/0x5d
>[ 91.414253] [<ffffffff812ec696>] netlink_broadcast+0x192/0x369
>[ 91.420436] [<ffffffff812ecdc3>] nlmsg_notify+0x43/0x89
>[ 91.426012] [<ffffffff812dabc7>] rtnl_notify+0x2b/0x2d
>[ 91.431501] [<ffffffff812dacbc>] rtmsg_ifinfo+0xf3/0x118
>[ 91.437165] [<ffffffff812dad0c>] rtnetlink_event+0x2b/0x2f
>[ 91.443003] [<ffffffff81369fe4>] notifier_call_chain+0x32/0x5e
>[ 91.449188] [<ffffffff8104d618>] raw_notifier_call_chain+0xf/0x11
>[ 91.455634] [<ffffffff812cfc73>] call_netdevice_notifiers+0x45/0x4a
>[ 91.462253] [<ffffffff812d04f7>] netdev_bonding_change+0x12/0x14
This warning is because the notifier call is happening with spin
locks held.
>[ 91.468614] [<ffffffffa029d589>] bond_select_active_slave+0xe8/0x123 [bonding]
>[ 91.476408] [<ffffffffa029e241>] bond_mii_monitor+0x479/0x4ed [bonding]
>[ 91.483375] [<ffffffff81046009>] worker_thread+0x1ef/0x2e2
>[ 91.489212] [<ffffffff81045fb4>] ? worker_thread+0x19a/0x2e2
>[ 91.495227] [<ffffffffa029ddc8>] ? bond_mii_monitor+0x0/0x4ed [bonding]
>[ 91.502192] [<ffffffff81049c71>] ? autoremove_wake_function+0x0/0x34
>[ 91.508897] [<ffffffff81045e1a>] ? worker_thread+0x0/0x2e2
>[ 91.514734] [<ffffffff810498bb>] kthread+0x7a/0x82
>[ 91.519878] [<ffffffff81003714>] kernel_thread_helper+0x4/0x10
>[ 91.526060] [<ffffffff81366ffc>] ? restore_args+0x0/0x30
>[ 91.531723] [<ffffffff81049841>] ? kthread+0x0/0x82
>[ 91.536953] [<ffffffff81003710>] ? kernel_thread_helper+0x0/0x10
>[ 91.543343] bonding: bond0: making interface eth2 the new active one.
>[ 91.550554] bonding: bond0: first active interface up!
>[ 91.556859] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
>
>
>No other patch applied. Just started netconsole over bonding, so no need
>to pull the cable from slaves. Reproduced twice, one I got the
>backtrace above, and on the other one the system hangs completely
>after the BUG: scheduling message.
>
>fbl
>
>
>>
>> Thanks!
>>
>> ----------------------->
>>
>> We should notify netconsole that bond is changing its slaves
>> when we use active-backup mode.
>>
>> Signed-off-by: WANG Cong <amwang@redhat.com>
>>
>> ----
>>
>
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 5e12462..9494c02 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -1199,6 +1199,7 @@ void bond_select_active_slave(struct bonding *bond)
>>
>> best_slave = bond_find_best_slave(bond);
>> if (best_slave != bond->curr_active_slave) {
>> + netdev_bonding_change(bond->dev, NETDEV_BONDING_DESLAVE);
>> bond_change_active_slave(bond, best_slave);
>> rv = bond_set_carrier(bond);
>> if (!rv)
You can't do this here; the driver is holding various spin
locks, and notifier calls can sleep (hence the warning). If you look at
the bond_change_active_slave function, it drops all locks other than
RTNL before making a notifier call, e.g.,
void bond_change_active_slave(struct bonding *bond, struct slave *new_active)
{
[...]
if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) {
[...]
write_unlock_bh(&bond->curr_slave_lock);
read_unlock(&bond->lock);
netdev_bonding_change(bond->dev, NETDEV_BONDING_FAILOVER);
read_lock(&bond->lock);
write_lock_bh(&bond->curr_slave_lock);
}
You may be able to add your notifier to this case, or change
your handler to notice the _FAILOVER notifier.
>> @@ -2154,6 +2155,7 @@ static int bond_ioctl_change_active(struct net_device *bond_dev, struct net_devi
>> (old_active) &&
>> (new_active->link == BOND_LINK_UP) &&
>> IS_UP(new_active->dev)) {
>> + netdev_bonding_change(bond->dev, NETDEV_BONDING_DESLAVE);
>> write_lock_bh(&bond->curr_slave_lock);
>> bond_change_active_slave(bond, new_active);
>> write_unlock_bh(&bond->curr_slave_lock);
This case will have the same problem, but will only be hit if a
user does a manual "ifenslave -c bond0 ethX".
You also probably wanted to do the sysfs path, but if the
notifier goes into the change_active_slave function itself, then I don't
think additional notifications would be necessary.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [REGRESSION,BISECTED] MIPv6 support broken by f4f914b58019f0
From: Arnaud Ebalard @ 2010-05-28 21:15 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Brian Haley, David Miller, Jiri Olsa, Scott Otto, netdev
In-Reply-To: <4C000E37.7080306@linux-ipv6.org>
Hi,
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
>>> I guess I always believed setting SO_BINDTODEVICE should always force
>>> traffic out that interface, but from Yoshifuji's email it seems that
>>> maybe wasn't the intention, at least for things that don't meet
>>> the rt_need_strict() criteria like globals. I don't know the history
>>> behind the setsockopt.
>>
>> The behavior I would expect from a combination of RFC 4191 and
>> SO_BINDTODEVICE sockopt would be the use of the interface as outgoing
>> interface and then the use of the best router (using router preference
>> info, reachability, ...) available on the subnet. IIRC, the router
>> preference info is per default router list in the RFC, i.e. per
>> interface.
>
> Good point.
>
> Whatever our original intention/thought was,
> current RFC says that we should honor outgoing interface
> specified by user (by IPV6_PKTINFO etc.), as we do for
> SO_BINDTODEVICE in IPv4 as well.
>
> In this sense, checking sk->sk_bound_dev_if in
> ip6_route_output() is not enough because we need to
> take outgoing interface specified in ancillary data
> into account, which is set to fl->oif.
>
> How about adding additional "flags" parameter
> for ip6_route_output()?
I think this may provide a better long term solution but getting all
combinations of cases (SO_BINDTODEVICE and other IPv6 sockopts) work
together (possibly with external info like RFC 4191 ones gathered from
RA or specific local routing config) will be a bit tricky.
Meanwhile, regarding the regression, as Brian's fix handles most
cases, I think it would be useful to apply it and push it to the
stable team.
Cheers,
a+
^ 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