* Re: [patch] 9p: fix min_t() casting
From: Dan Carpenter @ 2011-01-16 11:45 UTC (permalink / raw)
To: David Miller
Cc: ericvh, sripathik, jvrao, aneesh.kumar, netdev, kernel-janitors,
mohan
In-Reply-To: <20110115.205208.104051310.davem@davemloft.net>
On Sat, Jan 15, 2011 at 08:52:08PM -0800, David Miller wrote:
> From: Dan Carpenter <error27@gmail.com>
> Date: Sat, 15 Jan 2011 23:35:39 +0300
>
> > The intent here was to cap the length to USHRT_MAX, but what the
> > code actually does is it just casts the return from strlen() to
> > unsigned short and truncates the significant bits away.
> >
> > Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> If you want me to apply this, it doesn't apply cleanly to net-2.6
> at all.
Sorry. I screwed up.
This was on top of a patch from M. Mohan Kumar <mohan@in.ibm.com>
that hasn't hit net-2.6 yet. Mohan wasn't included on the CC
list because get_maintainer.pl changed and I didn't notice and
I wasn't careful.
Eric, could Mohan just fix his patch before it gets merged or is it
better to send these as two patches?
regards,
dan carpenter
Ps: Mohon the patch is here:
http://marc.info/?l=linux-netdev&m=129512381528034&w=2
^ permalink raw reply
* Re: inbound connection problems when "netlink: test for all flags of the NLM_F_DUMP composite" commit applied
From: Arthur Marsh @ 2011-01-16 12:39 UTC (permalink / raw)
To: Linux Networking Developer Mailing List
In-Reply-To: <alpine.LNX.2.01.1101161144350.8081@obet.zrqbmnf.qr>
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
Jan Engelhardt wrote, on 16/01/11 21:20:
>
> Le dimanche 16 janvier 2011 à 19:24 +1030, Arthur Marsh a écrit :
>>
>>> With kernels up to and including 2.6.37-git7, inbound telnetd-ssl
>>> connections worked fine. With kernel 2.6.37-git9 and later inbound
>>> telnetd-ssl connections failed, and on machine shut-down, there
>>> were warning messages about daemons not return status.
>
> Which daemons are these? For reference, what distro do you happen
> to use?
avahi-daemon (which gave multiple warning messages, hence I thought it
may have been multiple packages)
I'm running Debian unstable with kernel.org kernels.
>
>>> commit 0ab03c2b1478f2438d2c80204f7fef65b1bca9cf
>>> netlink: test for all flags of the NLM_F_DUMP composite
>
> Each of the hunks in this commit is independent of another.
> Would you mind bisecting these too?
Recompiling with the only the first patch (attached) resulted in a
repeat of the problem.
Arthur.
[-- Attachment #2: netlink1.patch --]
[-- Type: text/x-patch, Size: 489 bytes --]
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 750db57..a5f7535 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1820,7 +1820,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
if (kind != 2 && security_netlink_recv(skb, CAP_NET_ADMIN))
return -EPERM;
- if (kind == 2 && nlh->nlmsg_flags&NLM_F_DUMP) {
+ if (kind == 2 && (nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP) {
struct sock *rtnl;
rtnl_dumpit_func dumpit;
^ permalink raw reply related
* 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX
From: Simon Arlott @ 2011-01-16 14:09 UTC (permalink / raw)
To: netdev, Linux Kernel Mailing List; +Cc: jesse
[ 1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
[ 1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3
I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
to receive packets. Using tcpdump on eth0 shows the packets being
received with a VLAN tag but they don't appear on eth0.3840. They appear
with the VLAN tag on the bridge interface.
If I remove eth0 from the bridge, eth0.3840 starts working again. It
still works if eth0.3840 is part of a bridge but eth0 isn't (the device
is in promiscuous mode). I've only tested with broadcast traffic.
This works with 2.6.36.
git bisect produces 3701e51382a026cba10c60b03efabe534fba4ca4 as the
first bad commit.
The behaviour of drivers/net/forcedeth.c nv_rx_process_optimized looks
ok - vlan_gro_receive and napi_gro_receive are called correctly. (The
likely(!np->vlangrp) looks odd as it'll always be false if vlans are in
use).
--
Simon Arlott
^ permalink raw reply
* Creating virtual interface using C++
From: Chin Shi Hong @ 2011-01-16 14:37 UTC (permalink / raw)
To: netdev
Dear All,
Can someone give me suggestion for C++ codes that will create a
virtual network interface for the existing network interface
(including wired and wireless network interface)?
Regards,
^ permalink raw reply
* Re: Creating virtual interface using C++
From: Rémi Denis-Courmont @ 2011-01-16 14:43 UTC (permalink / raw)
To: Chin Shi Hong; +Cc: netdev
In-Reply-To: <AANLkTikcHuHGD4eEmuZr4+p9MSLbySmQwsr_Dj==AZ-y@mail.gmail.com>
Hello,
Le dimanche 16 janvier 2011 16:37:05 Chin Shi Hong, vous avez écrit :
> Can someone give me suggestion for C++ codes that will create a
> virtual network interface
It depends what you mean by virtual. Normally, you should use /dev/net/tun
which is documented at linux-2.6/Documentation/networking/tuntap.txt
> for the existing network interface
> (including wired and wireless network interface)?
But that part of your question does not make any sense.
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: Creating virtual interface using C++
From: Chin Shi Hong @ 2011-01-16 15:26 UTC (permalink / raw)
To: Rémi Denis-Courmont; +Cc: netdev
In-Reply-To: <201101161643.15508.remi@remlab.net>
2011/1/16 Rémi Denis-Courmont <remi@remlab.net>:
> Hello,
>
> Le dimanche 16 janvier 2011 16:37:05 Chin Shi Hong, vous avez écrit :
>> Can someone give me suggestion for C++ codes that will create a
>> virtual network interface
>
> It depends what you mean by virtual. Normally, you should use /dev/net/tun
> which is documented at linux-2.6/Documentation/networking/tuntap.txt
>
>> for the existing network interface
>> (including wired and wireless network interface)?
>
> But that part of your question does not make any sense.
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
> http://fi.linkedin.com/in/remidenis
>
Don't know how to explain by virtual. But, you know the "iw" utility
(http://wireless.kernel.org/en/users/Documentation/iw)? If you
installed this utility, and then run the command "sudo iw dev
<wireless interface> interface add <virtual interface name> type
<wireless mode>", for example "sudo iw dev wlan0 interface add mon0
type monitor", it will add an virtual wireless interface named "mon0"
for the wireless interface "wlan0", then switch it to monitor mode. if
you run that command, you will know what I mean.
^ permalink raw reply
* Re: [patch] 9p: fix min_t() casting
From: Eric Van Hensbergen @ 2011-01-16 16:33 UTC (permalink / raw)
To: Dan Carpenter
Cc: David Miller, sripathik, jvrao, aneesh.kumar, netdev,
kernel-janitors, mohan
In-Reply-To: <20110116114526.GG2721@bicker>
The patch has already made it upstream via the v9fs pull. I'll pull
in your fix Dan and request a second pull by Linus.
Thanks for catching this.
-eric
On Sun, Jan 16, 2011 at 5:45 AM, Dan Carpenter <error27@gmail.com> wrote:
> On Sat, Jan 15, 2011 at 08:52:08PM -0800, David Miller wrote:
>> From: Dan Carpenter <error27@gmail.com>
>> Date: Sat, 15 Jan 2011 23:35:39 +0300
>>
>> > The intent here was to cap the length to USHRT_MAX, but what the
>> > code actually does is it just casts the return from strlen() to
>> > unsigned short and truncates the significant bits away.
>> >
>> > Signed-off-by: Dan Carpenter <error27@gmail.com>
>>
>> If you want me to apply this, it doesn't apply cleanly to net-2.6
>> at all.
>
> Sorry. I screwed up.
>
> This was on top of a patch from M. Mohan Kumar <mohan@in.ibm.com>
> that hasn't hit net-2.6 yet. Mohan wasn't included on the CC
> list because get_maintainer.pl changed and I didn't notice and
> I wasn't careful.
>
> Eric, could Mohan just fix his patch before it gets merged or is it
> better to send these as two patches?
>
> regards,
> dan carpenter
>
> Ps: Mohon the patch is here:
> http://marc.info/?l=linux-netdev&m=129512381528034&w=2
>
^ permalink raw reply
* Re: panic in tg3 driver
From: Stephen Clark @ 2011-01-16 18:11 UTC (permalink / raw)
To: sclark46; +Cc: Matt Carlson, Linux Kernel Network Developers, Michael Chan
In-Reply-To: <4D2EFA44.8080008@earthlink.net>
On 01/13/2011 08:12 AM, Stephen Clark wrote:
> On 01/11/2011 10:06 PM, Matt Carlson wrote:
>> lspci -vvv -xxx -s 81:00.0
>
>
>
> Further information - I found these messages in /var/log/messages. It
> looks
> like after it switched to INTx mode interrupts for other devices were
> hosed.
>
> Jan 12 08:37:49 localhost kernel: tg3 0000:81:00.0: eth2: No interrupt
> was gener
> ated using MSI. Switching to INTx mode. Please report this failure to
> the PCI ma
> intainer and include system chipset information
> Jan 12 08:37:49 localhost kernel: ADDRCONF(NETDEV_UP): eth2: link is
> not ready
> Jan 12 08:38:50 localhost kernel: ata2: lost interrupt (Status 0x50)
> Jan 12 08:38:50 localhost kernel: ata2.01: exception Emask 0x0 SAct
> 0x0 SErr 0x0
> action 0x6 frozen
> Jan 12 08:38:50 localhost kernel: ata2.01: failed command: WRITE DMA
> Jan 12 08:38:50 localhost kernel: ata2.01: cmd
> ca/00:08:e0:bc:51/00:00:00:00:00/f0 tag 0 dma 4096 out
> Jan 12 08:38:50 localhost kernel: res
> 40/00:01:00:4f:c2/00:00:00:00:00/b0 Emask 0x4 (timeout)
> Jan 12 08:38:50 localhost kernel: ata2.01: status: { DRDY }
> Jan 12 08:38:50 localhost kernel: ata2: soft resetting link
> Jan 12 08:38:50 localhost kernel: do_IRQ: 0.64 No irq handler for
> vector (irq -1)
> Jan 12 08:38:50 localhost kernel: ata2.01: configured for UDMA/33
> Jan 12 08:38:54 localhost pppd[1983]: No response to 3 echo-requests
> Jan 12 08:39:55 localhost pppoe[1988]: Inactivity timeout... something
> wicked happened on session 3363
Just checking to make sure you have everything you need?
Thanks,
Steve
^ permalink raw reply
* Re: Realtek r8168C / r8169 driver VLAN TAG stripping
From: Francois Romieu @ 2011-01-16 19:20 UTC (permalink / raw)
To: Anand Raj Manickam; +Cc: netdev
In-Reply-To: <AANLkTimqkJ3DGBX5iREEcx6sgAM+2CZHNWMU+noNSitp@mail.gmail.com>
Anand Raj Manickam <anandrm@gmail.com> :
[...]
> This happens on a Linux 2.6.30.8 kernel .The driver is in-kernel.
I do not notice it with my 8168c (XID 18000000) on a modular 2.6.37-git.
Can you send the XID of the r8169 that appears in the log of your kernel
and upgrade to a more recent kernel ?
--
Ueimor
^ permalink raw reply
* Re: inbound connection problems when "netlink: test for all flags of the NLM_F_DUMP composite" commit applied
From: Pablo Neira Ayuso @ 2011-01-16 21:17 UTC (permalink / raw)
To: Arthur Marsh; +Cc: Jan Engelhardt, Eric Dumazet, Linux Netdev List
In-Reply-To: <4D32E3BA.5040008@internode.on.net>
[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]
On 16/01/11 13:25, Arthur Marsh wrote:
> Jan Engelhardt wrote, on 16/01/11 21:20:
>>
>> Le dimanche 16 janvier 2011 à 19:24 +1030, Arthur Marsh a écrit :
>>>
>>>> With kernels up to and including 2.6.37-git7, inbound telnetd-ssl
>>>> connections worked fine. With kernel 2.6.37-git9 and later inbound
>>>> telnetd-ssl connections failed, and on machine shut-down, there
>>>> were warning messages about daemons not return status.
>>
>> Which daemons are these? For reference, what distro do you happen
>> to use?
>
> avahi-daemon (which gave multiple warning messages, hence I thought it
> may have been multiple packages)
>
> I'm running Debian unstable with kernel.org kernels.
>
>>
>>>> commit 0ab03c2b1478f2438d2c80204f7fef65b1bca9cf
>>>> netlink: test for all flags of the NLM_F_DUMP composite
>>
>> Each of the hunks in this commit is independent of another.
>> Would you mind bisecting these too?
>
> Recompiling with the only the first patch (attached) resulted in a
> repeat of the problem.
>
> I've removed one person from the cc: list as they did not want to
> receive email about this even though they signed off the commit.
Please, pass this patch to the avahi-daemon developers. They use an
invalid netlink flag combination for dump operations.
This patch has spotted a problem that they have to fix indeed.
[-- Attachment #2: fix-netlink-in-avahi.patch --]
[-- Type: text/x-patch, Size: 1687 bytes --]
avahi: fix wrong use of netlink flags for dump operations
The avahi-daemon uses a wrong flag combination to operate with
rtnetlink. This patch fixes the problems.
No need to set NLM_F_ACK since the dump operation already includes
the trailing NLMSG_DONE message that informs about the end of the
dump operation.
Please, consider porting the avahi-daemon to libmnl:
http://www.netfilter.org/projects/libmnl/index.html
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Index: avahi-0.6.27/avahi-autoipd/iface-linux.c
===================================================================
--- avahi-0.6.27.orig/avahi-autoipd/iface-linux.c 2011-01-16 22:06:20.000000000 +0100
+++ avahi-0.6.27/avahi-autoipd/iface-linux.c 2011-01-16 22:07:34.000000000 +0100
@@ -262,7 +262,7 @@ int iface_get_initial_state(State *state
n->nlmsg_len = NLMSG_LENGTH(sizeof(*ifi));
n->nlmsg_type = RTM_GETLINK;
n->nlmsg_seq = seq;
- n->nlmsg_flags = NLM_F_MATCH|NLM_F_REQUEST|NLM_F_ACK;
+ n->nlmsg_flags = NLM_F_REQUEST|NLM_F_DUMP;
n->nlmsg_pid = 0;
ifi = NLMSG_DATA(n);
Index: avahi-0.6.27/avahi-core/iface-linux.c
===================================================================
--- avahi-0.6.27.orig/avahi-core/iface-linux.c 2011-01-16 22:06:51.000000000 +0100
+++ avahi-0.6.27/avahi-core/iface-linux.c 2011-01-16 22:07:08.000000000 +0100
@@ -53,7 +53,7 @@ static int netlink_list_items(AvahiNetli
n = (struct nlmsghdr*) req;
n->nlmsg_len = NLMSG_LENGTH(sizeof(struct rtgenmsg));
n->nlmsg_type = type;
- n->nlmsg_flags = NLM_F_ROOT|NLM_F_REQUEST;
+ n->nlmsg_flags = NLM_F_REQUEST|NLM_F_DUMP;
n->nlmsg_pid = 0;
gen = NLMSG_DATA(n);
^ permalink raw reply
* Re: [PATCH] net_sched: accurate bytes/packets stats/rates
From: Jarek Poplawski @ 2011-01-16 22:35 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Eric Dumazet, David Miller, netdev, Patrick McHardy, jamal
In-Reply-To: <20110114110342.4d95ad5b@nehalam>
On Fri, Jan 14, 2011 at 11:03:42AM -0800, Stephen Hemminger wrote:
> From Eric Dumazet <eric.dumazet@gmail.com>
>
> In commit 44b8288308ac9d (net_sched: pfifo_head_drop problem), we fixed
> a problem with pfifo_head drops that incorrectly decreased
> sch->bstats.bytes and sch->bstats.packets
>
> Several qdiscs (CHOKe, SFQ, pfifo_head, ...) are able to drop a
> previously enqueued packet, and bstats cannot be changed, so
> bstats/rates are not accurate (over estimated)
>
> This patch changes the qdisc_bstats updates to be done at dequeue() time
> instead of enqueue() time. bstats counters no longer account for dropped
> frames, and rates are more correct, since enqueue() bursts dont have
> effect on dequeue() rate.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
>
> CC: Patrick McHardy <kaber@trash.net>
> CC: Jarek Poplawski <jarkao2@gmail.com>
> CC: jamal <hadi@cyberus.ca>
...
> --- a/net/sched/sch_drr.c 2011-01-14 09:19:00.830857886 -0800
> +++ b/net/sched/sch_drr.c 2011-01-14 09:28:20.398631228 -0800
> @@ -376,7 +376,6 @@ static int drr_enqueue(struct sk_buff *s
> }
>
> bstats_update(&cl->bstats, skb);
Why leave leaf classes with different stats?
Jarek P.
> - qdisc_bstats_update(sch, skb);
>
> sch->q.qlen++;
> return err;
...
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Simon Horman @ 2011-01-16 22:37 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jesse Gross, Eric Dumazet, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110114065415.GA30300@redhat.com>
On Fri, Jan 14, 2011 at 08:54:15AM +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 14, 2011 at 03:35:28PM +0900, Simon Horman wrote:
> > On Fri, Jan 14, 2011 at 06:58:18AM +0200, Michael S. Tsirkin wrote:
> > > On Fri, Jan 14, 2011 at 08:41:36AM +0900, Simon Horman wrote:
> > > > On Thu, Jan 13, 2011 at 10:45:38AM -0500, Jesse Gross wrote:
> > > > > On Thu, Jan 13, 2011 at 1:47 AM, Simon Horman <horms@verge.net.au> wrote:
> > > > > > On Mon, Jan 10, 2011 at 06:31:55PM +0900, Simon Horman wrote:
> > > > > >> On Fri, Jan 07, 2011 at 10:23:58AM +0900, Simon Horman wrote:
> > > > > >> > On Thu, Jan 06, 2011 at 05:38:01PM -0500, Jesse Gross wrote:
> > > > > >> >
> > > > > >> > [ snip ]
> > > > > >> > >
> > > > > >> > > I know that everyone likes a nice netperf result but I agree with
> > > > > >> > > Michael that this probably isn't the right question to be asking. I
> > > > > >> > > don't think that socket buffers are a real solution to the flow
> > > > > >> > > control problem: they happen to provide that functionality but it's
> > > > > >> > > more of a side effect than anything. It's just that the amount of
> > > > > >> > > memory consumed by packets in the queue(s) doesn't really have any
> > > > > >> > > implicit meaning for flow control (think multiple physical adapters,
> > > > > >> > > all with the same speed instead of a virtual device and a physical
> > > > > >> > > device with wildly different speeds). The analog in the physical
> > > > > >> > > world that you're looking for would be Ethernet flow control.
> > > > > >> > > Obviously, if the question is limiting CPU or memory consumption then
> > > > > >> > > that's a different story.
> > > > > >> >
> > > > > >> > Point taken. I will see if I can control CPU (and thus memory) consumption
> > > > > >> > using cgroups and/or tc.
> > > > > >>
> > > > > >> I have found that I can successfully control the throughput using
> > > > > >> the following techniques
> > > > > >>
> > > > > >> 1) Place a tc egress filter on dummy0
> > > > > >>
> > > > > >> 2) Use ovs-ofctl to add a flow that sends skbs to dummy0 and then eth1,
> > > > > >> this is effectively the same as one of my hacks to the datapath
> > > > > >> that I mentioned in an earlier mail. The result is that eth1
> > > > > >> "paces" the connection.
> > >
> > > This is actually a bug. This means that one slow connection will affect
> > > fast ones. I intend to change the default for qemu to sndbuf=0 : this
> > > will fix it but break your "pacing". So pls do not count on this
> > > behaviour.
> >
> > Do you have a patch I could test?
>
> You can (and users already can) just run qemu with sndbuf=0. But if you
> like, below.
Thanks
> > > > > > Further to this, I wonder if there is any interest in providing
> > > > > > a method to switch the action order - using ovs-ofctl is a hack imho -
> > > > > > and/or switching the default action order for mirroring.
> > > > >
> > > > > I'm not sure that there is a way to do this that is correct in the
> > > > > generic case. It's possible that the destination could be a VM while
> > > > > packets are being mirrored to a physical device or we could be
> > > > > multicasting or some other arbitrarily complex scenario. Just think
> > > > > of what a physical switch would do if it has ports with two different
> > > > > speeds.
> > > >
> > > > Yes, I have considered that case. And I agree that perhaps there
> > > > is no sensible default. But perhaps we could make it configurable somehow?
> > >
> > > The fix is at the application level. Run netperf with -b and -w flags to
> > > limit the speed to a sensible value.
> >
> > Perhaps I should have stated my goals more clearly.
> > I'm interested in situations where I don't control the application.
>
> Well an application that streams UDP without any throttling
> at the application level will break on a physical network, right?
> So I am not sure why should one try to make it work on the virtual one.
>
> But let's assume that you do want to throttle the guest
> for reasons such as QOS. The proper approach seems
> to be to throttle the sender, not have a dummy throttled
> receiver "pacing" it. Place the qemu process in the
> correct net_cls cgroup, set the class id and apply a rate limit?
I would like to be able to use a class to rate limit egress packets.
That much works fine for me.
What I would also like is for there to be back-pressure such that the guest
doesn't consume lots of CPU, spinning, sending packets as fast as it can,
almost of all of which are dropped. That does seem like a lot of wasted
CPU to me.
Unfortunately there are several problems with this and I am fast concluding
that I will need to use a CPU cgroup. Which does make some sense, as what I
am really trying to limit here is CPU usage not network packet rates - even
if the test using the CPU is netperf. So long as the CPU usage can
(mostly) be attributed to the guest using a cgroup should work fine. And
indeed seems to in my limited testing.
One scenario in which I don't think it is possible for there to be
back-pressure in a meaningful sense is if root in the guest sets
/proc/sys/net/core/wmem_default to a large value, say 2000000.
I do think that to some extent there is back-pressure provided by sockbuf
in the case where process on the host is sending directly to a physical
interface. And to my mind it would be "nice" if the same kind of
back-pressure was present in guests. But through our discussions of the
past week or so I get the feeling that is not your view of things.
Perhaps I could characterise the guest situation by saying:
Egress packet rates can be controlled using tc on the host;
Guest CPU usage can be controlled using CPU cgroups on the host;
Sockbuf controls memory usage on the host;
Back-pressure is irrelevant.
^ permalink raw reply
* [Patch] Kill off warning: ‘inline’ is not at beginning of declaration
From: Jesper Juhl @ 2011-01-16 23:09 UTC (permalink / raw)
To: linux-kernel
Cc: alsa-devel, Mauro Carvalho Chehab, Takashi Iwai,
Frederic Weisbecker, Gustavo F. Padovan, Jaroslav Kysela,
Jens Axboe, Stephen Hemminger, Andi Kleen, H. Peter Anvin,
Pekka Savola (ipv6), x86, James Morris, Ingo Molnar,
oprofile-list, Alexey Kuznetsov, Mark Fasheh, Marcel Holtmann,
John W. Linville, David Teigland, Joel Becker, Thomas Gleixner,
linux-edac, trivial, Hideaki YOSHIFUJI
[-- Attachment #1: Type: TEXT/PLAIN, Size: 7359 bytes --]
Fix a bunch of
warning: ‘inline’ is not at beginning of declaration
messages when building a 'make allyesconfig' kernel with -Wextra.
These warnings are trivial to kill, yet rather annoying when building with
-Wextra.
The more we can cut down on pointless crap like this the better (IMHO).
A previous patch to do this for a 'allnoconfig' build has already been
merged. This just takes the cleanup a little further.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
arch/x86/oprofile/op_model_p4.c | 2 +-
drivers/bluetooth/btusb.c | 4 ++--
drivers/cpuidle/sysfs.c | 2 +-
drivers/edac/i7300_edac.c | 2 +-
fs/ocfs2/dir.c | 2 +-
kernel/trace/ring_buffer.c | 2 +-
net/ipv6/inet6_hashtables.c | 2 +-
net/mac80211/tx.c | 2 +-
sound/pci/au88x0/au88x0.h | 4 ++--
sound/pci/au88x0/au88x0_core.c | 4 ++--
10 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/x86/oprofile/op_model_p4.c b/arch/x86/oprofile/op_model_p4.c
index 9fadec0..98ab130 100644
--- a/arch/x86/oprofile/op_model_p4.c
+++ b/arch/x86/oprofile/op_model_p4.c
@@ -50,7 +50,7 @@ static inline void setup_num_counters(void)
#endif
}
-static int inline addr_increment(void)
+static inline int addr_increment(void)
{
#ifdef CONFIG_SMP
return smp_num_siblings == 2 ? 2 : 1;
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 1da773f..92d29bf 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -424,7 +424,7 @@ static void btusb_isoc_complete(struct urb *urb)
}
}
-static void inline __fill_isoc_descriptor(struct urb *urb, int len, int mtu)
+static inline void __fill_isoc_descriptor(struct urb *urb, int len, int mtu)
{
int i, offset = 0;
@@ -775,7 +775,7 @@ static void btusb_notify(struct hci_dev *hdev, unsigned int evt)
}
}
-static int inline __set_isoc_interface(struct hci_dev *hdev, int altsetting)
+static inline int __set_isoc_interface(struct hci_dev *hdev, int altsetting)
{
struct btusb_data *data = hdev->driver_data;
struct usb_interface *intf = data->isoc;
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index 0310ffa..be7917ec 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -300,7 +300,7 @@ static struct kobj_type ktype_state_cpuidle = {
.release = cpuidle_state_sysfs_release,
};
-static void inline cpuidle_free_state_kobj(struct cpuidle_device *device, int i)
+static inline void cpuidle_free_state_kobj(struct cpuidle_device *device, int i)
{
kobject_put(&device->kobjs[i]->kobj);
wait_for_completion(&device->kobjs[i]->kobj_unregister);
diff --git a/drivers/edac/i7300_edac.c b/drivers/edac/i7300_edac.c
index 05523b5..76d1f57 100644
--- a/drivers/edac/i7300_edac.c
+++ b/drivers/edac/i7300_edac.c
@@ -162,7 +162,7 @@ static struct edac_pci_ctl_info *i7300_pci;
#define AMBPRESENT_0 0x64
#define AMBPRESENT_1 0x66
-const static u16 mtr_regs[MAX_SLOTS] = {
+static const u16 mtr_regs[MAX_SLOTS] = {
0x80, 0x84, 0x88, 0x8c,
0x82, 0x86, 0x8a, 0x8e
};
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index d417b3f..f97b6f1 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -354,7 +354,7 @@ static inline int ocfs2_match(int len,
/*
* Returns 0 if not found, -1 on failure, and 1 on success
*/
-static int inline ocfs2_search_dirblock(struct buffer_head *bh,
+static inline int ocfs2_search_dirblock(struct buffer_head *bh,
struct inode *dir,
const char *name, int namelen,
unsigned long offset,
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index bd1c35a..6ee56b4 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -669,7 +669,7 @@ static struct list_head *rb_list_head(struct list_head *list)
* the reader page). But if the next page is a header page,
* its flags will be non zero.
*/
-static int inline
+static inline int
rb_is_head_page(struct ring_buffer_per_cpu *cpu_buffer,
struct buffer_page *page, struct list_head *list)
{
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index 633a6c2..b531972 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -124,7 +124,7 @@ out:
}
EXPORT_SYMBOL(__inet6_lookup_established);
-static int inline compute_score(struct sock *sk, struct net *net,
+static inline int compute_score(struct sock *sk, struct net *net,
const unsigned short hnum,
const struct in6_addr *daddr,
const int dif)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5950e3a..a449dd5 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -173,7 +173,7 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data *tx, int group_addr,
return cpu_to_le16(dur);
}
-static int inline is_ieee80211_device(struct ieee80211_local *local,
+static inline int is_ieee80211_device(struct ieee80211_local *local,
struct net_device *dev)
{
return local == wdev_priv(dev->ieee80211_ptr);
diff --git a/sound/pci/au88x0/au88x0.h b/sound/pci/au88x0/au88x0.h
index cf46bba..ecb8f4d 100644
--- a/sound/pci/au88x0/au88x0.h
+++ b/sound/pci/au88x0/au88x0.h
@@ -211,7 +211,7 @@ static void vortex_adbdma_startfifo(vortex_t * vortex, int adbdma);
//static void vortex_adbdma_stopfifo(vortex_t *vortex, int adbdma);
static void vortex_adbdma_pausefifo(vortex_t * vortex, int adbdma);
static void vortex_adbdma_resumefifo(vortex_t * vortex, int adbdma);
-static int inline vortex_adbdma_getlinearpos(vortex_t * vortex, int adbdma);
+static inline int vortex_adbdma_getlinearpos(vortex_t * vortex, int adbdma);
static void vortex_adbdma_resetup(vortex_t *vortex, int adbdma);
#ifndef CHIP_AU8810
@@ -219,7 +219,7 @@ static void vortex_wtdma_startfifo(vortex_t * vortex, int wtdma);
static void vortex_wtdma_stopfifo(vortex_t * vortex, int wtdma);
static void vortex_wtdma_pausefifo(vortex_t * vortex, int wtdma);
static void vortex_wtdma_resumefifo(vortex_t * vortex, int wtdma);
-static int inline vortex_wtdma_getlinearpos(vortex_t * vortex, int wtdma);
+static inline int vortex_wtdma_getlinearpos(vortex_t * vortex, int wtdma);
#endif
/* global stuff. */
diff --git a/sound/pci/au88x0/au88x0_core.c b/sound/pci/au88x0/au88x0_core.c
index 23f49f3..d43252a 100644
--- a/sound/pci/au88x0/au88x0_core.c
+++ b/sound/pci/au88x0/au88x0_core.c
@@ -1249,7 +1249,7 @@ static void vortex_adbdma_resetup(vortex_t *vortex, int adbdma) {
}
}
-static int inline vortex_adbdma_getlinearpos(vortex_t * vortex, int adbdma)
+static inline int vortex_adbdma_getlinearpos(vortex_t * vortex, int adbdma)
{
stream_t *dma = &vortex->dma_adb[adbdma];
int temp;
@@ -1498,7 +1498,7 @@ static int vortex_wtdma_getcursubuffer(vortex_t * vortex, int wtdma)
POS_SHIFT) & POS_MASK);
}
#endif
-static int inline vortex_wtdma_getlinearpos(vortex_t * vortex, int wtdma)
+static inline int vortex_wtdma_getlinearpos(vortex_t * vortex, int wtdma)
{
stream_t *dma = &vortex->dma_wt[wtdma];
int temp;
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
[-- Attachment #2: Type: text/plain, Size: 372 bytes --]
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
[-- Attachment #3: Type: text/plain, Size: 170 bytes --]
_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
^ permalink raw reply related
* Re: Flow Control and Port Mirroring Revisited
From: Rusty Russell @ 2011-01-16 23:56 UTC (permalink / raw)
To: Simon Horman
Cc: Michael S. Tsirkin, Jesse Gross, Eric Dumazet, virtualization,
dev, virtualization, netdev, kvm
In-Reply-To: <20110116223728.GA6279@verge.net.au>
On Mon, 17 Jan 2011 09:07:30 am Simon Horman wrote:
[snip]
I've been away, but what concerns me is that socket buffer limits are
bypassed in various configurations, due to skb cloning. We should probably
drop such limits altogether, or fix them to be consistent.
Simple fix is as someone suggested here, to attach the clone. That might
seriously reduce your sk limit, though. I haven't thought about it hard,
but might it make sense to move ownership into skb_shared_info; ie. the
data, rather than the skb head?
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH] net_sched: accurate bytes/packets stats/rates
From: Changli Gao @ 2011-01-17 0:09 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Stephen Hemminger, Eric Dumazet, David Miller, netdev,
Patrick McHardy, jamal
In-Reply-To: <20110116223540.GA1861@del.dom.local>
On Mon, Jan 17, 2011 at 6:35 AM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> On Fri, Jan 14, 2011 at 11:03:42AM -0800, Stephen Hemminger wrote:
>> From Eric Dumazet <eric.dumazet@gmail.com>
>>
>> In commit 44b8288308ac9d (net_sched: pfifo_head_drop problem), we fixed
>> a problem with pfifo_head drops that incorrectly decreased
>> sch->bstats.bytes and sch->bstats.packets
>>
>> Several qdiscs (CHOKe, SFQ, pfifo_head, ...) are able to drop a
>> previously enqueued packet, and bstats cannot be changed, so
>> bstats/rates are not accurate (over estimated)
>>
>> This patch changes the qdisc_bstats updates to be done at dequeue() time
>> instead of enqueue() time. bstats counters no longer account for dropped
>> frames, and rates are more correct, since enqueue() bursts dont have
>> effect on dequeue() rate.
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
>>
>> CC: Patrick McHardy <kaber@trash.net>
>> CC: Jarek Poplawski <jarkao2@gmail.com>
>> CC: jamal <hadi@cyberus.ca>
> ...
>> --- a/net/sched/sch_drr.c 2011-01-14 09:19:00.830857886 -0800
>> +++ b/net/sched/sch_drr.c 2011-01-14 09:28:20.398631228 -0800
>> @@ -376,7 +376,6 @@ static int drr_enqueue(struct sk_buff *s
>> }
>>
>> bstats_update(&cl->bstats, skb);
>
> Why leave leaf classes with different stats?
>
HTB also has the same problem, and I have fixed in my own product, but
the patch was rejected.
http://patchwork.ozlabs.org/patch/6227/
> Jarek P.
>
>> - qdisc_bstats_update(sch, skb);
>>
>> sch->q.qlen++;
>> return err;
> ...
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH] dummy: do not create a link (dummy0) at module init by default
From: David Ward @ 2011-01-17 0:49 UTC (permalink / raw)
To: netdev, shemminger
When the dummy network driver is initialized with no parameters, a link
is automatically created (named 'dummy0'). This is inconsistent with
other virtual network drivers such as veth, macvlan, and macvtap, which
do not create a link upon initialization.
This also causes confusing behavior when sending an RTM_NEWLINK message
for a dummy link, because the kernel will load the dummy network driver
first if it has not already been loaded. When that occurs, the result
is that two new links are actually created (or if IFLA_IFNAME is set to
'dummy0', the error EEXIST is returned). The following iproute command
demonstrates this behavior:
ip link add [ name dummy0 ] type dummy
With this change, users who still want to have a link created when the
dummy network driver is loaded (instead of using iproute to create the
link as shown above) just need to set the 'numdummies' parameter to 1:
modprobe dummy numdummies=1
Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
drivers/net/dummy.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index ff2d29b..ac8815f 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -38,7 +38,7 @@
#include <net/rtnetlink.h>
#include <linux/u64_stats_sync.h>
-static int numdummies = 1;
+static int numdummies = 0;
static int dummy_set_address(struct net_device *dev, void *p)
{
--
1.7.3.4
^ permalink raw reply related
* Re: inbound connection problems when "netlink: test for all flags of the NLM_F_DUMP composite" commit applied
From: Arthur Marsh @ 2011-01-17 1:03 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Jan Engelhardt, Eric Dumazet, Linux Netdev List
In-Reply-To: <4D336050.9030602@netfilter.org>
Pablo Neira Ayuso wrote, on 17/01/11 07:47:
> On 16/01/11 13:25, Arthur Marsh wrote:
>> Jan Engelhardt wrote, on 16/01/11 21:20:
>>>
>>> Le dimanche 16 janvier 2011 à 19:24 +1030, Arthur Marsh a écrit :
>>>>
>>>>> With kernels up to and including 2.6.37-git7, inbound telnetd-ssl
>>>>> connections worked fine. With kernel 2.6.37-git9 and later inbound
>>>>> telnetd-ssl connections failed, and on machine shut-down, there
>>>>> were warning messages about daemons not return status.
>>>
>>> Which daemons are these? For reference, what distro do you happen
>>> to use?
>>
>> avahi-daemon (which gave multiple warning messages, hence I thought it
>> may have been multiple packages)
>>
>> I'm running Debian unstable with kernel.org kernels.
>>
>>>
>>>>> commit 0ab03c2b1478f2438d2c80204f7fef65b1bca9cf
>>>>> netlink: test for all flags of the NLM_F_DUMP composite
>>>
>>> Each of the hunks in this commit is independent of another.
>>> Would you mind bisecting these too?
>>
>> Recompiling with the only the first patch (attached) resulted in a
>> repeat of the problem.
>>
>> I've removed one person from the cc: list as they did not want to
>> receive email about this even though they signed off the commit.
>
> Please, pass this patch to the avahi-daemon developers. They use an
> invalid netlink flag combination for dump operations.
>
> This patch has spotted a problem that they have to fix indeed.
>
I've forwarded this on as a Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610281
Regards,
Arthur.
^ permalink raw reply
* Re: [PATCH] net_sched: accurate bytes/packets stats/rates
From: Eric Dumazet @ 2011-01-17 6:54 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Stephen Hemminger, David Miller, netdev, Patrick McHardy, jamal
In-Reply-To: <20110116223540.GA1861@del.dom.local>
Le dimanche 16 janvier 2011 à 23:35 +0100, Jarek Poplawski a écrit :
> Why leave leaf classes with different stats?
>
I wanted to address this point in a followup patch, once general qdisc
stats changes are accepted.
^ permalink raw reply
* Re: [PATCH] net_sched: accurate bytes/packets stats/rates
From: Eric Dumazet @ 2011-01-17 7:17 UTC (permalink / raw)
To: Changli Gao
Cc: Jarek Poplawski, Stephen Hemminger, David Miller, netdev,
Patrick McHardy, jamal
In-Reply-To: <AANLkTim14h+6k6nt+UWP5gDcT5NmAGLU_S+wG6VhDn-O@mail.gmail.com>
Le lundi 17 janvier 2011 à 08:09 +0800, Changli Gao a écrit :
> On Mon, Jan 17, 2011 at 6:35 AM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> > On Fri, Jan 14, 2011 at 11:03:42AM -0800, Stephen Hemminger wrote:
> >> From Eric Dumazet <eric.dumazet@gmail.com>
> >>
> >> In commit 44b8288308ac9d (net_sched: pfifo_head_drop problem), we fixed
> >> a problem with pfifo_head drops that incorrectly decreased
> >> sch->bstats.bytes and sch->bstats.packets
> >>
> >> Several qdiscs (CHOKe, SFQ, pfifo_head, ...) are able to drop a
> >> previously enqueued packet, and bstats cannot be changed, so
> >> bstats/rates are not accurate (over estimated)
> >>
> >> This patch changes the qdisc_bstats updates to be done at dequeue() time
> >> instead of enqueue() time. bstats counters no longer account for dropped
> >> frames, and rates are more correct, since enqueue() bursts dont have
> >> effect on dequeue() rate.
> >>
> >> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> >> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
> >>
> >> CC: Patrick McHardy <kaber@trash.net>
> >> CC: Jarek Poplawski <jarkao2@gmail.com>
> >> CC: jamal <hadi@cyberus.ca>
> > ...
> >> --- a/net/sched/sch_drr.c 2011-01-14 09:19:00.830857886 -0800
> >> +++ b/net/sched/sch_drr.c 2011-01-14 09:28:20.398631228 -0800
> >> @@ -376,7 +376,6 @@ static int drr_enqueue(struct sk_buff *s
> >> }
> >>
> >> bstats_update(&cl->bstats, skb);
> >
> > Why leave leaf classes with different stats?
> >
>
> HTB also has the same problem, and I have fixed in my own product, but
> the patch was rejected.
>
> http://patchwork.ozlabs.org/patch/6227/
>
Hmm, considering qdisc stats are not used in kernel (only updated and
reported to tc users) it seems to me counting arrival instead of
departure rates is mostly useless for the user, if drops are ignored.
(I am not speaking of direct drops, when we try to enqueue() this skb,
but later ones, when another skb is enqueued and we drop a previously
enqueued skb)
User really wants to see the effective departure rate, to check its
qdisc parameters in respect with kernel ones (HZ=100/1000, HIGH res
timers off/on, ...)
Arrival rates are of litle use. However, it might be good to have a
second "bstats" only for dropped packets/bytes, or extend bstats in a
compatible way (maybe adding fields to the end of structure)
^ permalink raw reply
* Re: Realtek r8168C / r8169 driver VLAN TAG stripping
From: Anand Raj Manickam @ 2011-01-17 7:34 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <AANLkTi=uNKMj_gs_bKRQ1tQa0TMwdnyrtVcR5JPNpmJv@mail.gmail.com>
On Mon, Jan 17, 2011 at 11:52 AM, Anand Raj Manickam <anandrm@gmail.com> wrote:
> Hi Romieu ,
> This is the dmesg for XID
>
> eth0: RTL8168c/8111c at 0xf9628000, 00:17:54:00:f6:62, XID 1c4000c0 IRQ 31
> r8169: mac_version = 0x16
> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
>
> Unfortunately , i m not able to upgrade my kernel now . If there is a
> Fix for it , that would be great !!
>
> Thanks for your kind reply ,
> Anand
>
>
>
> On Mon, Jan 17, 2011 at 12:50 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
>> Anand Raj Manickam <anandrm@gmail.com> :
>> [...]
>>> This happens on a Linux 2.6.30.8 kernel .The driver is in-kernel.
>>
>> I do not notice it with my 8168c (XID 18000000) on a modular 2.6.37-git.
>>
>> Can you send the XID of the r8169 that appears in the log of your kernel
>> and upgrade to a more recent kernel ?
>>
>> --
>> Ueimor
>>
>
^ permalink raw reply
* [PATCH 2/3] vhost-net: Unify the code of mergeable and big buffer handling
From: Jason Wang @ 2011-01-17 8:11 UTC (permalink / raw)
To: virtualization, netdev, kvm, mst; +Cc: linux-kernel
In-Reply-To: <20110117081058.18900.67456.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
Codes duplication were found between the handling of mergeable and big
buffers, so this patch tries to unify them. This could be easily done
by adding a quota to the get_rx_bufs() which is used to limit the
number of buffers it returns (for mergeable buffer, the quota is
simply UIO_MAXIOV, for big buffers, the quota is just 1), and then the
previous handle_rx_mergeable() could be resued also for big buffers.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 128 +++------------------------------------------------
1 files changed, 7 insertions(+), 121 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 95e49de..c32a2e4 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -227,6 +227,7 @@ static int peek_head_len(struct sock *sk)
* @iovcount - returned count of io vectors we fill
* @log - vhost log
* @log_num - log offset
+ * @quota - headcount quota, 1 for big buffer
* returns number of buffer heads allocated, negative on error
*/
static int get_rx_bufs(struct vhost_virtqueue *vq,
@@ -234,7 +235,8 @@ static int get_rx_bufs(struct vhost_virtqueue *vq,
int datalen,
unsigned *iovcount,
struct vhost_log *log,
- unsigned *log_num)
+ unsigned *log_num,
+ unsigned int quota)
{
unsigned int out, in;
int seg = 0;
@@ -242,7 +244,7 @@ static int get_rx_bufs(struct vhost_virtqueue *vq,
unsigned d;
int r, nlogs = 0;
- while (datalen > 0) {
+ while (datalen > 0 && headcount < quota) {
if (unlikely(seg >= UIO_MAXIOV)) {
r = -ENOBUFS;
goto err;
@@ -282,116 +284,7 @@ err:
/* Expects to be always run from workqueue - which acts as
* read-size critical section for our kind of RCU. */
-static void handle_rx_big(struct vhost_net *net)
-{
- struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_RX];
- unsigned out, in, log, s;
- int head;
- struct vhost_log *vq_log;
- struct msghdr msg = {
- .msg_name = NULL,
- .msg_namelen = 0,
- .msg_control = NULL, /* FIXME: get and handle RX aux data. */
- .msg_controllen = 0,
- .msg_iov = vq->iov,
- .msg_flags = MSG_DONTWAIT,
- };
-
- struct virtio_net_hdr hdr = {
- .flags = 0,
- .gso_type = VIRTIO_NET_HDR_GSO_NONE
- };
-
- size_t len, total_len = 0;
- int err;
- size_t hdr_size;
- struct socket *sock = rcu_dereference(vq->private_data);
- if (!sock || skb_queue_empty(&sock->sk->sk_receive_queue))
- return;
-
- mutex_lock(&vq->mutex);
- vhost_disable_notify(vq);
- hdr_size = vq->vhost_hlen;
-
- vq_log = unlikely(vhost_has_feature(&net->dev, VHOST_F_LOG_ALL)) ?
- vq->log : NULL;
-
- for (;;) {
- head = vhost_get_vq_desc(&net->dev, vq, vq->iov,
- ARRAY_SIZE(vq->iov),
- &out, &in,
- vq_log, &log);
- /* On error, stop handling until the next kick. */
- if (unlikely(head < 0))
- break;
- /* OK, now we need to know about added descriptors. */
- if (head == vq->num) {
- if (unlikely(vhost_enable_notify(vq))) {
- /* They have slipped one in as we were
- * doing that: check again. */
- vhost_disable_notify(vq);
- continue;
- }
- /* Nothing new? Wait for eventfd to tell us
- * they refilled. */
- break;
- }
- /* We don't need to be notified again. */
- if (out) {
- vq_err(vq, "Unexpected descriptor format for RX: "
- "out %d, int %d\n",
- out, in);
- break;
- }
- /* Skip header. TODO: support TSO/mergeable rx buffers. */
- s = move_iovec_hdr(vq->iov, vq->hdr, hdr_size, in);
- msg.msg_iovlen = in;
- len = iov_length(vq->iov, in);
- /* Sanity check */
- if (!len) {
- vq_err(vq, "Unexpected header len for RX: "
- "%zd expected %zd\n",
- iov_length(vq->hdr, s), hdr_size);
- break;
- }
- err = sock->ops->recvmsg(NULL, sock, &msg,
- len, MSG_DONTWAIT | MSG_TRUNC);
- /* TODO: Check specific error and bomb out unless EAGAIN? */
- if (err < 0) {
- vhost_discard_vq_desc(vq, 1);
- break;
- }
- /* TODO: Should check and handle checksum. */
- if (err > len) {
- pr_debug("Discarded truncated rx packet: "
- " len %d > %zd\n", err, len);
- vhost_discard_vq_desc(vq, 1);
- continue;
- }
- len = err;
- err = memcpy_toiovec(vq->hdr, (unsigned char *)&hdr, hdr_size);
- if (err) {
- vq_err(vq, "Unable to write vnet_hdr at addr %p: %d\n",
- vq->iov->iov_base, err);
- break;
- }
- len += hdr_size;
- vhost_add_used_and_signal(&net->dev, vq, head, len);
- if (unlikely(vq_log))
- vhost_log_write(vq, vq_log, log, len);
- total_len += len;
- if (unlikely(total_len >= VHOST_NET_WEIGHT)) {
- vhost_poll_queue(&vq->poll);
- break;
- }
- }
-
- mutex_unlock(&vq->mutex);
-}
-
-/* Expects to be always run from workqueue - which acts as
- * read-size critical section for our kind of RCU. */
-static void handle_rx_mergeable(struct vhost_net *net)
+static void handle_rx(struct vhost_net *net)
{
struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_RX];
unsigned uninitialized_var(in), log;
@@ -431,7 +324,8 @@ static void handle_rx_mergeable(struct vhost_net *net)
sock_len += sock_hlen;
vhost_len = sock_len + vhost_hlen;
headcount = get_rx_bufs(vq, vq->heads, vhost_len,
- &in, vq_log, &log);
+ &in, vq_log, &log,
+ likely(mergeable) ? UIO_MAXIOV : 1);
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
break;
@@ -497,14 +391,6 @@ static void handle_rx_mergeable(struct vhost_net *net)
mutex_unlock(&vq->mutex);
}
-static void handle_rx(struct vhost_net *net)
-{
- if (vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF))
- handle_rx_mergeable(net);
- else
- handle_rx_big(net);
-}
-
static void handle_tx_kick(struct vhost_work *work)
{
struct vhost_virtqueue *vq = container_of(work, struct vhost_virtqueue,
^ permalink raw reply related
* [PATCH 3/3] vhost-net: use lock_sock_fast() in peek_head_len()
From: Jason Wang @ 2011-01-17 8:11 UTC (permalink / raw)
To: virtualization, netdev, kvm, mst; +Cc: linux-kernel
In-Reply-To: <20110117081058.18900.67456.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
We can use lock_sock_fast() instead of lock_sock() in order to get
speedup in peek_head_len().
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index c32a2e4..50b622a 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -211,12 +211,12 @@ static int peek_head_len(struct sock *sk)
{
struct sk_buff *head;
int len = 0;
+ bool slow = lock_sock_fast(sk);
- lock_sock(sk);
head = skb_peek(&sk->sk_receive_queue);
if (head)
len = head->len;
- release_sock(sk);
+ unlock_sock_fast(sk, slow);
return len;
}
^ permalink raw reply related
* [PATCH 1/3] vhost-net: check the support of mergeable buffer outside the receive loop
From: Jason Wang @ 2011-01-17 8:10 UTC (permalink / raw)
To: virtualization, netdev, kvm, mst; +Cc: linux-kernel
No need to check the support of mergeable buffer inside the recevie
loop as the whole handle_rx()_xx is in the read critical region. So
this patch move it ahead of the receiving loop.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 14fc189..95e49de 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -411,7 +411,7 @@ static void handle_rx_mergeable(struct vhost_net *net)
};
size_t total_len = 0;
- int err, headcount;
+ int err, headcount, mergeable;
size_t vhost_hlen, sock_hlen;
size_t vhost_len, sock_len;
struct socket *sock = rcu_dereference(vq->private_data);
@@ -425,6 +425,7 @@ static void handle_rx_mergeable(struct vhost_net *net)
vq_log = unlikely(vhost_has_feature(&net->dev, VHOST_F_LOG_ALL)) ?
vq->log : NULL;
+ mergeable = vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF);
while ((sock_len = peek_head_len(sock->sk))) {
sock_len += sock_hlen;
@@ -474,7 +475,7 @@ static void handle_rx_mergeable(struct vhost_net *net)
break;
}
/* TODO: Should check and handle checksum. */
- if (vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF) &&
+ if (likely(mergeable) &&
memcpy_toiovecend(vq->hdr, (unsigned char *)&headcount,
offsetof(typeof(hdr), num_buffers),
sizeof hdr.num_buffers)) {
^ permalink raw reply related
* [PATCH] virtio-net: fix a typo
From: Aurelien Jarno @ 2011-01-17 8:14 UTC (permalink / raw)
To: linux-kernel; +Cc: Aurelien Jarno, netdev, Michael S. Tsirkin
fitler -> filter
Cc: netdev@vger.kernel.org
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
---
drivers/net/virtio_net.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 90a23e4..48a4297 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -787,7 +787,7 @@ static void virtnet_set_rx_mode(struct net_device *dev)
if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_MAC,
VIRTIO_NET_CTRL_MAC_TABLE_SET,
sg, 2, 0))
- dev_warn(&dev->dev, "Failed to set MAC fitler table.\n");
+ dev_warn(&dev->dev, "Failed to set MAC filter table.\n");
kfree(buf);
}
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH v4 05/10] net/fec: add dual fec support for mx28
From: Lothar Waßmann @ 2011-01-17 8:16 UTC (permalink / raw)
To: Shawn Guo
Cc: gerg, B32542, netdev, s.hauer, bryan.wu, jamie, baruch, w.sang,
r64343, eric, Uwe Kleine-König, jamie, davem,
linux-arm-kernel
In-Reply-To: <20110114130849.GA27583@freescale.com>
Hi,
Shawn Guo writes:
> On Fri, Jan 14, 2011 at 08:52:23AM +0100, Uwe Kleine-König wrote:
> > On Fri, Jan 14, 2011 at 01:48:40PM +0800, Shawn Guo wrote:
> > > Hi Uwe,
> > >
> > > On Thu, Jan 13, 2011 at 03:48:05PM +0100, Uwe Kleine-König wrote:
> > >
> > > [...]
> > >
> > > > > +/* Controller is ENET-MAC */
> > > > > +#define FEC_QUIRK_ENET_MAC (1 << 0)
> > > > does this really qualify to be a quirk?
> > > >
> > > My understanding is that ENET-MAC is a type of "quirky" FEC
> > > controller.
> > >
> > > > > +/* Controller needs driver to swap frame */
> > > > > +#define FEC_QUIRK_SWAP_FRAME (1 << 1)
> > > > IMHO this is a bit misnamed. FEC_QUIRK_NEEDS_BE_DATA or similar would
> > > > be more accurate.
> > > >
> > > When your make this change, you may want to pick a better name for
> > > function swap_buffer too.
> > >
> > > [...]
> > >
> > > > > +static void *swap_buffer(void *bufaddr, int len)
> > > > > +{
> > > > > + int i;
> > > > > + unsigned int *buf = bufaddr;
> > > > > +
> > > > > + for (i = 0; i < (len + 3) / 4; i++, buf++)
> > > > > + *buf = cpu_to_be32(*buf);
> > > > if len isn't a multiple of 4 this accesses bytes behind len. Is this
> > > > generally OK here? (E.g. because skbs always have a length that is a
> > > > multiple of 4?)
> > > The len may not be a multiple of 4. But I believe bufaddr is always
> > > a buffer allocated in a length that is a multiple of 4, and the 1~3
> > > bytes exceeding the len very likely has no data that matters. But
> > > yes, it deserves a safer implementation.
> > Did you test what happens if bufaddr isn't aligned? Does it work at all
> > then?
> >
> I see many calls passing a len that is not a multiple of 4, but it
> works good.
>
That does not prove anything, actually.
Anyway "bufaddr isn't aligned" != "len is not a multiple of 4".
Is there any guarantee that the function cannot be called with a
non-aligned buffer address?
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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