* Re: [PATCH net-next-2.6 00/17] netdev: Fix queue count initialisation
From: David Miller @ 2010-09-28 5:12 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 27 Sep 2010 19:23:11 +0100
> This adds the functions:
> - netif_set_real_num_rx_queues() - set actual number of RX queues used
> - netif_copy_real_num_queues() - copy queue counts from another device
>
> and changes all drivers that currently set
> net_device::real_num_tx_queues to use netif_set_real_num_tx_queues()
> and/or these functions.
>
> The changes are compile-tested only, except that:
> - sfc and 8021q have been briefly tested
> - gianfar and mv643xx_eth have not been compiled, since they are
> platform-specific
>
> I noticed that the bonding driver sets its numbers of queues without
> regard to its slave devices. This makes some sense since a bond device
> initially has no slave devices. However, it seems to mean that a bond
> device can pass up an skb with an out-of-range queue_index, triggering a
> warning in get_rps_cpu().
Series applied, thanks Ben.
^ permalink raw reply
* Re: [Bugme-new] [Bug 18952] New: The mount of SYN retries is not equal to /proc/sys/net/ipv4/tcp_syn_retries
From: David Miller @ 2010-09-28 4:52 UTC (permalink / raw)
To: damian; +Cc: yuri, akpm, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <1285617608.9983.30.camel@nexus>
From: Damian Lukowski <damian@tvk.rwth-aachen.de>
Date: Mon, 27 Sep 2010 22:00:08 +0200
> My suggestion for solving this issue:
> Introducing a third boolean parameter for retransmits_timed_out()
> indicating whether the socket is in SYN state or not. In the SYN case,
> TCP_TIMEOUT_INIT will be used for the calculation instead of
> TCP_RTO_MIN.
>
> Is that ok?
Sounds fine to me, please prepare a patch.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] net: sk_{detach|attach}_filter() rcu fixes
From: David Miller @ 2010-09-28 4:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, paulmck
In-Reply-To: <1285603650.3017.57.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 27 Sep 2010 18:07:30 +0200
> Le lundi 27 septembre 2010 à 17:57 +0200, Eric Dumazet a écrit :
>> sk_attach_filter() is run with socket locked.
>>
>> Use the appropriate rcu_dereference_protected() instead of blocking BH,
>> and rcu_dereference_bh().
>> There is no point adding BH prevention and memory barrier.
>
> Hmm, same thing can be done in sk_detach_filter, here is a v2.
>
> Thanks
>
> [PATCH net-next-2.6 v2] net: sk_{detach|attach}_filter() rcu fixes
>
> sk_attach_filter() and sk_detach_filter() are run with socket locked.
>
> Use the appropriate rcu_dereference_protected() instead of blocking BH,
> and rcu_dereference_bh().
> There is no point adding BH prevention and memory barrier.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] fib: use atomic_inc_not_zero() in fib_rules_lookup
From: David Miller @ 2010-09-28 4:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, paulmck
In-Reply-To: <1285597107.23938.250.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 27 Sep 2010 16:18:27 +0200
> It seems we dont use appropriate refcount increment in an
> rcu_read_lock() protected section.
>
> fib_rule_get() might increment a null refcount and bad things could
> happen.
>
> While fib_nl_delrule() respects an rcu grace period before calling
> fib_rule_put(), fib_rules_cleanup_ops() calls fib_rule_put() without a
> grace period.
>
> Note : after this patch, we might avoid the synchronize_rcu() call done
> in fib_nl_delrule()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/4] tunnels: SMP safe accounting
From: David Miller @ 2010-09-28 4:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1285583568.23938.81.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 27 Sep 2010 12:32:48 +0200
> Before making ip_gre, ipip, and sit transmit path lockless, it is
> necessary to make accounting SMP safe, not only for correctness but to
> avoid cache line ping pongs.
>
> This also takes care of receive path, already lockless and using unsafe
> stats accounting.
>
> I chose to use small percpu structures, holding {rx|tx}_{packets|bytes}
> only, and keep all other counters in netdev->stats, since they should be
> seldom used.
Series applied, thanks a lot Eric!
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: use this_cpu_ptr() in vlan_skb_recv()
From: David Miller @ 2010-09-28 4:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1285577229.10965.3.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 27 Sep 2010 10:47:09 +0200
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/2] Phonet: Implement Pipe Controller to support Nokia Slim Modems
From: David Miller @ 2010-09-28 4:50 UTC (permalink / raw)
To: kumar.sanghvi
Cc: remi.denis-courmont, netdev, STEricsson_nomadik_linux,
sudeep.divakaran, gulshan.karmani, linus.walleij
In-Reply-To: <1285564079-23066-1-git-send-email-kumar.sanghvi@stericsson.com>
From: Kumar A Sanghvi <kumar.sanghvi@stericsson.com>
Date: Mon, 27 Sep 2010 10:37:59 +0530
> From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
>
> Phonet stack assumes the presence of Pipe Controller, either in Modem or
> on Application Processing Engine user-space for the Pipe data.
> Nokia Slim Modems like WG2.5 used in ST-Ericsson U8500 platform do not
> implement Pipe controller in them.
> This patch adds Pipe Controller implemenation to Phonet stack to support
> Pipe data over Phonet stack for Nokia Slim Modems.
>
> Signed-off-by: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Applied, thanks.
Please resubmit patch 2/2 if you want me to apply it.
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/5] XFRM,IPv6: Removal of RH2/HAO from IPsec-protected MIPv6 traffic
From: David Miller @ 2010-09-28 4:25 UTC (permalink / raw)
To: arno; +Cc: eric.dumazet, herbert, yoshfuji, netdev
In-Reply-To: <87bp7nrlvy.fsf@small.ssi.corp>
Please resubmit this after you've done some more exhaustive
build testing:
---
net/ipv6/xfrm6_input.c: In function ‘xfrm6_input_addr_check’:
net/ipv6/xfrm6_input.c:173: error: implicit declaration of function ‘ipv6_chk_home_addr’
net/ipv6/xfrm6_input.c:179: error: ‘struct sec_path’ has no member named ‘irodst’
net/ipv6/xfrm6_input.c:202: error: ‘struct sec_path’ has no member named ‘irosrc’
---
davem@sunset:~/src/GIT/net-next-2.6$ egrep XFRM .config
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
davem@sunset:~/src/GIT/net-next-2.6$
^ permalink raw reply
* Re: [PATCH net-next-2.6 12/17] mv643xx_eth: Use netif_set_real_num_{rx,tx}_queues()
From: Lennert Buytenhek @ 2010-09-28 4:18 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <1285612205.2263.310.camel@achroite.uk.solarflarecom.com>
On Mon, Sep 27, 2010 at 07:30:05PM +0100, Ben Hutchings wrote:
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
^ permalink raw reply
* Re: [PATCH V3] fs: allow for more than 2^31 files
From: David Miller @ 2010-09-28 4:10 UTC (permalink / raw)
To: eric.dumazet
Cc: dipankar, holt, viro, bcrl, den, mingo, mszeredi, cmm, npiggin,
xemul, linux-kernel, netdev
In-Reply-To: <1285645611.10438.27.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 28 Sep 2010 05:46:51 +0200
> [PATCH V3] fs: allow for more than 2^31 files
...
> Reported-by: Robin Holt <holt@sgi.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [Bugme-new] [Bug 16603] New: send of data > 4 GB fails on 64 bit systems
From: David Miller @ 2010-09-28 4:07 UTC (permalink / raw)
To: akpm; +Cc: netdev, bugzilla-daemon, bugme-daemon, bono
In-Reply-To: <20100927205624.1564649e.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 27 Sep 2010 20:56:24 -0700
> A blanket suckyfix might be, at the syscall level:
>
> if (size > 4g) {
> do_it_in_4g_hunks();
> do_the_last_bit();
> }
>
> unless that would break some networking syscall->framesize guarantees
> or something?
There is not a single length passed in, but a vector of them, that's
what the iovec conveys.
Even if you could, socket send calls have atomicity guarentees. For a
datagram socket, for example, a single send call corresponds to one
packet on the network.
BTW, this aspect of datagram sockets is a part of the reason we don't
see many reports about this stuff. :-) Only stream protocols can
really take such enormous lengths, and the most popular (TCP) does
much of the iovec handling by hand.
We just need to fix our junk, and the {min,max}_t(size_t, ...) change
I suggested is likely the easiest path.
^ permalink raw reply
* Re: [Bugme-new] [Bug 16603] New: send of data > 4 GB fails on 64 bit systems
From: Andrew Morton @ 2010-09-28 3:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bugzilla-daemon, bugme-daemon, bono
In-Reply-To: <20100927.202425.71120040.davem@davemloft.net>
On Mon, 27 Sep 2010 20:24:25 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> Ok, I suspect the following is enough to fix this specific bug
> report, TCP sending.
>
> However, as I stated in my previous reply there are creepy
> crawlies all over the place.
>
> For example, all of the routines in net/core/iovec.c (memcpy_toiovec,
> memcpy_toiovecend, memcpy_fromiovec, memcpy_fromiovecend,
> csum_partial_copy_fromiovecend) that cast using min_t() are currently
> casting "down" to "unsigned int".
>
> They should probably case "up" to "size_t".
eep.
A blanket suckyfix might be, at the syscall level:
if (size > 4g) {
do_it_in_4g_hunks();
do_the_last_bit();
}
unless that would break some networking syscall->framesize guarantees
or something?
And such a "fix" would make it hard to test the real fix!
I'm surprised that this issue hasn't come up before.
^ permalink raw reply
* [PATCH V3] fs: allow for more than 2^31 files
From: Eric Dumazet @ 2010-09-28 3:46 UTC (permalink / raw)
To: David Miller
Cc: dipankar, holt, viro, bcrl, den, mingo, mszeredi, cmm, npiggin,
xemul, linux-kernel, netdev
In-Reply-To: <20100927.153639.212415479.davem@davemloft.net>
Le lundi 27 septembre 2010 à 15:36 -0700, David Miller a écrit :
> Is someone following up on integrating this upstream so this thing
> gets fixed?
>
Thanks for the heads-up.
I am not sure V2 of my patch was reviewed, maybe it did not reach the
list.
Here is V3 of it. I removed the ATOMIC_INIT(0) I left in V2.
It should be an ATOMIC_LONG_INIT(0), but then, it can be avoided.
CC netdev
Thanks
[PATCH V3] fs: allow for more than 2^31 files
Robin Holt tried to boot a 16TB system and found af_unix was overflowing
a 32bit value :
<quote>
We were seeing a failure which prevented boot. The kernel was incapable
of creating either a named pipe or unix domain socket. This comes down
to a common kernel function called unix_create1() which does:
atomic_inc(&unix_nr_socks);
if (atomic_read(&unix_nr_socks) > 2 * get_max_files())
goto out;
The function get_max_files() is a simple return of files_stat.max_files.
files_stat.max_files is a signed integer and is computed in
fs/file_table.c's files_init().
n = (mempages * (PAGE_SIZE / 1024)) / 10;
files_stat.max_files = n;
In our case, mempages (total_ram_pages) is approx 3,758,096,384
(0xe0000000). That leaves max_files at approximately 1,503,238,553.
This causes 2 * get_max_files() to integer overflow.
</quote>
Fix is to let /proc/sys/fs/file-nr & /proc/sys/fs/file-max use long
integers, and change af_unix to use an atomic_long_t instead of
atomic_t.
get_max_files() is changed to return an unsigned long.
get_nr_files() is changed to return a long.
unix_nr_socks is changed from atomic_t to atomic_long_t, while not
strictly needed to address Robin problem.
Before patch (on a 64bit kernel) :
# echo 2147483648 >/proc/sys/fs/file-max
# cat /proc/sys/fs/file-max
-18446744071562067968
After patch:
# echo 2147483648 >/proc/sys/fs/file-max
# cat /proc/sys/fs/file-max
2147483648
Reported-by: Robin Holt <holt@sgi.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
fs/file_table.c | 15 ++++++---------
include/linux/fs.h | 8 ++++----
kernel/sysctl.c | 8 ++++----
net/unix/af_unix.c | 14 +++++++-------
4 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/fs/file_table.c b/fs/file_table.c
index a04bdd8..46457ba 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -60,7 +60,7 @@ static inline void file_free(struct file *f)
/*
* Return the total number of open files in the system
*/
-static int get_nr_files(void)
+static long get_nr_files(void)
{
return percpu_counter_read_positive(&nr_files);
}
@@ -68,7 +68,7 @@ static int get_nr_files(void)
/*
* Return the maximum number of open files in the system
*/
-int get_max_files(void)
+unsigned long get_max_files(void)
{
return files_stat.max_files;
}
@@ -105,7 +105,7 @@ int proc_nr_files(ctl_table *table, int write,
struct file *get_empty_filp(void)
{
const struct cred *cred = current_cred();
- static int old_max;
+ static long old_max;
struct file * f;
/*
@@ -140,8 +140,7 @@ struct file *get_empty_filp(void)
over:
/* Ran out of filps - report that */
if (get_nr_files() > old_max) {
- printk(KERN_INFO "VFS: file-max limit %d reached\n",
- get_max_files());
+ pr_info("VFS: file-max limit %lu reached\n", get_max_files());
old_max = get_nr_files();
}
goto fail;
@@ -487,7 +486,7 @@ retry:
void __init files_init(unsigned long mempages)
{
- int n;
+ unsigned long n;
filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
@@ -498,9 +497,7 @@ void __init files_init(unsigned long mempages)
*/
n = (mempages * (PAGE_SIZE / 1024)) / 10;
- files_stat.max_files = n;
- if (files_stat.max_files < NR_FILE)
- files_stat.max_files = NR_FILE;
+ files_stat.max_files = max_t(unsigned long, n, NR_FILE);
files_defer_init();
lg_lock_init(files_lglock);
percpu_counter_init(&nr_files, 0);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 63d069b..8c06590 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -34,9 +34,9 @@
/* And dynamically-tunable limits and defaults: */
struct files_stat_struct {
- int nr_files; /* read only */
- int nr_free_files; /* read only */
- int max_files; /* tunable */
+ unsigned long nr_files; /* read only */
+ unsigned long nr_free_files; /* read only */
+ unsigned long max_files; /* tunable */
};
struct inodes_stat_t {
@@ -404,7 +404,7 @@ extern void __init inode_init_early(void);
extern void __init files_init(unsigned long);
extern struct files_stat_struct files_stat;
-extern int get_max_files(void);
+extern unsigned long get_max_files(void);
extern int sysctl_nr_open;
extern struct inodes_stat_t inodes_stat;
extern int leases_enable, lease_break_time;
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index f88552c..fc667bf 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1352,16 +1352,16 @@ static struct ctl_table fs_table[] = {
{
.procname = "file-nr",
.data = &files_stat,
- .maxlen = 3*sizeof(int),
+ .maxlen = sizeof(files_stat),
.mode = 0444,
- .proc_handler = proc_nr_files,
+ .proc_handler = proc_doulongvec_minmax,
},
{
.procname = "file-max",
.data = &files_stat.max_files,
- .maxlen = sizeof(int),
+ .maxlen = sizeof(files_stat.max_files),
.mode = 0644,
- .proc_handler = proc_dointvec,
+ .proc_handler = proc_doulongvec_minmax,
},
{
.procname = "nr_open",
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 0b39b24..3e1d7d1 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -117,7 +117,7 @@
static struct hlist_head unix_socket_table[UNIX_HASH_SIZE + 1];
static DEFINE_SPINLOCK(unix_table_lock);
-static atomic_t unix_nr_socks = ATOMIC_INIT(0);
+static atomic_long_t unix_nr_socks;
#define unix_sockets_unbound (&unix_socket_table[UNIX_HASH_SIZE])
@@ -360,13 +360,13 @@ static void unix_sock_destructor(struct sock *sk)
if (u->addr)
unix_release_addr(u->addr);
- atomic_dec(&unix_nr_socks);
+ atomic_long_dec(&unix_nr_socks);
local_bh_disable();
sock_prot_inuse_add(sock_net(sk), sk->sk_prot, -1);
local_bh_enable();
#ifdef UNIX_REFCNT_DEBUG
- printk(KERN_DEBUG "UNIX %p is destroyed, %d are still alive.\n", sk,
- atomic_read(&unix_nr_socks));
+ printk(KERN_DEBUG "UNIX %p is destroyed, %ld are still alive.\n", sk,
+ atomic_long_read(&unix_nr_socks));
#endif
}
@@ -606,8 +606,8 @@ static struct sock *unix_create1(struct net *net, struct socket *sock)
struct sock *sk = NULL;
struct unix_sock *u;
- atomic_inc(&unix_nr_socks);
- if (atomic_read(&unix_nr_socks) > 2 * get_max_files())
+ atomic_long_inc(&unix_nr_socks);
+ if (atomic_long_read(&unix_nr_socks) > 2 * get_max_files())
goto out;
sk = sk_alloc(net, PF_UNIX, GFP_KERNEL, &unix_proto);
@@ -632,7 +632,7 @@ static struct sock *unix_create1(struct net *net, struct socket *sock)
unix_insert_socket(unix_sockets_unbound, sk);
out:
if (sk == NULL)
- atomic_dec(&unix_nr_socks);
+ atomic_long_dec(&unix_nr_socks);
else {
local_bh_disable();
sock_prot_inuse_add(sock_net(sk), sk->sk_prot, 1);
^ permalink raw reply related
* Re: [Bugme-new] [Bug 16603] New: send of data > 4 GB fails on 64 bit systems
From: David Miller @ 2010-09-28 3:24 UTC (permalink / raw)
To: akpm; +Cc: netdev, bugzilla-daemon, bugme-daemon, bono
In-Reply-To: <20100927161540.776f748e.akpm@linux-foundation.org>
Ok, I suspect the following is enough to fix this specific bug
report, TCP sending.
However, as I stated in my previous reply there are creepy
crawlies all over the place.
For example, all of the routines in net/core/iovec.c (memcpy_toiovec,
memcpy_toiovecend, memcpy_fromiovec, memcpy_fromiovecend,
csum_partial_copy_fromiovecend) that cast using min_t() are currently
casting "down" to "unsigned int".
They should probably case "up" to "size_t".
Otherwise 4GB iov_len's on 64-bit will be truncated to zero just
as they do in the TCP path being fixed here.
If, alterntatively, we want to try and take the size_t values all
the way down the code paths to the individual copies, that is
a huge undertaking.
It's huge because we end up getting to the architecture specific
csum_copy_*() routines, which all take 'int' as the length and
many are written in assembler and would need audits and potentially
changes before we can make the type 'long' or 'size_t'.
Anyways, this part here is simple enough and I'll push it to
Linus and -stable.
--------------------
tcp: Fix >4GB writes on 64-bit.
Fixes kernel bugzilla #16603
tcp_sendmsg() truncates iov_len to an 'int' which a 4GB write to write
zero bytes, for example.
There is also the problem higher up of how verify_iovec() works. It
wants to prevent the total length from looking like an error return
value.
However it does this using 'int', but syscalls return 'long' (and
thus signed 64-bit on 64-bit machines). So it could trigger
false-positives on 64-bit as written. So fix it to use 'long'.
Reported-by: Olaf Bonorden <bono@onlinehome.de>
Reported-by: Daniel Büse <dbuese@gmx.de>
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/include/linux/socket.h b/include/linux/socket.h
index a2fada9..a8f56e1 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -322,7 +322,7 @@ extern int csum_partial_copy_fromiovecend(unsigned char *kdata,
int offset,
unsigned int len, __wsum *csump);
-extern int verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode);
+extern long verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode);
extern int memcpy_toiovec(struct iovec *v, unsigned char *kdata, int len);
extern int memcpy_toiovecend(const struct iovec *v, unsigned char *kdata,
int offset, int len);
diff --git a/net/core/iovec.c b/net/core/iovec.c
index 1cd98df..e6b133b 100644
--- a/net/core/iovec.c
+++ b/net/core/iovec.c
@@ -35,9 +35,10 @@
* in any case.
*/
-int verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode)
+long verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode)
{
- int size, err, ct;
+ int size, ct;
+ long err;
if (m->msg_namelen) {
if (mode == VERIFY_READ) {
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 95d75d4..f115ea6 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -943,7 +943,7 @@ int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
sg = sk->sk_route_caps & NETIF_F_SG;
while (--iovlen >= 0) {
- int seglen = iov->iov_len;
+ size_t seglen = iov->iov_len;
unsigned char __user *from = iov->iov_base;
iov++;
^ permalink raw reply related
* Re: bonding vs GSO vs checksumming.
From: Herbert Xu @ 2010-09-28 3:21 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: Linux NetDev
In-Reply-To: <20100928024907.GA24948@gondor.apana.org.au>
On Tue, Sep 28, 2010 at 11:49:07AM +0900, Herbert Xu wrote:
> On Thu, Sep 23, 2010 at 05:56:43PM -0700, Maciej Żenczykowski wrote:
> > I'm seeing the following:
> >
> > bonding: caps=(0x1113a3, 0x1113ab) len=18192 data_len=18120 ip_summed=0
> >
> > on a 2.6.34.5 based kernel originating from v6 tcp transmit (mtu 1280)
> > on a bonded device of tg3 (presumably with TSO6) and forcedeth
> > (presumably without TSO6).
> >
> > I can't quite figure out what this truly means...
>
> Did it come with a kernel backtrace?
Actually your particular problem should be fixed by
commit 6afff0caa721211e8c04bdc7627ee3bff95bcb95
Author: John Fastabend <john.r.fastabend@intel.com>
Date: Wed Jun 16 14:18:12 2010 +0000
net: consolidate netif_needs_gso() checks
which went in after 2.6.34.
However, the fact that your feature bits show that bonding is
declaring TSO6 support without IPv6 checksum support also means
that the bonding feature computation is broken.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: pull-request: bluetooth-2.6 2010-09-27
From: David Miller @ 2010-09-28 3:00 UTC (permalink / raw)
To: padovan-Y3ZbgMPKUGA34EUeqzHoZw
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ, marcel-kz+m5ild9QBg9hUCZPvPmw,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100928023035.GA3033@vigoh>
From: "Gustavo F. Padovan" <padovan-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org>
Date: Mon, 27 Sep 2010 23:30:35 -0300
> And a fix for a deadlock issue between the sk_sndbuf and the backlog
> queue in ERTM. The rest are also needed bug fixes.
This fix is still under discussion.
That change effects quite a few code paths. And when I looked
at them, I was not at all convinced that dropping the socket
lock like that is safe.
Are you sure there are no pieces of socket or socket related state
that might change under us while we drop that lock, which would thus
make the operation suddenly invalid or cause a state corruption or
crash?
You really need to audit this.
^ permalink raw reply
* Re: bonding vs GSO vs checksumming.
From: Herbert Xu @ 2010-09-28 2:49 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: Linux NetDev
In-Reply-To: <AANLkTim2FF2n9JXfpdZmmnV5ZJ1ptC7se_JiU_z91okt@mail.gmail.com>
On Thu, Sep 23, 2010 at 05:56:43PM -0700, Maciej Żenczykowski wrote:
> I'm seeing the following:
>
> bonding: caps=(0x1113a3, 0x1113ab) len=18192 data_len=18120 ip_summed=0
>
> on a 2.6.34.5 based kernel originating from v6 tcp transmit (mtu 1280)
> on a bonded device of tg3 (presumably with TSO6) and forcedeth
> (presumably without TSO6).
>
> I can't quite figure out what this truly means...
Did it come with a kernel backtrace?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bugme-new] [Bug 16603] New: send of data > 4 GB fails on 64 bit systems
From: David Miller @ 2010-09-28 2:41 UTC (permalink / raw)
To: akpm; +Cc: netdev, bugzilla-daemon, bugme-daemon, bono
In-Reply-To: <20100927161540.776f748e.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 27 Sep 2010 16:15:40 -0700
> Yes, I think seglen should be size_t. Do you know if making that
> change fixes the bug?
Oh boy, what a rats nest.
Just scanning generically I see that net/core/iovec.c:verify_iovec()
has similar issues, it should probably use "long" instead of "int"
because it's trying to prevent the return value being interpreted
as an error code.
So if you fix that and make it return "long" this leads to another
set of problems, even if you fix that TCP bit sys_sendmsg() holds
the total length in an 'int' too. So more stuff to fix.
I'll try to do the whole audit, but no promises ;)
^ permalink raw reply
* pull-request: bluetooth-2.6 2010-09-27
From: Gustavo F. Padovan @ 2010-09-28 2:30 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ, marcel-kz+m5ild9QBg9hUCZPvPmw,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Hi David,
These are the Bluetooth fixes for 2.6.36, you are used to see Marcel doing this
job, but he has been busy lately so I'm taking the job of the pull request this
time. Since we are a bit late on the pull request I'm skipping the
wireless-2.6 step, tell me if you (including John here) disagree.
In this patch set we have two fixes for regressions in L2CAP due to ERTM code
we added in L2CAP for 2.6.36, a bugfix in the L2CAP Streaming Mode that was
making the kernel crash. And a fix for a deadlock issue between the sk_sndbuf
and the backlog queue in ERTM. The rest are also needed bug fixes.
Please tell me any problem you have pulling this.
PS: Considering that these patches do not go immediately to net-next how do I
run the Bluetooth pull request to net-next? Currently my -next tree is rebased
on net-next but before the bluetooth-next patches I put the bluetooth patches
I have in my bluetooth-2.6 tree, i.e., when making the pull request I have to be
sure that the -next patches will be on top of the patches I'm submitting now
for 2.6.36. Any help on that is welcome. :)
Regards,
---
The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c:
Linux 2.6.36-rc5 (2010-09-20 16:56:53 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git master
Andrei Emeltchenko (1):
Bluetooth: fix MTU L2CAP configuration parameter
Gustavo F. Padovan (4):
Bluetooth: Simplify L2CAP Streaming mode sending
Bluetooth: Fix inconsistent lock state with RFCOMM
Revert "Bluetooth: Don't accept ConfigReq if we aren't in the BT_CONFIG state"
Bluetooth: Fix deadlock in the ERTM logic
Mat Martineau (1):
Bluetooth: Only enable L2CAP FCS for ERTM or streaming
include/net/bluetooth/bluetooth.h | 11 +++++++
net/bluetooth/l2cap.c | 57 +++++++++++++++---------------------
net/bluetooth/rfcomm/sock.c | 4 ++
3 files changed, 39 insertions(+), 33 deletions(-)
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* RE: [PATCH v11 00/17] Provide a zero-copy method on KVM virtio-net.
From: Xin, Xiaohui @ 2010-09-28 1:25 UTC (permalink / raw)
To: Xin, Xiaohui, Michael S. Tsirkin
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, davem@davemloft.net,
herbert@gondor.hengli.com.au, jdike@linux.intel.com
In-Reply-To: <F2E9EB7348B8264F86B6AB8151CE2D792EC64F74FA@shsmsx502.ccr.corp.intel.com>
>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On
>Behalf Of Xin, Xiaohui
>Sent: Monday, September 27, 2010 8:45 AM
>To: Michael S. Tsirkin
>Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>jdike@linux.intel.com
>Subject: RE: [PATCH v11 00/17] Provide a zero-copy method on KVM virtio-net.
>
>>From: Michael S. Tsirkin [mailto:mst@redhat.com]
>>Sent: Monday, September 27, 2010 1:02 AM
>>To: Xin, Xiaohui
>>Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>>mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>>jdike@linux.intel.com
>>Subject: Re: [PATCH v11 00/17] Provide a zero-copy method on KVM virtio-net.
>>
>>On Sat, Sep 25, 2010 at 12:27:18PM +0800, xiaohui.xin@intel.com wrote:
>>> We provide an zero-copy method which driver side may get external
>>> buffers to DMA. Here external means driver don't use kernel space
>>> to allocate skb buffers. Currently the external buffer can be from
>>> guest virtio-net driver.
>>>
>>> The idea is simple, just to pin the guest VM user space and then
>>> let host NIC driver has the chance to directly DMA to it.
>>> The patches are based on vhost-net backend driver. We add a device
>>> which provides proto_ops as sendmsg/recvmsg to vhost-net to
>>> send/recv directly to/from the NIC driver. KVM guest who use the
>>> vhost-net backend may bind any ethX interface in the host side to
>>> get copyless data transfer thru guest virtio-net frontend.
>>> patch 01-10: net core and kernel changes.
>>> patch 11-13: new device as interface to mantpulate external buffers.
>>> patch 14: for vhost-net.
>>> patch 15: An example on modifying NIC driver to using napi_gro_frags().
>>> patch 16: An example how to get guest buffers based on driver
>>> who using napi_gro_frags().
>>> patch 17: It's a patch to address comments from Michael S. Thirkin
>>> to add 2 new ioctls in mp device.
>>> We split it out here to make easier reiewer.
>>
>>
>>
>>I commented on how to avoid mm semaphore on data path separately, and
>>since you didn't have time to review that yet, I won't repeat that here.
>>
>
>I think I did avoid that in data path to use mm semaphore. I stored the value
>in mp structures and check with that.
>
Hi Michael,
Did you think I have addressed your comments about to avoid mm semaphore on
data path or not? I stored the value in mp structures and don't use mmap_semphore.
Or you still have some concerns with it?
>>At this point what are the plans on macvtap integration?
>>You indicated this is the interface you intend to use longterm.
>
>I'm now working on that.
>
I'm now trying to export some functions from mp device, and let macvtap to use them
for rx zero-copy.
>
>Thanks
>Xiaohui
>--
>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: IGMP v3 reponse
From: David Stevens @ 2010-09-28 0:41 UTC (permalink / raw)
To: Bob Arendt
Cc: Christoph Lameter, Jason Gunthorpe,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <4CA12DF3.6050608-x0S3BwdUo6DQT0dZR+AlfA@public.gmane.org>
Bob Arendt <rda-x0S3BwdUo6DQT0dZR+AlfA@public.gmane.org> wrote on 09/27/2010 04:51:15 PM:
> Per rfc 2236, the v2 client *can't* drop the IGMPv3 query. From para
2.5:
> 2.5. Other fields
> Note that IGMP messages may be longer than 8 octets, especially
> future backwards-compatible versions of IGMP. As long as the Type
is
> one that is recognized, an IGMPv2 implementation MUST ignore
anything
> past the first 8 octets while processing the packet. However, the
> IGMP checksum is always computed over the whole IP payload, not just
> over the first 8 octets.
>
> The IGMPv3 query *is* a valid v2 query with extra crap at the end (it's
> backward compatible). Per rfc 2236 p2.5, the v3 query has to be
regarded
> as a valid v2 query if you're correctly implementing IGMPv2. Some
switch
> vendors (Cisco for one) only generate v3 queries when operating as an
> IGMP snooping switch, since a proper v2 client will respond with IGMPv2
> packets and it handles this properly. However, we're seeing some
switches
> get confused when a client initial joins with v2, then responds to a
query
> with v3. It ends up creating 2 entries, and only one is cleared by the
> leave message. This is also an issue when the primary (querier) switch
> only generates v3 queries, and some intermediate switches only support
v2.
> We set all the Linux clients to v2 .. but they respond the v2 query with
> v3 protocols, which could be missed by the intermediate switch.
>
> I believe the intent of the bug 18212 patch is correct.
Bob,
That would've been a nice quote for the other discussion; I didn't
do the v2 implementation for Linux, but it appears I broke this. I'll
take another look (and thanks for pointing that out!).
+-DLS
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: IGMP v3 reponse
From: Bob Arendt @ 2010-09-27 23:51 UTC (permalink / raw)
To: David Stevens
Cc: Christoph Lameter, Jason Gunthorpe, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, netdev-owner@vger.kernel.org
In-Reply-To: <OF9D99FA29.B3F53176-ON882577AB.00780023-882577AB.0078FAAE@us.ibm.com>
On 09/27/10 15:01, David Stevens wrote:
> Bob Arendt<rda@rincon.com> wrote on 09/27/2010 01:54:36 PM:
>> And it turns out that force_igmp_version=2 doesn't fully work.
>> If the host sees a IGMPv3 query, it still responds with a v3 Join
>> despite the flag. Bug report and candidate patch here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=18212
>
> This is a special case. The "correct" alternative is to drop
> the query and not send any report at all. Sending an answer in the
> originating protocol doesn't hurt anything here, because MC routers
> are required to use the earlier version too; there should be no such
> thing as an "IGMPv3-only querier" as in that report. IGMPv3 compliance
> *requires* falling back to IGMPv2 if there is a v2 query by another
> router.
> By answering instead of dropping, it allows fuller filter
> information from a manual query to be returned even if the network
> is using v2 MC routers, but dropping and ignoring the query as
> required by RFC does not fix the bug& patch submitter's problem.
> Which is why I also NACKed that patch.
>
> +-DLS
>
>
Per rfc 2236, the v2 client *can't* drop the IGMPv3 query. From para 2.5:
2.5. Other fields
Note that IGMP messages may be longer than 8 octets, especially
future backwards-compatible versions of IGMP. As long as the Type is
one that is recognized, an IGMPv2 implementation MUST ignore anything
past the first 8 octets while processing the packet. However, the
IGMP checksum is always computed over the whole IP payload, not just
over the first 8 octets.
The IGMPv3 query *is* a valid v2 query with extra crap at the end (it's
backward compatible). Per rfc 2236 p2.5, the v3 query has to be regarded
as a valid v2 query if you're correctly implementing IGMPv2. Some switch
vendors (Cisco for one) only generate v3 queries when operating as an
IGMP snooping switch, since a proper v2 client will respond with IGMPv2
packets and it handles this properly. However, we're seeing some switches
get confused when a client initial joins with v2, then responds to a query
with v3. It ends up creating 2 entries, and only one is cleared by the
leave message. This is also an issue when the primary (querier) switch
only generates v3 queries, and some intermediate switches only support v2.
We set all the Linux clients to v2 .. but they respond the v2 query with
v3 protocols, which could be missed by the intermediate switch.
I believe the intent of the bug 18212 patch is correct.
-Bob Arendt
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Herbert Xu @ 2010-09-27 23:28 UTC (permalink / raw)
To: Willy Tarreau; +Cc: davem, netdev
In-Reply-To: <20100927192112.GT12373@1wt.eu>
Willy Tarreau <w@1wt.eu> wrote:
>
> Two quick facts :
> - HTTP allows the client to send whatever it wants whenever it wants
> and allows the server to close after whatever response it wants.
> Thus the server cannot predict that the client will talk.
No it does not. Only buggy HTTP clients do that. Also, have
you ever observed any buggy HTTP client that sends more than
one CRLF? If not then you only have to deal with the case of
a single extra CRLF.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bugme-new] [Bug 16603] New: send of data > 4 GB fails on 64 bit systems
From: Andrew Morton @ 2010-09-27 23:15 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, bono
In-Reply-To: <bug-16603-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 16 Aug 2010 10:01:09 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16603
>
> Summary: send of data > 4 GB fails on 64 bit systems
> Product: Networking
> Version: 2.5
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: bono@onlinehome.de
> Regression: No
>
>
> Sending of data using linux function send fails if size is too large. glibc
> function is:
>
> ssize_t send(int sockfd, const void *buf, size_t len, int flags);
>
> Type of len is size_t, argument is stored in a kernel structure msgheader which
> contains an iovec. This iovec contains a size_t (64bit) length field, but in
> the linux kernel in function tcp_sendmsg the following lines
>
> while (--iovlen >= 0) {
> int seglen = iov->iov_len;
> unsigned char __user *from = iov->iov_base;
>
>
> convert the len to int (32 bit).
>
> Thus sending of 5 GB of data results in 1 GB sent (no problem), but sending of
> 4 GB results in 0 bytes sent.
>
> Workaround in userspace is easy (e.g. instead of len use len < 0x8000000 ? len
> : 0x7fffffff) but the kernel should handle this correctly.
>
whoops.
Yes, I think seglen should be size_t. Do you know if making that
change fixes the bug?
^ permalink raw reply
* Re: [PATCH] net/9p: Mount only matching virtio channels
From: David Miller @ 2010-09-27 22:54 UTC (permalink / raw)
To: sven.eckelmann; +Cc: ericvh, netdev, linux-kernel
In-Reply-To: <1285514893-11233-1-git-send-email-sven.eckelmann@gmx.de>
From: Sven Eckelmann <sven.eckelmann@gmx.de>
Date: Sun, 26 Sep 2010 17:28:13 +0200
> p9_virtio_create will only compare the the channel's tag characters
> against the device name till the end of the channel's tag but not till
> the end of the device name. This means that if a user defines channels
> with the tags foo and foobar then he would mount foo when he requested
> foonot and may mount foo when he requested foobar.
>
> Thus it is necessary to check both string lengths against each other in
> case of a successful partial string match.
>
> Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
I'll apply this, but this code would be so much simpler and this bug
would have never happened if these tags were NULL terminated when they
were pulled in from virtio.
^ 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