* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Neil Horman @ 2011-09-28 11:00 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andy Gospodarek, Stephen Hemminger, jeffrey t kirsher,
David Miller, netdev, gospo, Alexander H Duyck
In-Reply-To: <1317167146.2845.48.camel@bwh-desktop>
On Wed, Sep 28, 2011 at 12:45:46AM +0100, Ben Hutchings wrote:
> On Tue, 2011-09-20 at 16:23 -0400, Neil Horman wrote:
> [...]
> > This is the work Andy is referring to for those interested:
> > http://marc.info/?l=linux-kernel&m=131644727521409&w=2
> >
> > This version has Gregs Ack, and is waiting for an Ack from Jesse Barnes at the
> > moment.
>
> While I think it's useful to be able to list all IRQs assigned to a PCI
> device, this doesn't tell us anything about the way they're associated
> with queues.
>
I never claimed that it did. This just lets us definitavely correlate msi irq
instances to pci devices, and their device class. Preveously we were limited to
guessing what kind device an irq belonged to by doing hopeful string matches on
device names from proc/interrupts, something which was easily broken by a change
in driver naming practice, or an administrative device name change.
> > I think Andy's probably right, theres room here for expansion to create
> > a relationship between a given interrupt and a napi wieght. I expect what would
> > be most direct would be adding a napi_weight attribute that was conditional on
> > the class of the pci device allocating the irqs (make it visible for class 0x200
> > devs, invisible for others).
>
> That's a terrible idea; what has NAPI got to do with PCI devices?
>
Nothing directly, but stop making up an implementation, and deciding based on
that the whole notion is stupid. There are a few ways to do this, some of which
make sense.
I was thinking of something along the lines of two more attributes in
/sys/class/net/<if>/queues:
napi_weight
irq
The former is the napi weight of a given napi instance associated with a queue,
while the latter is a symlink either to ../device/irq or ../device/msi_irqs/<n>/
(or perhaps to ../devices/msi_irqs/<n>/irq if we want more consistency). This
lets us tune the napi weight of a queue and know what interrupt is associated
with it. That seems fairly sane to me.
Neil
^ permalink raw reply
* Re: [PATCH] tcp: properly update lost_cnt_hint during shifting
From: Ilpo Järvinen @ 2011-09-28 11:29 UTC (permalink / raw)
To: Yan, Zheng; +Cc: netdev@vger.kernel.org, Nandita Dukkipati
In-Reply-To: <4E82FAD6.1010708@intel.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1383 bytes --]
On Wed, 28 Sep 2011, Yan, Zheng wrote:
> > But is the non-SACKed case really handled right when hint == skb by the
> > sacktag_one. We move the seqno in between and then before(x->newseq,
> > x->newseq) check returns false?
> >
> you are right, thank you.
>
> really hope my patch is correct this time :)
> ---
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 21fab3e..a04622e 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -1390,8 +1390,7 @@ static int tcp_shifted_skb(struct sock *sk, struct sk_buff *skb,
> BUG_ON(!pcount);
>
> /* Tweak before seqno plays */
> - if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint &&
> - !before(TCP_SKB_CB(tp->lost_skb_hint)->seq, TCP_SKB_CB(skb)->seq))
> + if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint == skb)
> tp->lost_cnt_hint += pcount;
>
> TCP_SKB_CB(prev)->end_seq += shifted;
It also looks a lot nicer now and more obvious. According to my current
understanding, feel free to add this once doing the proper submission with
Signed-off etc. (please also remove the comment too as seqnos have no
longer any significance here):
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
...but it certainly wouldn't hurt if also somebody else has pair of eyes
to spare to confirm that we (both) are now in agreement what the code
really says.
--
i.
^ permalink raw reply
* Re: [PATCH v2 4/7] per-cgroup tcp buffers control
From: Andrew Wagin @ 2011-09-28 11:58 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <1316051175-17780-5-git-send-email-glommer@parallels.com>
* tcp_destroy_cgroup_fill() is executed for each cgroup and
initializes some proto methods. proto_list is global and we can
initialize each proto one time. Do we need this really?
* And when a cgroup is destroyed, it cleans proto methods
(tcp_destroy_cgroup_fill), how other cgroups will work after that?
* What about proto, which is registered when cgroup mounted?
My opinion that we may initialize proto by the following way:
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM+ .enter_memory_pressure
= tcp_enter_memory_pressure_nocg,
+ .sockets_allocated = sockets_allocated_tcp_nocg,
+ .memory_allocated = memory_allocated_tcp_nocg,
+ .memory_pressure = memory_pressure_tcp_nocg,
+#else
.enter_memory_pressure = tcp_enter_memory_pressure,
.sockets_allocated = sockets_allocated_tcp,
.memory_allocated = memory_allocated_tcp,
.memory_pressure = memory_pressure_tcp,
+#endif
It should work, because the root memory cgroup always exists.
>+int tcp_init_cgroup_fill(struct proto *prot, struct cgroup *cgrp,
>+ struct cgroup_subsys *ss)
>+{
>+ prot->enter_memory_pressure = tcp_enter_memory_pressure;
>+ prot->memory_allocated = memory_allocated_tcp;
>+ prot->prot_mem = tcp_sysctl_mem;
>+ prot->sockets_allocated = sockets_allocated_tcp;
>+ prot->memory_pressure = memory_pressure_tcp;
>+
>+ return 0;
>+}
> +void tcp_destroy_cgroup_fill(struct proto *prot, struct cgroup *cgrp,
> + struct cgroup_subsys *ss)
> +{
> + prot->enter_memory_pressure = tcp_enter_memory_pressure_nocg;
> + prot->memory_allocated = memory_allocated_tcp_nocg;
> + prot->prot_mem = tcp_sysctl_mem_nocg;
> + prot->sockets_allocated = sockets_allocated_tcp_nocg;
> + prot->memory_pressure = memory_pressure_tcp_nocg;
>
>@@ -2220,12 +2220,16 @@ struct proto tcpv6_prot = {
> .hash = tcp_v6_hash,
> .unhash = inet_unhash,
> .get_port = inet_csk_get_port
> + .enter_memory_pressure = tcp_enter_memory_pressure_nocg,
> + .sockets_allocated = sockets_allocated_tcp_nocg,
> + .memory_allocated = memory_allocated_tcp_nocg,
> + .memory_pressure = memory_pressure_tcp_nocg,
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 1/7] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-09-28 12:03 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel, paul, lizf, ebiederm, davem, gthelen, netdev,
linux-mm, kirill
In-Reply-To: <20110928095826.eb8ebc8c.kamezawa.hiroyu@jp.fujitsu.com>
On 09/27/2011 09:58 PM, KAMEZAWA Hiroyuki wrote:
> On Mon, 26 Sep 2011 20:18:39 -0300
> Glauber Costa<glommer@parallels.com> wrote:
>
>> On 09/26/2011 07:34 AM, KAMEZAWA Hiroyuki wrote:
>>> On Sun, 18 Sep 2011 21:56:39 -0300
>>> Glauber Costa<glommer@parallels.com> wrote:
> "If parent sets use_hierarchy==1, children must have the same kmem_independent value
>>> with parant's one."
>>>
>>> How do you think ? I think a hierarchy must have the same config.
>> BTW, Kame:
>>
>> Look again (I forgot myself when I first replied to you)
>> Only in the root cgroup those files get registered.
>> So shouldn't be a problem, because children won't even
>> be able to see them.
>>
>> Do you agree with this ?
>>
>
> agreed.
>
Actually it is the other way around, following previous suggestions...
The root cgroup does *not* get those files registered, since we don't
intend to do any kernel memory limitation for it. The others get it.
Given that, I will proceed writing some code to respect parent cgroup's
hierarchy.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Possible NULL dereference caused by -stable commit ef81bb40bf15f350fe865f31fa42f1082772a576
From: Eric Dumazet @ 2011-09-28 12:09 UTC (permalink / raw)
To: Jason Wang
Cc: netdev, David S. Miller, linux-kernel, Greg KH, stable,
Michael S. Tsirkin, Amos Kong
In-Reply-To: <4E82FC4E.5010101@redhat.com>
Le mercredi 28 septembre 2011 à 18:51 +0800, Jason Wang a écrit :
> Hi all:
>
> A possible NULL dereference were noticed by the stable commit
> ef81bb40bf15f350fe865f31fa42f1082772a576 (which is a backport of
> 87c48fa3b4630905f98268dde838ee43626a060c). The case happens when bridge
> froward a packet from guest to a physical nic, at this time no route is
> attached to the skb which may lead a NULL dereference in
> ipv6_select_ident(). -Next version have this check so it is fine. The
> following patch may be used to avoid this but may also lead the ip
> identification predicable, and this defect is also exist -next version
> when no route because we still depends on a global variable to generate
> the identification. Any thought on this?
1) Discussion on current kernel :
All we need here is not the route but inet_peer, so that inet_getid()
can be called on it.
If no route is given to ipv6_select_ident(), at least we can try to get
inet_peer, and release it before exiting from ipv6_select_ident()
2) On stable kernel, we already use an array
(ipv6_fragmentation_id[FID_HASH_SZ];) to make less predictables
fragments ids.
So we could get dst addr from the packet to be forwarded instead of the
(possibly NULL) route.
^ permalink raw reply
* Re: [PATCH v2 4/7] per-cgroup tcp buffers control
From: Glauber Costa @ 2011-09-28 12:11 UTC (permalink / raw)
To: Andrew Wagin
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <CANaxB-wy8VDv0Wjni6UzcfBzSgNn=bZBey5f+fXHebNuek=O1A@mail.gmail.com>
On 09/28/2011 08:58 AM, Andrew Wagin wrote:
> * tcp_destroy_cgroup_fill() is executed for each cgroup and
> initializes some proto methods. proto_list is global and we can
> initialize each proto one time. Do we need this really?
>
> * And when a cgroup is destroyed, it cleans proto methods
> (tcp_destroy_cgroup_fill), how other cgroups will work after that?
I've already realized that, and removed destruction from my upcoming
series. Thanks
> * What about proto, which is registered when cgroup mounted?
>
> My opinion that we may initialize proto by the following way:
>
> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM+ .enter_memory_pressure
> = tcp_enter_memory_pressure_nocg,
> + .sockets_allocated = sockets_allocated_tcp_nocg,
> + .memory_allocated = memory_allocated_tcp_nocg,
> + .memory_pressure = memory_pressure_tcp_nocg,
> +#else
> .enter_memory_pressure = tcp_enter_memory_pressure,
> .sockets_allocated = sockets_allocated_tcp,
> .memory_allocated = memory_allocated_tcp,
> .memory_pressure = memory_pressure_tcp,
> +#endif
>
> It should work, because the root memory cgroup always exists.
Yeah, I was still doing the initialization through cgroups, but I think
this works.
The reason I was keeping it cgroup's initialization method, was because
we have a parameter that allowed kmem accounting to be disabled.
But Kame suggested we'd remove it, and so I did.
>
>> +int tcp_init_cgroup_fill(struct proto *prot, struct cgroup *cgrp,
>> + struct cgroup_subsys *ss)
>> +{
>> + prot->enter_memory_pressure = tcp_enter_memory_pressure;
>> + prot->memory_allocated = memory_allocated_tcp;
>> + prot->prot_mem = tcp_sysctl_mem;
>> + prot->sockets_allocated = sockets_allocated_tcp;
>> + prot->memory_pressure = memory_pressure_tcp;
>> +
>> + return 0;
>> +}
>
>
>> +void tcp_destroy_cgroup_fill(struct proto *prot, struct cgroup *cgrp,
>> + struct cgroup_subsys *ss)
>> +{
>> + prot->enter_memory_pressure = tcp_enter_memory_pressure_nocg;
>> + prot->memory_allocated = memory_allocated_tcp_nocg;
>> + prot->prot_mem = tcp_sysctl_mem_nocg;
>> + prot->sockets_allocated = sockets_allocated_tcp_nocg;
>> + prot->memory_pressure = memory_pressure_tcp_nocg;
>>
>
>> @@ -2220,12 +2220,16 @@ struct proto tcpv6_prot = {
>> .hash = tcp_v6_hash,
>> .unhash = inet_unhash,
>> .get_port = inet_csk_get_port
>> + .enter_memory_pressure = tcp_enter_memory_pressure_nocg,
>> + .sockets_allocated = sockets_allocated_tcp_nocg,
>> + .memory_allocated = memory_allocated_tcp_nocg,
>> + .memory_pressure = memory_pressure_tcp_nocg,
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/2] virtio-net: Verify page list size before fitting into skb
From: Sasha Levin @ 2011-09-28 12:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Rusty Russell, virtualization, netdev, kvm
In-Reply-To: <20110927123719.GB11276@redhat.com>
On Tue, 2011-09-27 at 15:37 +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 27, 2011 at 02:20:29PM +0300, Sasha Levin wrote:
> > On Tue, 2011-09-27 at 10:00 +0300, Michael S. Tsirkin wrote:
> > > > skb = page_to_skb(vi, page, len);
> > > > ...
> > >
> > > Sorry I don't get it yet. Where is mergeable ignored here?
> >
> > The NULL deref happens in page_to_skb(), before merge buffers are
> > handled.
>
> The len here is a single buffer length, so for mergeable
> buffers it is <= the size of the buffer we gave to hardware,
> which is PAGE_SIZE.
>
> err = virtqueue_add_buf_single(vi->rvq, page_address(page),
> PAGE_SIZE, false, page, gfp);
>
>
> Unless of course we are trying to work around broken hardware again,
> which I don't have a problem with, but should probably
> get appropriate comments in code and trigger a warning.
>
> > I'll test it and see if it's really the case.
I've verified it with VIRTIO_NET_F_MRG_RXBUF set, and we still get the
NULL deref.
--
Sasha.
^ permalink raw reply
* [PATCH net-next v3] candev: allow SJW user setting for bittiming calculation
From: Oliver Hartkopp @ 2011-09-28 12:50 UTC (permalink / raw)
To: David Miller
Cc: SocketCAN Core Mailing List, Linux Netdev List,
Wolfgang Grandegger
This patch adds support for SJW user settings to not set the synchronization
jump width (SJW) to 1 in any case when using the in-kernel bittiming
calculation.
The ip-tool from iproute2 already supports to pass the user defined SJW
value. The given SJW value is sanitized with the controller specific sjw_max
and the calculated tseg2 value. As the SJW can have values up to 4 providing
this value will lead to the maximum possible SJW automatically. A higher SJW
allows higher controller oscillator tolerances.
Signed-off-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
---
v2: Resend due to wrong mail address header encoding.
v3: - Detected malformed patch format due to line break in function name
- Added Acked-by: from Wolfgang Grandegger
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 9bf1116..25695bd 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -150,7 +150,19 @@ static int can_calc_bittiming(struct net_device *dev, struct can_bittiming *bt)
bt->prop_seg = tseg1 / 2;
bt->phase_seg1 = tseg1 - bt->prop_seg;
bt->phase_seg2 = tseg2;
- bt->sjw = 1;
+
+ /* check for sjw user settings */
+ if (!bt->sjw || !btc->sjw_max)
+ bt->sjw = 1;
+ else {
+ /* bt->sjw is at least 1 -> sanitize upper bound to sjw_max */
+ if (bt->sjw > btc->sjw_max)
+ bt->sjw = btc->sjw_max;
+ /* bt->sjw must not be higher than tseg2 */
+ if (tseg2 < bt->sjw)
+ bt->sjw = tseg2;
+ }
+
bt->brp = best_brp;
/* real bit-rate */
bt->bitrate = priv->clock.freq / (bt->brp * (tseg1 + tseg2 + 1));
^ permalink raw reply related
* Re: [GIT PULL net-next] IPVS
From: Simon Horman @ 2011-09-28 13:28 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Wensong Zhang,
Julian Anastasov, Patrick McHardy, David S. Miller
In-Reply-To: <20110927081618.GA22655@1984>
On Tue, Sep 27, 2011 at 10:16:18AM +0200, Pablo Neira Ayuso wrote:
> On Mon, Sep 26, 2011 at 06:05:33PM +0900, Simon Horman wrote:
> > Hi,
> >
> > with all the excitement of kernel.org being offline and a bunch of trees
> > likewise being offline I am a little unsure who should take this pull
> > request which is based on the current net-next tree. But I guess it should
> > be Patrick, Pablo or Dave.
>
> I'll try to set up one tree in one of my servers along today, I'll
> send you the URI. We can use it until kernel.org comes back.
Thanks. Would you like me to rebase my tree on yours?
^ permalink raw reply
* [PATCH v2] tcp: properly update lost_cnt_hint during shifting
From: Yan, Zheng @ 2011-09-28 14:13 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: Ilpo Järvinen, Nandita Dukkipati, davem@davemloft.net
lost_skb_hint is used by tcp_mark_head_lost() to mark the first unhandled skb.
lost_cnt_hint is the number of sacked packets before the lost_skb_hint. When
shifting a skb that is before the lost_skb_hint, tcp_shifted_skb() doesn't need
to adjust lost_cnt_hint by itself because it calls tcp_sacktag_one() which will
do the job right.
Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 21fab3e..ae5a934 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1389,9 +1389,7 @@ static int tcp_shifted_skb(struct sock *sk, struct sk_buff *skb,
BUG_ON(!pcount);
- /* Tweak before seqno plays */
- if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint &&
- !before(TCP_SKB_CB(tp->lost_skb_hint)->seq, TCP_SKB_CB(skb)->seq))
+ if (!tcp_is_fack(tp) && tcp_is_sack(tp) && tp->lost_skb_hint == skb)
tp->lost_cnt_hint += pcount;
TCP_SKB_CB(prev)->end_seq += shifted;
^ permalink raw reply related
* Question about reply to a datagram sent to a Subnet-Router anycast address
From: François-Xavier Le Bail @ 2011-09-28 14:13 UTC (permalink / raw)
To: Linux Netdev List
Hi All,
I try to ping some routers on one of their Subnet-Router anycast addresses (SRAA).
(http://tools.ietf.org/html/rfc4291#section-2.6.1)
A Linux kernel 3.0 in IPv6 forwarding mode reply with an unicast source address (same subnet prefix).
An Alcatel router reply with the SRAA as source address.
The RFC 4291 removed the restrictions on using IPv6 anycast addresses, so a SRAA may be used as a source address, in a reply.
In the following draft, we have a rationale for the removal of restrictions regarding anycast as source address in RFC 4291 :
(http://tools.ietf.org/html/draft-jabley-v6-anycast-clarify-00#section-3.1)
"3.1 Anycast Source Addresses
For many conventional services to be distributed using anycast, it is
necessary for reply datagrams sent from servers to clients to be
sourced from the same address that was used as the destination in
request datagrams sent from clients to servers. When such a service
is distributed using anycast, the destination address used in request
datagrams is necessarily an anycast address; corresponding reply
packets must therefore use the same anycast address as their source
address.
Being able to use an anycast address as the source address in an IPv6
datagram is a prerequisite for the distribution of many services
using anycast over IPv6."
A SRAA is a special case of anycast address.
Is there a way to setup the Linux kernel to behave like Alcatel router, replying with the SRAA as source address ?
If not, why not update the behaviour of the Linux kernel to configurable ?
Please let me know your feedback.
Thanks,
Francois-Xavier Le Bail
^ permalink raw reply
* [PATCH v2 1/2] virtio-net: Verify page list size before fitting into skb
From: Sasha Levin @ 2011-09-28 14:40 UTC (permalink / raw)
To: linux-kernel
Cc: Sasha Levin, Rusty Russell, Michael S. Tsirkin, virtualization,
netdev, kvm
This patch verifies that the length of a buffer stored in a linked list
of pages is small enough to fit into a skb.
If the size is larger than a max size of a skb, it means that we shouldn't
go ahead building skbs anyway since we won't be able to send the buffer as
the user requested.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Cc: netdev@vger.kernel.org
Cc: kvm@vger.kernel.org
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
drivers/net/virtio_net.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0c7321c..bde0dec 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -195,6 +195,19 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
len -= copy;
offset += copy;
+ /*
+ * Verify that we can indeed put this data into a skb.
+ * This is here to handle cases when the device erroneously
+ * tries to receive more than is possible. This is usually
+ * the case of a broken device.
+ */
+ if (unlikely(len > MAX_SKB_FRAGS * PAGE_SIZE)) {
+ if (net_ratelimit())
+ pr_debug("%s: too much data\n", skb->dev->name);
+ dev_kfree_skb(skb);
+ return NULL;
+ }
+
while (len) {
set_skb_frag(skb, page, offset, &len);
page = (struct page *)page->private;
--
1.7.6.1
^ permalink raw reply related
* [PATCH v2 2/2] virtio-net: Prevent NULL dereference
From: Sasha Levin @ 2011-09-28 14:40 UTC (permalink / raw)
To: linux-kernel
Cc: Sasha Levin, Rusty Russell, Michael S. Tsirkin, virtualization,
netdev, kvm
In-Reply-To: <1317220855-9352-1-git-send-email-levinsasha928@gmail.com>
This patch prevents a NULL dereference when the user has passed a length
longer than an actual buffer to virtio-net.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Cc: netdev@vger.kernel.org
Cc: kvm@vger.kernel.org
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
drivers/net/virtio_net.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index bde0dec..4a53d2a 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -208,12 +208,22 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
return NULL;
}
- while (len) {
+ while (len && page) {
set_skb_frag(skb, page, offset, &len);
page = (struct page *)page->private;
offset = 0;
}
+ /*
+ * This is the case where we ran out of pages in our linked list, but
+ * supposedly have more data to read.
+ */
+ if (len > 0) {
+ pr_debug("%s: missing data to assemble skb\n", skb->dev->name);
+ dev_kfree_skb(skb);
+ return NULL;
+ }
+
if (page)
give_pages(vi, page);
--
1.7.6.1
^ permalink raw reply related
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Stephen Hemminger @ 2011-09-28 15:11 UTC (permalink / raw)
To: Neil Horman
Cc: Ben Hutchings, Andy Gospodarek, Stephen Hemminger,
jeffrey t kirsher, David Miller, netdev, gospo, Alexander H Duyck
In-Reply-To: <20110928110055.GA15340@hmsreliant.think-freely.org>
On Wed, 28 Sep 2011 07:00:55 -0400
Neil Horman <nhorman@tuxdriver.com> wrote:
> I was thinking of something along the lines of two more attributes in
> /sys/class/net/<if>/queues:
> napi_weight
> irq
>
> The former is the napi weight of a given napi instance associated with a queue,
> while the latter is a symlink either to ../device/irq or ../device/msi_irqs/<n>/
> (or perhaps to ../devices/msi_irqs/<n>/irq if we want more consistency). This
> lets us tune the napi weight of a queue and know what interrupt is associated
> with it. That seems fairly sane to me.
This breaks for the case of some corner case devices like multi-port Marvell boards.
There can be a N to 1 or 1 to N relationship between NAPI and the device.
^ permalink raw reply
* Re: Bridging broken/unfriendly
From: Michal Soltys @ 2011-09-28 15:21 UTC (permalink / raw)
To: sclark46; +Cc: Linux Kernel Network Developers
In-Reply-To: <4E7E5976.1070200@earthlink.net>
On 11-09-25 00:28, Stephen Clark wrote:
> Hi,
>
> Is there some reason Linux bridging won't let the ip address be on
> one of the interfaces, like FreeBSD does, instead of the bridge device?
>
You can do that, though you have to remember about proper routing, and
you will need ebtables to make some of the traffic not go through the
bridge.
Check http://ebtables.sourceforge.net/examples/basic.html#all for more
details.
^ permalink raw reply
* Re: Bridging broken/unfriendly
From: Stephen Hemminger @ 2011-09-28 15:30 UTC (permalink / raw)
To: sclark46; +Cc: Linux Kernel Network Developers
In-Reply-To: <4E7E5976.1070200@earthlink.net>
On Sat, 24 Sep 2011 18:28:06 -0400
Stephen Clark <sclark46@earthlink.net> wrote:
> Hi,
>
> Is there some reason Linux bridging won't let the ip address be on
> one of the interfaces, like FreeBSD does, instead of the bridge device?
>
> This makes it very difficult or impossible to remotely add the interface
> you are remoted in on to a bridge, or is there some sneaky way to
> do this without losing your connection?
>
I would like to see a clean solution to setting up a bridge.
There was a patch that was never completed to allow migrating a ethernet
interface into a bridge. It is possible to do it with a script, by
dumping routes with ip command and replaying that into the bridge.
To really do it right (including neighbor table and iptables rules)
would be complex, especially considering the error cases.
Having looked at the FreeBSD code, that is not the answer. Trying to keep
a clean separation between IP and bridging is much better.
^ permalink raw reply
* [PATCH 1/1] ibmveth: Fix oops on request_irq failure
From: Brian King @ 2011-09-28 15:33 UTC (permalink / raw)
To: netdev; +Cc: brking
If request_irq fails, the ibmveth driver will overwrite
the rc and end up returning a successful rc on its open
function, resulting in an oops later when a packet gets
sent and buffers are not allocated due to the failed open.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
drivers/net/ibmveth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_bounce_oops2 drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_bounce_oops2 2011-09-28 09:53:09.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2011-09-28 09:53:09.000000000 -0500
@@ -636,8 +636,8 @@ static int ibmveth_open(struct net_devic
netdev_err(netdev, "unable to request irq 0x%x, rc %d\n",
netdev->irq, rc);
do {
- rc = h_free_logical_lan(adapter->vdev->unit_address);
- } while (H_IS_LONG_BUSY(rc) || (rc == H_BUSY));
+ lpar_rc = h_free_logical_lan(adapter->vdev->unit_address);
+ } while (H_IS_LONG_BUSY(lpar_rc) || (lpar_rc == H_BUSY));
goto err_out;
}
_
^ permalink raw reply
* Re: [GIT PULL net-next] IPVS
From: Pablo Neira Ayuso @ 2011-09-28 15:45 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Wensong Zhang,
Julian Anastasov, Patrick McHardy, David S. Miller
In-Reply-To: <20110928132802.GC7661@verge.net.au>
On Wed, Sep 28, 2011 at 10:28:03PM +0900, Simon Horman wrote:
> On Tue, Sep 27, 2011 at 10:16:18AM +0200, Pablo Neira Ayuso wrote:
> > On Mon, Sep 26, 2011 at 06:05:33PM +0900, Simon Horman wrote:
> > > Hi,
> > >
> > > with all the excitement of kernel.org being offline and a bunch of trees
> > > likewise being offline I am a little unsure who should take this pull
> > > request which is based on the current net-next tree. But I guess it should
> > > be Patrick, Pablo or Dave.
> >
> > I'll try to set up one tree in one of my servers along today, I'll
> > send you the URI. We can use it until kernel.org comes back.
>
> Thanks. Would you like me to rebase my tree on yours?
For your patches, I put them in one branch and will cherrypick them
into master.
BTW, the trees are here:
http://1984.lsi.us.es/git/?p=net/.git;a=summary
http://1984.lsi.us.es/git/?p=net-next/.git;a=summary
I'll start iterating over the list collecting patches along today.
^ permalink raw reply
* Re: Bridging broken/unfriendly
From: Stephen Clark @ 2011-09-28 16:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux Kernel Network Developers
In-Reply-To: <20110928083021.2edf43a6@nehalam.linuxnetplumber.net>
On 09/28/2011 11:30 AM, Stephen Hemminger wrote:
> On Sat, 24 Sep 2011 18:28:06 -0400
> Stephen Clark<sclark46@earthlink.net> wrote:
>
>
>> Hi,
>>
>> Is there some reason Linux bridging won't let the ip address be on
>> one of the interfaces, like FreeBSD does, instead of the bridge device?
>>
>> This makes it very difficult or impossible to remotely add the interface
>> you are remoted in on to a bridge, or is there some sneaky way to
>> do this without losing your connection?
>>
>>
> I would like to see a clean solution to setting up a bridge.
> There was a patch that was never completed to allow migrating a ethernet
> interface into a bridge. It is possible to do it with a script, by
> dumping routes with ip command and replaying that into the bridge.
> To really do it right (including neighbor table and iptables rules)
> would be complex, especially considering the error cases.
>
> Having looked at the FreeBSD code, that is not the answer. Trying to keep
> a clean separation between IP and bridging is much better.
>
>
Hi Stephen,
Thanks for taking the time to reply. I had pretty much decided I would
have to do some kind
of script that would do everything at once, instead of trying to do the
commands one at a
time from the console.
Regards,
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: linux-next: build failure after merge of the moduleh tree
From: Kalle Valo @ 2011-09-28 16:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Paul Gortmaker, linux-next, linux-kernel,
Vasanthakumar Thiagarajan, Raja Mani, Vivek Natarajan,
Suraj Sumangala, Joe Perches, Jouni Malinen, John W. Linville,
David Miller, netdev, linux-wireless
In-Reply-To: <20110928183552.cb27a2b28b02fec275bca009@canb.auug.org.au>
On 09/28/2011 11:35 AM, Stephen Rothwell wrote:
> Hi Paul,
>
> After merging the moduleh tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/net/wireless/ath/ath6kl/init.c:27:26: error: expected ')' before 'uint'
>
> Caused by commit bdcd81707973 ("Add ath6kl cleaned up driver") from the
> net tree interacting with the module.h split up.
>
> I have applied the following patch for today (which sould be applied to
> the net or wireless trees).
>
> From 1875bfc8881cca3064c7d7fad024555fe1652926 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 28 Sep 2011 18:32:34 +1000
> Subject: [PATCH] wireless/ath6kl: use of module_param requires the inclusion
> of moduleparam.h
>
> Otheriwse the module.h split up fails like this:
>
> drivers/net/wireless/ath/ath6kl/init.c:27:26: error: expected ')' before 'uint'
Thanks, I applied this to ath6kl.git (had to fix just one conflict).
Later this week I will send a pull request to John so that the patch
should get to the wireless tree soon.
Unless John wants to take the patch directly, of course.
Kalle
^ permalink raw reply
* Re: [PATCH v2 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: David Daney @ 2011-09-28 16:51 UTC (permalink / raw)
To: Michał Mirosław
Cc: devicetree-discuss, grant.likely, linux-kernel, netdev, davem
In-Reply-To: <CAHXqBFLzrkH4AJVozbtT4k7ccgVgfaPoq69J48DeSJKSwEtxHw@mail.gmail.com>
On 09/28/2011 12:25 AM, Michał Mirosław wrote:
> 2011/9/28 David Daney<david.daney@cavium.com>:
> [...]
>> +Example :
>> +
>> + /* The parent MDIO bus. */
>> + smi1: mdio@1180000001900 {
>> + compatible = "cavium,octeon-3860-mdio";
>> + #address-cells =<1>;
>> + #size-cells =<0>;
>> + reg =<0x11800 0x00001900 0x0 0x40>;
>> + };
>> +
>> + /*
>> + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
>> + pair of GPIO lines. Child busses 2 and 3 populated with 4
>> + PHYs each.
>> + */
>> + mdio-mux {
>> + compatible = "cavium,mdio-mux-sn74cbtlv3253", "cavium,mdio-mux";
>> + gpios =<&gpio1 3 0>,<&gpio1 4 0>;
>> + mdio-parent-bus =<&smi1>;
>> + #address-cells =<1>;
>> + #size-cells =<0>;
>
> This should probably have 'compatible = "nxp,sn74cbtlv3253";' here.
>
No, the sn74cbtlv3253 is a general purpose part that could be used to
multiplex anything (I2C, SPI, random analog signals, etc.). Only when
it is in the "cavium,mdio-mux-sn74cbtlv3253" configuration is it an MDIO
bus multiplexer.
David Daney.
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Neil Horman @ 2011-09-28 17:07 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ben Hutchings, Andy Gospodarek, Stephen Hemminger,
jeffrey t kirsher, David Miller, netdev, gospo, Alexander H Duyck
In-Reply-To: <20110928081158.7273e9b4@nehalam.linuxnetplumber.net>
On Wed, Sep 28, 2011 at 08:11:58AM -0700, Stephen Hemminger wrote:
> On Wed, 28 Sep 2011 07:00:55 -0400
> Neil Horman <nhorman@tuxdriver.com> wrote:
>
> > I was thinking of something along the lines of two more attributes in
> > /sys/class/net/<if>/queues:
> > napi_weight
> > irq
> >
> > The former is the napi weight of a given napi instance associated with a queue,
> > while the latter is a symlink either to ../device/irq or ../device/msi_irqs/<n>/
> > (or perhaps to ../devices/msi_irqs/<n>/irq if we want more consistency). This
> > lets us tune the napi weight of a queue and know what interrupt is associated
> > with it. That seems fairly sane to me.
>
> This breaks for the case of some corner case devices like multi-port Marvell boards.
> There can be a N to 1 or 1 to N relationship between NAPI and the device.
>
I don't see that it has to explicitly _break_ anything. If a multiqueue device
uses a single napi instance to handle all queues, we can still create a napi
weight attribute for each queue, and simply let the device driver tie all the
weight sysfs objects to the same napi instance. It would be odd for certain,
but doable. In fact, since we'd have to get the driver involved in the creation
of such a per-queue napi weight attribute (since the driver is the only thing
with any knoweldge about which queue maps to which napi instance), we might be
able to explicitly export this information by allowing a single queue to hold
the napi wieght, and allowing the other queues sysfs symlinks back to that
object.
I'm just spitballing here on implementation, but I don't think the idea is
broken.
Neil
^ permalink raw reply
* Re: Possible NULL dereference caused by -stable commit ef81bb40bf15f350fe865f31fa42f1082772a576
From: David Miller @ 2011-09-28 17:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: jasowang, netdev, linux-kernel, gregkh, stable, mst, akong
In-Reply-To: <1317211749.2941.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Sep 2011 14:09:09 +0200
> All we need here is not the route but inet_peer, so that inet_getid()
> can be called on it.
It's not exactly that simple, you have to parse all hop-by-hop options
to get the correct "destination" address.
^ permalink raw reply
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Catalin Marinas @ 2011-09-28 17:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Huajun Li, linux-mm@kvack.org, netdev, linux-kernel, Tejun Heo,
Christoph Lameter
In-Reply-To: <1317066395.2796.11.camel@edumazet-laptop>
On Mon, Sep 26, 2011 at 08:46:35PM +0100, Eric Dumazet wrote:
> Le lundi 26 septembre 2011 à 17:50 +0100, Catalin Marinas a écrit :
> > kmemleak_not_leak() definitely not the write answer. The alloc_percpu()
> > call does not have any kmemleak_alloc() callback, so it doesn't scan
> > them.
> >
> > Huajun, could you please try the patch below:
...
> Hmm, you need to call kmemleak_alloc() for each chunk allocated per
> possible cpu.
I tried this but it's tricky. The problem is that the percpu pointer
returned by alloc_percpu() does not directly point to the per-cpu chunks
and kmemleak would report most percpu allocations as leaks. So far the
workaround is to simply mark the alloc_percpu() objects as never leaking
and at least we avoid false positives in other areas. See the patch
below (note that you have to increase the CONFIG_KMEMLEAK_EARLY_LOG_SIZE
as there are many alloc_percpu() calls before kmemleak is fully
initialised):
------------8<------------------------------------
kmemleak: Handle percpu memory allocation
From: Catalin Marinas <catalin.marinas@arm.com>
This patch adds kmemleak callbacks from the percpu allocator, reducing a
number of false positives caused by kmemleak not scanning such memory
blocks.
Reported-by: Huajun Li <huajun.li.lee@gmail.com>
Cc: Tejun Heo <tj@kernel.org>,
Cc: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
mm/percpu.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index bf80e55..ece9f85 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -67,6 +67,7 @@
#include <linux/spinlock.h>
#include <linux/vmalloc.h>
#include <linux/workqueue.h>
+#include <linux/kmemleak.h>
#include <asm/cacheflush.h>
#include <asm/sections.h>
@@ -709,6 +710,8 @@ static void __percpu *pcpu_alloc(size_t size, size_t align, bool reserved)
const char *err;
int slot, off, new_alloc;
unsigned long flags;
+ void __percpu *ptr;
+ unsigned int cpu;
if (unlikely(!size || size > PCPU_MIN_UNIT_SIZE || align > PAGE_SIZE)) {
WARN(true, "illegal size (%zu) or align (%zu) for "
@@ -801,7 +804,16 @@ area_found:
mutex_unlock(&pcpu_alloc_mutex);
/* return address relative to base address */
- return __addr_to_pcpu_ptr(chunk->base_addr + off);
+ ptr = __addr_to_pcpu_ptr(chunk->base_addr + off);
+
+ /*
+ * Percpu allocations are currently reported as leaks (kmemleak false
+ * positives). To avoid this, just set min_count to 0.
+ */
+ for_each_possible_cpu(cpu)
+ kmemleak_alloc(per_cpu_ptr(ptr, cpu), size, 0, GFP_KERNEL);
+
+ return ptr;
fail_unlock:
spin_unlock_irqrestore(&pcpu_lock, flags);
@@ -911,10 +923,14 @@ void free_percpu(void __percpu *ptr)
struct pcpu_chunk *chunk;
unsigned long flags;
int off;
+ unsigned int cpu;
if (!ptr)
return;
+ for_each_possible_cpu(cpu)
+ kmemleak_free(per_cpu_ptr(ptr, cpu));
+
addr = __pcpu_ptr_to_addr(ptr);
spin_lock_irqsave(&pcpu_lock, flags);
@@ -1619,6 +1635,8 @@ int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
rc = -ENOMEM;
goto out_free_areas;
}
+ /* kmemleak tracks the percpu allocations separately */
+ kmemleak_free(ptr);
areas[group] = ptr;
base = min(ptr, base);
@@ -1733,6 +1751,8 @@ int __init pcpu_page_first_chunk(size_t reserved_size,
"for cpu%u\n", psize_str, cpu);
goto enomem;
}
+ /* kmemleak tracks the percpu allocations separately */
+ kmemleak_free(ptr);
pages[j++] = virt_to_page(ptr);
}
--
Catalin
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: Draft manpage for recvmmsg [RESEND]
From: Michael Kerrisk @ 2011-09-28 17:29 UTC (permalink / raw)
To: Andi Kleen, acme-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Stephan Mueller, Anton Blanchard, Linux API
Hi Andi, Arnaldo,
Could you please review the revised recvmmsg.2 man page below.
Andi: I need to know what copyright and license to attach to the page
before I can release it.
Thanks,
Michael
---------- Forwarded message ----------
From: Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, Sep 15, 2011 at 6:15 AM
Subject: Re: Draft manpage for recvmmsg
To: Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
acme-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Stephan Mueller <stephan.mueller-fwYZOkdEjagAvxtiuMwx3w@public.gmane.org>, Anton
Blanchard <anton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>, Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
[CC list expanded]
Hi Andi, (and Arnaldo)
As noted in an earlier mail, I still need to know what copyright and
license to attach to the page before I can release it.
See below for further comments.
On Tue, Nov 23, 2010 at 11:15 AM, Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> wrote:
>
> Here's a draft manpage for recvmmsg(2), which is one
> of the last undocumented syscalls currently.
> Please review and comment.
>
> -Andi
>
>
> .TH RECVMMSG 2 2010-11-23 "Linux" "Linux Programmer's Manual"
> .SH NAME
> recvmmsg \- receive multiple messages on a socket
> .SH SYNOPSIS
> .BI "#include <sys/socket.h>"
> .br
> .BI "int recvmmsg(int " fd ", struct mmsghdr *" mmsghdr \
> ", unsigned int " vlen ","
> .br
> .BI " unsigned int " flags ", struct timespec *" timeout ");"
> .SH DESCRIPTION
> The
> .B recvmmsg
> system call receives multiple messages in a socket.
> It acts similar to
> .B recvmsg(2),
> but allows to batch multiple receive operations into a single syscall.
> In addition it support an explicit timeout.
>
> .B fd
> is the file descriptor of the socket to receive data from.
> .B mmsghdr
> is a pointer to an array with length
> .B vlen
> of
> .I mmsghdr
> structures.
> .I struct mmsg
> is defined in
> .I sys/socket.h
> as:
> .in +4n
> .nf
> struct mmsghdr {
> struct msghdr msg_hdr; /* Message header */
> unsigned int msg_len; /* Number of received bytes for header */
> };
> .fi
> .in
> .PP
> .B msg_hdr
> is a struct
> .I msghdr
> as described in
> .I recvmsg(2).
> .B msg_len
> is the number of bytes returned for the message in the entry.
> This field has the same value as the return value of a single
> .I recvmsg(2)
> on the header.
>
> .B flags
> contains flags ored together. The flags are the same
> as documented for
> .I recvmsg(2).
> The additional
> .B MSG_WAITFORONE
> turns one
> .I MSG_DONTWAIT
> after the first message has been received.
>
> .B timeout
> points to a
> .I struct timespec
> (see
> .I clock_gettime(2)
> )
> defining a timeout for receiving, or
> .I NULL
> for no timeout. When the timeout expires
> .I recvmmsg
> returns.
> .SH RETURN VALUE
> .I recvmmsg
> returns the number of messages received in
> .I mmsghdr
> or
> -1
> when an error occurs. The
> .I msg_len
> members of
> .I mmsghdr
> are updated for each received message,
> in addition to other fields in the msg_hdr for each message,
> as described in
> .I recvmsg(2).
> .SH SEE ALSO
> .B recvmsg(2),
> .B sendmsg(2),
> .B socket(7),
> .B socket(2),
> .B clock_gettime(2)
> .SH VERSIONS
> The
> .I recvmmsg
> syscall was added with kernel 2.6.32.
> Support in glibc was added with 2.6.12.
> On earlier glibcs the function can be called
> manually using
> .I syscall(2).
I reworked a number of pieces of text, and added several other pieces.
Could you please take a look (for others interested: "man -l <file>")
at the version below and let me know of inaccuracies
Thanks,
Michael
.TH RECVMMSG 2 2011-09-09 "Linux" "Linux Programmer's Manual"
.SH NAME
recvmmsg \- receive multiple messages on a socket
.SH SYNOPSIS
.nf
.B "#define _GNU_SOURCE"
.BI "#include <sys/socket.h>"
.BI "int recvmmsg(int " sockfd ", struct mmsghdr *" msgvec \
", unsigned int " vlen ","
.br
.BI " unsigned int " flags ", struct timespec *" timeout ");"
.fi
.SH DESCRIPTION
The
.BR recvmmsg ()
system call is an extension of
.BR recvmsg (2)
that allows the caller to receive multiple messages from a socket
using a single system call.
(This has performance benefits for some applications.)
A further extension over
.BR recvmsg (2)
is support for a timeout on the receive operation.
The
.I sockfd
argument is the file descriptor of the socket to receive data from.
The
.I msgvec
argument is a pointer to an array of
.I mmsghdr
structures.
The size of this array is specified in
.IR vlen .
The
.I mmsghdr
structure is defined in
.I <sys/socket.h>
as:
.in +4n
.nf
struct mmsghdr {
struct msghdr msg_hdr; /* Message header */
unsigned int msg_len; /* Number of received bytes for header */
};
.fi
.in
.PP
The
.I msg_hdr
field is a
.I msghdr
structure, as described in
.BR recvmsg (2).
The
.I msg_len
field is the number of bytes returned for the message in the entry.
This field has the same value as the return value of a single
.BR recvmsg (2)
on the header.
The
.I flags
argument contains flags ORed together.
The flags are the same as documented for
.BR recvmsg (2),
with the following addition:
.TP
.B MSG_WAITFORONE
Turns on
.B MSG_DONTWAIT
after the first message has been received.
.PP
The
.I timeout
argument points to a
.I struct timespec
(see
.BR clock_gettime (2))
defining a timeout (seconds plus nanoseconds) for the receive operation.
If
.I timeout
is
.I NULL
then the operation blocks indefinitely.
A blocking
.BR recvmmsg ()
call blocks until
.I vlen
messages have been received
or until the timeout expires.
A nonblocking call reads as many messages as are available
(up to the limit specified by
.IR vlen )
and returns immediately.
On return from
.BR recvmmsg (),
successive elements of
.IR msgvec
are updated to contain information about each received message:
.I msg_len
contains the size of the received message;
the subfields of
.I msg_hdr
are updated as described in
.BR recvmsg (2).
The return value of the call indicates the number of elements of
.I msgvec
that have been updated.
.SH RETURN VALUE
On success,
.BR recvmmsg ()
returns the number of messages received in
.IR msgvec ;
on error, \-1 is returned, and
.I errno
is set to indicate the error.
.SH ERRORS
Errors are as for
.BR recvmsg (2).
In addition, the following error can occur:
.TP
.B EINVAL
.I timeout
is invalid.
.SH VERSIONS
The
.BR recvmmsg ()
system call was added in Linux 2.6.32.
Support in glibc was added in version 2.12.
.SH CONFORMING TO
.BR recvmmsg ()
is Linux-specific.
.SH SEE ALSO
.BR clock_gettime (2),
.BR recvmsg (2),
.BR sendmmsg (2),
.BR sendmsg (2),
.BR socket (2),
.BR socket (7)
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
^ 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