* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Eric Dumazet @ 2011-09-19 20:46 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: David S. Miller, netdev, MuraliRaja Muniraju
In-Reply-To: <CANP3RGdxYg0Utfyrqfwoj+ojfCD+ZYJTa91nzPSdWBznZWKHaA@mail.gmail.com>
Le lundi 19 septembre 2011 à 13:39 -0700, Maciej Żenczykowski a écrit :
> The first hunk was for consistency - to always free in exit path. The
> second hunk is where the lockdep bug is.
>
> LOCKDEP gives the following (it's pretty rare):
>
> [ 90.543085] =======================================================
> [ 90.544012] [ INFO: possible circular locking dependency detected ]
> [ 90.544012] 2.6.34-smp-DEV #70
> [ 90.544012] -------------------------------------------------------
> [ 90.544012] swapper/0 is trying to acquire lock:
> [ 90.544012] (&tbl->lock){++--..}, at: [<ffffffff813c106d>]
> neigh_lookup+0x42/0xbf
> [ 90.544012]
> [ 90.544012] but task is already holding lock:
> [ 90.544012] (&(&rt_hash_locks[i])->rlock){+.-...}, at:
> [<ffffffff813db663>] rt_intern_hash+0xf2/0x3ad
> [ 90.544012]
> [ 90.544012] which lock already depends on the new lock.
> [ 90.544012]
> [ 90.544012]
> [ 90.544012] the existing dependency chain (in reverse order) is:
> [ 90.544012]
> [ 90.544012] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
> [ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff81430d66>] _raw_spin_lock_bh+0x36/0x45
> [ 90.544012] [<ffffffff813d9659>] rt_dst_release+0x4a/0x8d
> [ 90.544012] [<ffffffff813bee34>] dst_release+0x5d/0x66
> [ 90.544012] [<ffffffff813af24e>] skb_release_head_state+0x1f/0xa5
> [ 90.544012] [<ffffffff813aefec>] __kfree_skb+0x16/0x87
> [ 90.544012] [<ffffffff813af101>] kfree_skb+0x72/0x7a
> [ 90.544012] [<ffffffff813c06f9>] __neigh_event_send+0x126/0x176
> [ 90.544012] [<ffffffff813c2c1b>] neigh_resolve_output+0x7f/0x267
> [ 90.544012] [<ffffffff813e3057>] ip_finish_output2+0x1f2/0x221
> [ 90.544012] [<ffffffff813e30ea>] ip_finish_output+0x64/0x66
> [ 90.544012] [<ffffffff813e3200>] NF_HOOK_COND.clone.1+0x41/0x45
> [ 90.544012] [<ffffffff813e3277>] ip_output+0x73/0x75
> [ 90.544012] [<ffffffff813e1524>] dst_output+0x10/0x12
> [ 90.544012] [<ffffffff813e349f>] ip_local_out+0x23/0x27
> [ 90.544012] [<ffffffff813e378a>] ip_push_pending_frames+0x2e7/0x348
> [ 90.544012] [<ffffffff81401a13>] udp_push_pending_frames+0x2dc/0x35c
> [ 90.544012] [<ffffffff8140314e>] udp_sendmsg+0x628/0x763
> [ 90.544012] [<ffffffff81409933>] inet_sendmsg+0x58/0x61
> [ 90.544012] [<ffffffff813a726f>] __sock_sendmsg+0x5e/0x69
> [ 90.544012] [<ffffffff813a7737>] sock_sendmsg+0xa8/0xc1
> [ 90.544012] [<ffffffff813a79d9>] sys_sendmsg+0x1da/0x241
> [ 90.544012] [<ffffffff813cb482>] compat_sys_sendmsg+0x14/0x16
> [ 90.544012] [<ffffffff813cc081>] compat_sys_socketcall+0x13b/0x16c
> [ 90.544012] [<ffffffff81059687>] sysenter_dispatch+0x7/0x2c
> [ 90.544012]
> [ 90.544012] -> #1 (&n->lock){++--..}:
> [ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff81430e81>] _raw_write_lock+0x31/0x40
> [ 90.544012] [<ffffffff813c16fb>] neigh_periodic_work+0xae/0x196
> [ 90.544012] [<ffffffff8108a8ca>] worker_thread+0x1fb/0x2f1
> [ 90.544012] [<ffffffff8108e099>] kthread+0x7f/0x87
> [ 90.544012] [<ffffffff81032a94>] kernel_thread_helper+0x4/0x10
> [ 90.544012]
> [ 90.544012] -> #0 (&tbl->lock){++--..}:
> [ 90.544012] [<ffffffff810a47ba>] __lock_acquire+0x9e5/0xcda
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff81430ffa>] _raw_read_lock_bh+0x39/0x48
> [ 90.544012] [<ffffffff813c106d>] neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff81405067>]
> __neigh_lookup_errno.clone.0+0x24/0x40
> [ 90.544012] [<ffffffff814054b2>] arp_bind_neighbour+0x4c/0x65
> [ 90.544012] [<ffffffff813db815>] rt_intern_hash+0x2a4/0x3ad
> [ 90.544012] [<ffffffff813dc054>] ip_route_output_slow+0x6ec/0x739
> [ 90.544012] [<ffffffff813dc574>] __ip_route_output_key+0x1bd/0x1c9
> [ 90.544012] [<ffffffff81406f45>] icmp_send+0x2bf/0x3ca
> [ 90.544012] [<ffffffff813d9739>] ipv4_link_failure+0x22/0x5c
> [ 90.544012] [<ffffffff81404acd>] arp_error_report+0x31/0x3d
> [ 90.544012] [<ffffffff813c1172>] neigh_invalidate+0x88/0xa3
> [ 90.544012] [<ffffffff813c2a1b>] neigh_timer_handler+0x1a8/0x27f
> [ 90.544012] [<ffffffff8108087a>] run_timer_softirq+0x219/0x2e3
> [ 90.544012] [<ffffffff8107910e>] __do_softirq+0xf7/0x1cb
> [ 90.544012] [<ffffffff81032b8c>] call_softirq+0x1c/0x3e
> [ 90.544012] [<ffffffff81034615>] do_softirq+0x3d/0x85
> [ 90.544012] [<ffffffff81078d49>] irq_exit+0x4a/0x8c
> [ 90.544012] [<ffffffff8143708c>] smp_apic_timer_interrupt+0x99/0xa7
> [ 90.544012] [<ffffffff81032653>] apic_timer_interrupt+0x13/0x20
> [ 90.544012] [<ffffffff81030d92>] cpu_idle+0x5c/0x79
> [ 90.544012] [<ffffffff8142213f>] rest_init+0xc3/0xca
> [ 90.544012] [<ffffffff81b47d77>] start_kernel+0x3e2/0x3ed
> [ 90.544012] [<ffffffff81b4729f>] x86_64_start_reservations+0xaf/0xb3
> [ 90.544012] [<ffffffff81b47393>] x86_64_start_kernel+0xf0/0xf7
> [ 90.544012]
> [ 90.544012] other info that might help us debug this:
> [ 90.544012]
> [ 90.544012] 3 locks held by swapper/0:
> [ 90.544012] #0: (&n->timer){+.-...}, at: [<ffffffff810807e8>]
> run_timer_softirq+0x187/0x2e3
> [ 90.544012] #1: (slock-AF_INET){+.-...}, at: [<ffffffff814063d3>]
> icmp_xmit_lock+0x35/0x47
> [ 90.544012] #2: (&(&rt_hash_locks[i])->rlock){+.-...}, at:
> [<ffffffff813db663>] rt_intern_hash+0xf2/0x3ad
> [ 90.544012]
> [ 90.544012] stack backtrace:
> [ 90.544012] Pid: 0, comm: swapper Not tainted 2.6.34-smp-DEV #70
> [ 90.544012] Call Trace:
> [ 90.544012] <IRQ> [<ffffffff810a39c0>] print_circular_bug+0xa8/0xb7
> [ 90.544012] [<ffffffff810a47ba>] __lock_acquire+0x9e5/0xcda
> [ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff81430ffa>] _raw_read_lock_bh+0x39/0x48
> [ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff813c106d>] neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff81405067>] __neigh_lookup_errno.clone.0+0x24/0x40
> [ 90.544012] [<ffffffff814054b2>] arp_bind_neighbour+0x4c/0x65
> [ 90.544012] [<ffffffff813db663>] ? rt_intern_hash+0xf2/0x3ad
> [ 90.544012] [<ffffffff813db815>] rt_intern_hash+0x2a4/0x3ad
> [ 90.544012] [<ffffffff813dc054>] ip_route_output_slow+0x6ec/0x739
> [ 90.544012] [<ffffffff81078f49>] ? _local_bh_enable_ip+0xc1/0xc7
> [ 90.544012] [<ffffffff813dc574>] __ip_route_output_key+0x1bd/0x1c9
> [ 90.544012] [<ffffffff81406f45>] icmp_send+0x2bf/0x3ca
> [ 90.544012] [<ffffffff813c2800>] ? neigh_event_ns+0x2f/0xa2
> [ 90.544012] [<ffffffff813d9739>] ipv4_link_failure+0x22/0x5c
> [ 90.544012] [<ffffffff81404acd>] arp_error_report+0x31/0x3d
> [ 90.544012] [<ffffffff813c1172>] neigh_invalidate+0x88/0xa3
> [ 90.544012] [<ffffffff813c2a1b>] neigh_timer_handler+0x1a8/0x27f
> [ 90.544012] [<ffffffff8108087a>] run_timer_softirq+0x219/0x2e3
> [ 90.544012] [<ffffffff810807e8>] ? run_timer_softirq+0x187/0x2e3
> [ 90.544012] [<ffffffff8109158d>] ? __run_hrtimer+0xf4/0x132
> [ 90.544012] [<ffffffff813c2873>] ? neigh_timer_handler+0x0/0x27f
> [ 90.544012] [<ffffffff8107908d>] ? __do_softirq+0x76/0x1cb
> [ 90.544012] [<ffffffff8107910e>] __do_softirq+0xf7/0x1cb
> [ 90.544012] [<ffffffff8109f74a>] ? tick_program_event+0x2a/0x2c
> [ 90.544012] [<ffffffff81032b8c>] call_softirq+0x1c/0x3e
> [ 90.544012] [<ffffffff81034615>] do_softirq+0x3d/0x85
> [ 90.544012] [<ffffffff81078d49>] irq_exit+0x4a/0x8c
> [ 90.544012] [<ffffffff8143708c>] smp_apic_timer_interrupt+0x99/0xa7
> [ 90.544012] [<ffffffff81032653>] apic_timer_interrupt+0x13/0x20
> [ 90.544012] <EOI> [<ffffffff81039700>] ? mwait_idle+0x85/0x92
> [ 90.544012] [<ffffffff810396f7>] ? mwait_idle+0x7c/0x92
> [ 90.544012] [<ffffffff81030d92>] cpu_idle+0x5c/0x79
> [ 90.544012] [<ffffffff8142213f>] rest_init+0xc3/0xca
> [ 90.544012] [<ffffffff8142207c>] ? rest_init+0x0/0xca
> [ 90.544012] [<ffffffff81b47d77>] start_kernel+0x3e2/0x3ed
> [ 90.544012] [<ffffffff81b4729f>] x86_64_start_reservations+0xaf/0xb3
> [ 90.544012] [<ffffffff81b47393>] x86_64_start_kernel+0xf0/0xf7
>
> At some point in the past of the lifetime of this kernel we grabbed
> exactly the following 3 locks in the following order (where the first
> 2 were still held while we grabbed the 3rd):
> (&tbl->lock){++--..} => (&n->lock){++--..} =>
> (&(&rt_hash_locks[i])->rlock){+.-...}
>
> Now, we have grabbed the first three (are still holding them and are
> trying to grab the fourth) of these locks in this order:
> (&n->timer){+.-...} => (slock-AF_INET){+.-...} =>
> (&(&rt_hash_locks[i])->rlock){+.-...} => (&tbl->lock){++--..}
>
> We're complaining that this 4th lock is being grabbed after the 3rd,
> when previously it was the 1st before the 3rd - we've apparently
> reversed lock ordering...
Hmm
What exact kernel version is it ?
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: David Miller @ 2011-09-19 20:56 UTC (permalink / raw)
To: bhutchings; +Cc: alexander.h.duyck, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <1316448352.2764.27.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 19 Sep 2011 17:05:52 +0100
> But tx_max_coalesced_frames_irq is not supposed to be a work limit (and
> such a work limit doesn't seem useful in the absence of NAPI). As I
> understand it, it is supposed to be an alternate moderation value for
> the hardware to use if a frame is sent while the IRQ handler is running.
Exactly, the ethtool settings modify what the hardware interrupt mechanisms
do, ragardless of whether those hardware interrupts trigger NAPI or not.
And this is precisely what we want, because optimal behavior of NAPI
absoulutely depends upon having the interrupt moderated in hardware
at least a little bit.
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: David Miller @ 2011-09-19 20:57 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: alexander.h.duyck, netdev, gospo
In-Reply-To: <1316246677-8830-12-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 17 Sep 2011 01:04:35 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change is meant to make the NAPI budget limits for transmit
> adjustable. By doing this it is possible to tune the value for optimal
> performance with applications such as routing.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
As Ben and I have mentioned, this change is not acceptable.
Ethtool settings for "hardware interrupt" coalescing and mitigation
should have no effect on NAPI behavior.
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: David Miller @ 2011-09-19 21:00 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: bhutchings, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <4E776E92.6090303@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Mon, 19 Sep 2011 09:32:18 -0700
> The fact is ixgbe has been using this parameter this way for over 2
> years now and the main goal of this patch was just to synchronize how
> things work on igb and ixgbe.
>
> Our hardware doesn't have a mechanism for firing an interrupt after X
> number of frames so instead we simply have modified things so that we
> will only process X number of frames and then fire another
> interrupt/poll if needed. As such we aren't that far out of
> compliance with the meaning of how this parameter is supposed to be
> used.
All I can say is this was a huge mistake you therefore need to revert
the IXGBE change, these ethtool settings are not for changing NAPI or
software interrupt behavior.
And if you guys plan to be difficult on this and refuse to remove the
IXGBE bits, I'm letting you guys know ahead of time that I'll do it
for you.
If the hardware can't support this facility, neither should these
ethtool hooks, because the whole point is to avoid hardware interrupts
from firing using these parameters.
Propose new mechanisms to control NAPI behavior if you want.
^ permalink raw reply
* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Eric Dumazet @ 2011-09-19 21:03 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: David S. Miller, netdev, MuraliRaja Muniraju
In-Reply-To: <1316465182.2455.10.camel@edumazet-laptop>
Le lundi 19 septembre 2011 à 22:46 +0200, Eric Dumazet a écrit :
> Le lundi 19 septembre 2011 à 13:39 -0700, Maciej Żenczykowski a écrit :
> > [ 90.544012] the existing dependency chain (in reverse order) is:
> > [ 90.544012]
> > [ 90.544012] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
> > [ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
> > [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> > [ 90.544012] [<ffffffff81430d66>] _raw_spin_lock_bh+0x36/0x45
> > [ 90.544012] [<ffffffff813d9659>] rt_dst_release+0x4a/0x8d
rt_dst_release() again...
> > [ 90.544012] [<ffffffff813bee34>] dst_release+0x5d/0x66
> > [ 90.544012] [<ffffffff813af24e>] skb_release_head_state+0x1f/0xa5
> > [ 90.544012] [<ffffffff813aefec>] __kfree_skb+0x16/0x87
> > [ 90.544012] [<ffffffff813af101>] kfree_skb+0x72/0x7a
> > [ 90.544012] [<ffffffff813c06f9>] __neigh_event_send+0x126/0x176
> >
> Hmm
>
> What exact kernel version is it ?
>
>
Just to say what I already said to Murali raja Muniraju one week ago :
To my knowledge, no linux pristine linux kernel has this bug.
dst_release() is lockless.
So could you explain why its so important we add this 'bugfix' if it
only applies to a Google kernel ?
Anything I missed from my previous analysis ?
Thanks !
^ permalink raw reply
* Re: pull request: wireless-next 2011-09-19
From: David Miller @ 2011-09-19 21:11 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20110919203639.GF2608@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 19 Sep 2011 16:36:39 -0400
> Here is another big batch of updates intended for 3.2 -- still
> clearing-out the backlog...
>
> This round includes lots of updates to ath9k, b43, iwlagn, and rt2x00.
> Some cleanups go to mac80211, along with a number of mesh-mode fixes
> from Javier.
>
> Please let me know if there are problems!
What about the iwl build failure reported by Eric Dumazet?
If that's not handled here, I want that fixed before we add even
more regressions :-)
^ permalink raw reply
* Re: [net-next 01/13] ixgb: eliminate checkstack warnings
From: Jesse Brandeburg @ 2011-09-19 21:36 UTC (permalink / raw)
To: Joe Perches
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <1316249007.1610.13.camel@Joe-Laptop>
On Sat, 17 Sep 2011 01:43:26 -0700
Joe Perches <joe@perches.com> wrote:
> On Sat, 2011-09-17 at 01:04 -0700, Jeff Kirsher wrote:
> > From: Jesse Brandeburg <jesse.brandeburg@intel.com>
> > Really trivial fix, use kzalloc/kree instead of stack space.
>
> Some more trivialities...
>
> > diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
> > b/drivers/net/ethernet/intel/ixgb/ixgb_main.c\
> []
> > @@ -1120,8 +1120,12 @@ ixgb_set_multi(struct net_device *netdev)
> > rctl |= IXGB_RCTL_MPE;
> > IXGB_WRITE_REG(hw, RCTL, rctl);
> > } else {
> > - u8 mta[IXGB_MAX_NUM_MULTICAST_ADDRESSES *
> > - IXGB_ETH_LENGTH_OF_ADDRESS];
> > + u8 *mta = kzalloc(IXGB_MAX_NUM_MULTICAST_ADDRESSES
> > *
> > + IXGB_ETH_LENGTH_OF_ADDRESS,
> > GFP_KERNEL);
>
> This doesn't need to be kzalloc as every byte is overwritten.
> It should be kmalloc.
done, V2 on its way
> Maybe delete the #define IXGB_ETH_LENGTH_OF_ADDRESS and
> sed 's/\bIXGB_ETH_LENGTH_OF_ADDRESS\b/ETH_ALEN/g' ?
done
> Perhaps this loop could be clearer without the multiply:
>
> i = 0;
> netdev_for_each_mc_addr(ha, netdev)
> memcpy(&mta[i++ * IXGB_ETH_LENGTH_OF_ADDRESS],
> ha->addr, IXGB_ETH_LENGTH_OF_ADDRESS);
>
> Perhaps:
>
> u8 *addr = mta;
> netdev_for_each_mc_addr(ha, netdev) {
> memcpy(addr, ha->addr, ETH_ALEN);
> addr += ETH_ALEN;
> }
done, but because of the nature of the changes being code flow, I'm
going to retest through our lab. V2 will hopefully be at the list
shortly.
Thanks for the feedback,
Jesse
^ permalink raw reply
* Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by default
From: Tim Chen @ 2011-09-19 21:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, zheng.z.yan, yanzheng, netdev, sfr, jirislaby,
sedat.dilek, alex.shi, Valdis.Kletnieks
In-Reply-To: <1316447547.2539.34.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, 2011-09-19 at 17:52 +0200, Eric Dumazet wrote:
> Since commit 7361c36c5224 (af_unix: Allow credentials to work across
> user and pid namespaces) af_unix performance dropped a lot.
>
> This is because we now take a reference on pid and cred in each write(),
> and release them in read(), usually done from another process,
> eventually from another cpu. This triggers false sharing.
>
> # Events: 154K cycles
> #
> # Overhead Command Shared Object Symbol
> # ........ ....... .................. .........................
> #
> 10.40% hackbench [kernel.kallsyms] [k] put_pid
> 8.60% hackbench [kernel.kallsyms] [k] unix_stream_recvmsg
> 7.87% hackbench [kernel.kallsyms] [k] unix_stream_sendmsg
> 6.11% hackbench [kernel.kallsyms] [k] do_raw_spin_lock
> 4.95% hackbench [kernel.kallsyms] [k] unix_scm_to_skb
> 4.87% hackbench [kernel.kallsyms] [k] pid_nr_ns
> 4.34% hackbench [kernel.kallsyms] [k] cred_to_ucred
> 2.39% hackbench [kernel.kallsyms] [k] unix_destruct_scm
> 2.24% hackbench [kernel.kallsyms] [k] sub_preempt_count
> 1.75% hackbench [kernel.kallsyms] [k] fget_light
> 1.51% hackbench [kernel.kallsyms] [k]
> __mutex_lock_interruptible_slowpath
> 1.42% hackbench [kernel.kallsyms] [k] sock_alloc_send_pskb
>
>
> This patch includes SCM_CREDENTIALS information in a af_unix message/skb
> only if requested by the sender, [man 7 unix for details how to include
> ancillary data using sendmsg() system call]
>
> Note: This might break buggy applications that expected SCM_CREDENTIAL
> from an unaware write() system call, and receiver not using SO_PASSCRED
> socket option.
>
> If SOCK_PASSCRED is set on source or destination socket, we still
> include credentials for mere write() syscalls.
>
> Performance boost in hackbench : more than 50% gain on a 16 thread
> machine (2 quad-core cpus, 2 threads per core)
>
> hackbench 20 thread 2000
>
> 4.228 sec instead of 9.102 sec
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
Do we have to worry about the case where peer socket changes its flag
to SOCK_PASSCRED while packets are in flight? If there isn't such
pathological use case, the patch looks fine to me.
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Alexander Duyck @ 2011-09-19 22:27 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <20110919.170033.344802441047363137.davem@davemloft.net>
On 09/19/2011 02:00 PM, David Miller wrote:
> From: Alexander Duyck<alexander.h.duyck@intel.com>
> Date: Mon, 19 Sep 2011 09:32:18 -0700
>> The fact is ixgbe has been using this parameter this way for over 2
>> years now and the main goal of this patch was just to synchronize how
>> things work on igb and ixgbe.
>>
>> Our hardware doesn't have a mechanism for firing an interrupt after X
>> number of frames so instead we simply have modified things so that we
>> will only process X number of frames and then fire another
>> interrupt/poll if needed. As such we aren't that far out of
>> compliance with the meaning of how this parameter is supposed to be
>> used.
> All I can say is this was a huge mistake you therefore need to revert
> the IXGBE change, these ethtool settings are not for changing NAPI or
> software interrupt behavior.
>
> And if you guys plan to be difficult on this and refuse to remove the
> IXGBE bits, I'm letting you guys know ahead of time that I'll do it
> for you.
>
> If the hardware can't support this facility, neither should these
> ethtool hooks, because the whole point is to avoid hardware interrupts
> from firing using these parameters.
>
> Propose new mechanisms to control NAPI behavior if you want.
I'll remove the ixgbe code if that is what you want. It may be a month
or so before I can get to it though since I am slammed with work so if
you are in a hurry for it you might want to work with Jeff Kirsher to
have the code removed.
As far as this current patch goes I honestly don't have the time to add
or rewrite yet another ethtool interface so I will probably just see
about dropping the ethtool portion of this patch and update the
description in order to make it acceptable.
Thanks,
Alex
^ permalink raw reply
* [PATCH] intel: Convert <FOO>_LENGTH_OF_ADDRESS to ETH_ALEN
From: Joe Perches @ 2011-09-19 22:28 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <20110919143629.00007675@unknown>
Use the normal #defines not module specific ones.
Signed-off-by: Joe Perches <joe@perches.com>
---
Here are the other, not ixgb uses of LENGTH_OF_ADDRESS
converted to ETH_ALEN. Compile tested allyesconfig only.
drivers/net/ethernet/intel/e1000/e1000_hw.h | 1 -
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 8 +++-----
drivers/net/ethernet/intel/ixgbevf/defines.h | 1 -
drivers/net/ethernet/intel/ixgbevf/vf.c | 4 ++--
5 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_hw.h b/drivers/net/ethernet/intel/e1000/e1000_hw.h
index 5c9a840..cf7e3c0 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_hw.h
+++ b/drivers/net/ethernet/intel/e1000/e1000_hw.h
@@ -448,7 +448,6 @@ void e1000_io_write(struct e1000_hw *hw, unsigned long port, u32 value);
#define E1000_DEV_ID_INTEL_CE4100_GBE 0x2E6E
#define NODE_ADDRESS_SIZE 6
-#define ETH_LENGTH_OF_ADDRESS 6
/* MAC decode size is 128K - This is the size of BAR0 */
#define MAC_DECODE_SIZE (128 * 1024)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index d99d01e..29e092c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -363,7 +363,7 @@ static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
/* reply to reset with ack and vf mac address */
msgbuf[0] = IXGBE_VF_RESET | IXGBE_VT_MSGTYPE_ACK;
- memcpy(new_mac, vf_mac, IXGBE_ETH_LENGTH_OF_ADDRESS);
+ memcpy(new_mac, vf_mac, ETH_ALEN);
/*
* Piggyback the multicast filter type so VF can compute the
* correct vectors
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 9f618ee..ef34606 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -1699,8 +1699,6 @@ enum {
#define IXGBE_NVM_POLL_WRITE 1 /* Flag for polling for write complete */
#define IXGBE_NVM_POLL_READ 0 /* Flag for polling for read complete */
-#define IXGBE_ETH_LENGTH_OF_ADDRESS 6
-
#define IXGBE_EEPROM_PAGE_SIZE_MAX 128
#define IXGBE_EEPROM_RD_BUFFER_MAX_COUNT 512 /* EEPROM words # read in burst */
#define IXGBE_EEPROM_WR_BUFFER_MAX_COUNT 256 /* EEPROM words # wr in burst */
@@ -2737,9 +2735,9 @@ struct ixgbe_eeprom_info {
struct ixgbe_mac_info {
struct ixgbe_mac_operations ops;
enum ixgbe_mac_type type;
- u8 addr[IXGBE_ETH_LENGTH_OF_ADDRESS];
- u8 perm_addr[IXGBE_ETH_LENGTH_OF_ADDRESS];
- u8 san_addr[IXGBE_ETH_LENGTH_OF_ADDRESS];
+ u8 addr[ETH_ALEN];
+ u8 perm_addr[ETH_ALEN];
+ u8 san_addr[ETH_ALEN];
/* prefix for World Wide Node Name (WWNN) */
u16 wwnn_prefix;
/* prefix for World Wide Port Name (WWPN) */
diff --git a/drivers/net/ethernet/intel/ixgbevf/defines.h b/drivers/net/ethernet/intel/ixgbevf/defines.h
index 78abb6f..2eb89cb 100644
--- a/drivers/net/ethernet/intel/ixgbevf/defines.h
+++ b/drivers/net/ethernet/intel/ixgbevf/defines.h
@@ -35,7 +35,6 @@
#define IXGBE_VF_IRQ_CLEAR_MASK 7
#define IXGBE_VF_MAX_TX_QUEUES 1
#define IXGBE_VF_MAX_RX_QUEUES 1
-#define IXGBE_ETH_LENGTH_OF_ADDRESS 6
/* Link speed */
typedef u32 ixgbe_link_speed;
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index aa3682e..21533e3 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -108,7 +108,7 @@ static s32 ixgbevf_reset_hw_vf(struct ixgbe_hw *hw)
if (msgbuf[0] != (IXGBE_VF_RESET | IXGBE_VT_MSGTYPE_ACK))
return IXGBE_ERR_INVALID_MAC_ADDR;
- memcpy(hw->mac.perm_addr, addr, IXGBE_ETH_LENGTH_OF_ADDRESS);
+ memcpy(hw->mac.perm_addr, addr, ETH_ALEN);
hw->mac.mc_filter_type = msgbuf[IXGBE_VF_MC_TYPE_WORD];
return 0;
@@ -211,7 +211,7 @@ static s32 ixgbevf_mta_vector(struct ixgbe_hw *hw, u8 *mc_addr)
**/
static s32 ixgbevf_get_mac_addr_vf(struct ixgbe_hw *hw, u8 *mac_addr)
{
- memcpy(mac_addr, hw->mac.perm_addr, IXGBE_ETH_LENGTH_OF_ADDRESS);
+ memcpy(mac_addr, hw->mac.perm_addr, ETH_ALEN);
return 0;
}
^ permalink raw reply related
* Re: [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Troy Kisky @ 2011-09-19 22:39 UTC (permalink / raw)
To: Shawn Guo; +Cc: netdev, David S. Miller, linux-arm-kernel, patches
In-Reply-To: <1316346852-17090-4-git-send-email-shawn.guo@linaro.org>
On 9/18/2011 4:54 AM, Shawn Guo wrote:
> With the unnecessary 1 bit left-shift on fep->phy_speed during the
> calculation, the phy_speed always runs at the half frequency of the
> optimal one 2.5 MHz.
>
> The patch removes that 1 bit left-shift to get the optimal phy_speed.
>
> Signed-off-by: Shawn Guo<shawn.guo@linaro.org>
> ---
> drivers/net/fec.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 5ef0e34..04206e4 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> /*
> * Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
> */
> - fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000)<< 1;
> + fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
> writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
>
> fep->mii_bus = mdiobus_alloc();
Do you need to round up to an even value? Is the hardware documentation
wrong?
Does this need a quirk? What boards has this been verified to fix?
Thanks
Troy
^ permalink raw reply
* Re: [PATCH] intel: Convert <FOO>_LENGTH_OF_ADDRESS to ETH_ALEN
From: Jeff Kirsher @ 2011-09-19 23:33 UTC (permalink / raw)
To: Joe Perches
Cc: Brandeburg, Jesse, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <1316471288.22881.3.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]
On Mon, 2011-09-19 at 15:28 -0700, Joe Perches wrote:
> Use the normal #defines not module specific ones.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> Here are the other, not ixgb uses of LENGTH_OF_ADDRESS
> converted to ETH_ALEN. Compile tested allyesconfig only.
>
> drivers/net/ethernet/intel/e1000/e1000_hw.h | 1 -
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 8 +++-----
> drivers/net/ethernet/intel/ixgbevf/defines.h | 1 -
> drivers/net/ethernet/intel/ixgbevf/vf.c | 4 ++--
> 5 files changed, 6 insertions(+), 10 deletions(-)
Thanks Joe. I have added the patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Jeff Kirsher @ 2011-09-19 23:36 UTC (permalink / raw)
To: Duyck, Alexander H
Cc: David Miller, bhutchings@solarflare.com, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <4E77C1D4.503@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]
On Mon, 2011-09-19 at 15:27 -0700, Duyck, Alexander H wrote:
> On 09/19/2011 02:00 PM, David Miller wrote:
> > From: Alexander Duyck<alexander.h.duyck@intel.com>
> > Date: Mon, 19 Sep 2011 09:32:18 -0700
> >> The fact is ixgbe has been using this parameter this way for over 2
> >> years now and the main goal of this patch was just to synchronize how
> >> things work on igb and ixgbe.
> >>
> >> Our hardware doesn't have a mechanism for firing an interrupt after X
> >> number of frames so instead we simply have modified things so that we
> >> will only process X number of frames and then fire another
> >> interrupt/poll if needed. As such we aren't that far out of
> >> compliance with the meaning of how this parameter is supposed to be
> >> used.
> > All I can say is this was a huge mistake you therefore need to revert
> > the IXGBE change, these ethtool settings are not for changing NAPI or
> > software interrupt behavior.
> >
> > And if you guys plan to be difficult on this and refuse to remove the
> > IXGBE bits, I'm letting you guys know ahead of time that I'll do it
> > for you.
> >
> > If the hardware can't support this facility, neither should these
> > ethtool hooks, because the whole point is to avoid hardware interrupts
> > from firing using these parameters.
> >
> > Propose new mechanisms to control NAPI behavior if you want.
> I'll remove the ixgbe code if that is what you want. It may be a month
> or so before I can get to it though since I am slammed with work so if
> you are in a hurry for it you might want to work with Jeff Kirsher to
> have the code removed.
Alex- I will work on this to resolve the issues the Ben and Dave have
pointed out.
>
> As far as this current patch goes I honestly don't have the time to add
> or rewrite yet another ethtool interface so I will probably just see
> about dropping the ethtool portion of this patch and update the
> description in order to make it acceptable.
>
> Thanks,
>
> Alex
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Stephen Hemminger @ 2011-09-19 23:42 UTC (permalink / raw)
To: jeffrey t kirsher
Cc: David Miller, bhutchings, netdev, gospo, Alexander H Duyck
In-Reply-To: <1316475390.2184.8.camel@jtkirshe-mobl>
I would like to see a general solution to allow configuring
napi weight. The Rx weight isn't easily configurable either.
Probably needs to be through ethtool callback since actual value range
and dev -> napi relationship is device specific.
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: David Miller @ 2011-09-19 23:47 UTC (permalink / raw)
To: stephen.hemminger
Cc: jeffrey.t.kirsher, bhutchings, netdev, gospo, alexander.h.duyck
In-Reply-To: <19fca01e-5827-4e28-b12c-2b65cca96878@tahiti.vyatta.com>
From: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date: Mon, 19 Sep 2011 16:42:31 -0700 (PDT)
> I would like to see a general solution to allow configuring
> napi weight. The Rx weight isn't easily configurable either.
> Probably needs to be through ethtool callback since actual value range
> and dev -> napi relationship is device specific.
Agreed, it probably has to be per-queue too.
^ permalink raw reply
* Re: MSI-X vector count on 82754L
From: Jeff Kirsher @ 2011-09-19 23:56 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Allan, Bruce W, netdev@vger.kernel.org, Vogel, Jack
In-Reply-To: <CACqU3MUfQn_r2oJ+ptuzYhkkUoucfL_NTMnHoCa0+TouP0s0kA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]
On Sun, 2011-09-18 at 22:34 -0700, Arnaud Lacombe wrote:
> [fixing address of the netdev@ list, sorry - A.]
>
> On Mon, Sep 19, 2011 at 1:31 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> > Hi folks,
> >
> > In:
> >
> > commit 4662e82b2cb41c60826e50474dd86dd5c6372b0c
> > Author: Bruce Allan <bruce.w.allan@intel.com>
> > Date: Tue Aug 26 18:37:06 2008 -0700
> >
> > e1000e: add support for new 82574L part
> >
> > This new part has the same feature set as previous parts with the addition
> > of MSI-X support.
> >
> > Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
> >
> > MSI-X support was added to the e1000e driver, later on slightly reworked by:
> >
> > commit 8e86acd7d5968e08b3e1604e685a8c45f6fd7f40
> > Author: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Date: Mon Aug 2 14:27:23 2010 +0000
> >
> > e1000e: Fix irq_synchronize in MSI-X case
> >
> > Based on original patch/work from Jean Delvare <jdelvare@suse.de>
> > Synchronize all IRQs when in MSI-X IRQ mode.
> >
> > Jean's original patch hard coded the sync with the 3 possible vectors,
> > this patch incorporates more flexibility for the future and aligns
> > with how igb stores the number of vectors into the adapter structure.
> >
> > CC: Jean Delvare <jdelvare@suse.de>
> > Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> > Acked-by: Bruce Allan <bruce.w.allan@intel.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > [It is unclear to what "Jean" does this commit log refers to, as the
> > support MSI-X was added Bruce, anyway...]
> >
> > Why only 3 vectors are used when both the product brief and the
> > datasheet advertise up to 5 MSI-X vector usable by the chip ? That is
> > 2*RX + 2*TX.
> >
> > Thanks in advance,
> > - Arnaud
> >
The e1000e driver is only a single queue driver so it does not need more
than 3 vectors, that is the reason we only use the 3 vectors.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Maciej Żenczykowski @ 2011-09-20 0:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev, MuraliRaja Muniraju
In-Reply-To: <1316466207.2455.15.camel@edumazet-laptop>
> To my knowledge, no linux pristine linux kernel has this bug.
>
> dst_release() is lockless.
You are probably right there, I missed that this was caused by some
other old crappy code we've been trying to get rid of.
> So could you explain why its so important we add this 'bugfix' if it
> only applies to a Google kernel ?
Freeing the skb later seemed to be pretty painless...
> Anything I missed from my previous analysis ?
>
> Thanks !
Probably not.
Now that the dst cache is going away this probably doesn't really
matter either way.
Maciej
^ permalink raw reply
* Re: [net-next 01/11] ixgb: convert to ndo_fix_features
From: Jeff Kirsher @ 2011-09-20 0:02 UTC (permalink / raw)
To: Michał Mirosław
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <20110917132153.GA32572@rere.qmqm.pl>
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
On Sat, 2011-09-17 at 06:21 -0700, Michał Mirosław wrote:
> On Fri, Sep 16, 2011 at 07:15:42PM -0700, Jeff Kirsher wrote:
> > From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > Private rx_csum flags are now duplicate of netdev->features &
> NETIF_F_RXCSUM.
> > Removing this needs deeper surgery.
> [...]
>
> Hmm. Looks like this patch is not complete: part removing
> get/set_flags
> from ethtool_ops is missing. I don't remember if this was included or
> not
> in the patch I sent originally. I'm attaching it now, rebased on
> current
> net-next (not tested).
>
> Best Regards,
> Michał Mirosław
>
> ---
>
> Finish conversion to unified ethtool ops: convert get_flags.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Thanks Michal, I have added the patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Ben Hutchings @ 2011-09-20 0:10 UTC (permalink / raw)
To: Stephen Hemminger
Cc: jeffrey t kirsher, David Miller, netdev, gospo, Alexander H Duyck
In-Reply-To: <19fca01e-5827-4e28-b12c-2b65cca96878@tahiti.vyatta.com>
On Mon, 2011-09-19 at 16:42 -0700, Stephen Hemminger wrote:
> I would like to see a general solution to allow configuring
> napi weight. The Rx weight isn't easily configurable either.
Indeed.
> Probably needs to be through ethtool callback since actual value range
> and dev -> napi relationship is device specific.
The maximum meaningful value is device specific but I'm not sure that
really matters.
And as David said it's really a many-to-one mapping of queue -> NAPI.
At netconf we talked about having 'irq' as an attribute of each queue
but maybe we should expose NAPI contexts through sysfs and make queues
refer to them instead. NAPI contexts would be named (in the same way as
the corresponding IRQ handlers) and have irq, weight, etc.
(Still short of time to work on this myself, alas.)
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 net-next] af_unix: dont send SCM_CREDENTIALS by default
From: Valdis.Kletnieks @ 2011-09-20 2:10 UTC (permalink / raw)
To: Tim Chen
Cc: Eric Dumazet, David Miller, zheng.z.yan, yanzheng, netdev, sfr,
jirislaby, sedat.dilek, alex.shi
In-Reply-To: <1316468398.4680.6.camel@schen9-DESK>
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
On Mon, 19 Sep 2011 14:39:58 PDT, Tim Chen said:
> Do we have to worry about the case where peer socket changes its flag
> to SOCK_PASSCRED while packets are in flight? If there isn't such
> pathological use case, the patch looks fine to me.
I wouldn't think so - if you're sending a packet, and retroactively trying to
change the flag and expect it to work, your program is too ugly to live. After
all, if the scheduler had cut off your timeslice and scheduledthe receiving
process before you set the flag, that packet would be delivered and done with
anyhow, and no amount of wishing will set that flag on an already-delivered
packet.
What *is* worth checking is that we DTRT if a process/thread is doing a send on
one CPU, and another process/thread with a shared file descriptor for that
socket is diddling the flag. But if we just define it as "atomic op to change
the flag and other observers get whatever value their CPU sees at that
instant", I'm OK with that too.. ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Why not refresh ipv6 local link address of a bridge when a new interface added to the bridge?
From: Eric Xiong @ 2011-09-20 2:39 UTC (permalink / raw)
To: netdev
In-Reply-To: <CA+UXGK1XAgCxYUoOAP6yQSGhzDB-3p3oDqOoOc_e=rTT3DPx7Q@mail.gmail.com>
Hi all:
Sorry for disturb! when adding a interface to bridge, maybe the bridge
mac address will be changed. the bridge code don't invoke
call_netdevice_notifiers to notify ipv6 code to refresh local link
address. I don't know why. Thanks for your help!
BRs.
^ permalink raw reply
* Re: [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Shawn Guo @ 2011-09-20 2:57 UTC (permalink / raw)
To: Troy Kisky; +Cc: Shawn Guo, netdev, David S. Miller, linux-arm-kernel, patches
In-Reply-To: <4E77C4A2.1060802@boundarydevices.com>
On Mon, Sep 19, 2011 at 03:39:30PM -0700, Troy Kisky wrote:
> On 9/18/2011 4:54 AM, Shawn Guo wrote:
> >With the unnecessary 1 bit left-shift on fep->phy_speed during the
> >calculation, the phy_speed always runs at the half frequency of the
> >optimal one 2.5 MHz.
> >
> >The patch removes that 1 bit left-shift to get the optimal phy_speed.
> >
> >Signed-off-by: Shawn Guo<shawn.guo@linaro.org>
> >---
> > drivers/net/fec.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> >diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> >index 5ef0e34..04206e4 100644
> >--- a/drivers/net/fec.c
> >+++ b/drivers/net/fec.c
> >@@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> > /*
> > * Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
> > */
> >- fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000)<< 1;
> >+ fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
> > writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
> >
> > fep->mii_bus = mdiobus_alloc();
> Do you need to round up to an even value? Is the hardware
> documentation wrong?
The round up is something existed, and the patch does not touch that
part.
> Does this need a quirk? What boards has this been verified to fix?
>
I tested this on i.mx28, i.mx53 and i.mx6q. Do you see problem on
your platform?
--
Regards,
Shawn
^ permalink raw reply
* Re: pull request: wireless-next 2011-09-19
From: John W. Linville @ 2011-09-20 3:19 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev
In-Reply-To: <20110919.171124.1877822329573878893.davem@davemloft.net>
On Mon, Sep 19, 2011 at 05:11:24PM -0400, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Mon, 19 Sep 2011 16:36:39 -0400
>
> > Here is another big batch of updates intended for 3.2 -- still
> > clearing-out the backlog...
> >
> > This round includes lots of updates to ath9k, b43, iwlagn, and rt2x00.
> > Some cleanups go to mac80211, along with a number of mesh-mode fixes
> > from Javier.
> >
> > Please let me know if there are problems!
>
> What about the iwl build failure reported by Eric Dumazet?
>
> If that's not handled here, I want that fixed before we add even
> more regressions :-)
It's there. :-)
commit ff620849110649b5f94989ddfd7a72b2bd43bd42
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Tue Sep 6 09:31:25 2011 -0700
iwlagn: fix compilation when debug flags is unset
Trivial fixes to allow compilation without warnings when debug
compilation flag isn't set.
Also fix the compilation when debugfs flag isn't set.
Fix a warning: unused priv pointer on the way.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Greetings
From: Lee Shing @ 2011-09-20 3:58 UTC (permalink / raw)
Greetings,
I am Mr. Lee Shing, Principal Assurance manager for the Nanyang Commercial Bank of China. An investment was placed under my management eight years ago by a customer who is now deceased. I need your
assistance in investing these funds. If you're interested contact me via my private email lshing1515@yahoo.com.hk
If you're not interested in my offer do not respond to this email.Awaiting your urgent reply.
Thanks and my regards,
Lee Shing
^ permalink raw reply
* Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by default
From: Eric Dumazet @ 2011-09-20 4:16 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Tim Chen, David Miller, zheng.z.yan, yanzheng, netdev, sfr,
jirislaby, sedat.dilek, alex.shi
In-Reply-To: <6030.1316484637@turing-police.cc.vt.edu>
Le lundi 19 septembre 2011 à 22:10 -0400, Valdis.Kletnieks@vt.edu a
écrit :
> On Mon, 19 Sep 2011 14:39:58 PDT, Tim Chen said:
> > Do we have to worry about the case where peer socket changes its flag
> > to SOCK_PASSCRED while packets are in flight? If there isn't such
> > pathological use case, the patch looks fine to me.
>
> I wouldn't think so - if you're sending a packet, and retroactively trying to
> change the flag and expect it to work, your program is too ugly to live. After
> all, if the scheduler had cut off your timeslice and scheduledthe receiving
> process before you set the flag, that packet would be delivered and done with
> anyhow, and no amount of wishing will set that flag on an already-delivered
> packet.
>
> What *is* worth checking is that we DTRT if a process/thread is doing a send on
> one CPU, and another process/thread with a shared file descriptor for that
> socket is diddling the flag. But if we just define it as "atomic op to change
> the flag and other observers get whatever value their CPU sees at that
> instant", I'm OK with that too.. ;)
>
Note : The man page does states :
"To receive a struct ucred message the SO_PASSCRED option must be
enabled on the socket."
But it doesnt say if the SO_PASSCRED option must be enabled before the
sender sends its message, or before receiver attempts to read it.
Once a message is queued on an unix socket, flipping SO_PASSCRED cant
change its content (adding or removing credentials), since sender might
already have disappeared.
So current code includes credentials in all sent messages, just in case
receiver actually fetch credentials.
There are probably programs that assume they can set SO_PASSCRED right
before calling recvmsg(). Are we taking risk to break them, or are we
gentle and provide a sysctl option to ease the transition, I dont
know...
^ 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