* Re: [PATCH 4/7] vbus-proxy: add a pci-to-vbus bridge
From: Gregory Haskins @ 2009-08-07 15:44 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: alacrityvm-devel, Ira W. Snyder, linux-kernel, netdev
In-Reply-To: <200908071657.32858.arnd@arndb.de>
>>> On 8/7/2009 at 10:57 AM, in message <200908071657.32858.arnd@arndb.de>, Arnd
Bergmann <arnd@arndb.de> wrote:
> On Friday 07 August 2009, Gregory Haskins wrote:
>> >>> Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Thursday 06 August 2009, Gregory Haskins wrote:
>> >
>> > > 2b) I also want to collapse multiple interrupts together so as to
>> > > minimize the context switch rate (inject + EIO overhead). My design
>> > > effectively has "NAPI" for interrupt handling. This helps when the system
>
>> > > needs it the most: heavy IO.
>> >
>> > That sounds like a very useful concept in general, but this seems to be a
>> > detail of the interrupt controller implementation. If the IO-APIC cannot
>> > do what you want here, maybe we just need a paravirtual IRQ controller
>> > driver, like e.g. the PS3 has.
>>
>> Yeah, I agree this could be a function of the APIC code. Do note that I
>> mentioned this in passing to Avi a few months ago but FWIW he indicated
>> at that time that he is not interested in making the APIC PV.
>>
>> Also, I almost forgot an important one. Add:
>>
>> 2c) Interrupt prioritization. I want to be able to assign priority
>> to interrupts and handle them in priority order.
>
> I think this part of the interface has developed into the wrong direction
> because you confused two questions:
>
> 1. should you build an advanced interrupt mechanism for virtual drivers?
> 2. how should you build an advanced interrupt mechanism for virtual drivers?
>
> My guess is that when Avi said he did not want a paravirtual IO-APIC,
> he implied that the existing one is good enough (maybe Avi can clarify that
> point himself) answering question 1, while you took that as an indication
> that the code should live elsewhere instead, answering question 2.
>
> What you built with the shm-signal code is essentially a paravirtual nested
> interrupt controller by another name, and deeply integrated into a new
> bigger subsystem. I believe that this has significant disadvantages
> over the approach of making it a standard interrupt controller driver:
>
> * It completely avoids the infrastructure that we have built into Linux
> to deal with interrupts, e.g. /proc/interrupts statistics, IRQ
> balancing and CPU affinity.
>
> * It makes it impossible to quantify the value of the feature to start with,
> which could be used to answer question 1 above.
>
> * Less importantly, it does not work with any other drivers that might
> also benefit from a new interrupt controller -- if it is indeed better
> than the one we already have.
>
> Arnd <><
Hi Arnd,
I don't strongly disagree with anything you said (except for perhaps that I confused the question). I agree that the PCI-bridge effectively implements something akin to an interrupt controller. I agree that this interrupt controller, if indeed superior (I believe it is), can only benefit devices inherently behind the bridge instead of all of KVM (this in of itself doesnt bother me, as I plan on all my performance work to be based on that bus, but I digress. Also note that this is not dissimilar to other bridge+bus (think usb, scsi) operation). I agree that a potentially more ideal solution would be if we had a proper generic PV interrupt controller that exhibited similar traits as to what I describe (priority, inject+EIO overhead reduction, etc) so that all of KVM benefited.
The issue wasn't that I didn't know these things. The issue is that I have no control over whether such an intrusive change to KVM (and the guest arch code) is accepted (and at least one relevant maintainer expressed dissatisfaction (*) at the idea when proposed) Conversely, I am the maintainer of AlacrityVM, so I do have control over the bridge design. ;) Also note that this particular design decision is completely encapsulated within alacrityvm's components. IOW, I am not foisting my ideas on the entire kernel tree: If someone doesn't like what I have done, they can choose not to use alacrity and its like my ideas never existed. The important thing with this distinction is I am not changing how core linux or core kvm works in the process, only the one little piece of the world that
particularly interests me.
That said, if attitudes about some of these ideas have changed, I may be able to break that piece out and start submitting it to kvm@ as some kind of pv interrupt controller. I would only be interested in doing so if Avi et. al. express an openness to the idea...I.e.. I don't want to waste my time any more than any one elses.
Kind Regards,
-Greg
(*) I think Avi said something to the effect of "you are falling into the 'lets PV the world' trap"
^ permalink raw reply
* Re: [PATCH 2/7 v3] initdev:kernel:USB init device discovery notification
From: Alan Jenkins @ 2009-08-07 15:32 UTC (permalink / raw)
To: David VomLehn
Cc: linux-kernel, akpm, linux-usb, greg, linux-scsi, netdev, arjan
In-Reply-To: <20090804221506.GA9256@cuplxvomd02.corp.sa.net>
On 8/4/09, David VomLehn <dvomlehn@cisco.com> wrote:
> From: Alan Stern <stern@rowland.harvard.edu>
>
> Use init device discovery infrastructure to provide notification of
> availability of USB devices.
>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> Signed-off-by: David VomLehn <dvomlehn@cisco.com>
> ---
> drivers/usb/core/hub.c | 26 ++++++++++++++++++++++++++
> 1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index be86ae3..08baee0 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -37,6 +37,20 @@
> #endif
> #endif
>
> +/* The mask of possible USB boot devices depends on what drivers and
> + * options have been configured into the kernel. There are too many
> + * USB network config options to list here, so just assume it is always
> + * possible to have a USB network device.
> + */
That could be fixed though. Make the "USB Network Adaptors" menu into
an option. Then you just have e.g. "CONFIG_NETDEV_USB", plus the two
class devices outside the menu (CONFIG_USB_ACM and CONFIG_USB_WDM).
Alan
^ permalink raw reply
* [PATCH] korina: Read buffer overflow
From: Roel Kluin @ 2009-08-07 15:33 UTC (permalink / raw)
To: netdev, Andrew Morton, David S. Miller, n0-1, florian
If the loop breaks with an i of 0, then we read lp->rd_ring[-1].
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Should we clean up like this? please review
diff --git a/drivers/net/korina.c b/drivers/net/korina.c
index b4cf602..b965b2b 100644
--- a/drivers/net/korina.c
+++ b/drivers/net/korina.c
@@ -754,7 +754,7 @@ static void korina_alloc_ring(struct net_device *dev)
{
struct korina_private *lp = netdev_priv(dev);
struct sk_buff *skb;
- int i;
+ int i, j;
/* Initialize the transmit descriptors */
for (i = 0; i < KORINA_NUM_TDS; i++) {
@@ -771,7 +771,7 @@ static void korina_alloc_ring(struct net_device *dev)
for (i = 0; i < KORINA_NUM_RDS; i++) {
skb = dev_alloc_skb(KORINA_RBSIZE + 2);
if (!skb)
- break;
+ goto err_free;
skb_reserve(skb, 2);
lp->rx_skb[i] = skb;
lp->rd_ring[i].control = DMA_DESC_IOD |
@@ -790,6 +790,12 @@ static void korina_alloc_ring(struct net_device *dev)
lp->rx_chain_head = 0;
lp->rx_chain_tail = 0;
lp->rx_chain_status = desc_empty;
+err_free:
+ for (j = 0; j < i; j++) {
+ lp->rd_ring[j].control = 0;
+ dev_kfree_skb_any(lp->rx_skb[j]);
+ lp->rx_skb[j] = NULL;
+ }
}
static void korina_free_ring(struct net_device *dev)
^ permalink raw reply related
* [PATCH] sctp: fix missing destroy of percpu counter variable in sctp_proc_exit()
From: Vlad Yasevich @ 2009-08-07 15:17 UTC (permalink / raw)
To: netdev; +Cc: davem, Rafael Laufer, Vlad Yasevich
From: Rafael Laufer <rlaufer@cisco.com>
Commit 1748376b6626acf59c24e9592ac67b3fe2a0e026,
net: Use a percpu_counter for sockets_allocated
added percpu_counter function calls to sctp_proc_init code path, but
forgot to add them to sctp_proc_exit(). This resulted in a following
Ooops when performing this test
# modprobe sctp
# rmmod -f sctp
# modprobe sctp
[ 573.862512] BUG: unable to handle kernel paging request at f8214a24
[ 573.862518] IP: [<c0308b8f>] __percpu_counter_init+0x3f/0x70
[ 573.862530] *pde = 37010067 *pte = 00000000
[ 573.862534] Oops: 0002 [#1] SMP
[ 573.862537] last sysfs file: /sys/module/libcrc32c/initstate
[ 573.862540] Modules linked in: sctp(+) crc32c libcrc32c binfmt_misc bridge
stp bnep lp snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep
snd_pcm_oss snd_mixer_oss arc4 joydev snd_pcm ecb pcmcia snd_seq_dummy
snd_seq_oss iwlagn iwlcore snd_seq_midi snd_rawmidi snd_seq_midi_event
yenta_socket rsrc_nonstatic thinkpad_acpi snd_seq snd_timer snd_seq_device
mac80211 psmouse sdhci_pci sdhci nvidia(P) ppdev video snd soundcore serio_raw
pcspkr iTCO_wdt iTCO_vendor_support led_class ricoh_mmc pcmcia_core intel_agp
nvram agpgart usbhid parport_pc parport output snd_page_alloc cfg80211 btusb
ohci1394 ieee1394 e1000e [last unloaded: sctp]
[ 573.862589]
[ 573.862593] Pid: 5373, comm: modprobe Tainted: P R (2.6.31-rc3 #6)
7663B15
[ 573.862596] EIP: 0060:[<c0308b8f>] EFLAGS: 00010286 CPU: 1
[ 573.862599] EIP is at __percpu_counter_init+0x3f/0x70
[ 573.862602] EAX: f8214a20 EBX: f80faa14 ECX: c48c0000 EDX: f80faa20
[ 573.862604] ESI: f80a7000 EDI: 00000000 EBP: f69d5ef0 ESP: f69d5eec
[ 573.862606] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 573.862610] Process modprobe (pid: 5373, ti=f69d4000 task=c2130c70
task.ti=f69d4000)
[ 573.862612] Stack:
[ 573.862613] 00000000 f69d5f18 f80a70a8 f80fa9fc 00000000 fffffffc f69d5f30
c018e2d4
[ 573.862619] <0> 00000000 f80a7000 00000000 f69d5f88 c010112b 00000000
c07029c0 fffffffb
[ 573.862626] <0> 00000000 f69d5f38 c018f83f f69d5f54 c0557cad f80fa860
00000001 c07010c0
[ 573.862634] Call Trace:
[ 573.862644] [<f80a70a8>] ? sctp_init+0xa8/0x7d4 [sctp]
[ 573.862650] [<c018e2d4>] ? marker_update_probe_range+0x184/0x260
[ 573.862659] [<f80a7000>] ? sctp_init+0x0/0x7d4 [sctp]
[ 573.862662] [<c010112b>] ? do_one_initcall+0x2b/0x160
[ 573.862666] [<c018f83f>] ? tracepoint_module_notify+0x2f/0x40
[ 573.862671] [<c0557cad>] ? notifier_call_chain+0x2d/0x70
[ 573.862678] [<c01588fd>] ? __blocking_notifier_call_chain+0x4d/0x60
[ 573.862682] [<c016b2f1>] ? sys_init_module+0xb1/0x1f0
[ 573.862686] [<c0102ffc>] ? sysenter_do_call+0x12/0x28
[ 573.862688] Code: 89 48 08 b8 04 00 00 00 e8 df aa ec ff ba f4 ff ff ff 85
c0 89 43 14 74 31 b8 b0 18 71 c0 e8 19 b9 24 00 a1 c4 18 71 c0 8d 53 0c <89> 50
04 89 43 0c b8 b0 18 71 c0 c7 43 10 c4 18 71 c0 89 15 c4
[ 573.862725] EIP: [<c0308b8f>] __percpu_counter_init+0x3f/0x70 SS:ESP
0068:f69d5eec
[ 573.862730] CR2: 00000000f8214a24
[ 573.862734] ---[ end trace 39c4e0b55e7cf54d ]---
Signed-off-by: Rafael Laufer <rlaufer@cisco.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
---
net/sctp/protocol.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 79cbd47..a76da65 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -160,6 +160,7 @@ static void sctp_proc_exit(void)
remove_proc_entry("sctp", init_net.proc_net);
}
#endif
+ percpu_counter_destroy(&sctp_sockets_allocated);
}
/* Private helper to extract ipv4 address and stash them in
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH 0/7] AlacrityVM guest drivers
From: Gregory Haskins @ 2009-08-07 15:05 UTC (permalink / raw)
To: Anthony Liguori
Cc: Michael S. Tsirkin, Gregory Haskins, linux-kernel,
alacrityvm-devel, netdev, kvm
In-Reply-To: <4A7C37E5.4040302@codemonkey.ws>
[-- Attachment #1: Type: text/plain, Size: 3158 bytes --]
Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>>
>>> This series includes the basic plumbing, as well as the driver for
>>> accelerated 802.x (ethernet) networking.
>>>
>>
>> The graphs comparing virtio with vbus look interesting.
>>
>
> 1gbit throughput on a 10gbit link? I have a hard time believing that.
>
> I've seen much higher myself. Can you describe your test setup in more
> detail?
Sure,
For those graphs, two 8-core x86_64 boxes with Chelsio T3 10GE connected
back to back via cross over with 1500mtu. The kernel version was as
posted. The qemu version was generally something very close to
qemu-kvm.git HEAD at the time the data was gathered, but unfortunately I
didn't seem to log this info.
For KVM, we take one of those boxes and run a bridge+tap configuration
on top of that. We always run the server on the bare-metal machine on
the remote side of the link regardless of whether we run the client in a
VM or baremetal.
For guests, virtio-net and venet connect to the same linux bridge
instance, I just "ifdown eth0 / ifup eth1" (or vice versa) and repeat
the same test. I do this multiple times (usually about 10) and average
the result. I use several different programs, such as netperf, rsync,
and ping to take measurements.
That said, note that the graphs were from earlier kernel runs (2.6.28,
29-rc8). The most recent data I can find that I published is for
2.6.29, announced with the vbus-v3 release back in April:
http://lkml.org/lkml/2009/4/21/408
In it, the virtio-net throughput numbers are substantially higher and
possibly more in line with your expectations (4.5gb/s) (though notably
still lagging venet, which weighed in at 5.6gb/s).
Generally, I find that the virtio-net exhibits non-deterministic results
from release to release. I suspect (as we have discussed) the
tx-mitigation scheme. Some releases buffer the daylights out of the
stream, and virtio gets close(r) throughput (e.g. 4.5g vs 5.8g, but
absolutely terrible latency (4000us vs 65us). Other releases it seems
to operate with more of a compromise (1.3gb/s vs 3.8gb/s, but 350us vs
85us).
I do not understand what causes the virtio performance fluctuation, as I
use the same kernel config across builds, and I do not typically change
the qemu userspace. Note that some general fluctuation is evident
across the board just from kernel to kernel. I am referring to more of
the disparity in throughput vs latency than the ultimate numbers, as all
targets seem to scale max throughput about the same per kernel.
That said, I know I need to redo the graphs against HEAD (31-rc5, and
perhaps 30, and kvm.git). I've been heads down with the eventfd
interfaces since vbus-v3 so I havent been as active with generating the
results. I did confirm that vbus-v4 (alacrityvm-v0.1) still produces a
similar graph, but I didn't gather the data as scientifically as I would
feel comfortable publishing a graph for. This is on the TODO list.
If there is another patch-series/tree I should be using for comparison,
please point me at it.
HTH
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] vbus-proxy: add a pci-to-vbus bridge
From: Arnd Bergmann @ 2009-08-07 14:57 UTC (permalink / raw)
To: Gregory Haskins; +Cc: alacrityvm-devel, Ira W. Snyder, linux-kernel, netdev
In-Reply-To: <4A7B78580200005A00051D50@sinclair.provo.novell.com>
On Friday 07 August 2009, Gregory Haskins wrote:
> >>> Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 06 August 2009, Gregory Haskins wrote:
> >
> > > 2b) I also want to collapse multiple interrupts together so as to
> > > minimize the context switch rate (inject + EIO overhead). My design
> > > effectively has "NAPI" for interrupt handling. This helps when the system
> > > needs it the most: heavy IO.
> >
> > That sounds like a very useful concept in general, but this seems to be a
> > detail of the interrupt controller implementation. If the IO-APIC cannot
> > do what you want here, maybe we just need a paravirtual IRQ controller
> > driver, like e.g. the PS3 has.
>
> Yeah, I agree this could be a function of the APIC code. Do note that I
> mentioned this in passing to Avi a few months ago but FWIW he indicated
> at that time that he is not interested in making the APIC PV.
>
> Also, I almost forgot an important one. Add:
>
> 2c) Interrupt prioritization. I want to be able to assign priority
> to interrupts and handle them in priority order.
I think this part of the interface has developed into the wrong direction
because you confused two questions:
1. should you build an advanced interrupt mechanism for virtual drivers?
2. how should you build an advanced interrupt mechanism for virtual drivers?
My guess is that when Avi said he did not want a paravirtual IO-APIC,
he implied that the existing one is good enough (maybe Avi can clarify that
point himself) answering question 1, while you took that as an indication
that the code should live elsewhere instead, answering question 2.
What you built with the shm-signal code is essentially a paravirtual nested
interrupt controller by another name, and deeply integrated into a new
bigger subsystem. I believe that this has significant disadvantages
over the approach of making it a standard interrupt controller driver:
* It completely avoids the infrastructure that we have built into Linux
to deal with interrupts, e.g. /proc/interrupts statistics, IRQ
balancing and CPU affinity.
* It makes it impossible to quantify the value of the feature to start with,
which could be used to answer question 1 above.
* Less importantly, it does not work with any other drivers that might
also benefit from a new interrupt controller -- if it is indeed better
than the one we already have.
Arnd <><
^ permalink raw reply
* Re: [PATCH] lmc: Read outside array bounds
From: Roel Kluin @ 2009-08-07 14:54 UTC (permalink / raw)
To: David S. Miller, khc, netdev, Andrew Morton
In-Reply-To: <20090728144307.c189810b.akpm@linux-foundation.org>
If dev_alloc_skb() fails on the first iteration of the allocation loop, and we
break out of the loop, then we end up writing before the start of the array.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
> First of all, if we allocated at least one buffer we should
> mark the last one in the code right after this loop.
>
> Second of all, we should purge the TX skbs in the next
> loop even if we could not allocate even one RX buffer.
>
> The thing to do is probably to guard the set of "[i-1]" RX ring
> accesses with a "if (i != 0)" check.
Forgot a bit about this one, but I hope this is what you meant?
diff --git a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c
index 45b1822..b26fabb 100644
--- a/drivers/net/wan/lmc/lmc_main.c
+++ b/drivers/net/wan/lmc/lmc_main.c
@@ -1838,7 +1838,7 @@ void lmc_mii_writereg (lmc_softc_t * const sc, unsigned devaddr, unsigned regno,
static void lmc_softreset (lmc_softc_t * const sc) /*fold00*/
{
- int i;
+ int i, j;
lmc_trace(sc->lmc_device, "lmc_softreset in");
@@ -1897,24 +1897,27 @@ static void lmc_softreset (lmc_softc_t * const sc) /*fold00*/
/*
* Sets end of ring
*/
- sc->lmc_rxring[i - 1].length |= 0x02000000; /* Set end of buffers flag */
- sc->lmc_rxring[i - 1].buffer2 = virt_to_bus (&sc->lmc_rxring[0]); /* Point back to the start */
- LMC_CSR_WRITE (sc, csr_rxlist, virt_to_bus (sc->lmc_rxring)); /* write base address */
+ if (i > 0) {
+ sc->lmc_rxring[i - 1].length |= 0x02000000; /* Set end of buffers flag */
+ sc->lmc_rxring[i - 1].buffer2 = virt_to_bus(&sc->lmc_rxring[0]); /* Point back to the start */
+ LMC_CSR_WRITE(sc, csr_rxlist, virt_to_bus(sc->lmc_rxring)); /* write base address */
+ }
/* Initialize the transmit rings and buffers */
- for (i = 0; i < LMC_TXDESCS; i++)
- {
- if (sc->lmc_txq[i] != NULL){ /* have buffer */
- dev_kfree_skb(sc->lmc_txq[i]); /* free it */
+ for (j = 0; j < i; j++) {
+ if (sc->lmc_txq[j] != NULL) { /* have buffer */
+ dev_kfree_skb(sc->lmc_txq[j]); /* free it */
sc->lmc_device->stats.tx_dropped++; /* We just dropped a packet */
}
- sc->lmc_txq[i] = NULL;
- sc->lmc_txring[i].status = 0x00000000;
- sc->lmc_txring[i].buffer2 = virt_to_bus (&sc->lmc_txring[i + 1]);
+ sc->lmc_txq[j] = NULL;
+ sc->lmc_txring[j].status = 0x00000000;
+ sc->lmc_txring[j].buffer2 = virt_to_bus(&sc->lmc_txring[j + 1]);
+ }
+ if (j > 0) {
+ sc->lmc_txring[j - 1].buffer2 = virt_to_bus(&sc->lmc_txring[0]);
+ LMC_CSR_WRITE(sc, csr_txlist, virt_to_bus(sc->lmc_txring));
}
- sc->lmc_txring[i - 1].buffer2 = virt_to_bus (&sc->lmc_txring[0]);
- LMC_CSR_WRITE (sc, csr_txlist, virt_to_bus (sc->lmc_txring));
lmc_trace(sc->lmc_device, "lmc_softreset out");
}
^ permalink raw reply related
* Re: some bug in iproute2
From: jamal @ 2009-08-07 14:28 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Sergey Popov, netdev
In-Reply-To: <20090807101250.GA14064@ff.dom.local>
On Fri, 2009-08-07 at 10:12 +0000, Jarek Poplawski wrote:
> On 06-08-2009 10:50, Sergey Popov wrote:
> If you're using iptables > 1.4.2 then it's a known problem.
> You can read more in a netdev thread:
> Subject: iproute2 action/policer question
> starting date: Tue, 09 Jun 2009 22:10:46 +0200
I am giving up on fixing it for that release for general distros.
I will wait until iptables 1.4.4 becomes mainstream then i will make
another fix. It is very hard to keep up concurently with a) apis
changing randomly on the part of iptables b) distros picking random
versions of iptables and c) iproute2 being released in random
uncoordinated manner.
Maybe a solution that would work is to fork iproute2 or make ipt
part of iptables. In the meantime i can work with anyone who wants
to get it to work with fixed version of iproute2 + iptables. Sergey,
if this is of interest to you let me know.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 0/7] AlacrityVM guest drivers Reply-To:
From: Anthony Liguori @ 2009-08-07 14:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Gregory Haskins, linux-kernel, alacrityvm-devel, netdev, kvm
In-Reply-To: <20090806081955.GA9752@redhat.com>
Michael S. Tsirkin wrote:
>
>> This series includes the basic plumbing, as well as the driver for
>> accelerated 802.x (ethernet) networking.
>>
>
> The graphs comparing virtio with vbus look interesting.
>
1gbit throughput on a 10gbit link? I have a hard time believing that.
I've seen much higher myself. Can you describe your test setup in more
detail?
Regards,
Anthony Liguori
^ permalink raw reply
* [PATCH] pcnet32: Read buffer overflow
From: Roel Kluin @ 2009-08-07 13:24 UTC (permalink / raw)
To: Don Fry, netdev, Andrew Morton, David S. Miller
An `options[cards_found]' that equals `sizeof(options_mapping)' is already beyond
the array.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/net/pcnet32.c b/drivers/net/pcnet32.c
index 2836815..7f834a3 100644
--- a/drivers/net/pcnet32.c
+++ b/drivers/net/pcnet32.c
@@ -1835,7 +1835,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct pci_dev *pdev)
lp->chip_version = chip_version;
lp->msg_enable = pcnet32_debug;
if ((cards_found >= MAX_UNITS)
- || (options[cards_found] > sizeof(options_mapping)))
+ || (options[cards_found] >= sizeof(options_mapping)))
lp->options = PCNET32_PORT_ASEL;
else
lp->options = options_mapping[options[cards_found]];
^ permalink raw reply related
* Re: [PATCH] be2net: Implementation of request_firmware interface.
From: Ben Hutchings @ 2009-08-07 13:20 UTC (permalink / raw)
To: linuxram; +Cc: Sarveshwar Bandi, netdev, davem
In-Reply-To: <1249636833.6477.812.camel@localhost>
On Fri, 2009-08-07 at 02:20 -0700, Ram Pai wrote:
> On Sun, 2009-07-05 at 15:20 +0100, Ben Hutchings wrote:
> > On Sun, 2009-07-05 at 17:46 +0530, Sarveshwar Bandi wrote:
> > > I understand that most drivers use request_firmware() to load volatile
> > > firmware. I do see that there are other nic drivers that use this inferface to
> > > flash persistent firmware.
> > >
> > > We have other tools for offline flashing; but there is requirement
> > > to flash f/w through driver without having to use other proprietary tools.
> >
> > The firmware blob is proprietary and has to be distributed separately
> > from the kernel. So does it really matter that you have to distribute a
> > special tool as well?
> >
> > (Based on requirements specified by major OEMs, I have implemented
> > firmware update through the sfc driver (MDIO and MTD interfaces) but
> > under the control of a separate tool.)
> >
> > > Since the firmware load happens only when there is a version mismatch with
> > > f/w in /lib/firmware, Users who want to avoid automatic flashing at boot time
> > > can choose not to copy the f/w file under /lib/firmware.
> > [...]
> >
> > Is there a way of loading the firmware into the controller's RAM but not
> > writing it to flash? That ought to be the default behaviour.
> >
>
> Given that the volatile and non-volatile firmware reside in the same
> file, it is not possible for the driver to selectively load the intended
> firmware.
Your design error is your problem.
> However, is this behavior a gating factor for this patch from being
> accepted?
I'm not a gatekeeper; ask David Miller.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 04/10] documentation: fix wrt. headers rename
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-4-git-send-email-dbaryshkov@gmail.com>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
Documentation/networking/ieee802154.txt | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 1d4ed66..1c0c82c 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -22,7 +22,7 @@ int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
.....
The address family, socket addresses etc. are defined in the
-include/net/ieee802154/af_ieee802154.h header or in the special header
+include/net/af_ieee802154.h header or in the special header
in our userspace package (see either linux-zigbee sourceforge download page
or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee).
@@ -33,7 +33,7 @@ MLME - MAC Level Management
============================
Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands.
-See the include/net/ieee802154/nl802154.h header. Our userspace tools package
+See the include/net/nl802154.h header. Our userspace tools package
(see above) provides CLI configuration utility for radio interfaces and simple
coordinator for IEEE 802.15.4 networks as an example users of MLME protocol.
@@ -54,7 +54,7 @@ Those types of devices require different approach to be hooked into Linux kernel
HardMAC
=======
-See the header include/net/ieee802154/netdevice.h. You have to implement Linux
+See the header include/net/ieee802154_netdev.h. You have to implement Linux
net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family
code via plain sk_buffs. The control block of sk_buffs will contain additional
info as described in the struct ieee802154_mac_cb.
@@ -72,5 +72,4 @@ SoftMAC
We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
in software. This is currently WIP.
-See header include/net/ieee802154/mac802154.h and several drivers in
-drivers/ieee802154/
+See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
--
1.6.3.3
^ permalink raw reply related
* [PATCH 03/10] nl802154: make ieee802154_policy constant
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-3-git-send-email-dbaryshkov@gmail.com>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
include/linux/nl802154.h | 2 +-
net/ieee802154/nl_policy.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/nl802154.h b/include/linux/nl802154.h
index 2cda00c..266dd96 100644
--- a/include/linux/nl802154.h
+++ b/include/linux/nl802154.h
@@ -69,7 +69,7 @@ enum {
#define IEEE802154_ATTR_MAX (__IEEE802154_ATTR_MAX - 1)
-extern struct nla_policy ieee802154_policy[];
+extern const struct nla_policy ieee802154_policy[];
/* commands */
/* REQ should be responded with CONF
diff --git a/net/ieee802154/nl_policy.c b/net/ieee802154/nl_policy.c
index c7d71d1..83cb4cc 100644
--- a/net/ieee802154/nl_policy.c
+++ b/net/ieee802154/nl_policy.c
@@ -24,7 +24,7 @@
#define NLA_HW_ADDR NLA_U64
-struct nla_policy ieee802154_policy[IEEE802154_ATTR_MAX + 1] = {
+const struct nla_policy ieee802154_policy[IEEE802154_ATTR_MAX + 1] = {
[IEEE802154_ATTR_DEV_NAME] = { .type = NLA_STRING, },
[IEEE802154_ATTR_DEV_INDEX] = { .type = NLA_U32, },
@@ -50,3 +50,4 @@ struct nla_policy ieee802154_policy[IEEE802154_ATTR_MAX + 1] = {
[IEEE802154_ATTR_DURATION] = { .type = NLA_U8, },
[IEEE802154_ATTR_ED_LIST] = { .len = 27 },
};
+
--
1.6.3.3
^ permalink raw reply related
* [PATCH 02/10] af_ieee802154: fix ioctl processing
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-2-git-send-email-dbaryshkov@gmail.com>
fix two errors in ioctl processing:
1) if the ioctl isn't supported one should return -ENOIOCTLCMD
2) don't call ndo_do_ioctl if the device doesn't provide it
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
net/ieee802154/af_ieee802154.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ieee802154/af_ieee802154.c b/net/ieee802154/af_ieee802154.c
index 69c8d92..d504c34 100644
--- a/net/ieee802154/af_ieee802154.c
+++ b/net/ieee802154/af_ieee802154.c
@@ -136,7 +136,7 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct ifreq __user *arg,
unsigned int cmd)
{
struct ifreq ifr;
- int ret = -EINVAL;
+ int ret = -ENOIOCTLCMD;
struct net_device *dev;
if (copy_from_user(&ifr, arg, sizeof(struct ifreq)))
@@ -146,8 +146,10 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct ifreq __user *arg,
dev_load(sock_net(sk), ifr.ifr_name);
dev = dev_get_by_name(sock_net(sk), ifr.ifr_name);
- if (dev->type == ARPHRD_IEEE802154 ||
- dev->type == ARPHRD_IEEE802154_PHY)
+
+ if ((dev->type == ARPHRD_IEEE802154 ||
+ dev->type == ARPHRD_IEEE802154_PHY) &&
+ dev->netdev_ops->ndo_do_ioctl)
ret = dev->netdev_ops->ndo_do_ioctl(dev, &ifr, cmd);
if (!ret && copy_to_user(arg, &ifr, sizeof(struct ifreq)))
--
1.6.3.3
^ permalink raw reply related
* [NEXT][GIT PULL 0/10] Updates for the IEEE 802.15.4 stack
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
Please pull in the following updates:
* confirmation for START command
* configurable ACK requests
* other small fixes
^ permalink raw reply
* [PATCH 01/10] af_ieee802154: drop IEEE802154_SIOC_ADD_SLAVE declaration
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Sergey Lapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-1-git-send-email-dbaryshkov@gmail.com>
IEEE802154_SIOC_ADD_SLAVE was used to allocate 802.15.4 interfaces
on the top of radio. It's not used anymore, drop it.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
include/net/af_ieee802154.h | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/include/net/af_ieee802154.h b/include/net/af_ieee802154.h
index 0d78605..e9c70ea 100644
--- a/include/net/af_ieee802154.h
+++ b/include/net/af_ieee802154.h
@@ -54,7 +54,4 @@ struct sockaddr_ieee802154 {
struct ieee802154_addr addr;
};
-/* master device */
-#define IEEE802154_SIOC_ADD_SLAVE (SIOCDEVPRIVATE + 0)
-
#endif
--
1.6.3.3
^ permalink raw reply related
* [PATCH 10/10] fakehard: use START-CONFIRM primitive to report START failure
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-10-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/ieee802154/fakehard.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/ieee802154/fakehard.c b/drivers/ieee802154/fakehard.c
index 8a52e6e..2bc6c0c 100644
--- a/drivers/ieee802154/fakehard.c
+++ b/drivers/ieee802154/fakehard.c
@@ -177,18 +177,14 @@ static int fake_disassoc_req(struct net_device *dev,
*
* Note: This is in section 7.5.2.3 of the IEEE 802.15.4-2006
* document, with 7.3.8 describing coordinator realignment.
- *
- * Note: There is currently no way to notify the coordinator userland
- * program of whether or not the PAN has started successfully. As
- * such, the coordinator program cannot know when the MAC has
- * completed starting the network and will simply have to assume
- * completeness based on some form of time delay.
*/
static int fake_start_req(struct net_device *dev, struct ieee802154_addr *addr,
u8 channel,
u8 bcn_ord, u8 sf_ord, u8 pan_coord, u8 blx,
u8 coord_realign)
{
+ /* We don't emulate beacons here at all, so START should fail */
+ ieee802154_nl_start_confirm(dev, IEEE802154_INVALID_PARAMETER);
return 0;
}
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 09/10] nl802154: support START-CONFIRM primitive
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-9-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/net/nl802154.h | 9 +++++++++
net/ieee802154/netlink.c | 32 ++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/include/net/nl802154.h b/include/net/nl802154.h
index 6096096..e554ecd 100644
--- a/include/net/nl802154.h
+++ b/include/net/nl802154.h
@@ -114,4 +114,13 @@ int ieee802154_nl_scan_confirm(struct net_device *dev,
int ieee802154_nl_beacon_indic(struct net_device *dev, u16 panid,
u16 coord_addr);
+/**
+ * ieee802154_nl_start_confirm - Notify userland of completion of start.
+ * @dev: The device which was instructed to scan.
+ * @status: The status of the scan operation.
+ *
+ * Note: This is in section 7.1.14 of the IEEE 802.15.4 document.
+ */
+int ieee802154_nl_start_confirm(struct net_device *dev, u8 status);
+
#endif
diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
index 6fc6d6f..70a067e 100644
--- a/net/ieee802154/netlink.c
+++ b/net/ieee802154/netlink.c
@@ -31,6 +31,7 @@
#include <linux/nl802154.h>
#include <net/af_ieee802154.h>
#include <net/nl802154.h>
+#include <net/ieee802154.h>
#include <net/ieee802154_netdev.h>
static unsigned int ieee802154_seq_num;
@@ -262,6 +263,31 @@ nla_put_failure:
}
EXPORT_SYMBOL(ieee802154_nl_scan_confirm);
+int ieee802154_nl_start_confirm(struct net_device *dev, u8 status)
+{
+ struct sk_buff *msg;
+
+ pr_debug("%s\n", __func__);
+
+ msg = ieee802154_nl_create(0, IEEE802154_START_CONF);
+ if (!msg)
+ return -ENOBUFS;
+
+ NLA_PUT_STRING(msg, IEEE802154_ATTR_DEV_NAME, dev->name);
+ NLA_PUT_U32(msg, IEEE802154_ATTR_DEV_INDEX, dev->ifindex);
+ NLA_PUT(msg, IEEE802154_ATTR_HW_ADDR, IEEE802154_ADDR_LEN,
+ dev->dev_addr);
+
+ NLA_PUT_U8(msg, IEEE802154_ATTR_STATUS, status);
+
+ return ieee802154_nl_finish(msg);
+
+nla_put_failure:
+ nlmsg_free(msg);
+ return -ENOBUFS;
+}
+EXPORT_SYMBOL(ieee802154_nl_start_confirm);
+
static int ieee802154_nl_fill_iface(struct sk_buff *msg, u32 pid,
u32 seq, int flags, struct net_device *dev)
{
@@ -462,6 +488,12 @@ static int ieee802154_start_req(struct sk_buff *skb, struct genl_info *info)
blx = nla_get_u8(info->attrs[IEEE802154_ATTR_BAT_EXT]);
coord_realign = nla_get_u8(info->attrs[IEEE802154_ATTR_COORD_REALIGN]);
+ if (addr.short_addr == IEEE802154_ADDR_BROADCAST) {
+ ieee802154_nl_start_confirm(dev, IEEE802154_NO_SHORT_ADDRESS);
+ dev_put(dev);
+ return -EINVAL;
+ }
+
ret = ieee802154_mlme_ops(dev)->start_req(dev, &addr, channel,
bcn_ord, sf_ord, pan_coord, blx, coord_realign);
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 08/10] af_ieee802154: add support for WANT_ACK socket option
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-8-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/net/af_ieee802154.h | 5 +++
net/ieee802154/dgram.c | 58 ++++++++++++++++++++++++++++++++++++++++---
2 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/include/net/af_ieee802154.h b/include/net/af_ieee802154.h
index e9c70ea..75e64c7 100644
--- a/include/net/af_ieee802154.h
+++ b/include/net/af_ieee802154.h
@@ -54,4 +54,9 @@ struct sockaddr_ieee802154 {
struct ieee802154_addr addr;
};
+/* get/setsockopt */
+#define SOL_IEEE802154 0
+
+#define WPAN_WANTACK 0
+
#endif
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index 25018a9..77ae685 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -44,6 +44,7 @@ struct dgram_sock {
struct ieee802154_addr dst_addr;
unsigned bound:1;
+ unsigned want_ack:1;
};
static inline struct dgram_sock *dgram_sk(const struct sock *sk)
@@ -51,7 +52,6 @@ static inline struct dgram_sock *dgram_sk(const struct sock *sk)
return container_of(sk, struct dgram_sock, sk);
}
-
static void dgram_hash(struct sock *sk)
{
write_lock_bh(&dgram_lock);
@@ -74,6 +74,7 @@ static int dgram_init(struct sock *sk)
ro->dst_addr.addr_type = IEEE802154_ADDR_LONG;
ro->dst_addr.pan_id = 0xffff;
+ ro->want_ack = 1;
memset(&ro->dst_addr.hwaddr, 0xff, sizeof(ro->dst_addr.hwaddr));
return 0;
}
@@ -237,7 +238,10 @@ static int dgram_sendmsg(struct kiocb *iocb, struct sock *sk,
skb_reset_network_header(skb);
- mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA | MAC_CB_FLAG_ACKREQ;
+ mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
+ if (ro->want_ack)
+ mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
+
mac_cb(skb)->seq = ieee802154_mlme_ops(dev)->get_dsn(dev);
err = dev_hard_header(skb, dev, ETH_P_IEEE802154, &ro->dst_addr,
ro->bound ? &ro->src_addr : NULL, size);
@@ -382,13 +386,59 @@ int ieee802154_dgram_deliver(struct net_device *dev, struct sk_buff *skb)
static int dgram_getsockopt(struct sock *sk, int level, int optname,
char __user *optval, int __user *optlen)
{
- return -EOPNOTSUPP;
+ struct dgram_sock *ro = dgram_sk(sk);
+
+ int val, len;
+
+ if (level != SOL_IEEE802154)
+ return -EOPNOTSUPP;
+
+ if (get_user(len, optlen))
+ return -EFAULT;
+
+ len = min_t(unsigned int, len, sizeof(int));
+
+ switch (optname) {
+ case WPAN_WANTACK:
+ val = ro->want_ack;
+ break;
+ default:
+ return -ENOPROTOOPT;
+ }
+
+ if (put_user(len, optlen))
+ return -EFAULT;
+ if (copy_to_user(optval, &val, len))
+ return -EFAULT;
+ return 0;
}
static int dgram_setsockopt(struct sock *sk, int level, int optname,
char __user *optval, int __user optlen)
{
- return -EOPNOTSUPP;
+ struct dgram_sock *ro = dgram_sk(sk);
+ int val;
+ int err = 0;
+
+ if (optlen < sizeof(int))
+ return -EINVAL;
+
+ if (get_user(val, (int __user *)optval))
+ return -EFAULT;
+
+ lock_sock(sk);
+
+ switch (optname) {
+ case WPAN_WANTACK:
+ ro->want_ack = !!val;
+ break;
+ default:
+ err = -ENOPROTOOPT;
+ break;
+ }
+
+ release_sock(sk);
+ return err;
}
struct proto ieee802154_dgram_prot = {
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 07/10] af_ieee802154: minor cleanup in dgram_bind
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-7-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
1) fix ro->bound protection by socket lock
2) make ro->bound bit instead of int
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/dgram.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index d1da6c6..25018a9 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -40,9 +40,10 @@ static DEFINE_RWLOCK(dgram_lock);
struct dgram_sock {
struct sock sk;
- int bound;
struct ieee802154_addr src_addr;
struct ieee802154_addr dst_addr;
+
+ unsigned bound:1;
};
static inline struct dgram_sock *dgram_sk(const struct sock *sk)
@@ -86,18 +87,18 @@ static int dgram_bind(struct sock *sk, struct sockaddr *uaddr, int len)
{
struct sockaddr_ieee802154 *addr = (struct sockaddr_ieee802154 *)uaddr;
struct dgram_sock *ro = dgram_sk(sk);
- int err = 0;
+ int err = -EINVAL;
struct net_device *dev;
+ lock_sock(sk);
+
ro->bound = 0;
if (len < sizeof(*addr))
- return -EINVAL;
+ goto out;
if (addr->family != AF_IEEE802154)
- return -EINVAL;
-
- lock_sock(sk);
+ goto out;
dev = ieee802154_get_dev(sock_net(sk), &addr->addr);
if (!dev) {
@@ -113,6 +114,7 @@ static int dgram_bind(struct sock *sk, struct sockaddr *uaddr, int len)
memcpy(&ro->src_addr, &addr->addr, sizeof(struct ieee802154_addr));
ro->bound = 1;
+ err = 0;
out_put:
dev_put(dev);
out:
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 06/10] af_ieee802154: provide dummy get/setsockopt
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-6-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Provide dummt get/setsockopt implementations to stop these
syscalls from oopsing on our sockets.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/dgram.c | 14 ++++++++++++++
net/ieee802154/raw.c | 14 ++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index 53dd912..d1da6c6 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -377,6 +377,18 @@ int ieee802154_dgram_deliver(struct net_device *dev, struct sk_buff *skb)
return ret;
}
+static int dgram_getsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user *optlen)
+{
+ return -EOPNOTSUPP;
+}
+
+static int dgram_setsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user optlen)
+{
+ return -EOPNOTSUPP;
+}
+
struct proto ieee802154_dgram_prot = {
.name = "IEEE-802.15.4-MAC",
.owner = THIS_MODULE,
@@ -391,5 +403,7 @@ struct proto ieee802154_dgram_prot = {
.connect = dgram_connect,
.disconnect = dgram_disconnect,
.ioctl = dgram_ioctl,
+ .getsockopt = dgram_getsockopt,
+ .setsockopt = dgram_setsockopt,
};
diff --git a/net/ieee802154/raw.c b/net/ieee802154/raw.c
index ea8d1f1..60dee69 100644
--- a/net/ieee802154/raw.c
+++ b/net/ieee802154/raw.c
@@ -238,6 +238,18 @@ void ieee802154_raw_deliver(struct net_device *dev, struct sk_buff *skb)
read_unlock(&raw_lock);
}
+static int raw_getsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user *optlen)
+{
+ return -EOPNOTSUPP;
+}
+
+static int raw_setsockopt(struct sock *sk, int level, int optname,
+ char __user *optval, int __user optlen)
+{
+ return -EOPNOTSUPP;
+}
+
struct proto ieee802154_raw_prot = {
.name = "IEEE-802.15.4-RAW",
.owner = THIS_MODULE,
@@ -250,5 +262,7 @@ struct proto ieee802154_raw_prot = {
.unhash = raw_unhash,
.connect = raw_connect,
.disconnect = raw_disconnect,
+ .getsockopt = raw_getsockopt,
+ .setsockopt = raw_setsockopt,
};
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* [PATCH 05/10] nl802154: add support for dumping WPAN interface information
From: Dmitry Eremin-Solenikov @ 2009-08-07 12:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249649925-11996-5-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/linux/nl802154.h | 2 +
net/ieee802154/netlink.c | 106 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/include/linux/nl802154.h b/include/linux/nl802154.h
index 266dd96..9a1af5f 100644
--- a/include/linux/nl802154.h
+++ b/include/linux/nl802154.h
@@ -111,6 +111,8 @@ enum {
IEEE802154_RX_ENABLE_REQ, /* Not supported yet */
IEEE802154_RX_ENABLE_CONF, /* Not supported yet */
+ IEEE802154_LIST_IFACE,
+
__IEEE802154_CMD_MAX,
};
diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
index a615b9d..6fc6d6f 100644
--- a/net/ieee802154/netlink.c
+++ b/net/ieee802154/netlink.c
@@ -19,6 +19,7 @@
* Written by:
* Sergey Lapin <slapin-9cOl001CZnBAfugRpC6u6w@public.gmane.org>
* Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ * Maxim Osipov <maxim.osipov-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org>
*/
#include <linux/kernel.h>
@@ -26,6 +27,7 @@
#include <linux/netdevice.h>
#include <net/netlink.h>
#include <net/genetlink.h>
+#include <net/sock.h>
#include <linux/nl802154.h>
#include <net/af_ieee802154.h>
#include <net/nl802154.h>
@@ -73,7 +75,7 @@ static int ieee802154_nl_finish(struct sk_buff *msg)
/* XXX: nlh is right at the start of msg */
void *hdr = genlmsg_data(NLMSG_DATA(msg->data));
- if (!genlmsg_end(msg, hdr))
+ if (genlmsg_end(msg, hdr) < 0)
goto out;
return genlmsg_multicast(msg, 0, ieee802154_coord_mcgrp.id,
@@ -260,6 +262,35 @@ nla_put_failure:
}
EXPORT_SYMBOL(ieee802154_nl_scan_confirm);
+static int ieee802154_nl_fill_iface(struct sk_buff *msg, u32 pid,
+ u32 seq, int flags, struct net_device *dev)
+{
+ void *hdr;
+
+ pr_debug("%s\n", __func__);
+
+ hdr = genlmsg_put(msg, 0, seq, &ieee802154_coordinator_family, flags,
+ IEEE802154_LIST_IFACE);
+ if (!hdr)
+ goto out;
+
+ NLA_PUT_STRING(msg, IEEE802154_ATTR_DEV_NAME, dev->name);
+ NLA_PUT_U32(msg, IEEE802154_ATTR_DEV_INDEX, dev->ifindex);
+
+ NLA_PUT(msg, IEEE802154_ATTR_HW_ADDR, IEEE802154_ADDR_LEN,
+ dev->dev_addr);
+ NLA_PUT_U16(msg, IEEE802154_ATTR_SHORT_ADDR,
+ ieee802154_mlme_ops(dev)->get_short_addr(dev));
+ NLA_PUT_U16(msg, IEEE802154_ATTR_PAN_ID,
+ ieee802154_mlme_ops(dev)->get_pan_id(dev));
+ return genlmsg_end(msg, hdr);
+
+nla_put_failure:
+ genlmsg_cancel(msg, hdr);
+out:
+ return -EMSGSIZE;
+}
+
/* Requests from userspace */
static struct net_device *ieee802154_nl_get_dev(struct genl_info *info)
{
@@ -272,7 +303,7 @@ static struct net_device *ieee802154_nl_get_dev(struct genl_info *info)
dev = dev_get_by_name(&init_net, name);
} else if (info->attrs[IEEE802154_ATTR_DEV_INDEX])
dev = dev_get_by_index(&init_net,
- nla_get_u32(info->attrs[IEEE802154_ATTR_DEV_INDEX]));
+ nla_get_u32(info->attrs[IEEE802154_ATTR_DEV_INDEX]));
else
return NULL;
@@ -466,6 +497,67 @@ static int ieee802154_scan_req(struct sk_buff *skb, struct genl_info *info)
return ret;
}
+static int ieee802154_list_iface(struct sk_buff *skb,
+ struct genl_info *info)
+{
+ /* Request for interface name, index, type, IEEE address,
+ PAN Id, short address */
+ struct sk_buff *msg;
+ struct net_device *dev = NULL;
+ int rc = -ENOBUFS;
+
+ pr_debug("%s\n", __func__);
+
+ dev = ieee802154_nl_get_dev(info);
+ if (!dev)
+ return -ENODEV;
+
+ msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
+ if (!msg)
+ goto out_dev;
+
+ rc = ieee802154_nl_fill_iface(msg, info->snd_pid, info->snd_seq,
+ 0, dev);
+ if (rc < 0)
+ goto out_free;
+
+ dev_put(dev);
+
+ return genlmsg_unicast(msg, info->snd_pid);
+out_free:
+ nlmsg_free(msg);
+out_dev:
+ dev_put(dev);
+ return rc;
+
+}
+
+static int ieee802154_dump_iface(struct sk_buff *skb,
+ struct netlink_callback *cb)
+{
+ struct net *net = sock_net(skb->sk);
+ struct net_device *dev;
+ int idx;
+ int s_idx = cb->args[0];
+
+ pr_debug("%s\n", __func__);
+
+ idx = 0;
+ for_each_netdev(net, dev) {
+ if (idx < s_idx || (dev->type != ARPHRD_IEEE802154))
+ goto cont;
+
+ if (ieee802154_nl_fill_iface(skb, NETLINK_CB(cb->skb).pid,
+ cb->nlh->nlmsg_seq, NLM_F_MULTI, dev) < 0)
+ break;
+cont:
+ idx++;
+ }
+ cb->args[0] = idx;
+
+ return skb->len;
+}
+
#define IEEE802154_OP(_cmd, _func) \
{ \
.cmd = _cmd, \
@@ -475,12 +567,22 @@ static int ieee802154_scan_req(struct sk_buff *skb, struct genl_info *info)
.flags = GENL_ADMIN_PERM, \
}
+#define IEEE802154_DUMP(_cmd, _func, _dump) \
+ { \
+ .cmd = _cmd, \
+ .policy = ieee802154_policy, \
+ .doit = _func, \
+ .dumpit = _dump, \
+ }
+
static struct genl_ops ieee802154_coordinator_ops[] = {
IEEE802154_OP(IEEE802154_ASSOCIATE_REQ, ieee802154_associate_req),
IEEE802154_OP(IEEE802154_ASSOCIATE_RESP, ieee802154_associate_resp),
IEEE802154_OP(IEEE802154_DISASSOCIATE_REQ, ieee802154_disassociate_req),
IEEE802154_OP(IEEE802154_SCAN_REQ, ieee802154_scan_req),
IEEE802154_OP(IEEE802154_START_REQ, ieee802154_start_req),
+ IEEE802154_DUMP(IEEE802154_LIST_IFACE, ieee802154_list_iface,
+ ieee802154_dump_iface),
};
static int __init ieee802154_nl_init(void)
--
1.6.3.3
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply related
* Re: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: Paul Moore @ 2009-08-07 12:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: Eric W. Biederman, netdev, David Miller
In-Reply-To: <20090807000021.GA1566@gondor.apana.org.au>
On Thursday 06 August 2009 08:00:21 pm Herbert Xu wrote:
> On Thu, Aug 06, 2009 at 02:20:20PM -0400, Paul Moore wrote:
> > The code currently looks something like this:
> >
> > err = -ENOMEM;
> > buf = alloc(...);
> > if (!buf)
> > goto label;
> >
> > This means that in the common case where 'alloc()' completes without
> > error we are doing an extra, unnecessary assignment where we set the
> > value in 'err'. Now, if we change this slightly to match what I proposed
> > in the patch:
> >
> > buf = alloc(...);
> > if (!buf) {
> > err = -ENOMEM;
> > goto label;
> > }
> >
> > We eliminate that extra assignment in the case where 'alloc()' completes
> > without error, which should result in more efficient code (less
> > instructions in the common case). Am I wrong? If that is the case I
> > would appreciate an explanation ...
>
> Your style potentially introduces a second jump which may end
> up being worse compared to the extra work on a modern CPU.
Thanks, I hadn't thought of that possibility. I suppose the impact of a
second jump is going to depend quite a bit on the hardware it runs on
(pipeline depth, branch prediction, etc.) and isn't as easy to quantify as I
had hoped. Oh well, I appreciate the explanation anyway :)
--
paul moore
linux @ hp
^ permalink raw reply
* Re: [Socketcan-users] [PATCH] CAN: make checking in can_rcv less restrictive
From: Rémi Denis-Courmont @ 2009-08-07 11:54 UTC (permalink / raw)
To: ext Oliver Hartkopp
Cc: netdev@vger.kernel.org, socketcan-users@lists.berlios.de
In-Reply-To: <4A7C117E.5010005@hartkopp.net>
On Friday 07 August 2009 14:35:26 ext Oliver Hartkopp wrote:
> So you would need to have an originating interface with ARPHRD_CAN ...
>
> Do you think, it's still possible with the TUN driver?
Hmm, actually no... TUN can create packets with any type (ETH_P_*), but
devices always have ARPHRD_NONE type.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* [PATCH] fec: fix FEC driver packet transmission breakage
From: Greg Ungerer @ 2009-08-07 3:58 UTC (permalink / raw)
To: netdev; +Cc: gerg, s.hauer
fec: fix FEC driver packet transmission breakage
Commit f0b3fbeae11a526c3d308b691684589ee37c359b breaks transmission of
packets where the skb data buffer is not memory aligned according to
FEC_ALIGNMENT. It incorrectly passes to dma_sync_single() the buffer
address directly from the skb, instead of the address calculated for
use (which may be the skb address or one of the bounce buffers).
It seems there is no use converting the cpu address of the buffer to
a physical either, since dma_map_single() expects the cpu address and
will return the dma address to use in the descriptor. So remove the use
of __pa() on the buffer address as well.
This patch is against 2.6.30-rc5. This breakage is a regression over
2.6.30, which does not have this problem.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 0d2ab43..a32230b 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -285,6 +285,7 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct fec_enet_private *fep = netdev_priv(dev);
struct bufdesc *bdp;
+ void *bufaddr;
unsigned short status;
unsigned long flags;
@@ -312,7 +313,7 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
status &= ~BD_ENET_TX_STATS;
/* Set buffer length and buffer pointer */
- bdp->cbd_bufaddr = __pa(skb->data);
+ bufaddr = skb->data;
bdp->cbd_datlen = skb->len;
/*
@@ -320,11 +321,11 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
* 4-byte boundaries. Use bounce buffers to copy data
* and get it aligned. Ugh.
*/
- if (bdp->cbd_bufaddr & FEC_ALIGNMENT) {
+ if (((unsigned long) bufaddr) & FEC_ALIGNMENT) {
unsigned int index;
index = bdp - fep->tx_bd_base;
memcpy(fep->tx_bounce[index], (void *)skb->data, skb->len);
- bdp->cbd_bufaddr = __pa(fep->tx_bounce[index]);
+ bufaddr = fep->tx_bounce[index];
}
/* Save skb pointer */
@@ -336,7 +337,7 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* Push the data cache so the CPM does not get stale memory
* data.
*/
- bdp->cbd_bufaddr = dma_map_single(&dev->dev, skb->data,
+ bdp->cbd_bufaddr = dma_map_single(&dev->dev, bufaddr,
FEC_ENET_TX_FRSIZE, DMA_TO_DEVICE);
/* Send it on its way. Tell FEC it's ready, interrupt when done,
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox