* [PATCH net-next] net : optimize skb_release_data()
From: Eric Dumazet @ 2014-09-24 1:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Cache skb_shinfo(skb) in a variable to avoid computing it multiple
times.
Reorganize the tests to remove one indentation level.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/skbuff.c | 43 ++++++++++++++++++++++---------------------
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 06a8feb10099..d4fdc649112c 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -491,32 +491,33 @@ static void skb_free_head(struct sk_buff *skb)
static void skb_release_data(struct sk_buff *skb)
{
- if (!skb->cloned ||
- !atomic_sub_return(skb->nohdr ? (1 << SKB_DATAREF_SHIFT) + 1 : 1,
- &skb_shinfo(skb)->dataref)) {
- if (skb_shinfo(skb)->nr_frags) {
- int i;
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
- skb_frag_unref(skb, i);
- }
+ struct skb_shared_info *shinfo = skb_shinfo(skb);
+ int i;
- /*
- * If skb buf is from userspace, we need to notify the caller
- * the lower device DMA has done;
- */
- if (skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY) {
- struct ubuf_info *uarg;
+ if (skb->cloned &&
+ atomic_sub_return(skb->nohdr ? (1 << SKB_DATAREF_SHIFT) + 1 : 1,
+ &shinfo->dataref))
+ return;
- uarg = skb_shinfo(skb)->destructor_arg;
- if (uarg->callback)
- uarg->callback(uarg, true);
- }
+ for (i = 0; i < shinfo->nr_frags; i++)
+ __skb_frag_unref(&shinfo->frags[i]);
- if (skb_has_frag_list(skb))
- skb_drop_fraglist(skb);
+ /*
+ * If skb buf is from userspace, we need to notify the caller
+ * the lower device DMA has done;
+ */
+ if (shinfo->tx_flags & SKBTX_DEV_ZEROCOPY) {
+ struct ubuf_info *uarg;
- skb_free_head(skb);
+ uarg = shinfo->destructor_arg;
+ if (uarg->callback)
+ uarg->callback(uarg, true);
}
+
+ if (shinfo->frag_list)
+ kfree_skb_list(shinfo->frag_list);
+
+ skb_free_head(skb);
}
/*
^ permalink raw reply related
* Re: linux-next: build warning after merge of the net tree
From: Stephen Rothwell @ 2014-09-24 0:36 UTC (permalink / raw)
To: Michal Marek
Cc: Randy Dunlap, David Miller, netdev, linux-next, linux-kernel,
linux-kbuild, Linus
In-Reply-To: <20140924072306.799005a3@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 3034 bytes --]
Hi all,
On Wed, 24 Sep 2014 07:23:06 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 23 Sep 2014 16:59:59 +0200 Michal Marek <mmarek@suse.cz> wrote:
> >
> > On 2014-09-18 02:35, Randy Dunlap wrote:
> > > On 09/17/14 17:32, Stephen Rothwell wrote:
> > >> Hi all,
> > >>
> > >> After merging the net tree, today's linux-next build (powerpc
> > >> ppc64_defconfig) produced these warnings:
> > >>
> > >> warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> > >>
> > >
> > > I have looked into these and don't see why there is a problem.
> > > Any help would be appreciated.
> >
> > This is a side effect of 5d6be6a5 ("scsi_netlink : Make SCSI_NETLINK
> > dependent on NET instead of selecting NET"). Previously, SCSI_FC_ATTRS
> > would select SCSI_NETLINK which would select CONFIG_NET. The above
> > warnings are just a tip of the iceberg, the more serious issue is that
> > ppc64_defconfig is lacking networking support. This is the downside of
> > savedefconfig, because the 'select' implications can disappear over
> > time. Looks like more defconfigs are affected by this:
>
> And since 5d6be6a5 is now in Linus' tree, we need Michal's 5 patches
> (at least) to be sent to Linus ASAP ...
I have put those 5 patches in my fixes tree for today ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v4 2/2] bonding: Simplify the xmit function for modes that use xmit_hash
From: Mahesh Bandewar @ 2014-09-24 0:14 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David Miller,
netdev, Eric Dumazet, Maciej Zenczykowski
In-Reply-To: <54212F51.4080707@redhat.com>
On Tue, Sep 23, 2014 at 1:29 AM, Nikolay Aleksandrov <nikolay@redhat.com> wrote:
> On 23/09/14 07:13, Mahesh Bandewar wrote:
>>
>> On Sun, Sep 21, 2014 at 4:07 AM, Nikolay Aleksandrov <nikolay@redhat.com>
>> wrote:
>>>
>>> On 09/20/2014 10:04 PM, Mahesh Bandewar wrote:
>>>>
>>>> On Sat, Sep 20, 2014 at 3:19 AM, Nikolay Aleksandrov
>>>> <nikolay@redhat.com> wrote:
>>>>>
>>>>> On 09/20/2014 02:09 AM, Mahesh Bandewar wrote:
>>>>>>
>>>>>> On Fri, Sep 19, 2014 at 4:06 AM, Nikolay Aleksandrov
>>>>>> <nikolay@redhat.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 09/19/2014 12:00 PM, Nikolay Aleksandrov wrote:
>>>>>>>>
>>>>>>>> On 09/18/2014 11:53 PM, Mahesh Bandewar wrote:
>>>>>>>>>
>>>>>>>>> Earlier change to use usable slave array for TLB mode had an
>>>>>>>>> additional
>>>>>>>>> performance advantage. So extending the same logic to all other
>>>>>>>>> modes
>>>>>>>>> that use xmit-hash for slave selection (viz 802.3AD, and XOR
>>>>>>>>> modes).
>>>>>>>>> Also consolidating this with the earlier TLB change.
>>>>>>>>>
>>>>>>>>> The main idea is to build the usable slaves array in the control
>>>>>>>>> path
>>>>>>>>> and use that array for slave selection during xmit operation.
>>>>>>>>>
>>>>>>>>> Measured performance in a setup with a bond of 4x1G NICs with 200
>>>>>>>>> instances of netperf for the modes involved (3ad, xor, tlb)
>>>>>>>>> cmd: netperf -t TCP_RR -H <TargetHost> -l 60 -s 5
>>>>>>>>>
>>>>>>>>> Mode TPS-Before TPS-After
>>>>>>>>>
>>>>>>>>> 802.3ad : 468,694 493,101
>>>>>>>>> TLB (lb=0): 392,583 392,965
>>>>>>>>> XOR : 475,696 484,517
>>>>>>>>>
>>>>>>>>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>>>>>>>>> ---
>>>>>>>>> v1:
>>>>>>>>> (a) If bond_update_slave_arr() fails to allocate memory, it will
>>>>>>>>> overwrite
>>>>>>>>> the slave that need to be removed.
>>>>>>>>> (b) Freeing of array will assign NULL (to handle bond->down to
>>>>>>>>> bond->up
>>>>>>>>> transition gracefully.
>>>>>>>>> (c) Change from pr_debug() to pr_err() if
>>>>>>>>> bond_update_slave_arr() returns
>>>>>>>>> failure.
>>>>>>>>> (d) XOR: bond_update_slave_arr() will consider mii-mon, arp-mon
>>>>>>>>> cases and
>>>>>>>>> will populate the array even if these parameters are not
>>>>>>>>> used.
>>>>>>>>> (e) 3AD: Should handle the ad_agg_selection_logic correctly.
>>>>>>>>> v2:
>>>>>>>>> (a) Removed rcu_read_{un}lock() calls from array manipulation
>>>>>>>>> code.
>>>>>>>>> (b) Slave link-events now refresh array for all these modes.
>>>>>>>>> (c) Moved free-array call from bond_close() to bond_uninit().
>>>>>>>>> v3:
>>>>>>>>> (a) Fixed null pointer dereference.
>>>>>>>>> (b) Removed bond->lock lockdep dependency.
>>>>>>>>> v4:
>>>>>>>>> (a) Made to changes to comply with Nikolay's locking changes
>>>>>>>>> (b) Added a work-queue to refresh slave-array when RTNL is not
>>>>>>>>> held
>>>>>>>>> (c) Array refresh happens ONLY with RTNL now.
>>>>>>>>> (d) alloc changed from GFP_ATOMIC to GFP_KERNEL
>>>>>>>>>
>>>>>>> <<<snip>>>
>>>>>>>>>
>>>>>>>>> @@ -3839,6 +4003,7 @@ static void bond_uninit(struct net_device
>>>>>>>>> *bond_dev)
>>>>>>>>> struct bonding *bond = netdev_priv(bond_dev);
>>>>>>>>> struct list_head *iter;
>>>>>>>>> struct slave *slave;
>>>>>>>>> + struct bond_up_slave *arr;
>>>>>>>>>
>>>>>>>>> bond_netpoll_cleanup(bond_dev);
>>>>>>>>>
>>>>>>>>> @@ -3847,6 +4012,12 @@ static void bond_uninit(struct net_device
>>>>>>>>> *bond_dev)
>>>>>>>>> __bond_release_one(bond_dev, slave->dev, true);
>>>>>>>>> netdev_info(bond_dev, "Released all slaves\n");
>>>>>>>>>
>>>>>>> Sorry but I just spotted a major problem, bond_3ad_unbind_slave()
>>>>>>> (called
>>>>>>> from __bond_release_one) calls ad_agg_selection_logic() which can
>>>>>>> re-arm
>>>>>>> the slave_arr work after it's supposed to be stopped here (i.e. the
>>>>>>> bond
>>>>>>> device has been closed so all works should've been stopped) so we
>>>>>>> might
>>>>>>> leak memory and access freed memory after all since it'll keep
>>>>>>> re-scheduling itself until it can acquire rtnl which is after the
>>>>>>> bond
>>>>>>> device has been destroyed.
>>>>>>>
>>>>>> This should not be a problem. ndo_close (bond_close()) is called
>>>>>> before ndo_uninit(bond_uninit()), so the work-queues get cancelled
>>>>>> there so if rearm tries to schedule some work after queue gets
>>>>>> cancelled, it can't do much and wont harm anything.
>>>>>> Hence there wont be any arrays built once it's free-ed completely and
>>>>>> therefore no memory leak. I addded some instrumentation and tried
>>>>>> following sequence -
>>>>>>
>>>>>> # modprobe bonding mode=4
>>>>>> # ip link set bond0 up
>>>>>> # [Add ip]
>>>>>> # [Add default route]
>>>>>> # ifenslave bond0 eth0 eth1 eth2 eth3
>>>>>> ....
>>>>>> [Run some backgound traffic. I used netperf.]
>>>>>>
>>>>>> # ip link bond0 down
>>>>>>
>>>>>> I did not see anything "bad" happening. Did your trial produced
>>>>>> something unpleasant?
>>>>>>
>>>>> The test you've done is irrelevant to the situation that I described
>>>>> because ndo_uninit() is called when the device is being destroyed.
>>>>> Moreover
>>>>> the case I told you about would require to have an active aggregator
>>>>> and an
>>>>> inactive one (i.e. so agg selection logic will get called), here is the
>>>>> result:
>>>>> [ 428.916586] bond1 (unregistering): Removing an active aggregator
>>>>> [ 428.916589] Failed to build slave-array.
>>>>> [ 428.916849] bond1 (unregistering): Releasing active interface eth1
>>>>> [ 428.920342] bond1 (unregistering): Released all slaves
>>>>> [ 428.923043] Failed to update slave array from WT
>>>>> [ 428.924098] Failed to update slave array from WT
>>>>> [ 428.925125] Failed to update slave array from WT
>>>>> [ 428.926120] Failed to update slave array from WT
>>>>> [ 428.927096] Failed to update slave array from WT
>>>>> [ 428.928101] Failed to update slave array from WT
>>>>> [ 428.929120] Failed to update slave array from WT
>>>>> [ 428.930086] BUG: unable to handle kernel NULL pointer dereference at
>>>>> (null)
>>>>> [ 428.930644] IP: [<ffffffff810aa37b>] __queue_work+0x7b/0x350
>>>>> [ 428.930946] PGD 0
>>>>> [ 428.931053] Oops: 0000 [#1] SMP
>>>>> [ 428.931053] Modules linked in: sfc ptp pps_core mdio i2c_algo_bit
>>>>> mtd
>>>>> bonding(O) snd_hda_codec_generic joydev crct10dif_pclmul crc32_pclmul
>>>>> i2c_piix4 ppdev crc32c_intel ghash_clmulni_intel parport_pc
>>>>> snd_hda_intel
>>>>> snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer
>>>>> 9pnet_virtio
>>>>> snd 9pnet pcspkr parport i2ccore serio_raw virtio_console
>>>>> virtio_balloon
>>>>> pvpanic soundcore virtio_blk virtio_net ata_generic floppy pata_acpi
>>>>> virtio_pci virtio_ring virtio
>>>>> [ 428.935022] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O
>>>>> 3.17.0-rc4+ #30
>>>>> [ 428.935022] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
>>>>> [ 428.935022] task: ffffffff81c1b460 ti: ffffffff81c00000 task.ti:
>>>>> ffffffff81c00000
>>>>> [ 428.935022] RIP: 0010:[<ffffffff810aa37b>] [<ffffffff810aa37b>]
>>>>> __queue_work+0x7b/0x350
>>>>> [ 428.935022] RSP: 0018:ffff88005f003e28 EFLAGS: 00010086
>>>>> [ 428.935022] RAX: ffff88005c05c800 RBX: 0000000000000000 RCX:
>>>>> 0000000000000000
>>>>> [ 428.935022] RDX: 0000000000000000 RSI: 0000000000000006 RDI:
>>>>> ffff88005a4fbd58
>>>>> [ 428.935022] RBP: ffff88005f003e60 R08: 0000000000000046 R09:
>>>>> ffffffff8225abc2
>>>>> [ 428.935022] R10: 0000000000000004 R11: 0000000000000005 R12:
>>>>> ffff88005a4fbd58
>>>>> [ 428.935022] R13: 0000000000000008 R14: ffff88004b211800 R15:
>>>>> 00000000000102f0
>>>>> [ 428.935022] FS: 0000000000000000(0000) GS:ffff88005f000000(0000)
>>>>> knlGS:0000000000000000
>>>>> [ 428.935022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>> [ 428.935022] CR2: 0000000000000000 CR3: 000000004abde000 CR4:
>>>>> 00000000000406f0
>>>>> [ 428.935022] Stack:
>>>>> [ 428.935022] 0a19522f72b12222 0000000081c1b460 ffffffff8225abc0
>>>>> ffff88005a4fbd78
>>>>> [ 428.935022] 0000000000000101 ffffffff810aa650 ffff88005a4fbd58
>>>>> ffff88005f003e70
>>>>> [ 428.935022] ffffffff810aa668 ffff88005f003ea8 ffffffff810f3536
>>>>> ffffffff8225abc0
>>>>> [ 428.935022] Call Trace:
>>>>> [ 428.935022] <IRQ>
>>>>> [ 428.935022]
>>>>> [ 428.935022] [<ffffffff810aa650>] ? __queue_work+0x350/0x350
>>>>> [ 428.935022] [<ffffffff810aa668>] delayed_work_timer_fn+0x18/0x20
>>>>> [ 428.935022] [<ffffffff810f3536>] call_timer_fn+0x36/0x120
>>>>> [ 428.935022] [<ffffffff810aa650>] ? __queue_work+0x350/0x350
>>>>> [ 428.935022] [<ffffffff810f38f5>] run_timer_softirq+0x1a5/0x320
>>>>> [ 428.935022] [<ffffffff81096dc5>] __do_softirq+0xf5/0x2b0
>>>>> [ 428.935022] [<ffffffff810971fd>] irq_exit+0xbd/0xd0
>>>>> [ 428.935022] [<ffffffff8173b715>] smp_apic_timer_interrupt+0x45/0x60
>>>>> [ 428.935022] [<ffffffff8173981d>] apic_timer_interrupt+0x6d/0x80
>>>>> [ 428.935022] <EOI>
>>>>> [ 428.935022]
>>>>> [ 428.935022] [<ffffffff810581c6>] ? native_safe_halt+0x6/0x10
>>>>> [ 428.935022] [<ffffffff8101f36f>] default_idle+0x1f/0xe0
>>>>> [ 428.935022] [<ffffffff8101fd8f>] arch_cpu_idle+0xf/0x20
>>>>> [ 428.935022] [<ffffffff810d25dd>] cpu_startup_entry+0x38d/0x3c0
>>>>> [ 428.935022] [<ffffffff81722927>] rest_init+0x87/0x90
>>>>> [ 428.935022] [<ffffffff81d3510e>] start_kernel+0x482/0x4a3
>>>>> [ 428.935022] [<ffffffff81d34a85>] ? set_init_arg+0x53/0x53
>>>>> [ 428.935022] [<ffffffff81d34120>] ? early_idt_handlers+0x120/0x120
>>>>> [ 428.935022] [<ffffffff81d345ee>]
>>>>> x86_64_start_reservations+0x2a/0x2c
>>>>> [ 428.935022] [<ffffffff81d3473d>] x86_64_start_kernel+0x14d/0x170
>>>>> [ 428.935022] Code: 84 bb 01 00 00 a8 02 0f 85 eb 00 00 00 48 63 45 d4
>>>>> 49
>>>>> 8b 9e 08 01 00 00 48 03 1c c5 60 fa d0 81 4c 89 e7 e8 18 f5 ff ff 48 85
>>>>> c0
>>>>> <48> 8b 3b 0f 84 7c 01 00 00 48 39 c7 0f 84 73 01 00 00 48 89 c7
>>>>> [ 428.935022] RIP [<ffffffff810aa37b>] __queue_work+0x7b/0x350
>>>>> [ 428.935022] RSP <ffff88005f003e28>
>>>>> [ 428.935022] CR2: 0000000000000000
>>>>>
>>>>> This is because it keeps trying to re-schedule even though the
>>>>> interface's
>>>>> memory has been freed.
>>>>>
>>>> Hmm, how do we handle this?
>>>>
>>> This is tricky and what concerns me more is that people might make this
>>> mistake again in the future. It's easy to unknowingly make use of a
>>> function that re-schedules this from the wrong place.
>>> What I just noticed is that for all 3ad cases you could pull the
>>> scheduling
>>> in the bond_3ad_state_machine_handler() function.
>>> The call sites of ad_agg_selection_logic() are:
>>> - 3ad unbind slave (no need to schedule here as __bond_release_one would
>>> rebuild the array anyhow)
>>> - bond_3ad_state_machine_handler() <- here's where the schedule should
>>> happen as this gets stopped first when the bond is closed and can't get
>>> restarted unless it's opened again.
>>> - ad_port_selection_logic() <- this is called from
>>> bond_3ad_state_machine_handler() only, so this case will be handled as
>>> well.
>>>
>>> The other 2 functions that you convert - ad_enable/disable_collecting are
>>> used only from ad_mux_machine() which is only called in
>>> bond_3ad_state_machine_handler().
>>>
>>> So basically you can pull all rebuild schedules in their common caller -
>>> bond_3ad_state_machine_handler(), just make a flag to note that a rebuild
>>> is needed probably something similar to should_notify_rtnl.
>>> This way you can remove the scheduling from the various 3ad functions
>>> that
>>> may get used and will have it only in 1 place which is more easily
>>> controlled.
>>>
>> Well, I was just trying to avoid using flags to pass state from one to
>> another function so that we can update the array at one place. This
>> might introduce some bug so I was keeping it simple and build it only
>> when the condition requires it to build it. However I do not see how
>> this will fix the issue that you have seen, or would it? If so how?
>>
> You don't have to pass state between functions, you just have to collect the
> return values from them in the single caller and see if scheduling an update
> is required in the end. Obviously I haven't tested this fix, but the
> reasoning behind it goes like this:
> The usual device destruction goes like: 1. ndo_close() 2. ndo_uninit()... So
> when bond_close() is executed the 3ad workqueue will get stopped first, and
> then the slave_update workqueue will get stopped (note - the order is
> important, since the only place where the slave_update workqueue gets
> scheduled to run is from the 3ad workqueue function). So when we reach
> bond_uninit() there's no way for the 3ad workqueue function to run and we're
> 100% sure that the slave_update workqueue has been canceled as well.
> The reason for this is because the 3ad workqueue function is started in
> bond_open() which obviously can't run without rtnl held, which is why the
> other workqueue functions also are stopped in the same manner.
> So basically, the idea is that you have only 1 place from which you can
> schedule the slave_update array and we can guarantee that it cannot get
> called once the bond device has been closed (bond_close()). You must not do
> a slave array update schedule in bond_3ad_unbind_slave, but that is okay
> because the slave array will get updated by __bond_release_one() anyhow.
>
I try doing this in 3ad_state_machine().
>>> Of course, the alternative would be once again - convert
>>> bond_3ad_state_machine_handler() to RTNL, but that has its own set of
>>> problems.
>>>
>> It's convoluted, let's keep it simple for now :)
>>
>>>>> While testing this I spotted another issue as well - Failed to build
>>>>> slave_arr message has been printed too many times because you print it
>>>>> in
>>>>> 3ad mode when there's no active aggregator
>>>>> (bond_3ad_get_active_agg_info
>>>>> check in bond_update_slave_arr) which leads to re-scheduling which also
>>>>> lead to a deadlock.
>>>>>
>>>> I think this can be corrected with pr_ratelimited() call.
>>>>
>>> IMO it shouldn't print anything if it couldn't rebuild the array due to
>>> missing active aggregator as that's not an error condition. It should
>>> though probably clean out the slave array because transmission shouldn't
>>> be
>>> possible without an active aggregator in 3ad.
>>>
>> Sure missing active aggregator is not an error but free-ing the slave
>> array silently would be bad either. At least we would see something in
>> the messages about "something" went wrong.
>
> Nothing has went wrong, not having an active aggregator is a normal state
> that can happen and in fact could be the state while the bond device is
> configured. It is not advisable to spit out errors in such case as there has
> been no error condition to begin with. Dealing with failed active aggregator
> and notifying the user of it and so on is the job of the 3ad code, not of
> the slave_update mechanism.
> One more thing you really should make sure that we don't xmit when there's
> no active aggregator, it doesn't make sense otherwise and it is actually the
> current behaviour (check bond_3ad_xmit_xor(), first thing it does is try to
> obtain active aggregator and if it fails - it drops the packet, the error
> condition there has been marked as netdev_dbg() so it can be enabled only
> per request of the user and isn't printed normally).
> Moreover it's really a bad idea to reschedule the slave array rebuilding if
> there's no active aggregator because it may be the case we don't have it for
> a long time and it will cause constant rtnl acquire/release cycles.
>
alright. I'll update the code to make sure that active agg not being
present does not trigger error. However malloc failure is still an
error.
>>>
>>>
>>>
>
^ permalink raw reply
* Re: [PATCH] net/openvswitch: remove dup comment in vport.h
From: Pravin Shelar @ 2014-09-23 21:44 UTC (permalink / raw)
To: Wang Sheng-Hui; +Cc: David Miller, dev@openvswitch.org, netdev
In-Reply-To: <1411473735-15184-1-git-send-email-shhuiw@gmail.com>
On Tue, Sep 23, 2014 at 5:02 AM, Wang Sheng-Hui <shhuiw@gmail.com> wrote:
> Remove the duplicated comment
> "/* The following definitions are for users of the vport subsytem: */"
> in vport.h
>
> Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Thanks.
> ---
> net/openvswitch/vport.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/openvswitch/vport.h b/net/openvswitch/vport.h
> index 35f89d8..5b43010 100644
> --- a/net/openvswitch/vport.h
> +++ b/net/openvswitch/vport.h
> @@ -35,7 +35,6 @@ struct vport_parms;
>
> /* The following definitions are for users of the vport subsytem: */
>
> -/* The following definitions are for users of the vport subsytem: */
> struct vport_net {
> struct vport __rcu *gre_vport;
> };
> --
> 1.8.4.5
>
^ permalink raw reply
* Re: [PATCH v2] net/netfilter/x_tables.c: use __seq_open_private()
From: Pablo Neira Ayuso @ 2014-09-23 21:40 UTC (permalink / raw)
To: Ben Hutchings
Cc: Rob Jones, davem, coreteam, netdev, linux-kernel, linux-kernel,
netfilter, netfilter-devel
In-Reply-To: <1411494387.32579.138.camel@xylophone>
On Tue, Sep 23, 2014 at 06:46:27PM +0100, Ben Hutchings wrote:
> On Tue, 2014-09-23 at 18:05 +0100, Rob Jones wrote:
> > Reduce boilerplate code by using __seq_open_private() instead of seq_open()
> > in xt_match_open() and xt_target_open().
> >
> > Signed-off-by: Rob Jones <rob.jones@codethink.co.uk>
> > ---
> >
> > This patch uses an existing variant of seq_open() to reduce the kernel code
> > size.
> >
> > The only significant variation from the pre-existing code is the fact that
> > __seq_open_private() calls kzalloc() rather than kmalloc(), which could
> > conceivably have an impact on timing.
> >
> > This version 2 incorporates a minor initialisation simplification (resulting
> > from kzalloc() being used) requested by netfilter-devel@vger.kernel.org
> [...]
> > --- a/net/netfilter/x_tables.c
> > +++ b/net/netfilter/x_tables.c
> > @@ -1080,7 +1080,6 @@ static void *xt_mttg_seq_start(struct seq_file *seq, loff_t *pos,
> > struct nf_mttg_trav *trav = seq->private;
> > unsigned int j;
> >
> > - trav->class = MTTG_TRAV_INIT;
> > for (j = 0; j < *pos; ++j)
> > if (xt_mttg_seq_next(seq, NULL, NULL, is_target) == NULL)
> > return NULL;
> [...]
>
> I'm fairly sure this simplification is wrong, as xt_mttg_seq_start() is
> potentially called multiple times on the same file handle.
Right. I'm going to take v1 of this patch instead, sorry for the
inconvenience Rob.
^ permalink raw reply
* [PATCH net-next] sparc: bpf_jit: add support for BPF_LD(X) | BPF_LEN instructions
From: Alexei Starovoitov @ 2014-09-23 21:36 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
BPF_LD | BPF_W | BPF_LEN instruction is occasionally used by tcpdump
and present in 11 tests in lib/test_bpf.c
Teach sparc JIT compiler to emit it.
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
coupled with pending net fix test_bpf still comes out clean on sparc64.
compile tested only on sparc32
Though both patches touch the same file, there should be no conflicts
between net and net-next.
arch/sparc/net/bpf_jit_comp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/sparc/net/bpf_jit_comp.c b/arch/sparc/net/bpf_jit_comp.c
index 7c06f18150ab..86bad49d6604 100644
--- a/arch/sparc/net/bpf_jit_comp.c
+++ b/arch/sparc/net/bpf_jit_comp.c
@@ -624,7 +624,12 @@ void bpf_jit_compile(struct bpf_prog *fp)
emit_and(r_A, r_TMP, r_A);
}
break;
-
+ case BPF_LD | BPF_W | BPF_LEN:
+ emit_skb_load32(len, r_A);
+ break;
+ case BPF_LDX | BPF_W | BPF_LEN:
+ emit_skb_load32(len, r_X);
+ break;
case BPF_LD | BPF_IMM:
emit_loadimm(K, r_A);
break;
--
1.7.9.5
^ permalink raw reply related
* Re: linux-next: build warning after merge of the net tree
From: Stephen Rothwell @ 2014-09-23 21:23 UTC (permalink / raw)
To: Michal Marek
Cc: Randy Dunlap, David Miller, netdev, linux-next, linux-kernel,
linux-kbuild, Linus
In-Reply-To: <54218AEF.5090200@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 3334 bytes --]
Hi all,
On Tue, 23 Sep 2014 16:59:59 +0200 Michal Marek <mmarek@suse.cz> wrote:
>
> On 2014-09-18 02:35, Randy Dunlap wrote:
> > On 09/17/14 17:32, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> After merging the net tree, today's linux-next build (powerpc
> >> ppc64_defconfig) produced these warnings:
> >>
> >> warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> >> warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> >> warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> >> warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> >> warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> >> warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> >> warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> >> warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
> >>
> >
> > I have looked into these and don't see why there is a problem.
> > Any help would be appreciated.
>
> This is a side effect of 5d6be6a5 ("scsi_netlink : Make SCSI_NETLINK
> dependent on NET instead of selecting NET"). Previously, SCSI_FC_ATTRS
> would select SCSI_NETLINK which would select CONFIG_NET. The above
> warnings are just a tip of the iceberg, the more serious issue is that
> ppc64_defconfig is lacking networking support. This is the downside of
> savedefconfig, because the 'select' implications can disappear over
> time. Looks like more defconfigs are affected by this:
And since 5d6be6a5 is now in Linus' tree, we need Michal's 5 patches
(at least) to be sent to Linus ASAP ...
So it appears that using select can get us into the same sort of
trouble that not including all needed header files can. Unfortunately,
savedconfig makes that much worse :-(. So anyone changing a "select X"
to "depends on X" needs to regenerate a lot of defconfigs to make sure
that there are no unforeseen consequences.
Dave, this is a bit slack of you since I reported that problem a week
ago in the net tree and yet it has not been completely fixed before you
asked Linus to pull your tree :-(
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] et131x: Promote staging et131x driver to drivers/net
From: Joe Perches @ 2014-09-23 21:07 UTC (permalink / raw)
To: Mark Einon; +Cc: devel, angus, gregkh, linux-kernel, netdev, davem
In-Reply-To: <1411502723-4628-1-git-send-email-mark.einon@gmail.com>
On Tue, 2014-09-23 at 21:05 +0100, Mark Einon wrote:
> This patch moves the et131x gigabit ethernet driver from drivers/staging
> to drivers/net/ethernet/agere.
checkpatch type modification you might consider:
Reduce logging line count by consolidating repeated dev_warn
Use ether_addr_copy
Line wrapping for 80 columns
Remove unnecessary parentheses
Remove unnecessary OOM message
---
drivers/staging/et131x/et131x.c | 51 ++++++++++++++++-------------------------
1 file changed, 20 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index eefa9f1..3aaedc9 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -1294,9 +1294,8 @@ static int et131x_phy_mii_read(struct et131x_adapter *adapter, u8 addr,
/* If we hit the max delay, we could not read the register */
if (delay == 50) {
dev_warn(&adapter->pdev->dev,
- "reg 0x%08x could not be read\n", reg);
- dev_warn(&adapter->pdev->dev, "status is 0x%08x\n",
- mii_indicator);
+ "reg 0x%08x could not be read - status is 0x%08x\n",
+ reg, mii_indicator);
status = -EIO;
goto out;
@@ -1371,11 +1370,8 @@ static int et131x_mii_write(struct et131x_adapter *adapter, u8 addr, u8 reg,
u16 tmp;
dev_warn(&adapter->pdev->dev,
- "reg 0x%08x could not be written", reg);
- dev_warn(&adapter->pdev->dev, "status is 0x%08x\n",
- mii_indicator);
- dev_warn(&adapter->pdev->dev, "command is 0x%08x\n",
- readl(&mac->mii_mgmt_cmd));
+ "reg 0x%08x could not be written - status is 0x%08x - command is 0x%08x\n",
+ reg, mii_indicator, readl(&mac->mii_mgmt_cmd));
et131x_mii_read(adapter, reg, &tmp);
@@ -2444,10 +2440,8 @@ static struct rfd *nic_rx_pkts(struct et131x_adapter *adapter)
rfd->len = len;
skb = dev_alloc_skb(rfd->len + 2);
- if (!skb) {
- dev_err(&adapter->pdev->dev, "Couldn't alloc an SKB for Rx\n");
+ if (!skb)
return NULL;
- }
adapter->netdev->stats.rx_bytes += rfd->len;
@@ -2661,7 +2655,7 @@ static int nic_send_packet(struct et131x_adapter *adapter, struct tcb *tcb)
desc[frag].len_vlan = skb_headlen(skb) / 2;
dma_addr = dma_map_single(&adapter->pdev->dev,
skb->data,
- (skb_headlen(skb) / 2),
+ skb_headlen(skb) / 2,
DMA_TO_DEVICE);
desc[frag].addr_lo = lower_32_bits(dma_addr);
desc[frag].addr_hi = upper_32_bits(dma_addr);
@@ -2670,8 +2664,8 @@ static int nic_send_packet(struct et131x_adapter *adapter, struct tcb *tcb)
desc[frag].len_vlan = skb_headlen(skb) / 2;
dma_addr = dma_map_single(&adapter->pdev->dev,
skb->data +
- (skb_headlen(skb) / 2),
- (skb_headlen(skb) / 2),
+ skb_headlen(skb) / 2,
+ skb_headlen(skb) / 2,
DMA_TO_DEVICE);
desc[frag].addr_lo = lower_32_bits(dma_addr);
desc[frag].addr_hi = upper_32_bits(dma_addr);
@@ -3212,15 +3206,13 @@ static void et131x_hwaddr_init(struct et131x_adapter *adapter)
* working with so we need to copy the current
* address into the permanent address
*/
- memcpy(adapter->rom_addr,
- adapter->addr, ETH_ALEN);
+ ether_addr_copy(adapter->rom_addr, adapter->addr);
} else {
/* We do not have an override address, so set the
* current address to the permanent address and add
* it to the device
*/
- memcpy(adapter->addr,
- adapter->rom_addr, ETH_ALEN);
+ ether_addr_copy(adapter->addr, adapter->rom_addr);
}
}
@@ -3415,7 +3407,8 @@ static void et131x_adjust_link(struct net_device *netdev)
et131x_mii_read(adapter, PHY_MPHY_CONTROL_REG,
®ister18);
et131x_mii_write(adapter, phydev->addr,
- PHY_MPHY_CONTROL_REG, register18 | 0x4);
+ PHY_MPHY_CONTROL_REG,
+ register18 | 0x4);
et131x_mii_write(adapter, phydev->addr, PHY_INDEX_REG,
register18 | 0x8402);
et131x_mii_write(adapter, phydev->addr, PHY_DATA_REG,
@@ -3448,7 +3441,8 @@ static void et131x_adjust_link(struct net_device *netdev)
et131x_mii_read(adapter, PHY_MPHY_CONTROL_REG,
®ister18);
et131x_mii_write(adapter, phydev->addr,
- PHY_MPHY_CONTROL_REG, register18 | 0x4);
+ PHY_MPHY_CONTROL_REG,
+ register18 | 0x4);
et131x_mii_write(adapter, phydev->addr,
PHY_INDEX_REG, register18 | 0x8402);
et131x_mii_write(adapter, phydev->addr,
@@ -3778,8 +3772,7 @@ static irqreturn_t et131x_isr(int irq, void *dev_id)
*/
/* TRAP();*/
- dev_warn(&adapter->pdev->dev,
- "RxDMA_ERR interrupt, error %x\n",
+ dev_warn(&adapter->pdev->dev, "RxDMA_ERR interrupt, error %x\n",
readl(&iomem->txmac.tx_test));
}
@@ -3805,8 +3798,7 @@ static irqreturn_t et131x_isr(int irq, void *dev_id)
* occur. In a nutshell, the whole Tx path will have to be reset
* and re-configured afterwards.
*/
- dev_warn(&adapter->pdev->dev,
- "TXMAC interrupt, error 0x%08x\n",
+ dev_warn(&adapter->pdev->dev, "TXMAC interrupt, error 0x%08x\n",
err);
/* If we are debugging, we want to see this error, otherwise we
@@ -3823,11 +3815,8 @@ static irqreturn_t et131x_isr(int irq, void *dev_id)
/* MP_SET_FLAG( adapter, FMP_ADAPTER_HARDWARE_ERROR); */
dev_warn(&adapter->pdev->dev,
- "RXMAC interrupt, error 0x%08x. Requesting reset\n",
+ "RXMAC interrupt, error 0x%08x - requesting reset - Enable 0x%08x, Diag 0x%08x\n",
readl(&iomem->rxmac.err_reg));
-
- dev_warn(&adapter->pdev->dev,
- "Enable 0x%08x, Diag 0x%08x\n",
readl(&iomem->rxmac.ctrl),
readl(&iomem->rxmac.rxq_diag));
@@ -4081,7 +4070,7 @@ static void et131x_multicast(struct net_device *netdev)
netdev_for_each_mc_addr(ha, netdev) {
if (i == NIC_MAX_MCAST_LIST)
break;
- memcpy(adapter->multicast_list[i++], ha->addr, ETH_ALEN);
+ ether_addr_copy(adapter->multicast_list[i++], ha->addr);
}
adapter->multicast_addr_count = i;
@@ -4211,7 +4200,7 @@ static int et131x_change_mtu(struct net_device *netdev, int new_mtu)
et131x_init_send(adapter);
et131x_hwaddr_init(adapter);
- memcpy(netdev->dev_addr, adapter->addr, ETH_ALEN);
+ ether_addr_copy(netdev->dev_addr, adapter->addr);
/* Init the device with the new settings */
et131x_adapter_setup(adapter);
@@ -4329,7 +4318,7 @@ static int et131x_pci_setup(struct pci_dev *pdev,
netif_napi_add(netdev, &adapter->napi, et131x_poll, 64);
/* Copy address into the net_device struct */
- memcpy(netdev->dev_addr, adapter->addr, ETH_ALEN);
+ ether_addr_copy(netdev->dev_addr, adapter->addr);
rc = -ENOMEM;
^ permalink raw reply related
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Tom Herbert @ 2014-09-23 20:57 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Thomas Graf, Jiri Pirko, John Fastabend, Jamal Hadi Salim,
netdev@vger.kernel.org, David S. Miller, Neil Horman,
Andy Gospodarek, Daniel Borkmann, Or Gerlitz, Jesse Gross,
Pravin Shelar, Andy Zhou, Ben Hutchings, Stephen Hemminger,
Jeff Kirsher, Vladislav Yasevich, Cong Wang, Eric Dumazet,
Scott Feldman, Florian Fainelli, Roopa Prabhu,
John Linville <linvi
In-Reply-To: <CAADnVQ+=vKEjzUTcEW+yzA4bTL4TKabrzzk=gb=OyfuVGwOyPA@mail.gmail.com>
> SKB_GSO_UDP_TUNNEL_CSUM was the right way
> to start splitting overloaded and messy semantics of
> UDP_TUNNEL. I'm still not sure whether you've intended
> it for both rx and tx, since to support tunnel_csum on rx,
> parsing of encap is needed, whereas tx is so much simpler.
> Unless you're assuming checksum_complete model for rx...
>
>> If properly implemented, HW can implement a whole bunch of
>> UDP encap protocols without knowing how to parse them.
>
> on a tx side... yes, but I cannot see how you can do rx
> with inner csum verify without parsing encap.
> What do you have in mind ?
>
Implement checksum-complete. It does not require a device to parse the
encap, is usable with probably all encapsulation formats being
discussed, and easily supports multiple checksums in a packet. This
will even work with something like L2TP where a device can't do
stateless parsing (pseudo wire encapsulation).
Of the five basic NIC offloads (RX-csum, TX-csum, TSO, LRO, and RSS),
LRO is the one that probably cannot be generalized so that NICs don't
need to parse specific encapsulation protocols. Fortunately, GRO
performance is now very comparable anyway so I tend to think LRO
support is not crucial (the same argument might be made for GSO/TSO I
suppose, but TSO we can mostly generalize). HW support for checksum
offloads and RSS are definitely still very relevant!
>> I don't see how
>> a switch on the NIC helps this...
>
> correct, just a switch on a nic isn't very useful.
>
> If immediate consumer of the packet is a VM,
> then doing switching in the nic after decap doesn't
> add much speed, since bridge+router+nat+policy in sw
> after decap and csum verify done by hw are fast enough.
> But switching in HW becomes useful when VF
> is a destination device, since it avoids hw->sw->hw
> roundtrip as Thomas was saying.
>
> Also there are x86 network gateways where tunneled
> traffic from virtual network is terminated and sent
> over internet or to other datacenter. Performance
> demands are high, so if tunnel+switch+nat+policy
> can be done in off-the-shelf HW it would be great.
>
>>> And this is just tx offload. On rx smart tunnel offload in HW parses
>>> encap and goes all the way to inner headers to verify checksums,
>>> it also steers based on inner headers.
>>> Try mellanox nics with and without vxlan offload to see
>>> the difference.
>>
>> Turn on UDP RSS on the device and I bet you'll see those differences
>> go away!
>
> Logically it should, since all inner flows should get
> hashed into different outer src_port, but somehow
> that didn't work. Need to re-investigate with your
> l4_hash stuff.
>
You may need to enable RSS for UDP. Like "ethtool -N eth0 rx-flow-hash
udp4 sdfn"
>> Alexei, I believe you said previously said that SW should not dictate
>> HW models. I agree with this, but also believe the converse is true--
>> HW shouldn't dictate SW model.
>
> completely agree!
>
>> This is really why I'm raising the
>> question of what it means to integrate a switch into the host stack.
>> If this is something that doesn't require any model change to the
>> stack and is just a clever backend for rx-filters or tc, then I'm fine
>> with that!
>
> agree as well. I'm not excited about switchdev
> abstraction from this given patch, since it looks overly
> simplified and not applicable to real silicon, but
> discussion about exposing programmable
> nics/switches to sw in a generic way is worth having :)
^ permalink raw reply
* [PATCH net] sparc: bpf_jit: fix loads from negative offsets
From: Alexei Starovoitov @ 2014-09-23 20:50 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
- fix BPF_LD|ABS|IND from negative offsets:
make sure to sign extend lower 32 bits in 64-bit register
before calling C helpers from JITed code, otherwise 'int k'
argument of bpf_internal_load_pointer_neg_helper() function
will be added as large unsigned integer, causing packet size
check to trigger and abort the program.
It's worth noting that JITed code for 'A = A op K' will affect
upper 32 bits differently depending whether K is simm13 or not.
Since small constants are sign extended, whereas large constants
are stored in temp register and zero extended.
That is ok and we don't have to pay a penalty of sign extension
for every sethi, since all classic BPF instructions have 32-bit
semantics and we only need to set correct upper bits when
transitioning from JITed code into C.
- though instructions 'A &= 0' and 'A *= 0' are odd, JIT compiler
should not optimize them out
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
More detailed explanation of 1st bug:
BPF_STMT(BPF_LD | BPF_B | BPF_ABS, SKF_LL_OFF)
will be JITed as:
sethi %hi(0xffe00000), %g3
or %g3, 0, %g3
call bpf_jit_load_byte_negative_offset
which will do:
mov %g3, %o1
call bpf_internal_load_pointer_neg_helper
mov 1, %o2
void *bpf_internal_load_pointer_neg_helper(const struct sk_buff *skb, int k, unsigned int size)
{
...
ptr = skb_mac_header(skb) + k - SKF_LL_OFF;
here 'k' will be added as 0xffe00000 instead of SKF_LL_OFF == -0x200000
After these fixes, test_bpf is now clean on sparc64.
Compile tested only on sparc32
arch/sparc/net/bpf_jit_asm.S | 3 +++
arch/sparc/net/bpf_jit_comp.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/sparc/net/bpf_jit_asm.S b/arch/sparc/net/bpf_jit_asm.S
index 9d016c7..8c83f4b 100644
--- a/arch/sparc/net/bpf_jit_asm.S
+++ b/arch/sparc/net/bpf_jit_asm.S
@@ -6,10 +6,12 @@
#define SAVE_SZ 176
#define SCRATCH_OFF STACK_BIAS + 128
#define BE_PTR(label) be,pn %xcc, label
+#define SIGN_EXTEND(reg) sra reg, 0, reg
#else
#define SAVE_SZ 96
#define SCRATCH_OFF 72
#define BE_PTR(label) be label
+#define SIGN_EXTEND(reg)
#endif
#define SKF_MAX_NEG_OFF (-0x200000) /* SKF_LL_OFF from filter.h */
@@ -135,6 +137,7 @@ bpf_slow_path_byte_msh:
save %sp, -SAVE_SZ, %sp; \
mov %i0, %o0; \
mov r_OFF, %o1; \
+ SIGN_EXTEND(%o1); \
call bpf_internal_load_pointer_neg_helper; \
mov (LEN), %o2; \
mov %o0, r_TMP; \
diff --git a/arch/sparc/net/bpf_jit_comp.c b/arch/sparc/net/bpf_jit_comp.c
index 51ae87b..ece4af0 100644
--- a/arch/sparc/net/bpf_jit_comp.c
+++ b/arch/sparc/net/bpf_jit_comp.c
@@ -184,7 +184,7 @@ do { \
*/
#define emit_alu_K(OPCODE, K) \
do { \
- if (K) { \
+ if (K || OPCODE == AND || OPCODE == MUL) { \
unsigned int _insn = OPCODE; \
_insn |= RS1(r_A) | RD(r_A); \
if (is_simm13(K)) { \
--
1.7.9.5
^ permalink raw reply related
* Re: /proc/net/sockstat invalid memory accounting or memory leak in latest kernels?
From: Semen Slepov @ 2014-09-23 20:14 UTC (permalink / raw)
To: netdev
In-Reply-To: <1405672897.10255.95.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet <eric.dumazet <at> gmail.com> writes:
>
>
> tcp believes its under pressure because of some bug on accounting.
>
> If you change /proc/sys/net/ipv4/tcp_mem (3rd value), it might say it
> is not under pressure.
>
> I am taking a look, thanks again for the report.
>
>
Still have this accounting bug on 3.15.7 . Is there fix in further kernel
releases (or patch)?
^ permalink raw reply
* Re: [RFC PATCH linux-next] et131x: Promote staging et131x driver to drivers/net
From: Francois Romieu @ 2014-09-23 20:07 UTC (permalink / raw)
To: Joe Perches; +Cc: devel, netdev, linux-kernel, gregkh, Mark Einon, davem
In-Reply-To: <1411499875.29268.7.camel@joe-AO725>
Joe Perches <joe@perches.com> :
> On Tue, 2014-09-23 at 21:02 +0200, Francois Romieu wrote:
[...]
> > How about kernel tinification ?
>
> The tiny case where a large number of ethernet drivers are included?
No.
A couple of bytes here and there vs a cosmetic kernel wide change.
--
Ueimor
^ permalink raw reply
* [PATCH v2] et131x: Promote staging et131x driver to drivers/net
From: Mark Einon @ 2014-09-23 20:05 UTC (permalink / raw)
To: gregkh, davem; +Cc: devel, angus, netdev, linux-kernel, joe, Mark Einon
In-Reply-To: <1411421283-25073-1-git-send-email-mark.einon@gmail.com>
This patch moves the et131x gigabit ethernet driver from drivers/staging
to drivers/net/ethernet/agere.
Signed-off-by: Mark Einon <mark.einon@gmail.com>
---
Changes from v1:
-modified MAINTAINERS in scope with changes
-Fixed typo in Kconfig, Atheros -> Agere
-Made review changes from Tobias Klauser, see patchset
http://marc.info/?l=linux-driver-devel&m=141150128909523&w=2
-v2 patch formatted with '-M' git-format-patch flag
** Patch applies and tested on linux-next tag next-20140923, on top of the 8
patches at http://marc.info/?l=linux-driver-devel&m=141141591110262&w=2 and the
four patches linked above. Posting in such a messy way in order to hopefully
solicit enough feedback before the upcoming merge window **
MAINTAINERS | 10 +++----
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/agere/Kconfig | 31 ++++++++++++++++++++++
.../et131x => net/ethernet/agere}/Makefile | 0
.../et131x => net/ethernet/agere}/et131x.c | 0
.../et131x => net/ethernet/agere}/et131x.h | 0
drivers/staging/Kconfig | 2 --
drivers/staging/Makefile | 1 -
drivers/staging/et131x/Kconfig | 10 -------
drivers/staging/et131x/README | 15 -----------
11 files changed, 38 insertions(+), 33 deletions(-)
create mode 100644 drivers/net/ethernet/agere/Kconfig
rename drivers/{staging/et131x => net/ethernet/agere}/Makefile (100%)
rename drivers/{staging/et131x => net/ethernet/agere}/et131x.c (100%)
rename drivers/{staging/et131x => net/ethernet/agere}/et131x.h (100%)
delete mode 100644 drivers/staging/et131x/Kconfig
delete mode 100644 drivers/staging/et131x/README
diff --git a/MAINTAINERS b/MAINTAINERS
index 637112c..26b5238 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3572,6 +3572,11 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git
F: drivers/video/fbdev/s1d13xxxfb.c
F: include/video/s1d13xxxfb.h
+ET131X NETWORK DRIVER
+M: Mark Einon <mark.einon@gmail.com>
+S: Odd Fixes
+F: drivers/net/ethernet/agere/
+
ETHERNET BRIDGE
M: Stephen Hemminger <stephen@networkplumber.org>
L: bridge@lists.linux-foundation.org
@@ -8764,11 +8769,6 @@ M: H Hartley Sweeten <hsweeten@visionengravers.com>
S: Odd Fixes
F: drivers/staging/comedi/
-STAGING - ET131X NETWORK DRIVER
-M: Mark Einon <mark.einon@gmail.com>
-S: Odd Fixes
-F: drivers/staging/et131x/
-
STAGING - FLARION FT1000 DRIVERS
M: Marek Belisko <marek.belisko@gmail.com>
S: Odd Fixes
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index dc7406c..d48fc9c 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -20,6 +20,7 @@ config SUNGEM_PHY
source "drivers/net/ethernet/3com/Kconfig"
source "drivers/net/ethernet/adaptec/Kconfig"
source "drivers/net/ethernet/aeroflex/Kconfig"
+source "drivers/net/ethernet/agere/Kconfig"
source "drivers/net/ethernet/allwinner/Kconfig"
source "drivers/net/ethernet/alteon/Kconfig"
source "drivers/net/ethernet/altera/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 224a018..89207ac 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_NET_VENDOR_3COM) += 3com/
obj-$(CONFIG_NET_VENDOR_8390) += 8390/
obj-$(CONFIG_NET_VENDOR_ADAPTEC) += adaptec/
obj-$(CONFIG_GRETH) += aeroflex/
+obj-$(CONFIG_NET_VENDOR_AGERE) += agere/
obj-$(CONFIG_NET_VENDOR_ALLWINNER) += allwinner/
obj-$(CONFIG_NET_VENDOR_ALTEON) += alteon/
obj-$(CONFIG_ALTERA_TSE) += altera/
diff --git a/drivers/net/ethernet/agere/Kconfig b/drivers/net/ethernet/agere/Kconfig
new file mode 100644
index 0000000..63e805d
--- /dev/null
+++ b/drivers/net/ethernet/agere/Kconfig
@@ -0,0 +1,31 @@
+#
+# Agere device configuration
+#
+
+config NET_VENDOR_AGERE
+ bool "Agere devices"
+ default y
+ depends on PCI
+ ---help---
+ If you have a network (Ethernet) card belonging to this class, say Y
+ and read the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about Agere devices. If you say Y, you will be asked
+ for your specific card in the following questions.
+
+if NET_VENDOR_AGERE
+
+config ET131X
+ tristate "Agere ET-1310 Gigabit Ethernet support"
+ depends on PCI
+ select PHYLIB
+ ---help---
+ This driver supports Agere ET-1310 ethernet adapters.
+
+ To compile this driver as a module, choose M here. The module
+ will be called et131x.
+
+endif # NET_VENDOR_AGERE
diff --git a/drivers/staging/et131x/Makefile b/drivers/net/ethernet/agere/Makefile
similarity index 100%
rename from drivers/staging/et131x/Makefile
rename to drivers/net/ethernet/agere/Makefile
diff --git a/drivers/staging/et131x/et131x.c b/drivers/net/ethernet/agere/et131x.c
similarity index 100%
rename from drivers/staging/et131x/et131x.c
rename to drivers/net/ethernet/agere/et131x.c
diff --git a/drivers/staging/et131x/et131x.h b/drivers/net/ethernet/agere/et131x.h
similarity index 100%
rename from drivers/staging/et131x/et131x.h
rename to drivers/net/ethernet/agere/et131x.h
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 6e2d6fd..9d18a1c 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -24,8 +24,6 @@ menuconfig STAGING
if STAGING
-source "drivers/staging/et131x/Kconfig"
-
source "drivers/staging/slicoss/Kconfig"
source "drivers/staging/wlan-ng/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 74c679e..8c56326 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -4,7 +4,6 @@
obj-$(CONFIG_STAGING) += staging.o
obj-y += media/
-obj-$(CONFIG_ET131X) += et131x/
obj-$(CONFIG_SLICOSS) += slicoss/
obj-$(CONFIG_PRISM2_USB) += wlan-ng/
obj-$(CONFIG_COMEDI) += comedi/
diff --git a/drivers/staging/et131x/Kconfig b/drivers/staging/et131x/Kconfig
deleted file mode 100644
index 8190f2a..0000000
--- a/drivers/staging/et131x/Kconfig
+++ /dev/null
@@ -1,10 +0,0 @@
-config ET131X
- tristate "Agere ET-1310 Gigabit Ethernet support"
- depends on PCI && NET && NETDEVICES
- select PHYLIB
- default n
- ---help---
- This driver supports Agere ET-1310 ethernet adapters.
-
- To compile this driver as a module, choose M here. The module
- will be called et131x.
diff --git a/drivers/staging/et131x/README b/drivers/staging/et131x/README
deleted file mode 100644
index 13c8168..0000000
--- a/drivers/staging/et131x/README
+++ /dev/null
@@ -1,15 +0,0 @@
-This is a driver for the ET1310 network device.
-
-Based on the driver found at https://sourceforge.net/projects/et131x/
-
-Cleaned up immensely by Olaf Hartman and Christoph Hellwig <hch@infradead.org>
-
-Note, the powermanagement options were removed from the vendor provided
-driver as they did not build properly at the time.
-
-TODO:
-
-Please send patches to:
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Mark Einon <mark.einon@gmail.com>
-
--
2.1.0
^ permalink raw reply related
* [PATCH 4/4] staging: et131x: Remove unnecessary defines to enable driver PM
From: Mark Einon @ 2014-09-23 19:41 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, linux-kernel, Mark Einon
In-Reply-To: <1411501274-2970-1-git-send-email-mark.einon@gmail.com>
The Power Management functions can be conditional by assigning pm ops
directly to .driver.pm, instead of using #ifdef's, saving some lines of
code.
Reported-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Mark Einon <mark.einon@gmail.com>
---
drivers/staging/et131x/et131x.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index 10f20b3..41fcaa0 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -3607,12 +3607,9 @@ static int et131x_resume(struct device *dev)
return 0;
}
+#endif
static SIMPLE_DEV_PM_OPS(et131x_pm_ops, et131x_suspend, et131x_resume);
-#define ET131X_PM_OPS (&et131x_pm_ops)
-#else
-#define ET131X_PM_OPS NULL
-#endif
/* et131x_isr - The Interrupt Service Routine for the driver.
* @irq: the IRQ on which the interrupt was received.
@@ -4406,7 +4403,7 @@ static struct pci_driver et131x_driver = {
.id_table = et131x_pci_table,
.probe = et131x_pci_setup,
.remove = et131x_pci_remove,
- .driver.pm = ET131X_PM_OPS,
+ .driver.pm = &et131x_pm_ops,
};
module_pci_driver(et131x_driver);
--
2.1.0
^ permalink raw reply related
* [PATCH 3/4] staging: et131x: Add space after { in pci ID table
From: Mark Einon @ 2014-09-23 19:41 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, linux-kernel, Mark Einon
In-Reply-To: <1411501274-2970-1-git-send-email-mark.einon@gmail.com>
Signed-off-by: Mark Einon <mark.einon@gmail.com>
---
drivers/staging/et131x/et131x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index 6539a8a..10f20b3 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -4397,7 +4397,7 @@ err_disable:
static const struct pci_device_id et131x_pci_table[] = {
{ PCI_VDEVICE(ATT, ET131X_PCI_DEVICE_ID_GIG), 0UL},
{ PCI_VDEVICE(ATT, ET131X_PCI_DEVICE_ID_FAST), 0UL},
- {0,}
+ { 0,}
};
MODULE_DEVICE_TABLE(pci, et131x_pci_table);
--
2.1.0
^ permalink raw reply related
* [PATCH 2/4] staging: et131x: don't cast a void* to a struct pointer
From: Mark Einon @ 2014-09-23 19:41 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, linux-kernel, Mark Einon
In-Reply-To: <1411501274-2970-1-git-send-email-mark.einon@gmail.com>
Casting a void* popinter to a struct pointer is unnecessary, don't do
it.
Signed-off-by: Mark Einon <mark.einon@gmail.com>
---
drivers/staging/et131x/et131x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index 2889f86..6539a8a 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -3624,7 +3624,7 @@ static irqreturn_t et131x_isr(int irq, void *dev_id)
{
bool handled = true;
bool enable_interrupts = true;
- struct net_device *netdev = (struct net_device *)dev_id;
+ struct net_device *netdev = dev_id;
struct et131x_adapter *adapter = netdev_priv(netdev);
struct address_map __iomem *iomem = adapter->regs;
struct rx_ring *rx_ring = &adapter->rx_ring;
--
2.1.0
^ permalink raw reply related
* [PATCH 1/4] staging: et131x: zero allocation of fbr to prevent random address access
From: Mark Einon @ 2014-09-23 19:41 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, linux-kernel, Mark Einon
In-Reply-To: <20140923100106.GE4657@distanz.ch>
If et131x_rx_dma_memory_alloc() allocates rx_ring->fbr[0] but fails to
allocate rx_ring->fbr[1], this leaves fbr[0]->ring_virtaddr with the
possibility of being accessed in et131x_rx_dma_memory_free() as it
contains a random value, potentially causing an oops.
Fix this by zeroing the fbr memory on allocation. Subsequent frees of
this fbr memory explicitly zeros the ring_virtaddr value.
Reported-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Mark Einon <mark.einon@gmail.com>
---
drivers/staging/et131x/et131x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index 93afd61..2889f86 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -2003,10 +2003,10 @@ static int et131x_rx_dma_memory_alloc(struct et131x_adapter *adapter)
struct fbr_lookup *fbr;
/* Alloc memory for the lookup table */
- rx_ring->fbr[0] = kmalloc(sizeof(*fbr), GFP_KERNEL);
+ rx_ring->fbr[0] = kzalloc(sizeof(*fbr), GFP_KERNEL);
if (rx_ring->fbr[0] == NULL)
return -ENOMEM;
- rx_ring->fbr[1] = kmalloc(sizeof(*fbr), GFP_KERNEL);
+ rx_ring->fbr[1] = kzalloc(sizeof(*fbr), GFP_KERNEL);
if (rx_ring->fbr[1] == NULL)
return -ENOMEM;
--
2.1.0
^ permalink raw reply related
* Re: [net-next] vxlan: Fix bug introduced by commit acbf74a76300
From: David Miller @ 2014-09-23 19:33 UTC (permalink / raw)
To: azhou; +Cc: netdev, eric.dumazet
In-Reply-To: <1411461891-4442-1-git-send-email-azhou@nicira.com>
From: Andy Zhou <azhou@nicira.com>
Date: Tue, 23 Sep 2014 01:44:51 -0700
> Commit acbf74a76300 ("vxlan: Refactor vxlan driver to make use of the common UDP tunnel functions." introduced a bug in vxlan_xmit_one()
> function, causing it to transmit Vxlan packets without proper
> Vxlan header inserted. The change was not needed in the first
> place. Revert it.
>
> Reported-by: Tom Herbert <therbert@google.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Andy Zhou <azhou@nicira.com>
Applied, thanks Andy.
^ permalink raw reply
* Re: [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns
From: Andy Lutomirski @ 2014-09-23 19:26 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: Network Development, Linux Containers,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stephen Hemminger, Eric W. Biederman, Linux API, Andrew Morton,
David S. Miller
In-Reply-To: <1411478430-4989-1-git-send-email-nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
On Tue, Sep 23, 2014 at 6:20 AM, Nicolas Dichtel
<nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> wrote:
> The goal of this serie is to be able to multicast netlink messages with an
> attribute that identify a peer netns.
> This is needed by the userland to interpret some informations contained in
> netlink messages (like IFLA_LINK value, but also some other attributes in case
> of x-netns netdevice (see also
> http://thread.gmane.org/gmane.linux.network/315933/focus=316064 and
> http://thread.gmane.org/gmane.linux.kernel.containers/28301/focus=4239)).
>
> Ids are stored in the parent user namespace. These ids are valid only inside
> this user namespace. The user can retrieve these ids via a new netlink messages,
> but only if peer netns are in the same user namespace.
What about the parent / ancestors of the owning userns? Can processes
in those usernses see any form of netns id?
--Andy
^ permalink raw reply
* Re: ip6_udp_tunnel fails to load
From: Eyal perry @ 2014-09-23 19:25 UTC (permalink / raw)
To: Tom Herbert
Cc: Eric Dumazet, Andy Zhou, Linux Netdev List, Or Gerlitz,
Amir Vadai
In-Reply-To: <CA+mtBx9kf7Jj38tF4AxGktDboAMt3uNurdU-99vKAro=gP2Zbw@mail.gmail.com>
On 9/23/2014 7:55 PM, Tom Herbert wrote:
> On Tue, Sep 23, 2014 at 9:33 AM, Eyal perry <eyalpe@dev.mellanox.co.il> wrote:
>> On 9/23/2014 6:39 PM, Eric Dumazet wrote:
>>> On Tue, 2014-09-23 at 18:21 +0300, Eyal perry wrote:
>>>> Hello Andy,
>>>>
>>>> Lately I've start to observe a phenomena where the mlx4_en driver
>>>> couldn't load on my system as a result of an 'Unknown symbol in module'.
>>>>
>>>> [ 1277.458715] ip6_udp_tunnel: Unknown symbol ip6_local_out (err 0)
>>>> [ 1277.486810] ip6_udp_tunnel: Unknown symbol __put_net (err 0)
>>>>
>>>> Apparently, the mlx4_en driver is depend on the vxlan driver, which
>>>> depends on the ip6_udp_tunnel module which fails to load.
>>>>
>>>> 1. I've bisected this issue down to the following commit:
>>>> fd38441 udp_tunnel: Seperate ipv6 functions into its own file.
>>>>
>>>> 2. on a different host with a different .config, the module is loads
>>>> cleanly.
>>>>
>>>> 3. my sources are based on net-next commit
>>>> 6d967f8 udp_tunnel: Only build ip6_udp_tunnel.c when IPV6 is selected
>>>>
>>>> I'll send you both of the .config files in a private message.
>>>>
>>>> This issue is making any driver which is depend on vxlan/ip6_udp_tunnel
>>>> unusable, please take a look and fix
>>>
>>> Have you tried this patch ?
>>>
>>> https://patchwork.ozlabs.org/patch/392275/
>>>
>>> Thanks
>>
> Try https://patchwork.ozlabs.org/patch/392109/
>
> Tom
>
>> Hello Eric,
>>
>> Now I've tried but it still fails - the vxlan is still depends on the
>> ip6_udp_tunnel and it still fails to load because of the missing symbols
>> mentioned above.
>>
>>
>>
>>
>> --
>> 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
Thanks Tom, that solves my problem, though I can verify at the moment
that vxlan is well functioning.
^ permalink raw reply
* Re: [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns
From: Cong Wang @ 2014-09-23 19:22 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: netdev, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA, David Miller, Eric W. Biederman,
Stephen Hemminger, Andrew Morton, Andy Lutomirski
In-Reply-To: <1411478430-4989-1-git-send-email-nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
On Tue, Sep 23, 2014 at 6:20 AM, Nicolas Dichtel
<nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> wrote:
>
> Here is a small screenshot to show how it can be used by userland:
> $ ip netns add foo
> $ ip netns del foo
> $ ip netns
> $ touch /var/run/netns/init_net
> $ mount --bind /proc/1/ns/net /var/run/netns/init_net
> $ ip netns add foo
> $ ip netns
> foo (id: 3)
> init_net (id: 1)
> $ ip netns exec foo ip netns
> foo (id: 3)
> init_net (id: 1)
> $ ip netns exec foo ip link add ipip1 link-netnsid 1 type ipip remote 10.16.0.121 local 10.16.0.249
> $ ip netns exec foo ip l ls ipip1
> 6: ipip1@NONE: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default
> link/ipip 10.16.0.249 peer 10.16.0.121 link-netnsid 1
>
> The parameter link-netnsid shows us where the interface sends and receives
> packets (and thus we know where encapsulated addresses are set).
>
So ipip1 is shown in netns foo but functioning in netns init_net? Getting the
id of init_net in foo depends on your mount namespace, /var/run/netns/ may
not visible inside foo, in this case, link-netnsid is meaningless. It
is not your
fault, network namespace already heavily relies on mount namespace (sysfs
needs to be remount otherwise you can not create device with the same name.)
On the other hand, what's the problem you are trying to solve? AFAIK,
the ifindex
issue is purely in output, IOW, the device still functions correctly
even through
its link ifindex is not correct after moving to another namespace. If
not, it is bug
we need to fix.
^ permalink raw reply
* Re: [RFC PATCH linux-next] et131x: Promote staging et131x driver to drivers/net
From: Joe Perches @ 2014-09-23 19:17 UTC (permalink / raw)
To: Francois Romieu
Cc: Mark Einon, Tobias Klauser, gregkh, davem, devel, netdev,
linux-kernel
In-Reply-To: <20140923190242.GA8096@electric-eye.fr.zoreil.com>
On Tue, 2014-09-23 at 21:02 +0200, Francois Romieu wrote:
> Mark Einon <mark.einon@gmail.com> :
> [...]
> > > No need for the #define here, just assigne et131x_pm_ops to .driver.pm
> > > directly, its members will be NULL and thus never called. Also, you can
> > > make et131x_pm_ops const.
> >
> > Ok, I can change this.
> >
> > Btw, this appears to be a fairly standard way of using .driver.pm among
> > ethernet drivers, e.g. see 3com/3c59x.c, atheros, marvell... - perhaps
> > there is a case for changing all instances of this code?
>
> How about kernel tinification ?
The tiny case where a large number of ethernet drivers are included?
^ permalink raw reply
* Re: [RFC PATCH linux-next] et131x: Promote staging et131x driver to drivers/net
From: Francois Romieu @ 2014-09-23 19:02 UTC (permalink / raw)
To: Mark Einon; +Cc: Tobias Klauser, gregkh, davem, devel, netdev, linux-kernel
In-Reply-To: <20140923094614.GA5130@leicester.auvation.com>
Mark Einon <mark.einon@gmail.com> :
[...]
> > No need for the #define here, just assigne et131x_pm_ops to .driver.pm
> > directly, its members will be NULL and thus never called. Also, you can
> > make et131x_pm_ops const.
>
> Ok, I can change this.
>
> Btw, this appears to be a fairly standard way of using .driver.pm among
> ethernet drivers, e.g. see 3com/3c59x.c, atheros, marvell... - perhaps
> there is a case for changing all instances of this code?
How about kernel tinification ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next] udp: Need to make ip6_udp_tunnel.c have GPL license
From: Andy Zhou @ 2014-09-23 19:00 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx8EbRBxS2OF65cWjBHGMXhLkbmMjibOtRRBMTqWGmgD5g@mail.gmail.com>
Yes, it is a bug in the Vxlan transmit code. I have sent out a patch
a while ago. Would you please give it try?
https://patchwork.ozlabs.org/patch/392275/
Thanks for letting me know and the help to reproduce the bug off list.
Andy
On Mon, Sep 22, 2014 at 1:17 PM, Tom Herbert <therbert@google.com> wrote:
> Andy, even with the is patch I still can't get VXLAN to work again. I
> am assuming this is a problem related to the common UDP tunnel
> functions. I haven't had time to look into it in depth, can you verify
> if there is an issue.
>
> Thanks,
> Tom
>
>
> On Mon, Sep 22, 2014 at 12:08 PM, David Miller <davem@davemloft.net> wrote:
>> From: Tom Herbert <therbert@google.com>
>> Date: Mon, 22 Sep 2014 11:39:44 -0700
>>
>>> Unable to load various tunneling modules without this:
>>>
>>> [ 80.679049] fou: Unknown symbol udp_sock_create6 (err 0)
>>> [ 91.439939] ip6_udp_tunnel: Unknown symbol ip6_local_out (err 0)
>>> [ 91.439954] ip6_udp_tunnel: Unknown symbol __put_net (err 0)
>>> [ 91.457792] vxlan: Unknown symbol udp_sock_create6 (err 0)
>>> [ 91.457831] vxlan: Unknown symbol udp_tunnel6_xmit_skb (err 0)
>>>
>>> Signed-off-by: Tom Herbert <therbert@google.com>
>>
>> Applied, thanks Tom.
^ permalink raw reply
* Off Topic: Request for Old Hardware
From: tedheadster @ 2014-09-23 18:56 UTC (permalink / raw)
To: netdev
If you have an ancient dual-processor 80486 system, please email me
off-list. Yes, a few of these did indeed exist.
- Matt
^ 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