* Re: [PATCH] net-sched: sch_cbq: avoid infinite loop
From: David Miller @ 2012-09-12 2:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: denys, netdev
In-Reply-To: <1347405072.13103.675.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 12 Sep 2012 01:11:12 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Its possible to setup a bad cbq configuration leading to
> an infinite loop in cbq_classify()
>
> DEV_OUT=eth0
> ICMP="match ip protocol 1 0xff"
> U32="protocol ip u32"
> DST="match ip dst"
> tc qdisc add dev $DEV_OUT root handle 1: cbq avpkt 1000 \
> bandwidth 100mbit
> tc class add dev $DEV_OUT parent 1: classid 1:1 cbq \
> rate 512kbit allot 1500 prio 5 bounded isolated
> tc filter add dev $DEV_OUT parent 1: prio 3 $U32 \
> $ICMP $DST 192.168.3.234 flowid 1:
>
> Reported-by: Denys Fedoryschenko <denys@visp.net.lb>
> Tested-by: Denys Fedoryschenko <denys@visp.net.lb>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* [PATCH] CodingStyle: Add networking specific block comment style
From: Joe Perches @ 2012-09-12 3:11 UTC (permalink / raw)
To: Allan, Bruce W; +Cc: Andrew Morton, Andy Whitcroft, David Miller, LKML, netdev
In-Reply-To: <804857E1F29AAC47BF68C404FC60A1842EB021D9@ORSMSX102.amr.corp.intel.com>
The block comment style in net/ and drivers/net is non-standard.
Document it.
Signed-off-by: Joe Perches <joe@perches.com>
---
> This conflicts with the preferred style for long (multi-line) comments documented in
> ./Documentation/CodingStyle. If this is the way comments should be done in the
> networking code this patch should also include an update to Chapter 8 in CodingStyle
> documenting the networking specific style to avoid confusion.
Documentation/CodingStyle | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index cb9258b..495e5ba 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -454,6 +454,16 @@ The preferred style for long (multi-line) comments is:
* with beginning and ending almost-blank lines.
*/
+For files in net/ and drivers/net/ the preferred style for long (multi-line)
+comments is a little different.
+
+ /* The preferred comment style for files in net/ and drivers/net
+ * looks like this.
+ *
+ * It is nearly the same as the generally preferred comment style,
+ * but there is no initial almost-blank line.
+ */
+
It's also important to comment data, whether they are basic types or derived
types. To this end, use just one data declaration per line (no commas for
multiple data declarations). This leaves you room for a small comment on each
^ permalink raw reply related
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5 corrupted using NFS
From: rebelyouth hacklab @ 2012-09-12 3:34 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAPxKiaw9yHisO8imXwKkTEqCm-BE+Tiq_t3s28EE7xMgqNnggA@mail.gmail.com>
Hi Xiong,
Sorry for the long delay but I did some experiment :
I tried with different pc and devices and OS and the problem is only in Linux.
I don't get kernel oops (actually was the ATI catalyst the problem,
now with the Open source driver is all ok ) and ifconfig showing is
all ok on the pc side (Atheros)
eth0 Link encap:Ethernet HWaddr
inet addr:192.168.2.2 Bcast:192.168.2.15 Mask:255.255.255.240
inet6 addr: fe80::226:18ff:fe62:72f5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9933884 errors:0 dropped:0 overruns:0 frame:0
TX packets:3235805 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:14432030555 (413.4 GiB) TX bytes:275014758 (262.2 GiB)
Interrupt:46
On the server side I received :
eth0 Link encap:Ethernet HWaddr
inet addr:192.168.2.5 Bcast:192.168.2.15 Mask:255.255.255.240
inet6 addr: fe80::201:2eff:fe2b:67b6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13922264 errors:20736 dropped:0 overruns:20736 frame:0
TX packets:8782465 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4995676199 (414.6 GiB) TX bytes:31479570606 (229.3 GiB)
Interrupt:22
The server receive a lot of errors in RX
RX packets:13922264 errors:20736 dropped:0 overruns:20736 frame:0
I tried big DVD isos and separate files zip an rar and there are
perfect in Windows, Freebsd and Mac OS X (samba,ftp,nfs) the ipconfig
on the server showing is all ok
I also tried to optimize the NFS server and client but the only
setting for get the same of the other OS is need to set proto=udp on
/ etc/fstab (now is more stable from before)
I can also see there isn't any problem on the client computer using
the usb adapter with ax8112 Chipset without set proto=udp
So tried to disable the TSO with : ethtool -K eth0 tso off and IS
working !!!
I really think the problem is this one and unfortunately I can't send
any oops, but if you need any information or to run any software
please let me know!!!
> On Fri, Aug 10, 2012 at 3:26 PM, Rebelyouth
> <rebelyouth.hacklab@gmail.com> wrote:
>>
>>
>> Hi Xiong,
>>
>> Thank you for your replay,
>>
>> I am in a middle of reinstall all my machines f, so for now I can send you my
>> lspci and try to recreate the MD5 /SHA1 problem
>>
>> I will send you another email when I get the result
>> Thanks in advance
>>
>>
>>
>> 00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge
>> Subsystem: Advanced Micro Devices [AMD] RS780 Host Bridge
>> Flags: bus master, 66MHz, medium devsel, latency 0
>> Capabilities: <access denied>
>>
>> 00:02.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (ext
>> gfx port 0) (prog-if 00 [Normal decode])
>> Flags: bus master, fast devsel, latency 0
>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>> I/O behind bridge: 0000c000-0000cfff
>> Memory behind bridge: fbd00000-fbdfffff
>> Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
>> Capabilities: <access denied>
>> Kernel driver in use: pcieport
>>
>> 00:06.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE
>> port 2) (prog-if 00 [Normal decode])
>> Flags: bus master, fast devsel, latency 0
>> Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
>> I/O behind bridge: 0000d000-0000dfff
>> Memory behind bridge: fbe00000-fbefffff
>> Capabilities: <access denied>
>> Kernel driver in use: pcieport
>>
>> 00:07.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE
>> port 3) (prog-if 00 [Normal decode])
>> Flags: bus master, fast devsel, latency 0
>> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
>> I/O behind bridge: 0000e000-0000efff
>> Memory behind bridge: fbf00000-fbffffff
>> Capabilities: <access denied>
>> Kernel driver in use: pcieport
>>
>> 00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI
>> SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (prog-if 01 [AHCI 1.0])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA
>> Controller [AHCI mode]
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 43
>> I/O ports at b000 [size=8]
>> I/O ports at a000 [size=4]
>> I/O ports at 9000 [size=8]
>> I/O ports at 8000 [size=4]
>> I/O ports at 7000 [size=16]
>> Memory at fbcffc00 (32-bit, non-prefetchable) [size=1K]
>> Capabilities: <access denied>
>> Kernel driver in use: ahci
>>
>> 00:12.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> USB OHCI0 Controller (prog-if 10 [OHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB
>> OHCI0 Controller
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
>> Memory at fbcfd000 (32-bit, non-prefetchable) [size=4K]
>> Kernel driver in use: ohci_hcd
>>
>> 00:12.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1
>> Controller (prog-if 10 [OHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1
>> Controller
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
>> Memory at fbcfe000 (32-bit, non-prefetchable) [size=4K]
>> Kernel driver in use: ohci_hcd
>>
>> 00:12.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> USB EHCI Controller (prog-if 20 [EHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4397
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17
>> Memory at fbcff800 (32-bit, non-prefetchable) [size=256]
>> Capabilities: <access denied>
>> Kernel driver in use: ehci_hcd
>>
>> 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> USB OHCI0 Controller (prog-if 10 [OHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4398
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
>> Memory at fbcfb000 (32-bit, non-prefetchable) [size=4K]
>> Kernel driver in use: ohci_hcd
>>
>> 00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1
>> Controller (prog-if 10 [OHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4399
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
>> Memory at fbcfc000 (32-bit, non-prefetchable) [size=4K]
>> Kernel driver in use: ohci_hcd
>>
>> 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> USB EHCI Controller (prog-if 20 [EHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB
>> EHCI Controller
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
>> Memory at fbcff400 (32-bit, non-prefetchable) [size=256]
>> Capabilities: <access denied>
>> Kernel driver in use: ehci_hcd
>>
>> 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller
>> (rev 3c)
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller
>> Flags: 66MHz, medium devsel
>> Capabilities: <access denied>
>>
>> 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> IDE Controller (prog-if 8a [Master SecP PriP])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 IDE
>> Controller
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
>> I/O ports at 01f0 [size=8]
>> I/O ports at 03f4 [size=1]
>> I/O ports at 0170 [size=8]
>> I/O ports at 0374 [size=1]
>> I/O ports at ff00 [size=16]
>> Capabilities: <access denied>
>> Kernel driver in use: pata_atiixp
>>
>> 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel
>> HDA)
>> Subsystem: ASUSTeK Computer Inc. Device 8357
>> Flags: bus master, slow devsel, latency 64, IRQ 16
>> Memory at fbcf4000 (64-bit, non-prefetchable) [size=16K]
>> Capabilities: <access denied>
>> Kernel driver in use: snd_hda_intel
>>
>> 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC
>> host controller
>> Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4383
>> Flags: bus master, 66MHz, medium devsel, latency 0
>>
>> 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI
>> Bridge (prog-if 01 [Subtractive decode])
>> Flags: bus master, 66MHz, medium devsel, latency 64
>> Bus: primary=00, secondary=04, subordinate=04, sec-latency=64
>>
>> 00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0
>> USB OHCI2 Controller (prog-if 10 [OHCI])
>> Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4396
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
>> Memory at fbcfa000 (32-bit, non-prefetchable) [size=4K]
>> Kernel driver in use: ohci_hcd
>>
>> 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
>> HyperTransport Configuration
>> Flags: fast devsel
>> Capabilities: <access denied>
>>
>> 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address
>> Map
>> Flags: fast devsel
>>
>> 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM
>> Controller
>> Flags: fast devsel
>>
>> 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
>> Miscellaneous Control
>> Flags: fast devsel
>> Capabilities: <access denied>
>> Kernel driver in use: k10temp
>>
>> 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link
>> Control
>> Flags: fast devsel
>>
>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
>> Juniper [Radeon HD 5700 Series] (prog-if 00 [VGA controller])
>> Subsystem: Micro-Star International Co., Ltd. Device 2140
>> Flags: bus master, fast devsel, latency 0, IRQ 44
>> Memory at d0000000 (64-bit, prefetchable) [size=256M]
>> Memory at fbdc0000 (64-bit, non-prefetchable) [size=128K]
>> I/O ports at c000 [size=256]
>> Expansion ROM at fbda0000 [disabled] [size=128K]
>> Capabilities: <access denied>
>> Kernel driver in use: radeon
>>
>> 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio
>> [Radeon HD 5700 Series]
>> Subsystem: Micro-Star International Co., Ltd. Device aa58
>> Flags: bus master, fast devsel, latency 0, IRQ 45
>> Memory at fbdfc000 (64-bit, non-prefetchable) [size=16K]
>> Capabilities: <access denied>
>> Kernel driver in use: snd_hda_intel
>>
>> 02:00.0 Ethernet controller: Atheros Communications Inc. AR8121/AR8113/AR8114
>> Gigabit or Fast Ethernet (rev b0)
>> Subsystem: ASUSTeK Computer Inc. Device 831c
>> Flags: bus master, fast devsel, latency 0, IRQ 46
>> Memory at fbec0000 (64-bit, non-prefetchable) [size=256K]
>> I/O ports at dc00 [size=128]
>> Capabilities: <access denied>
>> Kernel driver in use: ATL1E
>>
>> 03:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire
>> Controller (prog-if 10 [OHCI])
>> Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
>> Flags: bus master, fast devsel, latency 0, IRQ 19
>> Memory at fbfff800 (64-bit, non-prefetchable) [size=2K]
>> I/O ports at e800 [size=256]
>> Capabilities: <access denied>
>> Kernel driver in use: firewire_ohci
>>
>> > Marco
>> > Could you run lspci, and list the kernel oops ?
>> > we could duplicate it using the same NIC.
>> >
>> >
>> > PS. The driver of 1.0.1.14 is not for your NIC.
>> >
>> > Thanks
>> > Xiong
>> >
>> > > -----Original Message-----
>> > > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>> > > On Behalf Of Marco Castiglione
>> > > Sent: Tuesday, August 07, 2012 1:03
>> > > To: netdev@vger.kernel.org
>> > > Subject: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or
>> > > Fast Ethernet (rev b0) 1.0.0.7 md5 corrupted using NFS
>> > >
>> > > Hi,
>> > >
>> > > I have a problem with :
>> > >
>> > > Ethernet controller: Atheros Communications Inc. AR8121/AR8113/AR8114
>> > > Gigabit or Fast Ethernet (rev b0)
>> > >
>> > > Subsystem: ASUSTeK Computer Inc. Device 831c
>> > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> > >
>> > > ParErr-
>> > > Stepping- SERR+ FastB2B- DisINTx+
>> > >
>> > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> > >
>> > > <TAbort- <MAbort- >SERR- <PERR- INTx-
>> > >
>> > > Latency: 0, Cache Line Size: 64 bytes
>> > > Interrupt: pin A routed to IRQ 46
>> > > Region 0: Memory at fbec0000 (64-bit, non-prefetchable)
>> > > [size=256K] Region 2: I/O ports at dc00 [size=128]
>> > > Capabilities: <access denied>
>> > > Kernel driver in use: ATL1E
>> > >
>> > > The driver working fine except for nfs3 and nfs4
>> > >
>> > > If I try to copy a file bigger of 400 mb the file get corrupted, If I try
>> > > with multiple files I have a kernel oops
>> > >
>> > > I tried different system and service (Ftp,samba) and they working fine.
>> > >
>> > > I also tried to set nfs to use udp, it kinda fix the problem but only in
>> > > part (I get 1 on 3 big file with md5 mismatch).
>> > >
>> > > I notice in almost every kernel from 2.6 to now 3.2.15 the driver is the
>> > > same version
>> > >
>> > > Filename: /lib/modules/3.2.0-2-amd64/
>> > > kernel/drivers/net/ethernet/atheros/atl1e/atl1e.ko
>> > > version: 1.0.0.7-NAPI
>> > > license: GPL
>> > > description: Atheros 1000M Ethernet Network Driver
>> > > author: Atheros Corporation, <xiong.huang@atheros.com>, Jie Yang
>> > > < jie.yang@atheros.com>
>> > > srcversion: 6E5949327D7FDF32D5F4A5B
>> > > alias: pci:v00001969d00001066sv*sd*bc*sc*i*
>> > > alias: pci:v00001969d00001026sv*sd*bc*sc*i*
>> > > depends:
>> > > intree: Y
>> > > vermagic: 3.2.0-2-amd64 SMP mod_unload modversions
>> > > parm: tx_desc_cnt:Transmit description count (array of int)
>> > > parm: rx_mem_size:memory size of rx buffer(KB) (array of int)
>> > > parm: media_type:MediaType Select (array of int)
>> > > parm: int_mod_timer:Interrupt Moderator Timer (array of int)
>> > >
>> > > I found on ubuntu website the last version of the driver is 1.0.1.14 with
>> > > this change log :
>> > >
>> > > 1.0.1.14
>> > >
>> > > 1. don't define napi_struct in kcompat.h when GRO isn't supported.
>> > >
>> > > 1.0.1.13
>> > >
>> > > 1. fix AR8151-A hang when plug in LAN cable by cleaning bit1 of
>> > >
>> > > REG(0x1114).
>> > >
>> > > 1.0.1.12
>> > >
>> > > 1. fix tpd, rfd, rrs, configure error for powerpc
>> > >
>> > > 1.0.1.11
>> > >
>> > > 1. only save power when WOL enable.
>> > >
>> > > 1.0.1.10
>> > >
>> > > 1. add l1d 2.0 support.
>> > > 2. fix atl1c_phy_power_saving bug.
>> > >
>> > > 1.0.1.9
>> > >
>> > > 1. fix AR8131 reset error TX pending.
>> > > 2. add AR8152 description.
>> > >
>> > > 1.0.1.8
>> > >
>> > > 1. add L2CB V2.0 support.
>> > >
>> > > 1.0.1.7
>> > >
>> > > 1. fix L0s/L1 bug.
>> > > 2. update suspend procedure.
>> > >
>> > > 1.0.1.6
>> > >
>> > > 1. fix valn error.
>> > > 2. use common task instead of reset task and link change task.
>> > > 3. reset phy when link down.
>> > >
>> > > 1.0.1.5
>> > >
>> > > 1. change rx mod.
>> > >
>> > > 1.0.1.4
>> > >
>> > > 1. add l1d support.
>> > >
>> > > 1.0.1.3
>> > >
>> > > 1. fix TSO error.
>> > >
>> > > 1.0.1.2
>> > >
>> > > 1. fix compile error for kernel >= 2.6.30.
>> > >
>> > > 1.0.1.1
>> > >
>> > > 1. add L2cB support.
>> > >
>> > > 1.0.0.10
>> > >
>> > > 1. fix memory leak when power suspend.
>> > >
>> > > 1.0.0.9
>> > >
>> > > 1. do power saving when bootup with link lost.
>> > > 2. remove ATL1C_INTR_CLEAR_ON_READ for power saving
>> > >
>> > > 1.0.0.8
>> > >
>> > > 1. remove dump_stack(), which was used for debugging.
>> > >
>> > > So I found out the TSO is corrupt in the current version and that
>> > > explain with the udp setting do the trick.
>> > >
>> > > Now I tried to compile the new version from AR81Family-linux-
>> > > v1.0.1.14.tar.gz but was made for the 2.6 so I can't
>> > > compile.( <http://goog_56610235>
>> > > http://media.cdn.ubuntu-de.org/forum/attachments/2666793/AR81Family-
>> > > linux-
>> > > v1.0.1.14_10.10.tar.gz
>> > > )
>> > >
>> > > The Atheros support and web page is gone after Qualcomm acquisition and
>> > > the patch I found on Ubuntu forum don't work either (
>> > > http://ubuntuforums.org/attachment.php?attachmentid=182141&d=1296221
>> > > 015)
>> > >
>> > > I found out lots of people have the same issue and they using samba at
>> > > the moment.
>> > >
>> > > My temp solution is use a usb/eth adapter with ax8112 chipset but it run
>> > > at 100mbps.
>> > >
>> > > SO my request is this : Is possible for somebody of the kernel team look
>> > > the code inside AR81Family-linux-v1.0.1.14.tar.gz and update the one in
>> > > the kernel 3.x?
>> > >
>> > > Thank you for you time and consideration
>> > > --
>> > > 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
>>
>>
>> Hi
^ permalink raw reply
* [PATCH] ipv6: replace write lock with read lock when get route info
From: roy.qing.li @ 2012-09-12 5:25 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
geting route info does not write rt->rt6i_table, so replace
write lock with read lock
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/ipv6/route.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 399613b..8be1d86 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1837,7 +1837,7 @@ static struct rt6_info *rt6_get_route_info(struct net *net,
if (!table)
return NULL;
- write_lock_bh(&table->tb6_lock);
+ read_lock_bh(&table->tb6_lock);
fn = fib6_locate(&table->tb6_root, prefix ,prefixlen, NULL, 0);
if (!fn)
goto out;
@@ -1853,7 +1853,7 @@ static struct rt6_info *rt6_get_route_info(struct net *net,
break;
}
out:
- write_unlock_bh(&table->tb6_lock);
+ read_unlock_bh(&table->tb6_lock);
return rt;
}
@@ -1896,7 +1896,7 @@ struct rt6_info *rt6_get_dflt_router(const struct in6_addr *addr, struct net_dev
if (!table)
return NULL;
- write_lock_bh(&table->tb6_lock);
+ read_lock_bh(&table->tb6_lock);
for (rt = table->tb6_root.leaf; rt; rt=rt->dst.rt6_next) {
if (dev == rt->dst.dev &&
((rt->rt6i_flags & (RTF_ADDRCONF | RTF_DEFAULT)) == (RTF_ADDRCONF | RTF_DEFAULT)) &&
@@ -1905,7 +1905,7 @@ struct rt6_info *rt6_get_dflt_router(const struct in6_addr *addr, struct net_dev
}
if (rt)
dst_hold(&rt->dst);
- write_unlock_bh(&table->tb6_lock);
+ read_unlock_bh(&table->tb6_lock);
return rt;
}
--
1.7.4.1
^ permalink raw reply related
* Re: [V3 PATCH 9/9] cxgb4vf: Chelsio FCoE offload driver submission (header compatibility fixes).
From: Naresh Kumar Inna @ 2012-09-12 5:35 UTC (permalink / raw)
To: David Miller
Cc: JBottomley@parallels.com, linux-scsi@vger.kernel.org,
Dimitrios Michailidis, Casey Leedom, netdev@vger.kernel.org,
Chethan Seshadri
In-Reply-To: <20120911.133321.282568248903907762.davem@davemloft.net>
On 9/11/2012 11:03 PM, David Miller wrote:
> From: Naresh Kumar Inna <naresh@chelsio.com>
> Date: Tue, 11 Sep 2012 20:09:07 +0530
>
>> This patch contains minor fixes to make cxgb4vf driver work with the updates to
>> shared firmware/hardware header files.
>>
>> Signed-off-by: Naresh Kumar Inna <naresh@chelsio.com>
>
> You cannot submit a patch set that isn't bisectable, and in particular
> create a situation that mid-way through your patch set things do not
> build or operate correctly.
>
Sorry, I am new to this process. The reason I did that was because I was
not sure if I could create a single patch with both cxgb4 and cxgb4vf
files in it, since they are two different subsystems. If I could do
that, the single patch then would build on its own, and not be dependent
on the other patches in the series. Is that something I can do?
Thanks,
Naresh.
^ permalink raw reply
* Re: [V3 PATCH 5/9] csiostor: Chelsio FCoE offload driver submission (sources part 5).
From: Naresh Kumar Inna @ 2012-09-12 5:40 UTC (permalink / raw)
To: David Miller
Cc: JBottomley@parallels.com, linux-scsi@vger.kernel.org,
Dimitrios Michailidis, Casey Leedom, netdev@vger.kernel.org,
Chethan Seshadri
In-Reply-To: <20120911.133510.1351483747174862495.davem@davemloft.net>
On 9/11/2012 11:05 PM, David Miller wrote:
> From: Naresh Kumar Inna <naresh@chelsio.com>
> Date: Tue, 11 Sep 2012 20:09:03 +0530
>
>> +#include <linux/moduleparam.h>
>
> This header include is not necessary.
>
I will remove it, thanks.
^ permalink raw reply
* Re: [V3 PATCH 9/9] cxgb4vf: Chelsio FCoE offload driver submission (header compatibility fixes).
From: David Miller @ 2012-09-12 5:47 UTC (permalink / raw)
To: naresh; +Cc: JBottomley, linux-scsi, dm, leedom, netdev, chethan
In-Reply-To: <50501F1A.6040905@chelsio.com>
From: Naresh Kumar Inna <naresh@chelsio.com>
Date: Wed, 12 Sep 2012 11:05:22 +0530
> On 9/11/2012 11:03 PM, David Miller wrote:
>> From: Naresh Kumar Inna <naresh@chelsio.com>
>> Date: Tue, 11 Sep 2012 20:09:07 +0530
>>
>>> This patch contains minor fixes to make cxgb4vf driver work with the updates to
>>> shared firmware/hardware header files.
>>>
>>> Signed-off-by: Naresh Kumar Inna <naresh@chelsio.com>
>>
>> You cannot submit a patch set that isn't bisectable, and in particular
>> create a situation that mid-way through your patch set things do not
>> build or operate correctly.
>>
>
> Sorry, I am new to this process. The reason I did that was because I was
> not sure if I could create a single patch with both cxgb4 and cxgb4vf
> files in it, since they are two different subsystems. If I could do
> that, the single patch then would build on its own, and not be dependent
> on the other patches in the series. Is that something I can do?
I don't know how else to say this, every step along the way the tree
has to build. You arrange the patches however necessary to achieve
that goal.
^ permalink raw reply
* Re: [PATCHv4] virtio-spec: virtio network device multiqueue support
From: Rusty Russell @ 2012-09-12 5:49 UTC (permalink / raw)
To: Jason Wang, Michael S. Tsirkin
Cc: kvm, netdev, rick.jones2, virtualization, levinsasha928, pbonzini,
Tom Herbert
In-Reply-To: <504DC831.1000709@redhat.com>
Jason Wang <jasowang@redhat.com> writes:
> On 09/10/2012 02:33 PM, Michael S. Tsirkin wrote:
>> A final addition: what you suggest above would be
>> "TX follows RX", right?
BTW, yes. But it's a weird way to express what the nic is doing.
>> It is in anticipation of something like that, that I made
>> steering programming so generic.
>> I think TX follows RX is more immediately useful for reasons above
>> but we can add both to spec and let drivers and devices
>> decide what they want to support.
You mean "RX follows TX"? ie. accelerated RFS. I agree.
Perhaps Tom can explain how we avoid out-of-order receive for the
accelerated RFS case? It's not clear to me, but we need to be able to
do that for virtio-net if it implements accelerated RFS.
> AFAIK, ixgbe does "rx follows tx". The only differences between ixgbe
> and virtio-net is that ixgbe driver programs the flow director during
> packet transmission but we suggest to do it silently in the device for
> simplicity.
Implying the receive queue by xmit will be slightly laggy. Don't know
if that's a problem.
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH 2/2] netprio_cgroup: Optimize the priomap copy loop slightly
From: Srivatsa S. Bhat @ 2012-09-12 6:05 UTC (permalink / raw)
To: David Laight
Cc: davem, nhorman, john.r.fastabend, gaofeng, eric.dumazet,
mark.d.rustad, lizefan, netdev, linux-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6FE9@saturn3.aculab.com>
On 09/11/2012 05:12 PM, David Laight wrote:
>> - for (i = 0;
>> - old_priomap && (i < old_priomap->priomap_len);
>> - i++)
>> - new_priomap->priomap[i] = old_priomap->priomap[i];
>> + if (old_priomap) {
>> + old_len = old_priomap->priomap_len;
>> +
>> + for (i = 0; i < old_len; i++)
>> + new_priomap->priomap[i] = old_priomap->priomap[i];
>> + }
>
> Or:
> memcpy(new_priomap->priomap, old_priomap->priomap,
> old_priomap->priomap_len * sizeof old_priomap->priomap[0]);
>
Ah, indeed that would be better. I'll send out an updated version of the
patches. Thanks!
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* [v2 PATCH 1/2] netprio_cgroup: Remove update_netdev_tables() since it is unnecessary
From: Srivatsa S. Bhat @ 2012-09-12 6:07 UTC (permalink / raw)
To: davem, nhorman
Cc: David.Laight, john.r.fastabend, gaofeng, eric.dumazet,
mark.d.rustad, lizefan, netdev, linux-kernel, srivatsa.bhat
The update_netdev_tables() function appears to be unnecessary, since the
write_update_netdev_table() function will adjust the priomaps as and when
required anyway. So drop the usage of update_netdev_tables() entirely.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
net/core/netprio_cgroup.c | 32 --------------------------------
1 files changed, 0 insertions(+), 32 deletions(-)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index c75e3f9..fd339bb0 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -109,32 +109,6 @@ static int write_update_netdev_table(struct net_device *dev)
return ret;
}
-static int update_netdev_tables(void)
-{
- int ret = 0;
- struct net_device *dev;
- u32 max_len;
- struct netprio_map *map;
-
- rtnl_lock();
- max_len = atomic_read(&max_prioidx) + 1;
- for_each_netdev(&init_net, dev) {
- map = rtnl_dereference(dev->priomap);
- /*
- * don't allocate priomap if we didn't
- * change net_prio.ifpriomap (map == NULL),
- * this will speed up skb_update_prio.
- */
- if (map && map->priomap_len < max_len) {
- ret = extend_netdev_table(dev, max_len);
- if (ret < 0)
- break;
- }
- }
- rtnl_unlock();
- return ret;
-}
-
static struct cgroup_subsys_state *cgrp_create(struct cgroup *cgrp)
{
struct cgroup_netprio_state *cs;
@@ -153,12 +127,6 @@ static struct cgroup_subsys_state *cgrp_create(struct cgroup *cgrp)
goto out;
}
- ret = update_netdev_tables();
- if (ret < 0) {
- put_prioidx(cs->prioidx);
- goto out;
- }
-
return &cs->css;
out:
kfree(cs);
^ permalink raw reply related
* [v2 PATCH 2/2] netprio_cgroup: Use memcpy instead of the for-loop to copy priomap
From: Srivatsa S. Bhat @ 2012-09-12 6:07 UTC (permalink / raw)
To: davem, nhorman
Cc: David.Laight, john.r.fastabend, gaofeng, eric.dumazet,
mark.d.rustad, lizefan, netdev, linux-kernel, srivatsa.bhat
In-Reply-To: <20120912060741.11037.37347.stgit@srivatsabhat.in.ibm.com>
Replace the current (inefficient) for-loop with memcpy, to copy priomap.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
net/core/netprio_cgroup.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index fd339bb0..83bbd0e 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -73,7 +73,6 @@ static int extend_netdev_table(struct net_device *dev, u32 new_len)
((sizeof(u32) * new_len));
struct netprio_map *new_priomap = kzalloc(new_size, GFP_KERNEL);
struct netprio_map *old_priomap;
- int i;
old_priomap = rtnl_dereference(dev->priomap);
@@ -82,10 +81,10 @@ static int extend_netdev_table(struct net_device *dev, u32 new_len)
return -ENOMEM;
}
- for (i = 0;
- old_priomap && (i < old_priomap->priomap_len);
- i++)
- new_priomap->priomap[i] = old_priomap->priomap[i];
+ if (old_priomap)
+ memcpy(new_priomap->priomap, old_priomap->priomap,
+ old_priomap->priomap_len *
+ sizeof(old_priomap->priomap[0]));
new_priomap->priomap_len = new_len;
^ permalink raw reply related
* [PATCH] iproute2: GENL: merge GENL_REQUEST and GENL_INITIALIZER
From: Julian Anastasov @ 2012-09-12 6:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Both macros are used together, so better to have
single define. Update all requests in ipl2tp.c to use the
new macro.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
include/libgenl.h | 27 +++++++++-----------
ip/ipl2tp.c | 72 +++++++++++-----------------------------------------
lib/libgenl.c | 7 ++---
3 files changed, 31 insertions(+), 75 deletions(-)
diff --git a/include/libgenl.h b/include/libgenl.h
index 0b11a89..9db4baf 100644
--- a/include/libgenl.h
+++ b/include/libgenl.h
@@ -3,25 +3,22 @@
#include "libnetlink.h"
-#define GENL_REQUEST(_req, _hdrsiz, _bufsiz) \
+#define GENL_REQUEST(_req, _bufsiz, _family, _hdrsiz, _ver, _cmd, _flags) \
struct { \
struct nlmsghdr n; \
struct genlmsghdr g; \
char buf[NLMSG_ALIGN(_hdrsiz) + (_bufsiz)]; \
-} _req
-
-#define GENL_INITIALIZER(_family, _hdrsiz, _ver, _cmd, _flags) \
- { \
- .n = { \
- .nlmsg_type = (_family), \
- .nlmsg_flags = (_flags), \
- .nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN + (_hdrsiz)), \
- }, \
- .g = { \
- .cmd = (_cmd), \
- .version = (_ver), \
- }, \
- }
+} _req = { \
+ .n = { \
+ .nlmsg_type = (_family), \
+ .nlmsg_flags = (_flags), \
+ .nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN + (_hdrsiz)), \
+ }, \
+ .g = { \
+ .cmd = (_cmd), \
+ .version = (_ver), \
+ }, \
+}
extern int genl_resolve_family(struct rtnl_handle *grth, const char *family);
diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index aaa3d31..f6e264a 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -96,9 +96,8 @@ static int create_tunnel(struct l2tp_parm *p)
uint32_t local_attr = L2TP_ATTR_IP_SADDR;
uint32_t peer_attr = L2TP_ATTR_IP_DADDR;
- GENL_REQUEST(req, 0, 1024)
- = GENL_INITIALIZER(genl_family, NLM_F_REQUEST | NLM_F_ACK, 0,
- L2TP_CMD_TUNNEL_CREATE, L2TP_GENL_VERSION);
+ GENL_REQUEST(req, 1024, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_TUNNEL_CREATE, NLM_F_REQUEST | NLM_F_ACK);
addattr32(&req.n, 1024, L2TP_ATTR_CONN_ID, p->tunnel_id);
addattr32(&req.n, 1024, L2TP_ATTR_PEER_CONN_ID, p->peer_tunnel_id);
@@ -126,9 +125,8 @@ static int create_tunnel(struct l2tp_parm *p)
static int delete_tunnel(struct l2tp_parm *p)
{
- GENL_REQUEST(req, 0, 1024)
- = GENL_INITIALIZER(genl_family, NLM_F_REQUEST | NLM_F_ACK, 0,
- L2TP_CMD_TUNNEL_DELETE, L2TP_GENL_VERSION);
+ GENL_REQUEST(req, 128, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_TUNNEL_DELETE, NLM_F_REQUEST | NLM_F_ACK);
addattr32(&req.n, 128, L2TP_ATTR_CONN_ID, p->tunnel_id);
@@ -140,18 +138,8 @@ static int delete_tunnel(struct l2tp_parm *p)
static int create_session(struct l2tp_parm *p)
{
- struct {
- struct nlmsghdr n;
- struct genlmsghdr g;
- char buf[1024];
- } req;
-
- memset(&req, 0, sizeof(req));
- req.n.nlmsg_type = genl_family;
- req.n.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
- req.n.nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN);
- req.g.cmd = L2TP_CMD_SESSION_CREATE;
- req.g.version = L2TP_GENL_VERSION;
+ GENL_REQUEST(req, 1024, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_SESSION_CREATE, NLM_F_REQUEST | NLM_F_ACK);
addattr32(&req.n, 1024, L2TP_ATTR_CONN_ID, p->tunnel_id);
addattr32(&req.n, 1024, L2TP_ATTR_PEER_CONN_ID, p->peer_tunnel_id);
@@ -182,18 +170,8 @@ static int create_session(struct l2tp_parm *p)
static int delete_session(struct l2tp_parm *p)
{
- struct {
- struct nlmsghdr n;
- struct genlmsghdr g;
- char buf[128];
- } req;
-
- memset(&req, 0, sizeof(req));
- req.n.nlmsg_type = genl_family;
- req.n.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
- req.n.nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN);
- req.g.cmd = L2TP_CMD_SESSION_DELETE;
- req.g.version = L2TP_GENL_VERSION;
+ GENL_REQUEST(req, 1024, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_SESSION_DELETE, NLM_F_REQUEST | NLM_F_ACK);
addattr32(&req.n, 1024, L2TP_ATTR_CONN_ID, p->tunnel_id);
addattr32(&req.n, 1024, L2TP_ATTR_SESSION_ID, p->session_id);
@@ -380,20 +358,11 @@ static int session_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n, void
static int get_session(struct l2tp_data *p)
{
- struct {
- struct nlmsghdr n;
- struct genlmsghdr g;
- char buf[128];
- } req;
-
- memset(&req, 0, sizeof(req));
- req.n.nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN);
- req.n.nlmsg_type = genl_family;
- req.n.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST;
- req.n.nlmsg_seq = genl_rth.dump = ++genl_rth.seq;
+ GENL_REQUEST(req, 128, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_SESSION_GET,
+ NLM_F_ROOT | NLM_F_MATCH | NLM_F_REQUEST);
- req.g.cmd = L2TP_CMD_SESSION_GET;
- req.g.version = L2TP_GENL_VERSION;
+ req.n.nlmsg_seq = genl_rth.dump = ++genl_rth.seq;
if (p->config.tunnel_id && p->config.session_id) {
addattr32(&req.n, 128, L2TP_ATTR_CONN_ID, p->config.tunnel_id);
@@ -423,20 +392,11 @@ static int tunnel_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n, void
static int get_tunnel(struct l2tp_data *p)
{
- struct {
- struct nlmsghdr n;
- struct genlmsghdr g;
- char buf[1024];
- } req;
-
- memset(&req, 0, sizeof(req));
- req.n.nlmsg_len = NLMSG_LENGTH(GENL_HDRLEN);
- req.n.nlmsg_type = genl_family;
- req.n.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST;
- req.n.nlmsg_seq = genl_rth.dump = ++genl_rth.seq;
+ GENL_REQUEST(req, 1024, genl_family, 0, L2TP_GENL_VERSION,
+ L2TP_CMD_TUNNEL_GET,
+ NLM_F_ROOT | NLM_F_MATCH | NLM_F_REQUEST);
- req.g.cmd = L2TP_CMD_TUNNEL_GET;
- req.g.version = L2TP_GENL_VERSION;
+ req.n.nlmsg_seq = genl_rth.dump = ++genl_rth.seq;
if (p->config.tunnel_id)
addattr32(&req.n, 1024, L2TP_ATTR_CONN_ID, p->config.tunnel_id);
diff --git a/lib/libgenl.c b/lib/libgenl.c
index d68e58e..ef3e5db 100644
--- a/lib/libgenl.c
+++ b/lib/libgenl.c
@@ -47,11 +47,10 @@ static int genl_parse_getfamily(struct nlmsghdr *nlh)
int genl_resolve_family(struct rtnl_handle *grth, const char *family)
{
- GENL_REQUEST(req, 0, 1024)
- = GENL_INITIALIZER(GENL_ID_CTRL, 0,
- 0, CTRL_CMD_GETFAMILY, NLM_F_REQUEST);
+ GENL_REQUEST(req, 1024, GENL_ID_CTRL, 0, 0, CTRL_CMD_GETFAMILY,
+ NLM_F_REQUEST);
- addattr_l(&req.n, 1024, CTRL_ATTR_FAMILY_NAME,
+ addattr_l(&req.n, sizeof(req), CTRL_ATTR_FAMILY_NAME,
family, strlen(family) + 1);
if (rtnl_talk(grth, &req.n, 0, 0, &req.n) < 0) {
--
1.7.3.4
^ permalink raw reply related
* Re: [V3 PATCH 9/9] cxgb4vf: Chelsio FCoE offload driver submission (header compatibility fixes).
From: Naresh Kumar Inna @ 2012-09-12 6:27 UTC (permalink / raw)
To: David Miller
Cc: JBottomley@parallels.com, linux-scsi@vger.kernel.org,
Dimitrios Michailidis, Casey Leedom, netdev@vger.kernel.org,
Chethan Seshadri
In-Reply-To: <20120912.014746.636228439025755624.davem@davemloft.net>
On 9/12/2012 11:17 AM, David Miller wrote:
> From: Naresh Kumar Inna <naresh@chelsio.com>
> Date: Wed, 12 Sep 2012 11:05:22 +0530
>
>> On 9/11/2012 11:03 PM, David Miller wrote:
>>> From: Naresh Kumar Inna <naresh@chelsio.com>
>>> Date: Tue, 11 Sep 2012 20:09:07 +0530
>>>
>>>> This patch contains minor fixes to make cxgb4vf driver work with the updates to
>>>> shared firmware/hardware header files.
>>>>
>>>> Signed-off-by: Naresh Kumar Inna <naresh@chelsio.com>
>>>
>>> You cannot submit a patch set that isn't bisectable, and in particular
>>> create a situation that mid-way through your patch set things do not
>>> build or operate correctly.
>>>
>>
>> Sorry, I am new to this process. The reason I did that was because I was
>> not sure if I could create a single patch with both cxgb4 and cxgb4vf
>> files in it, since they are two different subsystems. If I could do
>> that, the single patch then would build on its own, and not be dependent
>> on the other patches in the series. Is that something I can do?
>
> I don't know how else to say this, every step along the way the tree
> has to build. You arrange the patches however necessary to achieve
> that goal.
>
OK, I think I should be able to arrange the patch set to fulfill that
requirement. I was under the impression it was fine for new drivers to
split patches in this fashion, since they go as a single commit, sorry
about that.
As for a single patch with both cxgb4 and cxgb4vf changes, I assume it
is OK for the commit log to start with "cxgb4/cxgb4vf:..."?
Thanks,
Naresh.
^ permalink raw reply
* Re: [PATCH] net_tx_action: Call trace_consume_skb() instead of trace_kfree_skb()
From: Eric Dumazet @ 2012-09-12 7:33 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: netdev, sanagi.koki, davem
In-Reply-To: <1347406098-22071-1-git-send-email-sbohrer@rgmadvisors.com>
On Tue, 2012-09-11 at 18:28 -0500, Shawn Bohrer wrote:
> Call trace_consume_skb() instead of trace_kfree_skb() as skbs are
> removed from the completion_queue during transmit. This avoids false
> positives from dropwatch/drop_monitor making them more useful.
>
> Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
> ---
>
> In my case I seem to hit this tracepoint for every packet I transmit so
> these appear to be false positives to me. Perhaps there are cases where
> you could hit this and it is a real packet drop?
>
> net/core/dev.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8398836..00774ce 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3015,7 +3015,7 @@ static void net_tx_action(struct softirq_action *h)
> clist = clist->next;
>
> WARN_ON(atomic_read(&skb->users));
> - trace_kfree_skb(skb, net_tx_action);
> + trace_consume_skb(skb);
> __kfree_skb(skb);
> }
> }
> --
> 1.7.7.6
>
>
Problem here is : we dont know if caller of dev_kfree_skb_irq(skb)
wanted to drop or consume skb.
(We dont have a dev_consume_skb_irq(skb) function)
For example, drivers/infiniband/ulp/ipoib/ipoib_main.c function
path_free() does :
while ((skb = __skb_dequeue(&path->queue)))
dev_kfree_skb_irq(skb);
Are these packets dropped or consumed, I dont really know...
Note : NAPI drivers dont use dev_kfree_skb_irq(skb).
What is the NIC driver you are using, I thought it was mellanox (wich is
NAPI) ?
^ permalink raw reply
* Re: [PATCH net-next v3 4/4] ipv6: use DST_* macro to set obselete field
From: Eric Dumazet @ 2012-09-12 7:40 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: vyasevich, davem, sds, james.l.morris, eparis, sri, linux-sctp,
netdev
In-Reply-To: <1347350987-8054-5-git-send-email-nicolas.dichtel@6wind.com>
On Tue, 2012-09-11 at 10:09 +0200, Nicolas Dichtel wrote:
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> net/ipv6/route.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 561f249..0c6f132 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -226,7 +226,7 @@ static struct rt6_info ip6_null_entry_template = {
> .dst = {
> .__refcnt = ATOMIC_INIT(1),
> .__use = 1,
> - .obsolete = -1,
> + .obsolete = DST_OBSOLETE_FORCE_CHK,
> .error = -ENETUNREACH,
> .input = ip6_pkt_discard,
> .output = ip6_pkt_discard_out,
> @@ -246,7 +246,7 @@ static struct rt6_info ip6_prohibit_entry_template = {
> .dst = {
> .__refcnt = ATOMIC_INIT(1),
> .__use = 1,
> - .obsolete = -1,
> + .obsolete = DST_OBSOLETE_FORCE_CHK,
> .error = -EACCES,
> .input = ip6_pkt_prohibit,
> .output = ip6_pkt_prohibit_out,
> @@ -261,7 +261,7 @@ static struct rt6_info ip6_blk_hole_entry_template = {
> .dst = {
> .__refcnt = ATOMIC_INIT(1),
> .__use = 1,
> - .obsolete = -1,
> + .obsolete = DST_OBSOLETE_FORCE_CHK,
> .error = -EINVAL,
> .input = dst_discard,
> .output = dst_discard,
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH] ipv6: replace write lock with read lock when get route info
From: Eric Dumazet @ 2012-09-12 7:45 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1347427553-17781-1-git-send-email-roy.qing.li@gmail.com>
On Wed, 2012-09-12 at 13:25 +0800, roy.qing.li@gmail.com wrote:
> From: Li RongQing <roy.qing.li@gmail.com>
>
> geting route info does not write rt->rt6i_table, so replace
> write lock with read lock
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
> ---
> net/ipv6/route.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 399613b..8be1d86 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1837,7 +1837,7 @@ static struct rt6_info *rt6_get_route_info(struct net *net,
> if (!table)
> return NULL;
>
> - write_lock_bh(&table->tb6_lock);
> + read_lock_bh(&table->tb6_lock);
> fn = fib6_locate(&table->tb6_root, prefix ,prefixlen, NULL, 0);
> if (!fn)
> goto out;
> @@ -1853,7 +1853,7 @@ static struct rt6_info *rt6_get_route_info(struct net *net,
> break;
> }
> out:
> - write_unlock_bh(&table->tb6_lock);
> + read_unlock_bh(&table->tb6_lock);
> return rt;
> }
>
> @@ -1896,7 +1896,7 @@ struct rt6_info *rt6_get_dflt_router(const struct in6_addr *addr, struct net_dev
> if (!table)
> return NULL;
>
> - write_lock_bh(&table->tb6_lock);
> + read_lock_bh(&table->tb6_lock);
> for (rt = table->tb6_root.leaf; rt; rt=rt->dst.rt6_next) {
> if (dev == rt->dst.dev &&
> ((rt->rt6i_flags & (RTF_ADDRCONF | RTF_DEFAULT)) == (RTF_ADDRCONF | RTF_DEFAULT)) &&
> @@ -1905,7 +1905,7 @@ struct rt6_info *rt6_get_dflt_router(const struct in6_addr *addr, struct net_dev
> }
> if (rt)
> dst_hold(&rt->dst);
> - write_unlock_bh(&table->tb6_lock);
> + read_unlock_bh(&table->tb6_lock);
> return rt;
> }
>
Why dont you also change addrconf_get_prefix_route() ?
^ permalink raw reply
* [PATCH] netfilter/iptables: Fix log-level processing
From: Joe Perches @ 2012-09-12 7:46 UTC (permalink / raw)
To: auto75914331, Bart De Schuymer, Pablo Neira Ayuso,
Patrick McHardy, Stephen Hemminger
Cc: netfilter-devel, netfilter, coreteam, bridge, netdev,
linux-kernel
In-Reply-To: <20120912045120.9E1A76F446@smtp.hushmail.com>
auto75914331@hushmail.com reports that iptables does not correctly
output the KERN_<level>.
$IPTABLES -A RULE_0_in -j LOG --log-level notice --log-prefix "DENY in: "
result with linux 3.6-rc5
Sep 12 06:37:29 xxxxx kernel: <5>DENY in: IN=eth0 OUT= MAC=.......
result with linux 3.5.3 and older:
Sep 9 10:43:01 xxxxx kernel: DENY in: IN=eth0 OUT= MAC......
commit 04d2c8c83d0
("printk: convert the format for KERN_<LEVEL> to a 2 byte pattern")
updated the syslog header style but did not update netfilter uses.
Do so.
Signed-off-by: Joe Perches <joe@perches.com>
cc: auto75914331@hushmail.com
---
net/bridge/netfilter/ebt_log.c | 4 ++--
net/netfilter/xt_LOG.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/bridge/netfilter/ebt_log.c b/net/bridge/netfilter/ebt_log.c
index f88ee53..cb46d2f 100644
--- a/net/bridge/netfilter/ebt_log.c
+++ b/net/bridge/netfilter/ebt_log.c
@@ -80,8 +80,8 @@ ebt_log_packet(u_int8_t pf, unsigned int hooknum,
unsigned int bitmask;
spin_lock_bh(&ebt_log_lock);
- printk("<%c>%s IN=%s OUT=%s MAC source = %pM MAC dest = %pM proto = 0x%04x",
- '0' + loginfo->u.log.level, prefix,
+ printk("%c%c%s IN=%s OUT=%s MAC source = %pM MAC dest = %pM proto = 0x%04x",
+ KERN_SOH_ASCII, '0' + loginfo->u.log.level, prefix,
in ? in->name : "", out ? out->name : "",
eth_hdr(skb)->h_source, eth_hdr(skb)->h_dest,
ntohs(eth_hdr(skb)->h_proto));
diff --git a/net/netfilter/xt_LOG.c b/net/netfilter/xt_LOG.c
index ff5f75f..bdc5352 100644
--- a/net/netfilter/xt_LOG.c
+++ b/net/netfilter/xt_LOG.c
@@ -436,8 +436,8 @@ log_packet_common(struct sbuff *m,
const struct nf_loginfo *loginfo,
const char *prefix)
{
- sb_add(m, "<%d>%sIN=%s OUT=%s ", loginfo->u.log.level,
- prefix,
+ sb_add(m, "%c%c%sIN=%s OUT=%s ",
+ KERN_SOH_ASCII, '0' + loginfo->u.log.level, prefix,
in ? in->name : "",
out ? out->name : "");
#ifdef CONFIG_BRIDGE_NETFILTER
^ permalink raw reply related
* [PATCH net-next] ipv6: route templates can be const
From: Eric Dumazet @ 2012-09-12 7:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
We kmemdup() templates, so they can be const.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/route.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 399613b..f568ac6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -222,7 +222,7 @@ static const u32 ip6_template_metrics[RTAX_MAX] = {
[RTAX_HOPLIMIT - 1] = 255,
};
-static struct rt6_info ip6_null_entry_template = {
+static const struct rt6_info ip6_null_entry_template = {
.dst = {
.__refcnt = ATOMIC_INIT(1),
.__use = 1,
@@ -242,7 +242,7 @@ static struct rt6_info ip6_null_entry_template = {
static int ip6_pkt_prohibit(struct sk_buff *skb);
static int ip6_pkt_prohibit_out(struct sk_buff *skb);
-static struct rt6_info ip6_prohibit_entry_template = {
+static const struct rt6_info ip6_prohibit_entry_template = {
.dst = {
.__refcnt = ATOMIC_INIT(1),
.__use = 1,
@@ -257,7 +257,7 @@ static struct rt6_info ip6_prohibit_entry_template = {
.rt6i_ref = ATOMIC_INIT(1),
};
-static struct rt6_info ip6_blk_hole_entry_template = {
+static const struct rt6_info ip6_blk_hole_entry_template = {
.dst = {
.__refcnt = ATOMIC_INIT(1),
.__use = 1,
^ permalink raw reply related
* Re: [v2 PATCH 2/2] netprio_cgroup: Use memcpy instead of the for-loop to copy priomap
From: David Miller @ 2012-09-12 7:49 UTC (permalink / raw)
To: srivatsa.bhat
Cc: nhorman, David.Laight, john.r.fastabend, gaofeng, eric.dumazet,
mark.d.rustad, lizefan, netdev, linux-kernel
In-Reply-To: <20120912060747.11037.42623.stgit@srivatsabhat.in.ibm.com>
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Date: Wed, 12 Sep 2012 11:37:47 +0530
> + memcpy(new_priomap->priomap, old_priomap->priomap,
> + old_priomap->priomap_len *
> + sizeof(old_priomap->priomap[0]));
This argument indentation is ridiculous. Try:
memcpy(new_priomap->priomap, old_priomap->priomap,
old_priomap->priomap_len *
sizeof(old_priomap->priomap[0]));
Using TABs exclusively for argumentat indentation is not the goal.
Rather, lining the arguments up properly so that they sit at the first
column after the first line's openning parenthesis is what you should
be trying to achieve.
And ignoring whatever stylistic convention we may or may not have, I
find it impossibly hard to believe that the code quoted above looks
good even to you.
^ permalink raw reply
* Re: [PATCH] ipv6: replace write lock with read lock when get route info
From: RongQing Li @ 2012-09-12 7:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1347435907.13103.693.camel@edumazet-glaptop>
>>
>
> Why dont you also change addrconf_get_prefix_route() ?
>
>
I did not find it, I will send v2
Thanks
-Roy
^ permalink raw reply
* Re: [PATCHv4] virtio-spec: virtio network device multiqueue support
From: Michael S. Tsirkin @ 2012-09-12 7:57 UTC (permalink / raw)
To: Rusty Russell
Cc: kvm, netdev, rick.jones2, virtualization, levinsasha928, pbonzini,
Tom Herbert
In-Reply-To: <87har3dc4o.fsf@rustcorp.com.au>
On Wed, Sep 12, 2012 at 03:19:11PM +0930, Rusty Russell wrote:
> Jason Wang <jasowang@redhat.com> writes:
> > On 09/10/2012 02:33 PM, Michael S. Tsirkin wrote:
> >> A final addition: what you suggest above would be
> >> "TX follows RX", right?
>
> BTW, yes. But it's a weird way to express what the nic is doing.
It explains what the system is doing.
TX is done by driver, RX by nic.
We document both driver and device in the spec
so I thought it's fine. any suggestions wellcome.
> >> It is in anticipation of something like that, that I made
> >> steering programming so generic.
>
> >> I think TX follows RX is more immediately useful for reasons above
> >> but we can add both to spec and let drivers and devices
> >> decide what they want to support.
>
> You mean "RX follows TX"? ie. accelerated RFS. I agree.
Yes that's what I meant. Thanks for the correction.
> Perhaps Tom can explain how we avoid out-of-order receive for the
> accelerated RFS case? It's not clear to me, but we need to be able to
> do that for virtio-net if it implements accelerated RFS.
Basically this has tx vq per cpu and relies on scheduler not bouncing threads
between cpus too aggressively. Appears to be what ixgbe does.
> > AFAIK, ixgbe does "rx follows tx". The only differences between ixgbe
> > and virtio-net is that ixgbe driver programs the flow director during
> > packet transmission but we suggest to do it silently in the device for
> > simplicity.
>
> Implying the receive queue by xmit will be slightly laggy. Don't know
> if that's a problem.
>
> Cheers,
> Rusty.
Doesn't seem to be a problem in Jason's testing so far.
^ permalink raw reply
* [PATCH v2] ipv6: replace write lock with read lock when get route info
From: roy.qing.li @ 2012-09-12 7:59 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
geting route info does not write rt->rt6i_table, so replace
write lock with read lock
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/ipv6/addrconf.c | 4 ++--
net/ipv6/route.c | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 1237d5d..061c100 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1706,7 +1706,7 @@ static struct rt6_info *addrconf_get_prefix_route(const struct in6_addr *pfx,
if (table == NULL)
return NULL;
- write_lock_bh(&table->tb6_lock);
+ read_lock_bh(&table->tb6_lock);
fn = fib6_locate(&table->tb6_root, pfx, plen, NULL, 0);
if (!fn)
goto out;
@@ -1721,7 +1721,7 @@ static struct rt6_info *addrconf_get_prefix_route(const struct in6_addr *pfx,
break;
}
out:
- write_unlock_bh(&table->tb6_lock);
+ read_unlock_bh(&table->tb6_lock);
return rt;
}
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 399613b..8be1d86 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1837,7 +1837,7 @@ static struct rt6_info *rt6_get_route_info(struct net *net,
if (!table)
return NULL;
- write_lock_bh(&table->tb6_lock);
+ read_lock_bh(&table->tb6_lock);
fn = fib6_locate(&table->tb6_root, prefix ,prefixlen, NULL, 0);
if (!fn)
goto out;
@@ -1853,7 +1853,7 @@ static struct rt6_info *rt6_get_route_info(struct net *net,
break;
}
out:
- write_unlock_bh(&table->tb6_lock);
+ read_unlock_bh(&table->tb6_lock);
return rt;
}
@@ -1896,7 +1896,7 @@ struct rt6_info *rt6_get_dflt_router(const struct in6_addr *addr, struct net_dev
if (!table)
return NULL;
- write_lock_bh(&table->tb6_lock);
+ read_lock_bh(&table->tb6_lock);
for (rt = table->tb6_root.leaf; rt; rt=rt->dst.rt6_next) {
if (dev == rt->dst.dev &&
((rt->rt6i_flags & (RTF_ADDRCONF | RTF_DEFAULT)) == (RTF_ADDRCONF | RTF_DEFAULT)) &&
@@ -1905,7 +1905,7 @@ struct rt6_info *rt6_get_dflt_router(const struct in6_addr *addr, struct net_dev
}
if (rt)
dst_hold(&rt->dst);
- write_unlock_bh(&table->tb6_lock);
+ read_unlock_bh(&table->tb6_lock);
return rt;
}
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] netfilter/iptables: Fix log-level processing
From: Eric Dumazet @ 2012-09-12 8:07 UTC (permalink / raw)
To: Joe Perches
Cc: auto75914331, netfilter, coreteam, netdev, bridge, linux-kernel,
Bart De Schuymer, netfilter-devel, Stephen Hemminger,
Patrick McHardy, Pablo Neira Ayuso
In-Reply-To: <1347435973.2456.23.camel@joe2Laptop>
On Wed, 2012-09-12 at 00:46 -0700, Joe Perches wrote:
> auto75914331@hushmail.com reports that iptables does not correctly
> output the KERN_<level>.
>
> $IPTABLES -A RULE_0_in -j LOG --log-level notice --log-prefix "DENY in: "
>
> result with linux 3.6-rc5
> Sep 12 06:37:29 xxxxx kernel: <5>DENY in: IN=eth0 OUT= MAC=.......
>
> result with linux 3.5.3 and older:
> Sep 9 10:43:01 xxxxx kernel: DENY in: IN=eth0 OUT= MAC......
>
> commit 04d2c8c83d0
> ("printk: convert the format for KERN_<LEVEL> to a 2 byte pattern")
> updated the syslog header style but did not update netfilter uses.
>
> Do so.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> cc: auto75914331@hushmail.com
> ---
> net/bridge/netfilter/ebt_log.c | 4 ++--
> net/netfilter/xt_LOG.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/bridge/netfilter/ebt_log.c b/net/bridge/netfilter/ebt_log.c
> index f88ee53..cb46d2f 100644
> --- a/net/bridge/netfilter/ebt_log.c
> +++ b/net/bridge/netfilter/ebt_log.c
> @@ -80,8 +80,8 @@ ebt_log_packet(u_int8_t pf, unsigned int hooknum,
> unsigned int bitmask;
>
> spin_lock_bh(&ebt_log_lock);
> - printk("<%c>%s IN=%s OUT=%s MAC source = %pM MAC dest = %pM proto = 0x%04x",
> - '0' + loginfo->u.log.level, prefix,
> + printk("%c%c%s IN=%s OUT=%s MAC source = %pM MAC dest = %pM proto = 0x%04x",
> + KERN_SOH_ASCII, '0' + loginfo->u.log.level, prefix,
> in ? in->name : "", out ? out->name : "",
> eth_hdr(skb)->h_source, eth_hdr(skb)->h_dest,
> ntohs(eth_hdr(skb)->h_proto));
> diff --git a/net/netfilter/xt_LOG.c b/net/netfilter/xt_LOG.c
> index ff5f75f..bdc5352 100644
> --- a/net/netfilter/xt_LOG.c
> +++ b/net/netfilter/xt_LOG.c
> @@ -436,8 +436,8 @@ log_packet_common(struct sbuff *m,
> const struct nf_loginfo *loginfo,
> const char *prefix)
> {
> - sb_add(m, "<%d>%sIN=%s OUT=%s ", loginfo->u.log.level,
> - prefix,
> + sb_add(m, "%c%c%sIN=%s OUT=%s ",
> + KERN_SOH_ASCII, '0' + loginfo->u.log.level, prefix,
> in ? in->name : "",
> out ? out->name : "");
> #ifdef CONFIG_BRIDGE_NETFILTER
>
would be better to avoid the %c
->
sb_add(m, KERN_SOH "%c%sIN=%s OUT=%s ",
'0' + loginfo->u.log.level, prefix,
^ permalink raw reply
* Re: [PATCH v2] ipv6: replace write lock with read lock when get route info
From: Eric Dumazet @ 2012-09-12 8:12 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1347436741-344-1-git-send-email-roy.qing.li@gmail.com>
On Wed, 2012-09-12 at 15:59 +0800, roy.qing.li@gmail.com wrote:
> From: Li RongQing <roy.qing.li@gmail.com>
>
> geting route info does not write rt->rt6i_table, so replace
> write lock with read lock
>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
> ---
> net/ipv6/addrconf.c | 4 ++--
> net/ipv6/route.c | 8 ++++----
> 2 files changed, 6 insertions(+), 6 deletions(-)
I guess you missed the net-next tag in your [PATCH ...] ?
Signed-off-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [v2 PATCH 2/2] netprio_cgroup: Use memcpy instead of the for-loop to copy priomap
From: Srivatsa S. Bhat @ 2012-09-12 8:24 UTC (permalink / raw)
To: David Miller
Cc: nhorman, David.Laight, john.r.fastabend, gaofeng, eric.dumazet,
mark.d.rustad, lizefan, netdev, linux-kernel
In-Reply-To: <20120912.034901.184817520125489015.davem@davemloft.net>
On 09/12/2012 01:19 PM, David Miller wrote:
> From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> Date: Wed, 12 Sep 2012 11:37:47 +0530
>
>> + memcpy(new_priomap->priomap, old_priomap->priomap,
>> + old_priomap->priomap_len *
>> + sizeof(old_priomap->priomap[0]));
>
> This argument indentation is ridiculous. Try:
>
> memcpy(new_priomap->priomap, old_priomap->priomap,
> old_priomap->priomap_len *
> sizeof(old_priomap->priomap[0]));
>
> Using TABs exclusively for argumentat indentation is not the goal.
>
> Rather, lining the arguments up properly so that they sit at the first
> column after the first line's openning parenthesis is what you should
> be trying to achieve.
OK, will fix it, thanks!
>
> And ignoring whatever stylistic convention we may or may not have, I
> find it impossibly hard to believe that the code quoted above looks
> good even to you.
>
On second thoughts, I think the memcpy in this case will actually be worse
since it will copy the contents in chunks of smaller size than the for-loop.
Or, did you mean to say that this code is plain wrong for some reason?
Regards,
Srivatsa S. Bhat
^ 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