* Re: [PATCH v2 net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
From: Tom Herbert @ 2015-01-15 5:33 UTC (permalink / raw)
To: Sriharsha Basavapatna; +Cc: Linux Netdev List
In-Reply-To: <31318D46B5DF3F4AB71CC057601E9FEB3A7F5178@CMEXMB1.ad.emulex.com>
> I don't understand why this is needed. The only GSO type with with encapsulation allowed by device features SKB_GSO_UDP_TUNNEL. This should not be GRE for instance. Do you see cases where protocol is not UDP at this point?
> [Harsha] It's needed for GRE checksum case; without this, GRE pkts are sent down without checksum by the stack, but HW
> can only offload checksum for VxLAN pkts.
>
Okay, I see that this is a problem with checksum not GSO. Please ask
your hardware guys to provide NETIF_F_HW_CSUM to avoid any more of
this unpleasantness in the future :-)
>> + skb->inner_protocol_type != ENCAP_TYPE_ETHER ||
>> + skb->inner_protocol != htons(ETH_P_TEB) ||
>> + skb_inner_mac_header(skb) - skb_transport_header(skb) !=
>> + sizeof(struct udphdr) + sizeof(struct vxlanhdr))
>> + return features & ~(NETIF_F_ALL_CSUM |
>> + NETIF_F_GSO_MASK);
>> +
>> + return features;
>> }
>> #endif
>>
>> --
>> 1.7.9.5
>>
>> --
>> 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 v2 net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
From: Sriharsha Basavapatna @ 2015-01-15 5:45 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Netdev List
In-Reply-To: <CA+mtBx-tLRi21Sveh-TOmMC0T2cRNqcaEOx2thnqhU-ZLyaN2A@mail.gmail.com>
-----Original Message-----
From: Tom Herbert [mailto:therbert@google.com]
Sent: Thursday, January 15, 2015 11:04 AM
To: Sriharsha Basavapatna
Cc: Linux Netdev List
Subject: Re: [PATCH v2 net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
> I don't understand why this is needed. The only GSO type with with encapsulation allowed by device features SKB_GSO_UDP_TUNNEL. This should not be GRE for instance. Do you see cases where protocol is not UDP at this point?
> [Harsha] It's needed for GRE checksum case; without this, GRE pkts
> are sent down without checksum by the stack, but HW can only offload checksum for VxLAN pkts.
>
Okay, I see that this is a problem with checksum not GSO. Please ask your hardware guys to provide NETIF_F_HW_CSUM to avoid any more of this unpleasantness in the future :-)
[Harsha] Ok, will do :-)
>> + skb->inner_protocol_type != ENCAP_TYPE_ETHER ||
>> + skb->inner_protocol != htons(ETH_P_TEB) ||
>> + skb_inner_mac_header(skb) - skb_transport_header(skb) !=
>> + sizeof(struct udphdr) + sizeof(struct vxlanhdr))
>> + return features & ~(NETIF_F_ALL_CSUM |
>> + NETIF_F_GSO_MASK);
>> +
>> + return features;
>> }
>> #endif
>>
>> --
>> 1.7.9.5
>>
>> --
>> 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
* PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev.
From: Nakashima Akihiro @ 2015-01-15 5:57 UTC (permalink / raw)
To: davem@davemloft.net, netdev@vger.kernel.org
Cc: Ueda Motoki, Otsu Takahiro, Tomono Mitsunori,
linux-kernel@vger.kernel.org
Dear David and networking developers:
I got kernel panic on 3.4.105 kernel.
Please see a report below.
[1.] One line summary of the problem: [3.4] neigh_destroy() crashes on unplug netdev.
[2.] Full description of the problem/report:
I got kernel panic: neigh_destroy() crashes on unplug my wlan dongle. Please see Oops.. message for detail.
I found this problem is occured on kernel 3.4 branch, but kernel 3.6 or later do not have it.
It does not occur on every netdev device, but I think it is not a driver specific problem.
And I found 20 patches that you released on 05-Jul-2012 look effective to solve it.
Patches are below:
01. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a263b3093641fb1ec377582c90986a7fd0625184
02. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3c521f2ba9646c5543963cbc2b9c9d3f02a82594
03. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=60d354ebebd9d0f760cb6c3b9f53a7ade0f8cd0e
04. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5110effee8fde2edfacac9cd12a9960ab2dc39ea
05. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f894cbf847c9bea1955095bf37aca6c050553167
06. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dbedbe6d56e8944f220e34deb9ebdf4bec2a2afd
07. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=178709bbfe9d4fe432c272ed65a34b8582703c23
08. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=24db1ba866eebf5b516df80ea2212d2479bfb502
09. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0b399d46b317a6d0a73ad523e014ecfa4d449769
10. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c473737765c0f72ceb5b245ada7ead798d88b4f6
11. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f9d751667fd60788fe3641738938e0968e99cece
12. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=13a43d94ab026c423dc8902170ef27c2bd36aa87
13. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fccd7d5c77ff61d5283e7ce8242791d5f00dcc17
14. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1d248b1cf4e09dbec8cef5f7fbeda5874248bd09
15. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=534cb283efef9fdbd9f70f4615054d26aa444dd6
16. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=97cac0821af4474ec4ba3a9e7a36b98ed9b6db88
17. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f187bc6efb7250afee0e2009b6106370319b0c8b
18. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1e31fb02b31ba88d5650d97c35eb58f52bfe0e1
19. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36bdbcae2fa2a6dfa99344d4190fcea0aa7b7c25
20. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a2de86f63cfc92f7aaf11e7b9d9f2150946a1622
I applied these patches to 3.4.105 kernel, and confirmed the problem is solved on my box.
Could you confirm and backport them to 3.4 branch?
[3.] Keywords (i.e., modules, networking, kernel): networking
[4.] Kernel version (from /proc/version):
Linux version 3.4.105 (root@JP1201393) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP Tue Jan 13 13:39:40 JST 2015
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
BUG: unable to handle kernel paging request at f87be0ac
IP: [<c1475c5f>] neigh_destroy+0x8f/0x110
*pdpt = 00000000018c0001 *pde = 0000000032f7c067 *pte = 0000000000000000
Oops: 0000 [#1] SMP
Modules linked in: mt7603u_sta(0) nls_iso8859_1 bnep rfcomm bluetooth snd_hda_codec_realtek snd_hda_intel snd_hda_codec i915 snd_hwdep snd_pcm drm_kms_helper binfmt_misc snd_seq_midi drm snd_rawmidi snd_seq_midi_event snd_seq aesni_intel snd_timer snd_seq_device snd cryptd aes_i586 i2c_algo_bit microcode soundcore psmouse video snd_page_alloc serio_raw mac_hid ppdev parport_pc lp parport usbhid hid usb_storage ahci firewire_ohci libahci firewire_core crc_itu_te1000e
Pid: 19, comm: ksoftirqd/3 Tainted: G O 3.4.105 #1 EPSON DIRECT CORP. MR690D0F61/MR6900
EIP: 0060:[<c1475c5f>] EFLAGS: 00010206 CPU: 3
EIP is at neigh_destroy+0x8f/0x110
EAX: f87be000 EBX: f1fd461c ECX: 80150006 EDX: 00000100
ESI: f1fd4600 EDI: ec5ae000 EBP: f2d71ef4 ESP: f2d71edc
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: f87be0ac CR3: 3184b000 CR4: 000407f0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process ksoftirqd/3 (pid: 19, ti=f2d70000 task=f2d68000 task.ti=f2d70000)
Stack:
c1472b23 c1472b23 f1fd4614 ee27b0c0 00000000 00000005 f2d71f0c c1472b95
c1552da3 0000000a ee26a9c0 00000005 f2d71f14 c149292c f2d71f44 c10a80f6
f33bc0e0 0000000a f1b1cc8c f33bc0f8 c17b9ec0 f2d68000 00000000 00000003
Call Trace:
[<c1472b23>] ? dst_destroy+0x43/0xe0
[<c1472b23>] ? dst_destroy+0x43/0xe0
[<c1472b95>] dst_destroy+0xb5/0xe0
[<c1552da3>] ? _raw_spin_unlock_bh+0x13/0x20
[<c149292c>] dst_rcu_free+0x1c/0x30
[<c10a80f6>] __rcu_process_callbacks+0x186/0x310
[<c10a82bc>] rcu_process_callbacks+0x3c/0xc0
[<c1038041>] __do_softirq+0x81/0x190
[<c15533cd>] ? apic_timer_interrupt+0x31/0x38
[<c10381f8>] run_ksoftirqd+0xa8/0x130
[<c1038150>] ? __do_softirq+0x190/0x190
[<c104ff82>] kthread+0x72/0x80
[<c104ff10>] ? flush_kthread_work+0xc0/0xc0
[<c1559ebe>] kernel_thread_helper+0x6/0x10
Code: 40 04 00 00 00 00 89 51 04 89 0a e8 bc a2 fe ff 8b 03 39 c3 75 d6 8b 45 f0 e8 fe d0 0d 00 c7 46 2c 00 00 00 00 8b 87 34 01 00 00 <8b> 90 ac 00 00 00 85 d2 74 04 89 f0 ff d2 8b 87 98 02 00 00 64
EIP: [<c1475c5f>] neigh_destroy+0x8f/0x110 SS:ESP 0068:f2d71edc
CR2: 00000000f87be0ac
Kernel panic - not syncing: Fatal exception in interrupt
panic occurred, switching back to text console
call trace indicate these code line:
<c1475c5f>: net/core/neighbour.c:729
<c1472b23>: net/core/dst.c:250
<c1472b95>: include/net/neighbour.h:294
<c1552da3>: kernel/spinlock.c:194
<c149292c>: include/net/dst.h:385
[6.] A small shell script or example program which triggers the
problem (if possible)
Method to reproduce the problem:
1. run shell script below:
#/bin/sh
while [ true ]
do
ifconfig wlan0 192.168.1.2 up
done
2. unplug and plug a netdev dongle. (repeat)
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
--- ver_linux ---
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux JP1201393 3.4.105 #2 SMP Tue Jan 13 13:39:40 JST 2015 i686 i686 i386 GNU/Linux
Gnu C 4.6
Gnu make 3.81
binutils 2.22
util-linux 2.20.1
mount support
module-init-tools 3.16
e2fsprogs 1.42
pcmciautils 018
PPP 2.4.5
Linux C Library 2.15
Dynamic linker (ldd) 2.15
Procps 3.2.8
Net-tools 1.60
Kbd 1.15.2
Sh-utils 8.13
wireless-tools 30
Modules Loaded mt7603u_sta nls_iso8859_1 rfcomm bnep bluetooth snd_hda_codec_realtek snd_hda_intel snd_hda_codec i915 snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event drm_kms_helper aesni_intel snd_seq drm cryptd psmouse snd_timer snd_seq_device aes_i586 microcode binfmt_misc serio_raw snd soundcore snd_page_alloc i2c_algo_bit mac_hid video ppdev parport_pc lp parport usbhid hid usb_storage ahci libahci e1000e firewire_ohci firewire_core crc_itu_t
[7.2.] Processor information (from /proc/cpuinfo):
I think this is no relationship about the problem.
If it is needed, I will gather it.
[7.3.] Module information (from /proc/modules):
--- /proc/modules ---
mt7603u_sta 1114536 1 - Live 0x00000000 (O)
nls_iso8859_1 12618 1 - Live 0x00000000
rfcomm 57545 0 - Live 0x00000000
bnep 18868 2 - Live 0x00000000
bluetooth 263846 10 rfcomm,bnep, Live 0x00000000
snd_hda_codec_realtek 63163 1 - Live 0x00000000
snd_hda_intel 31907 3 - Live 0x00000000
snd_hda_codec 102579 2 snd_hda_codec_realtek,snd_hda_intel, Live 0x00000000
i915 427399 2 - Live 0x00000000
snd_hwdep 13277 1 snd_hda_codec, Live 0x00000000
snd_pcm 84645 2 snd_hda_intel,snd_hda_codec, Live 0x00000000
snd_seq_midi 13133 0 - Live 0x00000000
snd_rawmidi 25115 1 snd_seq_midi, Live 0x00000000
snd_seq_midi_event 14476 1 snd_seq_midi, Live 0x00000000
drm_kms_helper 45322 1 i915, Live 0x00000000
aesni_intel 18135 0 - Live 0x00000000
snd_seq 55404 2 snd_seq_midi,snd_seq_midi_event, Live 0x00000000
drm 215637 3 i915,drm_kms_helper, Live 0x00000000
cryptd 15580 1 aesni_intel, Live 0x00000000
psmouse 81253 0 - Live 0x00000000
snd_timer 24503 2 snd_pcm,snd_seq, Live 0x00000000
snd_seq_device 14138 3 snd_seq_midi,snd_rawmidi,snd_seq, Live 0x00000000
aes_i586 16996 1 aesni_intel, Live 0x00000000
microcode 18819 0 - Live 0x00000000
binfmt_misc 17208 1 - Live 0x00000000
serio_raw 13156 0 - Live 0x00000000
snd 60917 16 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq_midi,snd_rawmidi,snd_seq,snd_timer,snd_seq_device, Live 0x00000000
soundcore 12601 1 snd, Live 0x00000000
snd_page_alloc 14037 2 snd_hda_intel,snd_pcm, Live 0x00000000
i2c_algo_bit 13198 1 i915, Live 0x00000000
mac_hid 13038 0 - Live 0x00000000
video 18688 1 i915, Live 0x00000000
ppdev 17364 0 - Live 0x00000000
parport_pc 27505 1 - Live 0x00000000
lp 13300 0 - Live 0x00000000
parport 40763 3 ppdev,parport_pc,lp, Live 0x00000000
usbhid 47307 0 - Live 0x00000000
hid 81906 1 usbhid, Live 0x00000000
usb_storage 48081 1 - Live 0x00000000
ahci 25497 2 - Live 0x00000000
libahci 25871 1 ahci, Live 0x00000000
e1000e 175750 0 - Live 0x00000000
firewire_ohci 35480 0 - Live 0x00000000
firewire_core 56954 1 firewire_ohci, Live 0x00000000
crc_itu_t 12628 1 firewire_core, Live 0x00000000
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
--- /proc/ioports ---
0000-03af : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0200-0201 : pnp 00:02
0378-037a : parport0
03b0-03df : PCI Bus 0000:00
03e0-0cf7 : PCI Bus 0000:00
03f8-03ff : serial
0400-0453 : pnp 00:0a
0400-0403 : ACPI PM1a_EVT_BLK
0404-0405 : ACPI PM1a_CNT_BLK
0408-040b : ACPI PM_TMR
0410-0415 : ACPI CPU throttle
0420-042f : ACPI GPE0_BLK
0450-0450 : ACPI PM2_CNT_BLK
0454-0457 : pnp 00:0b
0458-047f : pnp 00:0a
04d0-04d1 : pnp 00:08
0500-057f : pnp 00:0a
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
1180-119f : pnp 00:0a
d000-dfff : PCI Bus 0000:04
d000-d01f : 0000:04:00.0
e000-efff : PCI Bus 0000:03
e000-e0ff : 0000:03:00.0
f000-f03f : 0000:00:02.0
f040-f05f : 0000:00:1f.3
f060-f07f : 0000:00:1f.2
f060-f07f : ahci
f080-f09f : 0000:00:19.0
f0a0-f0a3 : 0000:00:1f.2
f0a0-f0a3 : ahci
f0b0-f0b7 : 0000:00:1f.2
f0b0-f0b7 : ahci
f0c0-f0c3 : 0000:00:1f.2
f0c0-f0c3 : ahci
f0d0-f0d7 : 0000:00:1f.2
f0d0-f0d7 : ahci
--- /proc/iomem ---
00000000-0000ffff : reserved
00010000-0009d7ff : System RAM
0009d800-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000a0000-000bffff : Video RAM area
000c0000-000dffff : PCI Bus 0000:00
000c0000-000cd7ff : Video ROM
000e0000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-1fffffff : System RAM
01000000-0155addd : Kernel code
0155adde-01813f3f : Kernel data
018c0000-0194bfff : Kernel bss
20000000-201fffff : reserved
20200000-3fffffff : System RAM
40000000-401fffff : reserved
40200000-bad8bfff : System RAM
bad8c000-badd8fff : ACPI Non-volatile Storage
badd9000-bade0fff : ACPI Tables
bade1000-badf5fff : reserved
badf6000-badf7fff : System RAM
badf8000-bae04fff : ACPI Non-volatile Storage
bae05000-bae2bfff : reserved
bae2c000-bae6efff : ACPI Non-volatile Storage
bae6f000-baffffff : System RAM
bb000000-bb7fffff : RAM buffer
bb800000-bf9fffff : reserved
bfa00000-ffffffff : PCI Bus 0000:00
d0000000-dfffffff : 0000:00:02.0
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
e0000000-efffffff : pnp 00:01
fe000000-fe3fffff : 0000:00:02.0
fe400000-fe4fffff : PCI Bus 0000:04
fe400000-fe47ffff : 0000:04:00.0
fe400000-fe47ffff : e1000e
fe480000-fe4bffff : 0000:04:00.0
fe4c0000-fe4dffff : 0000:04:00.0
fe4c0000-fe4dffff : e1000e
fe4e0000-fe4e3fff : 0000:04:00.0
fe4e0000-fe4e3fff : e1000e
fe500000-fe5fffff : PCI Bus 0000:03
fe500000-fe5007ff : 0000:03:00.0
fe500000-fe5007ff : firewire_ohci
fe600000-fe61ffff : 0000:00:19.0
fe600000-fe61ffff : e1000e
fe620000-fe623fff : 0000:00:1b.0
fe620000-fe623fff : ICH HD audio
fe624000-fe6240ff : 0000:00:1f.3
fe625000-fe6257ff : 0000:00:1f.2
fe625000-fe6257ff : ahci
fe626000-fe6263ff : 0000:00:1d.0
fe626000-fe6263ff : ehci_hcd
fe627000-fe6273ff : 0000:00:1a.0
fe627000-fe6273ff : ehci_hcd
fe628000-fe628fff : 0000:00:19.0
fe628000-fe628fff : e1000e
fe629000-fe62900f : 0000:00:16.0
fec00000-fec003ff : IOAPIC 0
fed00000-fed003ff : HPET 0
fed08000-fed08fff : pnp 00:0a
fed10000-fed19fff : pnp 00:01
fed1c000-fed1ffff : reserved
fed1c000-fed1ffff : pnp 00:0a
fed20000-fed3ffff : pnp 00:01
fed90000-fed93fff : pnp 00:01
fee00000-fee0ffff : pnp 00:01
fee00000-fee00fff : Local APIC
ff000000-ffffffff : reserved
ff000000-ffffffff : pnp 00:0a
100000000-23f7fffff : System RAM
23f800000-23fffffff : RAM buffer
[7.5.] PCI information ('lspci -vvv' as root)
I think this is no relationship about the problem.
If it is needed, I will gather it.
[7.6.] SCSI information (from /proc/scsi/scsi):
I don't think no relationship about this issue.
If it is needed, I will gather it.
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
[X.] Other notes, patches, fixes, workarounds:
patches I described on [2.] look effective.
Best regards,
Akihiro Nakashima
----------------------------------
NAKASHIMA Akihiro
Nakashima.Akihiro@exc.epson.co.jp
----------------------------------
^ permalink raw reply
* [MERGE] net --> net-next
From: David Miller @ 2015-01-15 6:06 UTC (permalink / raw)
To: netdev
With Linus taking in my bug fixes from 'net' I subsequently merged
his tree into 'net' and the merged 'net' into 'net-next'.
Just FYI...
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: David Miller @ 2015-01-15 6:06 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, david.vrabel
In-Reply-To: <20150115134735.1e4612c6@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 15 Jan 2015 13:47:35 +1100
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/xen-netfront.c between commit 900e183301b5 ("xen-netfront:
> use different locks for Rx and Tx stats") from the net tree and commit
> a55e8bb8fb89 ("xen-netfront: refactor making Tx requests") from the
> net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks a lot Stephen, I just resolved this.
^ permalink raw reply
* Re: [PATCH 0/5 net-next v6] VXLAN Group Policy Extension
From: David Miller @ 2015-01-15 6:12 UTC (permalink / raw)
To: tgraf
Cc: jesse, stephen, pshelar, therbert, alexei.starovoitov,
nicolas.dichtel, netdev, dev
In-Reply-To: <cover.1421290198.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Thu, 15 Jan 2015 03:53:54 +0100
> Implements supports for the Group Policy VXLAN extension [0] to provide
> a lightweight and simple security label mechanism across network peers
> based on VXLAN. The security context and associated metadata is mapped
> to/from skb->mark. This allows further mapping to a SELinux context
> using SECMARK, to implement ACLs directly with nftables, iptables, OVS,
> tc, etc.
>
> The extension is disabled by default and should be run on a distinct
> port in mixed Linux VXLAN VTEP environments. Liberal VXLAN VTEPs
> which ignore unknown reserved bits will be able to receive VXLAN-GBP
> frames.
>
> Simple usage example:
>
> 10.1.1.1:
> # ip link add vxlan0 type vxlan id 10 remote 10.1.1.2 gbp
> # iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark 0x200
>
> 10.1.1.2:
> # ip link add vxlan0 type vxlan id 10 remote 10.1.1.1 gbp
> # iptables -I INPUT -m mark --mark 0x200 -j DROP
>
> iproute2 [1] and OVS [2] support will be provided in separate patches.
>
> [0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy
> [1] https://github.com/tgraf/iproute2/tree/vxlan-gbp
> [2] https://github.com/tgraf/ovs/tree/vxlan-gbp
Applied, thanks a lot Thomas.
^ permalink raw reply
* Re: [PATCH 0/8] netfilter updates for net-next
From: David Miller @ 2015-01-15 6:54 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1421267689-24894-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 14 Jan 2015 21:34:41 +0100
> The following patchset contains netfilter updates for net-next, just a
> bunch of cleanups and small enhancement to selectively flush conntracks
> in ctnetlink, more specifically the patches are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks a lot Pablo.
^ permalink raw reply
* Re: [PATCH v2 net] be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured
From: David Miller @ 2015-01-15 6:55 UTC (permalink / raw)
To: sriharsha.basavapatna; +Cc: netdev
In-Reply-To: <1421318323-2547-1-git-send-email-sriharsha.basavapatna@emulex.com>
From: Sriharsha Basavapatna <sriharsha.basavapatna@emulex.com>
Date: Thu, 15 Jan 2015 16:08:43 +0530
> Other tunnels like GRE break while VxLAN offloads are enabled in Skyhawk-R. To
> avoid this, we should restrict offload features on a per-packet basis in such
> conditions.
>
> Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: core: Fix race by protecting process_queues at CPU hotplug
From: Eric Dumazet @ 2015-01-15 7:01 UTC (permalink / raw)
To: subashab; +Cc: netdev
In-Reply-To: <75547b88b7e2d15b35339a6321c3a929.squirrel@www.codeaurora.org>
On Thu, 2015-01-15 at 03:13 +0000, subashab@codeaurora.org wrote:
> I am seeing frequent crashes in high throughput conditions in a
> multiprocessor system with kernel version 3.10 where cores are getting hot
> plugged. I have pinned the network stack to a particular core using
> receive packet steering (RPS). At the time of crash, it looks like a
> contention of the process_queue between dev_cpu_callback and
> process_backlog.
Your patch is mangled, hard to tell what is going on.
^ permalink raw reply
* Re: PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev.
From: Eric Dumazet @ 2015-01-15 7:03 UTC (permalink / raw)
To: Nakashima Akihiro
Cc: davem@davemloft.net, netdev@vger.kernel.org, Ueda Motoki,
Otsu Takahiro, Tomono Mitsunori, linux-kernel@vger.kernel.org
In-Reply-To: <E694983F62A0954788A62E997021A9C31093E1@JPEX011.apo.epson.net>
On Thu, 2015-01-15 at 05:57 +0000, Nakashima Akihiro wrote:
> Dear David and networking developers:
>
> I got kernel panic on 3.4.105 kernel.
> Please see a report below.
Please try a recent kernel.
We are not going to debug such an old one, given there are chances we
already fixed the problem ages ago.
Thanks
^ permalink raw reply
* Re: [patch net] team: avoid possible underflow of count_pending value for notify_peers and mcast_rejoin
From: Jiri Pirko @ 2015-01-15 7:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jbenc
In-Reply-To: <20150114.165509.1466571325244320266.davem@davemloft.net>
Wed, Jan 14, 2015 at 10:55:09PM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Wed, 14 Jan 2015 18:15:30 +0100
>
>> This patch is fixing a race condition that may cause setting
>> count_pending to -1, which results in unwanted big bulk of arp messages
>> (in case of "notify peers").
>>
>> Consider following scenario:
> ...
>> Fix this race by using atomic_dec_if_positive - that will prevent
>> count_pending running under 0.
>>
>> Fixes: fc423ff00df3a1955441 ("team: add peer notification")
>> Fixes: 492b200efdd20b8fcfd ("team: add support for sending multicast rejoins")
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> Signed-off-by: Jiri Benc <jbenc@redhat.com>
>
>Applied, thanks.
>
>I am assuming that v3.12 and later need this fix, therefore I'm queueing it up for
>-stable.
Yes, thanks!
^ permalink raw reply
* Re: [patch-net-next v2 3/3] net: ethernet: cpsw: don't requests IRQs we don't use
From: Mugunthan V N @ 2015-01-15 7:49 UTC (permalink / raw)
To: Felipe Balbi, davem; +Cc: Tony Lindgren, Linux OMAP Mailing List, netdev
In-Reply-To: <1421254729-10602-3-git-send-email-balbi@ti.com>
On Wednesday 14 January 2015 10:28 PM, Felipe Balbi wrote:
> CPSW never uses RX_THRESHOLD or MISC interrupts. In
> fact, they are always kept masked in their appropriate
> IRQ Enable register.
>
> Instead of allocating an IRQ that never fires, it's best
> to remove that code altogether and let future patches
> implement it if anybody needs those.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
Instead of introducing dummy ISR in previous patch and then removing in
this patch, both can be squashed into a single patch.
Regards
Mugunthan V N
^ permalink raw reply
* RE: PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev.
From: Nakashima Akihiro @ 2015-01-15 7:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem@davemloft.net, netdev@vger.kernel.org, Ueda Motoki,
Otsu Takahiro, Tomono Mitsunori, linux-kernel@vger.kernel.org
In-Reply-To: <1421305399.11734.40.camel@edumazet-glaptop2.roam.corp.google.com>
Dear Eric:
3.6 or later kernels (including recent mainline) do not have this problem.
3.4.105 is based on an old kernel, but it is a latest kernel of 3.4 LTS branch.
I think it is better to backport 20 patches to LTS branch.
But if you do not have such support policy, I will apply these patches to my 3.4 kernel only.
Thanks
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: Thursday, January 15, 2015 4:03 PM
To: Nakashima Akihiro
Cc: davem@davemloft.net; netdev@vger.kernel.org; Ueda Motoki; Otsu Takahiro; Tomono Mitsunori; linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev.
On Thu, 2015-01-15 at 05:57 +0000, Nakashima Akihiro wrote:
> Dear David and networking developers:
>
> I got kernel panic on 3.4.105 kernel.
> Please see a report below.
Please try a recent kernel.
We are not going to debug such an old one, given there are chances we already fixed the problem ages ago.
Thanks
^ permalink raw reply
* Re: [PATCH] ethernet: atheros: Add nss-gmac driver
From: wstephen-sgV2jX0FEOL9JmXXK+q4OQ @ 2015-01-15 8:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Wang, jcliburn-Re5JQEeQqe8AvxtiuMwx3w,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5550127.3sXOcCISZN@wuerfel>
Hi Arnd, Francois
The nss-gmac driver is for the internal GMAC IP in the Qualcomm IPQ806x
SoC. There are 2 ARM cores and 2 NSS cores inside the IPQ806x SoC. The
main purpose of these NSS cores is to offload the networking stack from
the ARM cores to achieve high performance at routing/ipsec..etc without
exhausting the ARM core CPU cycles. There is another nss-drv driver for
the NSS cores.
The nss-gmac driver is designed to work standalone or with the nss-drv
driver so the switchable data plane overlay was implemented. When it
worked standalone, the data plane is running on the ARM core as a standard
networking driver. The nss-drv driver can take over the data plane and
offload it to the NSS cores. The STMicro stmmac driver does not have this
kind of overlay design so is not suitable for IPQ806x. This is why we
don't based on the stmmac driver
Thanks,
Stephen
>> diff --git a/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt
>> b/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt
>> new file mode 100644
>> index 0000000..806f2e6
>> --- /dev/null
>> +++ b/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt
>> @@ -0,0 +1,14 @@
>> +Linux Driver for 3504 DWC Ether MAC 10/100/1000 Universal
>> +Linux Driver for 3507 DWC Ether MAC 10/100 Universal
>> +
>> +IMPORTANT: Synopsys Ethernet MAC Linux Software Drivers and
>> documentation (hereinafter, "Software") are unsupported proprietary
>> works of Synopsys, Inc. unless otherwise expressly agreed to in writing
>> between Synopsys and you.
>> +
>> +The Software uses certain Linux kernel functionality and may therefore
>> be subject to the GNU Public License which is available at:
>> +http://www.gnu.org/licenses/gpl.html
>
> It sounds like this one is related to the dwmac driver in
> drivers/net/ethernet/stmicro/stmmac/. Please move the code into
> the same directory and reuse as much as you can.
>
> If this is a completely unrelated part, it should probably go
> into drivers/net/ethernet/designware or drivers/net/ethernet/synopsys.
>
>> +#ifdef CONFIG_OF
>> +#include <msm_nss_gmac.h>
>> +#else
>> +#include <mach/msm_nss_gmac.h>
>> +#endif
>
> Drop the non-CONFIG_OF part here and elsewhere, we don't support
> separate platform directories any more, and mach-qcom is already
> DT-only.
>
>> +/**********************************************************
>> + * GMAC registers Map
>> + * For Pci based system address is BARx + gmac_register_base
>> + * For any other system translation is done accordingly
>> + **********************************************************/
>> +enum gmac_registers {
>> + gmac_config = 0x0000, /* Mac config Register */
>> + gmac_frame_filter = 0x0004, /* Mac frame filtering controls */
>> + gmac_hash_high = 0x0008, /* Multi-cast hash table high */
>> + gmac_hash_low = 0x000c, /* Multi-cast hash table low */
>> + gmac_gmii_addr = 0x0010, /* GMII address Register(ext. Phy) */
>> + gmac_gmii_data = 0x0014, /* GMII data Register(ext. Phy) */
>> + gmac_flow_control = 0x0018, /* Flow control Register */
>> + gmac_vlan = 0x001c, /* VLAN tag Register (IEEE 802.1Q) */
>> + gmac_version = 0x0020, /* GMAC Core Version Register */
>> + gmac_wakeup_addr = 0x0028, /* GMAC wake-up frame filter adrress
>> + reg */
>
> This looks a lot like dwmac1000 as well.
>
>> + if (of_property_read_u32(np, "qcom,id", &gmacdev->macid)
>> + || of_property_read_u32(np, "qcom,emulation", &gmaccfg->emulation)
>> + || of_property_read_u32(np, "qcom,phy_mii_type",
>> &gmaccfg->phy_mii_type)
>> + || of_property_read_u32(np, "qcom,phy_mdio_addr",
>> &gmaccfg->phy_mdio_addr)
>> + || of_property_read_u32(np, "qcom,rgmii_delay",
>> &gmaccfg->rgmii_delay)
>> + || of_property_read_u32(np, "qcom,poll_required",
>> &gmaccfg->poll_required)
>> + || of_property_read_u32(np, "qcom,forced_speed",
>> &gmaccfg->forced_speed)
>> + || of_property_read_u32(np, "qcom,forced_duplex",
>> &gmaccfg->forced_duplex)
>> + || of_property_read_u32(np, "qcom,irq", &netdev->irq)
>> + || of_property_read_u32(np, "qcom,socver", &gmaccfg->socver)) {
>
> This is not an acceptable way to pass data from DT, please use the
> standard properties.
>
>> + if (test_bit(__NSS_GMAC_LINKPOLL, &gmacdev->flags)) {
>> +#if (LINUX_VERSION_CODE <= KERNEL_VERSION(3, 8, 0))
>> + gmacdev->phydev = phy_connect(netdev, (const char *)phy_id,
>> + &nss_gmac_adjust_link, 0, phyif);
>> +#else
>> + gmacdev->phydev = phy_connect(netdev, (const char *)phy_id,
>> + &nss_gmac_adjust_link, phyif);
>> +#endif
>
> Drop all LINUX_VERSION_CODE checks
>
>> + if (IS_ERR_OR_NULL(gmacdev->phydev)) {
>> + netdev_dbg(netdev, "PHY %s attach FAIL", phy_id);
>> + ret = -EIO;
>> + goto nss_gmac_phy_attach_fail;
>> + }
>
> Also any IS_ERR_OR_NULL checks, you are using the API incorrectly.
>
>> +static struct of_device_id nss_gmac_dt_ids[] = {
>> + { .compatible = "qcom,nss-gmac0" },
>> + { .compatible = "qcom,nss-gmac1" },
>> + { .compatible = "qcom,nss-gmac2" },
>> + { .compatible = "qcom,nss-gmac3" },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, nss_gmac_dt_ids);
>
> Are all four versions supported by this driver?
>
> Each one of these needs its own devicetree binding that documents which
> hardware it is for and what the supported DT properties are.
>
>> +static struct platform_driver nss_gmac_drv = {
>> + .probe = nss_gmac_probe,
>> + .remove = nss_gmac_remove,
>> + .driver = {
>> + .name = "nss-gmac",
>> + .owner = THIS_MODULE,
>> +#ifdef CONFIG_OF
>> + .of_match_table = of_match_ptr(nss_gmac_dt_ids),
>> +#endif
>
> The redundancy here is redundant and unnecessary.
>
>> +
>> +/**
>> + * @brief IOCTL interface.
>> + * This function is mainly for debugging purpose.
>> + * This provides hooks for Register read write, Retrieve descriptor
>> status
>> + * and Retreiving Device structure information.
>> + * @param[in] pointer to net_device structure.
>> + * @param[in] pointer to ifreq structure.
>> + * @param[in] ioctl command.
>> + * @return Returns 0 on success Error code on failure.
>> + */
>> +static int32_t nss_gmac_linux_do_ioctl(struct net_device *netdev,
>> + struct ifreq *ifr, int32_t cmd)
>> +{
>
> Remove the private ioctls.
>
>> +/**
>> + * @brief Stats Callback to receive statistics from NSS
>> + * @param[in] pointer to gmac context
>> + * @param[in] pointer to gmac statistics
>> + * @return Returns void.
>> + */
>> +static void nss_gmac_stats_receive(struct nss_gmac_dev *gmacdev,
>> + struct nss_gmac_stats *gstat)
>> +{
> ...
>> +}
>> +EXPORT_SYMBOL(nss_gmac_receive);
>
> Why multiple modules instead of linking everything together?
>
>> +
>> +/**
>> + * NSS Driver interface APIs
>> + */
>
> What is an NSS driver?
>
>> +/*
>> + * nss_gmac_open_work()
>> + * Schedule delayed work to open the netdev again
>> + */
>> +void nss_gmac_open_work(struct work_struct *work)
>> +{
>> + struct nss_gmac_dev *gmacdev = container_of(to_delayed_work(work),
>> + struct nss_gmac_dev, gmacwork);
>> +
>> + netdev_dbg(gmacdev->netdev, "Do the network up in delayed queue %s\n",
>> + gmacdev->netdev->name);
>> + nss_gmac_linux_open(gmacdev->netdev);
>> +}
>
> You seem to have an operating system abstraction layer in here. We know
> which OS we are running on, so please remove the abstraction.
>
> Arnd
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] [PATCH] net: sxgbe: Fix waring for double kfree()
From: Dan Carpenter @ 2015-01-15 8:12 UTC (permalink / raw)
To: Kukjin Kim; +Cc: netdev, Dave Miller, Byungho An
In-Reply-To: <1421286191-9550-1-git-send-email-kgene@kernel.org>
On Thu, Jan 15, 2015 at 10:43:11AM +0900, Kukjin Kim wrote:
> rx_ring->rx_skbuff = kmalloc_array(rx_rsize,
> sizeof(struct sk_buff *), GFP_KERNEL);
> - if (rx_ring->rx_skbuff == NULL)
> - goto rxbuff_err;
> + if (!rx_ring->rx_skbuff) {
This is missing a dma_free_coherent() here.
> + kfree(rx_ring->rx_skbuff_dma);
> + goto error;
> + }
>
> /* initialise the buffers */
> for (desc_index = 0; desc_index < rx_rsize; desc_index++) {
> @@ -502,13 +508,6 @@ static int init_rx_ring(struct net_device *dev, u8 queue_no,
> err_init_rx_buffers:
> while (--desc_index >= 0)
> free_rx_ring(priv->device, rx_ring, desc_index);
> - kfree(rx_ring->rx_skbuff);
The double free bug is that free_rx_ring() frees
kfree(rx_ring->rx_skbuff_dma); and kfree(rx_ring->rx_skbuff); so just
calling it in a loop here will cause a double free.
Also free_rx_ring() doesn't take an index parameter, it takes a size
parameter.
The right way to fix this is to create a release function that mirrors
sxgbe_init_rx_buffers().
static void sxgbe_free_rx_buffers(struct net_device *dev,
struct sxgbe_rx_norm_desc *p, int i,
unsigned int dma_buf_sz,
struct sxgbe_rx_queue *rx_ring)
{
struct sxgbe_priv_data *priv = netdev_priv(dev);
kfree_skb(rx_ring->rx_skbuff[i]);
dma_unmap_single(priv->device, rx_ring->rx_skbuff_dma[i],
dma_buf_sz, DMA_FROM_DEVICE);
}
Then just swap that into the free loop instead of the free_rx_ring().
err_init_rx_buffers:
while (--desc_index >= 0) {
struct sxgbe_rx_norm_desc *p;
p = rx_ring->dma_rx + desc_index;
sxgbe_init_rx_buffers(dev, p, desc_index, bfsize, rx_ring);
}
kfree(rx_ring->rx_skbuff);
Something like that.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH net-next v13 0/3] add hisilicon hip04 ethernet driver
From: Ding Tianhong @ 2015-01-15 8:37 UTC (permalink / raw)
To: Alexander Graf, arnd, robh+dt, davem, grant.likely
Cc: sergei.shtylyov, linux-arm-kernel, eric.dumazet, xuwei5,
zhangfei.gao, netdev, devicetree, linux
In-Reply-To: <54B642B4.8010807@suse.de>
On 2015/1/14 18:19, Alexander Graf wrote:
>
>
> On 14.01.15 07:34, Ding Tianhong wrote:
>> v13:
>> - Fix the problem of alignment parameters for function and checkpatch warming.
>>
>> v12:
>> - According Alex's suggestion, modify the changelog and add MODULE_DEVICE_TABLE
>> for hip04 ethernet.
>>
>> v11:
>> - Add ethtool support for tx coalecse getting and setting, the xmit_more
>> is not supported for this patch, but I think it could work for hip04,
>> will support it later after some tests for performance better.
>>
>> Here are some performance test results by ping and iperf(add tx_coalesce_frames/users),
>> it looks that the performance and latency is more better by tx_coalesce_frames/usecs.
>>
>> - Before:
>> $ ping 192.168.1.1 ...
>> === 192.168.1.1 ping statistics ===
>> 24 packets transmitted, 24 received, 0% packet loss, time 22999ms
>> rtt min/avg/max/mdev = 0.180/0.202/0.403/0.043 ms
>>
>> $ iperf -c 192.168.1.1 ...
>> [ ID] Interval Transfer Bandwidth
>> [ 3] 0.0- 1.0 sec 115 MBytes 945 Mbits/sec
>>
>> - After:
>> $ ping 192.168.1.1 ...
>> === 192.168.1.1 ping statistics ===
>> 24 packets transmitted, 24 received, 0% packet loss, time 22999ms
>> rtt min/avg/max/mdev = 0.178/0.190/0.380/0.041 ms
>>
>> $ iperf -c 192.168.1.1 ...
>> [ ID] Interval Transfer Bandwidth
>> [ 3] 0.0- 1.0 sec 115 MBytes 965 Mbits/sec
>
> Using v11 on top of 3.18 and after generating some traffic on the
> network as well as compiling code on ahci in parallel I ran into the
> following OOPS. Any idea what exactly is going on?
>
>>From a 10000 feet perspective it looks like two problems to me
>
> 1) Allocation failure doesn't get handled properly somewhere
> 2) We fail to allocate with order=0 - I don't see why
>
is it easy to repetition this bug? how big is your memory on your board, is it happened in your previous hip04 driver?
ding
>
> Alex
>
>
> [44085.652301] ld: page allocation failure: order:0, mode:0x120
> [44085.671314] CPU: 0 PID: 5121 Comm: ld Not tainted 3.18.0-5-lpae #1
> [44085.692110] [<c0335814>] (unwind_backtrace) from [<c032fcc8>]
> (show_stack+0x18/0x1c)
> [44085.718109] [<c032fcc8>] (show_stack) from [<c0a50afc>]
> (dump_stack+0x88/0x98)
> [44085.742360] [<c0a50afc>] (dump_stack) from [<c0443f98>]
> (warn_alloc_failed+0xdc/0x124)
> [44085.768938] [<c0443f98>] (warn_alloc_failed) from [<c04469ec>]
> (__alloc_pages_nodemask+0x7ac/0xa8c)
> [44085.799305] [<c04469ec>] (__alloc_pages_nodemask) from [<c0959a88>]
> (__netdev_alloc_frag+0xac/0x17c)
> [44085.829994] [<c0959a88>] (__netdev_alloc_frag) from [<bf00051c>]
> (hip04_rx_poll+0x168/0x3cc [hip04_eth])
> [44085.861830] [<bf00051c>] (hip04_rx_poll [hip04_eth]) from
> [<c096c0fc>] (net_rx_action+0x15c/0x258)
> [44085.891897] [<c096c0fc>] (net_rx_action) from [<c0369508>]
> (__do_softirq+0x138/0x2dc)
> [44085.918171] [<c0369508>] (__do_softirq) from [<c0369920>]
> (irq_exit+0x80/0xb8)
> [44085.942408] [<c0369920>] (irq_exit) from [<c03b3ee0>]
> (__handle_domain_irq+0x68/0xa8)
> [44085.968685] [<c03b3ee0>] (__handle_domain_irq) from [<c03086ac>]
> (hip04_handle_irq+0x38/0x68)
> [44085.997296] [<c03086ac>] (hip04_handle_irq) from [<c0a56d48>]
> (__irq_usr+0x48/0x60)
> [44086.022977] Exception stack(0xd3fbbfb0 to 0xd3fbbff8)
> [44086.039925] bfa0: 03fa94f8
> 01fc2598 01fc2598 00000000
> [44086.067357] bfc0: 03fa9458 40482000 00000000 400878b0 004e46e8
> 00000040 01f61f80 00000013
> [44086.094785] bfe0: fbad2488 bed4c270 403aeb5c 403bbe84 200e0010 ffffffff
> [44086.116970] Mem-info:
> [44086.124597] DMA per-cpu:
> [44086.133098] CPU 0: hi: 186, btch: 31 usd: 191
> [44086.149167] HighMem per-cpu:
> [44086.158829] CPU 0: hi: 186, btch: 31 usd: 10
> [44086.174919] active_anon:78994 inactive_anon:57435 isolated_anon:0
> [44086.174919] active_file:721847 inactive_file:559931 isolated_file:0
> [44086.174919] unevictable:20 dirty:567 writeback:0 unstable:0
> [44086.174919] free:2674014 slab_reclaimable:41072 slab_unreclaimable:5704
> [44086.174919] mapped:13107 shmem:42709 pagetables:933 bounce:0
> [44086.174919] free_cma:16216
> [44086.286552] DMA free:1088kB min:3012kB low:3764kB high:4516kB
> active_anon:584kB inactive_anon:2948kB active_file:183224kB
> inactive_file:183268kB unevictable:16kB isolated(anon):0kB
> isolated(file):0kB present:778240kB managed:569024kB mlocked:16kB
> dirty:28kB writeback:0kB mapped:864kB shmem:2948kB
> slab_reclaimable:164288kB slab_unreclaimable:22816kB kernel_stack:776kB
> pagetables:3732kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB
> pages_scanned:0 all_unreclaimable? no
> [44086.427835] lowmem_reserve[]: 0 0 15624 15624
> [44086.442687] HighMem free:10694968kB min:512kB low:21708kB
> high:42908kB active_anon:315392kB inactive_anon:226792kB
> active_file:2704164kB inactive_file:2056456kB unevictable:64kB
> isolated(anon):0kB isolated(file):0kB present:15998976kB
> managed:15998976kB mlocked:64kB dirty:2240kB writeback:0kB
> mapped:51564kB shmem:167888kB slab_reclaimable:0kB
> slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB
> bounce:59318392kB free_cma:64864kB writeback_tmp:0kB pages_scanned:0
> all_unreclaimable? no
> [44086.590672] lowmem_reserve[]: 0 0 0 0
> [44086.603158] DMA: 0*4kB 0*8kB 0*16kB 0*32kB 1*64kB (R) 0*128kB 0*256kB
> 0*512kB 1*1024kB (R) 0*2048kB 0*4096kB = 1088kB
> [44086.639330] HighMem: 6*4kB (UMC) 2*8kB (U) 3*16kB (UMC) 5*32kB (UC)
> 3*64kB (UMC) 1*128kB (C) 1*256kB (M) 57*512kB (UM) 25*1024kB (UMC)
> 7*2048kB (UMC) 2594*4096kB (MRC) = 10694968kB
> [44086.694225] Node 0 hugepages_total=0 hugepages_free=0
> hugepages_surp=0 hugepages_size=2048kB
> [44086.722524] 1324446 total pagecache pages
> [44086.735973] 33 pages in swap cache
> [44086.747384] Swap cache stats: add 741, delete 708, find 0/0
> [44086.766072] Free swap = 497068kB
> [44086.777185] Total swap = 500032kB
> [44087.151253] 4194304 pages of RAM
> [44087.162085] 2674498 free pages
> [44087.172327] 52304 reserved pages
> [44087.183150] 46573 slab pages
> [44087.192810] 1004058 pages shared
> [44087.203632] 33 pages swap cached
> [44087.217489] Unable to handle kernel paging request at virtual address
> b0000000
> [44087.241776] pgd = c0303000
> [44087.250887] [b0000000] *pgd=80000010306003, *pmd=00000000
> [44087.269133] Internal error: Oops: 2a06 [#1] SMP ARM
> [44087.285499] Modules linked in: fuse dm_mod uio_pdrv_genirq uio
> nls_iso8859_1 nls_cp437 vfat fat sg st sr_mod cdrom af_packet squashfs
> loop virtio_blk virtio_ring virtio brd marvell ahci_platform
> libahci_platform libahci hip04_mdio gpio_dwapb hip04_eth [last unloaded:
> dm_mod]
> [44087.368299] CPU: 0 PID: 9 Comm: rcuos/0 Not tainted 3.18.0-5-lpae #1
> [44087.389614] task: e88a46c0 ti: e88ac000 task.ti: e88ac000
> [44087.407749] PC is at v7_dma_inv_range+0x34/0x4c
> [44087.422951] LR is at dma_cache_maint_page+0x9c/0x118
> [44087.439609] pc : [<c0340b94>] lr : [<c033a67c>] psr: 400e0013
> [44087.439609] sp : e88addc0 ip : c0340c2c fp : 00000002
> [44087.478104] r10: 00000000 r9 : c0e73580 r8 : c0e778c4
> [44087.495630] r7 : c0fdfb80 r6 : c0f20780 r5 : 00000000 r4 : 00000640
> [44087.517524] r3 : 0000003f r2 : 00000040 r1 : b0000640 r0 : b0000000
> [44087.539424] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM
> Segment kernel
> [44087.563939] Control: 30c5387d Table: 21305b40 DAC: fffffffd
> [44087.583213] Process rcuos/0 (pid: 9, stack limit = 0xe88ac238)
> [44087.602777] Stack: (0xe88addc0 to 0xe88ae000)
> [44087.617398] ddc0: 00000000 00000000 e88a4708 e8ae059c e8ae0000
> c0e778c4 c0fdfb80 00000640
> [44087.644829] dde0: 00000000 df7f9000 00000002 c033a91c c0340c2c
> 00000700 df9da740 e8ae059c
> [44087.672259] de00: e8ae0000 000012ac 00000038 db903700 e8ae02d8
> c0fdfb80 00000001 bf000498
> [44087.699689] de20: 00000640 00000002 00000000 c0e9c5b0 e88ac000
> 00000101 c0e7ab04 00000000
> [44087.727119] de40: 00000040 bf001e28 c0f77800 e8ae059c 00000000
> 00000040 0000012c df9da740
> [44087.754549] de60: c0e6d100 00000101 e88ac000 c096c0fc c0f245e4
> df9da748 007aae3c e88ac000
> [44087.781978] de80: c0f26038 c0f2410d e88a5850 00000003 c0e6d08c
> 00000002 e88ac000 00000002
> [44087.809407] dea0: c0f24314 00000101 e1f4d4c0 c0369508 00000000
> c0e94fd4 0000000c c0e6d080
> [44087.836837] dec0: c0e65448 0000000a c0f34000 c0e6d100 007aae3b
> e88ac030 c0a62b84 00208040
> [44087.864266] dee0: a00e0013 600e0013 df9d7680 000001ff 00000001
> df9d7744 00000000 c0e73630
> [44087.891696] df00: e1f4d4c0 c036976c e88ac010 c0369830 db903700
> df9d7680 e88ac000 c03bc8cc
> [44087.919125] df20: 00000000 d3fedb80 000b7df0 00000000 e88a46c0
> c039db48 e88adf38 e88adf38
> [44087.946554] df40: 00000000 e8838940 00000000 df9d7680 c03bc74c
> 00000000 00000000 00000000
> [44087.973984] df60: 00000000 c0380398 00000000 00000000 00000001
> df9d7680 00000000 00000000
> [44088.001413] df80: e88adf80 e88adf80 00000000 00000000 e88adf90
> e88adf90 e88adfac e8838940
> [44088.028843] dfa0: c03802b8 00000000 00000000 c032bbc8 00000000
> 00000000 00000000 00000000
> [44088.056272] dfc0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> [44088.083701] dfe0: 00000000 00000000 00000000 00000000 00000013
> 00000000 e88adff4 00000000
> [44088.111150] [<c0340b94>] (v7_dma_inv_range) from [<c033a67c>]
> (dma_cache_maint_page+0x9c/0x118)
> [44088.140339] [<c033a67c>] (dma_cache_maint_page) from [<c033a91c>]
> (__dma_page_dev_to_cpu+0x90/0x110)
> [44088.170996] [<c033a91c>] (__dma_page_dev_to_cpu) from [<bf000498>]
> (hip04_rx_poll+0xe4/0x3cc [hip04_eth])
> [44088.203119] [<bf000498>] (hip04_rx_poll [hip04_eth]) from
> [<c096c0fc>] (net_rx_action+0x15c/0x258)
> [44088.233185] [<c096c0fc>] (net_rx_action) from [<c0369508>]
> (__do_softirq+0x138/0x2dc)
> [44088.259457] [<c0369508>] (__do_softirq) from [<c036976c>]
> (do_softirq+0x5c/0x64)
> [44088.284270] [<c036976c>] (do_softirq) from [<c0369830>]
> (__local_bh_enable_ip+0xbc/0xc0)
> [44088.311428] [<c0369830>] (__local_bh_enable_ip) from [<c03bc8cc>]
> (rcu_nocb_kthread+0x180/0x5bc)
> [44088.340910] [<c03bc8cc>] (rcu_nocb_kthread) from [<c0380398>]
> (kthread+0xe0/0xf8)
> [44088.366026] [<c0380398>] (kthread) from [<c032bbc8>]
> (ret_from_fork+0x14/0x20)
> [44088.390260] Code: 1e070f3e e1110003 e1c11003 1e071f3e (ee070f36)
> [44088.410808] ---[ end trace ccf8b617d193d373 ]---
> [44088.426324] Kernel panic - not syncing: Fatal exception in interrupt
> [44088.447652] Rebooting in 100 seconds..Reboot failed -- System halted
>
> .
>
^ permalink raw reply
* Re: [ 2375.793397] WARNING: CPU: 0 PID: 1149 at net/netlink/genetlink.c:1037 genl_unbind+0xc0/0xd0()
From: Johannes Berg @ 2015-01-15 8:37 UTC (permalink / raw)
To: Jeff Layton; +Cc: netdev
In-Reply-To: <20150114212039.68c9a5a6@synchrony.poochiereds.net>
On Wed, 2015-01-14 at 21:20 -0500, Jeff Layton wrote:
> > Ok - after long deliberation I found a way to trigger it. It requires
> > that you leave a multicast group (likely by destroying a socket) at the
> > same time as the kernel unregisters the generic netlink group. I have no
> > idea what generic netlink group you might be using here, but I could
> > reproduce it with a strategically placed delay in the netlink code and
> > the nl80211 genl group by opening a socket, closing the socket, and
> > removing the cfg80211 module (to unregister the nl80211 genl group)
> > while the socket was still being closed.
> >
> > I'll think about a fix tomorrow - it doesn't seem trivial due to
> > possible locking concerns.
> FWIW, it popped around a dozen times or so?
Yeah it would pop up for every multicast group that any socket you owned
while closing the program (which of course closes the sockets) would
have opened on that genl family.
The thing that confuses me is how you managed to unregister a genl
family at literally the same time, but I cannot find - from code review
- a way to trigger it without that. If the family goes away cleanly
before then the groups of all open sockets are cleared so it can't
happen, and if the family is still alive when the socket is closed then
of course it also can't happen.
> Unfortunately, I didn't save the logs from the run. I'll try to
> reproduce it again tomorrow (and save the logs this time), but I don't
> see it every time.
If you do manage to do that it would be great to confirm that it is
indeed the scenario I found (and reproduced).
Thanks,
johannes
^ permalink raw reply
* [patch net-next v5 1/2] tc: add BPF based action
From: Jiri Pirko @ 2015-01-15 8:52 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, dborkman, ast, hannes, gaofeng
This action provides a possibility to exec custom BPF code.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
v4->v5:
- fixed typo in Kconfig spotted out by Gao
v3->v4:
- fixed Kconfig typo spotted out by Daniel
- added some desc to Kconfig suggested by Daniel
- fixed code flow in tcf_bpf to avoid gotos suggested by Daniel
- drop retval changed from -1 to 0 as suggested by Daniel and agreed by Alexei
- added a little comment to tcf_bpf drop code as suggested by Daniel
v2->v3:
- s/bpf_len/bpf_num_ops/ per DaveM's suggestion
v1->v2:
- fixed error path in _init
- added cleanup function to kill filter prog
---
include/net/tc_act/tc_bpf.h | 25 +++++
include/uapi/linux/tc_act/Kbuild | 1 +
include/uapi/linux/tc_act/tc_bpf.h | 31 ++++++
net/sched/Kconfig | 12 +++
net/sched/Makefile | 1 +
net/sched/act_bpf.c | 205 +++++++++++++++++++++++++++++++++++++
6 files changed, 275 insertions(+)
create mode 100644 include/net/tc_act/tc_bpf.h
create mode 100644 include/uapi/linux/tc_act/tc_bpf.h
create mode 100644 net/sched/act_bpf.c
diff --git a/include/net/tc_act/tc_bpf.h b/include/net/tc_act/tc_bpf.h
new file mode 100644
index 0000000..86a070f
--- /dev/null
+++ b/include/net/tc_act/tc_bpf.h
@@ -0,0 +1,25 @@
+/*
+ * Copyright (c) 2015 Jiri Pirko <jiri@resnulli.us>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __NET_TC_BPF_H
+#define __NET_TC_BPF_H
+
+#include <linux/filter.h>
+#include <net/act_api.h>
+
+struct tcf_bpf {
+ struct tcf_common common;
+ struct bpf_prog *filter;
+ struct sock_filter *bpf_ops;
+ u16 bpf_num_ops;
+};
+#define to_bpf(a) \
+ container_of(a->priv, struct tcf_bpf, common)
+
+#endif /* __NET_TC_BPF_H */
diff --git a/include/uapi/linux/tc_act/Kbuild b/include/uapi/linux/tc_act/Kbuild
index b057da2..19d5219 100644
--- a/include/uapi/linux/tc_act/Kbuild
+++ b/include/uapi/linux/tc_act/Kbuild
@@ -8,3 +8,4 @@ header-y += tc_nat.h
header-y += tc_pedit.h
header-y += tc_skbedit.h
header-y += tc_vlan.h
+header-y += tc_bpf.h
diff --git a/include/uapi/linux/tc_act/tc_bpf.h b/include/uapi/linux/tc_act/tc_bpf.h
new file mode 100644
index 0000000..5288bd77
--- /dev/null
+++ b/include/uapi/linux/tc_act/tc_bpf.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2015 Jiri Pirko <jiri@resnulli.us>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __LINUX_TC_BPF_H
+#define __LINUX_TC_BPF_H
+
+#include <linux/pkt_cls.h>
+
+#define TCA_ACT_BPF 13
+
+struct tc_act_bpf {
+ tc_gen;
+};
+
+enum {
+ TCA_ACT_BPF_UNSPEC,
+ TCA_ACT_BPF_TM,
+ TCA_ACT_BPF_PARMS,
+ TCA_ACT_BPF_OPS_LEN,
+ TCA_ACT_BPF_OPS,
+ __TCA_ACT_BPF_MAX,
+};
+#define TCA_ACT_BPF_MAX (__TCA_ACT_BPF_MAX - 1)
+
+#endif
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index c54c9d9..4669435 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -698,6 +698,18 @@ config NET_ACT_VLAN
To compile this code as a module, choose M here: the
module will be called act_vlan.
+config NET_ACT_BPF
+ tristate "BPF based action"
+ depends on NET_CLS_ACT
+ ---help---
+ Say Y here to execute BPF code on packets. The BPF code will decide
+ if the packet should be dropped or not.
+
+ If unsure, say N.
+
+ To compile this code as a module, choose M here: the
+ module will be called act_bpf.
+
config NET_CLS_IND
bool "Incoming device classification"
depends on NET_CLS_U32 || NET_CLS_FW
diff --git a/net/sched/Makefile b/net/sched/Makefile
index 679f24a..7ca2b4e 100644
--- a/net/sched/Makefile
+++ b/net/sched/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_NET_ACT_SIMP) += act_simple.o
obj-$(CONFIG_NET_ACT_SKBEDIT) += act_skbedit.o
obj-$(CONFIG_NET_ACT_CSUM) += act_csum.o
obj-$(CONFIG_NET_ACT_VLAN) += act_vlan.o
+obj-$(CONFIG_NET_ACT_BPF) += act_bpf.o
obj-$(CONFIG_NET_SCH_FIFO) += sch_fifo.o
obj-$(CONFIG_NET_SCH_CBQ) += sch_cbq.o
obj-$(CONFIG_NET_SCH_HTB) += sch_htb.o
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
new file mode 100644
index 0000000..1bd257e
--- /dev/null
+++ b/net/sched/act_bpf.c
@@ -0,0 +1,205 @@
+/*
+ * Copyright (c) 2015 Jiri Pirko <jiri@resnulli.us>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/skbuff.h>
+#include <linux/rtnetlink.h>
+#include <linux/filter.h>
+#include <net/netlink.h>
+#include <net/pkt_sched.h>
+
+#include <linux/tc_act/tc_bpf.h>
+#include <net/tc_act/tc_bpf.h>
+
+#define BPF_TAB_MASK 15
+
+static int tcf_bpf(struct sk_buff *skb, const struct tc_action *a,
+ struct tcf_result *res)
+{
+ struct tcf_bpf *b = a->priv;
+ int action;
+ int filter_res;
+
+ spin_lock(&b->tcf_lock);
+ b->tcf_tm.lastuse = jiffies;
+ bstats_update(&b->tcf_bstats, skb);
+ action = b->tcf_action;
+
+ filter_res = BPF_PROG_RUN(b->filter, skb);
+ if (filter_res == 0) {
+ /* Return code 0 from the BPF program
+ * is being interpreted as a drop here.
+ */
+ action = TC_ACT_SHOT;
+ b->tcf_qstats.drops++;
+ }
+
+ spin_unlock(&b->tcf_lock);
+ return action;
+}
+
+static int tcf_bpf_dump(struct sk_buff *skb, struct tc_action *a,
+ int bind, int ref)
+{
+ unsigned char *tp = skb_tail_pointer(skb);
+ struct tcf_bpf *b = a->priv;
+ struct tc_act_bpf opt = {
+ .index = b->tcf_index,
+ .refcnt = b->tcf_refcnt - ref,
+ .bindcnt = b->tcf_bindcnt - bind,
+ .action = b->tcf_action,
+ };
+ struct tcf_t t;
+ struct nlattr *nla;
+
+ if (nla_put(skb, TCA_ACT_BPF_PARMS, sizeof(opt), &opt))
+ goto nla_put_failure;
+
+ if (nla_put_u16(skb, TCA_ACT_BPF_OPS_LEN, b->bpf_num_ops))
+ goto nla_put_failure;
+
+ nla = nla_reserve(skb, TCA_ACT_BPF_OPS, b->bpf_num_ops *
+ sizeof(struct sock_filter));
+ if (!nla)
+ goto nla_put_failure;
+
+ memcpy(nla_data(nla), b->bpf_ops, nla_len(nla));
+
+ t.install = jiffies_to_clock_t(jiffies - b->tcf_tm.install);
+ t.lastuse = jiffies_to_clock_t(jiffies - b->tcf_tm.lastuse);
+ t.expires = jiffies_to_clock_t(b->tcf_tm.expires);
+ if (nla_put(skb, TCA_ACT_BPF_TM, sizeof(t), &t))
+ goto nla_put_failure;
+ return skb->len;
+
+nla_put_failure:
+ nlmsg_trim(skb, tp);
+ return -1;
+}
+
+static const struct nla_policy act_bpf_policy[TCA_ACT_BPF_MAX + 1] = {
+ [TCA_ACT_BPF_PARMS] = { .len = sizeof(struct tc_act_bpf) },
+ [TCA_ACT_BPF_OPS_LEN] = { .type = NLA_U16 },
+ [TCA_ACT_BPF_OPS] = { .type = NLA_BINARY,
+ .len = sizeof(struct sock_filter) * BPF_MAXINSNS },
+};
+
+static int tcf_bpf_init(struct net *net, struct nlattr *nla,
+ struct nlattr *est, struct tc_action *a,
+ int ovr, int bind)
+{
+ struct nlattr *tb[TCA_ACT_BPF_MAX + 1];
+ struct tc_act_bpf *parm;
+ struct tcf_bpf *b;
+ u16 bpf_size, bpf_num_ops;
+ struct sock_filter *bpf_ops;
+ struct sock_fprog_kern tmp;
+ struct bpf_prog *fp;
+ int ret;
+
+ if (!nla)
+ return -EINVAL;
+
+ ret = nla_parse_nested(tb, TCA_ACT_BPF_MAX, nla, act_bpf_policy);
+ if (ret < 0)
+ return ret;
+
+ if (!tb[TCA_ACT_BPF_PARMS] ||
+ !tb[TCA_ACT_BPF_OPS_LEN] || !tb[TCA_ACT_BPF_OPS])
+ return -EINVAL;
+ parm = nla_data(tb[TCA_ACT_BPF_PARMS]);
+
+ bpf_num_ops = nla_get_u16(tb[TCA_ACT_BPF_OPS_LEN]);
+ if (bpf_num_ops > BPF_MAXINSNS || bpf_num_ops == 0)
+ return -EINVAL;
+
+ bpf_size = bpf_num_ops * sizeof(*bpf_ops);
+ bpf_ops = kzalloc(bpf_size, GFP_KERNEL);
+ if (!bpf_ops)
+ return -ENOMEM;
+
+ memcpy(bpf_ops, nla_data(tb[TCA_ACT_BPF_OPS]), bpf_size);
+
+ tmp.len = bpf_num_ops;
+ tmp.filter = bpf_ops;
+
+ ret = bpf_prog_create(&fp, &tmp);
+ if (ret)
+ goto free_bpf_ops;
+
+ if (!tcf_hash_check(parm->index, a, bind)) {
+ ret = tcf_hash_create(parm->index, est, a, sizeof(*b), bind);
+ if (ret)
+ goto destroy_fp;
+
+ ret = ACT_P_CREATED;
+ } else {
+ if (bind)
+ goto destroy_fp;
+ tcf_hash_release(a, bind);
+ if (!ovr) {
+ ret = -EEXIST;
+ goto destroy_fp;
+ }
+ }
+
+ b = to_bpf(a);
+ spin_lock_bh(&b->tcf_lock);
+ b->tcf_action = parm->action;
+ b->bpf_num_ops = bpf_num_ops;
+ b->bpf_ops = bpf_ops;
+ b->filter = fp;
+ spin_unlock_bh(&b->tcf_lock);
+
+ if (ret == ACT_P_CREATED)
+ tcf_hash_insert(a);
+ return ret;
+
+destroy_fp:
+ bpf_prog_destroy(fp);
+free_bpf_ops:
+ kfree(bpf_ops);
+ return ret;
+}
+
+static void tcf_bpf_cleanup(struct tc_action *a, int bind)
+{
+ struct tcf_bpf *b = a->priv;
+
+ bpf_prog_destroy(b->filter);
+}
+
+static struct tc_action_ops act_bpf_ops = {
+ .kind = "bpf",
+ .type = TCA_ACT_BPF,
+ .owner = THIS_MODULE,
+ .act = tcf_bpf,
+ .dump = tcf_bpf_dump,
+ .cleanup = tcf_bpf_cleanup,
+ .init = tcf_bpf_init,
+};
+
+static int __init bpf_init_module(void)
+{
+ return tcf_register_action(&act_bpf_ops, BPF_TAB_MASK);
+}
+
+static void __exit bpf_cleanup_module(void)
+{
+ tcf_unregister_action(&act_bpf_ops);
+}
+
+module_init(bpf_init_module);
+module_exit(bpf_cleanup_module);
+
+MODULE_AUTHOR("Jiri Pirko <jiri@resnulli.us>");
+MODULE_DESCRIPTION("TC BPF based action");
+MODULE_LICENSE("GPL v2");
--
1.9.3
^ permalink raw reply related
* [patch net-next v5 2/2] tc: cls_bpf: rename bpf_len to bpf_num_ops
From: Jiri Pirko @ 2015-01-15 8:52 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, dborkman, ast, hannes, gaofeng
In-Reply-To: <1421311960-14744-1-git-send-email-jiri@resnulli.us>
It was suggested by DaveM to change the name as "len" might indicate
unit bytes.
Suggested-by: David Miller <davem@davemloft.net>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
---
v3->v4->v5:
- no change
patch added in v3
---
net/sched/cls_bpf.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index 84c8219..1029923 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -37,7 +37,7 @@ struct cls_bpf_prog {
struct tcf_result res;
struct list_head link;
u32 handle;
- u16 bpf_len;
+ u16 bpf_num_ops;
struct tcf_proto *tp;
struct rcu_head rcu;
};
@@ -160,7 +160,7 @@ static int cls_bpf_modify_existing(struct net *net, struct tcf_proto *tp,
struct tcf_exts exts;
struct sock_fprog_kern tmp;
struct bpf_prog *fp;
- u16 bpf_size, bpf_len;
+ u16 bpf_size, bpf_num_ops;
u32 classid;
int ret;
@@ -173,13 +173,13 @@ static int cls_bpf_modify_existing(struct net *net, struct tcf_proto *tp,
return ret;
classid = nla_get_u32(tb[TCA_BPF_CLASSID]);
- bpf_len = nla_get_u16(tb[TCA_BPF_OPS_LEN]);
- if (bpf_len > BPF_MAXINSNS || bpf_len == 0) {
+ bpf_num_ops = nla_get_u16(tb[TCA_BPF_OPS_LEN]);
+ if (bpf_num_ops > BPF_MAXINSNS || bpf_num_ops == 0) {
ret = -EINVAL;
goto errout;
}
- bpf_size = bpf_len * sizeof(*bpf_ops);
+ bpf_size = bpf_num_ops * sizeof(*bpf_ops);
bpf_ops = kzalloc(bpf_size, GFP_KERNEL);
if (bpf_ops == NULL) {
ret = -ENOMEM;
@@ -188,14 +188,14 @@ static int cls_bpf_modify_existing(struct net *net, struct tcf_proto *tp,
memcpy(bpf_ops, nla_data(tb[TCA_BPF_OPS]), bpf_size);
- tmp.len = bpf_len;
+ tmp.len = bpf_num_ops;
tmp.filter = bpf_ops;
ret = bpf_prog_create(&fp, &tmp);
if (ret)
goto errout_free;
- prog->bpf_len = bpf_len;
+ prog->bpf_num_ops = bpf_num_ops;
prog->bpf_ops = bpf_ops;
prog->filter = fp;
prog->res.classid = classid;
@@ -303,10 +303,10 @@ static int cls_bpf_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
if (nla_put_u32(skb, TCA_BPF_CLASSID, prog->res.classid))
goto nla_put_failure;
- if (nla_put_u16(skb, TCA_BPF_OPS_LEN, prog->bpf_len))
+ if (nla_put_u16(skb, TCA_BPF_OPS_LEN, prog->bpf_num_ops))
goto nla_put_failure;
- nla = nla_reserve(skb, TCA_BPF_OPS, prog->bpf_len *
+ nla = nla_reserve(skb, TCA_BPF_OPS, prog->bpf_num_ops *
sizeof(struct sock_filter));
if (nla == NULL)
goto nla_put_failure;
--
1.9.3
^ permalink raw reply related
* Re: [linux-nics] [PATCHv4 net] i40e: Implement ndo_gso_check()
From: Jeff Kirsher @ 2015-01-15 9:03 UTC (permalink / raw)
To: Jesse Gross
Cc: Joe Stringer, netdev, linux.nics, Linux Kernel Mailing List,
Tom Herbert
In-Reply-To: <CAEP_g=8iRKx9HPf0KRt6m=6pqAuMeT8_9GM8L+uFe+bMoxk33Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
On Wed, 2015-01-14 at 18:24 -0800, Jesse Gross wrote:
> On Fri, Dec 26, 2014 at 3:58 PM, Jesse Gross <jesse@nicira.com> wrote:
> > On Fri, Dec 5, 2014 at 2:12 PM, Jeff Kirsher
> > <jeffrey.t.kirsher@intel.com> wrote:
> >> On Fri, 2014-12-05 at 10:41 -0800, Joe Stringer wrote:
> >>> ndo_gso_check() was recently introduced to allow NICs to report the
> >>> offloading support that they have on a per-skb basis. Add an
> >>> implementation for this driver which checks for IPIP, GRE, UDP
> >>> tunnels.
> >>>
> >>> Signed-off-by: Joe Stringer <joestringer@nicira.com>
> >>> ---
> >>> v4: Simplify the check to just do tunnel header length.
> >>> Fix #define style issue.
> >>> v3: Drop IPIP and GRE (no driver support even though hw supports it).
> >>> Check for UDP outer protocol for UDP tunnels.
> >>> v2: Expand to include IP in IP and IPv4/IPv6 inside GRE/UDP tunnels.
> >>> Add MAX_INNER_LENGTH (as 80).
> >>> ---
> >>> drivers/net/ethernet/intel/i40e/i40e_main.c | 12 ++++++++++++
> >>> 1 file changed, 12 insertions(+)
> >>
> >> Thanks Joe, I will update the patch in my queue with your latest
> >> version.
> >
> > Jeff, as a heads-up, this patch and the corresponding one for fm10k
> > will no longer apply now that the ndo has changed. This was changed by
> > 5f35227e ("net: Generalize ndo_gso_check to ndo_features_check"). The
> > update needed is trivial and is just due to the change in the function
> > signature but I'm not sure where you are in the testing process with
> > this.
>
> Jeff - just wanted to check if you had seen this.
Yeah, I have the updated patch in my queue. I was hoping to get this
patch pushed later this week. It did not make the series of i40e
patches I am preparing to send out in the next couple of hours, but
should be in the next series or the series following the next. Holidays
put a damper on things unfortunately.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v13 3/3] net: hisilicon: new hip04 ethernet driver
From: Arnd Bergmann @ 2015-01-15 9:05 UTC (permalink / raw)
To: Ding Tianhong
Cc: robh+dt, davem, grant.likely, agraf, sergei.shtylyov,
linux-arm-kernel, eric.dumazet, xuwei5, zhangfei.gao, netdev,
devicetree, linux
In-Reply-To: <54B72BE0.7040403@huawei.com>
On Thursday 15 January 2015 10:54:24 Ding Tianhong wrote:
> On 2015/1/14 16:53, Arnd Bergmann wrote:
> > On Wednesday 14 January 2015 14:34:14 Ding Tianhong wrote:
> >> +#define HIP04_MAX_TX_COALESCE_USECS 200
> >> +#define HIP04_MIN_TX_COALESCE_USECS 100
> >> +#define HIP04_MAX_TX_COALESCE_FRAMES 200
> >> +#define HIP04_MIN_TX_COALESCE_FRAMES 100
> >
> > It's not important, but in case you are creating another version of the
> > patch, maybe the allowed range can be extended somewhat. The example values
> > I picked when I sent my suggestion were really made up. It's great if
> > they work fine, but users might want to tune this far more depending on
> > their workloads, How about these
> >
> > #define HIP04_MAX_TX_COALESCE_USECS 100000
> > #define HIP04_MIN_TX_COALESCE_USECS 1
> > #define HIP04_MAX_TX_COALESCE_FRAMES (TX_DESC_NUM - 1)
> > #define HIP04_MIN_TX_COALESCE_FRAMES 1
> >
>
> Is it really ok that the so big range may break the driver and hip04 could not work fine?
> I am not sure it is ok, I will fix it in next version.
Obviously, performance will suffer when you pick a bad setting for
a given workload. If the numbers are too low, you will increase
the CPU load but get better latency, so I see nothing wrong in
allowing '1' as the minimum. For the descriptor number, you can't
go above TX_DESC_NUM, but there is nothing wrong in going close to
it, it will just mean that the timer should fire before you get
there and you again get more interrupts.
The 100ms maximum delay is a bit extreme, and will definitely impact
TX latency in some workloads if a user sets this, but the system
will should still be usable, and I couldn't think of a better
limit. Feel free to set this to e.g. 10ms or 1ms if you feel more
comfortable with that.
For reference, with TX_DESC_NUM=256 and 1500 byte frames, you have
up to 300ms worth of data in a full tx queue on a 10mbit link,
or 3ms respectively for a 1gbit link. Because of BQL, the actual
queue length will normally be much shorter than this, but on a
tx-only workload won't shrink below the currently used
tx_coalesce_usecs value.
Arnd
^ permalink raw reply
* [net PATCH 1/1] drivers: net: cpsw: fix cpsw hung with add vlan using vconfig
From: Mugunthan V N @ 2015-01-15 9:29 UTC (permalink / raw)
To: netdev; +Cc: davem, Mugunthan V N
while adding vlan in dual EMAC mode, only specific ports should be
subscribed for the vlan, else it will lead to switching mode and
if both ports connected to same switch cpsw will hung as it creates
a network loop. Fixing this by adding only specific ports in case
of dual EMAC.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 64d1cef..e068d48 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1634,16 +1634,24 @@ static inline int cpsw_add_vlan_ale_entry(struct cpsw_priv *priv,
unsigned short vid)
{
int ret;
- int unreg_mcast_mask;
+ int unreg_mcast_mask = 0;
+ u32 port_mask;
- if (priv->ndev->flags & IFF_ALLMULTI)
- unreg_mcast_mask = ALE_ALL_PORTS;
- else
- unreg_mcast_mask = ALE_PORT_1 | ALE_PORT_2;
+ if (priv->data.dual_emac) {
+ port_mask = (1 << (priv->emac_port + 1)) | ALE_PORT_HOST;
+
+ if (priv->ndev->flags & IFF_ALLMULTI)
+ unreg_mcast_mask = port_mask;
+ } else {
+ port_mask = ALE_ALL_PORTS;
+
+ if (priv->ndev->flags & IFF_ALLMULTI)
+ unreg_mcast_mask = ALE_ALL_PORTS;
+ else
+ unreg_mcast_mask = ALE_PORT_1 | ALE_PORT_2;
+ }
- ret = cpsw_ale_add_vlan(priv->ale, vid,
- ALE_ALL_PORTS << priv->host_port,
- 0, ALE_ALL_PORTS << priv->host_port,
+ ret = cpsw_ale_add_vlan(priv->ale, vid, port_mask, 0, port_mask,
unreg_mcast_mask << priv->host_port);
if (ret != 0)
return ret;
@@ -1654,8 +1662,7 @@ static inline int cpsw_add_vlan_ale_entry(struct cpsw_priv *priv,
goto clean_vid;
ret = cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
- ALE_ALL_PORTS << priv->host_port,
- ALE_VLAN, vid, 0);
+ port_mask, ALE_VLAN, vid, 0);
if (ret != 0)
goto clean_vlan_ucast;
return 0;
--
2.2.1.62.g3f15098
^ permalink raw reply related
* [PATCH net-next v2] socket: use iov_length()
From: Nicolas Dichtel @ 2015-01-15 9:35 UTC (permalink / raw)
To: netdev; +Cc: davem, Nicolas Dichtel
In-Reply-To: <20150114.164528.230093054757243054.davem@davemloft.net>
Better to use available helpers.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
v2: initialize size variable with iov_length() result
net/socket.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index a2c33a4dc7ba..e1278d7e1d5d 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -882,11 +882,7 @@ static ssize_t do_sock_read(struct msghdr *msg, struct kiocb *iocb,
unsigned long nr_segs)
{
struct socket *sock = file->private_data;
- size_t size = 0;
- int i;
-
- for (i = 0; i < nr_segs; i++)
- size += iov[i].iov_len;
+ size_t size = iov_length(iov, nr_segs);
msg->msg_name = NULL;
msg->msg_namelen = 0;
@@ -921,11 +917,7 @@ static ssize_t do_sock_write(struct msghdr *msg, struct kiocb *iocb,
unsigned long nr_segs)
{
struct socket *sock = file->private_data;
- size_t size = 0;
- int i;
-
- for (i = 0; i < nr_segs; i++)
- size += iov[i].iov_len;
+ size_t size = iov_length(iov, nr_segs);
msg->msg_name = NULL;
msg->msg_namelen = 0;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next v13 0/3] add hisilicon hip04 ethernet driver
From: Arnd Bergmann @ 2015-01-15 9:42 UTC (permalink / raw)
To: Ding Tianhong
Cc: Alexander Graf, robh+dt, davem, grant.likely, sergei.shtylyov,
linux-arm-kernel, eric.dumazet, xuwei5, zhangfei.gao, netdev,
devicetree, linux
In-Reply-To: <54B77C43.6010200@huawei.com>
On Thursday 15 January 2015 16:37:23 Ding Tianhong wrote:
> On 2015/1/14 18:19, Alexander Graf wrote:
> >
> >>From a 10000 feet perspective it looks like two problems to me
> >
> > 1) Allocation failure doesn't get handled properly somewhere
This is the bug that Eric pointed out as well.
> > 2) We fail to allocate with order=0 - I don't see why
GFP_ATOMIC. When allocating from a the napi poll function in softirq
context, you have to use nonblocking allocations, which occasionally
fail. This should not cause any harm other than dropped packets.
> is it easy to repetition this bug? how big is your memory on your board,
> is it happened in your previous hip04 driver?
It should be independent of memory size, but may be more likely if you
don't have swap space configured.
Arnd
^ permalink raw reply
* Re: [PATCH net-next v13 3/3] net: hisilicon: new hip04 ethernet driver
From: Arnd Bergmann @ 2015-01-15 9:53 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Ding Tianhong, robh+dt, davem, grant.likely, agraf, devicetree,
linux, sergei.shtylyov, eric.dumazet, netdev, xuwei5,
zhangfei.gao
In-Reply-To: <1421217254-12008-4-git-send-email-dingtianhong@huawei.com>
On Wednesday 14 January 2015 14:34:14 Ding Tianhong wrote:
> +static int hip04_set_coalesce(struct net_device *netdev,
> + struct ethtool_coalesce *ec)
> +{
> + struct hip04_priv *priv = netdev_priv(netdev);
> +
> + /* Check not supported parameters */
> + if ((ec->rx_max_coalesced_frames) || (ec->rx_coalesce_usecs_irq) ||
> + (ec->rx_max_coalesced_frames_irq) || (ec->tx_coalesce_usecs_irq) ||
> + (ec->use_adaptive_rx_coalesce) || (ec->use_adaptive_tx_coalesce) ||
> + (ec->pkt_rate_low) || (ec->rx_coalesce_usecs_low) ||
> + (ec->rx_max_coalesced_frames_low) || (ec->tx_coalesce_usecs_high) ||
> + (ec->tx_max_coalesced_frames_low) || (ec->pkt_rate_high) ||
> + (ec->tx_coalesce_usecs_low) || (ec->rx_coalesce_usecs_high) ||
> + (ec->rx_max_coalesced_frames_high) || (ec->rx_coalesce_usecs) ||
> + (ec->tx_max_coalesced_frames_irq) ||
> + (ec->stats_block_coalesce_usecs) ||
> + (ec->tx_max_coalesced_frames_high) || (ec->rate_sample_interval))
> + return -EOPNOTSUPP;
> +
> + if ((ec->tx_coalesce_usecs > HIP04_MAX_TX_COALESCE_USECS ||
> + ec->tx_coalesce_usecs < HIP04_MIN_TX_COALESCE_USECS) ||
> + (ec->tx_max_coalesced_frames > HIP04_MAX_TX_COALESCE_FRAMES ||
> + ec->tx_max_coalesced_frames < HIP04_MIN_TX_COALESCE_FRAMES))
> + return -EINVAL;
> +
> + priv->tx_coalesce_usecs = ec->tx_coalesce_usecs;
> + priv->tx_coalesce_frames = ec->tx_max_coalesced_frames;
> +
> + return 0;
> +}
I just looked at this again and noticed that you fail to actually use the
tx_coalesce_usecs value anywhere, since you don't call hrtimer_set_expires_range()
any more.
Also, I guess it would be nice use the rx_coalesce_usecs_low and
tx_coalesce_usecs_high numbers instead of just a single number, as
hrtimer_set_expires_range takes two values already. Just do something
like
hrtimer_set_expires_range(&priv->tx_coalesce_timer,
priv->rx_coalesce_usecs_low,
priv->rx_coalesce_usecs_high -
priv->rx_coalesce_usecs_low);
and make sure the 'low' value is smaller than the 'high' one.
> + priv->tx_coalesce_frames = TX_DESC_NUM * 3 / 4;
> + priv->tx_coalesce_usecs = 200;
Related, instead of putting the raw numbers here, how about
adding the defaults along with the other macros we talked about:
#define HIP04_MAX_TX_COALESCE_USECS 10000
#define HIP04_MIN_TX_COALESCE_USECS 1
#define HIP04_MAX_TX_COALESCE_FRAMES (TX_DESC_NUM - 1)
#define HIP04_MIN_TX_COALESCE_FRAMES 1
#define HIP04_DEFAULT_TX_COALESCE_USECS_LOW 80
#define HIP04_DEFAULT_TX_COALESCE_USECS_HIGH 200
#define HIP04_DEFAULT_TX_COALESCE_FRAMES (TX_DESC_NUM / 2)
Arnd
^ 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