* 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
* Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by default
From: David Miller @ 2011-09-28 17:30 UTC (permalink / raw)
To: eric.dumazet
Cc: tim.c.chen, zheng.z.yan, yanzheng, netdev, sfr, jirislaby,
sedat.dilek, alex.shi, Valdis.Kletnieks
In-Reply-To: <1316447547.2539.34.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 19 Sep 2011 17:52:27 +0200
> This patch includes SCM_CREDENTIALS information in a af_unix message/skb
> only if requested by the sender, [man 7 unix for details how to include
> ancillary data using sendmsg() system call]
>
> Note: This might break buggy applications that expected SCM_CREDENTIAL
> from an unaware write() system call, and receiver not using SO_PASSCRED
> socket option.
>
> If SOCK_PASSCRED is set on source or destination socket, we still
> include credentials for mere write() syscalls.
I thought a lot about this and I think we should be able to get away
with this trick, so I've added this patch to net-next, thanks!
^ permalink raw reply
* Re: [PATCH v2 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: Michał Mirosław @ 2011-09-28 17:32 UTC (permalink / raw)
To: David Daney; +Cc: devicetree-discuss, grant.likely, linux-kernel, netdev, davem
In-Reply-To: <4E8350A8.7090307@cavium.com>
W dniu 28 września 2011 18:51 użytkownik David Daney
<david.daney@cavium.com> napisał:
> 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.
This should use some generic name then. 'mdio-mux-gpio' or something.
There's no point in introducing chip's model for a gate-like discrete
device.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH net-next] net: rps: fix the support for PPPOE
From: David Miller @ 2011-09-28 17:35 UTC (permalink / raw)
To: xiaosuo; +Cc: netdev
In-Reply-To: <1316594167-12313-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 21 Sep 2011 16:36:07 +0800
> The upper protocol numbers of PPPOE are different, and should be treated
> specially.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: David Daney @ 2011-09-28 17:42 UTC (permalink / raw)
To: Michał Mirosław
Cc: devicetree-discuss, grant.likely, linux-kernel, netdev, davem
In-Reply-To: <CAHXqBF+ZVbCGEvnCcOtHk+sOWFLp1CuEnGLq+GEtHQTpu9PuYg@mail.gmail.com>
On 09/28/2011 10:32 AM, Michał Mirosław wrote:
> W dniu 28 września 2011 18:51 użytkownik David Daney
> <david.daney@cavium.com> napisał:
>> 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.
>
> This should use some generic name then. 'mdio-mux-gpio' or something.
> There's no point in introducing chip's model for a gate-like discrete
> device.
That could be. We could define an "mdio-mux-gpio" as something that
selects the child bus based on the binary encoded value presented on the
GPIO lines.
I will regenerate the patch set with this in mind. Note that the only
part of this patch that will change is this mdio-mux.txt file, no actual
code is affected. In patch 3/3 I will add "mdio-mux-gpio" to the
.of_match_table.
Thanks,
David Daney
^ permalink raw reply
* Re: [patch 1/1] connector: add comm change event report to proc connector
From: David Miller @ 2011-09-28 17:42 UTC (permalink / raw)
To: akpm; +Cc: netdev, vzapolskiy, zbr
In-Reply-To: <201109211926.p8LJQk0P007038@hpaq6.eem.corp.google.com>
From: akpm@google.com
Date: Wed, 21 Sep 2011 12:26:44 -0700
> From: Vladimir Zapolskiy <vzapolskiy@gmail.com>
> Subject: connector: add comm change event report to proc connector
>
> Add an event to monitor comm value changes of tasks. Such an event
> becomes vital, if someone desires to control threads of a process in
> different manner.
>
> A natural characteristic of threads is its comm value, and helpfully
> application developers have an opportunity to change it in runtime.
> Reporting about such events via proc connector allows to fine-grain
> monitoring and control potentials, for instance a process control daemon
> listening to proc connector and following comm value policies can place
> specific threads to assigned cgroup partitions.
>
> It might be possible to achieve a pale partial one-shot likeness without
> this update, if an application changes comm value of a thread generator
> task beforehand, then a new thread is cloned, and after that proc
> connector listener gets the fork event and reads new thread's comm value
> from procfs stat file, but this change visibly simplifies and extends the
> matter.
>
> Signed-off-by: Vladimir Zapolskiy <vzapolskiy@gmail.com>
> Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] can/sja1000: add driver for EMS PCMCIA card
From: David Miller @ 2011-09-28 17:42 UTC (permalink / raw)
To: socketcan; +Cc: netdev, wg, plessing, socketcan-core
In-Reply-To: <4E7CBB04.8070807@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Fri, 23 Sep 2011 18:59:48 +0200
> This patch adds the driver for the SJA1000 based PCMCIA card 'CPC-Card' from
> EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de).
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3] candev: allow SJW user setting for bittiming calculation
From: David Miller @ 2011-09-28 17:43 UTC (permalink / raw)
To: socketcan; +Cc: netdev, wg, socketcan-core
In-Reply-To: <4E831803.7020409@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Wed, 28 Sep 2011 14:50:11 +0200
> 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@hartkopp.net>
> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] net: sh_eth: use ioremap()
From: David Miller @ 2011-09-28 17:43 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: netdev, linux-sh
In-Reply-To: <4E82D16A.8090105@renesas.com>
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Wed, 28 Sep 2011 16:48:58 +0900
> This patch also changes writel/readl to iowrite32/ioread32.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] sh: modify prototype in sh_eth.h
From: David Miller @ 2011-09-28 17:43 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: lethal, linux-sh, netdev
In-Reply-To: <4E82D171.6060200@renesas.com>
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Wed, 28 Sep 2011 16:49:05 +0900
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] net: sh_eth: move the asm/sh_eth.h to include/linux/
From: David Miller @ 2011-09-28 17:43 UTC (permalink / raw)
To: yoshihiro.shimoda.uh; +Cc: lethal, netdev, linux-sh
In-Reply-To: <4E82D178.9020808@renesas.com>
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Wed, 28 Sep 2011 16:49:12 +0900
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied.
^ permalink raw reply
* Problem with ARP-replies on Kernels 2.6 (possibly 3.0, but not 2.4!)
From: skandranon @ 2011-09-28 17:49 UTC (permalink / raw)
To: netdev
Hi,
I sure hope that this is the right forum to find help with my problem.
If not, please someone provide me with a pointer!
Following up to a complaint, I found some strange behavior with ARP
replies being sent out for IP addresses via interfaces that have no
relation to the IP addresses being queried.
The setup is about as follows:
I have a machine connected to multiple physically disconnected networks,
neither doing any routing, bridging or anything similar.
MyMachine:eth0: 10.1.1.1/24
MyMachine:eth1: 192.168.1.2/24
MyMachine:eth2: 172.20.7.7/24
Network 10.1.1.0/24 is not controlled by me, and someone decided to
setup a Windows machine doing multinetworking:similar to
HisMachine:eth0: 10.1.1.15/24
HisMachine:eth0:0: 192.168.1.2/24
Now, HisMachine is detecting another server using IP address
192.168.1.2, and it is giving the MAC address of MyMachine:eth0 as the
offender.
Some investigation showed that MyMachine is responding to ARP-broadcasts
coming in on interface eth0 if those ARP packets have a source address
of either 0.0.0.0 or some IP address from 10.1.1.0/24 irrespective of
the IP address that is being queried:
example queries:
"ARP: who has 192.168.1.2 tell 0.0.0.0", received on MyMachine:eth0 =>
MyMachine sends a reply with the MAC-address of its eth0
"ARP: who has 192.168.1.2 tell 10.1.1.15", received on MyMachine:eth0 =>
MyMachine send a reply with the MAC-address of its eth0
"ARP: who has 192.168.1.2 tell 192.168.1.x" (x=1..254), received on
MyMachine:eth0 => no reply is being sent
Similar behaviour can be seen for other combination of IP addresses and
interfaces (e.g. "ARP: who has 10.1.1.1 tell 0.0.0.0" received on
interface eth1 would also be answered - via eth1, of course)
I've tested this using
arping -I <interface> -s <source> <IP address>
arping -I <interface> -D <IP address>
for several different systems (SuSE SLES 8- 2.421, SuSE SLES 9 - 2.6.5,
SuSE SLES 10 - 2.6.16, SuSE SLES 11 - 2.6.32, Open Suse 11.3 - 2.6.34,
OpenSuSE 11.4 - 2.6.37, several different Ubuntu versions...),
and found that any 2.6-based system displayed similar behaviour, but not
the old 2.4-based ones.
Basically, I would have expected MyMachine to answer ARP queries
received via eth0 only if an address was queried that was assigned to
eth0 (also secondary IP addresses assigned by "ip" or virtual interfaces
generated by ifconfig).
So: Is this a bug or a feature?
In any case: many thanks to each of you developers (but for you, I
wouldn't have my current job), and also many thanks to each of you
taking the time to answer questions on this list!
Best Regards,
Frank Mayer
^ permalink raw reply
* Re: ICMP redirect issue
From: David Miller @ 2011-09-28 18:06 UTC (permalink / raw)
To: fbl; +Cc: netdev
In-Reply-To: <20110927162120.30394030@asterix.rh>
From: Flavio Leitner <fbl@redhat.com>
Date: Tue, 27 Sep 2011 16:21:20 -0300
> The issue is about the gateway being a LVS, so the servers behind use
> the IP alias address as the default gateway. However, when the gateway
> sends an ICMP redirect, it comes from the primary IP address which is
> ignored on older kernels because of the old_gw check:
>
> - if (rth->rt_dst != daddr ||
> - rth->rt_src != saddr ||
> - rth->dst.error ||
> - rth->rt_gateway != old_gw ||
> - rth->dst.dev != dev)
> - break;
>
>
> Well, the consequence is that the issue doesn't happen in newer kernels
> because it happily accepts the ICMP redirect.
>
> The admin can still control using shared_media and secure_redirects if
> the host should accept only the ICMP redirects for gateways listed in
> default gateway list or not.
Unfortunately, shared_media is on by default which means the default
secure_redirects setting of '1' is ignored.
This means that redirects can be spoofed in the default configuration,
but with the above check they would not be spoofable.
I suspect that, because of this, we'll need to add the check back. Or
do something similar.
We can't "fix" this by turning shared_media off by default because that
changes behavior on input route processing wrt. how we decide whether
to emit a redirect or not.
^ permalink raw reply
* Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X
From: Sasha Levin @ 2011-09-28 18:30 UTC (permalink / raw)
To: Rusty Russell
Cc: Michael S. Tsirkin, linux-kernel, virtualization, netdev, kvm
In-Reply-To: <874o09x97m.fsf@rustcorp.com.au>
On Mon, 2011-09-19 at 17:19 +0930, Rusty Russell wrote:
> On Mon, 19 Sep 2011 09:01:50 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Mon, Sep 19, 2011 at 01:05:17PM +0930, Rusty Russell wrote:
> > > On Sat, 20 Aug 2011 23:00:44 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > On Fri, Aug 19, 2011 at 07:33:07PM +0300, Sasha Levin wrote:
> > > > > Maybe this is better solved by copying the way it was done in PCI itself
> > > > > with capability linked list?
> > > >
> > > > There are any number of ways to lay out the structure. I went for what
> > > > seemed a simplest one. For MSI-X the train has left the station. We
> > > > can probably still tweak where the high 32 bit features
> > > > for 64 bit features are. No idea if it's worth it.
> > >
> > > Sorry, this has been in the back of my mind. I think it's a good idea;
> > > can we use the capability linked list for pre-device specific stuff from
> > > now on?
> > >
> > > Thanks,
> > > Rusty.
> >
> > Do we even want capability bits then?
> > We can give each capability an ack flag ...
>
> We could have, and if I'd known PCI when I designed virtio I might have.
>
> But it's not easy now to map structure offsets to that scheme, and we
> can't really force such a change on the non-PCI users. So I'd say we
> should only do it for the non-device-specific options. ie. we'll still
> have the MSI-X case move the device-specific config, but we'll use a
> linked list from now on, eg. for the next 32 features bits...
>
> Thoughts?
> Rusty.
What if we create a capability list but place it in the virtio-pci
config space instead of the PCI space?
It'll work fine with non-PCI users and would leave MSI-X as the only
thing that changes offsets (and we could probably deprecate and remove
it at some point in the future).
--
Sasha.
^ permalink raw reply
* Re: Possible NULL dereference caused by -stable commit ef81bb40bf15f350fe865f31fa42f1082772a576
From: David Miller @ 2011-09-28 18:32 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
> 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()
Ok, after some auditing, there is only one call site of ipv6_select_ident()
that can happen with a NULL route and that is udp6_ufo_fragment().
ipv6_gso_segment() already walks the extension headers via
ipv6_gso_pull_exthdrs() so maybe we can calculate the true destination
address there and get that passed down somehow into the fragment ID
selection for an inetpeer lookup.
^ permalink raw reply
* 82574 DMA Burst Mode Enablement
From: Denis Radovanovic @ 2011-09-28 18:39 UTC (permalink / raw)
To: bruce.w.allan@intel.com, jeffrey.t.kirsher@intel.com
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Prasanna Panchamukhi
[-- Attachment #1.1: Type: text/plain, Size: 583 bytes --]
Hi,
We are currently testing small packet performance on 82574, comparing it to 82571. Initial pktgen measurements have shown a significant difference in performance that is the most visible when running bidirectional traffic with 256 byte packets.
Looking at the e1000e driver, we noticed that flag FLAG2_DMA_BURST is enabled for 82571 and 82572 but it is not enabled for 82574. After enabling the flag, the 82574 performance significantly improved, approaching the one on 82571.
Is there a reason that this flag is not enabled for 82574?
Thank you,
Denis Radovanovic
[-- Attachment #2: Type: text/plain, Size: 378 bytes --]
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [GIT PULL net-next] IPVS
From: Pablo Neira Ayuso @ 2011-09-28 19:13 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?
http://1984.lsi.us.es/git/?p=net-next/.git;a=shortlog;h=refs/heads/nf-next
I have added these five patches to the nf-next branch of our temporary
tree.
^ permalink raw reply
* Re: [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: Steve Wise @ 2011-09-28 20:03 UTC (permalink / raw)
To: Jonathan Lallinger; +Cc: David Miller, netdev
In-Reply-To: <4E82075B.9000003@opengridcomputing.com>
On 09/27/2011 12:26 PM, Jonathan Lallinger wrote:
> Hello David,
>
> I am ashamed I made the same mistake twice. This happened because I had two git trees (I made a second one when
> kernel.org went down based off the github remote). I fixed, built, and ran several tests on the patch, and then sent
> the wrong patch from an old git tree (which was never build tested).
>
> I can assure you I have a working patch, and it has been tested by the QA group at Chelsio and it builds/runs but
> there are still additional bugs in rds. So once I resolve those I will resend the correct patch with some additional
> fixes.
Hey Jonathan,
I think you should get this patch resubmitted as-is (the correct patch though ;). If we hit other issues in testing,
then we can submit more patches. The problems Chelsio is seeing may be backport issues and not upstream bugs.
Steve.
^ permalink raw reply
* Re: Problem with ARP-replies on Kernels 2.6 (possibly 3.0, but not 2.4!)
From: Nicolas de Pesloüan @ 2011-09-28 20:07 UTC (permalink / raw)
To: skandranon; +Cc: netdev
In-Reply-To: <4E835E35.3030503@gmx.at>
Le 28/09/2011 19:49, skandranon a écrit :
> Basically, I would have expected MyMachine to answer ARP queries received via eth0 only if an
> address was queried that was assigned to eth0 (also secondary IP addresses assigned by "ip" or
> virtual interfaces generated by ifconfig).
>
> So: Is this a bug or a feature?
It is a feature.
You should have a look at the file Documentation/networking/ip-sysctl in the kernel source tree, in
particular the entry about arp_ignore.
Nicolas.
^ permalink raw reply
* Re: ICMP redirect issue
From: Flavio Leitner @ 2011-09-28 20:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110928.140632.726302773135946390.davem@davemloft.net>
On Wed, 28 Sep 2011 14:06:32 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Flavio Leitner <fbl@redhat.com>
> Date: Tue, 27 Sep 2011 16:21:20 -0300
>
> > The issue is about the gateway being a LVS, so the servers behind
> > use the IP alias address as the default gateway. However, when the
> > gateway sends an ICMP redirect, it comes from the primary IP
> > address which is ignored on older kernels because of the old_gw
> > check:
> >
> > - if (rth->rt_dst != daddr ||
> > - rth->rt_src != saddr ||
> > - rth->dst.error ||
> > - rth->rt_gateway != old_gw ||
> > - rth->dst.dev != dev)
> > - break;
> >
> >
> > Well, the consequence is that the issue doesn't happen in newer
> > kernels because it happily accepts the ICMP redirect.
> >
> > The admin can still control using shared_media and secure_redirects
> > if the host should accept only the ICMP redirects for gateways
> > listed in default gateway list or not.
>
> Unfortunately, shared_media is on by default which means the default
> secure_redirects setting of '1' is ignored.
>
> This means that redirects can be spoofed in the default configuration,
> but with the above check they would not be spoofable.
I fail to see what that check is preventing because if someone manages
to inject a redirect packet into the network, then likely the old_gw can
be tweaked to be the network gateway.
> I suspect that, because of this, we'll need to add the check back. Or
> do something similar.
>
> We can't "fix" this by turning shared_media off by default because
> that changes behavior on input route processing wrt. how we decide
> whether to emit a redirect or not.
What about something like below? It will change a bit the
secure_redirects documentation.
shared_media secure_redirect behavior:
0 0 all pass.
0 1 only from gateways and for gateways.
1 0 all pass.
1 1 default, old behavior, only from
gateways.
If you agree with the approach, I'll run tests here and post
the patch with a proper changelog, documentation and signed-off.
thanks,
fbl
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 075212e..fa00fcd 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1332,6 +1332,9 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw,
goto reject_redirect;
}
+ if (IN_DEV_SEC_REDIRECTS(in_dev) && ip_fib_check_default(old_gw, dev))
+ goto reject_redirect;
+
peer = inet_getpeer_v4(daddr, 1);
if (peer) {
peer->redirect_learned.a4 = new_gw;
^ permalink raw reply related
* Re: [PATCH] Fix repeatable Oops on container destroy with conntrack
From: Pablo Neira Ayuso @ 2011-09-28 21:08 UTC (permalink / raw)
To: Alex Bligh
Cc: Alexey Dobriyan, netfilter-devel, linux-kernel, containers,
Linux Containers, netdev
In-Reply-To: <A51A04647674405AF6C39A4F@nimrod.local>
On Wed, Sep 14, 2011 at 09:01:34AM +0100, Alex Bligh wrote:
> --On 14 September 2011 03:35:00 +0200 Pablo Neira Ayuso
> <pablo@netfilter.org> wrote:
>
> >>Is this new version OK? I am happy to adjust if not.
> >
> >Hm, I still think that this is a workaround.
>
> It is a bit of a workaround, that is true. But it is a workaround
> that will fix the bug in every kernel since 2.6.32 (and perhaps
> before - I haven't looked). It's thus reasonably easily applicable
> to stable kernel series.
The container support for netfilter seems to be in intermediate state,
we need several patches to get it finished that:
* subsys_table definition in nfnetlink.c.
* ctnl_notifier and ctnl_notifier_exp definitions in
nfnetlink_conntrack.c
* similar things for nfnetlink_queue and nfnetlink_log.
If nobody is going to fix all these, I'll find some spare time to do
it myself, but I don't think we'll have a proper fix that we can pass
to -stable. This will have to go to net-next, given the amount of
patches that we'll need to appropriately fix this.
> I'm not clued-up enough on Netfilter to know what the right fix is,
> but is applying the workaround in a commit which could be easily
> backported, then applying the 'right fix' (assuming that is different)
> a reasonable strategy?
>
> As you can probably tell, my interest here is to get something that
> doesn't oops into stable kernels.
As said, I'm not sure that this can happen, given that the amount of
patches that we need to fix it fine, sorry.
^ permalink raw reply
* Re: [PATCH RFC v2 0/5] netfilter reverse path filter matches
From: Pablo Neira Ayuso @ 2011-09-28 21:18 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel, netdev, davem
In-Reply-To: <1315856552-1422-1-git-send-email-fw@strlen.de>
On Mon, Sep 12, 2011 at 09:42:27PM +0200, Florian Westphal wrote:
> Version 2 of the ipv4/v6 reverse path filter matches discussed during
> nfws 2011.
>
> The ipv4 match (ipt_rpfilter) tries to do exactly what the current
> fib_validate_source does. The main problem with this is that
> we need to do an additional fib lookup to get the oif in the match.
> [ delaying until FORWARD is invoked is not possible because by
> that point the stack might have already sent icmp errors ].
>
> Patrick McHardy suggested to simply attach the result as the dst, so
> ipv4 input path doesn't have to do it again.
>
> This works, but does have a few side effects wrt. route-by-mark and
> TPROXY, see patch changelog for details.
>
> The ipv6 version does a pure 'reverse' lookup instead. This makes
> things a lot easier (e.g. when multiple route entries exist), but has
> the caveat that a real reply packet might be handled differently due to
> policy routing rules.
>
> Userspace part is stored in my iptables repository on
> http://git.breakpoint.cc/cgi-bin/gitweb.cgi?p=fw/iptables.git (branch 'rpfilter').
>
> Kernel patches are located in the 'xt_rpfilter_5' branch on
> http://git.breakpoint.cc/cgi-bin/gitweb.cgi?p=fw/nf-next.git
> (patches will be sent as followup to this email).
>
> [ in case you are wondering: the earlier xt_rpfilter version was
> removed -- causes too many module dependency issues and most of the
> code cannot be shared anyway ].
This involves other net changes, I'd like to get an ack from David
before applying this. Or let me know if it's better to follow the
netdev path.
^ permalink raw reply
* Re: [PATCH RFC v2 0/5] netfilter reverse path filter matches
From: Florian Westphal @ 2011-09-28 21:23 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Florian Westphal, netfilter-devel, netdev, davem
In-Reply-To: <20110928211847.GC2761@1984>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Kernel patches are located in the 'xt_rpfilter_5' branch on
> > http://git.breakpoint.cc/cgi-bin/gitweb.cgi?p=fw/nf-next.git
> > (patches will be sent as followup to this email).
> >
> > [ in case you are wondering: the earlier xt_rpfilter version was
> > removed -- causes too many module dependency issues and most of the
> > code cannot be shared anyway ].
>
> This involves other net changes, I'd like to get an ack from David
> before applying this. Or let me know if it's better to follow the
> netdev path.
Pablo, please do not apply these patches, I have newer versions
available.
David, it would be nice if you could indicate how these patches
should be merged (ie. via net-next or netfilter-next).
[ in case there are objections, I'd like to hear about those too :-) ]
Thanks,
Florian
^ permalink raw reply
* Re: [GIT PULL net-next] IPVS
From: Pablo Neira Ayuso @ 2011-09-28 21:45 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, 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?
Thinking it well, and given that you'll have to send me more patches,
I think it's a good idea if you rebase.
BTW, please no need to Cc netfilter@vger.kernel.org, that list is for
netfilter users, not for developers.
^ permalink raw reply
* Re: [PATCH] iwlagn: iwl-agn-rs: remove unnecessary null check for sta and lq_sta
From: Guy, Wey-Yi @ 2011-09-28 22:18 UTC (permalink / raw)
To: Gregory.Dietsche@cuw.edu
Cc: ilw@linux.intel.com, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1317250444-2248-1-git-send-email-Gregory.Dietsche@cuw.edu>
On Wed, 2011-09-28 at 15:54 -0700, Gregory.Dietsche@cuw.edu wrote:
> From: Greg Dietsche <Gregory.Dietsche@cuw.edu>
>
> both sta and lq_sta are guaranteed to be not null in the
> calling function so we don't need to check them here.
>
> Signed-off-by: Greg Dietsche <Gregory.Dietsche@cuw.edu>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
you are correct
Wey
^ 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