* Re: [PATCH net-next 2/4] net: allow > 0 order atomic page alloc in skb_page_frag_refill
From: Eric Dumazet @ 2013-11-12 22:42 UTC (permalink / raw)
To: Michael Dalton
Cc: Michael S. Tsirkin, netdev, Daniel Borkmann, virtualization,
Eric Dumazet, David S. Miller
In-Reply-To: <1384294885-6444-2-git-send-email-mwdalton@google.com>
On Tue, 2013-11-12 at 14:21 -0800, Michael Dalton wrote:
> skb_page_frag_refill currently permits only order-0 page allocs
> unless GFP_WAIT is used. Change skb_page_frag_refill to attempt
> higher-order page allocations whether or not GFP_WAIT is used. If
> memory cannot be allocated, the allocator will fall back to
> successively smaller page allocs (down to order-0 page allocs).
>
> This change brings skb_page_frag_refill in line with the existing
> page allocation strategy employed by netdev_alloc_frag, which attempts
> higher-order page allocations whether or not GFP_WAIT is set, falling
> back to successively lower-order page allocations on failure. Part
> of migration of virtio-net to per-receive queue page frag allocators.
>
> Signed-off-by: Michael Dalton <mwdalton@google.com>
> ---
> net/core/sock.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next 3/4] virtio-net: use per-receive queue page frag alloc for mergeable bufs
From: Eric Dumazet @ 2013-11-12 22:43 UTC (permalink / raw)
To: Michael Dalton
Cc: Michael S. Tsirkin, netdev, Daniel Borkmann, virtualization,
Eric Dumazet, David S. Miller
In-Reply-To: <1384294885-6444-3-git-send-email-mwdalton@google.com>
On Tue, 2013-11-12 at 14:21 -0800, Michael Dalton wrote:
> The virtio-net driver currently uses netdev_alloc_frag() for GFP_ATOMIC
> mergeable rx buffer allocations. This commit migrates virtio-net to use
> per-receive queue page frags for GFP_ATOMIC allocation. This change unifies
> mergeable rx buffer memory allocation, which now will use skb_refill_frag()
> for both atomic and GFP-WAIT buffer allocations.
>
> To address fragmentation concerns, if after buffer allocation there
> is too little space left in the page frag to allocate a subsequent
> buffer, the remaining space is added to the current allocated buffer
> so that the remaining space can be used to store packet data.
>
> Signed-off-by: Michael Dalton <mwdalton@google.com>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH] net/7990: Make lance_private.name const
From: Geert Uytterhoeven @ 2013-11-12 22:44 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: David Miller, netdev@vger.kernel.org, Linux/m68k
In-Reply-To: <5282BC76.5050701@cogentembedded.com>
On Wed, Nov 13, 2013 at 12:40 AM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 11/13/2013 12:12 AM, David Miller wrote:
>
>>>> @@ -100,7 +100,7 @@ struct lance_init_block {
>>>> */
>>>> struct lance_private
>>>> {
>>>> - char *name;
>>>> + const char *name;
>
>
>>> Indent with tab, not spaces, please.
>
>
>> This whole file is %99 space indentation, you really can't blame
>> Geert for this.
>
>
> It's never late to fix some.
That would be a separate patch. Care to create and send it?
> And remember about checkpatch.pl which was hardly content with the patch.
Only because checkpatch looks at the _new_ lines, and doesn't compare the
styles of the old and new lines.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/2] random32: add __init prefix to prandom_start_seed_timer
From: Daniel Borkmann @ 2013-11-12 22:45 UTC (permalink / raw)
To: davem; +Cc: netdev, Hannes Frederic Sowa
We only call that in functions annotated with __init, so add __init
prefix in prandom_start_seed_timer() as well, so that the kernel can
make use of this hint and we can possibly free up resources after it's
usage. And since it's an internal function rename it to
__prandom_start_seed_timer().
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
lib/random32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/random32.c b/lib/random32.c
index 82da4f4..4f9d5df 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -222,7 +222,7 @@ static void __prandom_timer(unsigned long dontcare)
add_timer(&seed_timer);
}
-static void prandom_start_seed_timer(void)
+static void __init __prandom_start_seed_timer(void)
{
set_timer_slack(&seed_timer, HZ);
seed_timer.expires = jiffies + 40 * HZ;
@@ -270,7 +270,7 @@ void prandom_reseed_late(void)
static int __init prandom_reseed(void)
{
__prandom_reseed(false);
- prandom_start_seed_timer();
+ __prandom_start_seed_timer();
return 0;
}
late_initcall(prandom_reseed);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/2] random32: use msecs_to_jiffies for reseed timer
From: Daniel Borkmann @ 2013-11-12 22:45 UTC (permalink / raw)
To: davem; +Cc: netdev, Hannes Frederic Sowa
In-Reply-To: <1384296342-3348-1-git-send-email-dborkman@redhat.com>
Use msecs_to_jiffies, for these calculations as different HZ
considerations are taken into account for conversion of the timer
shot, and also it makes the code more readable.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
lib/random32.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/random32.c b/lib/random32.c
index 4f9d5df..1e5b2df 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -214,18 +214,22 @@ static DEFINE_TIMER(seed_timer, __prandom_timer, 0, 0);
static void __prandom_timer(unsigned long dontcare)
{
u32 entropy;
+ unsigned long expires;
get_random_bytes(&entropy, sizeof(entropy));
prandom_seed(entropy);
+
/* reseed every ~60 seconds, in [40 .. 80) interval with slack */
- seed_timer.expires = jiffies + (40 * HZ + (prandom_u32() % (40 * HZ)));
+ expires = 40 + (prandom_u32() % 40);
+ seed_timer.expires = jiffies + msecs_to_jiffies(expires * MSEC_PER_SEC);
+
add_timer(&seed_timer);
}
static void __init __prandom_start_seed_timer(void)
{
set_timer_slack(&seed_timer, HZ);
- seed_timer.expires = jiffies + 40 * HZ;
+ seed_timer.expires = jiffies + msecs_to_jiffies(40 * MSEC_PER_SEC);
add_timer(&seed_timer);
}
--
1.8.3.1
^ permalink raw reply related
* Re: shutdown(3) and bluetooth.
From: Dave Jones @ 2013-11-12 22:48 UTC (permalink / raw)
To: Marcel Holtmann
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org development
In-Reply-To: <FC5CE013-B077-4EA5-81C1-A7D8B4A5EF85-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
On Wed, Nov 13, 2013 at 07:32:09AM +0900, Marcel Holtmann wrote:
> > Here's the info I found in the logs, it looks like this was the only bluetooth socket.
> >
> > fd[195] = domain:31 (PF_BLUETOOTH) type:0x5 protocol:2
> > Setsockopt(1 d 2134000 8) on fd 195
>
> this is a bit confusing. Protocol 2 is actually SCO, but the stack trace shows RFCOMM.
Sorry, mixed up two separate runs. In the log above, the stack trace is actually..
[<ffffffffa0492dca>] bt_sock_wait_state+0xda/0x240 [bluetooth]
[<ffffffffa04c86d8>] sco_sock_release+0xb8/0xf0 [bluetooth]
[<ffffffff815cb1ff>] sock_release+0x1f/0x90
[<ffffffff815cb282>] sock_close+0x12/0x20
> > ./trinity -P PF_BLUETOOTH -l off -c setsockopt
> >
> > let it run a few seconds, and then ctrl-c. The main process will never exit.
> >
> > 5814 pts/6 Ss 0:00 | \_ bash
> > 5876 pts/6 S+ 0:00 | | \_ ./trinity -P PF_BLUETOOTH -l off -c setsockopt
> > 5877 pts/6 Z+ 0:00 | | \_ [trinity] <defunct>
> > 5878 pts/6 S+ 0:01 | | \_ [trinity-main]
> >
> > $ sudo cat /proc/5878/stack
> > [<ffffffffa04397a2>] bt_sock_wait_state+0xc2/0x190 [bluetooth]
> > [<ffffffffa0847a75>] rfcomm_sock_shutdown+0x85/0xb0 [rfcomm]
> > [<ffffffffa0847ad9>] rfcomm_sock_release+0x39/0xb0 [rfcomm]
So it seems it affects both SCO and RFCOMM.
> What kernel did you run this against? It is a shot in the dark, but can you try linux-next quickly.
> There was a socket related fix for the socket options where we confused RFCOMM vs L2CAP struct sock.
first noticed it on Linus' latest HEAD, and then reproduced it on 3.11.6
I'll look at linux-next tomorrow.
thanks,
Dave
^ permalink raw reply
* Re: linux-next: manual merge of the random tree with the net-next tree
From: Theodore Ts'o @ 2013-11-12 23:02 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Stephen Rothwell, linux-next, linux-kernel, Hannes Frederic Sowa,
David Miller, netdev
In-Reply-To: <5281ED01.5020204@redhat.com>
On Tue, Nov 12, 2013 at 09:55:29AM +0100, Daniel Borkmann wrote:
>
> As per Hannes' suggestion, the result should look like (see cover
> letter in [1]):
>
> if (r->entropy_total > 128) {
> r->initialized = 1;
> r->entropy_total = 0;
> if (r == &nonblocking_pool) {
> prandom_reseed_late();
> pr_notice("random: %s pool is initialized\n",
> r->name);
> }
> }
Agreed. What's the schedule for pushing net-dev to Linus? I'm
currently at Korea Linux Forum, and I was originally planning on
pushing random.git to Linus sometime today, but I'm also willing to
wait for net-dev to go first. Either way, we should make sure Linus
is aware of the agreed-upon resolution of the merge conflict.
Cheers,
- Ted
^ permalink raw reply
* Re: linux-next: manual merge of the random tree with the net-next tree
From: Hannes Frederic Sowa @ 2013-11-12 23:13 UTC (permalink / raw)
To: Theodore Ts'o, Daniel Borkmann, Stephen Rothwell, linux-next,
linux-kernel, David Miller, netdev
In-Reply-To: <20131112230242.GA1643@thunk.org>
On Tue, Nov 12, 2013 at 06:02:42PM -0500, Theodore Ts'o wrote:
> On Tue, Nov 12, 2013 at 09:55:29AM +0100, Daniel Borkmann wrote:
> >
> > As per Hannes' suggestion, the result should look like (see cover
> > letter in [1]):
> >
> > if (r->entropy_total > 128) {
> > r->initialized = 1;
> > r->entropy_total = 0;
> > if (r == &nonblocking_pool) {
> > prandom_reseed_late();
> > pr_notice("random: %s pool is initialized\n",
> > r->name);
> > }
> > }
>
> Agreed. What's the schedule for pushing net-dev to Linus? I'm
> currently at Korea Linux Forum, and I was originally planning on
> pushing random.git to Linus sometime today, but I'm also willing to
> wait for net-dev to go first. Either way, we should make sure Linus
> is aware of the agreed-upon resolution of the merge conflict.
net-next is already on its way: http://markmail.org/message/ihccweynhtpdd66u
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH] net/7990: Make lance_private.name const
From: David Miller @ 2013-11-12 23:15 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: geert, netdev, linux-m68k
In-Reply-To: <5282BC76.5050701@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Wed, 13 Nov 2013 02:40:38 +0300
> On 11/13/2013 12:12 AM, David Miller wrote:
>
>>>> @@ -100,7 +100,7 @@ struct lance_init_block {
>>>> */
>>>> struct lance_private
>>>> {
>>>> - char *name;
>>>> + const char *name;
>
>>> Indent with tab, not spaces, please.
>
>> This whole file is %99 space indentation, you really can't blame
>> Geert for this.
>
> It's never late to fix some. And remember about checkpatch.pl which
> was hardly content with the patch.
Good point, Geert please respin this, thanks.
^ permalink raw reply
* Re: [PATCH] net/7990: Make lance_private.name const
From: David Miller @ 2013-11-12 23:16 UTC (permalink / raw)
To: geert; +Cc: sergei.shtylyov, netdev, linux-m68k
In-Reply-To: <CAMuHMdVn6MFbXgdE_teYW10OfYBjyZsN7v2yTTAsKj0kXao7Hw@mail.gmail.com>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Tue, 12 Nov 2013 23:44:06 +0100
> On Wed, Nov 13, 2013 at 12:40 AM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
>> On 11/13/2013 12:12 AM, David Miller wrote:
>>
>>>>> @@ -100,7 +100,7 @@ struct lance_init_block {
>>>>> */
>>>>> struct lance_private
>>>>> {
>>>>> - char *name;
>>>>> + const char *name;
>>
>>
>>>> Indent with tab, not spaces, please.
>>
>>
>>> This whole file is %99 space indentation, you really can't blame
>>> Geert for this.
>>
>>
>> It's never late to fix some.
>
> That would be a separate patch. Care to create and send it?
>
>> And remember about checkpatch.pl which was hardly content with the patch.
>
> Only because checkpatch looks at the _new_ lines, and doesn't compare the
> styles of the old and new lines.
You really should fix the line you are changing to use tabs, please respin
with this in mind, thanks.
^ permalink raw reply
* Re: linux-next: manual merge of the random tree with the net-next tree
From: David Miller @ 2013-11-12 23:17 UTC (permalink / raw)
To: tytso; +Cc: dborkman, sfr, linux-next, linux-kernel, hannes, netdev
In-Reply-To: <20131112230242.GA1643@thunk.org>
From: Theodore Ts'o <tytso@mit.edu>
Date: Tue, 12 Nov 2013 18:02:42 -0500
> On Tue, Nov 12, 2013 at 09:55:29AM +0100, Daniel Borkmann wrote:
>>
>> As per Hannes' suggestion, the result should look like (see cover
>> letter in [1]):
>>
>> if (r->entropy_total > 128) {
>> r->initialized = 1;
>> r->entropy_total = 0;
>> if (r == &nonblocking_pool) {
>> prandom_reseed_late();
>> pr_notice("random: %s pool is initialized\n",
>> r->name);
>> }
>> }
>
> Agreed. What's the schedule for pushing net-dev to Linus? I'm
> currently at Korea Linux Forum, and I was originally planning on
> pushing random.git to Linus sometime today, but I'm also willing to
> wait for net-dev to go first. Either way, we should make sure Linus
> is aware of the agreed-upon resolution of the merge conflict.
Linus is going to pull it soon, I sent the pull request last night but
he was away from decent internet access at the time.
^ permalink raw reply
* Re: [PATCH iproute2] ss: avoid passing negative numbers to malloc
From: Eric Dumazet @ 2013-11-12 23:18 UTC (permalink / raw)
To: Andreas Henriksson; +Cc: stephen, netdev
In-Reply-To: <20131112185214.GA29913@amd64.fatal.se>
On Tue, 2013-11-12 at 19:52 +0100, Andreas Henriksson wrote:
> Example:
>
> $ ss state established \( sport = :4060 or sport = :4061 or sport = :4062 or sport = :4063 or sport = :4064 or sport = :4065 or sport = :4066 or sport = :4067 \) > /dev/null
> Aborted
>
> In the example above ssfilter_bytecompile(...) will return (int)136.
> char l1 = 136; means -120 which will result in a negative number
> being passed to malloc at misc/ss.c:913.
>
> Simply declare l1 and l2 as intergers to avoid the char overflow.
>
> This is one of the issues originally reported in http://bugs.debian.org/511720
>
> Reported-by: Andreas Schuldei <andreas@debian.org>
> Signed-off-by: Andreas Henriksson <andreas@fatal.se>
> ---
> misc/ss.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/misc/ss.c b/misc/ss.c
> index c0369f1..db3a3a4 100644
> --- a/misc/ss.c
> +++ b/misc/ss.c
> @@ -907,7 +907,8 @@ static int ssfilter_bytecompile(struct ssfilter *f, char **bytecode)
> }
> case SSF_OR:
> {
> - char *a1, *a2, *a, l1, l2;
> + char *a1, *a2, *a;
> + int l1, l2;
> l1 = ssfilter_bytecompile(f->pred, &a1);
> l2 = ssfilter_bytecompile(f->post, &a2);
> if (!(a = malloc(l1+l2+4))) abort();
Please fix the other cases (SSF_NOT and SSF_AND) ?
Thanks !
^ permalink raw reply
* Re: linux-next: manual merge of the random tree with the net-next tree
From: Theodore Ts'o @ 2013-11-12 23:24 UTC (permalink / raw)
To: David Miller; +Cc: dborkman, sfr, linux-next, linux-kernel, hannes, netdev
In-Reply-To: <20131112.181717.2152470373264166279.davem@davemloft.net>
On Tue, Nov 12, 2013 at 06:17:17PM -0500, David Miller wrote:
> > Agreed. What's the schedule for pushing net-dev to Linus? I'm
> > currently at Korea Linux Forum, and I was originally planning on
> > pushing random.git to Linus sometime today, but I'm also willing to
> > wait for net-dev to go first. Either way, we should make sure Linus
> > is aware of the agreed-upon resolution of the merge conflict.
>
> Linus is going to pull it soon, I sent the pull request last night but
> he was away from decent internet access at the time.
Great, I'll wait for net-dev to show up in Linus's tree before I send
the pull request for random.git.
Thanks,
- Ted
^ permalink raw reply
* Re: VLAN filtering/VLAN aware bridge problems
From: Vlad Yasevich @ 2013-11-12 23:25 UTC (permalink / raw)
To: Stefan Priebe; +Cc: David Miller, Linux Netdev List
In-Reply-To: <52829E41.6060604@profihost.ag>
On 11/12/2013 04:31 PM, Stefan Priebe wrote:
> sorry for the very late response.
>
> Am 10.09.2013 16:11, schrieb Vlad Yasevich:
>> On 08/30/2013 11:01 AM, Stefan Priebe - Profihost AG wrote:
>>> Yes
>>>
>>
>> Can you apply this patch and see if this fixes your problem.
>> http://patchwork.ozlabs.org/patch/273841/
>>
>> In my attempts to reproduce your problem I didn't configuring filtering
>> on the upper bridge, but that is what could have been causing
>> your problem. I'll attempt it and let you know.
>
> Even with the complete patchset which was merged upstream it doesn't
> work ;-(
>
> What's wrong there and / or how can i debug?
Can you provide the filtering settings for both bridges you use?
Thanks
-vlad
>
> Stefan
>
>> -vlad
>>
>>
>>> Stefan
>>>
>>> This mail was sent with my iPhone.
>>>
>>> Am 30.08.2013 um 16:13 schrieb Vlad Yasevich <vyasevic@redhat.com>:
>>>
>>>> On 08/30/2013 03:24 AM, Stefan Priebe - Profihost AG wrote:
>>>>> Am 29.08.2013 22:45, schrieb Vlad Yasevich:
>>>>>> On 08/29/2013 08:50 AM, Stefan Priebe - Profihost AG wrote:
>>>>>
>>>>>>> The packets never reach the TAP device.
>>>>>>>
>>>>>>> Here is an output of ip a l (vlan 3021):
>>>>>>
>>>>>> Can you provide output of brctl show?
>>>>>
>>>>> Sure:
>>>>> # brctl show
>>>>> bridge name bridge id STP enabled interfaces
>>>>> vmbr0 8000.00259084dea8 no bond0
>>>>> tap320i0
>>>>> vmbr1 8000.00259084deaa no bond1
>>>>> vmbr1v3021 8000.00259084deaa no
>>>>> tap320i1
>>>>> vmbr1.3021
>>>>
>>>> so let me see if I can understand this configuration.
>>>>
>>>> vmbr1v3021 (bridge)
>>>> / \
>>>> tap320i1 vmbr1.3021 (vlan)
>>>> \
>>>> vmbr1 (bridge)
>>>> \
>>>> bond1
>>>> \
>>>> eth X
>>>>
>>>>
>>>> Is that right? Is this the setup that has the problem you are
>>>> describing?
>>>>
>>>> Thanks
>>>> -vlad
>>>>
>>>>>> On the off chance that you are actually trying to configure vlan
>>>>>> filtering, can you give this patch a try (net-2.6 tree):
>>>>>>
>>>>>> Author: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>>> Date: Tue Aug 20 17:10:18 2013 +0900
>>>>>>
>>>>>> bridge: Use the correct bit length for bitmap functions in the
>>>>>> VLAN
>>>>>> code
>>>>>>
>>>>>> I don't think it made it to stable yet.
>>>>>
>>>>> I addd that patch and now the vlan stuff works at least on the host
>>>>> node. But my tap devices still don't work.
>>>>>
>>>>> I also tried to attach the tap device on top of a vlan attached to
>>>>> bond1
>>>>> but then gvrp does not work anymore. The kernel announces gvrp once
>>>>> and
>>>>> then does not answer the query packets from the switch.
>>>>>
>>>>> Stefan
>>>>
>>
^ permalink raw reply
* Re: [PATCH net-next v2 0/10] bonding: rebuild the lock use for bond monitor
From: Ben Hutchings @ 2013-11-12 23:26 UTC (permalink / raw)
To: David Miller; +Cc: dingtianhong, fubar, andy, nikolay, vfalico, netdev
In-Reply-To: <20131108.014550.886693705136672248.davem@davemloft.net>
On Fri, 2013-11-08 at 01:45 -0500, David Miller wrote:
> Such patches should not be submitted at this time, the merge window
> has openned up and therefore the net-next tree is closed.
>
> Please wait for the merge window to close and the net-next tree
> to open back up before submitting these changes.
These look like bug fixes that should have been submitted for the net
tree.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v2 00/19] Enable various Renesas drivers on all ARM platforms
From: Laurent Pinchart @ 2013-11-12 23:32 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Linus Walleij,
Guennadi Liakhovetski, Thierry Reding,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Laurent Pinchart, Vinod Koul,
linux-sh-u79uwXL29TY76Z2rM5mHXA, Magnus Damm, Eduardo Valentin,
Tomi Valkeinen, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Ian Molton, Mark Brown,
xfoundat@
In-Reply-To: <1383086274-11049-1-git-send-email-laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Hello,
On Tuesday 29 October 2013 23:37:35 Laurent Pinchart wrote:
> Hello,
>
> This patch series, based on v3.12-rc7, prepares various Renesas drivers
> for migration to multiplatform kernels by enabling their compilation or
> otherwise fixing them on all ARM platforms. The patches are pretty
> straightforward and are described in their commit message.
>
> Changes since v1:
>
> - The drivers can also be selected when COMPILE_TEST is enabled, regardless
> of the architecture. This should provide a good compromise between wide
> build test coverage and not clobbering configuration with drivers useless
> on non-SuperH, non-ARM platforms.
>
> - DMA configuration is now unconditional in patch 08/19
>
> I'd like to get all these patches merged in v3.14. As they will need to go
> through their respective subsystems' trees, I would appreciate if all
> maintainers involved could notify me when they merge patches from this
> series in their tree to help me tracking the merge status. I don't plan to
> send pull requests individually for these patches, and I will repost
> patches individually if changes are requested during review.
>
> If you believe the issue should be solved in a different way please reply to
> the cover letter to let other maintainers chime in.
This patch series was a prerequisite for a larger rework of Renesas platforms.
However, we've decided to go with an alternative approach that renames Kconfig
symbols to avoid touching all the drivers. There is thus no urgency to apply
this series anymore.
I still plan to enable COMPILE_TEST on Renesas drivers. I will send a v3 of
these patches based on the feedback received on v2. Patches from v2 that have
already been applied can be dropped, but there's no need to revert them rebase
trees as they're not invalid per-se. I will make sure to address the situation
in v3. I'm sorry for the inconvenience.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2/2] random32: use msecs_to_jiffies for reseed timer
From: Stephen Hemminger @ 2013-11-12 23:35 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, Hannes Frederic Sowa
In-Reply-To: <1384296342-3348-2-git-send-email-dborkman@redhat.com>
On Tue, 12 Nov 2013 23:45:42 +0100
Daniel Borkmann <dborkman@redhat.com> wrote:
> Use msecs_to_jiffies, for these calculations as different HZ
> considerations are taken into account for conversion of the timer
> shot, and also it makes the code more readable.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> lib/random32.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/lib/random32.c b/lib/random32.c
> index 4f9d5df..1e5b2df 100644
> --- a/lib/random32.c
> +++ b/lib/random32.c
> @@ -214,18 +214,22 @@ static DEFINE_TIMER(seed_timer, __prandom_timer, 0, 0);
> static void __prandom_timer(unsigned long dontcare)
> {
> u32 entropy;
> + unsigned long expires;
>
> get_random_bytes(&entropy, sizeof(entropy));
> prandom_seed(entropy);
> +
> /* reseed every ~60 seconds, in [40 .. 80) interval with slack */
> - seed_timer.expires = jiffies + (40 * HZ + (prandom_u32() % (40 * HZ)));
> + expires = 40 + (prandom_u32() % 40);
> + seed_timer.expires = jiffies + msecs_to_jiffies(expires * MSEC_PER_SEC);
> +
> add_timer(&seed_timer);
> }
>
> static void __init __prandom_start_seed_timer(void)
> {
> set_timer_slack(&seed_timer, HZ);
> - seed_timer.expires = jiffies + 40 * HZ;
> + seed_timer.expires = jiffies + msecs_to_jiffies(40 * MSEC_PER_SEC);
> add_timer(&seed_timer);
> }
>
Some questions:
1. What is the point of using msecs_to_jiffies? the older code already handled
differing HZ?
2. Why the magic 40-80 sec range? What about platforms with very low entropy
you will end up draining it faster.
3. I prefer using mod_timer rather than setting expires and call add_timer
4. You should also use round_jiffies to save power by making the wakeup on a second
boundary.
^ permalink raw reply
* Re: shutdown(3) and bluetooth.
From: Marcel Holtmann @ 2013-11-12 23:37 UTC (permalink / raw)
To: Dave Jones
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org development
In-Reply-To: <20131112224819.GE9057-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Dave,
>>> Here's the info I found in the logs, it looks like this was the only bluetooth socket.
>>>
>>> fd[195] = domain:31 (PF_BLUETOOTH) type:0x5 protocol:2
>>> Setsockopt(1 d 2134000 8) on fd 195
>>
>> this is a bit confusing. Protocol 2 is actually SCO, but the stack trace shows RFCOMM.
>
> Sorry, mixed up two separate runs. In the log above, the stack trace is actually..
>
> [<ffffffffa0492dca>] bt_sock_wait_state+0xda/0x240 [bluetooth]
> [<ffffffffa04c86d8>] sco_sock_release+0xb8/0xf0 [bluetooth]
> [<ffffffff815cb1ff>] sock_release+0x1f/0x90
> [<ffffffff815cb282>] sock_close+0x12/0x20
>
>
>>> ./trinity -P PF_BLUETOOTH -l off -c setsockopt
>>>
>>> let it run a few seconds, and then ctrl-c. The main process will never exit.
>>>
>>> 5814 pts/6 Ss 0:00 | \_ bash
>>> 5876 pts/6 S+ 0:00 | | \_ ./trinity -P PF_BLUETOOTH -l off -c setsockopt
>>> 5877 pts/6 Z+ 0:00 | | \_ [trinity] <defunct>
>>> 5878 pts/6 S+ 0:01 | | \_ [trinity-main]
>>>
>>> $ sudo cat /proc/5878/stack
>>> [<ffffffffa04397a2>] bt_sock_wait_state+0xc2/0x190 [bluetooth]
>>> [<ffffffffa0847a75>] rfcomm_sock_shutdown+0x85/0xb0 [rfcomm]
>>> [<ffffffffa0847ad9>] rfcomm_sock_release+0x39/0xb0 [rfcomm]
>
> So it seems it affects both SCO and RFCOMM.
>
>> What kernel did you run this against? It is a shot in the dark, but can you try linux-next quickly.
>> There was a socket related fix for the socket options where we confused RFCOMM vs L2CAP struct sock.
>
> first noticed it on Linus' latest HEAD, and then reproduced it on 3.11.6
> I'll look at linux-next tomorrow.
I looked through the code and only call bt_sock_wait_state when SOCK_LINGER and sk_lingertime is set. In that case we actually block until the socket state changes to BT_CLOSED.
The only way I see this could happen is if you have a huge linger timeout and confused the socket state before. What is actually the list of system calls that you are throwing at this socket.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] net/7990: Make lance_private.name const
From: Sergei Shtylyov @ 2013-11-12 23:40 UTC (permalink / raw)
To: David Miller; +Cc: geert, netdev, linux-m68k
In-Reply-To: <20131112.161253.601617211955537751.davem@davemloft.net>
On 11/13/2013 12:12 AM, David Miller wrote:
>>> @@ -100,7 +100,7 @@ struct lance_init_block {
>>> */
>>> struct lance_private
>>> {
>>> - char *name;
>>> + const char *name;
>> Indent with tab, not spaces, please.
> This whole file is %99 space indentation, you really can't blame
> Geert for this.
It's never late to fix some. And remember about checkpatch.pl which was
hardly content with the patch.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/2] random32: use msecs_to_jiffies for reseed timer
From: Hannes Frederic Sowa @ 2013-11-12 23:47 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Daniel Borkmann, davem, netdev
In-Reply-To: <20131112153512.68520cca@samsung-9>
On Tue, Nov 12, 2013 at 03:35:12PM -0800, Stephen Hemminger wrote:
> On Tue, 12 Nov 2013 23:45:42 +0100
> Daniel Borkmann <dborkman@redhat.com> wrote:
>
> > Use msecs_to_jiffies, for these calculations as different HZ
> > considerations are taken into account for conversion of the timer
> > shot, and also it makes the code more readable.
> >
> > Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > ---
> > lib/random32.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/random32.c b/lib/random32.c
> > index 4f9d5df..1e5b2df 100644
> > --- a/lib/random32.c
> > +++ b/lib/random32.c
> > @@ -214,18 +214,22 @@ static DEFINE_TIMER(seed_timer, __prandom_timer, 0, 0);
> > static void __prandom_timer(unsigned long dontcare)
> > {
> > u32 entropy;
> > + unsigned long expires;
> >
> > get_random_bytes(&entropy, sizeof(entropy));
> > prandom_seed(entropy);
> > +
> > /* reseed every ~60 seconds, in [40 .. 80) interval with slack */
> > - seed_timer.expires = jiffies + (40 * HZ + (prandom_u32() % (40 * HZ)));
> > + expires = 40 + (prandom_u32() % 40);
> > + seed_timer.expires = jiffies + msecs_to_jiffies(expires * MSEC_PER_SEC);
> > +
> > add_timer(&seed_timer);
> > }
> >
> > static void __init __prandom_start_seed_timer(void)
> > {
> > set_timer_slack(&seed_timer, HZ);
> > - seed_timer.expires = jiffies + 40 * HZ;
> > + seed_timer.expires = jiffies + msecs_to_jiffies(40 * MSEC_PER_SEC);
> > add_timer(&seed_timer);
> > }
> >
>
> Some questions:
> 1. What is the point of using msecs_to_jiffies? the older code already handled
> differing HZ?
The change is not that important. It seemed a bit more readable. We could
certainly drop that.
> 2. Why the magic 40-80 sec range? What about platforms with very low entropy
> you will end up draining it faster.
Daniel and me had a discussion about that. I originally had it even lower and
Daniel warned about that. The current window seemd fine to me as we don't want
to have a too big window where one could probe ports if an attacker could find
a bias in the PRNG. Do you have a suggestion?
> 3. I prefer using mod_timer rather than setting expires and call add_timer
I wanted the BUG_ON in add_timer in the code path so we can make sure no
two timers are running concurrently. Would be no problem to change that.
> 4. You should also use round_jiffies to save power by making the wakeup on a second
> boundary.
We already apply slack when initializing the timer:
static void prandom_start_seed_timer(void)
{
set_timer_slack(&seed_timer, HZ);
seed_timer.expires = jiffies + 40 * HZ;
add_timer(&seed_timer);
}
It thus does get rounded by apply_slack in mod_timer.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH] net/7990: Make lance_private.name const
From: Sergei Shtylyov @ 2013-11-13 0:04 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: David Miller, netdev@vger.kernel.org, Linux/m68k
In-Reply-To: <CAMuHMdVn6MFbXgdE_teYW10OfYBjyZsN7v2yTTAsKj0kXao7Hw@mail.gmail.com>
On 11/13/2013 01:44 AM, Geert Uytterhoeven wrote:
>>>>> @@ -100,7 +100,7 @@ struct lance_init_block {
>>>>> */
>>>>> struct lance_private
>>>>> {
>>>>> - char *name;
>>>>> + const char *name;
>>>> Indent with tab, not spaces, please.
>>> This whole file is %99 space indentation, you really can't blame
>>> Geert for this.
>> It's never late to fix some.
> That would be a separate patch. Care to create and send it?
I wasn't telling you to fix all of them, just the ones you touched anyway.
I don't see why the separate patch is needed for that.
>> And remember about checkpatch.pl which was hardly content with the patch.
> Only because checkpatch looks at the _new_ lines, and doesn't compare the
> styles of the old and new lines.
Care to fix it? :-)
> Gr{oetje,eeting}s,
> Geert
WBR, Sergei
^ permalink raw reply
* Re: shutdown(3) and bluetooth.
From: Dave Jones @ 2013-11-13 0:28 UTC (permalink / raw)
To: Marcel Holtmann
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org development
In-Reply-To: <D8BE686E-E81D-48CD-8D67-2B138191E0CC-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
On Wed, Nov 13, 2013 at 08:37:15AM +0900, Marcel Holtmann wrote:
> > So it seems it affects both SCO and RFCOMM.
> >
> >> What kernel did you run this against? It is a shot in the dark, but can you try linux-next quickly.
> >> There was a socket related fix for the socket options where we confused RFCOMM vs L2CAP struct sock.
> >
> > first noticed it on Linus' latest HEAD, and then reproduced it on 3.11.6
> > I'll look at linux-next tomorrow.
>
> I looked through the code and only call bt_sock_wait_state when SOCK_LINGER and sk_lingertime is set. In that case we actually block until the socket state changes to BT_CLOSED.
>
> The only way I see this could happen is if you have a huge linger timeout and confused the socket state before. What is actually the list of system calls that you are throwing at this socket.
Ah. I recently changed some code that's now doing this on every socket at shutdown..
(simplified cut-n-paste)
struct linger ling = { .l_onoff = FALSE, };
for (i = 0; i < nr_sockets; i++) {
fd = shm->sockets[i].fd;
shm->sockets[i].fd = 0;
setsockopt(fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(struct linger));
shutdown(fd, SHUT_RDWR);
close(fd);
}
I could just rip out that linger code completely and just hope that sockets staying in
TIME_WAIT is good enough. iirc, I added it when after multiple runs, some of the
weirder protocols would fail to open a socket once a certain number of existing
sockets had opened, even if they were in SOCK_WAIT
two remaining questions though. That code is setting linger to false. Why would
that cause the sk_lingertime to be taken into consideration ? And why is this
only a problem for bluetooth (apparently) ?
Dave
^ permalink raw reply
* Re: [PATCH] net:fec: fix WARNING caused by lack of calls to dma_mapping_error()
From: Ben Hutchings @ 2013-11-13 1:00 UTC (permalink / raw)
To: Fugang Duan; +Cc: b20596, davem, netdev
In-Reply-To: <1384224889-8316-1-git-send-email-B38611@freescale.com>
On Tue, 2013-11-12 at 10:54 +0800, Fugang Duan wrote:
> Enable CONFIG_HAVE_DMA_API_DEBUG, the kernel dump warning:
[...]
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index b2793b9..d93cb0c 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -386,7 +386,11 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> */
> bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, bufaddr,
> FEC_ENET_TX_FRSIZE, DMA_TO_DEVICE);
> -
> + if (dma_mapping_error(&fep->pdev->dev, bdp->cbd_bufaddr)) {
> + bdp->cbd_bufaddr = 0;
> + netdev_err(ndev, "Tx DMA memory map failed\n");
> + return NETDEV_TX_OK;
This error path must free the skb.
> + }
> /* Send it on its way. Tell FEC it's ready, interrupt when done,
> * it's the last BD of the frame, and to put the CRC on the end.
> */
> @@ -1001,6 +1005,9 @@ fec_enet_rx(struct net_device *ndev, int budget)
>
> bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, data,
> FEC_ENET_TX_FRSIZE, DMA_FROM_DEVICE);
> + /* here dma mapping shouldn't be error, just avoid kernel dump */
> + if (dma_mapping_error(&fep->pdev->dev, bdp->cbd_bufaddr))
> + netdev_err(ndev, "Rx DMA memory map failed\n");
This is not handling the error.
> rx_processing_done:
> /* Clear the status flags for this buffer */
> status &= ~BD_ENET_RX_STATS;
> @@ -1719,6 +1726,11 @@ static int fec_enet_alloc_buffers(struct net_device *ndev)
>
> bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, skb->data,
> FEC_ENET_RX_FRSIZE, DMA_FROM_DEVICE);
> + if (dma_mapping_error(&fep->pdev->dev, bdp->cbd_bufaddr)) {
> + fec_enet_free_buffers(ndev);
> + netdev_err(ndev, "Rx DMA memory map failed\n");
> + return -ENOMEM;
> + }
> bdp->cbd_sc = BD_ENET_RX_EMPTY;
>
> if (fep->bufdesc_ex) {
Error logging should be rate-limited.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH V2] usbnet: fix race condition caused spinlock bad magic issue
From: wangbiao @ 2013-11-13 1:11 UTC (permalink / raw)
To: oneukum-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, mingo-X9Un+BFzKDI,
a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw, rusty-8n+1lVoiYb80n/F98K4Iww,
william.douglas-ral2JQCrhuEAvxtiuMwx3w,
di.zhang-ral2JQCrhuEAvxtiuMwx3w, biao.wang-ral2JQCrhuEAvxtiuMwx3w
From: wang, biao <biao.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date: Mon, 11 Nov 2013 10:23:40 +0800
Subject: [PATCH] usbnet: fix race condition caused spinlock bad magic issue
1, there is race between usbnet_terminate_urbs and usbnet_bh, when
unlink_wakeup used in usbnet_bh, it may be already freed and used by
other function as unlink_wakeup was a local var on stack.
for example:
cpu 0: cpu 1:
usb_suspend_both
->usbnet_suspend
usbnet_bh ->usbnet_terminate_urbs
->__wake_up
->_raw_spin_unlock_irqrestore
->do_raw_spin_unlock
->spin_bug
when usbnet_terminate_urbs complete execution and memory of unlink_wakeup was
used by other function, then usbnet_bh may still use it.
2, for the same reason,dev->wait should be judged again before use it,
as between the judge point(if(dev->wait)) and use point(wakeup(dev->wait)),
the dev->wait may be set NULL by another cpu.
for issue 1, declare unlink_wakeup in global section instead of on stack.
for issue 2, use a temporary local var to keep the value of dev->wait
in stack and judge it before using.
Signed-off-by: wang, biao <biao.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Acked-by: Ingo Molnar <mingo.kernel.org-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
Acked-by: Zhang, Di <di.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
drivers/net/usb/usbnet.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 90a429b..0603ef6 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -86,6 +86,7 @@ static const char driver_name [] = "usbnet";
/* use ethtool to change the level for any given device */
static int msg_level = -1;
+static DECLARE_WAIT_QUEUE_HEAD(unlink_wakeup);
module_param (msg_level, int, 0);
MODULE_PARM_DESC (msg_level, "Override default message level");
@@ -761,7 +762,6 @@ EXPORT_SYMBOL_GPL(usbnet_unlink_rx_urbs);
// precondition: never called in_interrupt
static void usbnet_terminate_urbs(struct usbnet *dev)
{
- DECLARE_WAIT_QUEUE_HEAD_ONSTACK(unlink_wakeup);
DECLARE_WAITQUEUE(wait, current);
int temp;
@@ -1449,7 +1449,9 @@ static void usbnet_bh (unsigned long param)
// waiting for all pending urbs to complete?
if (dev->wait) {
if ((dev->txq.qlen + dev->rxq.qlen + dev->done.qlen) == 0) {
- wake_up (dev->wait);
+ wait_queue_head_t *wait_d = dev->wait;
+ if (wait_d)
+ wake_up(wait_d);
}
// or are we maybe short a few urbs?
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: gso: Handle new frag_list of frags GRO packets
From: Eric Dumazet @ 2013-11-13 1:13 UTC (permalink / raw)
To: Herbert Xu
Cc: Ben Hutchings, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131111185207.GA12277@gondor.apana.org.au>
On Tue, 2013-11-12 at 02:52 +0800, Herbert Xu wrote:
> Recently GRO started generating packets with frag_lists of frags.
> This was not handled by GSO, thus leading to a crash.
>
> Thankfully these packets are of a regular form and are easy to
> handle. This patch handles them in two ways. For completely
> non-linear frag_list entries, we simply continue to iterate over
> the frag_list frags once we exhaust the normal frags. For frag_list
> entries with linear parts, we call pskb_trim on the first part
> of the frag_list skb, and then process the rest of the frags in
> the usual way.
>
> This patch also kills a chunk of dead frag_list code that has
> obviously never ever been run since it ends up generating a bogus
> GSO-segmented packet with a frag_list entry.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 3735fad..557e1a5 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -2776,6 +2776,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> struct sk_buff *segs = NULL;
> struct sk_buff *tail = NULL;
> struct sk_buff *fskb = skb_shinfo(skb)->frag_list;
> + skb_frag_t *skb_frag = skb_shinfo(skb)->frags;
> unsigned int mss = skb_shinfo(skb)->gso_size;
> unsigned int doffset = skb->data - skb_mac_header(skb);
> unsigned int offset = doffset;
> @@ -2815,16 +2816,38 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> if (hsize > len || !sg)
> hsize = len;
>
> - if (!hsize && i >= nfrags) {
> - BUG_ON(fskb->len != len);
> + if (!hsize && i >= nfrags && skb_headlen(fskb) &&
> + (skb_headlen(fskb) == len || sg)) {
> + BUG_ON(skb_headlen(fskb) > len);
> +
Hmm, yet another BUG_ON() case...
> + i = 0;
> + nfrags = skb_shinfo(fskb)->nr_frags;
> + skb_frag = skb_shinfo(fskb)->frags;
> + pos += skb_headlen(fskb);
> +
> + while (pos < offset + len) {
> + BUG_ON(i >= nfrags);
> +
> + size = skb_frag_size(skb_frag);
> + if (pos + size > offset + len)
> + break;
> +
> + i++;
> + pos += size;
> + skb_frag++;
> + }
>
> - pos += len;
> nskb = skb_clone(fskb, GFP_ATOMIC);
> fskb = fskb->next;
>
> if (unlikely(!nskb))
> goto err;
>
> + if (unlikely(pskb_trim(nskb, len))) {
> + kfree_skb(nskb);
> + goto err;
> + }
> +
Note this pskb_trim() will reallocate/copy nskb head completely, since
nskb is a clone. (And increment page counts of frags, then eventually
decrement them)
I tested this patch one 'router', and it seems fine, although we consume
~90% more cpu doing the skb_segment() than not doing it.
GRO not building frag_list skbs :
lpaa6:~# mpstat -P 8 1 10
05:09:47 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle intr/s
05:09:48 PM 8 0.00 0.00 1.01 0.00 3.03 23.23 0.00 0.00 72.73 43462.63
05:09:49 PM 8 0.00 0.00 0.00 0.00 5.10 28.57 0.00 0.00 66.33 88079.59
05:09:50 PM 8 0.00 0.00 0.00 0.00 2.13 17.02 0.00 0.00 80.85 41297.87
05:09:51 PM 8 0.00 0.00 0.95 0.00 3.81 29.52 0.00 0.00 65.71 45741.90
05:09:52 PM 8 0.00 0.00 0.00 0.00 2.11 17.89 0.00 0.00 80.00 25413.68
05:09:53 PM 8 1.03 0.00 1.03 0.00 2.06 20.62 0.00 0.00 75.26 36131.96
05:09:54 PM 8 0.00 0.00 0.94 0.00 3.77 30.19 0.00 0.00 65.09 47100.00
05:09:55 PM 8 0.00 0.00 0.00 0.00 3.26 21.74 0.00 0.00 75.00 71805.43
05:09:56 PM 8 0.00 0.00 0.00 0.00 3.19 22.34 0.00 0.00 74.47 70672.34
05:09:57 PM 8 0.00 0.00 0.00 0.00 4.50 32.43 0.00 0.00 63.06 45919.82
Average: 8 0.10 0.00 0.40 0.00 3.33 24.62 0.00 0.00 71.54 51339.66
Current GRO (large skbs -> need to split them with skb_segment(), no TSO is used)
lpaa6:~# mpstat -P 8 1 10
05:10:05 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle intr/s
05:10:06 PM 8 0.00 0.00 0.00 0.00 8.16 44.90 0.00 0.00 46.94 88982.65
05:10:07 PM 8 0.00 0.00 1.05 0.00 8.42 50.53 0.00 0.00 40.00 54796.84
05:10:08 PM 8 0.00 0.00 1.94 0.00 8.74 52.43 0.00 0.00 36.89 50163.11
05:10:09 PM 8 0.00 0.00 0.00 0.00 7.14 39.80 0.00 0.00 53.06 85137.76
05:10:10 PM 8 0.00 0.00 0.00 0.00 8.08 44.44 0.00 0.00 47.47 42262.63
05:10:11 PM 8 0.00 0.00 0.00 0.00 8.00 53.00 0.00 0.00 39.00 53444.00
05:10:12 PM 8 0.00 0.00 0.00 0.00 5.00 27.50 0.00 0.00 67.50 91098.75
05:10:13 PM 8 0.00 0.00 0.00 0.00 8.55 47.86 0.00 0.00 43.59 34316.24
05:10:14 PM 8 0.00 0.00 0.00 0.00 8.70 48.91 0.00 0.00 42.39 56921.74
05:10:15 PM 8 0.00 0.00 0.93 0.00 7.41 46.30 0.00 0.00 45.37 77129.63
Average: 8 0.00 0.00 0.40 0.00 7.88 45.96 0.00 0.00 45.76 62458.99
^ 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