* 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: [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
* 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: 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
* 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: 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
* 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: [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
* 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 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 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 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 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 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 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: 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 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: 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: 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: 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: [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: [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: 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: 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: [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
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