* RE: mdiobus_register() issue for an SMSC8720a PHY
From: ANDY KENNEDY @ 2011-04-06 21:03 UTC (permalink / raw)
To: netdev
In-Reply-To: <9AC3F0E75060224C8BBC5BA2DDC8853A1FA0C0C6@EXV1.corp.adtran.com>
> ====== get_device_parent:689
> dev = 0x8781da40
> dev->class = 0x803c2ad4
> dev->class->p = 0x00000000
> dev->class->p->class_dirs = 0x00000048
Ughh. I deleted a line of text from the e-mail I sent. I found my
problem. The line of text that would have given all of you the answer
quickly was this:
The below code is from arch/mips/<myboard>/platform.c.
Perhaps this is vague, so I'll clarify. I start this process from the
board level configuration, therefore the mdio class (which gets created
in the init of mdiobus) isn't -- thus class->p is empty.
So, now I just need to relocate this code to some "real" network driver,
I guess.
Andy
^ permalink raw reply
* [PATCH] capi: Perform scheduled capifs removal
From: Jan Kiszka @ 2011-04-06 20:58 UTC (permalink / raw)
To: netdev; +Cc: Amerigo Wang, Karsten Keil, David S. Miller
In-Reply-To: <1302080739-4029-1-git-send-email-amwang@redhat.com>
udev fully replaces this special file system that only contains CAPI
NCCI TTY device nodes. User space (pppdcapiplugin) works without
noticing the difference.
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
---
I had this version queued locally for quite a while but then forgot to
post it... Thanks for bringing this topic up, Amerigo, but your patch
was missing a few remaining fragments.
Documentation/feature-removal-schedule.txt | 10 --
drivers/isdn/capi/Kconfig | 15 --
drivers/isdn/capi/Makefile | 1 -
drivers/isdn/capi/capi.c | 24 +---
drivers/isdn/capi/capifs.c | 239 ----------------------------
drivers/isdn/capi/capifs.h | 28 ----
6 files changed, 4 insertions(+), 313 deletions(-)
delete mode 100644 drivers/isdn/capi/capifs.c
delete mode 100644 drivers/isdn/capi/capifs.h
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 274b32d..e38ccae 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -425,16 +425,6 @@ Who: anybody or Florian Mickler <florian@mickler.org>
----------------------------
-What: capifs
-When: February 2011
-Files: drivers/isdn/capi/capifs.*
-Why: udev fully replaces this special file system that only contains CAPI
- NCCI TTY device nodes. User space (pppdcapiplugin) works without
- noticing the difference.
-Who: Jan Kiszka <jan.kiszka@web.de>
-
-----------------------------
-
What: KVM paravirt mmu host support
When: January 2011
Why: The paravirt mmu host support is slower than non-paravirt mmu, both
diff --git a/drivers/isdn/capi/Kconfig b/drivers/isdn/capi/Kconfig
index a168e8a..15c3ffd 100644
--- a/drivers/isdn/capi/Kconfig
+++ b/drivers/isdn/capi/Kconfig
@@ -33,21 +33,6 @@ config ISDN_CAPI_CAPI20
standardized libcapi20 to access this functionality. You should say
Y/M here.
-config ISDN_CAPI_CAPIFS_BOOL
- bool "CAPI2.0 filesystem support (DEPRECATED)"
- depends on ISDN_CAPI_MIDDLEWARE && ISDN_CAPI_CAPI20
- help
- This option provides a special file system, similar to /dev/pts with
- device nodes for the special ttys established by using the
- middleware extension above.
- You no longer need this, udev fully replaces it. This feature is
- scheduled for removal.
-
-config ISDN_CAPI_CAPIFS
- tristate
- depends on ISDN_CAPI_CAPIFS_BOOL
- default ISDN_CAPI_CAPI20
-
config ISDN_CAPI_CAPIDRV
tristate "CAPI2.0 capidrv interface support"
depends on ISDN_I4L
diff --git a/drivers/isdn/capi/Makefile b/drivers/isdn/capi/Makefile
index 57123e3..4d5b4b7 100644
--- a/drivers/isdn/capi/Makefile
+++ b/drivers/isdn/capi/Makefile
@@ -7,7 +7,6 @@
obj-$(CONFIG_ISDN_CAPI) += kernelcapi.o
obj-$(CONFIG_ISDN_CAPI_CAPI20) += capi.o
obj-$(CONFIG_ISDN_CAPI_CAPIDRV) += capidrv.o
-obj-$(CONFIG_ISDN_CAPI_CAPIFS) += capifs.o
# Multipart objects.
diff --git a/drivers/isdn/capi/capi.c b/drivers/isdn/capi/capi.c
index 0d70883..bea1009 100644
--- a/drivers/isdn/capi/capi.c
+++ b/drivers/isdn/capi/capi.c
@@ -38,8 +38,6 @@
#include <linux/isdn/capiutil.h>
#include <linux/isdn/capicmd.h>
-#include "capifs.h"
-
MODULE_DESCRIPTION("CAPI4Linux: Userspace /dev/capi20 interface");
MODULE_AUTHOR("Carsten Paeth");
MODULE_LICENSE("GPL");
@@ -85,7 +83,6 @@ struct capiminor {
struct kref kref;
unsigned int minor;
- struct dentry *capifs_dentry;
struct capi20_appl *ap;
u32 ncci;
@@ -300,17 +297,8 @@ static void capiminor_free(struct capiminor *mp)
static void capincci_alloc_minor(struct capidev *cdev, struct capincci *np)
{
- struct capiminor *mp;
- dev_t device;
-
- if (!(cdev->userflags & CAPIFLAG_HIGHJACKING))
- return;
-
- mp = np->minorp = capiminor_alloc(&cdev->ap, np->ncci);
- if (mp) {
- device = MKDEV(capinc_tty_driver->major, mp->minor);
- mp->capifs_dentry = capifs_new_ncci(mp->minor, device);
- }
+ if (cdev->userflags & CAPIFLAG_HIGHJACKING)
+ np->minorp = capiminor_alloc(&cdev->ap, np->ncci);
}
static void capincci_free_minor(struct capincci *np)
@@ -319,8 +307,6 @@ static void capincci_free_minor(struct capincci *np)
struct tty_struct *tty;
if (mp) {
- capifs_free_ncci(mp->capifs_dentry);
-
tty = tty_port_tty_get(&mp->port);
if (tty) {
tty_vhangup(tty);
@@ -1514,10 +1500,8 @@ static int __init capi_init(void)
proc_init();
-#if defined(CONFIG_ISDN_CAPI_CAPIFS) || defined(CONFIG_ISDN_CAPI_CAPIFS_MODULE)
- compileinfo = " (middleware+capifs)";
-#elif defined(CONFIG_ISDN_CAPI_MIDDLEWARE)
- compileinfo = " (no capifs)";
+#ifdef CONFIG_ISDN_CAPI_MIDDLEWARE
+ compileinfo = " (middleware)";
#else
compileinfo = " (no middleware)";
#endif
diff --git a/drivers/isdn/capi/capifs.c b/drivers/isdn/capi/capifs.c
deleted file mode 100644
index b4faed7..0000000
--- a/drivers/isdn/capi/capifs.c
+++ /dev/null
@@ -1,239 +0,0 @@
-/* $Id: capifs.c,v 1.1.2.3 2004/01/16 21:09:26 keil Exp $
- *
- * Copyright 2000 by Carsten Paeth <calle@calle.de>
- *
- * Heavily based on devpts filesystem from H. Peter Anvin
- *
- * This software may be used and distributed according to the terms
- * of the GNU General Public License, incorporated herein by reference.
- *
- */
-
-#include <linux/fs.h>
-#include <linux/mount.h>
-#include <linux/slab.h>
-#include <linux/namei.h>
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/ctype.h>
-#include <linux/sched.h> /* current */
-
-#include "capifs.h"
-
-MODULE_DESCRIPTION("CAPI4Linux: /dev/capi/ filesystem");
-MODULE_AUTHOR("Carsten Paeth");
-MODULE_LICENSE("GPL");
-
-/* ------------------------------------------------------------------ */
-
-#define CAPIFS_SUPER_MAGIC (('C'<<8)|'N')
-
-static struct vfsmount *capifs_mnt;
-static int capifs_mnt_count;
-
-static struct {
- int setuid;
- int setgid;
- uid_t uid;
- gid_t gid;
- umode_t mode;
-} config = {.mode = 0600};
-
-/* ------------------------------------------------------------------ */
-
-static int capifs_remount(struct super_block *s, int *flags, char *data)
-{
- int setuid = 0;
- int setgid = 0;
- uid_t uid = 0;
- gid_t gid = 0;
- umode_t mode = 0600;
- char *this_char;
- char *new_opt = kstrdup(data, GFP_KERNEL);
-
- this_char = NULL;
- while ((this_char = strsep(&data, ",")) != NULL) {
- int n;
- char dummy;
- if (!*this_char)
- continue;
- if (sscanf(this_char, "uid=%i%c", &n, &dummy) == 1) {
- setuid = 1;
- uid = n;
- } else if (sscanf(this_char, "gid=%i%c", &n, &dummy) == 1) {
- setgid = 1;
- gid = n;
- } else if (sscanf(this_char, "mode=%o%c", &n, &dummy) == 1)
- mode = n & ~S_IFMT;
- else {
- kfree(new_opt);
- printk("capifs: called with bogus options\n");
- return -EINVAL;
- }
- }
-
- mutex_lock(&s->s_root->d_inode->i_mutex);
-
- replace_mount_options(s, new_opt);
- config.setuid = setuid;
- config.setgid = setgid;
- config.uid = uid;
- config.gid = gid;
- config.mode = mode;
-
- mutex_unlock(&s->s_root->d_inode->i_mutex);
-
- return 0;
-}
-
-static const struct super_operations capifs_sops =
-{
- .statfs = simple_statfs,
- .remount_fs = capifs_remount,
- .show_options = generic_show_options,
-};
-
-
-static int
-capifs_fill_super(struct super_block *s, void *data, int silent)
-{
- struct inode * inode;
-
- s->s_blocksize = 1024;
- s->s_blocksize_bits = 10;
- s->s_magic = CAPIFS_SUPER_MAGIC;
- s->s_op = &capifs_sops;
- s->s_time_gran = 1;
-
- inode = new_inode(s);
- if (!inode)
- goto fail;
- inode->i_ino = 1;
- inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
- inode->i_mode = S_IFDIR | S_IRUGO | S_IXUGO | S_IWUSR;
- inode->i_op = &simple_dir_inode_operations;
- inode->i_fop = &simple_dir_operations;
- inode->i_nlink = 2;
-
- s->s_root = d_alloc_root(inode);
- if (s->s_root)
- return 0;
-
- printk("capifs: get root dentry failed\n");
- iput(inode);
-fail:
- return -ENOMEM;
-}
-
-static struct dentry *capifs_mount(struct file_system_type *fs_type,
- int flags, const char *dev_name, void *data)
-{
- return mount_single(fs_type, flags, data, capifs_fill_super);
-}
-
-static struct file_system_type capifs_fs_type = {
- .owner = THIS_MODULE,
- .name = "capifs",
- .mount = capifs_mount,
- .kill_sb = kill_anon_super,
-};
-
-static struct dentry *new_ncci(unsigned int number, dev_t device)
-{
- struct super_block *s = capifs_mnt->mnt_sb;
- struct dentry *root = s->s_root;
- struct dentry *dentry;
- struct inode *inode;
- char name[10];
- int namelen;
-
- mutex_lock(&root->d_inode->i_mutex);
-
- namelen = sprintf(name, "%d", number);
- dentry = lookup_one_len(name, root, namelen);
- if (IS_ERR(dentry)) {
- dentry = NULL;
- goto unlock_out;
- }
-
- if (dentry->d_inode) {
- dput(dentry);
- dentry = NULL;
- goto unlock_out;
- }
-
- inode = new_inode(s);
- if (!inode) {
- dput(dentry);
- dentry = NULL;
- goto unlock_out;
- }
-
- /* config contents is protected by root's i_mutex */
- inode->i_uid = config.setuid ? config.uid : current_fsuid();
- inode->i_gid = config.setgid ? config.gid : current_fsgid();
- inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
- inode->i_ino = number + 2;
- init_special_inode(inode, S_IFCHR|config.mode, device);
-
- d_instantiate(dentry, inode);
- dget(dentry);
-
-unlock_out:
- mutex_unlock(&root->d_inode->i_mutex);
-
- return dentry;
-}
-
-struct dentry *capifs_new_ncci(unsigned int number, dev_t device)
-{
- struct dentry *dentry;
-
- if (simple_pin_fs(&capifs_fs_type, &capifs_mnt, &capifs_mnt_count) < 0)
- return NULL;
-
- dentry = new_ncci(number, device);
- if (!dentry)
- simple_release_fs(&capifs_mnt, &capifs_mnt_count);
-
- return dentry;
-}
-
-void capifs_free_ncci(struct dentry *dentry)
-{
- struct dentry *root = capifs_mnt->mnt_sb->s_root;
- struct inode *inode;
-
- if (!dentry)
- return;
-
- mutex_lock(&root->d_inode->i_mutex);
-
- inode = dentry->d_inode;
- if (inode) {
- drop_nlink(inode);
- d_delete(dentry);
- dput(dentry);
- }
- dput(dentry);
-
- mutex_unlock(&root->d_inode->i_mutex);
-
- simple_release_fs(&capifs_mnt, &capifs_mnt_count);
-}
-
-static int __init capifs_init(void)
-{
- return register_filesystem(&capifs_fs_type);
-}
-
-static void __exit capifs_exit(void)
-{
- unregister_filesystem(&capifs_fs_type);
-}
-
-EXPORT_SYMBOL(capifs_new_ncci);
-EXPORT_SYMBOL(capifs_free_ncci);
-
-module_init(capifs_init);
-module_exit(capifs_exit);
diff --git a/drivers/isdn/capi/capifs.h b/drivers/isdn/capi/capifs.h
deleted file mode 100644
index e193d11..0000000
--- a/drivers/isdn/capi/capifs.h
+++ /dev/null
@@ -1,28 +0,0 @@
-/* $Id: capifs.h,v 1.1.2.2 2004/01/16 21:09:26 keil Exp $
- *
- * Copyright 2000 by Carsten Paeth <calle@calle.de>
- *
- * This software may be used and distributed according to the terms
- * of the GNU General Public License, incorporated herein by reference.
- *
- */
-
-#include <linux/dcache.h>
-
-#if defined(CONFIG_ISDN_CAPI_CAPIFS) || defined(CONFIG_ISDN_CAPI_CAPIFS_MODULE)
-
-struct dentry *capifs_new_ncci(unsigned int num, dev_t device);
-void capifs_free_ncci(struct dentry *dentry);
-
-#else
-
-static inline struct dentry *capifs_new_ncci(unsigned int num, dev_t device)
-{
- return NULL;
-}
-
-static inline void capifs_free_ncci(struct dentry *dentry)
-{
-}
-
-#endif
--
1.7.1
^ permalink raw reply related
* iputils git access broken?
From: Andrew Walrond @ 2011-04-06 21:32 UTC (permalink / raw)
To: netdev
I can't seem to clone the repo, although I can see source on gitweb.
$ git clone git://git.linux-ipv6.org/gitroot/iputils.git
Cloning into iputils...
git.linux-ipv6.org[0: 203.178.142.218]: errno=Connection refused
git.linux-ipv6.org[0: 2001:200:0:1c01:20f:1fff:fe67:32e9]: errno=Network is unreachable
fatal: unable to connect a socket (Network is unreachable)
Is something amiss?
Andrew Walrond
(cc me please; I'm not subscribed)
^ permalink raw reply
* Re: Kernel crash in 2.6.39-rc2-wl
From: Eric Dumazet @ 2011-04-06 20:54 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4D9CCD72.7020308@candelatech.com>
Le mercredi 06 avril 2011 à 13:30 -0700, Ben Greear a écrit :
> This is from today's wireless-testing kernel, with a few non-tainting
> patches related to wireless stuff. In general, 39-rc2 seems pretty
> flaky, but on this boot, this is the first kernel splat.
>
> I had reloaded our user-space network-config DB, which would have deleted
> and created some VETH and MAC-VLAN interfaces, and a bunch of
> protocol sockets, virtual-routers (xorp with unique routing tables) etc.
>
>
> BUG: unable to handle kernel paging request at 50435453
> IP: [<c04d8ac6>] __kmalloc_track_caller+0xd8/0x117
> *pde = 00000000
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0/block/sda/sda1/stat
> Modules linked in: xt_CT iptable_raw xt_DSCP xt_dscp xt_string xt_owner xt_NFQUEUE xt_multiport xt_mark xt_iprange xt_hashlimit xt_connmark xt_addrty]
>
> Pid: 12747, comm: xorp_rtrmgr Not tainted 2.6.39-rc2-wl+ #56 To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
> EIP: 0060:[<c04d8ac6>] EFLAGS: 00210206 CPU: 0
> EIP is at __kmalloc_track_caller+0xd8/0x117
> EAX: c0b18ee0 EBX: f5402500 ECX: 0001d3c9 EDX: 00000000
> ESI: 50435453 EDI: 0001d3c8 EBP: f17ddd00 ESP: f17ddce8
> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process xorp_rtrmgr (pid: 12747, ti=f17dc000 task=f147bde0 task.ti=f17dc000)
> Stack:
> c07869c6 000000d0 000001fc f1284fc0 000000d0 f5487f80 f17ddd1c c07468b9
> 00000001 00000140 f15e0000 f15e0000 00000000 f17ddd34 c07869c6 ffffffff
> f15e0000 00010000 f17ddd88 f17ddd98 c0787005 00004040 00000000 00000002
> Call Trace:
> [<c07869c6>] ? sk_stream_alloc_skb+0x2c/0xc4
> [<c07468b9>] __alloc_skb+0x5d/0xf9
> [<c07869c6>] sk_stream_alloc_skb+0x2c/0xc4
> [<c0787005>] tcp_sendmsg+0x16d/0x714
> [<c07a1776>] inet_sendmsg+0x55/0x5e
> [<c073ef79>] __sock_sendmsg+0x56/0x5f
> [<c073f608>] sock_sendmsg+0x98/0xac
> [<c0461879>] ? mark_lock+0x1e/0x1de
> [<c042b66d>] ? pick_next_highest_task_rt+0x148/0x148
> [<c04e643e>] ? fget_light+0x30/0xa4
> [<c073f686>] ? sockfd_lookup_light+0x1b/0x4b
> [<c073fc0f>] sys_sendto+0xaf/0xcb
> [<c045500b>] ? __run_hrtimer+0xbc/0x106
> [<c04633b5>] ? lock_release_non_nested+0x86/0x1d8
> [<c04c10a1>] ? might_fault+0x4c/0x86
> [<c073fc48>] sys_send+0x1d/0x1f
> [<c0740bb7>] sys_socketcall+0xe6/0x1aa
> [<c07fa19c>] sysenter_do_call+0x12/0x38
> [<c07f0000>] ? timer_cpu_notify+0x47/0x222
> Code: d2 75 13 8b 4d e8 8b 55 ec 50 89 d8 e8 e9 f6 ff ff 5f 89 c6 eb 21 8b 03 64 8b 30 39 d6 75 d2 64 8b 48 04 39 f9 75 ca 8b 53 14 41 <8b> 14 16 64
> EIP: [<c04d8ac6>] __kmalloc_track_caller+0xd8/0x117 SS:ESP 0068:f17ddce8
> CR2: 0000000050435453
Thats "STCP" in ASCII
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets (v2)
From: Neil Horman @ 2011-04-06 20:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber, therbert
In-Reply-To: <20110406.130749.35032326.davem@davemloft.net>
On Wed, Apr 06, 2011 at 01:07:49PM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Wed, 6 Apr 2011 15:37:27 -0400
>
> > properly record sk_rxhash in ipv6 sockets (v2)
> >
> > Noticed while working on another project that flows to sockets which I had open
> > on a test systems weren't getting steered properly when I had RFS enabled.
> > Looking more closely I found that:
> >
> > 1) The affected sockets were all ipv6
> > 2) They weren't getting steered because sk->sk_rxhash was never set from the
> > incomming skbs on that socket.
> >
> > This was occuring because there are several points in the IPv4 tcp and udp code
> > which save the rxhash value when a new connection is established. Those calls
> > to sock_rps_save_rxhash were never added to the corresponding ipv6 code paths.
> > This patch adds those calls. Tested by myself to properly enable RFS
> > functionalty on ipv6.
> >
> > Change notes:
> > v2:
> > Filtered UDP to only arm RFS on bound sockets (Eric Dumazet)
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
> Ok, I've decided to apply this to net-2.6
>
> The current behavior even surprised me, I was pretty sure we had added
> the hooks to both ipv4 and ipv6.
>
> Thanks a lot Neil.
>
Thanks Dave, I was kind of suprised too, but we definately weren't recording the
rxhash. FWIW It doesn't appear to be a regression. I can't find where in the
history we ever had the hooks. Perhaps at one point tcp and udp rcv paths were
common between ipv4 and 6 address families, and then we bifurcated without
replicating the sock_rps_save_rxhash calls?
Neil
^ permalink raw reply
* Re: [PATCH] dsa/mv88e6131: add support for mv88e6085 switch
From: David Miller @ 2011-04-06 20:33 UTC (permalink / raw)
To: buytenh; +Cc: jacmet, netdev
In-Reply-To: <20110405133944.GG22881@wantstofly.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Tue, 5 Apr 2011 15:39:44 +0200
> On Tue, Apr 05, 2011 at 03:03:56PM +0200, Peter Korsgaard wrote:
>
>> The mv88e6085 is identical to the mv88e6095, except that all ports are
>> 10/100 Mb/s, so use the existing setup code except for the cpu/dsa speed
>> selection in _setup_port().
>>
>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>
> I don't have access to DSA chip docs anymore, but assuming that you've
> tested this:
>
> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Applied, thanks.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: Eric Dumazet @ 2011-04-06 20:32 UTC (permalink / raw)
To: David Miller
Cc: acme, jesse.brandeburg, fedora-kernel-list, netdev,
jesse.brandeburg
In-Reply-To: <20110406.132906.200378990.davem@davemloft.net>
Le mercredi 06 avril 2011 à 13:29 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 06 Apr 2011 22:18:56 +0200
>
> > I remember last time I work on a fedora kernel, it had conntrack enabled
> >
> > And yes, conntrack can really slowdown a router, because of default
> > parameters.
>
> Yes, if conntrack is enabled performance will indeed tank.
I just check on latest fedora14 (yum updated) :
- conntrack is statically included in kernel, you cannot remove it.
Hmm...
^ permalink raw reply
* Re: [PATCHv3 NEXT 1/1] net: ethtool support to configure number of channels
From: David Miller @ 2011-04-06 20:30 UTC (permalink / raw)
To: bhutchings; +Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1302121247.2840.50.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 06 Apr 2011 21:20:47 +0100
> Amit, I told you already that you must not use my Signed-off-by line
> since you are changing the patch significantly.
Amit, this is a very serious infraction.
You must not ever add someone else's signed-off-by when you make
changes to a patch, unless you have their very clear and explicit
permission to do so.
^ permalink raw reply
* Kernel crash in 2.6.39-rc2-wl
From: Ben Greear @ 2011-04-06 20:30 UTC (permalink / raw)
To: netdev
This is from today's wireless-testing kernel, with a few non-tainting
patches related to wireless stuff. In general, 39-rc2 seems pretty
flaky, but on this boot, this is the first kernel splat.
I had reloaded our user-space network-config DB, which would have deleted
and created some VETH and MAC-VLAN interfaces, and a bunch of
protocol sockets, virtual-routers (xorp with unique routing tables) etc.
BUG: unable to handle kernel paging request at 50435453
IP: [<c04d8ac6>] __kmalloc_track_caller+0xd8/0x117
*pde = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0/block/sda/sda1/stat
Modules linked in: xt_CT iptable_raw xt_DSCP xt_dscp xt_string xt_owner xt_NFQUEUE xt_multiport xt_mark xt_iprange xt_hashlimit xt_connmark xt_addrty]
Pid: 12747, comm: xorp_rtrmgr Not tainted 2.6.39-rc2-wl+ #56 To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
EIP: 0060:[<c04d8ac6>] EFLAGS: 00210206 CPU: 0
EIP is at __kmalloc_track_caller+0xd8/0x117
EAX: c0b18ee0 EBX: f5402500 ECX: 0001d3c9 EDX: 00000000
ESI: 50435453 EDI: 0001d3c8 EBP: f17ddd00 ESP: f17ddce8
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process xorp_rtrmgr (pid: 12747, ti=f17dc000 task=f147bde0 task.ti=f17dc000)
Stack:
c07869c6 000000d0 000001fc f1284fc0 000000d0 f5487f80 f17ddd1c c07468b9
00000001 00000140 f15e0000 f15e0000 00000000 f17ddd34 c07869c6 ffffffff
f15e0000 00010000 f17ddd88 f17ddd98 c0787005 00004040 00000000 00000002
Call Trace:
[<c07869c6>] ? sk_stream_alloc_skb+0x2c/0xc4
[<c07468b9>] __alloc_skb+0x5d/0xf9
[<c07869c6>] sk_stream_alloc_skb+0x2c/0xc4
[<c0787005>] tcp_sendmsg+0x16d/0x714
[<c07a1776>] inet_sendmsg+0x55/0x5e
[<c073ef79>] __sock_sendmsg+0x56/0x5f
[<c073f608>] sock_sendmsg+0x98/0xac
[<c0461879>] ? mark_lock+0x1e/0x1de
[<c042b66d>] ? pick_next_highest_task_rt+0x148/0x148
[<c04e643e>] ? fget_light+0x30/0xa4
[<c073f686>] ? sockfd_lookup_light+0x1b/0x4b
[<c073fc0f>] sys_sendto+0xaf/0xcb
[<c045500b>] ? __run_hrtimer+0xbc/0x106
[<c04633b5>] ? lock_release_non_nested+0x86/0x1d8
[<c04c10a1>] ? might_fault+0x4c/0x86
[<c073fc48>] sys_send+0x1d/0x1f
[<c0740bb7>] sys_socketcall+0xe6/0x1aa
[<c07fa19c>] sysenter_do_call+0x12/0x38
[<c07f0000>] ? timer_cpu_notify+0x47/0x222
Code: d2 75 13 8b 4d e8 8b 55 ec 50 89 d8 e8 e9 f6 ff ff 5f 89 c6 eb 21 8b 03 64 8b 30 39 d6 75 d2 64 8b 48 04 39 f9 75 ca 8b 53 14 41 <8b> 14 16 64
EIP: [<c04d8ac6>] __kmalloc_track_caller+0xd8/0x117 SS:ESP 0068:f17ddce8
CR2: 0000000050435453
BUG: unable to handle kernel paging request
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: David Miller @ 2011-04-06 20:29 UTC (permalink / raw)
To: eric.dumazet
Cc: acme, jesse.brandeburg, fedora-kernel-list, netdev,
jesse.brandeburg
In-Reply-To: <1302121136.2701.16.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Apr 2011 22:18:56 +0200
> I remember last time I work on a fedora kernel, it had conntrack enabled
>
> And yes, conntrack can really slowdown a router, because of default
> parameters.
Yes, if conntrack is enabled performance will indeed tank.
^ permalink raw reply
* Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."
From: David Miller @ 2011-04-06 20:28 UTC (permalink / raw)
To: hirofumi; +Cc: netdev
In-Reply-To: <87oc4kj1bt.fsf@devron.myhome.or.jp>
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date: Tue, 05 Apr 2011 22:05:10 +0900
> ipv4: Set rt->rt_iif more sanely on output routes.
> (1018b5c01636c7c6bda31a719bda34fc631db29a)
>
> The above patch seems to be caused of avahi breakage.
>
> I'm not debugging fully though, avahi is using IP_PKTINFO and checking
> in_pktinfo->ipi_ifindex > 0.
>
> And if I reverted above patch, it seems to fix avahi's IP_PKTINFO problem.
in_pktinfo is given to the application only during recvmsg() calls, the
call chain is (for example):
udp_recvmsg()
--> ip_cmsg_recv()
--> ip_cmsg_recv_pktinfo()
Therefore we will only be working with receive packets, whose routes are
computed using ip_route_input*() which will fill in the rt_iif field
appropriately.
The only exception to this would be packets which are looped back, in
which case the cached output route attached to the packet will be used.
Your RFC patch should work, but we're trying to make "struct rtable"
smaller rather than larger.
In what way does routing break if you simply restore the original
rt_iif assignment in output route creation? That's the most preferred
fix for this.
^ permalink raw reply
* Re: [PATCHv3 NEXT 1/1] net: ethtool support to configure number of channels
From: Ben Hutchings @ 2011-04-06 20:20 UTC (permalink / raw)
To: David Miller; +Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <20110406.125637.70201394.davem@davemloft.net>
On Wed, 2011-04-06 at 12:56 -0700, David Miller wrote:
> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
> Date: Fri, 1 Apr 2011 21:58:03 -0700
>
> > o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
> > but it is tigtly coupled with RX flow hash configuration.
> > o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
> > soon.
> > o This patch is reworked on Ben Hutchings "ethtool: NUMA affinity control" patch,
> > dropping the affinity control from it.
> >
> > Ben Hutching:
> > o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
> > queues so that most channels combine RX and TX work.
> > o Please could you use a kernel-doc comment to describe the structure.
> >
> > Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> Ben, are you currently OK with this patch?
>
> There was some back and forth, and I just want to make sure all of the
> issues you raised were addressed to your satisfaction.
I'm afraid not.
On Fri, 2011-04-01 at 21:58 -0700, Amit Kumar Salecha wrote:
o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
> but it is tigtly coupled with RX flow hash configuration.
> o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
> soon.
> o This patch is reworked on Ben Hutchings "ethtool: NUMA affinity control" patch,
> dropping the affinity control from it.
>
> Ben Hutching:
> o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
> queues so that most channels combine RX and TX work.
> o Please could you use a kernel-doc comment to describe the structure.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Amit, I told you already that you must not use my Signed-off-by line
since you are changing the patch significantly.
> ---
> include/linux/ethtool.h | 41 +++++++++++++++++++++++++++++++++++++++++
> net/core/ethtool.c | 41 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 82 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index c8fcbdd..3c4d968 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -229,6 +229,42 @@ struct ethtool_ringparam {
> __u32 tx_pending;
> };
>
> +/**
> + * struct ethtool_channels - configuring number of network channel
> + * @cmd: ETHTOOL_{G,S}CHANNELS
> + * @type: Channel type defined in ethtool_channel_type
> + * @max_XX: Read only. Maximum number of channel the driver support
> + * @XX_count: Valid values are in the range 1 to the "max_XX" counterpart above.
The kernel-doc tools are going to complain about these field names with
'XX' in them. You'll have to describe each field individually.
> + * This can be used to configure RX,TX and other channels.
> + */
> +
> +struct ethtool_channels {
> + __u32 cmd;
> + __u32 type;
> + __u32 max_rx;
> + __u32 max_tx;
> + __u32 max_other;
> + __u32 rx_count;
> + __u32 tx_count;
> + __u32 other_count;
> +};
> +
> +/* Channel type */
> +/* Channel type should be pass in type field of ethtool_channels.
> + * TYPE_ALL indicates set all channels to XX_count values.
> + * TYPE_RX and TYPE_TX is to get and set RX and TX channels correspondingly.
> + * TYPE_COMBINED is to set both RX and TX channels to rx_count and tx_count
> + * correspondingly.
That's not what I meant by 'combined'. I meant a set of RX queues and
TX queues (usually 1 of each) with an IRQ and maybe an event queue
shared between them. It should be possible for ethtool to distinguish
combined channels, so it doesn't just report 'Invalid argument' if the
user tries to set rx_count != tx_count.
I think this requires that there are max_combined and combined_count (or
similar) fields in struct ethtool_channels, so a driver that only
supports combined channels can report max_rx = 0, max_tx = 0,
max_combined = N.
> TYPE_OTHER is to configure other channel.
> + */
> +enum ethtool_channel_type {
> + ETH_CHAN_TYPE_ALL = 0,
> + ETH_CHAN_TYPE_RX,
> + ETH_CHAN_TYPE_TX,
> + ETH_CHAN_TYPE_COMBINED,
> + ETH_CHAN_TYPE_OTHER,
> +};
[...]
Really I'm not sure whether there's a need to be able to specify which
channel counts are being changed. ethtool or whatever utility is used
can do ETHTOOL_GCHANNELS, modify channel counts, ETHTOOL_SCHANNELS and
all the counts the user didn't want to change will be unchanged. If you
still think it is useful then use flags for the different channel types
so there is no arbitrary restriction on which counts can be changed at
the same time.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: Eric Dumazet @ 2011-04-06 20:18 UTC (permalink / raw)
To: David Miller
Cc: acme, jesse.brandeburg, fedora-kernel-list, netdev,
jesse.brandeburg
In-Reply-To: <20110406.130239.232756965.davem@davemloft.net>
Le mercredi 06 avril 2011 à 13:02 -0700, David Miller a écrit :
> From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> Date: Wed, 6 Apr 2011 16:57:19 -0300
>
> > Something like ftrace code changing when the user inserts the first
> > rule?
> >
> > People wanting top performance disable it in the build, but thos wanting
> > to stick to vendor provided kernels don't have that choice :)
>
> Using ftrace-like stubs would be an interesting idea, and I highly encourage
> people to work on something like that.
>
> However I want to reiterate that I think that real rules are installed
> in Jesse's case, and once he removes those the majority of the
> overhead will disappear. The FC14 workstation I'm using right now, on
> which I've made no modifications to the installer's netfilter settings,
> has the following rules:
>
> --------------------
> [root@ilbolle davem]# iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
> ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
> ACCEPT icmp -- anywhere anywhere
> ACCEPT all -- anywhere anywhere
> ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
> ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
> ACCEPT udp -- anywhere 224.0.0.251 state NEW udp dpt:mdns
> ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ipp
> ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
> REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
> REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
> [root@ilbolle davem]#
> --------------------
>
> I suspect Jesse has something similar on his test box.
>
I suspect problem is worse than that.
I remember last time I work on a fedora kernel, it had conntrack enabled
And yes, conntrack can really slowdown a router, because of default
parameters.
cat /proc/sys/net/nf_conntrack_max
^ permalink raw reply
* Re: [PatchV2 : PL25A1 Support - 1/3] whitespace
From: David Miller @ 2011-04-06 20:17 UTC (permalink / raw)
To: simon; +Cc: gregkh, david-b, sshtylyov, linux-usb, netdev, linux-kernel
In-Reply-To: <1302063406-13077-1-git-send-email-simon@mungewell.org>
There are some problems with this patch series:
1) Please compose your subject lines more correctly. When I such these
patches into GIT, everything in the initial "[]" brackets is removed
and the commit header line for this patch (for example) ends up being
just "whitespace".
We want more than that.
Try something like:
Subject: [PATCH v2 1/3] usb: plusb: Whitespace.
Subject: [PATCH v2 2/3] usb: plusb: Add PL25A1 support.
Subject: [PATCH v2 3/3] usb: plusb: Add reset debugging.
2) Patch 2 doesn't apply cleanly to the current tree, you'll need to
refresh these patches.
Thanks.
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: Arnaldo Carvalho de Melo @ 2011-04-06 20:13 UTC (permalink / raw)
To: David Miller
Cc: fedora-kernel-list-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA,
jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w,
jesse.brandeburg-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20110406.130239.232756965.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Em Wed, Apr 06, 2011 at 01:02:39PM -0700, David Miller escreveu:
> From: Arnaldo Carvalho de Melo <acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>
> Date: Wed, 6 Apr 2011 16:57:19 -0300
>
> > Something like ftrace code changing when the user inserts the first
> > rule?
> >
> > People wanting top performance disable it in the build, but thos wanting
> > to stick to vendor provided kernels don't have that choice :)
>
> Using ftrace-like stubs would be an interesting idea, and I highly encourage
> people to work on something like that.
cool, these code modification and JIT mechanizms open up a lot of
possibilities indeed ;-)
> However I want to reiterate that I think that real rules are installed
> in Jesse's case, and once he removes those the majority of the
> overhead will disappear. The FC14 workstation I'm using right now, on
>
> which I've made no modifications to the installer's netfilter settings,
> has the following rules:
<SNIP>
> I suspect Jesse has something similar on his test box.
>
> When no rules are loaded, all the stubs make happen is a function call
> plus a list_empty() check. Nothing more. I really can't see that, all
> by itself, obliterating routing performance.
Yeah, would be nice, since he is playing with it, for him to post
numbers about the overheads.
> In fact I've done udp flood tests, as recently as a month ago, with just
> NETFILTER=y and no rules installed, and the impact was minimal.
>
> And that was on sparc64 where function calls are expensive :)
:-)
- Arnaldo
^ permalink raw reply
* Re: [Patch] isdn: remove deprecated ISDN_CAPI_CAPIFS
From: David Miller @ 2011-04-06 20:12 UTC (permalink / raw)
To: amwang; +Cc: netdev, isdn, jan.kiszka
In-Reply-To: <1302080739-4029-1-git-send-email-amwang@redhat.com>
From: Amerigo Wang <amwang@redhat.com>
Date: Wed, 6 Apr 2011 17:05:39 +0800
> Cc: Jan Kiszka <jan.kiszka@web.de>
> Cc: Karsten Keil <isdn@linux-pingi.de>
> Signed-off-by: WANG Cong <amwang@redhat.com>
capi.c still includes capifs.h, which you are deleting here.
How did you build test this?
^ permalink raw reply
* Re: [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets (v2)
From: David Miller @ 2011-04-06 20:07 UTC (permalink / raw)
To: nhorman; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber, therbert
In-Reply-To: <1302118647-7931-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Wed, 6 Apr 2011 15:37:27 -0400
> properly record sk_rxhash in ipv6 sockets (v2)
>
> Noticed while working on another project that flows to sockets which I had open
> on a test systems weren't getting steered properly when I had RFS enabled.
> Looking more closely I found that:
>
> 1) The affected sockets were all ipv6
> 2) They weren't getting steered because sk->sk_rxhash was never set from the
> incomming skbs on that socket.
>
> This was occuring because there are several points in the IPv4 tcp and udp code
> which save the rxhash value when a new connection is established. Those calls
> to sock_rps_save_rxhash were never added to the corresponding ipv6 code paths.
> This patch adds those calls. Tested by myself to properly enable RFS
> functionalty on ipv6.
>
> Change notes:
> v2:
> Filtered UDP to only arm RFS on bound sockets (Eric Dumazet)
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Ok, I've decided to apply this to net-2.6
The current behavior even surprised me, I was pretty sure we had added
the hooks to both ipv4 and ipv6.
Thanks a lot Neil.
^ permalink raw reply
* Re: [PATCH 01/24] sysctl: net: call unregister_net_sysctl_table where needed
From: David Miller @ 2011-04-06 20:06 UTC (permalink / raw)
To: lucian.grijincu; +Cc: adobriyan, ebiederm, tavi, linux-kernel, netdev
In-Reply-To: <BANLkTik6PKYFyjnGLWoeRBrwF4sPZaaGWw@mail.gmail.com>
From: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Date: Wed, 6 Apr 2011 22:04:53 +0200
> On Wed, Apr 6, 2011 at 9:52 PM, David Miller <davem@davemloft.net> wrote:
>> Oops, hmmm... Can this actually cause any real problems currently?
>>
>> If so I'd like to toss this specific patch into net-2.6
>
>
> Nope:
>
> void unregister_net_sysctl_table(struct ctl_table_header *header)
> {
> unregister_sysctl_table(header);
> }
> EXPORT_SYMBOL_GPL(unregister_net_sysctl_table);
Ok, that's good.
> But I thought that in the future, if something special needs to be
> done for unregister_net_sysctl_table, it would be better to have these
> consistent. I'll do a check on all the tree to see if there are other
> cases.
>
> Another approach would be to remove unregister_net_sysctl_table, as it
> does nothing different of unregister_sysctl_table and let our future
> selves deal with the problem.
>
> Can you tell me what you'd like?
I think the thing to do is to keep this patch as it is, and only apply
it along with this cookie patch series, for -next.
^ permalink raw reply
* Re: [PATCH 01/24] sysctl: net: call unregister_net_sysctl_table where needed
From: Lucian Adrian Grijincu @ 2011-04-06 20:04 UTC (permalink / raw)
To: David Miller; +Cc: adobriyan, ebiederm, tavi, linux-kernel, netdev
In-Reply-To: <20110406.125256.102558618.davem@davemloft.net>
On Wed, Apr 6, 2011 at 9:52 PM, David Miller <davem@davemloft.net> wrote:
> Oops, hmmm... Can this actually cause any real problems currently?
>
> If so I'd like to toss this specific patch into net-2.6
Nope:
void unregister_net_sysctl_table(struct ctl_table_header *header)
{
unregister_sysctl_table(header);
}
EXPORT_SYMBOL_GPL(unregister_net_sysctl_table);
But I thought that in the future, if something special needs to be
done for unregister_net_sysctl_table, it would be better to have these
consistent. I'll do a check on all the tree to see if there are other
cases.
Another approach would be to remove unregister_net_sysctl_table, as it
does nothing different of unregister_sysctl_table and let our future
selves deal with the problem.
Can you tell me what you'd like?
--
.
..: Lucian
^ permalink raw reply
* Re: fedora 14 kernel performance with ip forwarding workload
From: David Miller @ 2011-04-06 20:02 UTC (permalink / raw)
To: acme; +Cc: jesse.brandeburg, fedora-kernel-list, netdev, jesse.brandeburg
In-Reply-To: <20110406195719.GE14697@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Wed, 6 Apr 2011 16:57:19 -0300
> Something like ftrace code changing when the user inserts the first
> rule?
>
> People wanting top performance disable it in the build, but thos wanting
> to stick to vendor provided kernels don't have that choice :)
Using ftrace-like stubs would be an interesting idea, and I highly encourage
people to work on something like that.
However I want to reiterate that I think that real rules are installed
in Jesse's case, and once he removes those the majority of the
overhead will disappear. The FC14 workstation I'm using right now, on
which I've made no modifications to the installer's netfilter settings,
has the following rules:
--------------------
[root@ilbolle davem]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
ACCEPT udp -- anywhere 224.0.0.251 state NEW udp dpt:mdns
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ipp
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@ilbolle davem]#
--------------------
I suspect Jesse has something similar on his test box.
When no rules are loaded, all the stubs make happen is a function call
plus a list_empty() check. Nothing more. I really can't see that, all
by itself, obliterating routing performance.
In fact I've done udp flood tests, as recently as a month ago, with just
NETFILTER=y and no rules installed, and the impact was minimal.
And that was on sparc64 where function calls are expensive :)
^ permalink raw reply
* pull request: wireless-2.6 2011-04-06
From: John W. Linville @ 2011-04-06 20:00 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is another batch of fixes intended for 2.6.39...
This includes a fix to avoid receiving duplicate frames in "cooked"
monitor mode, a mac80211 documentation fix to avoid developer
confusion, an rt2x00 fix to avoid cancelling some uninitialized work,
a wl12xx buffer overflow fix, an email address correction for wl12xx
module info, a zd1211rw regression fix, a zd1211rw WARNING fix,
and rtlwifi fix to avoid using some uninitialized variables, a fix
to broaden the iwl600 hardware supported by iwlagn to match what the
Windows driver is supporting, a b43 fix to allocate properly sized
receive buffers, and some stuff related to device IDs.
Please let me know if there are problems!
John
---
The following changes since commit 738faca34335cd1d5d87fa7c58703139c7fa15bd:
ipv6: Don't pass invalid dst_entry pointer to dst_release(). (2011-04-04 13:07:26 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Christian Lamparter (1):
p54usb: IDs for two new devices
Helmut Schaa (1):
mac80211: Fix duplicate frames on cooked monitor
Johannes Berg (1):
mac80211: fix comment regarding aggregation buf_size
John W. Linville (2):
b43: allocate receive buffers big enough for max frame len + offset
iwlwifi: accept EEPROM version 0x423 for iwl6000
Jussi Kivilinna (2):
zd1211rw: remove URB_SHORT_NOT_OK flag in zd_usb_iowrite16v_async()
zd1211rw: reset rx idle timer from tasklet
Larry Finger (1):
rtlwifi: Fix some warnings/bugs
Luciano Coelho (2):
wl12xx: fix module author's email address in the spi and sdio modules
wl12xx: fix potential buffer overflow in testmode nvs push
Senthil Balasubramanian (1):
ath9k: Fix phy info print message with AR9485 chipset.
Stanislaw Gruszka (1):
rt2x00: fix cancelling uninitialized work
drivers/net/wireless/ath/ath9k/hw.c | 1 +
drivers/net/wireless/b43/dma.c | 2 +-
drivers/net/wireless/b43/dma.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 2 +-
drivers/net/wireless/p54/p54usb.c | 2 ++
drivers/net/wireless/rt2x00/rt2x00dev.c | 6 ++++--
drivers/net/wireless/rtlwifi/efuse.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c | 2 +-
drivers/net/wireless/rtlwifi/usb.c | 2 +-
drivers/net/wireless/wl12xx/sdio.c | 2 +-
drivers/net/wireless/wl12xx/spi.c | 2 +-
drivers/net/wireless/wl12xx/testmode.c | 5 ++++-
drivers/net/wireless/zd1211rw/zd_usb.c | 20 ++++++++++++++++++--
drivers/net/wireless/zd1211rw/zd_usb.h | 1 +
include/net/mac80211.h | 15 +++++++++++++--
net/mac80211/rx.c | 2 +-
16 files changed, 52 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 338b075..1ec9bcd 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2546,6 +2546,7 @@ static struct {
{ AR_SREV_VERSION_9287, "9287" },
{ AR_SREV_VERSION_9271, "9271" },
{ AR_SREV_VERSION_9300, "9300" },
+ { AR_SREV_VERSION_9485, "9485" },
};
/* For devices with external radios */
diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index 3d5566e..ff0f5ba 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -1536,7 +1536,7 @@ static void dma_rx(struct b43_dmaring *ring, int *slot)
dmaaddr = meta->dmaaddr;
goto drop_recycle_buffer;
}
- if (unlikely(len > ring->rx_buffersize)) {
+ if (unlikely(len + ring->frameoffset > ring->rx_buffersize)) {
/* The data did not fit into one descriptor buffer
* and is split over multiple buffers.
* This should never happen, as we try to allocate buffers
diff --git a/drivers/net/wireless/b43/dma.h b/drivers/net/wireless/b43/dma.h
index a01c210..e8a80a1 100644
--- a/drivers/net/wireless/b43/dma.h
+++ b/drivers/net/wireless/b43/dma.h
@@ -163,7 +163,7 @@ struct b43_dmadesc_generic {
/* DMA engine tuning knobs */
#define B43_TXRING_SLOTS 256
#define B43_RXRING_SLOTS 64
-#define B43_DMA0_RX_BUFFERSIZE IEEE80211_MAX_FRAME_LEN
+#define B43_DMA0_RX_BUFFERSIZE (B43_DMA0_RX_FRAMEOFFSET + IEEE80211_MAX_FRAME_LEN)
/* Pointer poison */
#define B43_DMA_PTR_POISON ((void *)ERR_PTR(-ENOMEM))
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.h b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
index 98aa8af..20b6646 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -241,7 +241,7 @@ struct iwl_eeprom_enhanced_txpwr {
/* 6x00 Specific */
#define EEPROM_6000_TX_POWER_VERSION (4)
-#define EEPROM_6000_EEPROM_VERSION (0x434)
+#define EEPROM_6000_EEPROM_VERSION (0x423)
/* 6x50 Specific */
#define EEPROM_6050_TX_POWER_VERSION (4)
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index 9b344a9..e183587 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -56,6 +56,7 @@ static struct usb_device_id p54u_table[] __devinitdata = {
{USB_DEVICE(0x0846, 0x4210)}, /* Netgear WG121 the second ? */
{USB_DEVICE(0x0846, 0x4220)}, /* Netgear WG111 */
{USB_DEVICE(0x09aa, 0x1000)}, /* Spinnaker Proto board */
+ {USB_DEVICE(0x0bf8, 0x1007)}, /* Fujitsu E-5400 USB */
{USB_DEVICE(0x0cde, 0x0006)}, /* Medion 40900, Roper Europe */
{USB_DEVICE(0x0db0, 0x6826)}, /* MSI UB54G (MS-6826) */
{USB_DEVICE(0x107b, 0x55f2)}, /* Gateway WGU-210 (Gemtek) */
@@ -68,6 +69,7 @@ static struct usb_device_id p54u_table[] __devinitdata = {
{USB_DEVICE(0x1915, 0x2235)}, /* Linksys WUSB54G Portable OEM */
{USB_DEVICE(0x2001, 0x3701)}, /* DLink DWL-G120 Spinnaker */
{USB_DEVICE(0x2001, 0x3703)}, /* DLink DWL-G122 */
+ {USB_DEVICE(0x2001, 0x3762)}, /* Conceptronic C54U */
{USB_DEVICE(0x5041, 0x2234)}, /* Linksys WUSB54G */
{USB_DEVICE(0x5041, 0x2235)}, /* Linksys WUSB54G Portable */
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 9de9dbe..84eb6ad 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -1062,8 +1062,10 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
* Stop all work.
*/
cancel_work_sync(&rt2x00dev->intf_work);
- cancel_work_sync(&rt2x00dev->rxdone_work);
- cancel_work_sync(&rt2x00dev->txdone_work);
+ if (rt2x00_is_usb(rt2x00dev)) {
+ cancel_work_sync(&rt2x00dev->rxdone_work);
+ cancel_work_sync(&rt2x00dev->txdone_work);
+ }
destroy_workqueue(rt2x00dev->workqueue);
/*
diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
index f74a870..590f14f 100644
--- a/drivers/net/wireless/rtlwifi/efuse.c
+++ b/drivers/net/wireless/rtlwifi/efuse.c
@@ -685,7 +685,7 @@ static int efuse_pg_packet_read(struct ieee80211_hw *hw, u8 offset, u8 *data)
u8 efuse_data, word_cnts = 0;
u16 efuse_addr = 0;
- u8 hworden;
+ u8 hworden = 0;
u8 tmpdata[8];
if (data == NULL)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c b/drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c
index 5ef9137..28a6ce3 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c
@@ -303,7 +303,7 @@ static void _rtl92c_fill_h2c_command(struct ieee80211_hw *hw,
u16 box_reg, box_extreg;
u8 u1b_tmp;
bool isfw_read = false;
- u8 buf_index;
+ u8 buf_index = 0;
bool bwrite_sucess = false;
u8 wait_h2c_limmit = 100;
u8 wait_writeh2c_limmit = 100;
diff --git a/drivers/net/wireless/rtlwifi/usb.c b/drivers/net/wireless/rtlwifi/usb.c
index a4b2613..f5d8573 100644
--- a/drivers/net/wireless/rtlwifi/usb.c
+++ b/drivers/net/wireless/rtlwifi/usb.c
@@ -246,7 +246,7 @@ static void _rtl_usb_io_handler_init(struct device *dev,
static void _rtl_usb_io_handler_release(struct ieee80211_hw *hw)
{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
+ struct rtl_priv __maybe_unused *rtlpriv = rtl_priv(hw);
mutex_destroy(&rtlpriv->io.bb_mutex);
}
diff --git a/drivers/net/wireless/wl12xx/sdio.c b/drivers/net/wireless/wl12xx/sdio.c
index 5b9dbea..b1c7d03 100644
--- a/drivers/net/wireless/wl12xx/sdio.c
+++ b/drivers/net/wireless/wl12xx/sdio.c
@@ -340,7 +340,7 @@ module_init(wl1271_init);
module_exit(wl1271_exit);
MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Luciano Coelho <luciano.coelho@nokia.com>");
+MODULE_AUTHOR("Luciano Coelho <coelho@ti.com>");
MODULE_AUTHOR("Juuso Oikarinen <juuso.oikarinen@nokia.com>");
MODULE_FIRMWARE(WL1271_FW_NAME);
MODULE_FIRMWARE(WL1271_AP_FW_NAME);
diff --git a/drivers/net/wireless/wl12xx/spi.c b/drivers/net/wireless/wl12xx/spi.c
index 18cf017..ffc745b 100644
--- a/drivers/net/wireless/wl12xx/spi.c
+++ b/drivers/net/wireless/wl12xx/spi.c
@@ -487,7 +487,7 @@ module_init(wl1271_init);
module_exit(wl1271_exit);
MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Luciano Coelho <luciano.coelho@nokia.com>");
+MODULE_AUTHOR("Luciano Coelho <coelho@ti.com>");
MODULE_AUTHOR("Juuso Oikarinen <juuso.oikarinen@nokia.com>");
MODULE_FIRMWARE(WL1271_FW_NAME);
MODULE_FIRMWARE(WL1271_AP_FW_NAME);
diff --git a/drivers/net/wireless/wl12xx/testmode.c b/drivers/net/wireless/wl12xx/testmode.c
index e64403b..6ec06a4 100644
--- a/drivers/net/wireless/wl12xx/testmode.c
+++ b/drivers/net/wireless/wl12xx/testmode.c
@@ -204,7 +204,10 @@ static int wl1271_tm_cmd_nvs_push(struct wl1271 *wl, struct nlattr *tb[])
kfree(wl->nvs);
- wl->nvs = kzalloc(sizeof(struct wl1271_nvs_file), GFP_KERNEL);
+ if (len != sizeof(struct wl1271_nvs_file))
+ return -EINVAL;
+
+ wl->nvs = kzalloc(len, GFP_KERNEL);
if (!wl->nvs) {
wl1271_error("could not allocate memory for the nvs file");
ret = -ENOMEM;
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
index 58236e6..ab607bb 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -643,7 +643,7 @@ static void rx_urb_complete(struct urb *urb)
usb = urb->context;
rx = &usb->rx;
- zd_usb_reset_rx_idle_timer(usb);
+ tasklet_schedule(&rx->reset_timer_tasklet);
if (length%rx->usb_packet_size > rx->usb_packet_size-4) {
/* If there is an old first fragment, we don't care. */
@@ -812,6 +812,7 @@ void zd_usb_disable_rx(struct zd_usb *usb)
__zd_usb_disable_rx(usb);
mutex_unlock(&rx->setup_mutex);
+ tasklet_kill(&rx->reset_timer_tasklet);
cancel_delayed_work_sync(&rx->idle_work);
}
@@ -1106,6 +1107,13 @@ static void zd_rx_idle_timer_handler(struct work_struct *work)
zd_usb_reset_rx(usb);
}
+static void zd_usb_reset_rx_idle_timer_tasklet(unsigned long param)
+{
+ struct zd_usb *usb = (struct zd_usb *)param;
+
+ zd_usb_reset_rx_idle_timer(usb);
+}
+
void zd_usb_reset_rx_idle_timer(struct zd_usb *usb)
{
struct zd_usb_rx *rx = &usb->rx;
@@ -1127,6 +1135,7 @@ static inline void init_usb_interrupt(struct zd_usb *usb)
static inline void init_usb_rx(struct zd_usb *usb)
{
struct zd_usb_rx *rx = &usb->rx;
+
spin_lock_init(&rx->lock);
mutex_init(&rx->setup_mutex);
if (interface_to_usbdev(usb->intf)->speed == USB_SPEED_HIGH) {
@@ -1136,11 +1145,14 @@ static inline void init_usb_rx(struct zd_usb *usb)
}
ZD_ASSERT(rx->fragment_length == 0);
INIT_DELAYED_WORK(&rx->idle_work, zd_rx_idle_timer_handler);
+ rx->reset_timer_tasklet.func = zd_usb_reset_rx_idle_timer_tasklet;
+ rx->reset_timer_tasklet.data = (unsigned long)usb;
}
static inline void init_usb_tx(struct zd_usb *usb)
{
struct zd_usb_tx *tx = &usb->tx;
+
spin_lock_init(&tx->lock);
atomic_set(&tx->enabled, 0);
tx->stopped = 0;
@@ -1671,6 +1683,10 @@ static void iowrite16v_urb_complete(struct urb *urb)
if (urb->status && !usb->cmd_error)
usb->cmd_error = urb->status;
+
+ if (!usb->cmd_error &&
+ urb->actual_length != urb->transfer_buffer_length)
+ usb->cmd_error = -EIO;
}
static int zd_submit_waiting_urb(struct zd_usb *usb, bool last)
@@ -1805,7 +1821,7 @@ int zd_usb_iowrite16v_async(struct zd_usb *usb, const struct zd_ioreq16 *ioreqs,
usb_fill_int_urb(urb, udev, usb_sndintpipe(udev, EP_REGS_OUT),
req, req_len, iowrite16v_urb_complete, usb,
ep->desc.bInterval);
- urb->transfer_flags |= URB_FREE_BUFFER | URB_SHORT_NOT_OK;
+ urb->transfer_flags |= URB_FREE_BUFFER;
/* Submit previous URB */
r = zd_submit_waiting_urb(usb, false);
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.h b/drivers/net/wireless/zd1211rw/zd_usb.h
index b3df2c8..325d0f9 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.h
+++ b/drivers/net/wireless/zd1211rw/zd_usb.h
@@ -183,6 +183,7 @@ struct zd_usb_rx {
spinlock_t lock;
struct mutex setup_mutex;
struct delayed_work idle_work;
+ struct tasklet_struct reset_timer_tasklet;
u8 fragment[2 * USB_MAX_RX_SIZE];
unsigned int fragment_length;
unsigned int usb_packet_size;
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index cefe1b3..965f1b1 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1753,8 +1753,19 @@ enum ieee80211_ampdu_mlme_action {
* that TX/RX_STOP can pass NULL for this parameter.
* The @buf_size parameter is only valid when the action is set to
* %IEEE80211_AMPDU_TX_OPERATIONAL and indicates the peer's reorder
- * buffer size (number of subframes) for this session -- aggregates
- * containing more subframes than this may not be transmitted to the peer.
+ * buffer size (number of subframes) for this session -- the driver
+ * may neither send aggregates containing more subframes than this
+ * nor send aggregates in a way that lost frames would exceed the
+ * buffer size. If just limiting the aggregate size, this would be
+ * possible with a buf_size of 8:
+ * - TX: 1.....7
+ * - RX: 2....7 (lost frame #1)
+ * - TX: 8..1...
+ * which is invalid since #1 was now re-transmitted well past the
+ * buffer size of 8. Correct ways to retransmit #1 would be:
+ * - TX: 1 or 18 or 81
+ * Even "189" would be wrong since 1 could be lost again.
+ *
* Returns a negative error code on failure.
* The callback can sleep.
*
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index aa5cc37..2afeac9 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2541,7 +2541,6 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx)
* same TID from the same station
*/
rx->skb = skb;
- rx->flags = 0;
CALL_RXH(ieee80211_rx_h_decrypt)
CALL_RXH(ieee80211_rx_h_check_more_data)
@@ -2612,6 +2611,7 @@ void ieee80211_release_reorder_timeout(struct sta_info *sta, int tid)
.sdata = sta->sdata,
.local = sta->local,
.queue = tid,
+ .flags = 0,
};
struct tid_ampdu_rx *tid_agg_rx;
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: fedora 14 kernel performance with ip forwarding workload
From: Arnaldo Carvalho de Melo @ 2011-04-06 19:57 UTC (permalink / raw)
To: David Miller
Cc: jesse.brandeburg, fedora-kernel-list, netdev, jesse.brandeburg
In-Reply-To: <20110406.121208.189703414.davem@davemloft.net>
Em Wed, Apr 06, 2011 at 12:12:08PM -0700, David Miller escreveu:
> From: Jesse Brandeburg <jesse.brandeburg@gmail.com>
> Date: Wed, 6 Apr 2011 11:51:06 -0700
> > perf showed netfilter being prominent, and removing it gives me much
> > higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
> > good thing to be able to disable netfilter if you want to?
>
> CONFIG_NETFILTER=y is the only possible non-disabled setting, as it's
> a boolean.
>
> All that is enabling is the hooks, and it's not possible to provide
> netfilter at all without the hooks being compiled into the kernel
> image.
>
> Fedora by default is also probably installing several defauly
> netfilter rules, make sure to remove them.
Was there ever any attempt to try to have netfilter built-in but not
causing the performance impact?
Something like ftrace code changing when the user inserts the first
rule?
People wanting top performance disable it in the build, but thos wanting
to stick to vendor provided kernels don't have that choice :)
- Arnaldo
^ permalink raw reply
* Re: [PATCHv3 NEXT 1/1] net: ethtool support to configure number of channels
From: David Miller @ 2011-04-06 19:56 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty, bhutchings
In-Reply-To: <1301720283-25038-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Fri, 1 Apr 2011 21:58:03 -0700
> o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
> but it is tigtly coupled with RX flow hash configuration.
> o Patches for qlcnic and netxen_nic driver supporting rx channel will follow
> soon.
> o This patch is reworked on Ben Hutchings "ethtool: NUMA affinity control" patch,
> dropping the affinity control from it.
>
> Ben Hutching:
> o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
> queues so that most channels combine RX and TX work.
> o Please could you use a kernel-doc comment to describe the structure.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Ben, are you currently OK with this patch?
There was some back and forth, and I just want to make sure all of the
issues you raised were addressed to your satisfaction.
Thanks.
^ permalink raw reply
* Re: [PATCH 03/24] sysctl: cookie: pass ctl_header_cookie to proc_handler
From: David Miller @ 2011-04-06 19:54 UTC (permalink / raw)
To: lucian.grijincu; +Cc: adobriyan, ebiederm, tavi, linux-kernel, netdev
In-Reply-To: <2c7dffeffbbb6cc768816a904a1dde2d969a1c4e.1301711868.git.lucian.grijincu@gmail.com>
From: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Date: Sat, 2 Apr 2011 04:53:17 +0200
> The bulk of this patch changes all proc_handlers in the kernel to
> receive the cookie.
>
> Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Since this stuff is pretty invasive outside of the networking I really
need to see two things:
1) Feedback from sysctl folks.
2) Some coordination with whoever maintains sysctl stuff so we can
decide how to stage these changes in various maintainer trees,
including mine.
^ permalink raw reply
* Re: [PATCH 02/24] sysctl: cookie: add ctl_header_cookie
From: David Miller @ 2011-04-06 19:53 UTC (permalink / raw)
To: lucian.grijincu; +Cc: adobriyan, ebiederm, tavi, linux-kernel, netdev
In-Reply-To: <059405611ddd6d70415081e0261805935e95d345.1301711868.git.lucian.grijincu@gmail.com>
From: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Date: Sat, 2 Apr 2011 04:53:16 +0200
> @@ -205,6 +205,7 @@ static struct ctl_table_header root_table_header = {
> .ctl_entry = LIST_HEAD_INIT(sysctl_table_root.default_set.list),}},
> .root = &sysctl_table_root,
> .set = &sysctl_table_root.default_set,
> + .ctl_header_cookie = NULL,
> };
Such explicit setting of structure members to NULL in an assignment is
never necessary. Please remove these, there were a few cases in this
patch.
Thanks.
^ 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