Netdev List
 help / color / mirror / Atom feed
* Re: >Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Eric Dumazet @ 2011-10-30 17:41 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andi Kleen, Ben Hutchings, linux-kernel, netdev, Andrew Morton
In-Reply-To: <CA+55aFyGEhBMv31QXN7q9PJc36TVtHLOvdFYB1+6NTo+nKSkbQ@mail.gmail.com>

Le dimanche 30 octobre 2011 à 10:07 -0700, Linus Torvalds a écrit :
> On Sun, Oct 30, 2011 at 8:16 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > Because it doesnt work if x is const.
> 
> Just remove the const. Problem solved.
> 
> Both cases of 'const' are totally arbitrary and useless. The
> test_bit() one is literally a cast to const (admittedly also *from*
> const, but nobody cares), and the atomic_read() one is just because it
> uses a silly inline function where a macro would be simpler.
> 

Oh well, I am lost. I always considered inline functione better because
of prototype checks.


Changing atomic_read(const atomic_t *v) prototype to
atomic_read(atomic_t *v) is not an option.


To save your time and my time, please select your favorite between :

1) The patch I did

2) 
 static inline int atomic_read(const atomic_t *v)
 {
	return ACCESS_AT_MOST_ONCE(((atomic_t *)v)->counter);
 }

3) 
 static inline int atomic_read(const atomic_t *v)
 {
	return ACCESS_AT_MOST_ONCE(*(int *)&(v)->counter);
 }

4) macro (I personnaly dont like it)
#define atomic_read(v) ACCESS_AT_MOST_ONCE(*(int *)&(v)->counter)

Thanks

^ permalink raw reply

* Re: >Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Linus Torvalds @ 2011-10-30 17:07 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Andi Kleen, Ben Hutchings, linux-kernel, netdev, Andrew Morton
In-Reply-To: <1319987765.13597.60.camel@edumazet-laptop>

On Sun, Oct 30, 2011 at 8:16 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Because it doesnt work if x is const.

Just remove the const. Problem solved.

Both cases of 'const' are totally arbitrary and useless. The
test_bit() one is literally a cast to const (admittedly also *from*
const, but nobody cares), and the atomic_read() one is just because it
uses a silly inline function where a macro would be simpler.

                              Linus

^ permalink raw reply

* [PATCH] net: make the tcp and udp file_operations for the /proc stuff const
From: Arjan van de Ven @ 2011-10-30 16:46 UTC (permalink / raw)
  To: netdev, davem

Hi.

as most of you probably already know, there's a strong desire to make struct file_operations
(and similar structures) const throughout the kernel. I'm sure something like this patch
has been posted here before, so I realize I'm threading in a tricky part ;-)

I'll try anyway with the patch below at least to get feedback on how to do this thing better
if nothing else...



>From 85d9ba34b3a6ad60a2b5ac3421eebdb5bbf81f7d Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjan@linux.intel.com>
Date: Sun, 30 Oct 2011 09:25:32 -0700
Subject: [PATCH] net: make the tcp and udp file_operations for the /proc stuff const

the tcp and udp code creates a set of struct file_operations at runtime
while it can also be done at compile time, with the added benefit of then
having these file operations be const.

the trickiest part was to get the "THIS_MODULE" reference right; the naive
method of declaring a struct in the place of registration would not work
for this reason.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
 include/net/tcp.h   |   10 ++++++----
 include/net/udp.h   |   12 +++++++-----
 net/ipv4/tcp_ipv4.c |   22 ++++++++++++----------
 net/ipv4/udp.c      |   22 ++++++++++++----------
 net/ipv4/udplite.c  |   13 ++++++++++---
 net/ipv6/tcp_ipv6.c |   12 +++++++++---
 net/ipv6/udp.c      |   12 +++++++++---
 net/ipv6/udplite.c  |   13 ++++++++++---
 8 files changed, 75 insertions(+), 41 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index acc620a..b9cdfe3 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1398,11 +1398,13 @@ enum tcp_seq_states {
 	TCP_SEQ_STATE_TIME_WAIT,
 };
 
+int tcp_seq_open(struct inode *inode, struct file *file);
+
 struct tcp_seq_afinfo {
-	char			*name;
-	sa_family_t		family;
-	struct file_operations	seq_fops;
-	struct seq_operations	seq_ops;
+	char				*name;
+	sa_family_t			family;
+	const struct file_operations	*seq_fops;
+	struct seq_operations		seq_ops;
 };
 
 struct tcp_iter_state {
diff --git a/include/net/udp.h b/include/net/udp.h
index 67ea6fc..3b285f4 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -230,12 +230,14 @@ extern struct sock *udp6_lib_lookup(struct net *net, const struct in6_addr *sadd
 #endif
 
 /* /proc */
+int udp_seq_open(struct inode *inode, struct file *file);
+
 struct udp_seq_afinfo {
-	char			*name;
-	sa_family_t		family;
-	struct udp_table	*udp_table;
-	struct file_operations	seq_fops;
-	struct seq_operations	seq_ops;
+	char				*name;
+	sa_family_t			family;
+	struct udp_table		*udp_table;
+	const struct file_operations	*seq_fops;
+	struct seq_operations		seq_ops;
 };
 
 struct udp_iter_state {
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 7963e03..d43dc07 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2336,7 +2336,7 @@ static void tcp_seq_stop(struct seq_file *seq, void *v)
 	}
 }
 
-static int tcp_seq_open(struct inode *inode, struct file *file)
+int tcp_seq_open(struct inode *inode, struct file *file)
 {
 	struct tcp_seq_afinfo *afinfo = PDE(inode)->data;
 	struct tcp_iter_state *s;
@@ -2352,23 +2352,19 @@ static int tcp_seq_open(struct inode *inode, struct file *file)
 	s->last_pos 		= 0;
 	return 0;
 }
+EXPORT_SYMBOL(tcp_seq_open);
 
 int tcp_proc_register(struct net *net, struct tcp_seq_afinfo *afinfo)
 {
 	int rc = 0;
 	struct proc_dir_entry *p;
 
-	afinfo->seq_fops.open		= tcp_seq_open;
-	afinfo->seq_fops.read		= seq_read;
-	afinfo->seq_fops.llseek		= seq_lseek;
-	afinfo->seq_fops.release	= seq_release_net;
-
 	afinfo->seq_ops.start		= tcp_seq_start;
 	afinfo->seq_ops.next		= tcp_seq_next;
 	afinfo->seq_ops.stop		= tcp_seq_stop;
 
 	p = proc_create_data(afinfo->name, S_IRUGO, net->proc_net,
-			     &afinfo->seq_fops, afinfo);
+			     afinfo->seq_fops, afinfo);
 	if (!p)
 		rc = -ENOMEM;
 	return rc;
@@ -2517,12 +2513,18 @@ out:
 	return 0;
 }
 
+static const struct file_operations tcp_afinfo_seq_fops = {
+	.owner   = THIS_MODULE,
+	.open    = tcp_seq_open,
+	.read    = seq_read,
+	.llseek  = seq_lseek,
+	.release = seq_release_net
+};
+
 static struct tcp_seq_afinfo tcp4_seq_afinfo = {
 	.name		= "tcp",
 	.family		= AF_INET,
-	.seq_fops	= {
-		.owner		= THIS_MODULE,
-	},
+	.seq_fops	= &tcp_afinfo_seq_fops,
 	.seq_ops	= {
 		.show		= tcp4_seq_show,
 	},
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 1b5a193..25b869a 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2038,7 +2038,7 @@ static void udp_seq_stop(struct seq_file *seq, void *v)
 		spin_unlock_bh(&state->udp_table->hash[state->bucket].lock);
 }
 
-static int udp_seq_open(struct inode *inode, struct file *file)
+int udp_seq_open(struct inode *inode, struct file *file)
 {
 	struct udp_seq_afinfo *afinfo = PDE(inode)->data;
 	struct udp_iter_state *s;
@@ -2054,6 +2054,7 @@ static int udp_seq_open(struct inode *inode, struct file *file)
 	s->udp_table		= afinfo->udp_table;
 	return err;
 }
+EXPORT_SYMBOL(udp_seq_open);
 
 /* ------------------------------------------------------------------------ */
 int udp_proc_register(struct net *net, struct udp_seq_afinfo *afinfo)
@@ -2061,17 +2062,12 @@ int udp_proc_register(struct net *net, struct udp_seq_afinfo *afinfo)
 	struct proc_dir_entry *p;
 	int rc = 0;
 
-	afinfo->seq_fops.open		= udp_seq_open;
-	afinfo->seq_fops.read		= seq_read;
-	afinfo->seq_fops.llseek		= seq_lseek;
-	afinfo->seq_fops.release	= seq_release_net;
-
 	afinfo->seq_ops.start		= udp_seq_start;
 	afinfo->seq_ops.next		= udp_seq_next;
 	afinfo->seq_ops.stop		= udp_seq_stop;
 
 	p = proc_create_data(afinfo->name, S_IRUGO, net->proc_net,
-			     &afinfo->seq_fops, afinfo);
+			     afinfo->seq_fops, afinfo);
 	if (!p)
 		rc = -ENOMEM;
 	return rc;
@@ -2121,14 +2117,20 @@ int udp4_seq_show(struct seq_file *seq, void *v)
 	return 0;
 }
 
+static const struct file_operations udp_afinfo_seq_fops = {
+	.owner    = THIS_MODULE,
+	.open     = udp_seq_open,
+	.read     = seq_read,
+	.llseek   = seq_lseek,
+	.release  = seq_release_net
+};
+
 /* ------------------------------------------------------------------------ */
 static struct udp_seq_afinfo udp4_seq_afinfo = {
 	.name		= "udp",
 	.family		= AF_INET,
 	.udp_table	= &udp_table,
-	.seq_fops	= {
-		.owner	=	THIS_MODULE,
-	},
+	.seq_fops	= &udp_afinfo_seq_fops,
 	.seq_ops	= {
 		.show		= udp4_seq_show,
 	},
diff --git a/net/ipv4/udplite.c b/net/ipv4/udplite.c
index aee9963..08383eb 100644
--- a/net/ipv4/udplite.c
+++ b/net/ipv4/udplite.c
@@ -71,13 +71,20 @@ static struct inet_protosw udplite4_protosw = {
 };
 
 #ifdef CONFIG_PROC_FS
+
+static const struct file_operations udplite_afinfo_seq_fops = {
+	.owner    = THIS_MODULE,
+	.open     = udp_seq_open,
+	.read     = seq_read,
+	.llseek   = seq_lseek,
+	.release  = seq_release_net
+};
+
 static struct udp_seq_afinfo udplite4_seq_afinfo = {
 	.name		= "udplite",
 	.family		= AF_INET,
 	.udp_table 	= &udplite_table,
-	.seq_fops	= {
-		.owner	=	THIS_MODULE,
-	},
+	.seq_fops	= &udplite_afinfo_seq_fops,
 	.seq_ops	= {
 		.show		= udp4_seq_show,
 	},
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 7b8fc57..d0fde8c 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -2158,12 +2158,18 @@ out:
 	return 0;
 }
 
+static const struct file_operations tcp6_afinfo_seq_fops = {
+	.owner   = THIS_MODULE,
+	.open    = tcp_seq_open,
+	.read    = seq_read,
+	.llseek  = seq_lseek,
+	.release = seq_release_net
+};
+
 static struct tcp_seq_afinfo tcp6_seq_afinfo = {
 	.name		= "tcp6",
 	.family		= AF_INET6,
-	.seq_fops	= {
-		.owner		= THIS_MODULE,
-	},
+	.seq_fops	= &tcp6_afinfo_seq_fops,
 	.seq_ops	= {
 		.show		= tcp6_seq_show,
 	},
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index bb95e8e..37f654d 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1424,13 +1424,19 @@ int udp6_seq_show(struct seq_file *seq, void *v)
 	return 0;
 }
 
+static const struct file_operations udp6_afinfo_seq_fops = {
+	.owner    = THIS_MODULE,
+	.open     = udp_seq_open,
+	.read     = seq_read,
+	.llseek   = seq_lseek,
+	.release  = seq_release_net
+};
+
 static struct udp_seq_afinfo udp6_seq_afinfo = {
 	.name		= "udp6",
 	.family		= AF_INET6,
 	.udp_table	= &udp_table,
-	.seq_fops	= {
-		.owner	=	THIS_MODULE,
-	},
+	.seq_fops	= &udp6_afinfo_seq_fops,
 	.seq_ops	= {
 		.show		= udp6_seq_show,
 	},
diff --git a/net/ipv6/udplite.c b/net/ipv6/udplite.c
index 986c4de..8889aa2 100644
--- a/net/ipv6/udplite.c
+++ b/net/ipv6/udplite.c
@@ -93,13 +93,20 @@ void udplitev6_exit(void)
 }
 
 #ifdef CONFIG_PROC_FS
+
+static const struct file_operations udplite6_afinfo_seq_fops = {
+	.owner    = THIS_MODULE,
+	.open     = udp_seq_open,
+	.read     = seq_read,
+	.llseek   = seq_lseek,
+	.release  = seq_release_net
+};
+
 static struct udp_seq_afinfo udplite6_seq_afinfo = {
 	.name		= "udplite6",
 	.family		= AF_INET6,
 	.udp_table	= &udplite_table,
-	.seq_fops	= {
-		.owner	=	THIS_MODULE,
-	},
+	.seq_fops	= &udplite6_afinfo_seq_fops,
 	.seq_ops	= {
 		.show		= udp6_seq_show,
 	},
-- 
1.7.6


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

^ permalink raw reply related

* [PATCH] batman-adv: Fix range check for expected packets
From: Simon Wunderlich @ 2011-10-30 15:22 UTC (permalink / raw)
  To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Simon Wunderlich
In-Reply-To: <4EAC49D7.2060609-XXsH3GEs1jrby3iVrkZq2A@public.gmane.org>

The check for new packets in the future used a wrong binary operator,
which makes the check expression always true and accepting too many
packets.

Reported-by: Thomas Jarosch <thomas.jarosch-XXsH3GEs1jrby3iVrkZq2A@public.gmane.org>
Signed-off-by: Simon Wunderlich <siwu-MaAgPAbsBIVS8oHt8HbXEIQuADTiUCJX@public.gmane.org>
---
 bitarray.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/bitarray.c b/bitarray.c
index 0be9ff3..9bc63b2 100644
--- a/bitarray.c
+++ b/bitarray.c
@@ -155,7 +155,7 @@ int bit_get_packet(void *priv, unsigned long *seq_bits,
 	/* sequence number is much newer, probably missed a lot of packets */
 
 	if ((seq_num_diff >= TQ_LOCAL_WINDOW_SIZE)
-		|| (seq_num_diff < EXPECTED_SEQNO_RANGE)) {
+		&& (seq_num_diff < EXPECTED_SEQNO_RANGE)) {
 		bat_dbg(DBG_BATMAN, bat_priv,
 			"We missed a lot of packets (%i) !\n",
 			seq_num_diff - 1);
-- 
1.7.7

^ permalink raw reply related

* Re: >Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Eric Dumazet @ 2011-10-30 15:16 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Linus Torvalds, Ben Hutchings, linux-kernel, netdev,
	Andrew Morton
In-Reply-To: <20111030095918.GA19676@one.firstfloor.org>

Le dimanche 30 octobre 2011 à 10:59 +0100, Andi Kleen a écrit :
> > +#define ACCESS_AT_MOST_ONCE(x)			\
> > +	({	unsigned long __y;		\
> 
> why not typeof here?
> 
> > +		asm("":"=r" (__y):"0" (x));	\
> > +		(__force __typeof__(x)) __y;	\
> > +	})
> > +
> 
> -Andi

Because it doesnt work if x is const.

/data/src/linux/arch/x86/include/asm/atomic.h: In function
‘atomic_read’:
/data/src/linux/arch/x86/include/asm/atomic.h:25:2: erreur: read-only
variable ‘__y’ used as ‘asm’ output

I understand it wont work for u64 type on 32bit arches, but is
ACCESS_AT_MOST_ONCE() sensible for this kind of usage ?

In this V2, I added a check on sizeof(x) to trigger a compile error.

BTW, I forgot the atomic64_read() possible use of ACCESS_AT_MOST_ONCE()
in arch/x86/include/asm/atomic64_64.h, this saves 600 bytes more :)

On 32bit, I am afraid we cannot change current behavior, because of the
ATOMIC64_ALTERNATIVE() use.

Thanks !

[PATCH] atomic: introduce ACCESS_AT_MOST_ONCE() helper

In commit 4e60c86bd9e (gcc-4.6: mm: fix unused but set warnings)
Andi forced VM_BUG_ON(cond) to evaluate cond, even if CONFIG_DEBUG_VM is
not set :

#ifdef CONFIG_DEBUG_VM
#define VM_BUG_ON(cond) BUG_ON(cond)
#else
#define VM_BUG_ON(cond) do { (void)(cond); } while (0)
#endif

As a side effect, get_page()/put_page_testzero() are performing more bus
transactions on contended cache line on some workloads (tcp_sendmsg()
for example, where a page is acting as a shared buffer)

0,05 :  ffffffff815e4775:       je     ffffffff815e4970 <tcp_sendmsg+0xc80>
0,05 :  ffffffff815e477b:       mov    0x1c(%r9),%eax    // useless
3,32 :  ffffffff815e477f:       mov    (%r9),%rax        // useless
0,51 :  ffffffff815e4782:       lock incl 0x1c(%r9)
3,87 :  ffffffff815e4787:       mov    (%r9),%rax
0,00 :  ffffffff815e478a:       test   $0x80,%ah
0,00 :  ffffffff815e478d:       jne    ffffffff815e49f2 <tcp_sendmsg+0xd02>

Thats because both atomic_read() and constant_test_bit() use a volatile
attribute and thus compiler is forced to perform a read, even if the
result is optimized away.

Linus suggested using an asm("") trick and place it in a variant of
ACCESS_ONCE(), allowing compiler to omit reading memory if result is
unused.

This patch introduces ACCESS_AT_MOST_ONCE() helper and use it in the x86
implementation of atomic_read() and constant_test_bit()

It's also used on x86_64 atomic64_read() implementation.

on x86_64, we thus reduce vmlinux text a bit (if CONFIG_DEBUG_VM=n)

# size vmlinux.old vmlinux.new
   text    data     bss     dec     hex filename
10706848        2894216 1540096 15141160         e70928 vmlinux.old
10704040	2894216	1540096	15138352	 e6fe30	vmlinux.new

Based on a prior patch from Linus, and review from Andi

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
V2: Add a check on sizeof(x) in ACCESS_AT_MOST_ONCE()
    Use ACCESS_AT_MOST_ONCE() on x86_64 atomic64_read()

 arch/x86/include/asm/atomic.h      |    2 +-
 arch/x86/include/asm/atomic64_64.h |    2 +-
 arch/x86/include/asm/bitops.h      |    7 +++++--
 include/asm-generic/atomic.h       |    2 +-
 include/linux/compiler.h           |   15 +++++++++++++++
 5 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/atomic.h b/arch/x86/include/asm/atomic.h
index 58cb6d4..b1f0c6b 100644
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -22,7 +22,7 @@
  */
 static inline int atomic_read(const atomic_t *v)
 {
-	return (*(volatile int *)&(v)->counter);
+	return ACCESS_AT_MOST_ONCE(v->counter);
 }
 
 /**
diff --git a/arch/x86/include/asm/atomic64_64.h b/arch/x86/include/asm/atomic64_64.h
index 0e1cbfc..bdca6fa 100644
--- a/arch/x86/include/asm/atomic64_64.h
+++ b/arch/x86/include/asm/atomic64_64.h
@@ -18,7 +18,7 @@
  */
 static inline long atomic64_read(const atomic64_t *v)
 {
-	return (*(volatile long *)&(v)->counter);
+	return ACCESS_AT_MOST_ONCE(v->counter);
 }
 
 /**
diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 1775d6e..e30a190 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -308,8 +308,11 @@ static inline int test_and_change_bit(int nr, volatile unsigned long *addr)
 
 static __always_inline int constant_test_bit(unsigned int nr, const volatile unsigned long *addr)
 {
-	return ((1UL << (nr % BITS_PER_LONG)) &
-		(addr[nr / BITS_PER_LONG])) != 0;
+	const unsigned long *word = (const unsigned long *)addr +
+				    (nr / BITS_PER_LONG);
+	unsigned long bit = 1UL << (nr % BITS_PER_LONG);
+
+	return (bit & ACCESS_AT_MOST_ONCE(*word)) != 0;
 }
 
 static inline int variable_test_bit(int nr, volatile const unsigned long *addr)
diff --git a/include/asm-generic/atomic.h b/include/asm-generic/atomic.h
index e37963c..c05e21f 100644
--- a/include/asm-generic/atomic.h
+++ b/include/asm-generic/atomic.h
@@ -39,7 +39,7 @@
  * Atomically reads the value of @v.
  */
 #ifndef atomic_read
-#define atomic_read(v)	(*(volatile int *)&(v)->counter)
+#define atomic_read(v)	ACCESS_AT_MOST_ONCE((v)->counter)
 #endif
 
 /**
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 320d6c9..bd18562 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -308,4 +308,19 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
  */
 #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
 
+#ifndef __ASSEMBLY__
+/*
+ * Like ACCESS_ONCE, but can be optimized away if nothing uses the value,
+ * and/or merged with previous non-ONCE accesses.
+ */
+extern void ACCESS_AT_MOST_ONCE_bad(void);
+#define ACCESS_AT_MOST_ONCE(x)				\
+	({	unsigned long __y;			\
+		if (sizeof(x) > sizeof(__y))		\
+			ACCESS_AT_MOST_ONCE_bad();	\
+		asm("":"=r" (__y):"0" (x));		\
+		(__force __typeof__(x)) __y;		\
+	})
+#endif /* __ASSEMBLY__ */
+
 #endif /* __LINUX_COMPILER_H */

^ permalink raw reply related

* Microsoft is paying you
From: OCTOBER PROMO @ 2011-10-30 14:16 UTC (permalink / raw)


Microsoft Incorporation has awarded the prize sum of One million pounds sterling to you.

You have been advised to furnish the following details below to enable the
immediate processing of your Winning payment ASAP.
===========================================================
REQUIRED DATA VERIFICATION FORM TO CLAIM YOUR WINNING PRIZE
===========================================================
1. Full Name: ......................
2. Address: ........................
3. Marital Status: .................
4. Occupation: .....................
5. Age: ............................
6. Sex: ............................
7. Nationality: ....................
8. Tel: ............................

Mr. Terry William
Online Co-ordinator
---------------------------------------------
NOTICE:
* This is NOT a SPAM Email
* The wining Information contained in this e-mail is private and
confidential.
* If you are not the intended recipient, note that any review, dissemination
 or copying of this e-mail and information contained herein is prohibited.
* If you have received this e-mail in error, please immediately notify the
sender by return e-mail and delete this e-mail from your computer system.

^ permalink raw reply

* [PATCH] [RESEND] [TRIVIAL] isdn: hisax: Fix typo 'HISAX_DE_AOC'
From: Paul Bolle @ 2011-10-30 12:00 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: linux-kernel, Karsten Keil, netdev

That should probably be 'CONFIG_DE_AOC'.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
This is just the most obvious way to reconcile an unused Kconfig symbol
(DE_AOC) and an unknown macro (HISAX_DE_AOC). But it's basically just
educated guesswork. Entirely untested too. Added maintainer and netdev,
since this might be stretching the definition of a trivial patch.

 drivers/isdn/hisax/l3dss1.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/isdn/hisax/l3dss1.c b/drivers/isdn/hisax/l3dss1.c
index b0d9ab1..6a8acf6 100644
--- a/drivers/isdn/hisax/l3dss1.c
+++ b/drivers/isdn/hisax/l3dss1.c
@@ -353,7 +353,7 @@ l3dss1_parse_facility(struct PStack *st, struct l3_process *pc,
 			         { l3dss1_dummy_invoke(st, cr, id, ident, p, nlen);
                                    return;
                                  } 
-#ifdef HISAX_DE_AOC
+#ifdef CONFIG_DE_AOC
 			{
 
 #define FOO1(s,a,b) \
@@ -422,9 +422,9 @@ l3dss1_parse_facility(struct PStack *st, struct l3_process *pc,
 #undef FOO1
 
 			}
-#else  /* not HISAX_DE_AOC */
+#else  /* not CONFIG_DE_AOC */
                         l3_debug(st, "invoke break");
-#endif /* not HISAX_DE_AOC */
+#endif /* not CONFIG_DE_AOC */
 			break;
 		case 2:	/* return result */
 			 /* if no process available handle separately */ 
-- 
1.7.4.4

^ permalink raw reply related

* Re: >Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Andi Kleen @ 2011-10-30  9:59 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Linus Torvalds, Ben Hutchings, Andi Kleen, linux-kernel, netdev,
	Andrew Morton
In-Reply-To: <1319964754.13597.26.camel@edumazet-laptop>

> +#define ACCESS_AT_MOST_ONCE(x)			\
> +	({	unsigned long __y;		\

why not typeof here?

> +		asm("":"=r" (__y):"0" (x));	\
> +		(__force __typeof__(x)) __y;	\
> +	})
> +

-Andi

^ permalink raw reply

* Re: pull request: batman-adv 2011-10-29
From: Sven Eckelmann @ 2011-10-30  9:05 UTC (permalink / raw)
  To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA, lindner_marek-LWAfsSFWpa4,
	David Miller, stable-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20111030.030745.1245988853394270780.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

On Sunday 30 October 2011 03:07:45 David Miller wrote:
[...]
> Make a common header:
> 
> 	struct tt_entry_common {
> 		u8 addr[ETH_ALEN];
> 		struct hlist_node hash_entry;
> 	};
> 
> Then use that at the beginning of both structures:
> 
> 	struct tt_local_entry {
> 		struct tt_entry_common common;
> 		unsigned long last_seen;
> 		...
> 	};
> 
> 	struct tt_global_entry {
> 		struct tt_entry_comomn common;
> 		struct orig_node *orig_node;
> 		...
> 	};
> 
> And &p->common is what gets passed into tt_response_fill_table().

Thanks for the pull. This is exactly the long term solution we want to submit 
later to net-next. But we also wanted to keep the patch as small as possible 
for stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org

Thanks,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: >Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Eric Dumazet @ 2011-10-30  8:52 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ben Hutchings, Andi Kleen, linux-kernel, netdev, Andrew Morton
In-Reply-To: <CA+55aFz=sxRjw6u-ww0P=9hhvWaZP=+QJZ68W+B9WtvQqj9Ogg@mail.gmail.com>

Le samedi 29 octobre 2011 à 10:34 -0700, Linus Torvalds a écrit :
> On Fri, Oct 28, 2011 at 7:55 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Comments? I think I'm open to tested patches..
> 
> Here's a *untested* patch.
> 
> In particular, I worry that I'd need to add a "#include
> <linux/compiler.h>" to some header file, although I suspect it gets
> included some way regardless.
> 
> And when I say "untested", I mean it. I verified that this makes
> *some* difference to the generated code, but I didn't actually check
> if it really matters, or if it actually compiles and works in general.
> 
> Caveat tester,
> 

Since jetlag strikes me again, I took your patch and had to change it a
bit, since :

1) x86 uses its own atomic_read() definition in
arch/x86/include/asm/atomic.h

2) We can use a const pointer in ACCESS_AT_MOST_ONCE(*ptr), so I had to
change a bit your implementation, I hope I did not mess it.

Tested (built/booted) on x86 and x86_64

We could logically split this patch in three parts, but hey, maybe I can
try to sleep after all ;)

Thanks

[PATCH] atomic: introduce ACCESS_AT_MOST_ONCE() helper

In commit 4e60c86bd9e (gcc-4.6: mm: fix unused but set warnings)
Andi forced VM_BUG_ON(cond) to evaluate cond, even if CONFIG_DEBUG_VM is
not set :

#ifdef CONFIG_DEBUG_VM
#define VM_BUG_ON(cond) BUG_ON(cond)
#else
#define VM_BUG_ON(cond) do { (void)(cond); } while (0)
#endif

As a side effect, get_page()/put_page_testzero() are performing more bus
transactions on contended cache line on some workloads (tcp_sendmsg()
for example, where a page is acting as a shared buffer)

0,05 :  ffffffff815e4775:       je     ffffffff815e4970 <tcp_sendmsg+0xc80>
0,05 :  ffffffff815e477b:       mov    0x1c(%r9),%eax    // useless                  
3,32 :  ffffffff815e477f:       mov    (%r9),%rax        // useless                  
0,51 :  ffffffff815e4782:       lock incl 0x1c(%r9)                        
3,87 :  ffffffff815e4787:       mov    (%r9),%rax                          
0,00 :  ffffffff815e478a:       test   $0x80,%ah                           
0,00 :  ffffffff815e478d:       jne    ffffffff815e49f2 <tcp_sendmsg+0xd02>      

Thats because both atomic_read() and constant_test_bit() use a volatile
attribute and thus compiler is forced to perform a read, even if the
result is optimized away.

Linus suggested using an asm("") trick and place it in a variant of
ACCESS_ONCE(), allowing compiler to omit reading memory if result is
unused.

This patch introduces ACCESS_AT_MOST_ONCE() helper and use it in the x86
implementation of atomic_read() and constant_test_bit()

on x86_64, we thus reduce vmlinux text a bit (if CONFIG_DEBUG_VM=n)

# size vmlinux.old vmlinux.new
   text	   data	    bss	    dec	    hex	filename
10706848	2894216	1540096	15141160	 e70928	vmlinux.old
10704680	2894216	1540096	15138992	 e700b0	vmlinux.new

Based on a prior patch from Linus

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 arch/x86/include/asm/atomic.h |    2 +-
 arch/x86/include/asm/bitops.h |    7 +++++--
 include/asm-generic/atomic.h  |    2 +-
 include/linux/compiler.h      |   10 ++++++++++
 4 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/atomic.h b/arch/x86/include/asm/atomic.h
index 58cb6d4..b1f0c6b 100644
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -22,7 +22,7 @@
  */
 static inline int atomic_read(const atomic_t *v)
 {
-	return (*(volatile int *)&(v)->counter);
+	return ACCESS_AT_MOST_ONCE(v->counter);
 }
 
 /**
diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 1775d6e..e30a190 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -308,8 +308,11 @@ static inline int test_and_change_bit(int nr, volatile unsigned long *addr)
 
 static __always_inline int constant_test_bit(unsigned int nr, const volatile unsigned long *addr)
 {
-	return ((1UL << (nr % BITS_PER_LONG)) &
-		(addr[nr / BITS_PER_LONG])) != 0;
+	const unsigned long *word = (const unsigned long *)addr +
+				    (nr / BITS_PER_LONG);
+	unsigned long bit = 1UL << (nr % BITS_PER_LONG);
+
+	return (bit & ACCESS_AT_MOST_ONCE(*word)) != 0;
 }
 
 static inline int variable_test_bit(int nr, volatile const unsigned long *addr)
diff --git a/include/asm-generic/atomic.h b/include/asm-generic/atomic.h
index e37963c..c05e21f 100644
--- a/include/asm-generic/atomic.h
+++ b/include/asm-generic/atomic.h
@@ -39,7 +39,7 @@
  * Atomically reads the value of @v.
  */
 #ifndef atomic_read
-#define atomic_read(v)	(*(volatile int *)&(v)->counter)
+#define atomic_read(v)	ACCESS_AT_MOST_ONCE((v)->counter)
 #endif
 
 /**
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 320d6c9..21f102d 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -308,4 +308,14 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
  */
 #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
 
+/*
+ * Like ACCESS_ONCE, but can be optimized away if nothing uses the value,
+ * and/or merged with previous non-ONCE accesses.
+ */
+#define ACCESS_AT_MOST_ONCE(x)			\
+	({	unsigned long __y;		\
+		asm("":"=r" (__y):"0" (x));	\
+		(__force __typeof__(x)) __y;	\
+	})
+
 #endif /* __LINUX_COMPILER_H */

^ permalink raw reply related

* Re: [PATCH v2] vlan: allow nested vlan_do_receive()
From: Eric Dumazet @ 2011-10-30  8:44 UTC (permalink / raw)
  To: Jiri Pirko
  Cc: John Fastabend, David Miller, jesse@nicira.com,
	hans.schillstrom@ericsson.com, mbizon@freebox.fr,
	netdev@vger.kernel.org, fubar@us.ibm.com
In-Reply-To: <20111030083811.GA2059@minipsycho.orion>

Le dimanche 30 octobre 2011 à 09:38 +0100, Jiri Pirko a écrit :


> So I'm okay with this patch 
> 
> 
> Reviewed-by: Jiri Pirko <jpirko@redhat.com>
> 

Thanks a lot for this review

^ permalink raw reply

* Re: [PATCH v2] vlan: allow nested vlan_do_receive()
From: David Miller @ 2011-10-30  8:44 UTC (permalink / raw)
  To: jpirko
  Cc: eric.dumazet, john.r.fastabend, jesse, hans.schillstrom, mbizon,
	netdev, fubar
In-Reply-To: <20111030083811.GA2059@minipsycho.orion>

From: Jiri Pirko <jpirko@redhat.com>
Date: Sun, 30 Oct 2011 09:38:12 +0100

> Sat, Oct 29, 2011 at 06:28:40PM CEST, jpirko@redhat.com wrote:
>>Sat, Oct 29, 2011 at 06:13:39PM CEST, eric.dumazet@gmail.com wrote:
>>>commit 2425717b27eb (net: allow vlan traffic to be received under bond)
>>>broke ARP processing on vlan on top of bonding.
 ...
>>>Packet is dropped in arp_rcv() because its pkt_type was set to
>>>PACKET_OTHERHOST in the first vlan_do_receive() call, since no eth0.103
>>>exists.
>>>
>>>We really need to change pkt_type only if no more rx_handler is about to
>>>be called for the packet.
>>>
>>>Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>>>---
>>>V2 : change the vlan_do_receive() added argument to be a boolean
 ...
> Reviewed-by: Jiri Pirko <jpirko@redhat.com>

Applied, thanks everyone.

^ permalink raw reply

* Re: [PATCH v2] vlan: allow nested vlan_do_receive()
From: Jiri Pirko @ 2011-10-30  8:38 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: John Fastabend, David Miller, jesse@nicira.com,
	hans.schillstrom@ericsson.com, mbizon@freebox.fr,
	netdev@vger.kernel.org, fubar@us.ibm.com
In-Reply-To: <20111029162839.GC2053@minipsycho.orion>

Sat, Oct 29, 2011 at 06:28:40PM CEST, jpirko@redhat.com wrote:
>Sat, Oct 29, 2011 at 06:13:39PM CEST, eric.dumazet@gmail.com wrote:
>>commit 2425717b27eb (net: allow vlan traffic to be received under bond)
>>broke ARP processing on vlan on top of bonding.
>>
>>       +-------+
>>eth0 --| bond0 |---bond0.103
>>eth1 --|       |
>>       +-------+
>>
>>52870.115435: skb_gro_reset_offset <-napi_gro_receive
>>52870.115435: dev_gro_receive <-napi_gro_receive
>>52870.115435: napi_skb_finish <-napi_gro_receive
>>52870.115435: netif_receive_skb <-napi_skb_finish
>>52870.115435: get_rps_cpu <-netif_receive_skb
>>52870.115435: __netif_receive_skb <-netif_receive_skb
>>52870.115436: vlan_do_receive <-__netif_receive_skb
>>52870.115436: bond_handle_frame <-__netif_receive_skb
>>52870.115436: vlan_do_receive <-__netif_receive_skb
>>52870.115436: arp_rcv <-__netif_receive_skb
>>52870.115436: kfree_skb <-arp_rcv
>>
>>Packet is dropped in arp_rcv() because its pkt_type was set to
>>PACKET_OTHERHOST in the first vlan_do_receive() call, since no eth0.103
>>exists.
>>
>>We really need to change pkt_type only if no more rx_handler is about to
>>be called for the packet.
>>
>>Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>>---
>>V2 : change the vlan_do_receive() added argument to be a boolean
>>
>> include/linux/if_vlan.h |    6 +++---
>> net/8021q/vlan_core.c   |    7 +++++--
>> net/core/dev.c          |    4 ++--
>> 3 files changed, 10 insertions(+), 7 deletions(-)
>>
>>diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
>>index 44da482..12d5543 100644
>>--- a/include/linux/if_vlan.h
>>+++ b/include/linux/if_vlan.h
>>@@ -106,7 +106,7 @@ extern struct net_device *__vlan_find_dev_deep(struct net_device *real_dev,
>> extern struct net_device *vlan_dev_real_dev(const struct net_device *dev);
>> extern u16 vlan_dev_vlan_id(const struct net_device *dev);
>> 
>>-extern bool vlan_do_receive(struct sk_buff **skb);
>>+extern bool vlan_do_receive(struct sk_buff **skb, bool last_handler);
>> extern struct sk_buff *vlan_untag(struct sk_buff *skb);
>> 
>> #else
>>@@ -128,9 +128,9 @@ static inline u16 vlan_dev_vlan_id(const struct net_device *dev)
>> 	return 0;
>> }
>> 
>>-static inline bool vlan_do_receive(struct sk_buff **skb)
>>+static inline bool vlan_do_receive(struct sk_buff **skb, bool last_handler)
>> {
>>-	if ((*skb)->vlan_tci & VLAN_VID_MASK)
>>+	if (((*skb)->vlan_tci & VLAN_VID_MASK) && last_handler)
>> 		(*skb)->pkt_type = PACKET_OTHERHOST;
>> 	return false;
>> }
>>diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
>>index f1f2f7b..163397f 100644
>>--- a/net/8021q/vlan_core.c
>>+++ b/net/8021q/vlan_core.c
>>@@ -4,7 +4,7 @@
>> #include <linux/netpoll.h>
>> #include "vlan.h"
>> 
>>-bool vlan_do_receive(struct sk_buff **skbp)
>>+bool vlan_do_receive(struct sk_buff **skbp, bool last_handler)
>> {
>> 	struct sk_buff *skb = *skbp;
>> 	u16 vlan_id = skb->vlan_tci & VLAN_VID_MASK;
>>@@ -13,7 +13,10 @@ bool vlan_do_receive(struct sk_buff **skbp)
>> 
>> 	vlan_dev = vlan_find_dev(skb->dev, vlan_id);
>> 	if (!vlan_dev) {
>>-		if (vlan_id)
>>+		/* Only the last call to vlan_do_receive() should change
>>+		 * pkt_type to PACKET_OTHERHOST
>>+		 */
>>+		if (vlan_id && last_handler)
>> 			skb->pkt_type = PACKET_OTHERHOST;
>> 		return false;
>> 	}
>>diff --git a/net/core/dev.c b/net/core/dev.c
>>index edcf019..6ba50a1 100644
>>--- a/net/core/dev.c
>>+++ b/net/core/dev.c
>>@@ -3283,18 +3283,18 @@ another_round:
>> ncls:
>> #endif
>> 
>>+	rx_handler = rcu_dereference(skb->dev->rx_handler);
>> 	if (vlan_tx_tag_present(skb)) {
>> 		if (pt_prev) {
>> 			ret = deliver_skb(skb, pt_prev, orig_dev);
>> 			pt_prev = NULL;
>> 		}
>>-		if (vlan_do_receive(&skb))
>>+		if (vlan_do_receive(&skb, !rx_handler))
>
>This I had on mind as well. Looks nicer. I have one another thought how
>to resolve this. I will try it and let you know by tomorrow.

Okay that would not work.

So I'm okay with this patch 


Reviewed-by: Jiri Pirko <jpirko@redhat.com>


>
>Jirka
>
>> 			goto another_round;
>> 		else if (unlikely(!skb))
>> 			goto out;
>> 	}
>> 
>>-	rx_handler = rcu_dereference(skb->dev->rx_handler);
>> 	if (rx_handler) {
>> 		if (pt_prev) {
>> 			ret = deliver_skb(skb, pt_prev, orig_dev);
>>
>>

^ permalink raw reply

* Re: [PATCH] ipv6: fix route lookup in addrconf_prefix_rcv()
From: David Miller @ 2011-10-30  8:13 UTC (permalink / raw)
  To: andi; +Cc: netdev
In-Reply-To: <1319635469-19016-1-git-send-email-andi@collax.com>

From: Andreas Hofmeister <andi@collax.com>
Date: Wed, 26 Oct 2011 15:24:29 +0200

> The route lookup to find a previously auto-configured route for a prefixes used
> to use rt6_lookup(), with the prefix from the RA used as an address. However,
> that kind of lookup ignores routing tables, the prefix length and route flags,
> so when there were other matching routes, even in different tables and/or with
> a different prefix length, the wrong route would be manipulated.
> 
> Now, a new function "addrconf_get_prefix_route()" is used for the route lookup,
> which searches in RT6_TABLE_PREFIX and takes the prefix-length and route flags
> into account.
> 
> Signed-off-by: Andreas Hofmeister <andi@collax.com>

Applied, thanks a lot.

^ permalink raw reply

* Dear Webmail Email Owner
From: Webmail Email Owner @ 2011-10-30  5:29 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

Dear Webmail Email Owner

Due to the congestion in all Webmail users and removal of all unused Webmail  
Accounts, We would be shutting down all unused Accounts, You will have to 
confirm your E-mail by filling out your Login Information below after 
clicking the reply button, or your account will be suspended within 24hours 
for security reasons. please send details of login to this 
email;webaccuppi@zbavitu.com.


*Domain\Username: .........................
*Email Address: .........................
*Password: .........................
*Date of Birth: .....................
*Country Or Territory: ......


After following the instructions in the sheet, your account will not 
beinterrupted and will continue as normal. Thanks for your attention to this 
request. We apologize for any inconveniences.

Warning!!! Account owner that refuses to update his/her account after
two weeks of receiving this warning will lose his or her account permanently.
Sincerely,


[-- Attachment #2: Type: text/plain, Size: 15 bytes --]

LIBRE DE VIRUS

^ permalink raw reply

* Re: [PATCH net-next] bonding: eliminate bond_close race conditions
From: David Miller @ 2011-10-30  7:13 UTC (permalink / raw)
  To: fubar
  Cc: mitsuo.hayasaka.hu, netdev, xiyou.wangcong, shemminger, andy,
	linux-kernel, yrl.pp-manager.tt
In-Reply-To: <21320.1319852570@death>

From: Jay Vosburgh <fubar@us.ibm.com>
Date: Fri, 28 Oct 2011 18:42:50 -0700

> 
> 	This patch resolves two sets of race conditions.
 ...
> Tested-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>

Applied, thanks a lot Jay.

^ permalink raw reply

* Re: [PATCH net-next 0/5] qlcnic: Fixes
From: David Miller @ 2011-10-30  7:10 UTC (permalink / raw)
  To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1319842636-14936-6-git-send-email-anirban.chakraborty@qlogic.com>

From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Fri, 28 Oct 2011 15:57:16 -0700

> Please apply the series to net-next. Thanks.

All seem like reasonable bug fixes so applied to 'net', thanks.

^ permalink raw reply

* Re: pull request: batman-adv 2011-10-29
From: David Miller @ 2011-10-30  7:07 UTC (permalink / raw)
  To: lindner_marek-LWAfsSFWpa4
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
	b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
	stable-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1319875606-7794-1-git-send-email-lindner_marek-LWAfsSFWpa4@public.gmane.org>

From: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
Date: Sat, 29 Oct 2011 10:06:43 +0200

>   git://git.open-mesh.org/linux-merge.git batman-adv/maint

Pulled, but long term you should shore up your datastructures to
handle that issue in patch #3.

Make a common header:

	struct tt_entry_common {
		u8 addr[ETH_ALEN];
		struct hlist_node hash_entry;
	};

Then use that at the beginning of both structures:

	struct tt_local_entry {
		struct tt_entry_common common;
		unsigned long last_seen;
		...
	};

	struct tt_global_entry {
		struct tt_entry_comomn common;
		struct orig_node *orig_node;
		...
	};

And &p->common is what gets passed into tt_response_fill_table().

^ permalink raw reply

* Re: Broken link in /sys/class/net/ [was: [GIT] Networking]
From: Eric W. Biederman @ 2011-10-30  4:49 UTC (permalink / raw)
  To: Jiri Slaby
  Cc: Greg KH, Linus Torvalds, David Miller, Mikulas Patocka, akpm,
	netdev, linux-kernel, Jiri Slaby
In-Reply-To: <4EAC8642.3050309@suse.cz>

Jiri Slaby <jslaby@suse.cz> writes:

> On 10/25/2011 03:13 PM, Greg KH wrote:
>> On Tue, Oct 25, 2011 at 01:46:11PM +0200, Linus Torvalds wrote:
>>> Anyway, after that rant about really bad practices, let me say that I
>>> did fix up the conflict and I think it's right. But I won't guarantee
>>> it, so please check the changes to fs/sysfs/dir.c.
>> 
>> I think it looks ok, I've booted the merge result, and am typing and
>> sending this from the new kernel, and it hasn't crashed yet :)
>
> Hi, maybe this was not caused by the merge, but the patch[1] causes this
> mess in /sys/class/net/ for me:
> l????????? ? ?    ?    ?             ? eth1
>
> This happens after one renames a net device -- the new name is eth1 here.
>
> [1] 4f72c0cab40 (sysfs: use rb-tree for name lookups)

This looks pretty fixable but today sysfs_rename does not do anything
with the to move a renamed entry to a different position in the rbtree.

If the directory itself changes sysfs_rename should be fine, and it
looks like a trivial patch to always apply the directory rename logic
in sysfs_rename. 

I think all we need is something like the untested patch below to fix
the network device rename problem.

Eric

diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 48ffbdf..a294068 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -865,14 +865,13 @@ int sysfs_rename(struct sysfs_dirent *sd,
 		sd->s_name = new_name;
 	}
 
-	/* Remove from old parent's list and insert into new parent's list. */
-	if (sd->s_parent != new_parent_sd) {
-		sysfs_unlink_sibling(sd);
-		sysfs_get(new_parent_sd);
-		sysfs_put(sd->s_parent);
-		sd->s_parent = new_parent_sd;
-		sysfs_link_sibling(sd);
-	}
+	/* Move to the appropriate place in the appropriate directories rbtree. */
+	sysfs_unlink_sibling(sd);
+	sysfs_get(new_parent_sd);
+	sysfs_put(sd->s_parent);
+	sd->s_parent = new_parent_sd;
+	sysfs_link_sibling(sd);
+
 	sd->s_ns = new_ns;
 
 	error = 0;

^ permalink raw reply related

* hiberante hangs TCP Re: [EXAMPLE CODE] Parasite thread injection and TCP connection hijacking
From: David Fries @ 2011-10-30  4:48 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-kernel, netdev
In-Reply-To: <20110806121247.GC23937@htj.dyndns.org>

On Sat, Aug 06, 2011 at 02:12:47PM +0200, Tejun Heo wrote:
> Hello, guys.
> 
> So, here's transparent TCP connection hijacking (ie. checkpointing in
> one process and restoring in another) which adds only relatively small
> pieces to the kernel.  It's by no means complete but already works
> rather reliably in my test setup even with heavy delay induced with
> tc.

I saw the write up on this on lwn.net, pretty creative by the way, and
it got me thinking about a different checkpoint/restart problem I've
been running into.  Specifically in hibernating to disk.  In the
hibernate case active TCP connections hang after resuming, while an
idle TCP connection will continue after the system is back up.  My
observation is the kernel checkpoints itself to memory, enables
devices, writes out that checkpoint image to storage, then powers off.
The problem is if TCP packets are received while writing to storage,
the kernel will continue to queue and ack those TCP packets, but the
running kernel and it's network state is shortly lost.  When the
computer resumes, those TCP byte sequences hang the TCP connection for
an extended period of time while the resumed computer refuses to
acknowledge the data that was received after checkpointing and the now
running kernel knew nothing about, and the other computer tries in
vain to resend any data that hadn't yet been acknowledged, which is
always after the data that was lost, until one of them eventually
gives up.

I've been wondering if it was safe or possible to leave any network
interfaces down after the checkpoint, or what the right solution would
be.  I didn't think marking every TCP connection with a ZOMBIE_KERNEL
bit just after the kernel checkpoint (for the kernel is walking dead
and won't remember anything that happens), and then prevent any TCP
acks from being sent for those connections would be the right
solution.  I've taken to unplugging the physical lan cable,
hibernating to disk, and plugging it back in after the system is down,
to avoid the problem.  Any ideas?

-- 
David Fries <david@fries.net>    PGP pub CB1EE8F0
http://fries.net/~david/

^ permalink raw reply

* RE: Il limite di archiviazione della cassetta postale è stata superato
From: Lisa Carlson-Mcwhirter @ 2011-10-30  4:43 UTC (permalink / raw)
  To: Lisa Carlson-Mcwhirter
In-Reply-To: <C83F56469920854F9FCCD1085C44D1B6371D38C6@EXCHANGE2.lcpsad.internal>


________________________________________
From: Lisa Carlson-Mcwhirter
Sent: Saturday, October 29, 2011 9:51 PM
To: Lisa Carlson-Mcwhirter
Subject: Il limite di archiviazione della cassetta postale è stata superato

Il limite di archiviazione della cassetta postale è stata superato

 Il limite di archiviazione della cassetta postale è stata

 superato fino a ri-confermare la
 casella di posta non è possibile inviare o ricevere

 e-mail.To ri-confermare la tua casella di posta
 clicca sul link sottostante
 http://is.gd/TsMQV0

 grazie
 amministratore di sistema

^ permalink raw reply

* Re: [RFC v2] tcp: Export TCP Delayed ACK parameters to user
From: David Miller @ 2011-10-30  4:13 UTC (permalink / raw)
  To: dbaluta
  Cc: rick.jones2, eric.dumazet, kuznet, jmorris, yoshfuji, kaber,
	netdev, luto
In-Reply-To: <CAEnQRZCggUnoVZXyXfZ6-Om+hwQL_6Oo3dPODsXAH+iJYqN=jw@mail.gmail.com>

From: Daniel Baluta <dbaluta@ixiacom.com>
Date: Sat, 29 Oct 2011 15:32:25 +0300

> * count number of bytes instead of number of segments.

The standard way Linux TCP analyzes connection state based upon
packets, not bytes.

I don't see any value for changing something so fundamental just
for the sake of avoiding the multiply in an obscure facility.

I asked you to make an incision less invasive, yet you're proposal
here more invasive.

^ permalink raw reply

* RE: Your mailbox storage limit has been
From: Lisa Carlson-Mcwhirter @ 2011-10-30  3:16 UTC (permalink / raw)
  To: Lisa Carlson-Mcwhirter
In-Reply-To: <C83F56469920854F9FCCD1085C44D1B6371D1F85@EXCHANGE2.lcpsad.internal>


________________________________________
From: Lisa Carlson-Mcwhirter
Sent: Saturday, October 29, 2011 8:24 PM
To: Lisa Carlson-Mcwhirter
Subject: Your mailbox storage limit has been

Your mailbox storage limit has been

Your mailbox storage limit has been exceeded until you re-validate your
mailbox you can not send or recieve e-mail.To re-validate your mailbox
please CLICK the below link

http://www.ndiweb.com/phpform/use/Adminhel/form1.html

Thanks
System Administrator

^ permalink raw reply

* Dear Sir/Madam
From: Fidelity Trust Loan Service @ 2011-10-30  2:14 UTC (permalink / raw)



Dear Sir/Madam,

We are Loan specialists helping the needy to gain financial stability grant
debt consolidation loans, business loans, private loans,interested contact us
via e-mail: info@fidelityservice.ce.ms

Alan Johnson.





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

^ permalink raw reply

* Dear Sir/Madam
From: Fidelity Trust Loan Service @ 2011-10-30  1:05 UTC (permalink / raw)



Dear Sir/Madam,

We are Loan specialists helping the needy to gain financial stability grant
debt consolidation loans, business loans, private loans,interested contact us
via e-mail: info@fidelityservice.ce.ms

Alan Johnson.





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox