* [PATCH 2/9] Bluetooth: Make USB device id constant
From: Marcel Holtmann @ 2010-02-27 22:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <cover.1267276098.git.marcel@holtmann.org>
From: Márton Németh <nm127@freemail.hu>
The id_table field of the struct usb_device_id is constant in <linux/usb.h>
so it is worth to make bcm203x_table also constant.
The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r@
disable decl_init,const_decl_init;
identifier I1, I2, x;
@@
struct I1 {
...
const struct I2 *x;
...
};
@s@
identifier r.I1, y;
identifier r.x, E;
@@
struct I1 y = {
.x = E,
};
@c@
identifier r.I2;
identifier s.E;
@@
const struct I2 E[] = ... ;
@depends on !c@
identifier r.I2;
identifier s.E;
@@
+ const
struct I2 E[] = ...;
// </smpl>
Signed-off-by: Márton Németh <nm127@freemail.hu>
Cc: Julia Lawall <julia@diku.dk>
Cc: cocci@diku.dk
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
drivers/bluetooth/bcm203x.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/bluetooth/bcm203x.c b/drivers/bluetooth/bcm203x.c
index eafd4af..b0c84c1 100644
--- a/drivers/bluetooth/bcm203x.c
+++ b/drivers/bluetooth/bcm203x.c
@@ -39,7 +39,7 @@
#define VERSION "1.2"
-static struct usb_device_id bcm203x_table[] = {
+static const struct usb_device_id bcm203x_table[] = {
/* Broadcom Blutonium (BCM2033) */
{ USB_DEVICE(0x0a5c, 0x2033) },
--
1.6.6
^ permalink raw reply related
* [PATCH 1/9] Bluetooth: Add __init/__exit macros to Marvell SDIO driver
From: Marcel Holtmann @ 2010-02-27 22:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <cover.1267276098.git.marcel@holtmann.org>
From: Peter Huewe <peterhuewe@gmx.de>
Trivial patch which adds the __init/__exit macros to the module_init/
module_exit functions of btmrvl_sdio.c driver.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
drivers/bluetooth/btmrvl_sdio.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 57d965b..94f1f55 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -976,7 +976,7 @@ static struct sdio_driver bt_mrvl_sdio = {
.remove = btmrvl_sdio_remove,
};
-static int btmrvl_sdio_init_module(void)
+static int __init btmrvl_sdio_init_module(void)
{
if (sdio_register_driver(&bt_mrvl_sdio) != 0) {
BT_ERR("SDIO Driver Registration Failed");
@@ -989,7 +989,7 @@ static int btmrvl_sdio_init_module(void)
return 0;
}
-static void btmrvl_sdio_exit_module(void)
+static void __exit btmrvl_sdio_exit_module(void)
{
/* Set the flag as user is removing this module. */
user_rmmod = 1;
--
1.6.6
^ permalink raw reply related
* Pull request: bluetooth-next-2.6 2010-02-27
From: Marcel Holtmann @ 2010-02-27 22:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]
I was hoping to get the Enhanced L2CAP updates ready for this merge window,
but in the end they were not stable enough. So I removed all the L2CAP
changes out of this merge request.
The leftovers are small updates and bug fixes. The only bigger change is
a patch that adds per controller debugfs. That way drivers don't have to
deal with it on their own. This avoids clashes with multiple controllers
attached to the same system. The Marvell driver is one of the examples
where this is needed. Their debugfs support and multiple controllers was
not done properly.
Regards
Marcel
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-next-2.6.git master
This will update the following files:
drivers/bluetooth/ath3k.c | 2 +
drivers/bluetooth/bcm203x.c | 2 +-
drivers/bluetooth/bfusb.c | 2 +-
drivers/bluetooth/bluecard_cs.c | 2 +-
drivers/bluetooth/bpa10x.c | 2 +-
drivers/bluetooth/bt3c_cs.c | 2 +-
drivers/bluetooth/btmrvl_debugfs.c | 14 ++--
drivers/bluetooth/btmrvl_main.c | 2 +-
drivers/bluetooth/btmrvl_sdio.c | 4 +-
drivers/bluetooth/btsdio.c | 2 +-
drivers/bluetooth/btuart_cs.c | 2 +-
drivers/bluetooth/btusb.c | 2 +-
drivers/bluetooth/dtl1_cs.c | 2 +-
drivers/bluetooth/hci_ldisc.c | 2 +-
drivers/bluetooth/hci_vhci.c | 2 +-
include/net/bluetooth/hci.h | 6 ++-
include/net/bluetooth/hci_core.h | 5 +-
net/bluetooth/hci_core.c | 12 +++-
net/bluetooth/hci_event.c | 1 +
net/bluetooth/hci_sock.c | 2 +-
net/bluetooth/hci_sysfs.c | 122 +++++++++++++++++++++++++----------
21 files changed, 129 insertions(+), 63 deletions(-)
through these ChangeSets:
Dan Carpenter (1):
Bluetooth: Add missing kfree() on error path in Atheros driver
Johann Felix Soden (1):
Bluetooth: Fix out of scope variable access in hci_sock_cmsg()
Marcel Holtmann (4):
Bluetooth: Convert controller hdev->type to hdev->bus
Bluetooth: Convert inquiry cache to use debugfs instead of sysfs
Bluetooth: Convert Marvell driver to use per adapter debugfs
Bluetooth: Add controller types for BR/EDR and 802.11 AMP
Márton Németh (1):
Bluetooth: Make USB device id constant
Peter Huewe (1):
Bluetooth: Add __init/__exit macros to Marvell SDIO driver
Stephen Coe (1):
Bluetooth: Add SCO fallback for unsupported feature error
^ permalink raw reply
* Re: [net-next-2.6 PATCH] infiniband: convert to use netdev_for_each_mc_addr
From: Jiri Pirko @ 2010-02-27 22:07 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Or Gerlitz, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Moni Shoua
In-Reply-To: <20100227184410.GB13231-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Sat, Feb 27, 2010 at 07:44:10PM CET, jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org wrote:
>On Sat, Feb 27, 2010 at 11:38:37AM +0100, Jiri Pirko wrote:
>
>> >The problem this statement is trying to solve had to do with bonding
>> >creating multicast addresess for ethernet rather than infiniband in
>> >some cases. This happens because bonding makes a device that switches
>> >from ethernet to infiniband during its lifetime. I'm not quite
>> >sure what kind of life cycle those addresses go through, but if they
>> >somehow stay on the mc_list then ipoib_mcast_addr_is_valid will still
>> >need to have the check.
>
>> Ok I see your point now. But in this case, the length check should be in all
>> drivers because if for example bonding device changes from infiniband back to
>> eth, the addresses stored would be "cut" to 6 bytes and would make no sense.
>
>Ideally, but the other wrinkle is due to other problems in the ipoib
>driver one bad multicast address blocks further addresses from being
>processed - effectively rendering the interface useless for
>multicast. Ethernet drivers will just subscribe to a bogus address, no
>real harm done.
>
>I would prefer to see the check remain in ipoib until we can see
>through testing that it is no longer triggering.
Fair enough.
Subject: [net-next-2.6 PATCH] ipoib: returned back addrle check for mc addresses
Apparently bogus mc address can brake IPOIB multicast processing. Therefore
returning the check for addrlen back until this is resolved in bonding (I don't
see any other point from where mc address with non-dev->addr_len length can came
from).
Signed-off-by: Jiri Pirko <jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 19eba3c..d41ea27 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -767,8 +767,11 @@ void ipoib_mcast_dev_flush(struct net_device *dev)
}
}
-static int ipoib_mcast_addr_is_valid(const u8 *addr, const u8 *broadcast)
+static int ipoib_mcast_addr_is_valid(const u8 *addr, unsigned int addrlen,
+ const u8 *broadcast)
{
+ if (addrlen != INFINIBAND_ALEN)
+ return 0;
/* reserved QPN, prefix, scope */
if (memcmp(addr, broadcast, 6))
return 0;
@@ -812,6 +815,7 @@ void ipoib_mcast_restart_task(struct work_struct *work)
union ib_gid mgid;
if (!ipoib_mcast_addr_is_valid(mclist->dmi_addr,
+ mclist->dmi_addrlen,
dev->broadcast))
continue;
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [net-next-2.6 PATCH] ethtool: Add n-tuple string length to drvinfo and return it
From: Waskiewicz Jr, Peter P @ 2010-02-27 20:28 UTC (permalink / raw)
To: Jeff Garzik
Cc: Waskiewicz Jr, Peter P, Kirsher, Jeffrey T, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, Ben Hutchings
In-Reply-To: <4B88BC2C.1030304@garzik.org>
On Fri, 26 Feb 2010, Jeff Garzik wrote:
> On 02/26/2010 06:49 PM, Peter P Waskiewicz Jr wrote:
> > On Fri, 2010-02-26 at 05:56 -0800, Jeff Garzik wrote:
> >> On 02/26/2010 06:54 AM, Jeff Kirsher wrote:
> >>> From: Peter Waskiewicz<peter.p.waskiewicz.jr@intel.com>
> >>>
> >>> The drvinfo struct should include the number of strings that
> >>> get_rx_ntuple will return. It will be variable if an underlying
> >>> driver implements its own get_rx_ntuple routine, so userspace
> >>> needs to know how much data is coming.
> >>>
> >>> Signed-off-by: Peter P Waskiewicz Jr<peter.p.waskiewicz.jr@intel.com>
> >>> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> >>> ---
> >>>
> >>> include/linux/ethtool.h | 1 +
> >>> net/core/ethtool.c | 3 +++
> >>> 2 files changed, 4 insertions(+), 0 deletions(-)
> >>
> >> (resending reply, standard patch-sending box is having trouble sending
> >> to vger)
> >>
> >>
> >> As noted in the other email, your patch breaks ABI. The proper path is
> >> to decrease the size of reserved struct member, and NOT shift the offset
> >> of other members.
> >>
> >>
> >>
> >> However, perhaps consider the following patch for returning n-tuple
> >> count, for four reasons:
> >>
> >> 1) space in ethtool_drvinfo is limited
> >>
> >> 2) the patch below permits trivial string set addition, without
> >> ABI changes beyond adding a new ETH_SS_xxx constant.
> >>
> >> 3) the patch below permits direct access to ops->get_sset_count(),
> >> rather than implicit access via ethtool_drvinfo
> >>
> >> 4) ethtool_drvinfo interface does not permit indication of
> >> ops->get_sset_count() failure, versus returning zero value. The
> >> patch below does so, via output sset_mask.
> >>
> >> WARNING: this patch is compile-tested only.
> >>
> >> NOTE: I added a cosmetic fix to ETHTOOL_[GS]RXNTUPLE constants, making
> >> their indentation consistent with the rest of the list of constants.
> >>
> >> Signed-off-by: Jeff Garzik<jgarzik@redhat.com>
> >
> > I'm updating your patch since I found an issue. The mask is passing in
> > the ETH_SS_* flags, but then they're treated as bits, not enumerated
> > flags. I'm thinking of the best non-intrusive way to correct it.
>
> As Ben noted, you cannot change those enumerated values, as they are
> already part of the ABI.
Apologies. My outstanding IT support marked your and Ben's emails as
spam, and moved it aside where I couldn't see them until this morning...
>
> For ETHTOOL_GSSET_INFO, you initialize the sset_mask like this:
>
> info.sset_mask = (1ULL << ETH_SS_NTUPLE_FILTERS);
>
> A multiple initialization would look like this:
>
> info.sset_mask = (1ULL << ETH_SS_NTUPLE_FILTERS) |
> (1ULL << ETH_SS_STATS) |
> (1ULL << ETH_SS_PRIV_FLAGS);
>
> Do you still see an issue in my suggested code, now that sset_mask
> confusion is cleared up?
This sounds like it makes sense. I'll make the changes (and the userspace
change you suggested in another mail) and get new patches out.
>
> Regards,
>
> Jeff
^ permalink raw reply
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Eric W. Biederman @ 2010-02-27 19:44 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: hadi, Daniel Lezcano, Patrick McHardy, Linux Netdev List,
containers, Netfilter Development Mailinglist, Ben Greear,
Serge Hallyn, Matt Helsley
In-Reply-To: <4B89727C.9040602@parallels.com>
Pavel Emelyanov <xemul@parallels.com> writes:
> Eric W. Biederman wrote:
>> Pavel Emelyanov <xemul@parallels.com> writes:
>>
>>> Eric W. Biederman wrote:
>>>> Pavel Emelyanov <xemul@parallels.com> writes:
>>>>
>>>>> Thanks. What's the problem with setns?
>>>> joining a preexisting namespace is roughly the same problem as
>>>> unsharing a namespace. We simply haven't figure out how to do it
>>>> safely for the pid and the uid namespaces.
>>> The pid may change after this for sure. What problems do you know
>>> about it? What if we try to allocate the same PID in a new space
>>> or return -EBUSY? This will be a good starting point. If we manage
>>> to fix it later this will not break the API at all.
>>
>> Parentage. The pid is the identity of a process and all kinds of things
>> make assumptions in all kinds of strange places. I don't see how
>> waitpid can work if you change the pid.
>
> Agree. But what if we enter a pid space, which is a subnamespace of a current
> one? In that case parent will still see the task by its old pid. We can restrict
> first version of entering with this rule as well and this restriction will not
> block us in typical usecase (I mean enter a container from a host).
When I was thinking about pid namespaces and unshare last time. The idea I came
to was we unshare of the pid namespace should only affect which pid namespace
your children are in.
I remember that do that there were a few cases where you would have to access
task->pid->pid_ns instead of task->nsproxy->pid_ns, but essentially it was pretty
simple.
>> glibc doesn't cope if you change someones pid.
>
> OK, but what if we try to allocate the same pid returning -EBUSY on failure?
>
> My aim is to provide even a restricted enter. For most of the cases this
> should work and make our lives easier. So two restrictions currently:
> a) enter a sub namespace
> b) allocate the same pid as we have now
>
> Hm? :)
Replacing struct pid is guaranteed to do all kinds of nasty things with
signal handling and the like, de_thread is nasty enough and you are talking
something worse. So if we can change pid namespaces without changing
the pid I am for it.
Eric
^ permalink raw reply
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Pavel Emelyanov @ 2010-02-27 19:29 UTC (permalink / raw)
To: Eric W. Biederman
Cc: hadi, Daniel Lezcano, Patrick McHardy, Linux Netdev List,
containers, Netfilter Development Mailinglist, Ben Greear,
Serge Hallyn, Matt Helsley
In-Reply-To: <m1iq9io5sc.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Pavel Emelyanov <xemul@parallels.com> writes:
>
>> Eric W. Biederman wrote:
>>> Pavel Emelyanov <xemul@parallels.com> writes:
>>>
>>>> Thanks. What's the problem with setns?
>>> joining a preexisting namespace is roughly the same problem as
>>> unsharing a namespace. We simply haven't figure out how to do it
>>> safely for the pid and the uid namespaces.
>> The pid may change after this for sure. What problems do you know
>> about it? What if we try to allocate the same PID in a new space
>> or return -EBUSY? This will be a good starting point. If we manage
>> to fix it later this will not break the API at all.
>
> Parentage. The pid is the identity of a process and all kinds of things
> make assumptions in all kinds of strange places. I don't see how
> waitpid can work if you change the pid.
Agree. But what if we enter a pid space, which is a subnamespace of a current
one? In that case parent will still see the task by its old pid. We can restrict
first version of entering with this rule as well and this restriction will not
block us in typical usecase (I mean enter a container from a host).
> glibc doesn't cope if you change someones pid.
OK, but what if we try to allocate the same pid returning -EBUSY on failure?
My aim is to provide even a restricted enter. For most of the cases this
should work and make our lives easier. So two restrictions currently:
a) enter a sub namespace
b) allocate the same pid as we have now
Hm? :)
>>> Definitely. I only consider the current interface to be a mushy not
>>> set in stone.
>> OK. The interface is good. I just don't want you to send it for an inclusion
>> until we decide what to do with waiting.
>
> Sure. I am get a jump on 2.6.35 not aiming for inclusion this merge
> window. There is plenty of time.
Good!
>> Poll is OK with me. As far as the notification is concerned - that's also
>> done in OpenVZ. If you are OK to wait for a week or two I can do it for net
>> namespaces.
>
> Seems reasonable.
OK. I'll spend some time playing with it next week then.
> Eric
>
Thanks,
Pavel
^ permalink raw reply
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Eric W. Biederman @ 2010-02-27 19:08 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: hadi, Daniel Lezcano, Patrick McHardy, Linux Netdev List,
containers, Netfilter Development Mailinglist, Ben Greear,
Serge Hallyn, Matt Helsley
In-Reply-To: <4B894564.7080104@parallels.com>
Pavel Emelyanov <xemul@parallels.com> writes:
> Eric W. Biederman wrote:
>> Pavel Emelyanov <xemul@parallels.com> writes:
>>
>>> Thanks. What's the problem with setns?
>>
>> joining a preexisting namespace is roughly the same problem as
>> unsharing a namespace. We simply haven't figure out how to do it
>> safely for the pid and the uid namespaces.
>
> The pid may change after this for sure. What problems do you know
> about it? What if we try to allocate the same PID in a new space
> or return -EBUSY? This will be a good starting point. If we manage
> to fix it later this will not break the API at all.
Parentage. The pid is the identity of a process and all kinds of things
make assumptions in all kinds of strange places. I don't see how
waitpid can work if you change the pid.
glibc doesn't cope if you change someones pid.
>> Definitely. I only consider the current interface to be a mushy not
>> set in stone.
>
> OK. The interface is good. I just don't want you to send it for an inclusion
> until we decide what to do with waiting.
Sure. I am get a jump on 2.6.35 not aiming for inclusion this merge
window. There is plenty of time.
>
> Poll is OK with me. As far as the notification is concerned - that's also
> done in OpenVZ. If you are OK to wait for a week or two I can do it for net
> namespaces.
Seems reasonable.
Eric
^ permalink raw reply
* Re: [net-next-2.6 PATCH] infiniband: convert to use netdev_for_each_mc_addr
From: Jason Gunthorpe @ 2010-02-27 18:44 UTC (permalink / raw)
To: Jiri Pirko
Cc: Or Gerlitz, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Moni Shoua
In-Reply-To: <20100227103835.GA2862-YzwxZg+R7et1/kRsl7OVgNvLeJWuRmrY@public.gmane.org>
On Sat, Feb 27, 2010 at 11:38:37AM +0100, Jiri Pirko wrote:
> >The problem this statement is trying to solve had to do with bonding
> >creating multicast addresess for ethernet rather than infiniband in
> >some cases. This happens because bonding makes a device that switches
> >from ethernet to infiniband during its lifetime. I'm not quite
> >sure what kind of life cycle those addresses go through, but if they
> >somehow stay on the mc_list then ipoib_mcast_addr_is_valid will still
> >need to have the check.
> Ok I see your point now. But in this case, the length check should be in all
> drivers because if for example bonding device changes from infiniband back to
> eth, the addresses stored would be "cut" to 6 bytes and would make no sense.
Ideally, but the other wrinkle is due to other problems in the ipoib
driver one bad multicast address blocks further addresses from being
processed - effectively rendering the interface useless for
multicast. Ethernet drivers will just subscribe to a bogus address, no
real harm done.
I would prefer to see the check remain in ipoib until we can see
through testing that it is no longer triggering.
> 2) when bonding changes it's type, flush mc addresses and start over.
>
> Second option looks nicer to me, but I might be missing something, thouths?
There was a patch posted that tried to do something like what you are
describing:
From: Moni Shoua <monis-hKgKHo2Ms0F+cjeuK/JdrQ@public.gmane.org>
Subject: Re: [PATCH RESEND] bonding: remap muticast addresses without using dev_close() and dev_open()
Thanks,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH] fix problems with NETIF_F_HIGHDMA in networking drivers
From: FUJITA Tomonori @ 2010-02-27 18:38 UTC (permalink / raw)
To: hancockrwd-Re5JQEeQqe8AvxtiuMwx3w
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, bzolnier-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <51f3faa71002270959o4d1435e3xf67185fccaf50b18-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sat, 27 Feb 2010 11:59:47 -0600
Robert Hancock <hancockrwd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sat, Feb 27, 2010 at 3:53 AM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> > From: Robert Hancock <hancockrwd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date: Fri, 26 Feb 2010 21:08:04 -0600
> >
> >> That seems like a reasonable approach to me. Only question is how to
> >> implement the check for DMA_64BIT. Can we just check page_to_phys on
> >> each of the pages in the skb to see if it's > 0xffffffff ? Are there
> >> any architectures where it's more complicated than that?
> >
> > On almost every platform it's "more complicated than that".
> >
> > This is the whole issue. What matters is the final DMA address and
> > since we have IOMMUs and the like, it is absolutely not tenable to
> > solve this by checking physical address attributes.
>
> Yeah, physical address isn't quite right. There is a precedent for
Probably, you need to check PCI_DMA_BUS_IS_PHYS.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH] fix problems with NETIF_F_HIGHDMA in networking drivers
From: FUJITA Tomonori @ 2010-02-27 18:38 UTC (permalink / raw)
To: hancockrwd; +Cc: davem, bzolnier, linux-kernel, netdev, linux-usb
In-Reply-To: <51f3faa71002271015i7c9ec45j18381b1269bfd799@mail.gmail.com>
On Sat, 27 Feb 2010 12:15:19 -0600
Robert Hancock <hancockrwd@gmail.com> wrote:
> On Sat, Feb 27, 2010 at 6:05 AM, David Miller <davem@davemloft.net> wrote:
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Date: Sat, 27 Feb 2010 12:59:31 +0100
> >
> >> Having IOMMU (even if it is only a software one, i.e. this would
> >> mean swiotlb for x86-32/highmem) always in place would simplify
> >> things greatly..
> >
> > I agree, things would be a lot simpler.
>
> Yeah, the situation kind of sucks on the platforms that don't have any
> IOMMU support, since it means that the DMA API can't handle anything
> over 4GB properly and you need all these hacks in the block layer,
> networking layer, etc. It would be nice if some kind of IOMMU support
> could be relied upon always.
When I proposed such approach (always use swiotlb) before, IIRC,
the objections were:
- better to make allocation respect dma_mask. (I don't think that this
approach is possible since we don't know which device handles data
later when we allocate memory).
- swiotlb is not good for small systems since it allocates too much
memory (we can fix this though).
There might be more.
^ permalink raw reply
* Re: [RFC PATCH] fix problems with NETIF_F_HIGHDMA in networking drivers
From: Robert Hancock @ 2010-02-27 18:15 UTC (permalink / raw)
To: David Miller; +Cc: bzolnier, linux-kernel, netdev, linux-usb
In-Reply-To: <20100227.040502.182574085.davem@davemloft.net>
On Sat, Feb 27, 2010 at 6:05 AM, David Miller <davem@davemloft.net> wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Sat, 27 Feb 2010 12:59:31 +0100
>
>> Having IOMMU (even if it is only a software one, i.e. this would
>> mean swiotlb for x86-32/highmem) always in place would simplify
>> things greatly..
>
> I agree, things would be a lot simpler.
Yeah, the situation kind of sucks on the platforms that don't have any
IOMMU support, since it means that the DMA API can't handle anything
over 4GB properly and you need all these hacks in the block layer,
networking layer, etc. It would be nice if some kind of IOMMU support
could be relied upon always.
^ permalink raw reply
* Re: [RFC PATCH] fix problems with NETIF_F_HIGHDMA in networking drivers
From: Robert Hancock @ 2010-02-27 17:59 UTC (permalink / raw)
To: David Miller; +Cc: bzolnier, linux-kernel, netdev, linux-usb
In-Reply-To: <20100227.015350.71138134.davem@davemloft.net>
On Sat, Feb 27, 2010 at 3:53 AM, David Miller <davem@davemloft.net> wrote:
> From: Robert Hancock <hancockrwd@gmail.com>
> Date: Fri, 26 Feb 2010 21:08:04 -0600
>
>> That seems like a reasonable approach to me. Only question is how to
>> implement the check for DMA_64BIT. Can we just check page_to_phys on
>> each of the pages in the skb to see if it's > 0xffffffff ? Are there
>> any architectures where it's more complicated than that?
>
> On almost every platform it's "more complicated than that".
>
> This is the whole issue. What matters is the final DMA address and
> since we have IOMMUs and the like, it is absolutely not tenable to
> solve this by checking physical address attributes.
Yeah, physical address isn't quite right. There is a precedent for
such a check in the block layer though - look at
blk_queue_bounce_limit in block/blk-settings.c:
void blk_queue_bounce_limit(struct request_queue *q, u64 dma_mask)
{
unsigned long b_pfn = dma_mask >> PAGE_SHIFT;
int dma = 0;
q->bounce_gfp = GFP_NOIO;
#if BITS_PER_LONG == 64
/*
* Assume anything <= 4GB can be handled by IOMMU. Actually
* some IOMMUs can handle everything, but I don't know of a
* way to test this here.
*/
if (b_pfn < (min_t(u64, 0xffffffffUL, BLK_BOUNCE_HIGH) >> PAGE_SHIFT))
dma = 1;
q->limits.bounce_pfn = max_low_pfn;
#else
if (b_pfn < blk_max_low_pfn)
dma = 1;
q->limits.bounce_pfn = b_pfn;
#endif
if (dma) {
init_emergency_isa_pool();
q->bounce_gfp = GFP_NOIO | GFP_DMA;
q->limits.bounce_pfn = b_pfn;
}
}
and then in mm/bounce.c:
static void __blk_queue_bounce(struct request_queue *q, struct bio **bio_orig,
mempool_t *pool)
{
struct page *page;
struct bio *bio = NULL;
int i, rw = bio_data_dir(*bio_orig);
struct bio_vec *to, *from;
bio_for_each_segment(from, *bio_orig, i) {
page = from->bv_page;
/*
* is destination page below bounce pfn?
*/
if (page_to_pfn(page) <= queue_bounce_pfn(q))
continue;
Following that logic then, it appears that page_to_pfn(page) >
(0xffffffff >> PAGE_SHIFT) should tell us what we want to know for the
DMA_64BIT flag.. or am I missing something?
^ permalink raw reply
* [net-next-2.6 PATCH] wireless: convert to use netdev_for_each_mc_addr
From: Jiri Pirko @ 2010-02-27 17:35 UTC (permalink / raw)
To: netdev; +Cc: davem
also added missed locking in rndis_wlan.c
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/wireless/libertas/main.c | 8 ++++++--
drivers/net/wireless/orinoco/hw.c | 22 +++++++---------------
drivers/net/wireless/orinoco/hw.h | 2 +-
drivers/net/wireless/orinoco/main.c | 3 +--
drivers/net/wireless/ray_cs.c | 8 ++++----
drivers/net/wireless/rndis_wlan.c | 15 ++++++++-------
drivers/net/wireless/zd1201.c | 9 ++++-----
7 files changed, 31 insertions(+), 36 deletions(-)
diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
index cd8ed7f..28a1c9d 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -319,15 +319,18 @@ static int lbs_add_mcast_addrs(struct cmd_ds_mac_multicast_adr *cmd,
{
int i = nr_addrs;
struct dev_mc_list *mc_list;
+ int cnt;
if ((dev->flags & (IFF_UP|IFF_MULTICAST)) != (IFF_UP|IFF_MULTICAST))
return nr_addrs;
netif_addr_lock_bh(dev);
- for (mc_list = dev->mc_list; mc_list; mc_list = mc_list->next) {
+ cnt = netdev_mc_count(dev);
+ netdev_for_each_mc_addr(mc_list, dev) {
if (mac_in_list(cmd->maclist, nr_addrs, mc_list->dmi_addr)) {
lbs_deb_net("mcast address %s:%pM skipped\n", dev->name,
mc_list->dmi_addr);
+ cnt--;
continue;
}
@@ -337,9 +340,10 @@ static int lbs_add_mcast_addrs(struct cmd_ds_mac_multicast_adr *cmd,
lbs_deb_net("mcast address %s:%pM added to filter\n", dev->name,
mc_list->dmi_addr);
i++;
+ cnt--;
}
netif_addr_unlock_bh(dev);
- if (mc_list)
+ if (cnt)
return -EOVERFLOW;
return i;
diff --git a/drivers/net/wireless/orinoco/hw.c b/drivers/net/wireless/orinoco/hw.c
index 404830f..e636924 100644
--- a/drivers/net/wireless/orinoco/hw.c
+++ b/drivers/net/wireless/orinoco/hw.c
@@ -1028,7 +1028,7 @@ int orinoco_clear_tkip_key(struct orinoco_private *priv, int key_idx)
}
int __orinoco_hw_set_multicast_list(struct orinoco_private *priv,
- struct dev_addr_list *mc_list,
+ struct net_device *dev,
int mc_count, int promisc)
{
hermes_t *hw = &priv->hw;
@@ -1049,24 +1049,16 @@ int __orinoco_hw_set_multicast_list(struct orinoco_private *priv,
* group address if either we want to multicast, or if we were
* multicasting and want to stop */
if (!promisc && (mc_count || priv->mc_count)) {
- struct dev_mc_list *p = mc_list;
+ struct dev_mc_list *p;
struct hermes_multicast mclist;
- int i;
+ int i = 0;
- for (i = 0; i < mc_count; i++) {
- /* paranoia: is list shorter than mc_count? */
- BUG_ON(!p);
- /* paranoia: bad address size in list? */
- BUG_ON(p->dmi_addrlen != ETH_ALEN);
-
- memcpy(mclist.addr[i], p->dmi_addr, ETH_ALEN);
- p = p->next;
+ netdev_for_each_mc_addr(p, dev) {
+ if (i == mc_count)
+ break;
+ memcpy(mclist.addr[i++], p->dmi_addr, ETH_ALEN);
}
- if (p)
- printk(KERN_WARNING "%s: Multicast list is "
- "longer than mc_count\n", priv->ndev->name);
-
err = hermes_write_ltv(hw, USER_BAP,
HERMES_RID_CNFGROUPADDRESSES,
HERMES_BYTES_TO_RECLEN(mc_count * ETH_ALEN),
diff --git a/drivers/net/wireless/orinoco/hw.h b/drivers/net/wireless/orinoco/hw.h
index e2f7fdc..9799a1d 100644
--- a/drivers/net/wireless/orinoco/hw.h
+++ b/drivers/net/wireless/orinoco/hw.h
@@ -43,7 +43,7 @@ int __orinoco_hw_set_tkip_key(struct orinoco_private *priv, int key_idx,
u8 *tsc, size_t tsc_len);
int orinoco_clear_tkip_key(struct orinoco_private *priv, int key_idx);
int __orinoco_hw_set_multicast_list(struct orinoco_private *priv,
- struct dev_addr_list *mc_list,
+ struct net_device *dev,
int mc_count, int promisc);
int orinoco_hw_get_essid(struct orinoco_private *priv, int *active,
char buf[IW_ESSID_MAX_SIZE+1]);
diff --git a/drivers/net/wireless/orinoco/main.c b/drivers/net/wireless/orinoco/main.c
index a9e9cea..b42634c 100644
--- a/drivers/net/wireless/orinoco/main.c
+++ b/drivers/net/wireless/orinoco/main.c
@@ -1676,8 +1676,7 @@ __orinoco_set_multicast_list(struct net_device *dev)
mc_count = netdev_mc_count(dev);
}
- err = __orinoco_hw_set_multicast_list(priv, dev->mc_list, mc_count,
- promisc);
+ err = __orinoco_hw_set_multicast_list(priv, dev, mc_count, promisc);
return err;
}
diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
index 85905ca..84c530a 100644
--- a/drivers/net/wireless/ray_cs.c
+++ b/drivers/net/wireless/ray_cs.c
@@ -1871,10 +1871,8 @@ static void ray_update_parm(struct net_device *dev, UCHAR objid, UCHAR *value,
/*===========================================================================*/
static void ray_update_multi_list(struct net_device *dev, int all)
{
- struct dev_mc_list *dmi, **dmip;
int ccsindex;
struct ccs __iomem *pccs;
- int i = 0;
ray_dev_t *local = netdev_priv(dev);
struct pcmcia_device *link = local->finder;
void __iomem *p = local->sram + HOST_TO_ECF_BASE;
@@ -1895,9 +1893,11 @@ static void ray_update_multi_list(struct net_device *dev, int all)
writeb(0xff, &pccs->var);
local->num_multi = 0xff;
} else {
+ struct dev_mc_list *dmi;
+ int i = 0;
+
/* Copy the kernel's list of MC addresses to card */
- for (dmip = &dev->mc_list; (dmi = *dmip) != NULL;
- dmip = &dmi->next) {
+ netdev_for_each_mc_addr(dmi, dev) {
memcpy_toio(p, dmi->dmi_addr, ETH_ALEN);
dev_dbg(&link->dev,
"ray_update_multi add addr %02x%02x%02x%02x%02x%02x\n",
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index 65cbd06..9f6d6bf 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -1502,6 +1502,7 @@ static void set_multicast_list(struct usbnet *usbdev)
filter = RNDIS_PACKET_TYPE_DIRECTED | RNDIS_PACKET_TYPE_BROADCAST;
+ netif_addr_lock_bh(usbdev->net);
if (usbdev->net->flags & IFF_PROMISC) {
filter |= RNDIS_PACKET_TYPE_PROMISCUOUS |
RNDIS_PACKET_TYPE_ALL_LOCAL;
@@ -1515,16 +1516,15 @@ static void set_multicast_list(struct usbnet *usbdev)
netdev_warn(usbdev->net,
"couldn't alloc %d bytes of memory\n",
size * ETH_ALEN);
+ netif_addr_unlock_bh(usbdev->net);
return;
}
- mclist = usbdev->net->mc_list;
- for (i = 0; i < size && mclist; mclist = mclist->next) {
- if (mclist->dmi_addrlen != ETH_ALEN)
- continue;
-
- memcpy(buf + i * ETH_ALEN, mclist->dmi_addr, ETH_ALEN);
- i++;
+ i = 0;
+ netdev_for_each_mc_addr(mclist, usbdev->net) {
+ if (i == size)
+ break;
+ memcpy(buf + i++ * ETH_ALEN, mclist->dmi_addr, ETH_ALEN);
}
ret = rndis_set_oid(usbdev, OID_802_3_MULTICAST_LIST, buf,
@@ -1539,6 +1539,7 @@ static void set_multicast_list(struct usbnet *usbdev)
kfree(buf);
}
+ netif_addr_unlock_bh(usbdev->net);
ret = rndis_set_oid(usbdev, OID_GEN_CURRENT_PACKET_FILTER, &filter,
sizeof(filter));
diff --git a/drivers/net/wireless/zd1201.c b/drivers/net/wireless/zd1201.c
index 5d2b52f..6917286 100644
--- a/drivers/net/wireless/zd1201.c
+++ b/drivers/net/wireless/zd1201.c
@@ -875,17 +875,16 @@ static struct iw_statistics *zd1201_get_wireless_stats(struct net_device *dev)
static void zd1201_set_multicast(struct net_device *dev)
{
struct zd1201 *zd = netdev_priv(dev);
- struct dev_mc_list *mc = dev->mc_list;
+ struct dev_mc_list *mc;
unsigned char reqbuf[ETH_ALEN*ZD1201_MAXMULTI];
int i;
if (netdev_mc_count(dev) > ZD1201_MAXMULTI)
return;
- for (i=0; i<netdev_mc_count(dev); i++) {
- memcpy(reqbuf+i*ETH_ALEN, mc->dmi_addr, ETH_ALEN);
- mc = mc->next;
- }
+ i = 0;
+ netdev_for_each_mc_addr(mc, dev)
+ memcpy(reqbuf + i++ * ETH_ALEN, mc->dmi_addr, ETH_ALEN);
zd1201_setconfig(zd, ZD1201_RID_CNFGROUPADDRESS, reqbuf,
netdev_mc_count(dev) * ETH_ALEN, 0);
}
--
1.6.6
^ permalink raw reply related
* Re: [patch] zd1211rw: fix potential array underflow
From: walter harms @ 2010-02-27 17:27 UTC (permalink / raw)
To: Benoit PAPILLAULT
Cc: Dan Carpenter, Daniel Drake, Ulrich Kunitz, John W. Linville,
Johannes Berg, Luis R. Rodriguez, André Goddard Rosa,
linux-wireless, netdev, linux-kernel, kernel-janitors
In-Reply-To: <4B892A2F.2040307@free.fr>
Benoit PAPILLAULT schrieb:
> Dan Carpenter a écrit :
>> The first chunk fixes a debugging assert to print a warning about
>> array underflows.
>> The second chunk corrects a potential array underflow. I also removed
>> an assert
>> in the second chunk because it can no longer happen.
>>
>> Signed-off-by: Dan Carpenter <error27@gmail.com>
>> ---
>> This was found by a static check and compile tested only. Please
>> review carefully.
>>
>> diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c
>> b/drivers/net/wireless/zd1211rw/zd_mac.c
>> index f14deb0..ead2f2c 100644
>> --- a/drivers/net/wireless/zd1211rw/zd_mac.c
>> +++ b/drivers/net/wireless/zd1211rw/zd_mac.c
>> @@ -350,7 +350,7 @@ static void zd_mac_tx_status(struct ieee80211_hw
>> *hw, struct sk_buff *skb,
>> first_idx = info->status.rates[0].idx;
>> ZD_ASSERT(0<=first_idx && first_idx<ARRAY_SIZE(zd_retry_rates));
>> retries = &zd_retry_rates[first_idx];
>> - ZD_ASSERT(0<=retry && retry<=retries->count);
>> + ZD_ASSERT(1 <= retry && retry <= retries->count);
>>
> Note: normal hardware always report a tx_status->retry >= 1. There are 2
> code paths to initialize retry itself : either tx_status is NULL and
> then retry=1 (so we are safe), or tx_status is not NULL and retry =
> tx_status->retry + success >=1 (so we are safe again).
>
> However, I wonder how we should handle if it happens that the HW reports
> a tx_status->retry = 0. I think ZD_ASSERT purpose is to catch
> programming errors, not bogus hardware. Comments?
Simply assume the worst, so far i see the patch does not
add more code nor should it change normal behavier.
This will help to make the code more robust.
just my 2 cents,
walter
>>
>> info->status.rates[0].idx = retries->rate[0];
>> info->status.rates[0].count = 1; // (retry > 1 ? 2 : 1);
>> @@ -360,7 +360,7 @@ static void zd_mac_tx_status(struct ieee80211_hw
>> *hw, struct sk_buff *skb,
>> info->status.rates[i].count = 1; // ((i==retry-1) && success
>> ? 1:2);
>> }
>> for (; i<IEEE80211_TX_MAX_RATES && i<retry; i++) {
>> - info->status.rates[i].idx = retries->rate[retry-1];
>> + info->status.rates[i].idx = retries->rate[retry - 1];
>> info->status.rates[i].count = 1; // (success ? 1:2);
>> }
>> if (i<IEEE80211_TX_MAX_RATES)
>> @@ -424,12 +424,10 @@ void zd_mac_tx_failed(struct urb *urb)
>> first_idx = info->status.rates[0].idx;
>> ZD_ASSERT(0<=first_idx && first_idx<ARRAY_SIZE(zd_retry_rates));
>> retries = &zd_retry_rates[first_idx];
>> - if (retry < 0 || retry > retries->count) {
>> + if (retry <= 0 || retry > retries->count)
>> continue;
>> - }
>>
>> - ZD_ASSERT(0<=retry && retry<=retries->count);
>> - final_idx = retries->rate[retry-1];
>> + final_idx = retries->rate[retry - 1];
>> final_rate = zd_rates[final_idx].hw_value;
>>
>> if (final_rate != tx_status->rate) {
>>
>>
> Acked-by: Benoit Papillault <benoit.papillault@free.fr>
>
> Regards,
> Benoit
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH 30/66] include/net/x25device.h: Checkpatch cleanup
From: Andrea Gelmini @ 2010-02-27 16:51 UTC (permalink / raw)
To: linux-kernel
Cc: Andrea Gelmini, Andrew Hendry, David S. Miller, linux-x25, netdev
In-Reply-To: <1267289508-31031-1-git-send-email-andrea.gelmini@gelma.net>
include/net/x25device.h:13: ERROR: trailing whitespace
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
include/net/x25device.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/x25device.h b/include/net/x25device.h
index 1415bcf..246a17b 100644
--- a/include/net/x25device.h
+++ b/include/net/x25device.h
@@ -10,7 +10,7 @@ static inline __be16 x25_type_trans(struct sk_buff *skb, struct net_device *dev)
skb->dev = dev;
skb_reset_mac_header(skb);
skb->pkt_type = PACKET_HOST;
-
+
return htons(ETH_P_X25);
}
#endif
--
1.7.0.90.g251a4
^ permalink raw reply related
* Re: [PATCH v3 0/7] pci: Add VPD parsing support
From: Jesse Barnes @ 2010-02-27 16:46 UTC (permalink / raw)
To: David Miller; +Cc: mcarlson, linux-pci, netdev, andy
In-Reply-To: <20100227.030831.210644479.davem@davemloft.net>
On Sat, 27 Feb 2010 03:08:31 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Fri, 26 Feb 2010 16:04:38 -0800
>
> > This patch adds code to help parse a device's VPD. The bnx2 and tg3
> > network drivers are modified as an example on how to use the API. I
> > believe the bnx2x driver will also use this API in the future.
>
> PCI folks, ok with this?
>
> And if so, OK if I merge this via the net-next-2.6 tree?
Yeah, latest round looks good to me. Thanks for doing this, Matt!
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] mq: support for bonding
From: Eric Dumazet @ 2010-02-27 16:29 UTC (permalink / raw)
To: "Oleg A. Arkhangelsky"; +Cc: David Miller, netdev
In-Reply-To: <310461267277260@webmail48.yandex.ru>
Le samedi 27 février 2010 à 16:27 +0300, "Oleg A. Arkhangelsky" a
écrit :
>
> Make bonding driver multiqueue aware.
>
I wish it could be true :)
> Signed-off-by: Oleg A. Arkhangelsky <sysoleg@yandex.ru>
>
> ---
>
> drivers/net/bonding/bond_main.c | 5 +++--
> drivers/net/bonding/bonding.h | 1 +
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 430c022..ea4ff33 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -4928,8 +4928,9 @@ int bond_create(struct net *net, const char *name)
>
> rtnl_lock();
>
> - bond_dev = alloc_netdev(sizeof(struct bonding), name ? name : "",
> - bond_setup);
> + bond_dev = alloc_netdev_mq(sizeof(struct bonding), name ? name : "",
> + bond_setup,
> + min_t(u32, BOND_MAX_TX_QUEUES, num_online_cpus()));
> if (!bond_dev) {
> pr_err("%s: eek! can't alloc netdev!\n", name);
> res = -ENOMEM;
> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
> index 257a7a4..4a6cfb4 100644
> --- a/drivers/net/bonding/bonding.h
> +++ b/drivers/net/bonding/bonding.h
> @@ -29,6 +29,7 @@
> #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver"
>
> #define BOND_MAX_ARP_TARGETS 16
> +#define BOND_MAX_TX_QUEUES 8
>
> #define IS_UP(dev) \
> ((((dev)->flags & IFF_UP) == IFF_UP) && \
>
> ---
>
Hi Oleg
1) Could you explain why this arbitrary value (8) was chosen ?
My dev machine has 16 cpus, and my network card has 16 queues per NIC
2) This multi queue support is not a real one, since bond driver is
currently using a per device central lock (bond->lock and
bond->curr_slave_lock).
Every xmit has to get this lock(s) and performance is not optimal.
^ permalink raw reply
* Re: iproute2: adding /128 address to sit interface borks
From: Stephen Hemminger @ 2010-02-27 16:23 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Stephen Hemminger, netdev
In-Reply-To: <alpine.LSU.2.01.1002271601210.29398@obet.zrqbmnf.qr>
On Sat, 27 Feb 2010 16:03:36 +0100 (CET)
Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Friday 2009-07-10 17:27, Stephen Hemminger wrote:
> >On Fri, 10 Jul 2009 14:05:01 +0200 (CEST)
> >Jan Engelhardt <jengelh@medozas.de> wrote:
> >
> >> it's impossible to do this, and the error message does not say why
> >> that is so. No word in dmesg either.
> >>
> >> # ip a a fc00::49/128 peer fc00::7 dev sit7
> >> RTNETLINK answers: Invalid argument
> >
> >You will need to walk through the path in the kernel.
> >In worst case, it means adding kernel printk's.
> >
> >Then if you want to be nice, make a patch to ipaddr.c in iproute
> >utilities so command line can find the error before passing to
> >kernel and give a nice error :-)
>
> The issue here was that the peer is encoded using the broadcast
> field, and since IPv6 has no broadcast, it was rejected by
> the kernel. The error messages really need to be improved.
>
> This year also came an article about that,
> http://lwn.net/Articles/374794/
The article overlooks the fact that netlink is a message based interface.
There is no reason that the response message can't be extended to add
additional sections to give more detailed answer. The issues are:
* no infrastructure for this (message format, helpers, etc)
* tedious effort to annotate all the existing error returns
* update to command and library
The extended error reports could even be a kernel config option so the
embedded and those worried about space would not have to have it.
--
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] net: consolidate netif_needs_gso() checks
From: David Miller @ 2010-02-27 16:17 UTC (permalink / raw)
To: herbert; +Cc: jeffrey.t.kirsher, netdev, gospo, john.r.fastabend
In-Reply-To: <20100227155245.GB3176@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 27 Feb 2010 23:52:45 +0800
> I just did a grep on net/sched and couldn't see anything obvious
> that uses transport_header.
I think skb_checksum_help() would be such a use and I
see a reference in net/sched/sch_netem.c
^ permalink raw reply
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Pavel Emelyanov @ 2010-02-27 16:16 UTC (permalink / raw)
To: Eric W. Biederman
Cc: hadi, Daniel Lezcano, Patrick McHardy, Linux Netdev List,
containers, Netfilter Development Mailinglist, Ben Greear,
Serge Hallyn, Matt Helsley
In-Reply-To: <m1bpfbqajn.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Pavel Emelyanov <xemul@parallels.com> writes:
>
>> Thanks. What's the problem with setns?
>
> joining a preexisting namespace is roughly the same problem as
> unsharing a namespace. We simply haven't figure out how to do it
> safely for the pid and the uid namespaces.
The pid may change after this for sure. What problems do you know
about it? What if we try to allocate the same PID in a new space
or return -EBUSY? This will be a good starting point. If we manage
to fix it later this will not break the API at all.
>>> I have designed these file descriptors to pin the namespaces, so
>>> waiting for them to exit isn't something they can do now. It makes a
>>> lot of sense to have similar ones that take weak references to the namespaces
>>> that we can use to wait for a namespace to exit.
>> Yes, I saw this from patches. Eric, I'd very much appreciate if we
>> workout a solution that will allow us to kill two birds with one stone.
>> I do not want to invent yet another bunch of system calls for "taking
>> weak reference".
>
> Definitely. I only consider the current interface to be a mushy not
> set in stone.
OK. The interface is good. I just don't want you to send it for an inclusion
until we decide what to do with waiting.
>> As a "brain storm" start up. Can we use inotify/dnotify for this?
>> Or maybe we should better equip the nsfd call with flags argument and
>> add a flag for weak reference? In that case - how shall we get a
>> notification about namespace is dead? With poll? Maybe worth making
>> the sys_close return only when the namespace is dead (by providing a
>> proper ->release callback of a file)?
>
> We would want poll to work, anything else is a weird work-around.
> The challenging part is that we don't have any infrastructure for
> notifying when a namespace goes away. So that has to be built before
> we can wire it up to userspace. I don't expect it is too difficult
> but there is work to be done.
Poll is OK with me. As far as the notification is concerned - that's also
done in OpenVZ. If you are OK to wait for a week or two I can do it for net
namespaces.
> Eric
>
>
^ permalink raw reply
* Re: [PATCH 10/13] bridge: Add multicast_router sysfs entries
From: Herbert Xu @ 2010-02-27 15:53 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20100227.032915.98669174.davem@davemloft.net>
On Sat, Feb 27, 2010 at 03:29:15AM -0800, David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Fri, 26 Feb 2010 16:42:11 -0800
>
> > I like the functionality, but don't like users whacking on sysfs
> > directly. Could you send patches to integrate a user API into
> > bridge-utils; the utils are at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git
>
> Sounds reasonable to me.
>
> Herbert, please do this after we've resolved the issues in your
> patch set and integrated it.
Will do.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] net: consolidate netif_needs_gso() checks
From: Herbert Xu @ 2010-02-27 15:52 UTC (permalink / raw)
To: David Miller; +Cc: jeffrey.t.kirsher, netdev, gospo, john.r.fastabend
In-Reply-To: <20100227.032725.158512690.davem@davemloft.net>
On Sat, Feb 27, 2010 at 03:27:25AM -0800, David Miller wrote:
>
> If we have ip_summed == CHECKSUM_PARTIAL might some classifier
> or packet scheduler action module require that the
> transport header is setup properly before the SKB gets into
> there?
I think this is OK as the transport header setting was only there
for backwards compatibility with certain drivers that relied on it.
Its use was very much isolated.
I just did a grep on net/sched and couldn't see anything obvious
that uses transport_header.
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index eb7f1a4..626124d 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -1835,12 +1835,40 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
> > {
> > const struct net_device_ops *ops = dev->netdev_ops;
> > int rc = NETDEV_TX_OK;
> > + int need_gso = netif_needs_gso(dev, skb);
> > +
> > + if (!need_gso) {
> > + if (skb_has_frags(skb) &&
> > + !(dev->features & NETIF_F_FRAGLIST) &&
> > + __skb_linearize(skb))
> > + goto out_kfree_skb;
> > +
> > + /* Fragmented skb is linearized if device does not support SG,
> > + * or if at least one of fragments is in highmem and device
> > + * does not support DMA from it.
> > + */
> > + if (skb_shinfo(skb)->nr_frags &&
> > + (!(dev->features & NETIF_F_SG) ||
> > + illegal_highdma(dev, skb)) &&
> > + __skb_linearize(skb))
> > + goto out_kfree_skb;
Please use skb_needs_linearize.
> > + /* If packet is not checksummed and device does not support
> > + * checksumming for this protocol, complete checksumming here.
> > + */
> > + if (skb->ip_summed == CHECKSUM_PARTIAL) {
> > + skb_set_transport_header(skb, skb->csum_start -
> > + skb_headroom(skb));
> > + if (!dev_can_checksum(dev, skb) &&
> > + skb_checksum_help(skb))
> > + goto out_kfree_skb;
> > + }
> > + }
> >
> > if (likely(!skb->next)) {
> > if (!list_empty(&ptype_all))
> > dev_queue_xmit_nit(skb, dev);
> >
> > - if (netif_needs_gso(dev, skb)) {
> > + if (need_gso) {
> > if (unlikely(dev_gso_segment(skb)))
> > goto out_kfree_skb;
> > if (skb->next)
That whole if block should be moved into an else clause here:
if (netif_needs_gso(dev, skb)) {
if (unlikely(dev_gso_segment(skb)))
goto out_kfree_skb;
if (skb->next)
goto gso;
} else {
do your thing
}
The reason is that the other paths only act on the fragments
generated by GSO, so logically with your change we shouldn't
apply any further software emulation to them, even if the device
setting changed.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/13] bridge: Allow tail-call on br_pass_frame_up
From: Herbert Xu @ 2010-02-27 15:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger
In-Reply-To: <20100227.031451.21192400.davem@davemloft.net>
On Sat, Feb 27, 2010 at 03:14:51AM -0800, David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Fri, 26 Feb 2010 23:35:07 +0800
>
> > @@ -20,9 +20,9 @@
> > /* Bridge group multicast address 802.1d (pg 51). */
> > const u8 br_group_address[ETH_ALEN] = { 0x01, 0x80, 0xc2, 0x00, 0x00, 0x00 };
> >
> > -static void br_pass_frame_up(struct net_bridge *br, struct sk_buff *skb)
> > +static int br_pass_frame_up(struct sk_buff *skb)
> > {
> > - struct net_device *indev, *brdev = br->dev;
> > + struct net_device *indev, *brdev = BR_INPUT_SKB_CB(skb)->brdev;
> >
>
> You use this new BR_INPUT_SKB_CB() here in patch #2, but you only
> start setting ->brdev it in patch #4.
Actually this patch does work as is. The brdev setting in #4 is
for the bridge device's local xmit path. br_pass_frame_up is not
used on the local xmit path (since that would create a packet loop).
It's only used for packets originating from bridge ports, where
patch #2 ensures that BR_INPUT_SKB_CB is set correctly.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: iproute2: adding /128 address to sit interface borks
From: Jan Engelhardt @ 2010-02-27 15:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20090710082731.0b06c0eb@nehalam>
On Friday 2009-07-10 17:27, Stephen Hemminger wrote:
>On Fri, 10 Jul 2009 14:05:01 +0200 (CEST)
>Jan Engelhardt <jengelh@medozas.de> wrote:
>
>> it's impossible to do this, and the error message does not say why
>> that is so. No word in dmesg either.
>>
>> # ip a a fc00::49/128 peer fc00::7 dev sit7
>> RTNETLINK answers: Invalid argument
>
>You will need to walk through the path in the kernel.
>In worst case, it means adding kernel printk's.
>
>Then if you want to be nice, make a patch to ipaddr.c in iproute
>utilities so command line can find the error before passing to
>kernel and give a nice error :-)
The issue here was that the peer is encoded using the broadcast
field, and since IPv6 has no broadcast, it was rejected by
the kernel. The error messages really need to be improved.
This year also came an article about that,
http://lwn.net/Articles/374794/
^ 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