* Re: [PATCH 1/1] netlink: Deletion of an unnecessary check before the function call "__module_get"
From: David Miller @ 2014-11-19 20:28 UTC (permalink / raw)
To: elfring; +Cc: netdev, linux-kernel, kernel-janitors, cocci
In-Reply-To: <546BA747.6000703@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 18 Nov 2014 21:08:39 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 18 Nov 2014 21:03:13 +0100
>
> The __module_get() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/4] igb: enable internal PPS for the i210.
From: Richard Cochran @ 2014-11-19 20:26 UTC (permalink / raw)
To: Keller, Jacob E
Cc: netdev@vger.kernel.org, davem@davemloft.net, Allan, Bruce W,
Ronciak, John, Kirsher, Jeffrey T, Vick, Matthew
In-Reply-To: <1416425553.15933.32.camel@jekeller-desk1.amr.corp.intel.com>
On Wed, Nov 19, 2014 at 07:32:33PM +0000, Keller, Jacob E wrote:
> Good catch :)
(Well, my X session suddenly disappeared, and a kernel oops appeared in
the console... hard to overlook ;^)
> Did you see my concern about the reset path needing to fully restore the
> state since it is called after a hardware MAC reset which has cleared
> all these registers?
Yes, and that bit I copied from the first series a year ago. I don't
remember why, but IIRC that was necessary to let the SDP stuff work at
all. Maybe the reset function was called under different circumstances
back then. I'll take another look.
I find it a bit weird that the auxiliary functions don't work when the
interface or the link is down.
Thanks,
Richard
^ permalink raw reply
* Re: [patches][RFC] situation with csum_and_copy_... API
From: David Miller @ 2014-11-19 20:25 UTC (permalink / raw)
To: viro; +Cc: netdev, torvalds, linux-kernel
In-Reply-To: <20141118194053.GA14641@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Tue, 18 Nov 2014 19:40:53 +0000
> On Tue, Nov 18, 2014 at 08:47:45AM +0000, Al Viro wrote:
>
>> I do have a patch doing just that; the question is what to do with csum-and-copy
>> primitives. Originally I planned to simply strip those access_ok() from those
>> (both the explicit calls and use of copy_from_user() where we ought to use
>> __copy_from_user(), etc.), but that's not nice to potential out-of-tree callers
>> of those suckers. If any of those exist and manage to cope with the wonderful
>> calling conventions, that is. As it is, we have the total of 4 callers of
>> csum_and_copy_from_user() and 2 callers of csum_and_copy_to_user(), all in
>> networking code. Do we care about potential out-of-tree users existing and
>> getting screwed by such change? Davem, Linus?
>
> FWIW, the beginning of series in question follows; removal of those
> access_ok() is 3/5. The series is longer than that (see vfs.git#iov_iter-net
> for a bit more, and there's more stuff in local queue still too much in flux
> to push them out), but all the stuff relevant to validating iovecs on
> sendmsg/recvmsg and getting rid of excessive access_ok() is in the first 5
> commits.
Al I really like this series, especially patch #2.
Sorry for taking so long to review this, I just wanted to make sure we
got this right.
Can you give me a pull request for just these 5 patches? Then feel free
to post the next batch for review, I'm eager to see it as are others.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/1] net: pktgen: Deletion of an unnecessary check before the function call "proc_remove"
From: David Miller @ 2014-11-19 20:20 UTC (permalink / raw)
To: elfring; +Cc: netdev, linux-kernel, kernel-janitors, cocci
In-Reply-To: <546B9AF5.9050809@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 18 Nov 2014 20:16:05 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 18 Nov 2014 20:10:34 +0100
>
> The proc_remove() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] openvswitch: Fix mask generation for IPv6 labels.
From: David Miller @ 2014-11-19 20:19 UTC (permalink / raw)
To: joestringer; +Cc: netdev, linux-kernel, pshelar, dev
In-Reply-To: <1416336857-61405-1-git-send-email-joestringer@nicira.com>
From: Joe Stringer <joestringer@nicira.com>
Date: Tue, 18 Nov 2014 10:54:17 -0800
> When userspace doesn't provide a mask, OVS datapath generates a fully
> unwildcarded mask for the flow. This is done by taking a copy of the
> flow key, then iterating across its attributes, setting all values to
> 0xff. This works for most attributes, as the length of the netlink
> attribute typically matches the length of the value. However, IPv6
> labels only use the lower 20 bits of the field. This patch makes a
> special case to handle this.
>
> This fixes the following error seen when installing IPv6 flows without a mask:
>
> openvswitch: netlink: Invalid IPv6 flow label value (value=ffffffff, max=fffff)
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
Judging by the discussion ongoing about this patch, I am assuming there
will be a new version of this change forthcoming.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] usbnet: rtl8150: remove unused variable
From: David Miller @ 2014-11-19 20:17 UTC (permalink / raw)
To: sudipm.mukherjee; +Cc: petkan, linux-usb, netdev, linux-kernel
In-Reply-To: <1416327921-2233-1-git-send-email-sudipm.mukherjee@gmail.com>
From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date: Tue, 18 Nov 2014 21:55:21 +0530
> remove unused variable
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> ---
>
> change in v2: changed the commit message
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-net 0/4] Increase the limit of tuntap queues
From: David Miller @ 2014-11-19 20:16 UTC (permalink / raw)
To: pagupta
Cc: linux-kernel, netdev, jasowang, mst, dgibson, vfalico, edumazet,
vyasevic, hkchu, wuzhy, xemul, therbert, bhutchings, xii, stephen,
jiri, sergei.shtylyov
In-Reply-To: <1416327778-17716-1-git-send-email-pagupta@redhat.com>
From: Pankaj Gupta <pagupta@redhat.com>
Date: Tue, 18 Nov 2014 21:52:54 +0530
> - Accept maximum number of queues as sysctl param so that any user space
> application like libvirt can use this value to limit number of queues. Also
> Administrators can specify maximum number of queues by updating this sysctl
> entry.
This is the only part I don't like.
Just let whoever has privileges to configure the tun device shoot
themselves in the foot if they want to by configuring "too many"
queues.
If the virtual entity runs itself out of resources by doing something
stupid, it's purely their problem.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: Add VXLAN ndo calls to the PF net device ops too
From: David Miller @ 2014-11-19 20:11 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, fw, amirv, saeedm
In-Reply-To: <1416325887-14704-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Tue, 18 Nov 2014 17:51:27 +0200
> This is currently missing, which results in a crash when one attempts
> to set VXLAN tunnel over the mlx4_en when acting as PF.
>
> [ 2408.785472] BUG: unable to handle kernel NULL pointer dereference at (null)
> [...]
> [ 2408.994104] Call Trace:
> [ 2408.996584] [<ffffffffa021f7f5>] ? vxlan_get_rx_port+0xd6/0x103 [vxlan]
> [ 2409.003316] [<ffffffffa021f71f>] ? vxlan_lowerdev_event+0xf2/0xf2 [vxlan]
> [ 2409.010225] [<ffffffffa0630358>] mlx4_en_start_port+0x862/0x96a [mlx4_en]
> [ 2409.017132] [<ffffffffa063070f>] mlx4_en_open+0x17f/0x1b8 [mlx4_en]
>
> While here, make sure to invoke vxlan_get_rx_port() only when VXLAN
> offloads are actually enabled and not when they are only supported.
>
> Reported-by: Ido Shamay <idos@mellanox.com>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Applied, -stable material? If so for what releases?
In the future, if you add an appropriated Fixes: tag I can figure most
of this out without asking you.
Thanks.
^ permalink raw reply
* Re: [PATCH net] bonding: fix curr_active_slave/carrier with loadbalance arp monitoring
From: David Miller @ 2014-11-19 20:10 UTC (permalink / raw)
To: gospo; +Cc: vfalico, nikolay, netdev, j.vosburgh, andy, dingtianhong
In-Reply-To: <20141118152847.GB2002@gospo.home.greyhouse.net>
From: Andy Gospodarek <gospo@cumulusnetworks.com>
Date: Tue, 18 Nov 2014 10:28:47 -0500
> On Tue, Nov 18, 2014 at 03:37:27PM +0100, Veaceslav Falico wrote:
>> On Tue, Nov 18, 2014 at 03:14:44PM +0100, Nikolay Aleksandrov wrote:
>> >Since commit 6fde8f037e60 ("bonding: fix locking in
>> >bond_loadbalance_arp_mon()") we can have a stale bond carrier state and
>> >stale curr_active_slave when using arp monitoring in loadbalance modes. The
>> >reason is that in bond_loadbalance_arp_mon() we can't have
>> >do_failover == true but slave_state_changed == false, whenever do_failover
>> >is true then slave_state_changed is also true. Then the following piece
>> >from bond_loadbalance_arp_mon():
>> > if (slave_state_changed) {
>> > bond_slave_state_change(bond);
>> > if (BOND_MODE(bond) == BOND_MODE_XOR)
>> > bond_update_slave_arr(bond, NULL);
>> > } else if (do_failover) {
>>
>> Ouch, must have been a big PITA to track :).
>
> Agreed!
...
>> Acked-by: Veaceslav Falico <vfalico@gmail.com>
>
> Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
Applied, and queued up for -stable, thanks everyone!
^ permalink raw reply
* Re: [net-next.git 0/3] stmmac: update driver documentation
From: David Miller @ 2014-11-19 20:06 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1416300421-25500-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Tue, 18 Nov 2014 09:46:58 +0100
> Recently many changes have been done inside the driver
> so this patch updates the driver's doc for example reviewing
> information for the rx and tx processes that are managed
> by napi method, adding new information for missing glue-logic files
> etc.
> Also this reviews and fixes what is reported when run kernel-doc script.
Series applied, thanks.
^ permalink raw reply
* Kernel BUG?: IPv6 neighbor discovery fails in network namespace with TAP interface
From: Spike Curtis @ 2014-11-19 19:59 UTC (permalink / raw)
To: netdev@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 7987 bytes --]
One line summary of the problem:
IPv6 neighbor discovery fails in network namespace with TAP interface
Full description of the problem/report:
I'm working in a network namespace (netns), and have several TAP devices as virtual network interfaces, which another process outside the namespace reads and writes.
The problem is that IPv6 neighbor discovery times out over these interfaces. I have a TCP6 session from a loopback assigned address to a remote peer, which is directly connected over the tap interface.
I've monitored the connection with Wireshark: when the TCP6 session is activated, I see Neighbor Solicitation packets sent to the solicited node multicast address for the peer, a response from the peer, and then traffic over TCP6. I don't see any later unicast Neighbor Solicitation probes to the peer address. Instead, I see another multicast probe to the solicited node address. I also see repeated Neighbor Solicitations for the link local address auto-assigned to the TAP interface, but I'm not sure if this is because duplicate address detection is failing, or if Linux periodically probes, or if the TAP interface is cyclically failing at the IPv6 layer (I also run IPv4 traffic over the TAP and there are no interruptions).
When I monitor the IPv6 neighbor cache using 'ip -6 neigh show', I can see the peer address moving to FAILED or INCOMPLETE state (after several iterations of multicast probes seeming to work correctly).
What's odd to me is that
a) The established TCP6 connection doesn't keep the neighbor cache entry fresh
b) I only ever see multicast probes, never a unicast probe for unreachability detection
Anyway, the consequence of all this is that my running TCP6 session fails.
IPv6 forwarding is disabled, and all other IPv6 parameters are at their Ubuntu 14.04 defaults. In particular, ucast_solicit = 3, so it *should* be sending unicast probes.
Nothing related to networking is logged to syslog while all of this is happening.
I've attached a pcap: 2001:400::1:0:0/128 is the local loopback, 2001:400::16:0/127 is the local address, 2001:400::16:1 is the remote IPv6 speaker.
Keywords:
IPv6, ndp, network namespace, TAP
Kernel version (from /proc/version):
Linux version 3.13.0-39-generic (buildd@toyol) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014
Environment
Ubuntu 14.04 LTS, running virtualized on Virtual Box 4.3.15 (Windows 7)
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3687U CPU @ 2.10GHz
stepping : 9
microcode : 0x19
cpu MHz : 2484.699
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl pni ssse3 lahf_lm
bogomips : 4969.39
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3687U CPU @ 2.10GHz
stepping : 9
microcode : 0x19
cpu MHz : 2484.699
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl pni ssse3 lahf_lm
bogomips : 4969.39
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
$ cat /proc/modules
xt_recent 18498 0 - Live 0x0000000000000000
nfnetlink_queue 22329 0 - Live 0x0000000000000000
nfnetlink_log 17926 0 - Live 0x0000000000000000
nfnetlink 14606 2 nfnetlink_queue,nfnetlink_log, Live 0x0000000000000000
veth 13331 0 - Live 0x0000000000000000
vboxsf 39690 0 - Live 0x0000000000000000 (OX)
bridge 110833 0 - Live 0x0000000000000000
stp 12976 1 bridge, Live 0x0000000000000000
llc 14552 2 bridge,stp, Live 0x0000000000000000
rfcomm 69160 0 - Live 0x0000000000000000
bnep 19624 2 - Live 0x0000000000000000
bluetooth 391136 10 rfcomm,bnep, Live 0x0000000000000000
binfmt_misc 17468 1 - Live 0x0000000000000000
hid_generic 12548 0 - Live 0x0000000000000000
joydev 17381 0 - Live 0x0000000000000000
snd_intel8x0 38153 2 - Live 0x0000000000000000
snd_ac97_codec 130285 1 snd_intel8x0, Live 0x0000000000000000
ac97_bus 12730 1 snd_ac97_codec, Live 0x0000000000000000
snd_pcm 102099 2 snd_intel8x0,snd_ac97_codec, Live 0x0000000000000000
ip6t_REJECT 12939 1 - Live 0x0000000000000000
snd_page_alloc 18710 2 snd_intel8x0,snd_pcm, Live 0x0000000000000000
snd_seq_midi 13324 0 - Live 0x0000000000000000
snd_seq_midi_event 14899 1 snd_seq_midi, Live 0x0000000000000000
xt_hl 12521 6 - Live 0x0000000000000000
ip6t_rt 13537 3 - Live 0x0000000000000000
snd_rawmidi 30144 1 snd_seq_midi, Live 0x0000000000000000
nf_conntrack_ipv6 18894 8 - Live 0x0000000000000000
nf_defrag_ipv6 34768 1 nf_conntrack_ipv6, Live 0x0000000000000000
ipt_REJECT 12541 1 - Live 0x0000000000000000
xt_LOG 17717 10 - Live 0x0000000000000000
snd_seq 61560 2 snd_seq_midi,snd_seq_midi_event, Live 0x0000000000000000
xt_limit 12711 13 - Live 0x0000000000000000
xt_tcpudp 12884 28 - Live 0x0000000000000000
xt_addrtype 12635 4 - Live 0x0000000000000000
snd_seq_device 14497 3 snd_seq_midi,snd_rawmidi,snd_seq, Live 0x0000000000000000
nf_conntrack_ipv4 15012 8 - Live 0x0000000000000000
nf_defrag_ipv4 12758 1 nf_conntrack_ipv4, Live 0x0000000000000000
snd_timer 29482 2 snd_pcm,snd_seq, Live 0x0000000000000000
usbhid 52659 0 - Live 0x0000000000000000
xt_conntrack 12760 16 - Live 0x0000000000000000
hid 106148 2 hid_generic,usbhid, Live 0x0000000000000000
vboxvideo 12658 1 - Live 0x0000000000000000 (OX)
ip6table_filter 12815 1 - Live 0x0000000000000000
drm 303102 2 vboxvideo, Live 0x0000000000000000
ip6_tables 27025 1 ip6table_filter, Live 0x0000000000000000
nf_conntrack_netbios_ns 12665 0 - Live 0x0000000000000000
nf_conntrack_broadcast 12589 1 nf_conntrack_netbios_ns, Live 0x0000000000000000
nf_nat_ftp 12770 0 - Live 0x0000000000000000
nf_nat 21841 1 nf_nat_ftp, Live 0x0000000000000000
nf_conntrack_ftp 18638 1 nf_nat_ftp, Live 0x0000000000000000
nf_conntrack 96976 8 nf_conntrack_ipv6,nf_conntrack_ipv4,xt_conntrack,nf_conntrack_netbios_ns,nf_conntrack_broadcast,nf_nat_ftp,nf_nat,nf_conntrack_ftp, Live 0x0000000000000000
snd 69322 12 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_seq_midi,snd_rawmidi,snd_seq,snd_seq_device,snd_timer, Live 0x0000000000000000
iptable_filter 12810 1 - Live 0x0000000000000000
ip_tables 27239 1 iptable_filter, Live 0x0000000000000000
x_tables 34059 14 xt_recent,ip6t_REJECT,xt_hl,ip6t_rt,ipt_REJECT,xt_LOG,xt_limit,xt_tcpudp,xt_addrtype,xt_conntrack,ip6table_filter,ip6_tables,iptable_filter,ip_tables, Live 0x0000000000000000
serio_raw 13462 0 - Live 0x0000000000000000
i2c_piix4 22155 0 - Live 0x0000000000000000
soundcore 12680 1 snd, Live 0x0000000000000000
vboxguest 248675 7 vboxsf, Live 0x0000000000000000 (OX)
parport_pc 32701 0 - Live 0x0000000000000000
ppdev 17671 0 - Live 0x0000000000000000
mac_hid 13205 0 - Live 0x0000000000000000
lp 17759 0 - Live 0x0000000000000000
parport 42348 3 parport_pc,ppdev,lp, Live 0x0000000000000000
psmouse 106714 0 - Live 0x0000000000000000
ahci 25819 2 - Live 0x0000000000000000
libahci 32716 1 ahci, Live 0x0000000000000000
e1000 145174 0 - Live 0x0000000000000000
[-- Attachment #2: ipv6ndp.pcap --]
[-- Type: application/octet-stream, Size: 38786 bytes --]
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Michael Tokarev @ 2014-11-19 19:58 UTC (permalink / raw)
To: Arend van Spriel
Cc: Maximilian Engelhardt, Rafał Miłecki, Seth Forshee,
brcm80211 development, linux-wireless@vger.kernel.org,
Network Development
In-Reply-To: <546CD94D.9060509@broadcom.com>
19.11.2014 20:54, Arend van Spriel wrote:
[]
> In our last email exchange I got the impression you switch to Intel board and did not want to keep replacing cards for testing.
I especially wrote that I have several days to try things out and
if you'll be quick it will be possible for me to test things.
You never replied before now (which is some more months later).
> Nice to hear you have an alternative setup for this and I assume are willing to do some testing.
>
> I submitted two patches upstream and additionally I have attached two other that are still under review. Could you try these patches and sent me the content of the two debugfs files 'macstat' and 'hardware' after a stall has occurred.
You didn't tell which kernel it is based on. So I tried it on 3.16,
ofcourse the patches didn't apply so I hand-edited the debug
printf in drivers/net/wireless/brcm80211/brcmsmac/debug.c (in
3.16 it didn't use seq_printf yet). So now I have a `hardware'
file (in brcmsmac/bcma0:0/ subdir in debugfs), but not
macstat. Here's the contents `hardware' one:
chipnum 0x4313
chiprev 0x1
chippackage 0x8
corerev 0x18
boardid 0x1795
boardvendor 0x103c
boardrev P107
boardflags 0x402201
boardflags2 0x884
ucoderev 0x262032c
radiorev 0x1
phytype 0x8
phyrev 0x1
anarev 0xa
nvramrev 8
Since there's no macstats, I guess it is not very useful,
so before digging for too deep, I ask which kernel do you
want me to try here.
Thanks,
/mjt
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: make connect() mem charging friendly
From: David Miller @ 2014-11-19 19:57 UTC (permalink / raw)
To: ycheng; +Cc: eric.dumazet, nuclearcat, netdev, ncardwell
In-Reply-To: <CAK6E8=dUvde2s7VuUS9rHiA2fU0ZT2bS=ronjM+9BOA=0u-rVw@mail.gmail.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 19 Nov 2014 14:10:42 +0800
> On Tue, Nov 18, 2014 at 3:06 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> While working on sk_forward_alloc problems reported by Denys
>> Fedoryshchenko, we found that tcp connect() (and fastopen) do not call
>> sk_wmem_schedule() for SYN packet (and/or SYN/DATA packet), so
>> sk_forward_alloc is negative while connect is in progress.
>>
>> We can fix this by calling regular sk_stream_alloc_skb() both for the
>> SYN packet (in tcp_connect()) and the syn_data packet in
>> tcp_send_syn_data()
>>
>> Then, tcp_send_syn_data() can avoid copying syn_data as we simply
>> can manipulate syn_data->cb[] to remove SYN flag (and increment seq)
>>
>> Instead of open coding memcpy_fromiovecend(), simply use this helper.
>>
>> This leaves in socket write queue clean fast clone skbs.
>>
>> This was tested against our fastopen packetdrill tests.
>>
>> Reported-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>
>
> Thanks! this simplifies the code a lot.
Agreed, applied, thanks everyone!
^ permalink raw reply
* [PATCH 1/1] mISDN: Deletion of unnecessary checks before the function call "vfree"
From: SF Markus Elfring @ 2014-11-19 19:55 UTC (permalink / raw)
To: Karsten Keil, netdev; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5317A59D.4@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 19 Nov 2014 20:48:26 +0100
The vfree() function performs also input parameter validation. Thus the test
around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/isdn/mISDN/l1oip_codec.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/isdn/mISDN/l1oip_codec.c b/drivers/isdn/mISDN/l1oip_codec.c
index a601c84..9b033be 100644
--- a/drivers/isdn/mISDN/l1oip_codec.c
+++ b/drivers/isdn/mISDN/l1oip_codec.c
@@ -312,10 +312,8 @@ l1oip_ulaw_to_alaw(u8 *data, int len, u8 *result)
void
l1oip_4bit_free(void)
{
- if (table_dec)
- vfree(table_dec);
- if (table_com)
- vfree(table_com);
+ vfree(table_dec);
+ vfree(table_com);
table_com = NULL;
table_dec = NULL;
}
--
2.1.3
^ permalink raw reply related
* Re: [PATCH net-next] tun: return NET_XMIT_DROP for dropped packets
From: Cong Wang @ 2014-11-19 19:53 UTC (permalink / raw)
To: David Miller
Cc: Jason Wang, netdev, linux-kernel@vger.kernel.org,
Michael S. Tsirkin
In-Reply-To: <20141119.144604.269852847904624488.davem@davemloft.net>
On Wed, Nov 19, 2014 at 11:46 AM, David Miller <davem@davemloft.net> wrote:
>
> Often the issue with TX return values is lack of clear documentation
> and use cases.
>
NET_XMIT_* are marked as qdisc ->enqueue() return codes
in include/linux/netdevice.h, and are indeed used mostly by
qdisc:
$ git grep NET_XMIT_ -- net/sched/ | wc -l
88
$ git grep NET_XMIT_ -- drivers/net/ | wc -l
15
It is a mess. Not to mention we have __NET_XMIT_ code too.
^ permalink raw reply
* Re: [ovs-dev] [PATCH net] openvswitch: Fix mask generation for IPv6 labels.
From: Joe Stringer @ 2014-11-19 19:51 UTC (permalink / raw)
To: Pravin Shelar; +Cc: dev@openvswitch.org, netdev, LKML
In-Reply-To: <CALnjE+pQnUGiiuWPGt7fNnBetwdn7SQReDqCHDforX7ykQQR8Q@mail.gmail.com>
On Wednesday, November 19, 2014 11:08:35 Pravin Shelar wrote:
> On Wed, Nov 19, 2014 at 9:48 AM, Joe Stringer <joestringer@nicira.com>
wrote:
> > On Wednesday, November 19, 2014 00:11:01 Pravin Shelar wrote:
> >> On Tue, Nov 18, 2014 at 11:25 PM, Joe Stringer <joestringer@nicira.com>
> >
> > wrote:
> >> > On 18 November 2014 22:09, Pravin Shelar <pshelar@nicira.com> wrote:
> >> >> On Tue, Nov 18, 2014 at 10:54 AM, Joe Stringer
> >> >> <joestringer@nicira.com>
> >> >>
> >> >> wrote:
> >> >> > When userspace doesn't provide a mask, OVS datapath generates a
> >> >> > fully unwildcarded mask for the flow. This is done by taking a
> >> >> > copy of the flow key, then iterating across its attributes,
> >> >> > setting all values to 0xff. This works for most attributes, as the
> >> >> > length of the netlink attribute typically matches the length of
> >> >> > the value. However, IPv6 labels only use the lower 20 bits of the
> >> >> > field. This patch makes a special case to handle this.
> >> >> >
> >> >> > This fixes the following error seen when installing IPv6 flows
> >> >> > without a mask:
> >> >> >
> >> >> > openvswitch: netlink: Invalid IPv6 flow label value
> >> >> > (value=ffffffff, max=fffff)
> >> >>
> >> >> We should allow exact match mask here rather than generating
> >> >> wildcarded mask. So that ovs can catch invalid ipv6.label.
> >> >
> >> > I don't quite follow, I thought this was exact-match? (The existing
> >> > function sets all bits to 1)
> >>
> >> With 0xffffffff value we can exact match on all ipv6.lable bits.
> >
> > The label field is only 20 bits. The other bits in the same word of the
> > IPv6 header are for version (fixed) and traffic class (handled
> > separately). We don't do anything with the other bits.
>
> This is just to make sure that we do not use those field for any thing
> else. Masking those extra bits can hide incorrect ipv6 key extraction.
Oh, I see. I meant something more like:
ipv6_key->ipv6_label &= htonl(0xFFF00000);
ipv6_key->ipv6_label |= htonl(0x000FFFFF);
(Which would propagate the invalid bits from the flow key, but actually produce
an exact match).
^ permalink raw reply
* Re: [PATCH v2] ipv6: delete protocol and unregister rtnetlink when cleanup
From: Cong Wang @ 2014-11-19 19:46 UTC (permalink / raw)
To: Duan Jiong; +Cc: David Miller, netdev, Eric Dumazet
In-Reply-To: <546BF3EB.1080603@cn.fujitsu.com>
On Tue, Nov 18, 2014 at 5:35 PM, Duan Jiong <duanj.fnst@cn.fujitsu.com> wrote:
>
>
> pim6_protocol was added when initiation, but it not deleted.
> Similarly, unregister RTNL_FAMILY_IP6MR rtnetlink.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> ---
> v2: add missing rtnl_unregister()
Reviewed-by: Cong Wang <cwang@twopensource.com>
^ permalink raw reply
* Re: [PATCH net-next] tun: return NET_XMIT_DROP for dropped packets
From: David Miller @ 2014-11-19 19:46 UTC (permalink / raw)
To: jasowang; +Cc: cwang, netdev, linux-kernel, mst
In-Reply-To: <546C0B58.5030402@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Wed, 19 Nov 2014 11:15:36 +0800
> On 11/19/2014 03:53 AM, Cong Wang wrote:
>> On Mon, Nov 17, 2014 at 9:20 PM, Jason Wang <jasowang@redhat.com> wrote:
>>> > After commit 5d097109257c03a71845729f8db6b5770c4bbedc
>>> > ("tun: only queue packets on device"), NETDEV_TX_OK was returned for
>>> > dropped packets. This will confuse pktgen since dropped packets were
>>> > counted as sent ones.
>>> >
>>> > Fixing this by returning NET_XMIT_DROP to let pktgen count it as error
>>> > packet.
>> pktgen is suspicious, it sends out packets directly without going through
>> qdisc, so it should not care about NET_XMIT_* qdisc error code?
>
> Well, NET_XMIT_DROP has been used by some devices. I don't see any side
> effect of using this especially consider that pktgen can recognize them.
>> Looks like NETDEV_TX_OK doesn't have to mean TX is successful,
>> the comment says driver takes care of the packet, can be either dropped
>> or sent out. We might need a new code to distinguish success or failure.
>
> Most drivers only drop bad packets when they return NETDEV_TX_OK and
> they will stop the txq before tx ring is full. This is not the case of
> tun, it never stop txq and keep accepting packets and dropping them when
> socket receive queue is full.
Agreed.
Often the issue with TX return values is lack of clear documentation
and use cases.
I've applied this patch, thanks Jason.
^ permalink raw reply
* Re: [PATCH] ixgbe: Correctly disable vlan filter in promiscuous mode
From: Vlad Yasevich @ 2014-11-19 19:41 UTC (permalink / raw)
To: Tantilov, Emil S, netdev@vger.kernel.org
Cc: Kirsher, Jeffrey T, Keller, Jacob E, Skidmore, Donald C
In-Reply-To: <87618083B2453E4A8714035B62D679925019F38A@FMSMSX105.amr.corp.intel.com>
On 11/18/2014 03:24 PM, Tantilov, Emil S wrote:
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Vladislav Yasevich
>> Sent: Tuesday, November 18, 2014 11:28 AM
>> To: netdev@vger.kernel.org
>> Cc: Vladislav Yasevich; Kirsher, Jeffrey T; Keller, Jacob E
>> Subject: [PATCH] ixgbe: Correctly disable vlan filter in promiscuous mode
>>
>> IXGBE adapater seems to require that vlan filtering be enabled if VMDQ
>> or SRIOV are enabled. When those functions are disabled,
>> vlan filtering may be disabled in promiscuous mode.
>>
>> Prior to commit a9b8943ee129e11045862d6d6e25c5b63c95403c
>> ixgbe: remove vlan_filter_disable and enable functions
>>
>> the logic was correct. However, after the commit the logic
>> got reversed and vlan filtered in now turned on when VMDQ/SRIOV
>> is disabled.
>>
>> This patch changes the condition to enable hw vlan filtered
>> when VMDQ or SRIOV is enabled.
>>
>> Fixes: a9b8943ee129e11045862d6d6e25c5b63c95403c (ixgbe:
>> remove
>> vlan_filter_disable and enable functions)
>> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> CC: Jacob Keller <jacob.e.keller@intel.com>
>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>> ---
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> index d2df4e3..3f81c7a 100644
>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> @@ -3936,8 +3936,8 @@ void ixgbe_set_rx_mode(struct
>> net_device *netdev)
>> * if SR-IOV and VMDQ are disabled - otherwise ensure
>> * that hardware VLAN filters remain enabled.
>> */
>> - if (!(adapter->flags & (IXGBE_FLAG_VMDQ_ENABLED |
>> - IXGBE_FLAG_SRIOV_ENABLED)))
>> + if (adapter->flags & (IXGBE_FLAG_VMDQ_ENABLED |
>> + IXGBE_FLAG_SRIOV_ENABLED))
>> vlnctrl |= (IXGBE_VLNCTRL_VFE |
>> IXGBE_VLNCTRL_CFIEN);
>> } else {
>> if (netdev->flags & IFF_ALLMULTI) {
>
> The current logic is correct and it's like this on purpose as it should be obvious by the comment preceding this check.
Actually the comment right now does not match what the code is doing.
The comment states:
/* Only disable hardware filter vlans in promiscuous mode
* if SR-IOV and VMDQ are disabled - otherwise ensure
* that hardware VLAN filters remain enabled.
*/
However, the code currently will _enable_ vlan filtering if VMDQ/SRIOV
is _disabled_ in promiscuous mode.
> The reason for not disabling the vlan filters in promisc mode is because this can break VLAN isolation between VMs which is considered a security risk.
But VLAN isolation between VMs isn't enforced if you have a simple bridged
setup without VMDQs or SRIOV enabled. Bridge makes all devices promiscuous
and should receive all VLANs.
-vlad
>
> There is another patch that was proposed:
> http://marc.info/?l=linux-netdev&m=141586938625969
>
> which should do what you want using an ethtool toggle.
>
> Thanks,
> Emil
>
>
^ permalink raw reply
* Re: [PATCH net-next 3/4] igb: enable internal PPS for the i210.
From: Keller, Jacob E @ 2014-11-19 19:32 UTC (permalink / raw)
To: richardcochran@gmail.com
Cc: netdev@vger.kernel.org, davem@davemloft.net, Allan, Bruce W,
Ronciak, John, Kirsher, Jeffrey T, Vick, Matthew
In-Reply-To: <20141119063724.GB4109@localhost.localdomain>
On Wed, 2014-11-19 at 07:37 +0100, Richard Cochran wrote:
> On Tue, Nov 18, 2014 at 12:06:24AM +0100, Richard Cochran wrote:
> > --- a/drivers/net/ethernet/intel/igb/igb_main.c
> > +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> > @@ -5386,8 +5386,14 @@ void igb_update_stats(struct igb_adapter *adapter,
> > static void igb_tsync_interrupt(struct igb_adapter *adapter)
> > {
> > struct e1000_hw *hw = &adapter->hw;
> > + struct ptp_clock_event event;
> > u32 tsicr = rd32(E1000_TSICR);
> >
> > + if (tsicr & TSINTR_SYS_WRAP) {
> > + event.type = PTP_CLOCK_PPS;
> > + ptp_clock_event(adapter->ptp_clock, &event);
>
> This causes a BUG for the 82580. When you enable E1000_TSICR_TXTS, it
> seems that TSINTR_SYS_WRAP is also automatically enabled. Because the
> 82580 variant has no pps device enabled, the driver then dereferences
> a null pointer.
>
> So we need to make the call to ptp_clock_event() conditional based on
> whether pps is enabled. I'll fix this in V2.
>
> > + }
> > +
>
> Thanks,
> Richard
Good catch :)
Did you see my concern about the reset path needing to fully restore the
state since it is called after a hardware MAC reset which has cleared
all these registers?
Regards,
Jake
^ permalink raw reply
* Re: [PATCH] net: team: expose sysfs attributes for each team option
From: Daniel Borkmann @ 2014-11-19 19:17 UTC (permalink / raw)
To: Cong Wang; +Cc: Hamad Kadmany, Jiri Pirko, netdev, tgraf
In-Reply-To: <CAHA+R7OOnSfSP1uHrg=osH=+=sb-0Zj-=yYx8HXmpO95v+Dhyg@mail.gmail.com>
On 11/19/2014 07:45 PM, Cong Wang wrote:
> On Wed, Nov 19, 2014 at 4:28 AM, Hamad Kadmany <hkadmany@codeaurora.org> wrote:
>> On Mon, November 17, 2014 1:02 pm, Jiri Pirko wrote:
>>>
>>> Nak.
>>>
>>> I don't like this patch. The plan for team was keep things simple and to
>>> have single userspace api using netlink, as that is the correct way to
>>> deal with things. Sysfs for this use-case is not. Please, use netlink api.
+1
>> Using team driver requires using libnl3. In Android based platforms, libnl3
>> is not supported, and libnl3 license poses constraints in Android's user-space.
Constraints?! libnl3 is LGPL ...
> Check if libmnl fits your license:
> http://www.netfilter.org/projects/libmnl/
... and this one, too.
^ permalink raw reply
* Re: net: sched: Deletion of an unnecessary check before the function call "kfree"
From: Daniel Borkmann @ 2014-11-19 19:09 UTC (permalink / raw)
To: SF Markus Elfring
Cc: John Fastabend, David S. Miller, Jamal Hadi Salim, netdev, LKML,
kernel-janitors
In-Reply-To: <546CE650.6080205@users.sourceforge.net>
On 11/19/2014 07:49 PM, SF Markus Elfring wrote:
>> Marcus, what tree are you looking at?
>
> I dared to base this update suggestion on the source files
> for Linux 3.17.3. Are newer software developments relevant here?
>
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/net/sched/
Pointing to linux-next and saying you based your changes on 3.17.3
is confusing, please look correctly when you provide a link ...
Again, John's commit 1f947bf151e90ec0b removed the relevant part in
cls_bpf_modify_existing() that you're trying to modify:
$ git grep -n bpf_old net/sched/cls_bpf.c
$
Therefore, this patch is not needed.
Thanks !
^ permalink raw reply
* Re: [ovs-dev] [PATCH net] openvswitch: Fix mask generation for IPv6 labels.
From: Pravin Shelar @ 2014-11-19 19:08 UTC (permalink / raw)
To: Joe Stringer; +Cc: dev@openvswitch.org, netdev, LKML
In-Reply-To: <201411190948.11857.joestringer@nicira.com>
On Wed, Nov 19, 2014 at 9:48 AM, Joe Stringer <joestringer@nicira.com> wrote:
> On Wednesday, November 19, 2014 00:11:01 Pravin Shelar wrote:
>> On Tue, Nov 18, 2014 at 11:25 PM, Joe Stringer <joestringer@nicira.com>
> wrote:
>> > On 18 November 2014 22:09, Pravin Shelar <pshelar@nicira.com> wrote:
>> >> On Tue, Nov 18, 2014 at 10:54 AM, Joe Stringer <joestringer@nicira.com>
>> >>
>> >> wrote:
>> >> > When userspace doesn't provide a mask, OVS datapath generates a fully
>> >> > unwildcarded mask for the flow. This is done by taking a copy of the
>> >> > flow key, then iterating across its attributes, setting all values to
>> >> > 0xff. This works for most attributes, as the length of the netlink
>> >> > attribute typically matches the length of the value. However, IPv6
>> >> > labels only use the lower 20 bits of the field. This patch makes a
>> >> > special case to handle this.
>> >> >
>> >> > This fixes the following error seen when installing IPv6 flows without
>> >> > a mask:
>> >> >
>> >> > openvswitch: netlink: Invalid IPv6 flow label value (value=ffffffff,
>> >> > max=fffff)
>> >>
>> >> We should allow exact match mask here rather than generating
>> >> wildcarded mask. So that ovs can catch invalid ipv6.label.
>> >
>> > I don't quite follow, I thought this was exact-match? (The existing
>> > function sets all bits to 1)
>>
>> With 0xffffffff value we can exact match on all ipv6.lable bits.
>
> The label field is only 20 bits. The other bits in the same word of the IPv6
> header are for version (fixed) and traffic class (handled separately). We don't
> do anything with the other bits.
This is just to make sure that we do not use those field for any thing
else. Masking those extra bits can hide incorrect ipv6 key extraction.
^ permalink raw reply
* Re: net: sched: Deletion of an unnecessary check before the function call "kfree"
From: SF Markus Elfring @ 2014-11-19 18:49 UTC (permalink / raw)
To: John Fastabend
Cc: David S. Miller, Jamal Hadi Salim, netdev, LKML, kernel-janitors
In-Reply-To: <546CC9B3.5060405@gmail.com>
> Marcus, what tree are you looking at?
I dared to base this update suggestion on the source files
for Linux 3.17.3. Are newer software developments relevant here?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/net/sched/
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] net: team: expose sysfs attributes for each team option
From: Cong Wang @ 2014-11-19 18:45 UTC (permalink / raw)
To: Hamad Kadmany; +Cc: Jiri Pirko, netdev
In-Reply-To: <03067d01f18e264b30f86d0307d11b07.squirrel@www.codeaurora.org>
On Wed, Nov 19, 2014 at 4:28 AM, Hamad Kadmany <hkadmany@codeaurora.org> wrote:
> On Mon, November 17, 2014 1:02 pm, Jiri Pirko wrote:
>>
>> Nak.
>>
>> I don't like this patch. The plan for team was keep things simple and to
>> have single userspace api using netlink, as that is the correct way to
>> deal with things. Sysfs for this use-case is not. Please, use netlink api.
>
> Using team driver requires using libnl3. In Android based platforms, libnl3 is not supported, and libnl3 license poses constraints in Android's user-space.
>
Check if libmnl fits your license:
http://www.netfilter.org/projects/libmnl/
^ 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