* Re: [PATCH net-next-2.6 1/2] net: add IFLA_NUM_TXQ attribute
From: David Miller @ 2010-09-17 23:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1284712288.3391.36.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 17 Sep 2010 10:31:28 +0200
> In order to enable multiqueue support on some devices,
> add IFLA_NUM_TXQ attribute, number of transmit queues, that "ip link"
> can use, at creation and show time :
>
> # ip link add gre34 txqueues 8 type gre remote 192.168.20.80
>
> # ip link sho dev gre34
> 8: gre34: <POINTOPOINT,NOARP> mtu 1476 qdisc noop state DOWN txqueues 8
> link/gre 0.0.0.0 peer 192.168.20.80
>
> Drivers not yet multiqueue aware are supported, because core network
> temporary sets real_num_tx_queues to one.
>
> Multiqueue enabled drivers must then sets real_num_tx_queues to
> num_tx_queues in their newlink() method.
>
> Limits number of queues to 256 for the moment.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
This is one way to solve the problem, but I think we can do a lot
better.
What is the true barrier for full parallel processing over GRE tunnels
at the moment?
It seems to me that the only issue that exists is the TXQ->lock done
by dev_queue_xmit() for the GRE tunnel xmit.
This is something we should have fixed ages ago, and we tried with the
ugly LLTX thing. In my opinion all paths leading to a non-queueing
device should not take the TX lock, because by definition there is no
queueing state or synchronization to be cognizant of.
Actually, statistics can matter but we already have to address that
problem seperately for the sake of 64-bit stats on 32-bit machines.
Alexey even open condones this in the huge comment that sits in
the "!q->enqueue" path of dev_queue_xmit().
If we take care of this, then TX multi-queue works transparently for
all software devices layered on top of suitably capable hardware,
without us having to make any explicit multi-queue changes to the
software device code.
Eric, if you can demonstrate a real need for this once we solve the
fundamental issue, as I have outlined above, I am happy to add this
netlink attribute and tunable. But for now I'm deferring these
two patches.
Thanks!
^ permalink raw reply
* Re: Remaining BKL users, what to do
From: Petr Vandrovec @ 2010-09-17 23:21 UTC (permalink / raw)
To: Arnd Bergmann, Anton Altaparmakov
Cc: Jan Kara, codalist, autofs, linux-media, dri-devel,
Christoph Hellwig, Mikulas Patocka, Trond Myklebust,
Anders Larsen, Evgeniy Dushistov, Ingo Molnar, netdev,
Samuel Ortiz, Arnaldo Carvalho de Melo, linux-kernel,
linux-fsdevel, Andrew Hendry
I'll try to come up with something for ncpfs.
Trivial lock replacement will open deadlock possibility when someone reads to page which is also mmaped from the same filesystem (like grep likes to do). BKL with its automated release on sleep helped (or papered over) a lot here.
Petr
"Arnd Bergmann" <arnd@arndb.de> wrote:
>On Thursday 16 September 2010, Anton Altaparmakov wrote:
>> On 16 Sep 2010, at 16:04, Jan Kara wrote:
>> > On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
>> >> The big kernel lock is gone from almost all code in linux-next, this is
>> >> the status of what I think will happen to the remaining users:
>> > ...
>> >> fs/ncpfs:
>> >> Should be fixable if Petr still cares about it. Otherwise suggest
>> >> moving to drivers/staging if there are no users left.
>> > I think some people still use this...
>>
>> Yes, indeed. Netware is still alive (unfortunately!) and ncpfs is used in a lot of
>> Universities here in the UK at least (we use it about a thousand workstations and
>> servers here at Cambridge University!).
>
>Ok, that means at least when someone gets around to fix it, there will be
>people that can test the patches.
>
>If you know someone who would like to help on this, it would be nice to try
>out the patch below, unless someone can come up with a better solution.
>My naïve understanding of the code tells me that simply using the super block
>lock there may work. In fact it makes locking stricter, so if it still works
>with that patch, there are probably no subtle regressions.
>The patch applies to current linux-next of my bkl/vfs series.
>
> Arnd
>
>---
>ncpfs: replace BKL with lock_super
>
>This mindlessly changes every instance of lock_kernel in ncpfs to
>lock_super. I haven't tested this, it may work or may break horribly.
>Please test with CONFIG_LOCKDEP enabled.
>
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
>diff --git a/fs/ncpfs/dir.c b/fs/ncpfs/dir.c
>index 9578cbe..303338d 100644
>--- a/fs/ncpfs/dir.c
>+++ b/fs/ncpfs/dir.c
>@@ -19,7 +19,6 @@
> #include <linux/mm.h>
> #include <asm/uaccess.h>
> #include <asm/byteorder.h>
>-#include <linux/smp_lock.h>
>
> #include <linux/ncp_fs.h>
>
>@@ -339,9 +338,10 @@ static int
> ncp_lookup_validate(struct dentry * dentry, struct nameidata *nd)
> {
> int res;
>- lock_kernel();
>+ struct super_block *sb = dentry->d_inode->i_sb;
>+ lock_super(sb);
> res = __ncp_lookup_validate(dentry);
>- unlock_kernel();
>+ unlock_super(sb);
> return res;
> }
>
>@@ -404,6 +404,7 @@ static int ncp_readdir(struct file *filp, void *dirent, filldir_t filldir)
> {
> struct dentry *dentry = filp->f_path.dentry;
> struct inode *inode = dentry->d_inode;
>+ struct super_block *sb = inode->i_sb;
> struct page *page = NULL;
> struct ncp_server *server = NCP_SERVER(inode);
> union ncp_dir_cache *cache = NULL;
>@@ -411,7 +412,7 @@ static int ncp_readdir(struct file *filp, void *dirent, filldir_t filldir)
> int result, mtime_valid = 0;
> time_t mtime = 0;
>
>- lock_kernel();
>+ lock_super(sb);
>
> ctl.page = NULL;
> ctl.cache = NULL;
>@@ -546,7 +547,7 @@ finished:
> page_cache_release(ctl.page);
> }
> out:
>- unlock_kernel();
>+ unlock_super(sb);
> return result;
> }
>
>@@ -794,12 +795,13 @@ out:
> static struct dentry *ncp_lookup(struct inode *dir, struct dentry *dentry, struct nameidata *nd)
> {
> struct ncp_server *server = NCP_SERVER(dir);
>+ struct super_block *sb = dir->i_sb;
> struct inode *inode = NULL;
> struct ncp_entry_info finfo;
> int error, res, len;
> __u8 __name[NCP_MAXPATHLEN + 1];
>
>- lock_kernel();
>+ lock_super(sb);
> error = -EIO;
> if (!ncp_conn_valid(server))
> goto finished;
>@@ -846,7 +848,7 @@ add_entry:
>
> finished:
> PPRINTK("ncp_lookup: result=%d\n", error);
>- unlock_kernel();
>+ unlock_super(sb);
> return ERR_PTR(error);
> }
>
>@@ -880,6 +882,7 @@ int ncp_create_new(struct inode *dir, struct dentry *dentry, int mode,
> {
> struct ncp_server *server = NCP_SERVER(dir);
> struct ncp_entry_info finfo;
>+ struct super_block *sb = dir->i_sb;
> int error, result, len;
> int opmode;
> __u8 __name[NCP_MAXPATHLEN + 1];
>@@ -888,7 +891,7 @@ int ncp_create_new(struct inode *dir, struct dentry *dentry, int mode,
> dentry->d_parent->d_name.name, dentry->d_name.name, mode);
>
> error = -EIO;
>- lock_kernel();
>+ lock_super(sb);
> if (!ncp_conn_valid(server))
> goto out;
>
>@@ -935,7 +938,7 @@ int ncp_create_new(struct inode *dir, struct dentry *dentry, int mode,
>
> error = ncp_instantiate(dir, dentry, &finfo);
> out:
>- unlock_kernel();
>+ unlock_super(sb);
> return error;
> }
>
>@@ -949,6 +952,7 @@ static int ncp_mkdir(struct inode *dir, struct dentry *dentry, int mode)
> {
> struct ncp_entry_info finfo;
> struct ncp_server *server = NCP_SERVER(dir);
>+ struct super_block *sb = dir->i_sb;
> int error, len;
> __u8 __name[NCP_MAXPATHLEN + 1];
>
>@@ -956,7 +960,7 @@ static int ncp_mkdir(struct inode *dir, struct dentry *dentry, int mode)
> dentry->d_parent->d_name.name, dentry->d_name.name);
>
> error = -EIO;
>- lock_kernel();
>+ lock_super(sb);
> if (!ncp_conn_valid(server))
> goto out;
>
>@@ -985,13 +989,14 @@ static int ncp_mkdir(struct inode *dir, struct dentry *dentry, int mode)
> error = ncp_instantiate(dir, dentry, &finfo);
> }
> out:
>- unlock_kernel();
>+ unlock_super(sb);
> return error;
> }
>
> static int ncp_rmdir(struct inode *dir, struct dentry *dentry)
> {
> struct ncp_server *server = NCP_SERVER(dir);
>+ struct super_block *sb = dir->i_sb;
> int error, result, len;
> __u8 __name[NCP_MAXPATHLEN + 1];
>
>@@ -999,7 +1004,7 @@ static int ncp_rmdir(struct inode *dir, struct dentry *dentry)
> dentry->d_parent->d_name.name, dentry->d_name.name);
>
> error = -EIO;
>- lock_kernel();
>+ lock_super(sb);
> if (!ncp_conn_valid(server))
> goto out;
>
>@@ -1040,17 +1045,18 @@ static int ncp_rmdir(struct inode *dir, struct dentry *dentry)
> break;
> }
> out:
>- unlock_kernel();
>+ unlock_super(sb);
> return error;
> }
>
> static int ncp_unlink(struct inode *dir, struct dentry *dentry)
> {
> struct inode *inode = dentry->d_inode;
>+ struct super_block *sb = dir->i_sb;
> struct ncp_server *server;
> int error;
>
>- lock_kernel();
>+ lock_super(sb);
> server = NCP_SERVER(dir);
> DPRINTK("ncp_unlink: unlinking %s/%s\n",
> dentry->d_parent->d_name.name, dentry->d_name.name);
>@@ -1102,7 +1108,7 @@ static int ncp_unlink(struct inode *dir, struct dentry *dentry)
> }
>
> out:
>- unlock_kernel();
>+ unlock_super(sb);
> return error;
> }
>
>@@ -1110,6 +1116,7 @@ static int ncp_rename(struct inode *old_dir, struct dentry *old_dentry,
> struct inode *new_dir, struct dentry *new_dentry)
> {
> struct ncp_server *server = NCP_SERVER(old_dir);
>+ struct super_block *sb = old_dir->i_sb;
> int error;
> int old_len, new_len;
> __u8 __old_name[NCP_MAXPATHLEN + 1], __new_name[NCP_MAXPATHLEN + 1];
>@@ -1119,7 +1126,7 @@ static int ncp_rename(struct inode *old_dir, struct dentry *old_dentry,
> new_dentry->d_parent->d_name.name, new_dentry->d_name.name);
>
> error = -EIO;
>- lock_kernel();
>+ lock_super(sb);
> if (!ncp_conn_valid(server))
> goto out;
>
>@@ -1165,7 +1172,7 @@ static int ncp_rename(struct inode *old_dir, struct dentry *old_dentry,
> break;
> }
> out:
>- unlock_kernel();
>+ unlock_super(sb);
> return error;
> }
>
>diff --git a/fs/ncpfs/file.c b/fs/ncpfs/file.c
>index 3639cc5..a871df0 100644
>--- a/fs/ncpfs/file.c
>+++ b/fs/ncpfs/file.c
>@@ -17,7 +17,6 @@
> #include <linux/mm.h>
> #include <linux/vmalloc.h>
> #include <linux/sched.h>
>-#include <linux/smp_lock.h>
>
> #include <linux/ncp_fs.h>
> #include "ncplib_kernel.h"
>@@ -284,9 +283,11 @@ static int ncp_release(struct inode *inode, struct file *file) {
> static loff_t ncp_remote_llseek(struct file *file, loff_t offset, int origin)
> {
> loff_t ret;
>- lock_kernel();
>+ struct super_block *sb = file->f_path.dentry->d_inode->i_sb;
>+
>+ lock_super(sb);
> ret = generic_file_llseek_unlocked(file, offset, origin);
>- unlock_kernel();
>+ unlock_super(sb);
> return ret;
> }
>
>diff --git a/fs/ncpfs/inode.c b/fs/ncpfs/inode.c
>index cdf0fce..f37d297 100644
>--- a/fs/ncpfs/inode.c
>+++ b/fs/ncpfs/inode.c
>@@ -26,7 +26,6 @@
> #include <linux/slab.h>
> #include <linux/vmalloc.h>
> #include <linux/init.h>
>-#include <linux/smp_lock.h>
> #include <linux/vfs.h>
> #include <linux/mount.h>
> #include <linux/seq_file.h>
>@@ -445,12 +444,12 @@ static int ncp_fill_super(struct super_block *sb, void *raw_data, int silent)
> #endif
> struct ncp_entry_info finfo;
>
>- lock_kernel();
>+ lock_super(sb);
>
> data.wdog_pid = NULL;
> server = kzalloc(sizeof(struct ncp_server), GFP_KERNEL);
> if (!server) {
>- unlock_kernel();
>+ unlock_super(sb);
> return -ENOMEM;
> }
> sb->s_fs_info = server;
>@@ -704,7 +703,7 @@ static int ncp_fill_super(struct super_block *sb, void *raw_data, int silent)
> if (!sb->s_root)
> goto out_no_root;
> sb->s_root->d_op = &ncp_root_dentry_operations;
>- unlock_kernel();
>+ unlock_super(sb);
> return 0;
>
> out_no_root:
>@@ -741,7 +740,7 @@ out:
> put_pid(data.wdog_pid);
> sb->s_fs_info = NULL;
> kfree(server);
>- unlock_kernel();
>+ unlock_super(sb);
> return error;
> }
>
>@@ -749,7 +748,7 @@ static void ncp_put_super(struct super_block *sb)
> {
> struct ncp_server *server = NCP_SBP(sb);
>
>- lock_kernel();
>+ lock_super(sb);
>
> ncp_lock_server(server);
> ncp_disconnect(server);
>@@ -778,7 +777,7 @@ static void ncp_put_super(struct super_block *sb)
> sb->s_fs_info = NULL;
> kfree(server);
>
>- unlock_kernel();
>+ unlock_super(sb);
> }
>
> static int ncp_statfs(struct dentry *dentry, struct kstatfs *buf)
>@@ -850,6 +849,7 @@ dflt:;
> int ncp_notify_change(struct dentry *dentry, struct iattr *attr)
> {
> struct inode *inode = dentry->d_inode;
>+ struct super_block *sb = inode->i_sb;
> int result = 0;
> __le32 info_mask;
> struct nw_modify_dos_info info;
>@@ -857,7 +857,7 @@ int ncp_notify_change(struct dentry *dentry, struct iattr *attr)
>
> result = -EIO;
>
>- lock_kernel();
>+ lock_super(sb);
>
> server = NCP_SERVER(inode);
> if ((!server) || !ncp_conn_valid(server))
>@@ -1011,7 +1011,7 @@ int ncp_notify_change(struct dentry *dentry, struct iattr *attr)
> mark_inode_dirty(inode);
>
> out:
>- unlock_kernel();
>+ unlock_super(sb);
> return result;
> }
>
>diff --git a/fs/ncpfs/ioctl.c b/fs/ncpfs/ioctl.c
>index 84a8cfc..4ce88d4 100644
>--- a/fs/ncpfs/ioctl.c
>+++ b/fs/ncpfs/ioctl.c
>@@ -17,7 +17,6 @@
> #include <linux/mount.h>
> #include <linux/slab.h>
> #include <linux/highuid.h>
>-#include <linux/smp_lock.h>
> #include <linux/vmalloc.h>
> #include <linux/sched.h>
>
>@@ -844,8 +843,9 @@ static int ncp_ioctl_need_write(unsigned int cmd)
> long ncp_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> {
> long ret;
>+ struct super_block *sb = filp->f_path.dentry->d_inode->i_sb;
>
>- lock_kernel();
>+ lock_super(sb);
> if (ncp_ioctl_need_write(cmd)) {
> /*
> * inside the ioctl(), any failures which
>@@ -863,19 +863,20 @@ long ncp_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> mnt_drop_write(filp->f_path.mnt);
>
> out:
>- unlock_kernel();
>+ unlock_super(sb);
> return ret;
> }
>
> #ifdef CONFIG_COMPAT
> long ncp_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> {
>+ struct super_block *sb = file->f_path.dentry->d_inode->i_sb;
> long ret;
>
>- lock_kernel();
>+ lock_super(sb);
> arg = (unsigned long) compat_ptr(arg);
> ret = ncp_ioctl(file, cmd, arg);
>- unlock_kernel();
>+ unlock_super(sb);
> return ret;
> }
> #endif
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: linux-next: build failure after merge of the rcu tree
From: Paul E. McKenney @ 2010-09-17 23:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Eric Dumazet, David Miller, netdev
In-Reply-To: <20100917124238.aa0596cb.sfr@canb.auug.org.au>
On Fri, Sep 17, 2010 at 12:42:38PM +1000, Stephen Rothwell wrote:
> Hi Paul,
>
> After merging the rcu tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/core/dev.c: In function 'netdev_run_todo':
> net/core/dev.c:5294: error: dereferencing pointer to incomplete type
> net/core/dev.c:5294: warning: type defaults to 'int' in declaration of '_________p1'
> net/core/dev.c:5294: error: dereferencing pointer to incomplete type
> net/core/dev.c:5294: warning: type defaults to 'int' in declaration of 'type name'
> net/core/dev.c:5294: error: dereferencing pointer to incomplete type
> net/core/dev.c:5294: warning: type defaults to 'int' in declaration of 'type name'
> net/core/dev.c:5294: warning: comparison of distinct pointer types lacks a cast
> net/core/dev.c:5294: error: dereferencing pointer to incomplete type
> net/core/dev.c:5294: warning: type defaults to 'int' in declaration of 'type name'
>
> Caused by commit ca5ecddfa8fcbd948c95530e7e817cee9fb43a3d ("rcu: define
> __rcu address space modifier for sparse") interacting with commit
> 95ae6b228f814fc0528d0506ee9f18ac333d6851 ("ipv4: ip_ptr cleanups") from
> the net tree.
>
> rcu_dereference_raw() now needs to know the type of the object its
> argument points to. I added the following merge fix (which could be
> applied to the net tree anyway).
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 17 Sep 2010 12:36:36 +1000
> Subject: [PATCH] net: include inetdevice.h for rcu_dereference_raw api change
>
> rcu_dereference_raw() now needs to know the type of its argument.
Good catch, thank you!!!
Thanx, Paul
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> net/core/dev.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index c6d837a..cadd28c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -129,6 +129,7 @@
> #include <linux/random.h>
> #include <trace/events/napi.h>
> #include <linux/pci.h>
> +#include <linux/inetdevice.h>
>
> #include "net-sysfs.h"
>
> --
> 1.7.1
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [net-next 4/4] stmmac: use one memset() to reset TDES01
From: David Miller @ 2010-09-17 23:13 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1284729822-29176-4-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri, 17 Sep 2010 15:23:42 +0200
> Use one memset() to reset all TDES01 fields instead
> of one by one to reduce number of instructions.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [net-next 3/4] stmmac: prevent dma init stuck in case of failures.
From: David Miller @ 2010-09-17 23:13 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1284729822-29176-3-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri, 17 Sep 2010 15:23:41 +0200
> Add a limit when perform the DMA reset procedure
> so, in case of problems (i.e. PHY reset failed) the
> Kernel won't hang on the stmmac DMA initialisation
> blocking the Kernels execution.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [net-next 2/4] stmmac: consolidate and tidy-up the COE support
From: David Miller @ 2010-09-17 23:13 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, js, deepak.sikri
In-Reply-To: <1284729822-29176-2-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri, 17 Sep 2010 15:23:40 +0200
> The first version of the driver had hard-coded the logic
> for handling the checksum offloading.
> This was designed according to the chips included in
> the STM platforms where:
> o MAC10/100 supports no COE at all.
> o GMAC fully supports RX/TX COE.
>
> This is not good for other chip configurations where,
> for example, the mac10/100 supports the tx csum in HW
> or when the GMAC has no IPC.
>
> Thanks to Johannes Stezenbach; he provided me a first
> draft of this patch that only reviewed the IPC for the
> GMAC devices.
>
> This patch also helps on SPEAr platforms where the
> MAC10/100 can perform the TX csum in HW.
> Thanks to Deepak SIKRI for his support on this.
>
> In the end, GMAC devices for STM platforms have
> a bugged Jumbo frame support that needs to have
> the Tx COE disabled for oversized frames (due to
> limited buffer sizes). This information is also
> passed through the driver's platform structure.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Signed-off-by: Johannes Stezenbach <js@sig21.net>
> Signed-off-by: Deepak SIKRI <deepak.sikri@st.com>
Applied.
^ permalink raw reply
* Re: [net-next 1/4] stmmac: add CSR Clock range selection
From: David Miller @ 2010-09-17 23:13 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, js
In-Reply-To: <1284729822-29176-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri, 17 Sep 2010 15:23:39 +0200
> This patch adds the CSR Clock range selection.
>
> Original patch from Johannes Stezenbach fixed the CSR
> in the stmmac_mdio. We agreed to provide this through
> the platform instead of.
> Also thanks to Johannes for having tested it on ARM.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Signed-off-by: Johannes Stezenbach <js@sig21.net>
Applied.
^ permalink raw reply
* Re: [PATCH stable-2.6.32] Phonet: disable network namespace support
From: David Miller @ 2010-09-17 23:04 UTC (permalink / raw)
To: remi; +Cc: linux-kernel, netdev, remi.denis-courmont, ebiederm, stable
In-Reply-To: <1284763006-22075-1-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Sat, 18 Sep 2010 01:36:46 +0300
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Network namespace in the Phonet socket stack causes an OOPS when a
> namespace is destroyed. This occurs as the loopback exit_net handler is
> called after the Phonet exit_net handler, and re-enters the Phonet
> stack. I cannot think of any nice way to fix this in kernel <= 2.6.32.
>
> For lack of a better solution, disable namespace support completely.
> If you need that, upgrade to a newer kernel.
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
"lkml" address fixed, and -stable CC: added this time, please don't
omit that if you want to submit stable networking patches that have no
upstream counterpart.
Acked-by: David S. Miller <davem@davemloft.net>
> ---
> net/phonet/af_phonet.c | 4 ++++
> net/phonet/pn_dev.c | 12 ++++++++++--
> net/phonet/pn_netlink.c | 9 ++++++++-
> 3 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/net/phonet/af_phonet.c b/net/phonet/af_phonet.c
> index f60c0c2..519ff9d 100644
> --- a/net/phonet/af_phonet.c
> +++ b/net/phonet/af_phonet.c
> @@ -67,6 +67,8 @@ static int pn_socket_create(struct net *net, struct socket *sock, int protocol)
> struct phonet_protocol *pnp;
> int err;
>
> + if (!net_eq(net, &init_net))
> + return -EAFNOSUPPORT;
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
>
> @@ -353,6 +355,8 @@ static int phonet_rcv(struct sk_buff *skb, struct net_device *dev,
> struct sockaddr_pn sa;
> u16 len;
>
> + if (!net_eq(net, &init_net))
> + goto out;
> /* check we have at least a full Phonet header */
> if (!pskb_pull(skb, sizeof(struct phonethdr)))
> goto out;
> diff --git a/net/phonet/pn_dev.c b/net/phonet/pn_dev.c
> index 5f42f30..5a2275c 100644
> --- a/net/phonet/pn_dev.c
> +++ b/net/phonet/pn_dev.c
> @@ -246,7 +246,11 @@ static struct notifier_block phonet_device_notifier = {
> /* Per-namespace Phonet devices handling */
> static int phonet_init_net(struct net *net)
> {
> - struct phonet_net *pnn = kmalloc(sizeof(*pnn), GFP_KERNEL);
> + struct phonet_net *pnn;
> +
> + if (!net_eq(net, &init_net))
> + return 0;
> + pnn = kmalloc(sizeof(*pnn), GFP_KERNEL);
> if (!pnn)
> return -ENOMEM;
>
> @@ -263,9 +267,13 @@ static int phonet_init_net(struct net *net)
>
> static void phonet_exit_net(struct net *net)
> {
> - struct phonet_net *pnn = net_generic(net, phonet_net_id);
> + struct phonet_net *pnn;
> struct net_device *dev;
>
> + if (!net_eq(net, &init_net))
> + return;
> + pnn = net_generic(net, phonet_net_id);
> +
> rtnl_lock();
> for_each_netdev(net, dev)
> phonet_device_destroy(dev);
> diff --git a/net/phonet/pn_netlink.c b/net/phonet/pn_netlink.c
> index d21fd35..7acab1e 100644
> --- a/net/phonet/pn_netlink.c
> +++ b/net/phonet/pn_netlink.c
> @@ -68,6 +68,8 @@ static int addr_doit(struct sk_buff *skb, struct nlmsghdr *nlh, void *attr)
> int err;
> u8 pnaddr;
>
> + if (!net_eq(net, &init_net))
> + return -EOPNOTSUPP;
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
>
> @@ -124,12 +126,16 @@ nla_put_failure:
>
> static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
> {
> + struct net *net = sock_net(skb->sk);
> struct phonet_device_list *pndevs;
> struct phonet_device *pnd;
> int dev_idx = 0, dev_start_idx = cb->args[0];
> int addr_idx = 0, addr_start_idx = cb->args[1];
>
> - pndevs = phonet_device_list(sock_net(skb->sk));
> + if (!net_eq(net, &init_net))
> + goto skip;
> +
> + pndevs = phonet_device_list(net);
> spin_lock_bh(&pndevs->lock);
> list_for_each_entry(pnd, &pndevs->list, list) {
> u8 addr;
> @@ -154,6 +160,7 @@ static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
>
> out:
> spin_unlock_bh(&pndevs->lock);
> +skip:
> cb->args[0] = dev_idx;
> cb->args[1] = addr_idx;
>
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH stable-2.6.32] Phonet: disable network namespace support
From: David Miller @ 2010-09-17 23:03 UTC (permalink / raw)
To: remi; +Cc: lkml, netdev, remi.denis-courmont, ebiederm
In-Reply-To: <1284763006-22075-1-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Sat, 18 Sep 2010 01:36:46 +0300
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Network namespace in the Phonet socket stack causes an OOPS when a
> namespace is destroyed. This occurs as the loopback exit_net handler is
> called after the Phonet exit_net handler, and re-enters the Phonet
> stack. I cannot think of any nice way to fix this in kernel <= 2.6.32.
>
> For lack of a better solution, disable namespace support completely.
> If you need that, upgrade to a newer kernel.
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: add rcu annotations in route.c
From: David Miller @ 2010-09-17 22:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1284753573.4373.7.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 17 Sep 2010 21:59:33 +0200
> Le vendredi 17 septembre 2010 à 17:59 +0200, Eric Dumazet a écrit :
>> Use __rcu attribute where appropriate.
>>
>> Use rcu_dereference_raw() in contexts where no lock is held.
>>
>> Use rcu_dereference_check() in contexts where the chain spinlock is
>> held.
>
> Hmm, it should be rcu_dereference_protected(), I'll send a v2
Ok.
^ permalink raw reply
* Re: Linux Plumbers Conference: User-visible Network Issues Mini-Conf
From: David Miller @ 2010-09-17 22:57 UTC (permalink / raw)
To: Matt_Domsch; +Cc: netdev
In-Reply-To: <1B9798A3396AB0429545ADFEA207931510536C7C8E@AUSX7MCPS302.AMER.DELL.COM>
From: <Matt_Domsch@Dell.com>
Date: Fri, 17 Sep 2010 14:12:29 -0500
> At the Linux Plumbers Conference [1] November 3-5, 2010 in
> Cambridge, MA, we have a half-day mini-conference [2] set aside to
> discuss "User-visible Network Issues" - challenges that users face,
> that could benefit from both userspace and kernel enhancements to
> make their lives easier.
When you schedule this track, try to keep it off of November 3rd as
the core kernel network folk are holding netconf at LPC for that
entire day.
That is, unless you don't want any of us to attend :-)
^ permalink raw reply
* [PATCH stable-2.6.32] Phonet: disable network namespace support
From: Rémi Denis-Courmont @ 2010-09-17 22:36 UTC (permalink / raw)
To: lkml, netdev; +Cc: Rémi Denis-Courmont, Eric W. Biederman
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Network namespace in the Phonet socket stack causes an OOPS when a
namespace is destroyed. This occurs as the loopback exit_net handler is
called after the Phonet exit_net handler, and re-enters the Phonet
stack. I cannot think of any nice way to fix this in kernel <= 2.6.32.
For lack of a better solution, disable namespace support completely.
If you need that, upgrade to a newer kernel.
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
---
net/phonet/af_phonet.c | 4 ++++
net/phonet/pn_dev.c | 12 ++++++++++--
net/phonet/pn_netlink.c | 9 ++++++++-
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/net/phonet/af_phonet.c b/net/phonet/af_phonet.c
index f60c0c2..519ff9d 100644
--- a/net/phonet/af_phonet.c
+++ b/net/phonet/af_phonet.c
@@ -67,6 +67,8 @@ static int pn_socket_create(struct net *net, struct socket *sock, int protocol)
struct phonet_protocol *pnp;
int err;
+ if (!net_eq(net, &init_net))
+ return -EAFNOSUPPORT;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
@@ -353,6 +355,8 @@ static int phonet_rcv(struct sk_buff *skb, struct net_device *dev,
struct sockaddr_pn sa;
u16 len;
+ if (!net_eq(net, &init_net))
+ goto out;
/* check we have at least a full Phonet header */
if (!pskb_pull(skb, sizeof(struct phonethdr)))
goto out;
diff --git a/net/phonet/pn_dev.c b/net/phonet/pn_dev.c
index 5f42f30..5a2275c 100644
--- a/net/phonet/pn_dev.c
+++ b/net/phonet/pn_dev.c
@@ -246,7 +246,11 @@ static struct notifier_block phonet_device_notifier = {
/* Per-namespace Phonet devices handling */
static int phonet_init_net(struct net *net)
{
- struct phonet_net *pnn = kmalloc(sizeof(*pnn), GFP_KERNEL);
+ struct phonet_net *pnn;
+
+ if (!net_eq(net, &init_net))
+ return 0;
+ pnn = kmalloc(sizeof(*pnn), GFP_KERNEL);
if (!pnn)
return -ENOMEM;
@@ -263,9 +267,13 @@ static int phonet_init_net(struct net *net)
static void phonet_exit_net(struct net *net)
{
- struct phonet_net *pnn = net_generic(net, phonet_net_id);
+ struct phonet_net *pnn;
struct net_device *dev;
+ if (!net_eq(net, &init_net))
+ return;
+ pnn = net_generic(net, phonet_net_id);
+
rtnl_lock();
for_each_netdev(net, dev)
phonet_device_destroy(dev);
diff --git a/net/phonet/pn_netlink.c b/net/phonet/pn_netlink.c
index d21fd35..7acab1e 100644
--- a/net/phonet/pn_netlink.c
+++ b/net/phonet/pn_netlink.c
@@ -68,6 +68,8 @@ static int addr_doit(struct sk_buff *skb, struct nlmsghdr *nlh, void *attr)
int err;
u8 pnaddr;
+ if (!net_eq(net, &init_net))
+ return -EOPNOTSUPP;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
@@ -124,12 +126,16 @@ nla_put_failure:
static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
{
+ struct net *net = sock_net(skb->sk);
struct phonet_device_list *pndevs;
struct phonet_device *pnd;
int dev_idx = 0, dev_start_idx = cb->args[0];
int addr_idx = 0, addr_start_idx = cb->args[1];
- pndevs = phonet_device_list(sock_net(skb->sk));
+ if (!net_eq(net, &init_net))
+ goto skip;
+
+ pndevs = phonet_device_list(net);
spin_lock_bh(&pndevs->lock);
list_for_each_entry(pnd, &pndevs->list, list) {
u8 addr;
@@ -154,6 +160,7 @@ static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
out:
spin_unlock_bh(&pndevs->lock);
+skip:
cb->args[0] = dev_idx;
cb->args[1] = addr_idx;
--
1.7.0.4
^ permalink raw reply related
* Re: Possible regression with skb_clone() in 2.6.36
From: Andrew Morton @ 2010-09-17 22:34 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
marcel-kz+m5ild9QBg9hUCZPvPmw
In-Reply-To: <1283209824-8795-1-git-send-email-padovan-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org>
On Mon, 30 Aug 2010 20:10:23 -0300
"Gustavo F. Padovan" <padovan-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org> wrote:
> I've been experiencing some problems when running the L2CAP Streaming mode in
> 2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
> wasn't happening before, so I think we may have a regression here (I didn't find
> where yet). The crash log is below.
So 2.6.35 was OK?
> The following patch does not fix the regression, but shows that removing the
> skb_clone() call from l2cap_streaming_send() makes the problem goes away. The
> patch is good anyway since it saves memory and time when sending Streaming mode
> packets.
How does "make it go away" differ from "fix the regression" :)
But yes, if we don't understand the source of the bug then it may well
still be there. Did you make any progress in understanding the cause?
>
> [ 5066.137533] Bluetooth: L2CAP ver 2.15
> [ 5066.137873] Bluetooth: L2CAP socket layer initialized
> [ 5066.545179] Bluetooth: RFCOMM TTY layer initialized
> [ 5066.545879] Bluetooth: RFCOMM socket layer initialized
> [ 5066.546582] Bluetooth: RFCOMM ver 1.11
> [ 5092.268021] l2test invoked oom-killer: gfp_mask=0x4d0, order=0, oom_adj=0, oom_score_adj=0
> [ 5092.268872] Pid: 3897, comm: l2test Not tainted 2.6.36-rc3 #5
> [ 5092.269863] Call Trace:
> [ 5092.270265] [<ffffffff8138b6a6>] ? _raw_spin_unlock+0x26/0x30
> [ 5092.270878] [<ffffffff810c0827>] T.427+0x77/0x1e0
> [ 5092.271874] [<ffffffff811b85e7>] ? security_real_capable_noaudit+0x37/0x60
> [ 5092.272956] [<ffffffff810c0e3a>] out_of_memory+0x2ca/0x2f0
> [ 5092.273894] [<ffffffff810c3d43>] __alloc_pages_nodemask+0x693/0x6b0
> [ 5092.274871] [<ffffffff810ea3e6>] cache_alloc_refill+0x2d6/0x5c0
> [ 5092.275864] [<ffffffff810ea805>] __kmalloc+0x135/0x150
> [ 5092.276876] [<ffffffff8130f2ae>] __alloc_skb+0x6e/0x150
> [ 5092.277865] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
> [ 5092.278652] [<ffffffff8130ace2>] sock_alloc_send_pskb+0x1c2/0x320
> [ 5092.278927] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
> [ 5092.279864] [<ffffffff81312add>] ? memcpy_fromiovec+0x6d/0x90
> [ 5092.280864] [<ffffffff8130ae50>] sock_alloc_send_skb+0x10/0x20
> [ 5092.281867] [<ffffffffa00e600f>] l2cap_create_iframe_pdu+0x9f/0x2c0 [l2cap]
> [ 5092.282865] [<ffffffffa00e84b9>] l2cap_sock_sendmsg+0x5d9/0x910 [l2cap]
> [ 5092.283932] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
> [ 5092.284865] [<ffffffff8130725b>] sock_sendmsg+0xdb/0x100
> [ 5092.285652] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
> [ 5092.285864] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
> [ 5092.286864] [<ffffffff813073c0>] sys_sendto+0xf0/0x130
> [ 5092.287864] [<ffffffff8138b60b>] ? _raw_spin_unlock_irq+0x2b/0x40
> [ 5092.288872] [<ffffffff81093cfd>] ? trace_hardirqs_on_caller+0x13d/0x180
> [ 5092.289927] [<ffffffff81093d4d>] ? trace_hardirqs_on+0xd/0x10
> [ 5092.290864] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
> [ 5092.291649] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
> [ 5092.291864] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
> [ 5092.292864] [<ffffffff8130740f>] sys_send+0xf/0x20
> [ 5092.293870] [<ffffffff8132ccd6>] compat_sys_socketcall+0x146/0x1f0
> [ 5092.294875] [<ffffffff81053ee4>] sysenter_dispatch+0x7/0x30
That's a pretty serious regression.
^ permalink raw reply
* Re: How about the order of Network stack initialize
From: Randy Dunlap @ 2010-09-17 21:19 UTC (permalink / raw)
To: Huangqiang Zhou; +Cc: ly, linux-net, netdev
In-Reply-To: <201009160906134537778@gmail.com>
On Thu, 16 Sep 2010 09:06:16 +0800 Huangqiang Zhou wrote:
> Hi all：
>
> I have a question about the order of network stack initialize.
>
> From some books it says the order is as below:
> 1.core_initcall: sock_init
> 2.fs_initcall: inet_init
> 3.subsys_initcall: net_dev_init
> 4.device_initcall: device init
>
> in the source code of linux2.6.18:
> #define core_initcall(fn) __define_initcall("1",fn)
> #define postcore_initcall(fn) __define_initcall("2",fn)
> #define arch_initcall(fn) __define_initcall("3",fn)
> #define subsys_initcall(fn) __define_initcall("4",fn)
> #define fs_initcall(fn) __define_initcall("5",fn)
> #define device_initcall(fn) __define_initcall("6",fn)
> #define late_initcall(fn) __define_initcall("7",fn)
>
> obviously:
> macro section
> core_initcall <--> .initcall1.init
> fs_initcall <--> .initcall5.init
> subsys_initcall <--> .initcall4.init
> device_intcall <--> .initcall6.init
>
> Some also says：
> “Every child is to determine the sequence between sections, the first call. Initcall1 init.
> The function pointer, again. Initcall2 init. Call the function pointer, etc. And in each section
> of the function pointer is associated with links to order, is uncertain ”
>
> As the above says, the order should be: core_initcall->subsys_initcall->fs_initcall->device_intcall
>
> So which one is really correct?
>
> 2010-09-15
> Huangqiang Zhou
Hi,
BTW, did you find out anything from your previous posting's answers?
http://marc.info/?l=linux-net&m=128443018603483&w=2
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: Seeing transmit timeouts on 8139cp
From: Francois Romieu @ 2010-09-17 20:00 UTC (permalink / raw)
To: Philip Prindeville; +Cc: Linux Netdev List
In-Reply-To: <4C92F853.8050701@redfish-solutions.com>
Philip Prindeville <philipp_subx@redfish-solutions.com> :
[...]
> Does this look familiar to anyone?
349124a00754129a5f1e43efa84733e364bf3749 ?
It would be a bit too easy.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: add rcu annotations in route.c
From: Eric Dumazet @ 2010-09-17 19:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1284739159.3391.95.camel@edumazet-laptop>
Le vendredi 17 septembre 2010 à 17:59 +0200, Eric Dumazet a écrit :
> Use __rcu attribute where appropriate.
>
> Use rcu_dereference_raw() in contexts where no lock is held.
>
> Use rcu_dereference_check() in contexts where the chain spinlock is
> held.
Hmm, it should be rcu_dereference_protected(), I'll send a v2
This is a bit tricky ...
^ permalink raw reply
* Re: [PATCH] Move "struct net" declaration inside the __KERNEL__ macro guard
From: Ollie Wild @ 2010-09-17 19:38 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Andrew Morton, David Marmaros
In-Reply-To: <AANLkTimXnjnkNgwtEVpXKYMxXgmBdye=Gtjeggd4N9UA@mail.gmail.com>
(Resending with a proper signoff.)
This patch reduces namespace pollution by moving the "struct net" declaration
out of the userspace-facing portion of linux/netlink.h. It has no impact on
the kernel, and the declaration is not referenced anywhere outside the
__KERNEL__ macro guard.
(This came up because we have several C++ applications which use "net" as a
namespace name.)
Ollie
Signed-off-by: Ollie Wild <aaw@google.com>
---
include/linux/netlink.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index 59d0669..1235669 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -27,8 +27,6 @@
#define MAX_LINKS 32
-struct net;
-
struct sockaddr_nl {
sa_family_t nl_family; /* AF_NETLINK */
unsigned short nl_pad; /* zero */
@@ -151,6 +149,8 @@ struct nlattr {
#include <linux/capability.h>
#include <linux/skbuff.h>
+struct net;
+
static inline struct nlmsghdr *nlmsg_hdr(const struct sk_buff *skb)
{
return (struct nlmsghdr *)skb->data;
--
1.7.0.4
^ permalink raw reply related
* [PATCH] bonding: enable gro by default
From: Eric Dumazet @ 2010-09-17 19:25 UTC (permalink / raw)
To: David Miller, Jay Vosburgh
Cc: shemminger, bphilips, e1000-devel, bruce.w.allan,
jesse.brandeburg, john.ronciak, jeffrey.t.kirsher, netdev,
bhutchings
In-Reply-To: <20100917.115707.106807995.davem@davemloft.net>
Le vendredi 17 septembre 2010 à 11:57 -0700, David Miller a écrit :
> Applied, thanks Eric.
>
> Can you do whatever change is needed to get it enabled by default?
>
Sure ;)
[PATCH] bonding: enable gro by default
gro can be enabled by default on bonding devices.
Actual support depends on the lower devices.
One can still use ethtool to switch off GRO if needed.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/bonding/bond_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 3b16f62..80610a6 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4678,6 +4678,10 @@ static void bond_setup(struct net_device *bond_dev)
NETIF_F_HW_VLAN_RX |
NETIF_F_HW_VLAN_FILTER);
+ /* By default, we enable GRO on bonding devices.
+ * Actual support requires lowlevel drivers are GRO ready.
+ */
+ bond_dev->features |= NETIF_F_GRO;
}
static void bond_work_cancel_all(struct bonding *bond)
^ permalink raw reply related
* Linux Plumbers Conference: User-visible Network Issues Mini-Conf
From: Matt_Domsch @ 2010-09-17 19:12 UTC (permalink / raw)
To: netdev
At the Linux Plumbers Conference [1] November 3-5, 2010 in Cambridge, MA, we have a half-day mini-conference [2] set aside to discuss "User-visible Network Issues" - challenges that users face, that could benefit from both userspace and kernel enhancements to make their lives easier.
Discussion proposals for this track are:
* Achieving Better Out-of-the-box Network Scaling
This is a discussion of how Linux needs to scale better out-of-the-box with large I/O network devices.
Peter Waskiewicz
* Challenges in Mobile Networking
Challenges that we have with networking in the mobile space.
Dan Williams and Marcel Holtmann
* Data Center Bridging: Creating DCB aware networks
Presentation will highlight the ongoing efforts for enabling data center bridging technologies in the Linux kernel to meet the requirements of applications and stacks over Ethernet.
John Fastabend
* Network Device Naming
Which of my NICs is eth0?
Matt Domsch
* Scaling techniques in the stack for servers with high connection rates
This talk will describe some techniques for scaling front end servers. In particular, we will describe the the use of SO_REUSEPORT in scaling servers for high connection rates with a single listening port.
Tom Herbert
* Simplifying network configuration for VMs by harmonizing multiple Bridging, QOS, DCB and CNA implementations
Shyam Iyer
While I'm sure the individual topics will generate great discussion, it will be vital that members of the netdev community be present to represent the kernel developers' perspectives on the problems and to help brainstorm solutions. Most of these topics have significant kernel components to them, and without additional kernel developer participation, I fear we would just be talking to ourselves, but no real progress made.
I invite you to attend LPC, and this mini-conf in particular, and lend your expertise. If you will be attending, which of the above topics are of most interest to you? We won't be able to cover all of these in the mini-conf, so those with the most interest (plus mine of course!) will make the agenda.
Thanks,
Matt
[1] http://www.linuxplumbersconf.org/2010/
[2] http://www.linuxplumbersconf.org/2010/ocw/events/LPC2010MC/tracks/63
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH] ethtool: change ethtool_set_gro() to use ethtool_op_get_rx_csum
From: David Miller @ 2010-09-17 18:57 UTC (permalink / raw)
To: eric.dumazet
Cc: shemminger, bphilips, e1000-devel, bruce.w.allan,
jesse.brandeburg, john.ronciak, jeffrey.t.kirsher, netdev,
bhutchings
In-Reply-To: <1284624663.3352.9.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 16 Sep 2010 10:11:03 +0200
> [PATCH] ethtool: change ethtool_set_gro() to use ethtool_op_get_rx_csum
>
> To be able to switch on GRO on a device, ethtool_set_gro() checks this
> device provides a get_rx_csum() method.
>
> Some devices dont provide this method, while they do support RX
> checksumming.
>
> This patch allows bonding to support GRO :
>
> ethtool -K bond0 gro on
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
Can you do whatever change is needed to get it enabled by default?
Thanks again.
^ permalink raw reply
* Re: Remaining BKL users, what to do
From: Arnd Bergmann @ 2010-09-17 18:46 UTC (permalink / raw)
To: Jens Axboe
Cc: Steven Rostedt, codalist@coda.cs.cmu.edu, autofs@linux.kernel.org,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
Christoph Hellwig, Mikulas Patocka, Trond Myklebust,
Petr Vandrovec, Anders Larsen, Jan Kara, Evgeniy Dushistov,
Ingo Molnar, netdev@vger.kernel.org, Samuel Ortiz,
Arnaldo Carvalho de Melo, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrew Hendry
In-Reply-To: <4C9262C4.9050006@fusionio.com>
On Thursday 16 September 2010 20:32:36 Jens Axboe wrote:
> On 2010-09-16 16:49, Steven Rostedt wrote:
> > Git blame shows this to be your code (copied from block/blktrace.c from
> > years past).
> >
> > Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9)
>
> It isn't, it can be removed.
Ok, I queued up this patch now. Thanks!
Arnd
---
Subject: [PATCH] blktrace: remove the big kernel lock
According to Jens, this code does not need the BKL at all,
it is sufficiently serialized by bd_mutex.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jens Axboe <jaxboe@fusionio.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index 959f8d6..5328e87 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -23,7 +23,6 @@
#include <linux/mutex.h>
#include <linux/slab.h>
#include <linux/debugfs.h>
-#include <linux/smp_lock.h>
#include <linux/time.h>
#include <linux/uaccess.h>
@@ -639,7 +638,6 @@ int blk_trace_ioctl(struct block_device *bdev, unsigned cmd, char __user *arg)
if (!q)
return -ENXIO;
- lock_kernel();
mutex_lock(&bdev->bd_mutex);
switch (cmd) {
@@ -667,7 +665,6 @@ int blk_trace_ioctl(struct block_device *bdev, unsigned cmd, char __user *arg)
}
mutex_unlock(&bdev->bd_mutex);
- unlock_kernel();
return ret;
}
@@ -1652,10 +1649,9 @@ static ssize_t sysfs_blk_trace_attr_show(struct device *dev,
struct block_device *bdev;
ssize_t ret = -ENXIO;
- lock_kernel();
bdev = bdget(part_devt(p));
if (bdev == NULL)
- goto out_unlock_kernel;
+ goto out;
q = blk_trace_get_queue(bdev);
if (q == NULL)
@@ -1683,8 +1679,7 @@ out_unlock_bdev:
mutex_unlock(&bdev->bd_mutex);
out_bdput:
bdput(bdev);
-out_unlock_kernel:
- unlock_kernel();
+out:
return ret;
}
@@ -1714,11 +1709,10 @@ static ssize_t sysfs_blk_trace_attr_store(struct device *dev,
ret = -ENXIO;
- lock_kernel();
p = dev_to_part(dev);
bdev = bdget(part_devt(p));
if (bdev == NULL)
- goto out_unlock_kernel;
+ goto out;
q = blk_trace_get_queue(bdev);
if (q == NULL)
@@ -1753,8 +1747,6 @@ out_unlock_bdev:
mutex_unlock(&bdev->bd_mutex);
out_bdput:
bdput(bdev);
-out_unlock_kernel:
- unlock_kernel();
out:
return ret ? ret : count;
}
^ permalink raw reply related
* Re: [PATCHv2 NEXT 0/5]qlcnic: vlan rx accleration support
From: David Miller @ 2010-09-17 18:31 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1284700483-16397-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Thu, 16 Sep 2010 22:14:38 -0700
> Hi
> Series v2 of 5 patches to support vlan rx accleration.
> This takes care of Eric Dumazet comment of using dev_kfree_skb(skb).
>
> I haven't combined accleration and GRO patch. Though its look strange
> with first patch. But I want to have separate patches for two different
> entity.
All applied, thanks.
^ permalink raw reply
* Re: [PATCHv2 NEXT 2/5] qlcnic: vlan gro support
From: David Miller @ 2010-09-17 18:25 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <20100917.112455.191154697.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 17 Sep 2010 11:24:55 -0700 (PDT)
> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
> Date: Thu, 16 Sep 2010 22:14:40 -0700
>
>> @@ -796,7 +796,7 @@ qlcnic_set_netdev_features(struct qlcnic_adapter *adapter,
>> features = (NETIF_F_SG | NETIF_F_IP_CSUM |
>> NETIF_F_IPV6_CSUM | NETIF_F_GRO);
>> vlan_features = (NETIF_F_SG | NETIF_F_IP_CSUM |
>> - NETIF_F_IPV6_CSUM);
>> + NETIF_F_IPV6_CSUM | NETIF_F_GRO);
>>
>> if (adapter->capabilities & QLCNIC_FW_CAPABILITY_TSO) {
>> features |= (NETIF_F_TSO | NETIF_F_TSO6);
>> @@ -1456,7 +1456,7 @@ qlcnic_setup_netdev(struct qlcnic_adapter *adapter,
>> netdev->features |= (NETIF_F_SG | NETIF_F_IP_CSUM |
>> NETIF_F_IPV6_CSUM | NETIF_F_GRO | NETIF_F_HW_VLAN_RX);
>> netdev->vlan_features |= (NETIF_F_SG | NETIF_F_IP_CSUM |
>> - NETIF_F_IPV6_CSUM);
>> + NETIF_F_IPV6_CSUM | NETIF_F_GRO);
>>
>> if (adapter->capabilities & QLCNIC_FW_CAPABILITY_TSO) {
>
> Drivers no longer should set NETIF_F_GRO in their vlan_features
> flags, the generic networking core does this for you now in
> register_netdevice() in net-next-2.6
>
> Please respin this patch with these settings removed.
Actually, nevermind, I'll take care of doing this for you, just be
aware of this new convention.
Thank you.
^ permalink raw reply
* Re: problem with flowi structure
From: Nicola Padovano @ 2010-09-17 18:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: AIJAZ BAIG, netfilter-devel, netdev
In-Reply-To: <1284746879.2235.9.camel@edumazet-laptop>
On Fri, Sep 17, 2010 at 8:07 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 17 septembre 2010 à 20:01 +0200, Nicola Padovano a écrit :
>> > if you say now :
>> >
>> > Send a packet to google, please, I dont care of what source address you
>> > chose, but I am interested to receive an answer, of course. (application
>> > does not use bind() system call, only a send())
>>
>> why an application that wants to send a packet to google would send it
>> with a different source ip of the host in which it resides?
>> ie. an application is on a machine which ip is: 192.168.0.2 and the
>> machine has only one ip address...
>>
>
> I dont understand the question or the problem.
>
> If you look closer, you can see your machine has at least two addresses.
ok, let's try in this way.
the code is this:
[CODE]
if (hooknumber == NF_INET_LOCAL_IN) fl.nl_u.ip4_u.saddr = niph->saddr;
//niph is the pointer to ip header of the packet to send
if (hooknumber == NF_INET_FORWARD) fl.nl_u.ip4_u.saddr = 0;
[/CODE]
so, i don't understand why saddr = 0 when the hooknumber is NF_INET_FORWARD....
this is the real problem.
--
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv2 NEXT 2/5] qlcnic: vlan gro support
From: David Miller @ 2010-09-17 18:24 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1284700483-16397-3-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Thu, 16 Sep 2010 22:14:40 -0700
> @@ -796,7 +796,7 @@ qlcnic_set_netdev_features(struct qlcnic_adapter *adapter,
> features = (NETIF_F_SG | NETIF_F_IP_CSUM |
> NETIF_F_IPV6_CSUM | NETIF_F_GRO);
> vlan_features = (NETIF_F_SG | NETIF_F_IP_CSUM |
> - NETIF_F_IPV6_CSUM);
> + NETIF_F_IPV6_CSUM | NETIF_F_GRO);
>
> if (adapter->capabilities & QLCNIC_FW_CAPABILITY_TSO) {
> features |= (NETIF_F_TSO | NETIF_F_TSO6);
> @@ -1456,7 +1456,7 @@ qlcnic_setup_netdev(struct qlcnic_adapter *adapter,
> netdev->features |= (NETIF_F_SG | NETIF_F_IP_CSUM |
> NETIF_F_IPV6_CSUM | NETIF_F_GRO | NETIF_F_HW_VLAN_RX);
> netdev->vlan_features |= (NETIF_F_SG | NETIF_F_IP_CSUM |
> - NETIF_F_IPV6_CSUM);
> + NETIF_F_IPV6_CSUM | NETIF_F_GRO);
>
> if (adapter->capabilities & QLCNIC_FW_CAPABILITY_TSO) {
Drivers no longer should set NETIF_F_GRO in their vlan_features
flags, the generic networking core does this for you now in
register_netdevice() in net-next-2.6
Please respin this patch with these settings removed.
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