* Re: [PATCH 7/7] ns: Wire up the setns system call
From: James Bottomley @ 2011-05-07 20:06 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-arch, linux-kernel, netdev, linux-fsdevel, jamal,
Daniel Lezcano, Linux Containers, Renato Westphal
In-Reply-To: <1304735101-1824-7-git-send-email-ebiederm@xmission.com>
On Fri, 2011-05-06 at 19:25 -0700, Eric W. Biederman wrote:
> v2: Most of the architecture support added by Daniel Lezcano <dlezcano@fr.ibm.com>
> v3: ported to v2.6.36-rc4 by: Eric W. Biederman <ebiederm@xmission.com>
> v4: Moved wiring up of the system call to another patch
> v5: ported to v2.6.39-rc6
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
We already have several syscalls queued up for parisc:
http://git.kernel.org/?p=linux/kernel/git/jejb/parisc-2.6.git;a=shortlog;h=refs/heads/misc
So if you could make this patch over them (or over linux-next), that
would help the merge process.
Thanks,
James
^ permalink raw reply
* Re: [PATCH] net/bonding: adjust codingstyle for bond_3ad files
From: matt mooney @ 2011-05-07 19:35 UTC (permalink / raw)
To: Joe Perches
Cc: aquini, kernel-janitors, David Miller, Jay Vosburgh,
Andy Gospodarek, shemminger, netdev, Nicolas Kaiser
In-Reply-To: <1304791360.1738.6.camel@Joe-Laptop>
On Sat, May 7, 2011 at 11:02 AM, Joe Perches <joe@perches.com> wrote:
> On Sat, 2011-05-07 at 14:31 -0300, Rafael Aquini wrote:
>> To exemplify my point, I'll taking that very __ad_timer_to_ticks() as an example:
>> static u16 __ad_timer_to_ticks(u16 timer_type, u16 par)
>> {
>> u16 retval = 0;
>>
>> switch (timer_type) {
>> case AD_CURRENT_WHILE_TIMER: /* for rx machine usage */
>> if (par)
>> retval = (AD_SHORT_TIMEOUT_TIME*ad_ticks_per_sec);
>> else
>> retval = (AD_LONG_TIMEOUT_TIME*ad_ticks_per_sec);
>> break;
>> case AD_ACTOR_CHURN_TIMER: /* for local churn machine */
>> retval = (AD_CHURN_DETECTION_TIME*ad_ticks_per_sec);
>> break;
>> case AD_PERIODIC_TIMER: /* for periodic machine */
>> retval = (par*ad_ticks_per_sec);
>> break;
>> case AD_PARTNER_CHURN_TIMER: /* for remote churn machine */
>> retval = (AD_CHURN_DETECTION_TIME*ad_ticks_per_sec);
>> break;
>> case AD_WAIT_WHILE_TIMER: /* for selection machine */
>> retval = (AD_AGGREGATE_WAIT_TIME*ad_ticks_per_sec);
>> break;
>> }
>> return retval;
>> }
>>
>> If, for some unknown reason timer_type receives an 'alien' value, and
>> we were
>> using retval uninitialized, this function, as it is, would return an
>> unpredictable value to its caller. Unless we have the switch block
>> re-factored, we cannot leave retval uninitialized. So, it's not just a
>> matter of leaving the variable uninitialized, or initialize it just to
>> get rid of a compiler warning. That's why those comments are not
>> helpful anyway.
>
> I'd write this not using a retval variable at all as:
But isn't the preferred style to have a single exit point?
> switch (timer_type) {
> case AD_CURRENT_WHILE_TIMER: /* for rx machine usage */
> if (par)
> return AD_SHORT_TIMEOUT_TIME * ad_ticks_per_sec;
> return AD_LONG_TIMEOUT_TIME * ad_ticks_per_sec;
> case AD_ACTOR_CHURN_TIMER: /* for local churn machine */
> return AD_CHURN_DETECTION_TIME * ad_ticks_per_sec;
> ...
> }
> WARN(1, "Invalid timer type: %u\n", timer_type)
> return 0;
> }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
GPG-Key: 9AFE00EA
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Eric Dumazet @ 2011-05-07 19:24 UTC (permalink / raw)
To: Alex Bligh; +Cc: netdev
In-Reply-To: <270382A9E068495F7E8A14CC@Ximines.local>
Le samedi 07 mai 2011 à 19:51 +0100, Alex Bligh a écrit :
>
> --On 7 May 2011 20:32:54 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Well, there is also one rcu_barrier() call that is expensive.
> > (It was changed from one synchronize_rcu() to one rcu_barrier() lately
> > in commit ef885afb , in 2.6.36 kernel)
>
> I think you are saying it may be waiting in rcu_barrier(). I'll
> instrument that later plus synchronize_sched().
>
> > http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi
> > tdiff;h=ef885afbf8a37689afc1d9d545e2f3e7a8276c17
>
> OK, so in head, which I am using, rollback_registered_many which
> previously had 2 calls to synchronize_net(), now has one, followed
> by a call to rc_barrier() at the bottom.
>
each device dismantle needs 2 synchronize_rcu() and one rcu_barrier()
> Right, that's what I patched before (see patch attached to
> message from earlier today) to do an exponential backoff (see
> previous entry), i.e. do a 5ms sleep, then a 10ms, then a 20ms, but
> never more than 250ms. It made no difference.
>
Oh well. How many time are you going to tell us about this ?
We suggested to wait no more than 1 ms, or even shout asap.
If after synchronize_rcu() and rcu_barrier() calls, they are still
references to the device, then there is a BUG somewhere.
Since these bugs are usually not fatal, we just wait a bit.
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Alex Bligh @ 2011-05-07 18:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Alex Bligh
In-Reply-To: <1304793174.3207.22.camel@edumazet-laptop>
--On 7 May 2011 20:32:54 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Well, there is also one rcu_barrier() call that is expensive.
> (It was changed from one synchronize_rcu() to one rcu_barrier() lately
> in commit ef885afb , in 2.6.36 kernel)
I think you are saying it may be waiting in rcu_barrier(). I'll
instrument that later plus synchronize_sched().
> http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi
> tdiff;h=ef885afbf8a37689afc1d9d545e2f3e7a8276c17
OK, so in head, which I am using, rollback_registered_many which
previously had 2 calls to synchronize_net(), now has one, followed
by a call to rc_barrier() at the bottom.
> netdev_wait_allrefs() waits that all references to a device vanishes.
>
> It currently uses a _very_ pessimistic 250 ms delay between each probe.
> Some users reported that no more than 4 devices can be dismantled per
> second, this is a pretty serious problem for some setups.
Right, that's what I patched before (see patch attached to
message from earlier today) to do an exponential backoff (see
previous entry), i.e. do a 5ms sleep, then a 10ms, then a 20ms, but
never more than 250ms. It made no difference.
> time to remove 50 ipip tunnels on a UP machine :
>
> before patch : real 11.910s
> after patch : real 1.250s
Sadly I don't see that improvement!
--
Alex Bligh
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Alex Bligh @ 2011-05-07 18:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Alex Bligh
In-Reply-To: <1304793749.3207.26.camel@edumazet-laptop>
--On 7 May 2011 20:42:29 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Here is my trace here for one device deletion on one 8 core machine
>
> [ 800.447012] synchronize_rcu() in 15787 us
> [ 800.455013] synchronize_rcu() in 7682 us
> [ 800.464019] rcu_barrier() in 8487 us
Would you mind trying it with my script to do veth devices? kill udev and do
unshare -n first.
I've done this on 2 different lots of hardware now, with 3 kernels 18
months apart.
$ grep RCU .config
# RCU Subsystem
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=64
# CONFIG_RCU_FANOUT_EXACT is not set
CONFIG_RCU_FAST_NO_HZ=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
--
Alex Bligh
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Eric Dumazet @ 2011-05-07 18:44 UTC (permalink / raw)
To: Alex Bligh; +Cc: netdev
In-Reply-To: <472A3314CA89E2E5270E320A@Ximines.local>
Le samedi 07 mai 2011 à 19:38 +0100, Alex Bligh a écrit :
>
> --On 7 May 2011 18:26:29 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> ># time rmmod dummy
> >
> > real 0m0.111s
> > user 0m0.000s
> > sys 0m0.000s
> >
> >
> > This removed my two dummy0/dummy1 devices.
>
> rmmod dummy even with numdummies=100 does only one synchronize_net() and
> is quick (0.8ms).
>
Yes, thanks to batching we added some time ago to speedup module unload.
And because you didnt setup IP addresses on them ;)
for i in `seq 0 99`
do
ifconfig dummy$i 192.168.$i.1 up
done
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Eric Dumazet @ 2011-05-07 18:42 UTC (permalink / raw)
To: Alex Bligh; +Cc: netdev
In-Reply-To: <1304793174.3207.22.camel@edumazet-laptop>
Here is my trace here for one device deletion on one 8 core machine
[ 800.447012] synchronize_rcu() in 15787 us
[ 800.455013] synchronize_rcu() in 7682 us
[ 800.464019] rcu_barrier() in 8487 us
Not that bad.
$ grep RCU .config
# RCU Subsystem
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_TRACE=y
CONFIG_RCU_FANOUT=32
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
CONFIG_TREE_RCU_TRACE=y
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Eric Dumazet @ 2011-05-07 18:39 UTC (permalink / raw)
To: Alex Bligh; +Cc: netdev
In-Reply-To: <1304793174.3207.22.camel@edumazet-laptop>
Le samedi 07 mai 2011 à 20:32 +0200, Eric Dumazet a écrit :
Also you could patch synchronize_sched() itself instead of
synchronize_net()
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index dd4aea8..4af6e10 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -1518,6 +1518,7 @@ EXPORT_SYMBOL_GPL(call_rcu_bh);
void synchronize_sched(void)
{
struct rcu_synchronize rcu;
+ ktime_t time_start = ktime_get();
if (rcu_blocking_is_gp())
return;
@@ -1529,6 +1530,7 @@ void synchronize_sched(void)
/* Wait for it. */
wait_for_completion(&rcu.completion);
destroy_rcu_head_on_stack(&rcu.head);
+ pr_err("synchronize_rcu() in %lld us\n", ktime_us_delta(ktime_get(), time_start));
}
EXPORT_SYMBOL_GPL(synchronize_sched);
^ permalink raw reply related
* Re: Scalability of interface creation and deletion
From: Alex Bligh @ 2011-05-07 18:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Alex Bligh
In-Reply-To: <1304785589.3207.5.camel@edumazet-laptop>
--On 7 May 2011 18:26:29 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote:
># time rmmod dummy
>
> real 0m0.111s
> user 0m0.000s
> sys 0m0.000s
>
>
> This removed my two dummy0/dummy1 devices.
rmmod dummy even with numdummies=100 does only one synchronize_net() and
is quick (0.8ms).
--
Alex Bligh
^ permalink raw reply
* Re: For the netdev list
From: Francois Romieu @ 2011-05-07 18:26 UTC (permalink / raw)
To: Tom Goetz; +Cc: netdev
In-Reply-To: <14130884-5927-4B8D-A52E-56C245D8225B@virtualcomputer.com>
Tom Goetz <tom.goetz@virtualcomputer.com> :
> We recently obtained a new a Lenovo Edge 0578-CTO. The r8169 driver causes
> instability in the system on this machine. The problem is that in
> rtl8169_rx_interrupt (status & 0x00001FFF) returns values less than four
This is unexpected. :o(
[...]
> For a work around we've added a patch to drop packets when we see this
> condition. I have attached lspci -vvv for this device and a patch for the
> work around we're using.
Thank you for debugging.
Can you grep for the XID of the device in the kernel's dmesg and specify
a bit of context for the problem (MTU ? features enabled through ethtool ?
kernel version ?) ?
--
Ueimor
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Eric Dumazet @ 2011-05-07 18:32 UTC (permalink / raw)
To: Alex Bligh; +Cc: netdev
In-Reply-To: <178E8895FB84C07251538EF7@Ximines.local>
Le samedi 07 mai 2011 à 19:24 +0100, Alex Bligh a écrit :
> Eric,
>
> --On 7 May 2011 18:26:29 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Here, on 2.6.38 kernel (Ubuntu 11.04 provided, on my 2 core laptop)
> ># time rmmod dummy
> > real 0m0.111s
> ...
> > On another machine with a very recent kernel :
> > $ modprobe dummy numdummies=1
> > $ ifconfig dummy0 192.168.46.46 up
> > $ time rmmod dummy
> >
> > real 0m0.032s
>
> I know it's different machines, but that's a pretty significant
> difference. So I compiled from 2.6.39-rc6 head (i.e. a kernel
> less than an hour old), with only your suggested change in,
> so that (a) I could eliminate old kernels, and (b) I could
> instrument it.
>
> > synchronize_rcu() calls are not consuming cpu, they just _wait_
> > rcu grace period.
> >
> > I suggest you read Documentation/RCU files if you really want to :)
>
> I understand the basic point: it needs to wait for all readers
> to drop their references. It's sort of hard to understand why
> on a machine with an idle network there would be reader(s) holding
> references for 250ms. And indeed the analysis below shows that
> isn't the case (it's more like 44 ms).
>
> > If you want to check how expensive it is, its quite easy:
> > add a trace in synchronize_net()
>
> At least for veth devices, I see the same on 2.6.39-rc6 - if anything
> it's worse:
>
> # ./ifseq -n 100
> Sat May 7 17:50:53 UTC 2011 creating 100 interfaces
> Sat May 7 17:50:54 UTC 2011 done
>
> real 0m1.549s
> user 0m0.060s
> sys 0m0.990s
> Sat May 7 17:50:54 UTC 2011 deleting 100 interfaces
> Sat May 7 17:51:22 UTC 2011 done
>
> real 0m27.917s
> user 0m0.420s
> sys 0m0.060s
>
> Performing that operation produced exactly 200 calls to synchronize net.
> The timestamps indicate that's 2 per veth pair deletion, and zero
> per veth pair creation.
>
> Analysing the resultant logs shows only 31% of the problem is
> time spent within synchronize_net() (perl script below).
>
> $ ./analyse.pl < syncnet | tail -2
> Total 18.98515 Usage 199 Average 0.09540 elsewhere
> Total 8.77581 Usage 200 Average 0.04388 synchronizing
>
> So *something* is spending more than twice as much time as
> synchronize_net().
>
> I've attached the log below as well.
>
> --
> Alex Bligh
>
>
> $ cat analyse.pl
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> my $lastuptime;
> my $uptime;
> my $diff;
> my $area;
> my %time;
> my %usage;
>
> while (<>)
> {
> chomp;
> if (m/\[\s*([0-9.]+)\].*synchronize_net/)
> {
> $uptime = $1;
> if (defined($lastuptime))
> {
> $area = (m/end/)?"synchronizing":"elsewhere";
> $diff = $uptime - $lastuptime;
> printf "%5.5f $area\n", $diff;
> $time{$area}+=$diff;
> $usage{$area}++;
> }
> $lastuptime = $uptime;
> }
> }
>
> print "\n";
>
> my $k;
> foreach $k (sort keys %time)
> {
> printf "Total %5.5f Usage %d Average %5.5f %s\n", $time{$k},
> $usage{$k}, $time{$k}/$usage{$k}, $k;
> }
>
>
>
> May 7 17:50:55 nattytest kernel: [ 127.490142] begin synchronize_net()
> May 7 17:50:55 nattytest kernel: [ 127.560084] end synchronize_net()
> May 7 17:50:55 nattytest kernel: [ 127.610350] begin synchronize_net()
> May 7 17:50:55 nattytest kernel: [ 127.610932] end synchronize_net()
> May 7 17:50:55 nattytest kernel: [ 127.740078] begin synchronize_net()
> May 7 17:50:55 nattytest kernel: [ 127.820071] end synchronize_net()
Well, there is also one rcu_barrier() call that is expensive.
(It was changed from one synchronize_rcu() to one rcu_barrier() lately
in commit ef885afb , in 2.6.36 kernel)
net/core/dev.c line 5167
http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ef885afbf8a37689afc1d9d545e2f3e7a8276c17
netdev_wait_allrefs() waits that all references to a device vanishes.
It currently uses a _very_ pessimistic 250 ms delay between each probe.
Some users reported that no more than 4 devices can be dismantled per
second, this is a pretty serious problem for some setups.
Most of the time, a refcount is about to be released by an RCU callback,
that is still in flight because rollback_registered_many() uses a
synchronize_rcu() call instead of rcu_barrier(). Problem is visible if
number of online cpus is one, because synchronize_rcu() is then a no op.
time to remove 50 ipip tunnels on a UP machine :
before patch : real 11.910s
after patch : real 1.250s
Reported-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Reported-by: Octavian Purdila <opurdila@ixiacom.com>
Reported-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: Lockdep splat for rt8169
From: Francois Romieu @ 2011-05-07 18:15 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4DC1CB8F.8080905@candelatech.com>
Ben Greear <greearb@candelatech.com> :
[...]
> Seems to be the first post 2.6.38 kernel that will boot stable
> on this system!
You are spoiled. I have to merge davem-next with -git or my raid1
test machine is unusable. :o/
> I previously reported the timer issue, but perhaps the lock
> debugging will help.
It is the same problem and will be triggered by any driver changing
the link state from an hard irq context - the r8169 driver is not
alone.
If you want a q'n'd workaround for the r8169 driver, defering its
LinkChg processing from the irq handler to a work task may do the
trick.
I am not sure what the general fix is:
- do more or less the same for linkwatch (i.e. defer more work to
a user context)
- audit each driver
- ???
--
Ueimor
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Alex Bligh @ 2011-05-07 18:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Alex Bligh
In-Reply-To: <1304785589.3207.5.camel@edumazet-laptop>
Eric,
--On 7 May 2011 18:26:29 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Here, on 2.6.38 kernel (Ubuntu 11.04 provided, on my 2 core laptop)
># time rmmod dummy
> real 0m0.111s
...
> On another machine with a very recent kernel :
> $ modprobe dummy numdummies=1
> $ ifconfig dummy0 192.168.46.46 up
> $ time rmmod dummy
>
> real 0m0.032s
I know it's different machines, but that's a pretty significant
difference. So I compiled from 2.6.39-rc6 head (i.e. a kernel
less than an hour old), with only your suggested change in,
so that (a) I could eliminate old kernels, and (b) I could
instrument it.
> synchronize_rcu() calls are not consuming cpu, they just _wait_
> rcu grace period.
>
> I suggest you read Documentation/RCU files if you really want to :)
I understand the basic point: it needs to wait for all readers
to drop their references. It's sort of hard to understand why
on a machine with an idle network there would be reader(s) holding
references for 250ms. And indeed the analysis below shows that
isn't the case (it's more like 44 ms).
> If you want to check how expensive it is, its quite easy:
> add a trace in synchronize_net()
At least for veth devices, I see the same on 2.6.39-rc6 - if anything
it's worse:
# ./ifseq -n 100
Sat May 7 17:50:53 UTC 2011 creating 100 interfaces
Sat May 7 17:50:54 UTC 2011 done
real 0m1.549s
user 0m0.060s
sys 0m0.990s
Sat May 7 17:50:54 UTC 2011 deleting 100 interfaces
Sat May 7 17:51:22 UTC 2011 done
real 0m27.917s
user 0m0.420s
sys 0m0.060s
Performing that operation produced exactly 200 calls to synchronize net.
The timestamps indicate that's 2 per veth pair deletion, and zero
per veth pair creation.
Analysing the resultant logs shows only 31% of the problem is
time spent within synchronize_net() (perl script below).
$ ./analyse.pl < syncnet | tail -2
Total 18.98515 Usage 199 Average 0.09540 elsewhere
Total 8.77581 Usage 200 Average 0.04388 synchronizing
So *something* is spending more than twice as much time as
synchronize_net().
I've attached the log below as well.
--
Alex Bligh
$ cat analyse.pl
#!/usr/bin/perl
use strict;
use warnings;
my $lastuptime;
my $uptime;
my $diff;
my $area;
my %time;
my %usage;
while (<>)
{
chomp;
if (m/\[\s*([0-9.]+)\].*synchronize_net/)
{
$uptime = $1;
if (defined($lastuptime))
{
$area = (m/end/)?"synchronizing":"elsewhere";
$diff = $uptime - $lastuptime;
printf "%5.5f $area\n", $diff;
$time{$area}+=$diff;
$usage{$area}++;
}
$lastuptime = $uptime;
}
}
print "\n";
my $k;
foreach $k (sort keys %time)
{
printf "Total %5.5f Usage %d Average %5.5f %s\n", $time{$k},
$usage{$k}, $time{$k}/$usage{$k}, $k;
}
May 7 17:50:55 nattytest kernel: [ 127.490142] begin synchronize_net()
May 7 17:50:55 nattytest kernel: [ 127.560084] end synchronize_net()
May 7 17:50:55 nattytest kernel: [ 127.610350] begin synchronize_net()
May 7 17:50:55 nattytest kernel: [ 127.610932] end synchronize_net()
May 7 17:50:55 nattytest kernel: [ 127.740078] begin synchronize_net()
May 7 17:50:55 nattytest kernel: [ 127.820071] end synchronize_net()
May 7 17:50:55 nattytest kernel: [ 127.870300] begin synchronize_net()
May 7 17:50:55 nattytest kernel: [ 127.871050] end synchronize_net()
May 7 17:50:55 nattytest kernel: [ 128.000079] begin synchronize_net()
May 7 17:50:55 nattytest kernel: [ 128.070070] end synchronize_net()
May 7 17:50:55 nattytest kernel: [ 128.140085] begin synchronize_net()
May 7 17:50:55 nattytest kernel: [ 128.140960] end synchronize_net()
May 7 17:50:55 nattytest kernel: [ 128.260082] begin synchronize_net()
May 7 17:50:55 nattytest kernel: [ 128.380072] end synchronize_net()
May 7 17:50:55 nattytest kernel: [ 128.430296] begin synchronize_net()
May 7 17:50:55 nattytest kernel: [ 128.431135] end synchronize_net()
May 7 17:50:56 nattytest kernel: [ 128.550087] begin synchronize_net()
May 7 17:50:56 nattytest kernel: [ 128.640057] end synchronize_net()
May 7 17:50:56 nattytest kernel: [ 128.710191] begin synchronize_net()
May 7 17:50:56 nattytest kernel: [ 128.730085] end synchronize_net()
May 7 17:50:56 nattytest kernel: [ 128.880074] begin synchronize_net()
May 7 17:50:56 nattytest kernel: [ 128.990123] end synchronize_net()
May 7 17:50:56 nattytest kernel: [ 129.060087] begin synchronize_net()
May 7 17:50:56 nattytest kernel: [ 129.070128] end synchronize_net()
May 7 17:50:56 nattytest kernel: [ 129.220079] begin synchronize_net()
May 7 17:50:56 nattytest kernel: [ 129.310070] end synchronize_net()
May 7 17:50:56 nattytest kernel: [ 129.370280] begin synchronize_net()
May 7 17:50:56 nattytest kernel: [ 129.390099] end synchronize_net()
May 7 17:50:57 nattytest kernel: [ 129.540174] begin synchronize_net()
May 7 17:50:57 nattytest kernel: [ 129.620063] end synchronize_net()
May 7 17:50:57 nattytest kernel: [ 129.690196] begin synchronize_net()
May 7 17:50:57 nattytest kernel: [ 129.710098] end synchronize_net()
May 7 17:50:57 nattytest kernel: [ 129.850084] begin synchronize_net()
May 7 17:50:57 nattytest kernel: [ 129.930070] end synchronize_net()
May 7 17:50:57 nattytest kernel: [ 129.980314] begin synchronize_net()
May 7 17:50:57 nattytest kernel: [ 129.990225] end synchronize_net()
May 7 17:50:57 nattytest kernel: [ 130.110086] begin synchronize_net()
May 7 17:50:57 nattytest kernel: [ 130.200078] end synchronize_net()
May 7 17:50:57 nattytest kernel: [ 130.270187] begin synchronize_net()
May 7 17:50:57 nattytest kernel: [ 130.280159] end synchronize_net()
May 7 17:50:57 nattytest kernel: [ 130.420133] begin synchronize_net()
May 7 17:50:58 nattytest kernel: [ 130.500075] end synchronize_net()
May 7 17:50:58 nattytest kernel: [ 130.550344] begin synchronize_net()
May 7 17:50:58 nattytest kernel: [ 130.550998] end synchronize_net()
May 7 17:50:58 nattytest kernel: [ 130.680075] begin synchronize_net()
May 7 17:50:58 nattytest kernel: [ 130.750071] end synchronize_net()
May 7 17:50:58 nattytest kernel: [ 130.800333] begin synchronize_net()
May 7 17:50:58 nattytest kernel: [ 130.801105] end synchronize_net()
May 7 17:50:58 nattytest kernel: [ 130.930071] begin synchronize_net()
May 7 17:50:58 nattytest kernel: [ 131.010064] end synchronize_net()
May 7 17:50:58 nattytest kernel: [ 131.080171] begin synchronize_net()
May 7 17:50:58 nattytest kernel: [ 131.090129] end synchronize_net()
May 7 17:50:58 nattytest kernel: [ 131.240078] begin synchronize_net()
May 7 17:50:58 nattytest kernel: [ 131.320068] end synchronize_net()
May 7 17:50:58 nattytest kernel: [ 131.390216] begin synchronize_net()
May 7 17:50:58 nattytest kernel: [ 131.403088] end synchronize_net()
May 7 17:50:59 nattytest kernel: [ 131.540081] begin synchronize_net()
May 7 17:50:59 nattytest kernel: [ 131.610072] end synchronize_net()
May 7 17:50:59 nattytest kernel: [ 131.660314] begin synchronize_net()
May 7 17:50:59 nattytest kernel: [ 131.661094] end synchronize_net()
May 7 17:50:59 nattytest kernel: [ 131.790076] begin synchronize_net()
May 7 17:50:59 nattytest kernel: [ 131.860082] end synchronize_net()
May 7 17:50:59 nattytest kernel: [ 131.910294] begin synchronize_net()
May 7 17:50:59 nattytest kernel: [ 131.911061] end synchronize_net()
May 7 17:50:59 nattytest kernel: [ 132.030075] begin synchronize_net()
May 7 17:50:59 nattytest kernel: [ 132.110079] end synchronize_net()
May 7 17:50:59 nattytest kernel: [ 132.160319] begin synchronize_net()
May 7 17:50:59 nattytest kernel: [ 132.161101] end synchronize_net()
May 7 17:50:59 nattytest kernel: [ 132.280075] begin synchronize_net()
May 7 17:50:59 nattytest kernel: [ 132.400066] end synchronize_net()
May 7 17:51:00 nattytest kernel: [ 132.450321] begin synchronize_net()
May 7 17:51:00 nattytest kernel: [ 132.451134] end synchronize_net()
May 7 17:51:00 nattytest kernel: [ 132.570078] begin synchronize_net()
May 7 17:51:00 nattytest kernel: [ 132.650080] end synchronize_net()
May 7 17:51:00 nattytest kernel: [ 132.700288] begin synchronize_net()
May 7 17:51:00 nattytest kernel: [ 132.701073] end synchronize_net()
May 7 17:51:00 nattytest kernel: [ 132.830066] begin synchronize_net()
May 7 17:51:00 nattytest kernel: [ 132.910069] end synchronize_net()
May 7 17:51:00 nattytest kernel: [ 132.990128] begin synchronize_net()
May 7 17:51:00 nattytest kernel: [ 132.990893] end synchronize_net()
May 7 17:51:00 nattytest kernel: [ 133.120076] begin synchronize_net()
May 7 17:51:00 nattytest kernel: [ 133.200071] end synchronize_net()
May 7 17:51:00 nattytest kernel: [ 133.250313] begin synchronize_net()
May 7 17:51:00 nattytest kernel: [ 133.251088] end synchronize_net()
May 7 17:51:00 nattytest kernel: [ 133.370082] begin synchronize_net()
May 7 17:51:01 nattytest kernel: [ 133.450147] end synchronize_net()
May 7 17:51:01 nattytest kernel: [ 133.500354] begin synchronize_net()
May 7 17:51:01 nattytest kernel: [ 133.505508] end synchronize_net()
May 7 17:51:01 nattytest kernel: [ 133.630085] begin synchronize_net()
May 7 17:51:01 nattytest kernel: [ 133.710090] end synchronize_net()
May 7 17:51:01 nattytest kernel: [ 133.760399] begin synchronize_net()
May 7 17:51:01 nattytest kernel: [ 133.770396] end synchronize_net()
May 7 17:51:01 nattytest kernel: [ 133.920090] begin synchronize_net()
May 7 17:51:01 nattytest kernel: [ 134.010083] end synchronize_net()
May 7 17:51:01 nattytest kernel: [ 134.060292] begin synchronize_net()
May 7 17:51:01 nattytest kernel: [ 134.080082] end synchronize_net()
May 7 17:51:01 nattytest kernel: [ 134.220082] begin synchronize_net()
May 7 17:51:01 nattytest kernel: [ 134.310064] end synchronize_net()
May 7 17:51:01 nattytest kernel: [ 134.380176] begin synchronize_net()
May 7 17:51:01 nattytest kernel: [ 134.390127] end synchronize_net()
May 7 17:51:02 nattytest kernel: [ 134.550205] begin synchronize_net()
May 7 17:51:02 nattytest kernel: [ 134.630133] end synchronize_net()
May 7 17:51:02 nattytest kernel: [ 134.830065] begin synchronize_net()
May 7 17:51:02 nattytest kernel: [ 134.880091] end synchronize_net()
May 7 17:51:02 nattytest kernel: [ 135.040194] begin synchronize_net()
May 7 17:51:02 nattytest kernel: [ 135.120072] end synchronize_net()
May 7 17:51:02 nattytest kernel: [ 135.190202] begin synchronize_net()
May 7 17:51:02 nattytest kernel: [ 135.210084] end synchronize_net()
May 7 17:51:02 nattytest kernel: [ 135.370081] begin synchronize_net()
May 7 17:51:03 nattytest kernel: [ 135.440076] end synchronize_net()
May 7 17:51:03 nattytest kernel: [ 135.490331] begin synchronize_net()
May 7 17:51:03 nattytest kernel: [ 135.491147] end synchronize_net()
May 7 17:51:03 nattytest kernel: [ 135.620079] begin synchronize_net()
May 7 17:51:03 nattytest kernel: [ 135.700064] end synchronize_net()
May 7 17:51:03 nattytest kernel: [ 135.757709] begin synchronize_net()
May 7 17:51:03 nattytest kernel: [ 135.770095] end synchronize_net()
May 7 17:51:03 nattytest kernel: [ 135.920101] begin synchronize_net()
May 7 17:51:03 nattytest kernel: [ 135.990068] end synchronize_net()
May 7 17:51:03 nattytest kernel: [ 136.050068] begin synchronize_net()
May 7 17:51:03 nattytest kernel: [ 136.050825] end synchronize_net()
May 7 17:51:03 nattytest kernel: [ 136.160081] begin synchronize_net()
May 7 17:51:03 nattytest kernel: [ 136.240067] end synchronize_net()
May 7 17:51:03 nattytest kernel: [ 136.290431] begin synchronize_net()
May 7 17:51:03 nattytest kernel: [ 136.291020] end synchronize_net()
May 7 17:51:03 nattytest kernel: [ 136.420094] begin synchronize_net()
May 7 17:51:04 nattytest kernel: [ 136.500062] end synchronize_net()
May 7 17:51:04 nattytest kernel: [ 136.550388] begin synchronize_net()
May 7 17:51:04 nattytest kernel: [ 136.550988] end synchronize_net()
May 7 17:51:04 nattytest kernel: [ 136.670101] begin synchronize_net()
May 7 17:51:04 nattytest kernel: [ 136.750063] end synchronize_net()
May 7 17:51:04 nattytest kernel: [ 136.800297] begin synchronize_net()
May 7 17:51:04 nattytest kernel: [ 136.801081] end synchronize_net()
May 7 17:51:04 nattytest kernel: [ 136.920070] begin synchronize_net()
May 7 17:51:04 nattytest kernel: [ 137.000069] end synchronize_net()
May 7 17:51:04 nattytest kernel: [ 137.050252] begin synchronize_net()
May 7 17:51:04 nattytest kernel: [ 137.051042] end synchronize_net()
May 7 17:51:04 nattytest kernel: [ 137.180076] begin synchronize_net()
May 7 17:51:04 nattytest kernel: [ 137.260065] end synchronize_net()
May 7 17:51:04 nattytest kernel: [ 137.320191] begin synchronize_net()
May 7 17:51:04 nattytest kernel: [ 137.340087] end synchronize_net()
May 7 17:51:05 nattytest kernel: [ 137.490082] begin synchronize_net()
May 7 17:51:05 nattytest kernel: [ 137.570071] end synchronize_net()
May 7 17:51:05 nattytest kernel: [ 137.620314] begin synchronize_net()
May 7 17:51:05 nattytest kernel: [ 137.621084] end synchronize_net()
May 7 17:51:05 nattytest kernel: [ 137.740083] begin synchronize_net()
May 7 17:51:05 nattytest kernel: [ 137.830071] end synchronize_net()
May 7 17:51:05 nattytest kernel: [ 137.890264] begin synchronize_net()
May 7 17:51:05 nattytest kernel: [ 137.910087] end synchronize_net()
May 7 17:51:05 nattytest kernel: [ 138.060074] begin synchronize_net()
May 7 17:51:05 nattytest kernel: [ 138.140070] end synchronize_net()
May 7 17:51:05 nattytest kernel: [ 138.210094] begin synchronize_net()
May 7 17:51:05 nattytest kernel: [ 138.210940] end synchronize_net()
May 7 17:51:05 nattytest kernel: [ 138.340089] begin synchronize_net()
May 7 17:51:05 nattytest kernel: [ 138.410088] end synchronize_net()
May 7 17:51:06 nattytest kernel: [ 138.470306] begin synchronize_net()
May 7 17:51:06 nattytest kernel: [ 138.471080] end synchronize_net()
May 7 17:51:06 nattytest kernel: [ 138.590082] begin synchronize_net()
May 7 17:51:06 nattytest kernel: [ 138.670131] end synchronize_net()
May 7 17:51:06 nattytest kernel: [ 138.720268] begin synchronize_net()
May 7 17:51:06 nattytest kernel: [ 138.721034] end synchronize_net()
May 7 17:51:06 nattytest kernel: [ 138.850077] begin synchronize_net()
May 7 17:51:06 nattytest kernel: [ 138.920071] end synchronize_net()
May 7 17:51:06 nattytest kernel: [ 138.970305] begin synchronize_net()
May 7 17:51:06 nattytest kernel: [ 138.971074] end synchronize_net()
May 7 17:51:06 nattytest kernel: [ 139.090082] begin synchronize_net()
May 7 17:51:06 nattytest kernel: [ 139.170068] end synchronize_net()
May 7 17:51:06 nattytest kernel: [ 139.230297] begin synchronize_net()
May 7 17:51:06 nattytest kernel: [ 139.231115] end synchronize_net()
May 7 17:51:06 nattytest kernel: [ 139.350083] begin synchronize_net()
May 7 17:51:07 nattytest kernel: [ 139.440057] end synchronize_net()
May 7 17:51:07 nattytest kernel: [ 139.510174] begin synchronize_net()
May 7 17:51:07 nattytest kernel: [ 139.520124] end synchronize_net()
May 7 17:51:07 nattytest kernel: [ 139.680077] begin synchronize_net()
May 7 17:51:07 nattytest kernel: [ 139.750087] end synchronize_net()
May 7 17:51:07 nattytest kernel: [ 139.840093] begin synchronize_net()
May 7 17:51:07 nattytest kernel: [ 139.840867] end synchronize_net()
May 7 17:51:07 nattytest kernel: [ 139.970079] begin synchronize_net()
May 7 17:51:07 nattytest kernel: [ 140.080094] end synchronize_net()
May 7 17:51:07 nattytest kernel: [ 140.130284] begin synchronize_net()
May 7 17:51:07 nattytest kernel: [ 140.131056] end synchronize_net()
May 7 17:51:07 nattytest kernel: [ 140.260076] begin synchronize_net()
May 7 17:51:07 nattytest kernel: [ 140.330076] end synchronize_net()
May 7 17:51:07 nattytest kernel: [ 140.380332] begin synchronize_net()
May 7 17:51:07 nattytest kernel: [ 140.381364] end synchronize_net()
May 7 17:51:08 nattytest kernel: [ 140.510081] begin synchronize_net()
May 7 17:51:08 nattytest kernel: [ 140.590074] end synchronize_net()
May 7 17:51:08 nattytest kernel: [ 140.650289] begin synchronize_net()
May 7 17:51:08 nattytest kernel: [ 140.670086] end synchronize_net()
May 7 17:51:08 nattytest kernel: [ 140.800064] begin synchronize_net()
May 7 17:51:08 nattytest kernel: [ 140.880073] end synchronize_net()
May 7 17:51:08 nattytest kernel: [ 140.930267] begin synchronize_net()
May 7 17:51:08 nattytest kernel: [ 140.931048] end synchronize_net()
May 7 17:51:08 nattytest kernel: [ 141.050072] begin synchronize_net()
May 7 17:51:08 nattytest kernel: [ 141.140067] end synchronize_net()
May 7 17:51:08 nattytest kernel: [ 141.190328] begin synchronize_net()
May 7 17:51:08 nattytest kernel: [ 141.200119] end synchronize_net()
May 7 17:51:08 nattytest kernel: [ 141.360077] begin synchronize_net()
May 7 17:51:08 nattytest kernel: [ 141.430074] end synchronize_net()
May 7 17:51:09 nattytest kernel: [ 141.480312] begin synchronize_net()
May 7 17:51:09 nattytest kernel: [ 141.481110] end synchronize_net()
May 7 17:51:09 nattytest kernel: [ 141.600080] begin synchronize_net()
May 7 17:51:09 nattytest kernel: [ 141.680081] end synchronize_net()
May 7 17:51:09 nattytest kernel: [ 141.730335] begin synchronize_net()
May 7 17:51:09 nattytest kernel: [ 141.731136] end synchronize_net()
May 7 17:51:09 nattytest kernel: [ 141.860079] begin synchronize_net()
May 7 17:51:09 nattytest kernel: [ 141.930070] end synchronize_net()
May 7 17:51:09 nattytest kernel: [ 141.980317] begin synchronize_net()
May 7 17:51:09 nattytest kernel: [ 141.981114] end synchronize_net()
May 7 17:51:09 nattytest kernel: [ 142.110097] begin synchronize_net()
May 7 17:51:09 nattytest kernel: [ 142.180074] end synchronize_net()
May 7 17:51:09 nattytest kernel: [ 142.230335] begin synchronize_net()
May 7 17:51:09 nattytest kernel: [ 142.231113] end synchronize_net()
May 7 17:51:09 nattytest kernel: [ 142.350080] begin synchronize_net()
May 7 17:51:09 nattytest kernel: [ 142.430087] end synchronize_net()
May 7 17:51:10 nattytest kernel: [ 142.480310] begin synchronize_net()
May 7 17:51:10 nattytest kernel: [ 142.481084] end synchronize_net()
May 7 17:51:10 nattytest kernel: [ 142.600090] begin synchronize_net()
May 7 17:51:10 nattytest kernel: [ 142.720091] end synchronize_net()
May 7 17:51:10 nattytest kernel: [ 142.770310] begin synchronize_net()
May 7 17:51:10 nattytest kernel: [ 142.771130] end synchronize_net()
May 7 17:51:10 nattytest kernel: [ 142.900080] begin synchronize_net()
May 7 17:51:10 nattytest kernel: [ 142.980070] end synchronize_net()
May 7 17:51:10 nattytest kernel: [ 143.060109] begin synchronize_net()
May 7 17:51:10 nattytest kernel: [ 143.080079] end synchronize_net()
May 7 17:51:10 nattytest kernel: [ 143.230095] begin synchronize_net()
May 7 17:51:10 nattytest kernel: [ 143.300044] end synchronize_net()
May 7 17:51:10 nattytest kernel: [ 143.350319] begin synchronize_net()
May 7 17:51:10 nattytest kernel: [ 143.351119] end synchronize_net()
May 7 17:51:11 nattytest kernel: [ 143.470076] begin synchronize_net()
May 7 17:51:11 nattytest kernel: [ 143.560083] end synchronize_net()
May 7 17:51:11 nattytest kernel: [ 143.620209] begin synchronize_net()
May 7 17:51:11 nattytest kernel: [ 143.640090] end synchronize_net()
May 7 17:51:11 nattytest kernel: [ 143.780078] begin synchronize_net()
May 7 17:51:11 nattytest kernel: [ 143.860076] end synchronize_net()
May 7 17:51:11 nattytest kernel: [ 143.910284] begin synchronize_net()
May 7 17:51:11 nattytest kernel: [ 143.911142] end synchronize_net()
May 7 17:51:11 nattytest kernel: [ 144.030075] begin synchronize_net()
May 7 17:51:11 nattytest kernel: [ 144.110085] end synchronize_net()
May 7 17:51:11 nattytest kernel: [ 144.160313] begin synchronize_net()
May 7 17:51:11 nattytest kernel: [ 144.161104] end synchronize_net()
May 7 17:51:11 nattytest kernel: [ 144.280080] begin synchronize_net()
May 7 17:51:11 nattytest kernel: [ 144.360074] end synchronize_net()
May 7 17:51:11 nattytest kernel: [ 144.410294] begin synchronize_net()
May 7 17:51:11 nattytest kernel: [ 144.411096] end synchronize_net()
May 7 17:51:12 nattytest kernel: [ 144.530092] begin synchronize_net()
May 7 17:51:12 nattytest kernel: [ 144.620072] end synchronize_net()
May 7 17:51:12 nattytest kernel: [ 144.680355] begin synchronize_net()
May 7 17:51:12 nattytest kernel: [ 144.700081] end synchronize_net()
May 7 17:51:12 nattytest kernel: [ 144.860073] begin synchronize_net()
May 7 17:51:12 nattytest kernel: [ 144.930075] end synchronize_net()
May 7 17:51:12 nattytest kernel: [ 144.980325] begin synchronize_net()
May 7 17:51:12 nattytest kernel: [ 144.981155] end synchronize_net()
May 7 17:51:12 nattytest kernel: [ 145.110079] begin synchronize_net()
May 7 17:51:12 nattytest kernel: [ 145.180084] end synchronize_net()
May 7 17:51:12 nattytest kernel: [ 145.230324] begin synchronize_net()
May 7 17:51:12 nattytest kernel: [ 145.231098] end synchronize_net()
May 7 17:51:12 nattytest kernel: [ 145.350077] begin synchronize_net()
May 7 17:51:12 nattytest kernel: [ 145.430081] end synchronize_net()
May 7 17:51:13 nattytest kernel: [ 145.480300] begin synchronize_net()
May 7 17:51:13 nattytest kernel: [ 145.481050] end synchronize_net()
May 7 17:51:13 nattytest kernel: [ 145.610079] begin synchronize_net()
May 7 17:51:13 nattytest kernel: [ 145.690071] end synchronize_net()
May 7 17:51:13 nattytest kernel: [ 145.750370] begin synchronize_net()
May 7 17:51:13 nattytest kernel: [ 145.760378] end synchronize_net()
May 7 17:51:13 nattytest kernel: [ 145.900074] begin synchronize_net()
May 7 17:51:13 nattytest kernel: [ 145.970077] end synchronize_net()
May 7 17:51:13 nattytest kernel: [ 146.020298] begin synchronize_net()
May 7 17:51:13 nattytest kernel: [ 146.021548] end synchronize_net()
May 7 17:51:13 nattytest kernel: [ 146.150081] begin synchronize_net()
May 7 17:51:13 nattytest kernel: [ 146.230073] end synchronize_net()
May 7 17:51:13 nattytest kernel: [ 146.299959] begin synchronize_net()
May 7 17:51:13 nattytest kernel: [ 146.310076] end synchronize_net()
May 7 17:51:14 nattytest kernel: [ 146.440080] begin synchronize_net()
May 7 17:51:14 nattytest kernel: [ 146.520065] end synchronize_net()
May 7 17:51:14 nattytest kernel: [ 146.580285] begin synchronize_net()
May 7 17:51:14 nattytest kernel: [ 146.590266] end synchronize_net()
May 7 17:51:14 nattytest kernel: [ 146.750063] begin synchronize_net()
May 7 17:51:14 nattytest kernel: [ 146.830084] end synchronize_net()
May 7 17:51:14 nattytest kernel: [ 146.890233] begin synchronize_net()
May 7 17:51:14 nattytest kernel: [ 146.910088] end synchronize_net()
May 7 17:51:14 nattytest kernel: [ 147.060081] begin synchronize_net()
May 7 17:51:14 nattytest kernel: [ 147.140061] end synchronize_net()
May 7 17:51:14 nattytest kernel: [ 147.200277] begin synchronize_net()
May 7 17:51:14 nattytest kernel: [ 147.220089] end synchronize_net()
May 7 17:51:14 nattytest kernel: [ 147.360081] begin synchronize_net()
May 7 17:51:15 nattytest kernel: [ 147.450084] end synchronize_net()
May 7 17:51:15 nattytest kernel: [ 147.510283] begin synchronize_net()
May 7 17:51:15 nattytest kernel: [ 147.530135] end synchronize_net()
May 7 17:51:15 nattytest kernel: [ 147.680075] begin synchronize_net()
May 7 17:51:15 nattytest kernel: [ 147.760066] end synchronize_net()
May 7 17:51:15 nattytest kernel: [ 147.830172] begin synchronize_net()
May 7 17:51:15 nattytest kernel: [ 147.870065] end synchronize_net()
May 7 17:51:15 nattytest kernel: [ 148.000075] begin synchronize_net()
May 7 17:51:15 nattytest kernel: [ 148.070065] end synchronize_net()
May 7 17:51:15 nattytest kernel: [ 148.120327] begin synchronize_net()
May 7 17:51:15 nattytest kernel: [ 148.121099] end synchronize_net()
May 7 17:51:15 nattytest kernel: [ 148.240073] begin synchronize_net()
May 7 17:51:15 nattytest kernel: [ 148.320061] end synchronize_net()
May 7 17:51:15 nattytest kernel: [ 148.370253] begin synchronize_net()
May 7 17:51:15 nattytest kernel: [ 148.371001] end synchronize_net()
May 7 17:51:16 nattytest kernel: [ 148.500082] begin synchronize_net()
May 7 17:51:16 nattytest kernel: [ 148.580073] end synchronize_net()
May 7 17:51:16 nattytest kernel: [ 148.650192] begin synchronize_net()
May 7 17:51:16 nattytest kernel: [ 148.670095] end synchronize_net()
May 7 17:51:16 nattytest kernel: [ 148.820077] begin synchronize_net()
May 7 17:51:16 nattytest kernel: [ 148.910058] end synchronize_net()
May 7 17:51:16 nattytest kernel: [ 148.980223] begin synchronize_net()
May 7 17:51:16 nattytest kernel: [ 148.990280] end synchronize_net()
May 7 17:51:16 nattytest kernel: [ 149.130076] begin synchronize_net()
May 7 17:51:16 nattytest kernel: [ 149.220104] end synchronize_net()
May 7 17:51:16 nattytest kernel: [ 149.270373] begin synchronize_net()
May 7 17:51:16 nattytest kernel: [ 149.300076] end synchronize_net()
May 7 17:51:17 nattytest kernel: [ 149.450078] begin synchronize_net()
May 7 17:51:17 nattytest kernel: [ 149.530063] end synchronize_net()
May 7 17:51:17 nattytest kernel: [ 149.580337] begin synchronize_net()
May 7 17:51:17 nattytest kernel: [ 149.581173] end synchronize_net()
May 7 17:51:17 nattytest kernel: [ 149.700072] begin synchronize_net()
May 7 17:51:17 nattytest kernel: [ 149.780071] end synchronize_net()
May 7 17:51:17 nattytest kernel: [ 149.830307] begin synchronize_net()
May 7 17:51:17 nattytest kernel: [ 149.831075] end synchronize_net()
May 7 17:51:17 nattytest kernel: [ 149.960083] begin synchronize_net()
May 7 17:51:17 nattytest kernel: [ 150.030067] end synchronize_net()
May 7 17:51:17 nattytest kernel: [ 150.080323] begin synchronize_net()
May 7 17:51:17 nattytest kernel: [ 150.081113] end synchronize_net()
May 7 17:51:17 nattytest kernel: [ 150.200076] begin synchronize_net()
May 7 17:51:17 nattytest kernel: [ 150.280065] end synchronize_net()
May 7 17:51:17 nattytest kernel: [ 150.330341] begin synchronize_net()
May 7 17:51:17 nattytest kernel: [ 150.331164] end synchronize_net()
May 7 17:51:18 nattytest kernel: [ 150.460081] begin synchronize_net()
May 7 17:51:18 nattytest kernel: [ 150.540064] end synchronize_net()
May 7 17:51:18 nattytest kernel: [ 150.600267] begin synchronize_net()
May 7 17:51:18 nattytest kernel: [ 150.620084] end synchronize_net()
May 7 17:51:18 nattytest kernel: [ 150.780067] begin synchronize_net()
May 7 17:51:18 nattytest kernel: [ 150.850065] end synchronize_net()
May 7 17:51:18 nattytest kernel: [ 150.900315] begin synchronize_net()
May 7 17:51:18 nattytest kernel: [ 150.901093] end synchronize_net()
May 7 17:51:18 nattytest kernel: [ 151.020083] begin synchronize_net()
May 7 17:51:18 nattytest kernel: [ 151.100069] end synchronize_net()
May 7 17:51:18 nattytest kernel: [ 151.150282] begin synchronize_net()
May 7 17:51:18 nattytest kernel: [ 151.151067] end synchronize_net()
May 7 17:51:18 nattytest kernel: [ 151.280079] begin synchronize_net()
May 7 17:51:18 nattytest kernel: [ 151.360070] end synchronize_net()
May 7 17:51:18 nattytest kernel: [ 151.410316] begin synchronize_net()
May 7 17:51:18 nattytest kernel: [ 151.411133] end synchronize_net()
May 7 17:51:19 nattytest kernel: [ 151.540178] begin synchronize_net()
May 7 17:51:19 nattytest kernel: [ 151.610071] end synchronize_net()
May 7 17:51:19 nattytest kernel: [ 151.660313] begin synchronize_net()
May 7 17:51:19 nattytest kernel: [ 151.661125] end synchronize_net()
May 7 17:51:19 nattytest kernel: [ 151.780072] begin synchronize_net()
May 7 17:51:19 nattytest kernel: [ 151.860074] end synchronize_net()
May 7 17:51:19 nattytest kernel: [ 151.910295] begin synchronize_net()
May 7 17:51:19 nattytest kernel: [ 151.911124] end synchronize_net()
May 7 17:51:19 nattytest kernel: [ 152.040109] begin synchronize_net()
May 7 17:51:19 nattytest kernel: [ 152.110066] end synchronize_net()
May 7 17:51:19 nattytest kernel: [ 152.160295] begin synchronize_net()
May 7 17:51:19 nattytest kernel: [ 152.161049] end synchronize_net()
May 7 17:51:19 nattytest kernel: [ 152.280073] begin synchronize_net()
May 7 17:51:19 nattytest kernel: [ 152.360085] end synchronize_net()
May 7 17:51:19 nattytest kernel: [ 152.410306] begin synchronize_net()
May 7 17:51:19 nattytest kernel: [ 152.411060] end synchronize_net()
May 7 17:51:20 nattytest kernel: [ 152.530075] begin synchronize_net()
May 7 17:51:20 nattytest kernel: [ 152.610064] end synchronize_net()
May 7 17:51:20 nattytest kernel: [ 152.660270] begin synchronize_net()
May 7 17:51:20 nattytest kernel: [ 152.661284] end synchronize_net()
May 7 17:51:20 nattytest kernel: [ 152.830095] begin synchronize_net()
May 7 17:51:20 nattytest kernel: [ 152.910065] end synchronize_net()
May 7 17:51:20 nattytest kernel: [ 152.960314] begin synchronize_net()
May 7 17:51:20 nattytest kernel: [ 152.961131] end synchronize_net()
May 7 17:51:20 nattytest kernel: [ 153.090076] begin synchronize_net()
May 7 17:51:20 nattytest kernel: [ 153.160083] end synchronize_net()
May 7 17:51:20 nattytest kernel: [ 153.210293] begin synchronize_net()
May 7 17:51:20 nattytest kernel: [ 153.211113] end synchronize_net()
May 7 17:51:20 nattytest kernel: [ 153.340081] begin synchronize_net()
May 7 17:51:20 nattytest kernel: [ 153.420067] end synchronize_net()
May 7 17:51:21 nattytest kernel: [ 153.470317] begin synchronize_net()
May 7 17:51:21 nattytest kernel: [ 153.471164] end synchronize_net()
May 7 17:51:21 nattytest kernel: [ 153.590082] begin synchronize_net()
May 7 17:51:21 nattytest kernel: [ 153.680063] end synchronize_net()
May 7 17:51:21 nattytest kernel: [ 153.740238] begin synchronize_net()
May 7 17:51:21 nattytest kernel: [ 153.750127] end synchronize_net()
May 7 17:51:21 nattytest kernel: [ 153.900077] begin synchronize_net()
May 7 17:51:21 nattytest kernel: [ 153.980077] end synchronize_net()
May 7 17:51:21 nattytest kernel: [ 154.080091] begin synchronize_net()
May 7 17:51:21 nattytest kernel: [ 154.080872] end synchronize_net()
May 7 17:51:21 nattytest kernel: [ 154.210077] begin synchronize_net()
May 7 17:51:21 nattytest kernel: [ 154.290061] end synchronize_net()
May 7 17:51:21 nattytest kernel: [ 154.340327] begin synchronize_net()
May 7 17:51:21 nattytest kernel: [ 154.360089] end synchronize_net()
May 7 17:51:22 nattytest kernel: [ 154.510085] begin synchronize_net()
May 7 17:51:22 nattytest kernel: [ 154.580075] end synchronize_net()
May 7 17:51:22 nattytest kernel: [ 154.630300] begin synchronize_net()
May 7 17:51:22 nattytest kernel: [ 154.631065] end synchronize_net()
May 7 17:51:22 nattytest kernel: [ 154.770074] begin synchronize_net()
May 7 17:51:22 nattytest kernel: [ 154.880081] end synchronize_net()
May 7 17:51:22 nattytest kernel: [ 154.940349] begin synchronize_net()
May 7 17:51:22 nattytest kernel: [ 154.960085] end synchronize_net()
May 7 17:51:22 nattytest kernel: [ 155.130080] begin synchronize_net()
May 7 17:51:22 nattytest kernel: [ 155.200079] end synchronize_net()
May 7 17:51:22 nattytest kernel: [ 155.250334] begin synchronize_net()
May 7 17:51:22 nattytest kernel: [ 155.251105] end synchronize_net()
^ permalink raw reply
* Re: [PATCH 7/7] ns: Wire up the setns system call
From: Geert Uytterhoeven @ 2011-05-07 18:22 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-arch, linux-kernel, netdev, linux-fsdevel, jamal,
Daniel Lezcano, Linux Containers, Renato Westphal
In-Reply-To: <m14o56pppd.fsf@fess.ebiederm.org>
On Sat, May 7, 2011 at 16:09, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
>> On Sat, May 7, 2011 at 04:25, Eric W. Biederman <ebiederm@xmission.com> wrote:
>>> arch/m68k/include/asm/unistd.h | 3 ++-
>>> arch/m68k/kernel/syscalltable.S | 1 +
>>
>> As the unified syscalltable for m68k/m68knommu is not yet in mainline
>> (planned for
>> 2.6.40), you should also add it to arch/m68k/kernel/entry_mm.S.
>>
>> Gr{oetje,eeting}s,
>
> Like so?
>
> From c06a03281d944ed36e2da02f5374ec6c650e4988 Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Sat, 7 May 2011 07:00:24 -0700
> Subject: [PATCH] m68knommu: Wire up the setns system call
>
> It seems I overlooked m68knommu where I wired up this syscall.
You overlooked m68k with MMU. syscalltable.s is used by m68knommu.
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> ---
> arch/m68k/kernel/entry_mm.S | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/m68k/kernel/entry_mm.S b/arch/m68k/kernel/entry_mm.S
> index 1359ee6..e048015 100644
> --- a/arch/m68k/kernel/entry_mm.S
> +++ b/arch/m68k/kernel/entry_mm.S
> @@ -754,4 +754,5 @@ sys_call_table:
> .long sys_open_by_handle_at
> .long sys_clock_adjtime
> .long sys_syncfs
> + .long sys_setns
Yep.
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
* Re: [PATCH] net/bonding: adjust codingstyle for bond_3ad files
From: Joe Perches @ 2011-05-07 18:02 UTC (permalink / raw)
To: aquini
Cc: kernel-janitors, David Miller, Jay Vosburgh, Andy Gospodarek,
shemminger, netdev, Nicolas Kaiser
In-Reply-To: <20110507173141.GA4204@x61.tchesoft.com>
On Sat, 2011-05-07 at 14:31 -0300, Rafael Aquini wrote:
> To exemplify my point, I'll taking that very __ad_timer_to_ticks() as an example:
> static u16 __ad_timer_to_ticks(u16 timer_type, u16 par)
> {
> u16 retval = 0;
>
> switch (timer_type) {
> case AD_CURRENT_WHILE_TIMER: /* for rx machine usage */
> if (par)
> retval = (AD_SHORT_TIMEOUT_TIME*ad_ticks_per_sec);
> else
> retval = (AD_LONG_TIMEOUT_TIME*ad_ticks_per_sec);
> break;
> case AD_ACTOR_CHURN_TIMER: /* for local churn machine */
> retval = (AD_CHURN_DETECTION_TIME*ad_ticks_per_sec);
> break;
> case AD_PERIODIC_TIMER: /* for periodic machine */
> retval = (par*ad_ticks_per_sec);
> break;
> case AD_PARTNER_CHURN_TIMER: /* for remote churn machine */
> retval = (AD_CHURN_DETECTION_TIME*ad_ticks_per_sec);
> break;
> case AD_WAIT_WHILE_TIMER: /* for selection machine */
> retval = (AD_AGGREGATE_WAIT_TIME*ad_ticks_per_sec);
> break;
> }
> return retval;
> }
>
> If, for some unknown reason timer_type receives an 'alien' value, and
> we were
> using retval uninitialized, this function, as it is, would return an
> unpredictable value to its caller. Unless we have the switch block
> re-factored, we cannot leave retval uninitialized. So, it's not just a
> matter of leaving the variable uninitialized, or initialize it just to
> get rid of a compiler warning. That's why those comments are not
> helpful anyway.
I'd write this not using a retval variable at all as:
switch (timer_type) {
case AD_CURRENT_WHILE_TIMER: /* for rx machine usage */
if (par)
return AD_SHORT_TIMEOUT_TIME * ad_ticks_per_sec;
return AD_LONG_TIMEOUT_TIME * ad_ticks_per_sec;
case AD_ACTOR_CHURN_TIMER: /* for local churn machine */
return AD_CHURN_DETECTION_TIME * ad_ticks_per_sec;
...
}
WARN(1, "Invalid timer type: %u\n", timer_type)
return 0;
}
^ permalink raw reply
* Re: [PATCH] net/bonding: adjust codingstyle for bond_3ad files
From: Rafael Aquini @ 2011-05-07 17:31 UTC (permalink / raw)
To: Joe Perches
Cc: kernel-janitors, David Miller, Jay Vosburgh, Andy Gospodarek,
shemminger, netdev, Nicolas Kaiser
In-Reply-To: <1304733100.11874.33.camel@Joe-Laptop>
Howdy Joe,
On Fri, May 06, 2011 at 06:51:40PM -0700, Joe Perches wrote:
> On Fri, 2011-05-06 at 22:27 -0300, Rafael Aquini wrote:
> > @@ -411,36 +406,32 @@ static inline void __initialize_port_locks(struct port *port)
> > */
> > static u16 __ad_timer_to_ticks(u16 timer_type, u16 par)
> > {
> > - u16 retval = 0; /* to silence the compiler */
> > + u16 retval = 0;
>
> I think it's not good to remove this sort of comment.
> (there are others like it)
Sorry to disagree, but I can't see those comments as being helpful at all.
I mean, what's the point about add a comment stating you are initializing
an etc var just to get rid of some compiler warning?
If, instead, some trick was used to initialize the var, then a comment would be worthwhile, isn't it? something like:
/* suppress the compiler uninitialized variable warnings
* without generating any code (retval is still uninitialized)
*/
u16 retval = retval;
> Another option might be to add __maybe_unused
I guess you meant uninitialized_var(x) here.
Yeah, I totally agree with you. It would be probably better using it considering
the performance standpoint (as it would not waste .text space and CPU cycles
initializing something that is about to be overwritten).
While better, it also would imply in some code re-factoring, as certainly at some point in the function the 'uninitialized' variable has to assume some value, otherwise bad things can happen when function returns.
To exemplify my point, I'll taking that very __ad_timer_to_ticks() as an example:
static u16 __ad_timer_to_ticks(u16 timer_type, u16 par)
{
u16 retval = 0;
switch (timer_type) {
case AD_CURRENT_WHILE_TIMER: /* for rx machine usage */
if (par)
retval = (AD_SHORT_TIMEOUT_TIME*ad_ticks_per_sec);
else
retval = (AD_LONG_TIMEOUT_TIME*ad_ticks_per_sec);
break;
case AD_ACTOR_CHURN_TIMER: /* for local churn machine */
retval = (AD_CHURN_DETECTION_TIME*ad_ticks_per_sec);
break;
case AD_PERIODIC_TIMER: /* for periodic machine */
retval = (par*ad_ticks_per_sec);
break;
case AD_PARTNER_CHURN_TIMER: /* for remote churn machine */
retval = (AD_CHURN_DETECTION_TIME*ad_ticks_per_sec);
break;
case AD_WAIT_WHILE_TIMER: /* for selection machine */
retval = (AD_AGGREGATE_WAIT_TIME*ad_ticks_per_sec);
break;
}
return retval;
}
If, for some unknown reason timer_type receives an 'alien' value, and we were
using retval uninitialized, this function, as it is, would return an unpredictable value to its caller. Unless we have the switch block re-factored, we cannot leave retval uninitialized. So, it's not just a matter of leaving the variable uninitialized, or initialize it just to get rid of a compiler warning. That's why those comments are not helpful anyway.
As I've mentioned at my first post, this is just a tinny collaboration in order to enforce CodingStyle. I've never had the intention of doing deep code re-factoring to this file (and I don't think it's needed), thus I didn't touch in automatic variables initialization, and other stuff related to its logic. If you thing it is needed, I can go forward and do it, though.
I'll always be more than willing (and glad) to help,
Thanks again, for the valuable feedback!
Cheers!
--
Rafael Aquini <aquini@linux.com>
^ permalink raw reply
* Re: [PATCH 1/5] ssb: Change fallback sprom to callback mechanism.
From: Jonas Gorski @ 2011-05-07 17:24 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: ralf, linux-mips, Michael Buesch, netdev, Florian Fainelli
In-Reply-To: <1304771263-10937-2-git-send-email-hauke@hauke-m.de>
Hi,
just some small small spelling nit-picks:
On 7 May 2011 14:27, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> Some embedded devices like the Netgear WNDR3300 have two SSB based
> cards without an own sprom on the pci bus. We have to provide two
> different fallback sproms for these and this was not possible with the
> old solution. In the bcm47xx architecture the sprom data is stored in
> the nvram in the main flash storage. The architecture code will be able
> to fill the sprom with the stored data based on the bus where the
> device was found.
>
> The bcm63xx code should to the same thing as before, just using the new
to -> do
> API.
>
> CC: Michael Buesch <mb@bu3sch.de>
> CC: netdev@vger.kernel.org
> CC: Florian Fainelli <florian@openwrt.org>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> ---
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 16 ++++++++++++++--
> drivers/ssb/pci.c | 16 +++++++++++-----
> drivers/ssb/sprom.c | 26 +++++++++++++++-----------
> drivers/ssb/ssb_private.h | 2 +-
> include/linux/ssb/ssb.h | 4 +++-
> 5 files changed, 44 insertions(+), 20 deletions(-)
>
> diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> index 8dba8cf..40b223b 100644
> --- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> @@ -643,6 +643,17 @@ static struct ssb_sprom bcm63xx_sprom = {
> .boardflags_lo = 0x2848,
> .boardflags_hi = 0x0000,
> };
> +
> +int bcm63xx_get_fallback_sprom(struct ssb_bus *bus, struct ssb_sprom *out)
> +{
> + if (bus->bustype == SSB_BUSTYPE_PCI) {
> + memcpy(out, &bcm63xx_sprom, sizeof(struct ssb_sprom));
> + return 0;
> + } else {
> + printk(KERN_ERR PFX "unable to fill SPROM for given bustype.\n");
> + return -EINVAL;
> + }
> +}
> #endif
>
> /*
> @@ -793,8 +804,9 @@ void __init board_prom_init(void)
> if (!board_get_mac_address(bcm63xx_sprom.il0mac)) {
> memcpy(bcm63xx_sprom.et0mac, bcm63xx_sprom.il0mac, ETH_ALEN);
> memcpy(bcm63xx_sprom.et1mac, bcm63xx_sprom.il0mac, ETH_ALEN);
> - if (ssb_arch_set_fallback_sprom(&bcm63xx_sprom) < 0)
> - printk(KERN_ERR "failed to register fallback SPROM\n");
> + if (ssb_arch_register_fallback_sprom(
> + &bcm63xx_get_fallback_sprom) < 0)
> + printk(KERN_ERR PFX "failed to register fallback SPROM\n");
> }
> #endif
> }
> diff --git a/drivers/ssb/pci.c b/drivers/ssb/pci.c
> index 6f34963..34955d1 100644
> --- a/drivers/ssb/pci.c
> +++ b/drivers/ssb/pci.c
> @@ -662,7 +662,6 @@ static int sprom_extract(struct ssb_bus *bus, struct ssb_sprom *out,
> static int ssb_pci_sprom_get(struct ssb_bus *bus,
> struct ssb_sprom *sprom)
> {
> - const struct ssb_sprom *fallback;
> int err;
> u16 *buf;
>
> @@ -707,10 +706,17 @@ static int ssb_pci_sprom_get(struct ssb_bus *bus,
> if (err) {
> /* All CRC attempts failed.
> * Maybe there is no SPROM on the device?
> - * If we have a fallback, use that. */
> - fallback = ssb_get_fallback_sprom();
> - if (fallback) {
> - memcpy(sprom, fallback, sizeof(*sprom));
> + * Now we ask the arch code if there is some sprom
> + * avaliable for this device in some other storage */
avaliable -> available
> + err = ssb_fill_sprom_with_fallback(bus, sprom);
> + if (err) {
> + ssb_printk(KERN_WARNING PFX "WARNING: Using"
> + " fallback SPROM failed (err %d)\n",
> + err);
> + } else {
> + ssb_dprintk(KERN_DEBUG PFX "Using SPROM"
> + " revision %d provided by"
> + " platform.\n", sprom->revision);
> err = 0;
> goto out_free;
> }
> diff --git a/drivers/ssb/sprom.c b/drivers/ssb/sprom.c
> index 5f34d7a..20cd139 100644
> --- a/drivers/ssb/sprom.c
> +++ b/drivers/ssb/sprom.c
> @@ -17,7 +17,7 @@
> #include <linux/slab.h>
>
>
> -static const struct ssb_sprom *fallback_sprom;
> +static int(*get_fallback_sprom)(struct ssb_bus *dev, struct ssb_sprom *out);
>
>
> static int sprom2hex(const u16 *sprom, char *buf, size_t buf_len,
> @@ -145,13 +145,14 @@ out:
> }
>
> /**
> - * ssb_arch_set_fallback_sprom - Set a fallback SPROM for use if no SPROM is found.
> + * ssb_arch_register_fallback_sprom - Registers a method providing a fallback
> + * SPROM if no SPROM is found.
> *
> - * @sprom: The SPROM data structure to register.
> + * @sprom_callback: The callbcak function.
callbcak -> callback
> *
> - * With this function the architecture implementation may register a fallback
> - * SPROM data structure. The fallback is only used for PCI based SSB devices,
> - * where no valid SPROM can be found in the shadow registers.
> + * With this function the architecture implementation may register a callback
> + * handler which wills the SPROM data structure. The fallback is only used for
wills -> fills
> + * PCI based SSB devices, where no valid SPROM can be found in the shadow registers.
> *
> * This function is useful for weird architectures that have a half-assed SSB device
> * hardwired to their PCI bus.
> @@ -163,18 +164,21 @@ out:
> *
> * This function is available for architecture code, only. So it is not exported.
> */
> -int ssb_arch_set_fallback_sprom(const struct ssb_sprom *sprom)
> +int ssb_arch_register_fallback_sprom(int (*sprom_callback)(struct ssb_bus *bus, struct ssb_sprom *out))
> {
> - if (fallback_sprom)
> + if (get_fallback_sprom)
> return -EEXIST;
> - fallback_sprom = sprom;
> + get_fallback_sprom = sprom_callback;
>
> return 0;
> }
>
> -const struct ssb_sprom *ssb_get_fallback_sprom(void)
> +int ssb_fill_sprom_with_fallback(struct ssb_bus *bus, struct ssb_sprom *out)
> {
> - return fallback_sprom;
> + if (!get_fallback_sprom)
> + return -ENOENT;
> +
> + return get_fallback_sprom(bus, out);
> }
>
> /* http://bcm-v4.sipsolutions.net/802.11/IsSpromAvailable */
> diff --git a/drivers/ssb/ssb_private.h b/drivers/ssb/ssb_private.h
> index 0331139..1a32f58 100644
> --- a/drivers/ssb/ssb_private.h
> +++ b/drivers/ssb/ssb_private.h
> @@ -171,7 +171,7 @@ ssize_t ssb_attr_sprom_store(struct ssb_bus *bus,
> const char *buf, size_t count,
> int (*sprom_check_crc)(const u16 *sprom, size_t size),
> int (*sprom_write)(struct ssb_bus *bus, const u16 *sprom));
> -extern const struct ssb_sprom *ssb_get_fallback_sprom(void);
> +extern int ssb_fill_sprom_with_fallback(struct ssb_bus *bus, struct ssb_sprom *out);
>
>
> /* core.c */
> diff --git a/include/linux/ssb/ssb.h b/include/linux/ssb/ssb.h
> index 9659eff..045f72a 100644
> --- a/include/linux/ssb/ssb.h
> +++ b/include/linux/ssb/ssb.h
> @@ -404,7 +404,9 @@ extern bool ssb_is_sprom_available(struct ssb_bus *bus);
>
> /* Set a fallback SPROM.
> * See kdoc at the function definition for complete documentation. */
> -extern int ssb_arch_set_fallback_sprom(const struct ssb_sprom *sprom);
> +extern int ssb_arch_register_fallback_sprom(
> + int (*sprom_callback)(struct ssb_bus *bus,
> + struct ssb_sprom *out));
>
> /* Suspend a SSB bus.
> * Call this from the parent bus suspend routine. */
> --
> 1.7.4.1
>
>
>
^ permalink raw reply
* Re: [PATCHv2 1/2] net: Export dev_queue_xmit_nit for use by macvlan driver
From: Ward, David - 0663 - MITLL @ 2011-05-07 16:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, kaber@trash.net
In-Reply-To: <20110505.105019.112577258.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
On 05/05/2011 01:50 PM, David Miller wrote:
> From: David Ward<david.ward@ll.mit.edu>
> Date: Thu, 28 Apr 2011 20:22:31 -0400
>
>> @@ -1521,11 +1521,13 @@ static inline int deliver_skb(struct sk_buff *skb,
>> }
>>
>> /*
>> - * Support routine. Sends outgoing frames to any network
>> - * taps currently in use.
>> + * dev_queue_xmit_nit - send outgoing frame to AF_PACKET sockets
>> + *
>> + * @skb: buffer to send
>> + * @dev: network device that AF_PACKET sockets are attached to (if any)
>> */
> I really don't like exposing these kinds of internals for what is
> largely a macvlan internal issue. Please find a less intrustive way
> to solve this problem.
>
> Thanks.
What do you think about creating __dev_forward_skb, which takes as an
additional parameter a device (or maybe a list of devices) whose taps
should see this packet as it is forwarded, such as a macvlan lowerdev?
This function would be able to call dev_queue_xmit_nit for (each of)
these devices.
Since the list of current network taps (ptype_all) is static inside
net/core/dev.c, some type of change has to be made to net/core/dev.c to
fix this.
Thanks,
David
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5650 bytes --]
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Eric Dumazet @ 2011-05-07 16:51 UTC (permalink / raw)
To: Ben Greear; +Cc: Alex Bligh, netdev
In-Reply-To: <4DC57702.4090606@candelatech.com>
Le samedi 07 mai 2011 à 09:44 -0700, Ben Greear a écrit :
> On 05/07/2011 09:37 AM, Eric Dumazet wrote:
> > Le samedi 07 mai 2011 à 09:23 -0700, Ben Greear a écrit :
> >
> >> I wonder if it would be worth having a 'delete me soon'
> >> method to delete interfaces that would not block on the
> >> RCU code.
> >>
> >> The controlling programs could use netlink messages to
> >> know exactly when an interface was truly gone.
> >>
> >> That should allow some batching in the sync-net logic
> >> too, if user-space code deletes 1000 interfaces very
> >> quickly, for instance...
> >>
> >
> > I suggested in the past to have an extension of batch capabilities, so
> > that one kthread could have 3 separate lists of devices being destroyed
> > in //,
> >
> > This daemon would basically loop on one call to synchronize_rcu(), and
> > transfert list3 to deletion, list2 to list3, list1 to list2, loop,
> > eventually releasing RTNL while blocked in synchronize_rcu()
> >
> > This would need to allow as you suggest an asynchronous deletion method,
> > or use a callback to wake the process blocked on device delete.
>
> I'd want to at least have the option to not block the calling
> process...otherwise, it would be a lot more difficult to
> quickly delete 1000 interfaces. You'd need 1000 threads, or
> sockets, or something to parallelize it otherwise, eh?
Yes, if you can afford not receive a final notification of device being
fully freed, it should be possible.
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Ben Greear @ 2011-05-07 16:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alex Bligh, netdev
In-Reply-To: <1304786277.3207.12.camel@edumazet-laptop>
On 05/07/2011 09:37 AM, Eric Dumazet wrote:
> Le samedi 07 mai 2011 à 09:23 -0700, Ben Greear a écrit :
>
>> I wonder if it would be worth having a 'delete me soon'
>> method to delete interfaces that would not block on the
>> RCU code.
>>
>> The controlling programs could use netlink messages to
>> know exactly when an interface was truly gone.
>>
>> That should allow some batching in the sync-net logic
>> too, if user-space code deletes 1000 interfaces very
>> quickly, for instance...
>>
>
> I suggested in the past to have an extension of batch capabilities, so
> that one kthread could have 3 separate lists of devices being destroyed
> in //,
>
> This daemon would basically loop on one call to synchronize_rcu(), and
> transfert list3 to deletion, list2 to list3, list1 to list2, loop,
> eventually releasing RTNL while blocked in synchronize_rcu()
>
> This would need to allow as you suggest an asynchronous deletion method,
> or use a callback to wake the process blocked on device delete.
I'd want to at least have the option to not block the calling
process...otherwise, it would be a lot more difficult to
quickly delete 1000 interfaces. You'd need 1000 threads, or
sockets, or something to parallelize it otherwise, eh?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Eric Dumazet @ 2011-05-07 16:37 UTC (permalink / raw)
To: Ben Greear; +Cc: Alex Bligh, netdev
In-Reply-To: <4DC571F1.2020108@candelatech.com>
Le samedi 07 mai 2011 à 09:23 -0700, Ben Greear a écrit :
> I wonder if it would be worth having a 'delete me soon'
> method to delete interfaces that would not block on the
> RCU code.
>
> The controlling programs could use netlink messages to
> know exactly when an interface was truly gone.
>
> That should allow some batching in the sync-net logic
> too, if user-space code deletes 1000 interfaces very
> quickly, for instance...
>
I suggested in the past to have an extension of batch capabilities, so
that one kthread could have 3 separate lists of devices being destroyed
in //,
This daemon would basically loop on one call to synchronize_rcu(), and
transfert list3 to deletion, list2 to list3, list1 to list2, loop,
eventually releasing RTNL while blocked in synchronize_rcu()
This would need to allow as you suggest an asynchronous deletion method,
or use a callback to wake the process blocked on device delete.
Right now, we hold RTNL for the whole 3 steps process, so we cannot use
any parallelism.
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Eric Dumazet @ 2011-05-07 16:26 UTC (permalink / raw)
To: Alex Bligh; +Cc: netdev
In-Reply-To: <0F4A638C2A523577CDBC295E@Ximines.local>
Le samedi 07 mai 2011 à 16:26 +0100, Alex Bligh a écrit :
> On the current 8 core box I am testing, I see 280ms per interface
> delete **even with only 10 interfaces**. I see 260ms with one
> interface. I know doing lots of rcu sync stuff can be slow, but
> 260ms to remove one veth pair sounds like more than rcu sync going
> on. It sounds like a sleep (though I may not have found the
> right one). I see no CPU load.
>
Here, on 2.6.38 kernel (Ubuntu 11.04 provided, on my 2 core laptop)
# time rmmod dummy
real 0m0.111s
user 0m0.000s
sys 0m0.000s
This removed my two dummy0/dummy1 devices.
On another machine with a very recent kernel :
$ modprobe dummy numdummies=1
$ ifconfig dummy0 192.168.46.46 up
$ time rmmod dummy
real 0m0.032s
user 0m0.000s
sys 0m0.001s
$ uname -a
Linux svivoipvnx001 2.6.39-rc6-00097-g6ac1576-dirty #550 SMP Sat May 7
00:12:26 CEST 2011 i686 i686 i386 GNU/Linux
So 260ms is a bit too much, maybe you hit yet another bug.
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Ben Greear @ 2011-05-07 16:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alex Bligh, netdev
In-Reply-To: <1304783684.9216.2.camel@edumazet-laptop>
On 05/07/2011 08:54 AM, Eric Dumazet wrote:
> Le samedi 07 mai 2011 à 16:26 +0100, Alex Bligh a écrit :
>> Well, I patched it (patch attached for what it's worth) and it made
>> no difference in this case. I would suggest however that it might
>> be the right think to do anyway.
>>
>
> As I said, this code should not be entered in normal situations.
>
> You are not the first to suggest a change, but it wont help you at all.
>
>
>
>
>> On the current 8 core box I am testing, I see 280ms per interface
>> delete **even with only 10 interfaces**. I see 260ms with one
>> interface. I know doing lots of rcu sync stuff can be slow, but
>> 260ms to remove one veth pair sounds like more than rcu sync going
>> on. It sounds like a sleep (though I may not have found the
>> right one). I see no CPU load.
>>
>> Equally, with one interface (remember I'm doing this in unshare -n
>> so there is only a loopback interface there), this bit surely
>> can't be sysfs.
>>
>
> synchronize_rcu() calls are not consuming cpu, they just _wait_
> rcu grace period.
>
> I suggest you read Documentation/RCU files if you really want to :)
>
> If you want to check how expensive it is, its quite easy:
> add a trace in synchronize_net()
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 856b6ee..70f3c46 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5915,8 +5915,10 @@ EXPORT_SYMBOL(free_netdev);
> */
> void synchronize_net(void)
> {
> + pr_err("begin synchronize_net()\n");
> might_sleep();
> synchronize_rcu();
> + pr_err("end synchronize_net()\n");
> }
> EXPORT_SYMBOL(synchronize_net);
I wonder if it would be worth having a 'delete me soon'
method to delete interfaces that would not block on the
RCU code.
The controlling programs could use netlink messages to
know exactly when an interface was truly gone.
That should allow some batching in the sync-net logic
too, if user-space code deletes 1000 interfaces very
quickly, for instance...
Thanks,
Ben
>
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: bug in select(2) regarding non-blocking connect(2) completion?
From: Michael Shuldman @ 2011-05-07 16:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, David S. Miller, karls, netdev
In-Reply-To: <1304770358.2821.1139.camel@edumazet-laptop>
Eric Dumazet wrote,
> Well, if you missed the original error report, all next getpeername()
> and SO_ERROR will do the same, and select() says fd is ready for 'write'
Many thanks for that. I was not aware that SO_ERROR would not get
set if the connect(2) failed "permanently" immediately, but have
now tested that it does. The other "strangeness" might very well
be caused by bugs related to this, so apologies for the noise and
many thanks for the help.
With kind regards,
--
_ //
\X/ -- Michael Shuldman
^ permalink raw reply
* Re: Scalability of interface creation and deletion
From: Eric Dumazet @ 2011-05-07 15:54 UTC (permalink / raw)
To: Alex Bligh; +Cc: netdev
In-Reply-To: <0F4A638C2A523577CDBC295E@Ximines.local>
Le samedi 07 mai 2011 à 16:26 +0100, Alex Bligh a écrit :
> Well, I patched it (patch attached for what it's worth) and it made
> no difference in this case. I would suggest however that it might
> be the right think to do anyway.
>
As I said, this code should not be entered in normal situations.
You are not the first to suggest a change, but it wont help you at all.
> On the current 8 core box I am testing, I see 280ms per interface
> delete **even with only 10 interfaces**. I see 260ms with one
> interface. I know doing lots of rcu sync stuff can be slow, but
> 260ms to remove one veth pair sounds like more than rcu sync going
> on. It sounds like a sleep (though I may not have found the
> right one). I see no CPU load.
>
> Equally, with one interface (remember I'm doing this in unshare -n
> so there is only a loopback interface there), this bit surely
> can't be sysfs.
>
synchronize_rcu() calls are not consuming cpu, they just _wait_
rcu grace period.
I suggest you read Documentation/RCU files if you really want to :)
If you want to check how expensive it is, its quite easy:
add a trace in synchronize_net()
diff --git a/net/core/dev.c b/net/core/dev.c
index 856b6ee..70f3c46 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5915,8 +5915,10 @@ EXPORT_SYMBOL(free_netdev);
*/
void synchronize_net(void)
{
+ pr_err("begin synchronize_net()\n");
might_sleep();
synchronize_rcu();
+ pr_err("end synchronize_net()\n");
}
EXPORT_SYMBOL(synchronize_net);
^ permalink raw reply related
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