* Re: [RFC net-next 1/3] bonding: add infrastructure for an option API
From: Scott Feldman @ 2014-01-10 20:21 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: Netdev
In-Reply-To: <1389359495-9700-2-git-send-email-nikolay@redhat.com>
On Jan 10, 2014, at 5:11 AM, Nikolay Aleksandrov <nikolay@redhat.com> wrote:
> This patch adds the necessary basic infrastructure to support
> centralized and unified option manipulation API for the bonding. The new
> structure bond_option will be used to describe each option with its
> dependencies on modes which will be checked automatically thus removing a
> lot of duplicated code. Also automatic range checking is added for
> non-string options. Currently the option setting function requires RTNL to
> be acquired prior to calling it, since many options already rely on RTNL
> it seemed like the best choice to protect all against common race
> conditions.
>
> +/**
> + * bond_opt_parse - parse option value
> + * @tbl: an option's values[] table to parse against
> + * @bufarg: value to parse
> + * @retval: pointer where to store the parsed value
> + * @string: how to treat bufarg (as string or integer)
> + *
> + * This functions tries to extract the value from bufarg and check if it's
> + * a possible match for the option. It shouldn't be possible to have a non-NULL
> + * return with @retval being < 0.
> + */
> +struct bond_value_tbl *bond_opt_parse(const struct bond_option *opt,
> + void *bufarg, int *retval, bool string)
> +{
> + char *buf, *p, valstr[BOND_MAX_MODENAME_LEN + 1] = { 0, };
Did you mean to use BOND_MAX_MODENAME_LEN here? bond_options.h should have it’s own define max value string len, I think.
> + struct bond_value_tbl *tbl, *maxval = NULL, *ret = NULL;
> + int valint = -1, i, rv;
> +
> + tbl = opt->values;
> + if (!tbl)
> + goto out;
> +
> + if (string) {
> + buf = bufarg;
> + for (p = (char *)buf; *p; p++)
> + if (!(isdigit(*p) || isspace(*p)))
> + break;
I think we lost a comment here from old code explaining eating whitespace and trailing newline.
>
> +struct bond_value_tbl {
> + char *name;
> + int value;
What if want a u64 value?
> + u32 flags;
> +};
struct bond_value_tbl_entry ? Or just struct bond_value? tbl is a collection of these, so it’s weird to have tbl in name of item.
-scott
^ permalink raw reply
* Re: [PATCH net 2/2] be2net: Need a delay before processing CQE after 2nd mbox register write
From: David Miller @ 2014-01-10 20:11 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev, kalesh.purayil
In-Reply-To: <4b4fd4cb-9d23-4900-a20c-f2c2bef70849@CMEXHTCAS2.ad.emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Wed, 8 Jan 2014 14:52:02 +0530
> Due to Host platform synchronization issues between the mbox RDY bit polled
> status and the completion of the DMA for the CQE, it is preferable that the
> Host always wait for the RDY bit to transition to 1 after the 2nd mbox register
> write and always follow that with a short wait for the valid bit in the CQE,
> before processing the CQE.
>
> Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_cmds.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
> index 94c35c8..78560f2 100644
> --- a/drivers/net/ethernet/emulex/benet/be_cmds.c
> +++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
> @@ -502,6 +502,9 @@ static int be_mbox_notify_wait(struct be_adapter *adapter)
> if (status != 0)
> return status;
>
> + /* Need a delay before processing CQE after 2nd mbox register write */
> + udelay(1);
> +
Like others, I find his delay being used to fix the stated problem as questionable,
at best.
Either find a more appropriate way to fix this problem, or elaborate (in the commit
message), why this is really a suitable way to handle this.
^ permalink raw reply
* Layer 2 acceleration vs GSO
From: Ben Hutchings @ 2014-01-10 20:05 UTC (permalink / raw)
To: John Fastabend, David S. Miller; +Cc: Neil Horman, Andy Gospodarek, netdev
What happens when an skb to be sent through ndo_dfwd_start_xmit()
requires software GSO?
dev_hard_start_xmit() will segment it and then submit each segment, and
then:
> gso:
> do {
[...]
> if (accel_priv)
> rc = ops->ndo_dfwd_start_xmit(nskb, dev, accel_priv);
> else
> rc = ops->ndo_start_xmit(nskb, dev);
> trace_net_dev_xmit(nskb, rc, dev, skb_len);
[...]
> txq_trans_update(txq);
Oops, txq is NULL. And once we add the obvious condition to that,
> if (unlikely(netif_xmit_stopped(txq) && skb->next))
> return NETDEV_TX_BUSY;
How can we tell if the hardware transmit queue filled up?
It seems like this feature currently relies on the driver returning
NETDEV_TX_BUSY when the TX queue is already full, like ixgbe does. But
that is exactly what drivers are *not* supposed to do.
Ben.
> } while (skb->next);
--
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: [RFC net-next 2/3] bonding: convert mode setting to use the new option API
From: Scott Feldman @ 2014-01-10 20:04 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: Netdev
In-Reply-To: <1389359495-9700-3-git-send-email-nikolay@redhat.com>
On Jan 10, 2014, at 5:11 AM, Nikolay Aleksandrov <nikolay@redhat.com> wrote:
> This patch makes the bond's mode setting use the new option API and
> adds support for dependency printing which relies on having an entry for
> the mode option in the bond_opts[] array.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
> -int bond_option_mode_set(struct bonding *bond, int mode)
> +int bond_option_mode_set(struct bonding *bond, void *newval)
> {
> - if (bond_parm_tbl_lookup(mode, bond_mode_tbl) < 0) {
> - pr_err("%s: Ignoring invalid mode value %d.\n",
> - bond->dev->name, mode);
> - return -EINVAL;
> - }
> -
> - if (bond->dev->flags & IFF_UP) {
> - pr_err("%s: unable to update mode because interface is up.\n",
> - bond->dev->name);
> - return -EPERM;
> - }
> -
> - if (bond_has_slaves(bond)) {
> - pr_err("%s: unable to update mode because bond has slaves.\n",
> - bond->dev->name);
> - return -EPERM;
> - }
> + int mode = *(int *)newval;
> + struct bond_option *opt;
>
> if (BOND_NO_USES_ARP(mode) && bond->params.arp_interval) {
> + opt = bond_opt_get(BOND_OPT_MODE);
> pr_info("%s: %s mode is incompatible with arp monitoring, start mii monitoring\n",
> - bond->dev->name, bond_mode_tbl[mode].modename);
> + bond->dev->name, opt->values[mode].name);
Can this be a name accessor func? ^^^^^^^^^^^^^^^^^^^^^^
> static ssize_t bonding_store_mode(struct device *d,
> struct device_attribute *attr,
> const char *buf, size_t count)
> {
> - int new_value, ret;
> struct bonding *bond = to_bond(d);
> + int ret;
>
> - new_value = bond_parse_parm(buf, bond_mode_tbl);
> - if (new_value < 0) {
> - pr_err("%s: Ignoring invalid mode value %.*s.\n",
> - bond->dev->name, (int)strlen(buf) - 1, buf);
> - return -EINVAL;
> - }
> - if (!rtnl_trylock())
> + ret = bond_opt_tryset_rtnl(bond, BOND_OPT_MODE, (char *)buf);
> + if (ret == -EAGAIN)
> return restart_syscall();
I wonder if the restart_syscall() should be kept close to rtnl_trylock() in bond_opt_tryset_rtnl?
^ permalink raw reply
* Re: [RFC net-next 3/3] bonding: convert packets_per_slave to use the new option API
From: Scott Feldman @ 2014-01-10 20:04 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: Netdev
In-Reply-To: <1389359495-9700-4-git-send-email-nikolay@redhat.com>
On Jan 10, 2014, at 5:11 AM, Nikolay Aleksandrov <nikolay@redhat.com> wrote:
> This patch adds the necessary changes so packets_per_slave would use the
> new bonding option API.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
> ---
> + [BOND_OPT_PACKETS_PER_SLAVE] = {
> + .id = BOND_OPT_PACKETS_PER_SLAVE,
> + .name = "packets_per_slave",
> + .desc = "Packets to send per slave in RR mode",
> + .valtype = BOND_OPTVAL_INTEGER,
> + .unsuppmodes = BOND_MODE_ALL_EX(BIT(BOND_MODE_ROUNDROBIN)),
This .unsuppmodes would be hard to generalize as-is since it’s bond-specific.
(*set)() could have done the check also. Maybe there is a (*check)() func to do pre-screening of value before (*set) is called, but after general checks are made?
> + .values = bond_pps_tbl,
> + .set = bond_option_pps_set
> + },
> { }
> };
>
> @@ -982,28 +997,6 @@ int bond_option_lp_interval_set(struct bonding *bond, int lp_interval)
> return 0;
> }
>
> -int bond_option_packets_per_slave_set(struct bonding *bond,
> - int packets_per_slave)
> -{
> - if (packets_per_slave < 0 || packets_per_slave > USHRT_MAX) {
> - pr_err("%s: packets_per_slave must be between 0 and %u\n",
> - bond->dev->name, USHRT_MAX);
> - return -EINVAL;
> - }
> -
> - if (bond->params.mode != BOND_MODE_ROUNDROBIN)
> - pr_warn("%s: Warning: packets_per_slave has effect only in balance-rr mode\n",
> - bond->dev->name);
> -
> - if (packets_per_slave > 1)
> - bond->params.packets_per_slave =
> - reciprocal_value(packets_per_slave);
> - else
> - bond->params.packets_per_slave = packets_per_slave;
> -
> - return 0;
> -}
> -
Nice! Good bye rambling code.
^ permalink raw reply
* Re: [PATCH 08/23] netfilter: nft_ct: load both IPv4 and IPv6 conntrack modules for NFPROTO_INET
From: Patrick McHardy @ 2014-01-10 19:59 UTC (permalink / raw)
To: David Miller; +Cc: sergei.shtylyov, pablo, netfilter-devel, netdev
In-Reply-To: <20140110.144813.659408334812475090.davem@davemloft.net>
On Fri, Jan 10, 2014 at 02:48:13PM -0500, David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Fri, 10 Jan 2014 19:42:36 +0000
>
> > I can see you're looking out for the important stuff. I consistently
> > used this style in nftables so I'm not going to change it here.
>
> Patrick, please follow the coding style conventions of the kernel,
> these issues are important for long term sanity of the kernel tree.
>
> It helps people who are looking at the netfilter code who perhaps
> do not do so usually. Do you really want to use a different style
> and therefore make your code harder to read for them? Really?
>
> Your code being consistent with your code only is less important than
> all of the networking looking the same.
>
> Thank you.
I agree to this, in fact style divergences really bother me since they
divert my attention :) I considered consistency more important for minor
stuff like this, but I really don't mind to add extra braces.
But I guess we both agree that its not worth sending patches just to
change this but just fix this up next time that line is touched.
^ permalink raw reply
* PROBLEM: usbnet / ax88179_178a: Panic in usb_hcd_map_urb_for_dma
From: Thomas Kear @ 2014-01-10 19:56 UTC (permalink / raw)
To: netdev
USB3 gigabit ethernet adapters with the ASIX AX88179 chipset (LevelOne
USB0401-V3, Plugable USB3-E1000, SIIG JU-NE0211-S1 and others) are
experiencing kernel panics in usb_hcd_map_urb_for_dma since 3.12. The
issue does not seem to directly correlate with low or high network
activity, occurring seemingly at random. Some panics occurred less
than 5 minutes from boot and tens of megabytes of network transfer,
while on other occasions it would be stable for multiple days with
tens to hundreds of gigabytes of line-rate throughput and several
sleep/resume cycles.
Both my Sony Vaio Pro 13 and another user reporting this issue on the
Arch forums [1] are Intel-based, my USB controller is an 8086:9c31
(Lynx Point LP), the other is reported as a C210/7 series (unknown
PID). A third with a Haswell Dell XPS has attempted my workaround and
reports similar success.
I have a mediocre quality photo of my laptop's screen from one of
these panics [2], the call trace - which is similar but not identical
between my machine and that of the other user reporting the issue - is
as follows:
usb_hcd_map_urb_for_dma
usb_hcd_submit_urb
local_bh_enable_ip
selinux_parse_skb
usb_alloc_urb
__kmalloc
usbnet_start_xmit
usbnet_start_xmit
dev_hard_start_xmit
sch_direct_xmit
dev_queue_xmit
ip_finish_output2
ip_finish_output
ip_output
dst_output
ip_local_out
ip_queue_xmit
tcp_transmit_skb
tcp_write_xmit
__tcp_push_pending_frames
tcp_push
tcp_sendmsg
inet_sendmsg
__sock_sendmsg_nosec
sock_sendmsg
set_restore_sigmask
set_restore_sigmask
fget_light
SYSC_sendto
set_restore_sigmask
SyS_sendto
system_call_fastpath
So far as I can tell, the driver is unaffected as late as 3.11.6, but
problematic as of 3.12 (and still affected in 3.13-rc5). The history
of drivers/net/usb/ax88179_178a.c for this time period yields this
patch, which at least in my somewhat limited understanding appeared a
likely candidate. I've reverted this on my system - against several
linux-next builds from the last 3-4 weeks - and have had no issues
with this network controller since.
commit 3804fad45411b48233b48003e33a78f290d227c8
Author: Ming Lei <ming.lei@canonical.com>
Date: Thu Aug 8 21:48:25 2013 +0800
USBNET: ax88179_178a: enable tso if usb host supports sg dma
This patch enables 'can_dma_sg' flag for ax88179_178a device
if the attached host controller supports building packet from
discontinuous buffers(DMA SG is possible), so TSO can be enabled
and skb fragment buffers can be passed to usb stack via urb->sg
directly.
With the patch, system CPU utilization decreased ~50% and throughput
increased by ~10% when doing iperf client test on one ARM A15 dual
core board.
Cc: Ben Hutchings <bhutchings@solarflare.com>
Cc: Grant Grundler <grundler@google.com>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Freddy Xin <freddy@asix.com.tw>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Acked-by: Eric Dumazet <edumazet@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Unfortunately I have not retained the built kernel from a broken 3.12
build, so the system information below reflects the patched linux-next
kernel I am running currently.
I understand this may be a somewhat obscure piece of hardware, I am
willing to assist by drop-shipping one to someone from Amazon (or
local country equivalent if the price is not extortionate) should it
be required.
System information:
ver_linux:
Linux neko 3.13.0-rc5-next-20131224+ #1 SMP Sat Dec 28 19:09:27 NZDT
2013 x86_64 Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz GenuineIntel
GNU/Linux
Gnu C 4.7.3
Gnu make 4.0
binutils 2.24
util-linux scripts/ver_linux: line 23: fdformat: command not found
mount assert
module-init-tools 16
e2fsprogs 1.42.9
jfsutils 1.1.15
reiserfsprogs 3.6.24
reiser4progs 1.0.7
xfsprogs 3.1.11
quota-tools 4.01.
PPP 2.4.5
Linux C Library 2.17
Dynamic linker (ldd) 2.17
Procps 3.3.9
Net-tools 1.60_p20130513023548
Kbd 2.0.1
Sh-utils 8.22
Modules Loaded bonding rndis_host cdc_ether tun snd_usb_audio
snd_usbmidi_lib snd_rawmidi cdc_acm ctr ccm hidp nfsd rfcomm bnep
iptable_nat nf_nat_ipv4 nf_nat uvcvideo btusb bluetooth hid_multitouch
videobuf2_vmalloc videobuf2_memops videobuf2_core uinput ax88179_178a
usbnet mii rtsx_pci_sdmmc rtsx_pci mmc_core fuse snd_hda_codec_realtek
iwlmvm kvm_intel snd_hda_codec_generic mac80211 kvm pn544_mei mei_phy
iwlwifi pn544 snd_hda_intel hci nfc snd_hda_codec snd_hwdep cfg80211
xhci_hcd
/proc/cpuinfo:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 69
model name : Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz
stepping : 1
microcode : 0x10
cpu MHz : 2968.125
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq
dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1
sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand
lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi
flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms
invpcid
bogomips : 4788.92
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
PCI:
-[0000:00]-+-00.0 Intel Corporation Haswell-ULT DRAM Controller [8086:0a04]
+-02.0 Intel Corporation Haswell-ULT Integrated Graphics
Controller [8086:0a16]
+-03.0 Intel Corporation Device [8086:0a0c]
+-14.0 Intel Corporation Lynx Point-LP USB xHCI HC [8086:9c31]
+-16.0 Intel Corporation Lynx Point-LP HECI #0 [8086:9c3a]
+-1b.0 Intel Corporation Lynx Point-LP HD Audio Controller
[8086:9c20]
+-1c.0-[01]----00.0 Intel Corporation Wireless 7260 [8086:08b1]
+-1c.3-[02]--
+-1c.4-[03]----00.0 Samsung Electronics Co Ltd Device [144d:a800]
+-1d.0 Intel Corporation Lynx Point-LP USB EHCI #1 [8086:9c26]
+-1f.0 Intel Corporation Lynx Point-LP LPC Controller [8086:9c43]
\-1f.3 Intel Corporation Lynx Point-LP SMBus Controller [8086:9c22]
USB:
Bus 001 Device 002: ID 8087:8000 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 025: ID 0b95:1790 ASIX Electronics Corp.
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 027: ID 8087:07dc Intel Corp.
Bus 002 Device 003: ID 04f2:b3be Chicony Electronics Co., Ltd
Bus 002 Device 002: ID 0eef:a108 D-WAV Scientific Co., Ltd
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
/proc/modules:
bonding 84837 0 - Live 0xffffffffc00d5000
rndis_host 5162 0 - Live 0xffffffffc0096000
cdc_ether 4324 1 rndis_host, Live 0xffffffffc006e000
tun 16811 0 - Live 0xffffffffc009e000
snd_usb_audio 102474 0 - Live 0xffffffffc007b000
snd_usbmidi_lib 16542 1 snd_usb_audio, Live 0xffffffffc0072000
snd_rawmidi 15891 1 snd_usbmidi_lib, Live 0xffffffffc0017000
cdc_acm 16166 0 - Live 0xffffffffc05ec000
ctr 3471 2 - Live 0xffffffffc05e8000
ccm 6977 2 - Live 0xffffffffc05e3000
hidp 12989 0 - Live 0xffffffffc05db000
nfsd 192979 13 - Live 0xffffffffc059b000
rfcomm 27704 12 - Live 0xffffffffc058e000
bnep 9055 2 - Live 0xffffffffc0587000
iptable_nat 2550 0 - Live 0xffffffffc0583000
nf_nat_ipv4 3118 1 iptable_nat, Live 0xffffffffc057f000
nf_nat 9984 2 iptable_nat,nf_nat_ipv4, Live 0xffffffffc0577000
uvcvideo 60542 0 - Live 0xffffffffc0562000
btusb 14182 0 - Live 0xffffffffc0519000
bluetooth 200149 23 hidp,rfcomm,bnep,btusb, Live 0xffffffffc04d8000
hid_multitouch 8791 0 - Live 0xffffffffc04d1000
videobuf2_vmalloc 2528 1 uvcvideo, Live 0xffffffffc04cd000
videobuf2_memops 1559 1 videobuf2_vmalloc, Live 0xffffffffc04c9000
videobuf2_core 22473 1 uvcvideo, Live 0xffffffffc04be000
uinput 6657 0 - Live 0xffffffffc04b9000
ax88179_178a 11352 0 - Live 0xffffffffc04b2000
usbnet 17066 3 rndis_host,cdc_ether,ax88179_178a, Live 0xffffffffc04a7000
mii 3427 2 ax88179_178a,usbnet, Live 0xffffffffc04a3000
rtsx_pci_sdmmc 8434 0 - Live 0xffffffffc049d000
rtsx_pci 24242 1 rtsx_pci_sdmmc, Live 0xffffffffc0490000
mmc_core 73734 1 rtsx_pci_sdmmc, Live 0xffffffffc0471000
fuse 65180 0 - Live 0xffffffffc0458000
snd_hda_codec_realtek 37786 1 - Live 0xffffffffc0448000
iwlmvm 99382 0 - Live 0xffffffffc03d9000
kvm_intel 119916 0 - Live 0xffffffffc033e000
snd_hda_codec_generic 39626 1 snd_hda_codec_realtek, Live 0xffffffffc032d000
mac80211 352537 1 iwlmvm, Live 0xffffffffc0239000
kvm 332678 1 kvm_intel, Live 0xffffffffc014f000
pn544_mei 1507 0 - Live 0xffffffffc014b000
mei_phy 1942 1 pn544_mei, Live 0xffffffffc0147000
iwlwifi 70257 1 iwlmvm, Live 0xffffffffc0129000
pn544 6215 1 pn544_mei, Live 0xffffffffc0124000
snd_hda_intel 29721 2 - Live 0xffffffffc0106000
hci 13343 2 mei_phy,pn544, Live 0xffffffffc00fd000
nfc 46459 2 pn544,hci, Live 0xffffffffc00c8000
snd_hda_codec 72588 3
snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel, Live
0xffffffffc00a7000
snd_hwdep 5373 2 snd_usb_audio,snd_hda_codec, Live 0xffffffffc009b000
cfg80211 320801 3 iwlmvm,mac80211,iwlwifi, Live 0xffffffffc001e000
xhci_hcd 88348 0 - Live 0xffffffffc0000000
/proc/iomem:
00000000-00000fff : reserved
00001000-00057fff : System RAM
00058000-00058fff : reserved
00059000-0009dfff : System RAM
0009e000-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000c3fff : PCI Bus 0000:00
000c4000-000c7fff : PCI Bus 0000:00
000c8000-000cbfff : PCI Bus 0000:00
000cc000-000cffff : PCI Bus 0000:00
000d0000-000d3fff : PCI Bus 0000:00
000d4000-000d7fff : PCI Bus 0000:00
000d8000-000dbfff : PCI Bus 0000:00
000dc000-000dffff : PCI Bus 0000:00
000f0000-000fffff : System ROM
00100000-ca4b7fff : System RAM
06000000-066753ba : Kernel code
066753bb-06cc83ff : Kernel data
06dc9000-06ecffff : Kernel bss
ca4b8000-ca4befff : ACPI Non-volatile Storage
ca4bf000-ca8e7fff : System RAM
ca8e8000-cac39fff : reserved
cac3a000-da89bfff : System RAM
da89c000-dab3ffff : reserved
dab40000-dab55fff : ACPI Tables
dab56000-dbaaafff : ACPI Non-volatile Storage
dbaab000-dbffefff : reserved
dbfff000-dbffffff : System RAM
dd000000-df1fffff : reserved
dd200000-df1fffff : Graphics Stolen Memory
df200000-feafffff : PCI Bus 0000:00
df200000-df3fffff : PCI Bus 0000:01
e0000000-efffffff : 0000:00:02.0
e0000000-e07e8fff : BOOTFB
f0000000-f09fffff : PCI Bus 0000:03
f0a00000-f13fffff : PCI Bus 0000:02
f6400000-f67fffff : 0000:00:02.0
f6800000-f71fffff : PCI Bus 0000:03
f6800000-f680ffff : 0000:03:00.0
f6810000-f6811fff : 0000:03:00.0
f6810000-f6811fff : ahci
f7200000-f7bfffff : PCI Bus 0000:02
f7c00000-f7cfffff : PCI Bus 0000:01
f7c00000-f7c01fff : 0000:01:00.0
f7c00000-f7c01fff : iwlwifi
f7d00000-f7d0ffff : 0000:00:14.0
f7d00000-f7d0ffff : xhci_hcd
f7d10000-f7d13fff : 0000:00:1b.0
f7d10000-f7d13fff : ICH HD audio
f7d14000-f7d17fff : 0000:00:03.0
f7d19000-f7d190ff : 0000:00:1f.3
f7d1a000-f7d1a3ff : 0000:00:1d.0
f7d1a000-f7d1a3ff : ehci_hcd
f7d1c000-f7d1c01f : 0000:00:16.0
f7d1c000-f7d1c01f : mei_me
f7fef000-f7feffff : pnp 00:0a
f7ff0000-f7ffffff : pnp 00:0a
f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f]
f8000000-fbffffff : reserved
f8000000-fbffffff : pnp 00:0a
fec00000-fec00fff : reserved
fec00000-fec003ff : IOAPIC 0
fed00000-fed03fff : reserved
fed00000-fed003ff : HPET 0
fed10000-fed17fff : pnp 00:0a
fed18000-fed18fff : pnp 00:0a
fed19000-fed19fff : pnp 00:0a
fed1c000-fed1ffff : reserved
fed1c000-fed1ffff : pnp 00:0a
fed1f410-fed1f414 : iTCO_wdt
fed1f410-fed1f414 : iTCO_wdt
fed20000-fed3ffff : pnp 00:0a
fed45000-fed8ffff : pnp 00:0a
fed90000-fed93fff : pnp 00:0a
fee00000-fee00fff : Local APIC
fee00000-fee00fff : reserved
ff000000-ffffffff : reserved
ff000000-ffffffff : pnp 00:0a
100000000-21fdfffff : System RAM
21fe00000-21fffffff : RAM buffer
/proc/ioports:
0000-0cf7 : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0062-0062 : EC data
0064-0064 : keyboard
0066-0066 : EC cmd
0070-0077 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
04d0-04d1 : pnp 00:07
0680-069f : pnp 00:04
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
164e-164f : pnp 00:04
1800-1803 : ACPI PM1a_EVT_BLK
1804-1805 : ACPI PM1a_CNT_BLK
1808-180b : ACPI PM_TMR
1810-1815 : ACPI CPU throttle
1830-1833 : iTCO_wdt
1830-1833 : iTCO_wdt
1850-1850 : ACPI PM2_CNT_BLK
1854-1857 : pnp 00:06
1860-187f : iTCO_wdt
1860-187f : iTCO_wdt
1880-189f : ACPI GPE0_BLK
1c00-1cfe : pnp 00:04
1d00-1dfe : pnp 00:04
1e00-1efe : pnp 00:04
1f00-1ffe : pnp 00:04
2008-200b : pnp 00:04
3000-3fff : PCI Bus 0000:01
d000-dfff : PCI Bus 0000:03
e000-efff : PCI Bus 0000:02
f000-f03f : 0000:00:02.0
f040-f05f : 0000:00:1f.3
ffff-ffff : pnp 00:04
ffff-ffff : pnp 00:04
Regards,
Thomas
(my apologies for forgetting the plain-text requirement resulting in
this not reaching the list immediately)
[1] https://bbs.archlinux.org/viewtopic.php?pid=1350921
[2] http://i.imgur.com/NCanPUY.jpg
^ permalink raw reply
* Re: [PATCH-next] intel ethernet: fix s390 build failure due to implicit prefetch.h
From: Jeff Kirsher @ 2014-01-10 19:56 UTC (permalink / raw)
To: David Miller
Cc: sibai.li, e1000-devel, netdev, jesse.brandeburg, paul.gortmaker
In-Reply-To: <20140110.145229.334617909103085999.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 1106 bytes --]
On Fri, 2014-01-10 at 14:52 -0500, David Miller wrote:
> From: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Fri, 10 Jan 2014 14:28:16 -0500
>
> > As of commit 7f12ad741a4870b8b6e3aafbcd868d0191770802 ("i40evf: transmit
> > and receive functionality") the s390 builds (allyesconfig) fail with:
> >
> > drivers/net/ethernet/intel/i40evf/i40e_txrx.c: In function 'i40e_clean_rx_irq':
> > drivers/net/ethernet/intel/i40evf/i40e_txrx.c:818:3: error: implicit declaration of function 'prefetch'
> > make[5]: *** [drivers/net/ethernet/intel/i40evf/i40e_txrx.o] Error 1
> >
> > due to an implicit assumption that the prototype from linux/prefetch.h
> > will be present.
> >
> > Cc: Mitch Williams <mitch.a.williams@intel.com>
> > Cc: Greg Rose <gregory.v.rose@intel.com>
> > Cc: Sibai Li <sibai.li@intel.com>
> > Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> I hope the Intel folks will pick this up quickly and push it to me.
Yep, Aaron has it in the queue and it is being reviewed and tested
currently.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 388 bytes --]
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: pull request: wireless-next 2014-01-10
From: David Miller @ 2014-01-10 19:53 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140110183853.GH2131-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Fri, 10 Jan 2014 13:38:54 -0500
> Please pull these updates for the 3.14 stream!
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH-next] intel ethernet: fix s390 build failure due to implicit prefetch.h
From: David Miller @ 2014-01-10 19:52 UTC (permalink / raw)
To: paul.gortmaker
Cc: e1000-devel, netdev, jesse.brandeburg, mitch.a.williams,
gregory.v.rose, sibai.li, jeffrey.t.kirsher
In-Reply-To: <1389382096-17122-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 10 Jan 2014 14:28:16 -0500
> As of commit 7f12ad741a4870b8b6e3aafbcd868d0191770802 ("i40evf: transmit
> and receive functionality") the s390 builds (allyesconfig) fail with:
>
> drivers/net/ethernet/intel/i40evf/i40e_txrx.c: In function 'i40e_clean_rx_irq':
> drivers/net/ethernet/intel/i40evf/i40e_txrx.c:818:3: error: implicit declaration of function 'prefetch'
> make[5]: *** [drivers/net/ethernet/intel/i40evf/i40e_txrx.o] Error 1
>
> due to an implicit assumption that the prototype from linux/prefetch.h
> will be present.
>
> Cc: Mitch Williams <mitch.a.williams@intel.com>
> Cc: Greg Rose <gregory.v.rose@intel.com>
> Cc: Sibai Li <sibai.li@intel.com>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
I hope the Intel folks will pick this up quickly and push it to me.
^ permalink raw reply
* Re: [PATCH] netfilter updates for net-next
From: David Miller @ 2014-01-10 19:51 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1389380158-8754-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri, 10 Jan 2014 19:55:57 +0100
> This batch contains one single patch with the l2tp match
> for xtables, from James Chapman.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git master
Pulled, thanks Pablo.
^ permalink raw reply
* Re: [PATCH 08/23] netfilter: nft_ct: load both IPv4 and IPv6 conntrack modules for NFPROTO_INET
From: David Miller @ 2014-01-10 19:48 UTC (permalink / raw)
To: kaber; +Cc: sergei.shtylyov, pablo, netfilter-devel, netdev
In-Reply-To: <20140110194235.GA9253@macbook.localnet>
From: Patrick McHardy <kaber@trash.net>
Date: Fri, 10 Jan 2014 19:42:36 +0000
> I can see you're looking out for the important stuff. I consistently
> used this style in nftables so I'm not going to change it here.
Patrick, please follow the coding style conventions of the kernel,
these issues are important for long term sanity of the kernel tree.
It helps people who are looking at the netfilter code who perhaps
do not do so usually. Do you really want to use a different style
and therefore make your code harder to read for them? Really?
Your code being consistent with your code only is less important than
all of the networking looking the same.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] sctp: make sctp_addto_chunk_fixed local
From: Sergei Shtylyov @ 2014-01-10 20:45 UTC (permalink / raw)
To: Stephen Hemminger, Vlad Yasevich, Neil Horman, David Miller; +Cc: netdev
In-Reply-To: <20140109223111.71e55286@nehalam.linuxnetplumber.net>
Hello.
On 01/10/2014 09:31 AM, Stephen Hemminger wrote:
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
[...]
> --- a/net/sctp/sm_make_chunk.c 2014-01-09 22:29:51.871663405 -0800
> +++ b/net/sctp/sm_make_chunk.c 2014-01-09 22:29:58.323581984 -0800
> @@ -78,6 +78,8 @@ static int sctp_process_param(struct sct
> gfp_t gfp);
> static void *sctp_addto_param(struct sctp_chunk *chunk, int len,
> const void *data);
> +static void *sctp_addto_chunk_fixed(struct sctp_chunk *, int len,
Sorry for nitpicking but two spaces after 'void' don't align well with the
previous declaration. Probably can be fixed while applying...
> + const void *data);
>
> /* Control chunk destructor */
> static void sctp_control_release_owner(struct sk_buff *skb)
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 08/23] netfilter: nft_ct: load both IPv4 and IPv6 conntrack modules for NFPROTO_INET
From: Patrick McHardy @ 2014-01-10 19:42 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Pablo Neira Ayuso, netfilter-devel, davem, netdev
In-Reply-To: <52D05AC6.20000@cogentembedded.com>
On Fri, Jan 10, 2014 at 11:40:38PM +0300, Sergei Shtylyov wrote:
> On 01/10/2014 03:35 AM, Pablo Neira Ayuso wrote:
>
> >From: Patrick McHardy <kaber@trash.net>
>
> >The ct expression can currently not be used in the inet family since
> >we don't have a conntrack module for NFPROTO_INET, so
> >nf_ct_l3proto_try_module_get() fails. Add some manual handling to
> >load the modules for both NFPROTO_IPV4 and NFPROTO_IPV6 if the
> >ct expression is used in the inet family.
>
> >Signed-off-by: Patrick McHardy <kaber@trash.net>
> >Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> >---
> > net/netfilter/nft_ct.c | 39 ++++++++++++++++++++++++++++++++++++---
> > 1 file changed, 36 insertions(+), 3 deletions(-)
>
> >diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c
> >index 955f4e6..3727a32 100644
> >--- a/net/netfilter/nft_ct.c
> >+++ b/net/netfilter/nft_ct.c
> [...]
> >+static void nft_ct_l3proto_module_put(uint8_t family)
> >+{
> >+ if (family == NFPROTO_INET) {
> >+ nf_ct_l3proto_module_put(NFPROTO_IPV4);
> >+ nf_ct_l3proto_module_put(NFPROTO_IPV6);
> >+ } else
> >+ nf_ct_l3proto_module_put(family);
>
> According to Documentation/CodingStyle, there should be {} in the
> *else* arm, as the other arm of *if* statement has it.
I can see you're looking out for the important stuff. I consistently
used this style in nftables so I'm not going to change it here.
^ permalink raw reply
* Re: [PATCH] net: Check skb->rxhash in gro_receive
From: Tom Herbert @ 2014-01-10 19:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1389380077.31367.114.camel@edumazet-glaptop2.roam.corp.google.com>
> Really, 99% of the time gro_list contains zero or one single slot, I
> have hard data saying so.
>
Please provide the data.
> If you want to optimize the case where list is fully populated (because
> of yet another synthetic benchmark you use), you really need to build a
> temporary list so that all layers do not even have to check
> NAPI_GRO_CB(p)->same_flow
>
Well if you prefer, you can think of the "synthetic benchmark" as
emulating an obvious DOS attack by pumping MSS sized TCP segments with
random ports to a server. The stack needs to be resilient to such
things, an O(n*m) algorithm in the data path is a red flag.
> Each gro handler would remove non matching flow from this temp list.
>
> -> when we finally reach tcp_gro_receive(), list would contain a single
> element.
>
>
>
> --
> 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
^ permalink raw reply
* Re: [PATCH 01/23] netfilter: nft_reject: fix compilation warning if NF_TABLES_IPV6 is disabled
From: David Miller @ 2014-01-10 19:39 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <52D05912.1030606@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Fri, 10 Jan 2014 23:33:22 +0300
> Hello.
>
> On 01/10/2014 03:35 AM, Pablo Neira Ayuso wrote:
>
>> net/netfilter/nft_reject.c: In function 'nft_reject_eval':
>> net/netfilter/nft_reject.c:37:14: warning: unused variable 'net'
>> [-Wunused-variable]
>
>> Reported-by: kbuild test robot <fengguang.wu@intel.com>
>> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>> ---
>> net/netfilter/nft_reject.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>> diff --git a/net/netfilter/nft_reject.c b/net/netfilter/nft_reject.c
>> index 0d690d4..7ae63cd 100644
>> --- a/net/netfilter/nft_reject.c
>> +++ b/net/netfilter/nft_reject.c
>> @@ -34,8 +34,9 @@ static void nft_reject_eval(const struct nft_expr
>> *expr,
>> const struct nft_pktinfo *pkt)
>> {
>> struct nft_reject *priv = nft_expr_priv(expr);
>> +#if IS_ENABLED(CONFIG_NF_TABLES_IPV6)
>> struct net *net = dev_net((pkt->in != NULL) ? pkt->in : pkt->out);
>> -
>
> Why remove empty line after the declaration block?
Because "#endif" sort of serves the same purpose.
This is what I do too in this situation.
^ permalink raw reply
* Re: [PATCH] netdevice.7: document SIOCGIFCONF case ifc_req==NULL
From: Tilman Schmidt @ 2014-01-10 19:35 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <52D03351.20501-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hello Michael,
Am 10.01.2014 18:52, schrieb Michael Kerrisk (man-pages):
> On 01/10/2014 12:30 PM, Tilman Schmidt wrote:
>> Add the missing description of the possibility to call SIOCGIFCONF
>> with ifc_req==NULL to determine the needed buffer size, as described
>> in http://lkml.indiana.edu/hypermail/linux/kernel/0110.1/0506.html
>> and verified against source files net/core/dev_ioctl.c and
>> net/ipv4/devinet.c in the current kernel git tree.
[...]>
> Thanks for the patch. I'm trying to verify this from the code, but
> am having some trouble finding the relevant pieces. Could you point
> me more specifically at the points in the kernel source where this
> case is handled?
Gladly.
Function dev_ifconf() [net/core/dev_ioctl.c line 67ff.] is the main
handler for SIOCGIFCONF. It calls the registered protocol specific
handlers via the table gifconf_list[]. The current kernel has only
one such handler, inet_gifconf() [net/ipv4/devinet.c line 1115ff.]
If ifc.ifc_buf is NULL, dev_ifconf() calls the protocol specific
handlers with NULL as second argument. [net/core/dev_ioctl.c line 96]
If inet_gifconf() is called with NULL as second argument it just
adds up the data sizes, skipping the size check and data transfer.
[net/ipv4/devinet.c line 1127f.]
Best regards,
Tilman
--
Tilman Schmidt E-Mail: tilman-ZTO5kqT2PaM@public.gmane.org
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC net-next 1/3] bonding: add infrastructure for an option API
From: Scott Feldman @ 2014-01-10 19:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Nikolay Aleksandrov, Netdev
In-Reply-To: <20140110111914.6b33b650@nehalam.linuxnetplumber.net>
On Jan 10, 2014, at 11:19 AM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> On Fri, 10 Jan 2014 14:11:33 +0100
> Nikolay Aleksandrov <nikolay@redhat.com> wrote:
>
>> This patch adds the necessary basic infrastructure to support
>> centralized and unified option manipulation API for the bonding. The new
>> structure bond_option will be used to describe each option with its
>> dependencies on modes which will be checked automatically thus removing a
>> lot of duplicated code. Also automatic range checking is added for
>> non-string options. Currently the option setting function requires RTNL to
>> be acquired prior to calling it, since many options already rely on RTNL
>> it seemed like the best choice to protect all against common race
>> conditions.
>
> Please add new features via netlink not sysfs.
> Sysfs is awkward API for command line, and not accessible through ip link.
> Also it provides no notification of changes or configuration back to switches
> and other things using netlink.
I don’t think Nikolay is adding a new bonding feature. This patch series is a (very nice!) cleanup of option handling in the bonding driver. The recently added netlink interface to bonding options is still intact. This patch moves all the parsing/setting/getting/locking/bounds_checking/dependency_checking into one nice clean API.
I’m still reviewing patch set and might have more comments, but the first comment is: can this be generalized for more than just bonding? It seems lots of drivers which maintain an option set could benefit from a similar API.
-scott
^ permalink raw reply
* [PATCH-next] intel ethernet: fix s390 build failure due to implicit prefetch.h
From: Paul Gortmaker @ 2014-01-10 19:28 UTC (permalink / raw)
To: e1000-devel; +Cc: Sibai Li, Paul Gortmaker, netdev, Jesse Brandeburg
As of commit 7f12ad741a4870b8b6e3aafbcd868d0191770802 ("i40evf: transmit
and receive functionality") the s390 builds (allyesconfig) fail with:
drivers/net/ethernet/intel/i40evf/i40e_txrx.c: In function 'i40e_clean_rx_irq':
drivers/net/ethernet/intel/i40evf/i40e_txrx.c:818:3: error: implicit declaration of function 'prefetch'
make[5]: *** [drivers/net/ethernet/intel/i40evf/i40e_txrx.o] Error 1
due to an implicit assumption that the prototype from linux/prefetch.h
will be present.
Cc: Mitch Williams <mitch.a.williams@intel.com>
Cc: Greg Rose <gregory.v.rose@intel.com>
Cc: Sibai Li <sibai.li@intel.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
index 8f2b3b2..ffdb01d 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -21,6 +21,8 @@
*
******************************************************************************/
+#include <linux/prefetch.h>
+
#include "i40evf.h"
static inline __le64 build_ctob(u32 td_cmd, u32 td_offset, unsigned int size,
--
1.8.5.1
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: [RFC net-next 1/3] bonding: add infrastructure for an option API
From: Stephen Hemminger @ 2014-01-10 19:19 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev
In-Reply-To: <1389359495-9700-2-git-send-email-nikolay@redhat.com>
On Fri, 10 Jan 2014 14:11:33 +0100
Nikolay Aleksandrov <nikolay@redhat.com> wrote:
> This patch adds the necessary basic infrastructure to support
> centralized and unified option manipulation API for the bonding. The new
> structure bond_option will be used to describe each option with its
> dependencies on modes which will be checked automatically thus removing a
> lot of duplicated code. Also automatic range checking is added for
> non-string options. Currently the option setting function requires RTNL to
> be acquired prior to calling it, since many options already rely on RTNL
> it seemed like the best choice to protect all against common race
> conditions.
> In order to add an option the following steps need to be done:
> 1. Add an entry BOND_OPT_<option> to bond_options.h so it gets a unique id
> and a bit corresponding to the id
> 2. Add a bond_option entry to the bond_opts[] array in bond_options.c which
> describes the option, its dependencies and its manipulation function
> 3. Add code to export the option through sysfs and/or as a module parameter
> (the sysfs export will be made automatically in the future)
>
> The current available option types are:
> BOND_OPTVAL_INTEGER - range option, the flags should be used to define
> it properly
> BOND_OPTVAL_STRING - string option or an option which wants to do its
> own validation and conversion since the buffer is
> passed unmodified to the option manipulation function
>
> The options can have different flags set, currently the following are
> supported:
> BOND_OPTFLAG_NOSLAVES - require that the bond device has no slaves prior
> to setting the option
> BOND_OPTFLAG_IFDOWN - require that the bond device is down prior to
> setting the option
>
> There's a new value structure to describe different types of values
> which can have the following flags:
> BOND_VALFLAG_DEFAULT - marks the default option (permanent string alias
> to this option is "default")
> BOND_VALFLAG_MIN - the minimum value that this option can have
> BOND_VALFLAG_MAX - the maximum value that this option can have
>
> An example would be nice here, so if we have an option which can have
> the values "off"(2), "special"(4, default) and supports a range, say
> 16 - 32, it should be defined as follows:
> "off", 2,
> "special", 4, BOND_VALFLAG_DEFAULT,
> "rangemin", 16, BOND_VALFLAG_MIN,
> "rangemax", 32, BOND_VALFLAG_MAX
> So we have the valid intervals: [2, 2], [4, 4], [16, 32]
>
> BOND_VALFLAG_(MIN|MAX) can be used to specify a valid range for an
> option, if MIN is omitted then 0 is considered as a minimum. If an
> exact match is found in the values[] table it will be returned,
> otherwise the range is tried (if available).
> The values[] table which describes the allowed values for an option is
> not mandatory for BOND_OPTVAL_STRING, but if it's present it will be
> used.
>
> For BOND_OPTVAL_INTEGER the values[] table is mandatory.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Please add new features via netlink not sysfs.
Sysfs is awkward API for command line, and not accessible through ip link.
Also it provides no notification of changes or configuration back to switches
and other things using netlink.
^ permalink raw reply
* Re: [PATCH net-next] net: vxlan: when lower dev unregisters remove vxlan dev as well
From: Daniel Borkmann @ 2014-01-10 19:16 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Cong Wang, David Miller, netdev
In-Reply-To: <20140110111233.3364ec17@nehalam.linuxnetplumber.net>
On 01/10/2014 08:12 PM, Stephen Hemminger wrote:
> On Fri, 10 Jan 2014 20:07:12 +0100
> Daniel Borkmann <dborkman@redhat.com> wrote:
>
>>>> + BUG_ON(!rtnl_is_locked());
>>>
>>>
>>> This is not necessary at all, it is known that netdev notication
>>> holds rtnl lock.
>>
>> We're not in fast-path, and if someone would call that function outside
>> of the notifier chain, it might be good to check if the lock was taken,
>> but if there's a strong opinion to not have that, I'll just remove it
>
> First, the standard way to do this is ASSERT_RTNL()
>
> Second, it is unnecessary. The function is local, only called through
> notifier and notifiers always have RTNL held.
Ok, I'll just remove it, and resend if you're fine with this.
^ permalink raw reply
* Re: [PATCH net-next] net: vxlan: when lower dev unregisters remove vxlan dev as well
From: Daniel Borkmann @ 2014-01-10 19:16 UTC (permalink / raw)
To: Cong Wang; +Cc: David Miller, netdev
In-Reply-To: <52D044E0.1090206@redhat.com>
On 01/10/2014 08:07 PM, Daniel Borkmann wrote:
> On 01/10/2014 07:51 PM, Cong Wang wrote:
>> On Fri, Jan 10, 2014 at 5:01 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> I think you need to flush fdb as well?
>
> Seems this is not done through normal rtnl_ops->dellink(); vxlan_dellink()
> is what we call there as well ...
Ok, this is being flushed during ndo_stop().
^ permalink raw reply
* Re: [PATCH net-next] net: vxlan: when lower dev unregisters remove vxlan dev as well
From: Stephen Hemminger @ 2014-01-10 19:12 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Cong Wang, David Miller, netdev
In-Reply-To: <52D044E0.1090206@redhat.com>
On Fri, 10 Jan 2014 20:07:12 +0100
Daniel Borkmann <dborkman@redhat.com> wrote:
> >> + BUG_ON(!rtnl_is_locked());
> >
> >
> > This is not necessary at all, it is known that netdev notication
> > holds rtnl lock.
>
> We're not in fast-path, and if someone would call that function outside
> of the notifier chain, it might be good to check if the lock was taken,
> but if there's a strong opinion to not have that, I'll just remove it
First, the standard way to do this is ASSERT_RTNL()
Second, it is unnecessary. The function is local, only called through
notifier and notifiers always have RTNL held.
^ permalink raw reply
* Re: [PATCH net-next] net: vxlan: when lower dev unregisters remove vxlan dev as well
From: Stephen Hemminger @ 2014-01-10 19:10 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev
In-Reply-To: <1389358907-19885-1-git-send-email-dborkman@redhat.com>
On Fri, 10 Jan 2014 14:01:47 +0100
Daniel Borkmann <dborkman@redhat.com> wrote:
> We can create a vxlan device with an explicit underlying carrier.
> In that case, when the carrier link is being deleted from the
> system (e.g. due to module unload) we should also clean up all
> created vxlan devices on top of it since otherwise we're in an
> inconsistent state in vxlan device. In that case, the user needs
> to remove all such devices, while in case of other virtual devs
> that sit on top of physical ones, it is usually the case that
> these devices do unregister automatically as well and do not
> leave the burden on the user.
>
> This work is not necessary when vxlan device was not created with
> a real underlying device, as connections can resume in that case
> when driver is plugged again. But at least for the other cases,
> we should go ahead and do the cleanup on removal.
>
> `ip -d link show vxlan13` after carrier removal before this patch:
>
> 5: vxlan13: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default
> link/ether 1e:47:da:6d:4d:99 brd ff:ff:ff:ff:ff:ff promiscuity 0
> vxlan id 13 group 239.0.0.10 dev 2 port 32768 61000 ageing 300
> ^^^^^
> While at it, we should also use vxlan_dellink() handler in
> vxlan_exit_net() as otherwise we seem to leak memory on module
> unload since only half of the cleanup is being done.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
The issue is generic to all tunnels
^ permalink raw reply
* Re: [PATCH net-next] net: vxlan: when lower dev unregisters remove vxlan dev as well
From: Daniel Borkmann @ 2014-01-10 19:07 UTC (permalink / raw)
To: Cong Wang; +Cc: David Miller, netdev
In-Reply-To: <CAHA+R7NPyEmSpmojrM6pOsAVq3B6NjVWWCw0oQMPZFdCaDW9sA@mail.gmail.com>
On 01/10/2014 07:51 PM, Cong Wang wrote:
> On Fri, Jan 10, 2014 at 5:01 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> We can create a vxlan device with an explicit underlying carrier.
>> In that case, when the carrier link is being deleted from the
>> system (e.g. due to module unload) we should also clean up all
>> created vxlan devices on top of it since otherwise we're in an
>> inconsistent state in vxlan device. In that case, the user needs
>> to remove all such devices, while in case of other virtual devs
>> that sit on top of physical ones, it is usually the case that
>> these devices do unregister automatically as well and do not
>> leave the burden on the user.
>>
>> This work is not necessary when vxlan device was not created with
>> a real underlying device, as connections can resume in that case
>> when driver is plugged again. But at least for the other cases,
>> we should go ahead and do the cleanup on removal.
>
> So it makes sense to move the notifier register to vxlan_newlink()
> from vxlan_init_module()?
That is probably a design descision ... I didn't want to bloat the
struct vxlan_dev, and by this approach, we can simply batch removals
through unregister_netdevice_many(), that's all.
> ...
>>
>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>> index 481f85d..39035ba 100644
>> --- a/drivers/net/vxlan.c
>> +++ b/drivers/net/vxlan.c
>> @@ -2656,6 +2656,54 @@ static struct rtnl_link_ops vxlan_link_ops __read_mostly = {
>> .fill_info = vxlan_fill_info,
>> };
>>
>> +static void vxlan_handle_lowerdev_unregister(struct vxlan_net *vn,
>> + struct net_device *dev)
>> +{
>> + struct vxlan_dev *vxlan, *next;
>> + LIST_HEAD(list_kill);
>> +
>> + BUG_ON(!rtnl_is_locked());
>
>
> This is not necessary at all, it is known that netdev notication
> holds rtnl lock.
We're not in fast-path, and if someone would call that function outside
of the notifier chain, it might be good to check if the lock was taken,
but if there's a strong opinion to not have that, I'll just remove it.
>> +
>> + list_for_each_entry_safe(vxlan, next, &vn->vxlan_list, next) {
>> + struct vxlan_rdst *dst = &vxlan->default_dst;
>> +
>> + /* In case we created vxlan device with carrier
>> + * and we loose the carrier due to module unload
>> + * we also need to remove vxlan device. In other
>> + * cases, it's not necessary and remote_ifindex
>> + * is 0 here, so no matches.
>> + */
>> + if (dst->remote_ifindex == dev->ifindex)
>> + vxlan_dellink(vxlan->dev, &list_kill);
>> + }
>> +
>> + unregister_netdevice_many(&list_kill);
>> + list_del(&list_kill);
>
>
> I think you need to flush fdb as well?
Seems this is not done through normal rtnl_ops->dellink(); vxlan_dellink()
is what we call there as well ...
>> static __net_init int vxlan_init_net(struct net *net)
>> {
>> struct vxlan_net *vn = net_generic(net, vxlan_net_id);
>> @@ -2673,14 +2721,16 @@ static __net_init int vxlan_init_net(struct net *net)
>> static __net_exit void vxlan_exit_net(struct net *net)
>> {
>> struct vxlan_net *vn = net_generic(net, vxlan_net_id);
>> - struct vxlan_dev *vxlan;
>> - LIST_HEAD(list);
>> + struct vxlan_dev *vxlan, *next;
>> + LIST_HEAD(list_kill);
>>
>> rtnl_lock();
>> - list_for_each_entry(vxlan, &vn->vxlan_list, next)
>> - unregister_netdevice_queue(vxlan->dev, &list);
>> - unregister_netdevice_many(&list);
>> + list_for_each_entry_safe(vxlan, next, &vn->vxlan_list, next)
>> + vxlan_dellink(vxlan->dev, &list_kill);
>> + unregister_netdevice_many(&list_kill);
>> rtnl_unlock();
>> +
>> + list_del(&list_kill);
>
>
> Why these changes in vxlan_exit_net()?
I think this is way cleaner; instead of only doing half the work, we
should remove it in the same way as we remove devices through normal
rtnl ops. In case we would do allocations in future that are being
freed during vxlan_dellink(), we would simply leak them here otherwise.
^ 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