* 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
* Fw: [Bug 63321] tcp_fastretrans_alert
From: Stephen Hemminger @ 2013-11-13 1:26 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Tue, 12 Nov 2013 08:43:45 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 63321] tcp_fastretrans_alert
https://bugzilla.kernel.org/show_bug.cgi?id=63321
--- Comment #3 from root@securitydot.net ---
Once again someone is delaying a fix for a major issue causing a lot of
trouble. Please fix it...
WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_input.c:2711
tcp_fastretrans_alert+0x56c/0x580()
Modules linked in: iptable_filter ip_tables autofs4 bonding ipv6 xt_LOG
ipt_REJECT xt_multiport xfs libcrc32c gpio_ich iTCO_wdt iTCO_vendor_support
joydev raid0 microcode pcspkr serio_raw sg lpc_ich hpilo hpwdt e1000e ptp
pps_core freq_table mperf ext4 jbd2 mbcache xts gf128mul dm_crypt raid1 sd_mod
crc_t10dif ahci libahci mgag200 ttm drm_kms_helper sysimgblt sysfillrect
syscopyarea dm_mirror dm_region_hash dm_log dm_mod
CPU: 2 PID: 0 Comm: swapper/2 Tainted: G W 3.11.6-1.el6.elrepo.x86_64
#1
Hardware name: HP ProLiant DL120 G7, BIOS J01 02/01/2012
0000000000000a97 ffff88020b4438e0 ffffffff815f7f89 0000000000000a97
0000000000000000 ffff88020b443920 ffffffff8106705c ffff880200138000
ffff8800beb7c880 0000000000000009 0000000000004120 0000000000000001
Call Trace:
<IRQ> [<ffffffff815f7f89>] dump_stack+0x49/0x60
[<ffffffff8106705c>] warn_slowpath_common+0x8c/0xc0
[<ffffffff810670aa>] warn_slowpath_null+0x1a/0x20
[<ffffffff8158425c>] tcp_fastretrans_alert+0x56c/0x580
[<ffffffff81585d3f>] tcp_ack+0x34f/0x7d0
[<ffffffff81586e5a>] tcp_rcv_established+0x2ca/0x700
[<ffffffff81590309>] tcp_v4_do_rcv+0x169/0x290
[<ffffffff81591c81>] tcp_v4_rcv+0x601/0x760
[<ffffffff8156ce90>] ? ip_rcv+0x350/0x350
[<ffffffff8156325d>] ? nf_hook_slow+0x7d/0x150
[<ffffffff8156ce90>] ? ip_rcv+0x350/0x350
[<ffffffff8156cf5e>] ip_local_deliver_finish+0xce/0x250
[<ffffffff8156d168>] ip_local_deliver+0x88/0x90
[<ffffffff8150a01f>] ? __alloc_and_insert_iova_range+0x17f/0x1f0
[<ffffffff8156c7b9>] ip_rcv_finish+0x119/0x360
[<ffffffff8156cdad>] ip_rcv+0x26d/0x350
[<ffffffffa0383880>] ? bond_hw_addr_swap+0x120/0x120 [bonding]
[<ffffffff81536f4e>] __netif_receive_skb_core+0x53e/0x6f0
[<ffffffff81537127>] __netif_receive_skb+0x27/0x70
[<ffffffff8153739d>] netif_receive_skb+0x2d/0x90
[<ffffffff81537fa8>] napi_gro_receive+0xb8/0x140
[<ffffffffa019745a>] e1000_receive_skb+0x7a/0xf0 [e1000e]
[<ffffffffa019a900>] e1000_clean_rx_irq+0x2a0/0x4a0 [e1000e]
[<ffffffffa019d1ed>] e1000e_poll+0xbd/0x2d0 [e1000e]
[<ffffffff81537ab2>] net_rx_action+0x112/0x290
[<ffffffff814df346>] ? cpuidle_enter_state+0x56/0xd0
[<ffffffff8106c147>] __do_softirq+0xf7/0x270
[<ffffffff81606adc>] call_softirq+0x1c/0x30
[<ffffffff81015885>] do_softirq+0x65/0xa0
[<ffffffff8106be75>] irq_exit+0xc5/0xd0
[<ffffffff816073e6>] do_IRQ+0x66/0xe0
[<ffffffff815fc6ed>] common_interrupt+0x6d/0x6d
<EOI> [<ffffffff814df346>] ? cpuidle_enter_state+0x56/0xd0
[<ffffffff814df33f>] ? cpuidle_enter_state+0x4f/0xd0
[<ffffffff814df79d>] cpuidle_idle_call+0xcd/0x160
[<ffffffff8101c70e>] arch_cpu_idle+0xe/0x30
[<ffffffff810bb109>] cpu_idle_loop+0x69/0x210
[<ffffffff810bb320>] cpu_startup_entry+0x70/0x80
[<ffffffff810437bd>] start_secondary+0xcd/0xd0
---[ end trace 858cf267ca4ce6b0 ]---
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: gso: Handle new frag_list of frags GRO packets
From: Herbert Xu @ 2013-11-13 1:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ben Hutchings, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <1384305223.28458.58.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Nov 12, 2013 at 05:13:43PM -0800, Eric Dumazet wrote:
>
> 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.
I presume this is on a NIC that produces completely linear packets?
I wonder what happens if we don't convert head_frag to frags and just
use frag_lists like we used to?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 1/1] net: sctp: bug fixing when sctp path recovers
From: Chang Xiangzhong @ 2013-11-13 1:34 UTC (permalink / raw)
To: vyasevich, nhorman, davem
Cc: linux-sctp, netdev, linux-kernel, dreibh, Chang Xiangzhong
Look for the __two__ most recently used path/transport and set to active_path
and retran_path respectively
Signed-off-by: changxiangzhong@gmail.com
---
net/sctp/associola.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index ab67efc..070011a 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -913,11 +913,15 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
if (!first || t->last_time_heard > first->last_time_heard) {
second = first;
first = t;
+ continue;
}
if (!second || t->last_time_heard > second->last_time_heard)
second = t;
}
+ if (!second)
+ second = first;
+
/* RFC 2960 6.4 Multi-Homed SCTP Endpoints
*
* By default, an endpoint should always transmit to the
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] net:fec: fix WARNING caused by lack of calls to dma_mapping_error()
From: Ben Hutchings @ 2013-11-13 1:43 UTC (permalink / raw)
To: Fugang Duan; +Cc: b20596, davem, netdev
In-Reply-To: <1384304453.3802.62.camel@bwh-desktop.uk.level5networks.com>
On Wed, 2013-11-13 at 01:00 +0000, Ben Hutchings wrote:
> On Tue, 2013-11-12 at 10:54 +0800, Fugang Duan wrote:
> > Enable CONFIG_HAVE_DMA_API_DEBUG, the kernel dump warning:
[...]
> > @@ -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.
[...]
It looks like the same RX DMA buffers are used repeatedly and the driver
copies into an skb. So fec_enet_rx() should not map or unmap at all; it
should use dma_sync_single_for_cpu(). Then, indeed, no error handling
is required.
But there's still a big problem with this function. Instead of
remembering the virtual address of each buffer, it passes the DMA
address to __va(). Physical and DMA addresses are *not* the same thing!
They may differ if the device is behind an IOMMU or bounce buffering was
required, or just because there is a fixed offset between the device and
host physical addresses.
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: Fw: [Bug 63321] tcp_fastretrans_alert
From: Ben Hutchings @ 2013-11-13 1:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20131112172615.498b3ac9@samsung-9>
On Tue, 2013-11-12 at 17:26 -0800, Stephen Hemminger wrote:
>
> Begin forwarded message:
>
> Date: Tue, 12 Nov 2013 08:43:45 -0800
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 63321] tcp_fastretrans_alert
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=63321
>
> --- Comment #3 from root@securitydot.net ---
> Once again someone is delaying a fix for a major issue causing a lot of
> trouble. Please fix it...
>
> WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_input.c:2711
> tcp_fastretrans_alert+0x56c/0x580()
[...]
> CPU: 2 PID: 0 Comm: swapper/2 Tainted: G W 3.11.6-1.el6.elrepo.x86_64
I think this is fixed by:
commit 031afe4990a7c9dbff41a3a742c44d3e740ea0a1
Author: Yuchung Cheng <ycheng@google.com>
Date: Sat Oct 12 10:16:27 2013 -0700
tcp: fix incorrect ca_state in tail loss probe
which went into 3.12-rc7 and then 3.11.7.
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: shutdown(3) and bluetooth.
From: Marcel Holtmann @ 2013-11-13 1:58 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev, linux-bluetooth@vger.kernel.org development
In-Reply-To: <20131113002819.GB12615@redhat.com>
Hi Dave,
>>> 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) ?
we are not touching that part of setsockopt. That is handled by net/core/sock.c and we just check if SOCK_LINGER flag is set and if we have a positive sk_lingertime. So this is a bit suspicious on why this is happening, but I don’t think it is our mistake.
Regards
Marcel
^ permalink raw reply
* RE: [PATCH] net:fec: fix WARNING caused by lack of calls to dma_mapping_error()
From: Fugang Duan @ 2013-11-13 2:10 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Frank Li, davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1384306989.3802.71.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Data: Wednesday, November 13, 2013 9:43 AM
>To: Duan Fugang-B38611
>Cc: Li Frank-B20596; davem@davemloft.net; netdev@vger.kernel.org
>Subject: Re: [PATCH] net:fec: fix WARNING caused by lack of calls to
>dma_mapping_error()
>
>On Wed, 2013-11-13 at 01:00 +0000, Ben Hutchings wrote:
>> On Tue, 2013-11-12 at 10:54 +0800, Fugang Duan wrote:
>> > Enable CONFIG_HAVE_DMA_API_DEBUG, the kernel dump warning:
>[...]
>> > @@ -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.
>[...]
>
>It looks like the same RX DMA buffers are used repeatedly and the driver copies
>into an skb. So fec_enet_rx() should not map or unmap at all; it should use
>dma_sync_single_for_cpu(). Then, indeed, no error handling is required.
>
Yes, there don't need to use dma_unmap_single()/dma_map_single() since the fec_enet_alloc_buffers() have mapped the virtual address.
I will change it. Thanks.
>But there's still a big problem with this function. Instead of remembering the
>virtual address of each buffer, it passes the DMA address to __va(). Physical
>and DMA addresses are *not* the same thing!
>They may differ if the device is behind an IOMMU or bounce buffering was
>required, or just because there is a fixed offset between the device and host
>physical addresses.
>
Yes, I agree that physical and DMA addresses are not the same thing.
But for imx serial platforms, there have no IOMMU, no offset between device and host physical address(this happen on FPGA platforms in mostly), so there have no problem.
I agree it is not common for other platforms like IOMMU...
Since it is another problem, I will submit another patch to fix the problem.
Thanks, Ben.
>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
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