dle-develop — Dependable Linux Effort mailing list for developers

[Dle-develop] [RFC PATCH 3/4] fs: modify disk_name() for alias name

[Nao N. <nao...@hi...>]

Make disk_name() return alais_name instead of disk_name when alias_name is set.
disk_name() is used in /proc/{partitions, diskstats}. Therefore, those files
show alias_name.

Signed-off-by: Nao Nishijima <nao...@hi...>
Reviewed-by: Masami Hiramatsu <mas...@hi...>
---

 Documentation/ABI/testing/sysfs-block |    8 ++++----
 fs/partitions/check.c                 |    6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block
index 07c4fcd..432140c 100644
--- a/Documentation/ABI/testing/sysfs-block
+++ b/Documentation/ABI/testing/sysfs-block
@@ -217,7 +217,7 @@ Description:
 		instead of raw device name. However, kernel doesn't show those
 		persistent names on its message (e.g. dmesg).
 		This file can store an alias name of the disk and it would be
-		appeared in kernel messages if it is set. A disk can have an
-		alias name which length is up to 255bytes. Users can use
-		use alphabets, numbers, "-" and "_" in alias name and can
-		change it anytime.
+		appeared in kernel messages and procfs if it is set. A disk
+		can have an alias name which length is up to 255bytes. Users
+		can use use alphabets, numbers, "-" and "_" in alias name and
+		can change it anytime.
diff --git a/fs/partitions/check.c b/fs/partitions/check.c
index d545e97..d0bfe56 100644
--- a/fs/partitions/check.c
+++ b/fs/partitions/check.c
@@ -125,11 +125,11 @@ static int (*check_part[])(struct parsed_partitions *) = {
 char *disk_name(struct gendisk *hd, int partno, char *buf)
 {
 	if (!partno)
-		snprintf(buf, BDEVNAME_SIZE, "%s", hd->disk_name);
+		snprintf(buf, BDEVNAME_SIZE, "%s", alias_name(hd));
 	else if (isdigit(hd->disk_name[strlen(hd->disk_name)-1]))
-		snprintf(buf, BDEVNAME_SIZE, "%sp%d", hd->disk_name, partno);
+		snprintf(buf, BDEVNAME_SIZE, "%sp%d", alias_name(hd), partno);
 	else
-		snprintf(buf, BDEVNAME_SIZE, "%s%d", hd->disk_name, partno);
+		snprintf(buf, BDEVNAME_SIZE, "%s%d", alias_name(hd), partno);
 
 	return buf;
 }

[Dle-develop] [RFC PATCH 4/4] sd: cleanup for alias name

[Nao N. <nao...@hi...>]

Use sd_printk() instead of printk().

Signed-off-by: Nao Nishijima <nao...@hi...>
Reviewed-by: Masami Hiramatsu <mas...@hi...>
---

 drivers/scsi/sd.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 953773c..e434e5f 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1066,12 +1066,13 @@ static int sd_ioctl(struct block_device *bdev, fmode_t mode,
 		    unsigned int cmd, unsigned long arg)
 {
 	struct gendisk *disk = bdev->bd_disk;
-	struct scsi_device *sdp = scsi_disk(disk)->device;
+	struct scsi_disk *sdkp = scsi_disk(disk);
+	struct scsi_device *sdp = sdkp->device;
 	void __user *p = (void __user *)arg;
 	int error;
     
-	SCSI_LOG_IOCTL(1, printk("sd_ioctl: disk=%s, cmd=0x%x\n",
-						disk->disk_name, cmd));
+	SCSI_LOG_IOCTL(1, sd_printk(KERN_INFO, sdkp, "sd_ioctl: disk=%s,"
+		       " cmd=0x%x\n", disk->disk_name, cmd));
 
 	/*
 	 * If we are in the middle of error recovery, don't let anyone

[Dle-develop] Deleita tus oidos por solo 9€, Pierde esos kilos de más sin cansarte por 10€, Disfruta la aventura con tus hijos haciendo el mono po 15€ y montones de ofertas increibles y solidarias en MyBonusWeb

[News M. <in...@my...>]

     
       

               
Añade in...@my... a tu libreta de
direcciones y llegaremos siempre a tu bandeja de entrada.

                     Si no puedes ver bien este MyBonusDay haz click aquí

                  


                  



                     Ofertas
Solidarias en Tu Ciudad

                     Sé solidario, colabora con los que lo necesitan solo con tu email
                      
                   

 
                  



                  



                     
52% Dto. Una entrada para concierto del Festival de Musica Samamadrid.

Deleita tus
oidos por solo 9€...

                     



                     
                  

SOLO: 9€
                  


                  

Precio

                      original:
20€

                      
                     Descuento:
52%

                      
                     Ahorro:
11€

                  




                     
                     
                     
                     
                  


                     
                     
                       Relájate y disfruta de la música en el Festival de Música Antigua de Samamadrid. Varios conciertos durante todo el mes de Julio, de estilos similares y con los mejores artistas de música antigua... 
¡Consigue
tu MyBonus Ya! 
                       Con reserva previa. Validez del MyBonus, hasta el 30 de Julio.

                     
                     
                  


                     
                     
                     
                     
                  


                     
                     
                     
                     
                  



                  



                     
50% Dto.Ya no tienes excusa para lucir tu mejor figura.

Cuida tu cuerpo y tu mente, a
un precio único...

                     
                     
                  

SOLO: 10€
                  


                  

Precio

                      original:
20€

                      
                     Descuento:
50%

                      
                     Ahorro:
10€

                  




                     
                     
                     
                     
                  


                     
                     
                       Tonifícate, adelgaza y mejora tu flexibilidad sin apenas realizar esfuerzo. Prueba este nuevo sistema de Gimnasia Asistida para recuperar tu línea sin cansarte... 
¡Consigue tu MyBonus Ya! 
                       Con reserva previa. Validez del MyBonus, 3 meses.

                     
                     
                  


                     
                     
                     
                     
                  


                     
                     
                     
                     
                  



                  



                     
50% Dto.Circuito de arborismo de aproximadamente 3 horas.

Disfruta la aventura con tus
hijos a un precio increible...

                     
                     
                  

SOLO: 15€
                  


                  

Precio

                      original:
30€

                      
                     Descuento:
50%

                      
                     Ahorro:
15€

                  




                     
                     
                     
                     
                  


                     
                     
                       ¿Te gustan las aventuras?
Consigue esta aventura por un increíble precio, Arborismo durante 3 horas aproximadamente con diferentes modalidades de recorrido. Para niños o adultos que midan más de 1,50 cm de altura... 
¡Consigue tu MyBonus Ya! 
                       Con reserva previa. Validez del MyBonus, 6 meses.

                     
                     
                  


                     
                     
                     
                     
                  


                     
                     
                     
                     
                  



                  



                     
60% Dto.Consigue unos brillos espectaculares sin dañar tu cabello.

Deslumbra con tu
pelo, no pierdas la oportunidad...

                     
                     
                  

SOLO: 24,00€
                  


                  

Precio

                      original:
60€

                      
                     Descuento:
60%

                      
                     Ahorro:
36€

                  




                     
                     
                     
                     
                  


                     
                     
                       Dale a tu pelo un aspecto cuidado y bonito con los Velos de Color (Valido para cabellos teñidos y naturales)... 
¡Consigue tu MyBonus Ya! 
                       Con reserva previa. Validez del MyBonus, 6 meses.

                     
                     
                  


                     
                     
                     
                     
                  


                     
                     
                     
                     
                  



                      
                      
                      
                     
                  



                  


                     Si nos referencias a tus amigos o familiares todos tendréis un gran descuento en la compra de vuestros ¡MyBonus!
                     

                     
Sé el primero en recibir nuestras ofertas, para ello haz click en tu ciudad:

Madrid · Barcelona · Bilbao · Valencia · Zaragoza · Sevilla · Málaga · A Coruña · Mallorca · Alicante · Las Palmas · Valladolid · Córdoba · Granada · Oviedo · Otra

                     
                  




                  


Descuentos solidarios de hasta el 90% en tu ciudad
www.mybonusweb.eu

                  


                      
                      Actualmente estás suscrito a este boletín con la cuenta (dle...@li...). Tus datos se encuentran recogidos en un fichero automatizado cuyo responsable es Mybonus Experience S.L., a través de la web www.mybonusweb.eu podrás ejercitar los derechos de acceso, rectificación, cancelación y oposición. Todo ello en cumplimiento de lo dispuesto en la Ley Orgánica 15/1999,
de 13 de Diciembre de Protección de Datos de Carácter Personal.


                      Por favor no respondas a este mail. Si tienes cualquier duda o sugerencia contacta con in...@my... (in...@my...) 

                     Si NO deseas recibir las fantásticas ofertas solidarias de tu ciudad con las que tienes un ahorro de hasta el 90% y además ayudas a proyectos solidarios, haz click aquí

                  


                  


          

Re: [Dle-develop] [PATCH 0/2] Tracepoints for queueing skb to rcvbuf

[David M. <da...@da...>]

From: Satoru Moriya <sat...@hd...>
Date: Fri, 17 Jun 2011 17:56:55 -0400

> To separate these reasons, this patchset adds 3 tracepoints.
> 
> 1st one is added to __udp_queue_rcv_skb to get return value of
> ip_queue_rcv_skb. Analyzing it we can separate above (*) (3 possibilities).
> 
> 2nd and 3rd one are to get more detailed information. We can collect status 
> of socket receive queue and related parameters(some of them are sysctl knob
> e.g. /proc/sys/net/ipv4/udp_mem, etc. for UDP) and then we can tune kernel
> behavior easily.

Both patches applied, thanks.

Re: [Dle-develop] [PATCH 2/2] core: add tracepoints for queueing skb to rcvbuf

[Neil H. <nh...@tu...>]

On Fri, Jun 17, 2011 at 06:00:03PM -0400, Satoru Moriya wrote:
> This patch adds 2 tracepoints to get a status of a socket receive queue
> and related parameter. 
> 
> One tracepoint is added to sock_queue_rcv_skb. It records rcvbuf size
> and its usage. The other tracepoint is added to __sk_mem_schedule and
> it records limitations of memory for sockets and current usage.
> 
> By using these tracepoints we're able to know detailed reason why kernel
> drop the packet.
> 
> Signed-off-by: Satoru Moriya <sat...@hd...>
> ---
>  include/trace/events/sock.h |   68 +++++++++++++++++++++++++++++++++++++++++++
>  net/core/net-traces.c       |    1 +
>  net/core/sock.c             |    5 +++
>  3 files changed, 74 insertions(+), 0 deletions(-)
>  create mode 100644 include/trace/events/sock.h
> 
> diff --git a/include/trace/events/sock.h b/include/trace/events/sock.h
> new file mode 100644
> index 0000000..779abb9
> --- /dev/null
> +++ b/include/trace/events/sock.h
> @@ -0,0 +1,68 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM sock
> +
> +#if !defined(_TRACE_SOCK_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_SOCK_H
> +
> +#include <net/sock.h>
> +#include <linux/tracepoint.h>
> +
> +TRACE_EVENT(sock_rcvqueue_full,
> +
> +	TP_PROTO(struct sock *sk, struct sk_buff *skb),
> +
> +	TP_ARGS(sk, skb),
> +
> +	TP_STRUCT__entry(
> +		__field(int, rmem_alloc)
> +		__field(unsigned int, truesize)
> +		__field(int, sk_rcvbuf)
> +	),
> +
> +	TP_fast_assign(
> +		__entry->rmem_alloc = atomic_read(&sk->sk_rmem_alloc);
> +		__entry->truesize   = skb->truesize;
> +		__entry->sk_rcvbuf  = sk->sk_rcvbuf;
> +	),
> +
> +	TP_printk("rmem_alloc=%d truesize=%u sk_rcvbuf=%d",
> +		__entry->rmem_alloc, __entry->truesize, __entry->sk_rcvbuf)
> +);
> +
> +TRACE_EVENT(sock_exceed_buf_limit,
> +
> +	TP_PROTO(struct sock *sk, struct proto *prot, long allocated),
> +
> +	TP_ARGS(sk, prot, allocated),
> +
> +	TP_STRUCT__entry(
> +		__array(char, name, 32)
> +		__field(long *, sysctl_mem)
> +		__field(long, allocated)
> +		__field(int, sysctl_rmem)
> +		__field(int, rmem_alloc)
> +	),
> +
> +	TP_fast_assign(
> +		strncpy(__entry->name, prot->name, 32);
> +		__entry->sysctl_mem = prot->sysctl_mem;
> +		__entry->allocated = allocated;
> +		__entry->sysctl_rmem = prot->sysctl_rmem[0];
> +		__entry->rmem_alloc = atomic_read(&sk->sk_rmem_alloc);
> +	),
> +
> +	TP_printk("proto:%s sysctl_mem=%ld,%ld,%ld allocated=%ld "
> +		"sysctl_rmem=%d rmem_alloc=%d",
> +		__entry->name,
> +		__entry->sysctl_mem[0],
> +		__entry->sysctl_mem[1],
> +		__entry->sysctl_mem[2],
> +		__entry->allocated,
> +		__entry->sysctl_rmem,
> +		__entry->rmem_alloc)
> +);
> +
> +#endif /* _TRACE_SOCK_H */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
> diff --git a/net/core/net-traces.c b/net/core/net-traces.c
> index 13aab64..52380b1 100644
> --- a/net/core/net-traces.c
> +++ b/net/core/net-traces.c
> @@ -28,6 +28,7 @@
>  #include <trace/events/skb.h>
>  #include <trace/events/net.h>
>  #include <trace/events/napi.h>
> +#include <trace/events/sock.h>
>  #include <trace/events/udp.h>
>  
>  EXPORT_TRACEPOINT_SYMBOL_GPL(kfree_skb);
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 6e81978..76c4031 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -128,6 +128,8 @@
>  
>  #include <linux/filter.h>
>  
> +#include <trace/events/sock.h>
> +
>  #ifdef CONFIG_INET
>  #include <net/tcp.h>
>  #endif
> @@ -292,6 +294,7 @@ int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
>  	if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
>  	    (unsigned)sk->sk_rcvbuf) {
>  		atomic_inc(&sk->sk_drops);
> +		trace_sock_rcvqueue_full(sk, skb);
>  		return -ENOMEM;
>  	}
>  
> @@ -1736,6 +1739,8 @@ suppress_allocation:
>  			return 1;
>  	}
>  
> +	trace_sock_exceed_buf_limit(sk, prot, allocated);
> +
>  	/* Alas. Undo changes. */
>  	sk->sk_forward_alloc -= amt * SK_MEM_QUANTUM;
>  	atomic_long_sub(amt, prot->memory_allocated);
> -- 
> 1.7.1
> 
> 
> 
Acked-by: Neil Horman <nh...@tu...>

Re: [Dle-develop] [PATCH 1/2] udp: add tracepoints for queueing skb to rcvbuf

[Neil H. <nh...@tu...>]

On Fri, Jun 17, 2011 at 05:58:39PM -0400, Satoru Moriya wrote:
> This patch adds a tracepoint to __udp_queue_rcv_skb to get the
> return value of ip_queue_rcv_skb. It indicates why kernel drops
> a packet at this point.
> 
> ip_queue_rcv_skb returns following values in the packet drop case:
> 
> rcvbuf is full                 : -ENOMEM
> sk_filter returns error        : -EINVAL, -EACCESS, -ENOMEM, etc.
> __sk_mem_schedule returns error: -ENOBUF
> 
> 
> Signed-off-by: Satoru Moriya <sat...@hd...>
> ---
>  include/trace/events/udp.h |   32 ++++++++++++++++++++++++++++++++
>  net/core/net-traces.c      |    1 +
>  net/ipv4/udp.c             |    2 ++
>  3 files changed, 35 insertions(+), 0 deletions(-)
>  create mode 100644 include/trace/events/udp.h
> 
> diff --git a/include/trace/events/udp.h b/include/trace/events/udp.h
> new file mode 100644
> index 0000000..a664bb9
> --- /dev/null
> +++ b/include/trace/events/udp.h
> @@ -0,0 +1,32 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM udp
> +
> +#if !defined(_TRACE_UDP_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_UDP_H
> +
> +#include <linux/udp.h>
> +#include <linux/tracepoint.h>
> +
> +TRACE_EVENT(udp_fail_queue_rcv_skb,
> +
> +	TP_PROTO(int rc, struct sock *sk),
> +
> +	TP_ARGS(rc, sk),
> +
> +	TP_STRUCT__entry(
> +		__field(int, rc)
> +		__field(__u16, lport)
> +	),
> +
> +	TP_fast_assign(
> +		__entry->rc = rc;
> +		__entry->lport = inet_sk(sk)->inet_num;
> +	),
> +
> +	TP_printk("rc=%d port=%hu", __entry->rc, __entry->lport)
> +);
> +
> +#endif /* _TRACE_UDP_H */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
> diff --git a/net/core/net-traces.c b/net/core/net-traces.c
> index 7f1bb2a..13aab64 100644
> --- a/net/core/net-traces.c
> +++ b/net/core/net-traces.c
> @@ -28,6 +28,7 @@
>  #include <trace/events/skb.h>
>  #include <trace/events/net.h>
>  #include <trace/events/napi.h>
> +#include <trace/events/udp.h>
>  
>  EXPORT_TRACEPOINT_SYMBOL_GPL(kfree_skb);
>  
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index abca870..37aa9bf 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -105,6 +105,7 @@
>  #include <net/route.h>
>  #include <net/checksum.h>
>  #include <net/xfrm.h>
> +#include <trace/events/udp.h>
>  #include "udp_impl.h"
>  
>  struct udp_table udp_table __read_mostly;
> @@ -1363,6 +1364,7 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
>  					 is_udplite);
>  		UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
>  		kfree_skb(skb);
> +		trace_udp_fail_queue_rcv_skb(rc, sk);
>  		return -1;
>  	}
>  
> -- 
> 1.7.1
> 
I was thinking you could just trace callers of __sk_mem_schedule, but looking at
it this works as well
Acked-by: Neil Horman <nh...@tu...>

> 
> 

[Dle-develop] [PATCH 2/2] core: add tracepoints for queueing skb to rcvbuf

[Satoru M. <sat...@hd...>]

This patch adds 2 tracepoints to get a status of a socket receive queue
and related parameter. 

One tracepoint is added to sock_queue_rcv_skb. It records rcvbuf size
and its usage. The other tracepoint is added to __sk_mem_schedule and
it records limitations of memory for sockets and current usage.

By using these tracepoints we're able to know detailed reason why kernel
drop the packet.

Signed-off-by: Satoru Moriya <sat...@hd...>
---
 include/trace/events/sock.h |   68 +++++++++++++++++++++++++++++++++++++++++++
 net/core/net-traces.c       |    1 +
 net/core/sock.c             |    5 +++
 3 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100644 include/trace/events/sock.h

diff --git a/include/trace/events/sock.h b/include/trace/events/sock.h
new file mode 100644
index 0000000..779abb9
--- /dev/null
+++ b/include/trace/events/sock.h
@@ -0,0 +1,68 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM sock
+
+#if !defined(_TRACE_SOCK_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_SOCK_H
+
+#include <net/sock.h>
+#include <linux/tracepoint.h>
+
+TRACE_EVENT(sock_rcvqueue_full,
+
+	TP_PROTO(struct sock *sk, struct sk_buff *skb),
+
+	TP_ARGS(sk, skb),
+
+	TP_STRUCT__entry(
+		__field(int, rmem_alloc)
+		__field(unsigned int, truesize)
+		__field(int, sk_rcvbuf)
+	),
+
+	TP_fast_assign(
+		__entry->rmem_alloc = atomic_read(&sk->sk_rmem_alloc);
+		__entry->truesize   = skb->truesize;
+		__entry->sk_rcvbuf  = sk->sk_rcvbuf;
+	),
+
+	TP_printk("rmem_alloc=%d truesize=%u sk_rcvbuf=%d",
+		__entry->rmem_alloc, __entry->truesize, __entry->sk_rcvbuf)
+);
+
+TRACE_EVENT(sock_exceed_buf_limit,
+
+	TP_PROTO(struct sock *sk, struct proto *prot, long allocated),
+
+	TP_ARGS(sk, prot, allocated),
+
+	TP_STRUCT__entry(
+		__array(char, name, 32)
+		__field(long *, sysctl_mem)
+		__field(long, allocated)
+		__field(int, sysctl_rmem)
+		__field(int, rmem_alloc)
+	),
+
+	TP_fast_assign(
+		strncpy(__entry->name, prot->name, 32);
+		__entry->sysctl_mem = prot->sysctl_mem;
+		__entry->allocated = allocated;
+		__entry->sysctl_rmem = prot->sysctl_rmem[0];
+		__entry->rmem_alloc = atomic_read(&sk->sk_rmem_alloc);
+	),
+
+	TP_printk("proto:%s sysctl_mem=%ld,%ld,%ld allocated=%ld "
+		"sysctl_rmem=%d rmem_alloc=%d",
+		__entry->name,
+		__entry->sysctl_mem[0],
+		__entry->sysctl_mem[1],
+		__entry->sysctl_mem[2],
+		__entry->allocated,
+		__entry->sysctl_rmem,
+		__entry->rmem_alloc)
+);
+
+#endif /* _TRACE_SOCK_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
diff --git a/net/core/net-traces.c b/net/core/net-traces.c
index 13aab64..52380b1 100644
--- a/net/core/net-traces.c
+++ b/net/core/net-traces.c
@@ -28,6 +28,7 @@
 #include <trace/events/skb.h>
 #include <trace/events/net.h>
 #include <trace/events/napi.h>
+#include <trace/events/sock.h>
 #include <trace/events/udp.h>
 
 EXPORT_TRACEPOINT_SYMBOL_GPL(kfree_skb);
diff --git a/net/core/sock.c b/net/core/sock.c
index 6e81978..76c4031 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -128,6 +128,8 @@
 
 #include <linux/filter.h>
 
+#include <trace/events/sock.h>
+
 #ifdef CONFIG_INET
 #include <net/tcp.h>
 #endif
@@ -292,6 +294,7 @@ int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 	if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
 	    (unsigned)sk->sk_rcvbuf) {
 		atomic_inc(&sk->sk_drops);
+		trace_sock_rcvqueue_full(sk, skb);
 		return -ENOMEM;
 	}
 
@@ -1736,6 +1739,8 @@ suppress_allocation:
 			return 1;
 	}
 
+	trace_sock_exceed_buf_limit(sk, prot, allocated);
+
 	/* Alas. Undo changes. */
 	sk->sk_forward_alloc -= amt * SK_MEM_QUANTUM;
 	atomic_long_sub(amt, prot->memory_allocated);
-- 
1.7.1

[Dle-develop] [PATCH 1/2] udp: add tracepoints for queueing skb to rcvbuf

[Satoru M. <sat...@hd...>]

This patch adds a tracepoint to __udp_queue_rcv_skb to get the
return value of ip_queue_rcv_skb. It indicates why kernel drops
a packet at this point.

ip_queue_rcv_skb returns following values in the packet drop case:

rcvbuf is full                 : -ENOMEM
sk_filter returns error        : -EINVAL, -EACCESS, -ENOMEM, etc.
__sk_mem_schedule returns error: -ENOBUF


Signed-off-by: Satoru Moriya <sat...@hd...>
---
 include/trace/events/udp.h |   32 ++++++++++++++++++++++++++++++++
 net/core/net-traces.c      |    1 +
 net/ipv4/udp.c             |    2 ++
 3 files changed, 35 insertions(+), 0 deletions(-)
 create mode 100644 include/trace/events/udp.h

diff --git a/include/trace/events/udp.h b/include/trace/events/udp.h
new file mode 100644
index 0000000..a664bb9
--- /dev/null
+++ b/include/trace/events/udp.h
@@ -0,0 +1,32 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM udp
+
+#if !defined(_TRACE_UDP_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_UDP_H
+
+#include <linux/udp.h>
+#include <linux/tracepoint.h>
+
+TRACE_EVENT(udp_fail_queue_rcv_skb,
+
+	TP_PROTO(int rc, struct sock *sk),
+
+	TP_ARGS(rc, sk),
+
+	TP_STRUCT__entry(
+		__field(int, rc)
+		__field(__u16, lport)
+	),
+
+	TP_fast_assign(
+		__entry->rc = rc;
+		__entry->lport = inet_sk(sk)->inet_num;
+	),
+
+	TP_printk("rc=%d port=%hu", __entry->rc, __entry->lport)
+);
+
+#endif /* _TRACE_UDP_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
diff --git a/net/core/net-traces.c b/net/core/net-traces.c
index 7f1bb2a..13aab64 100644
--- a/net/core/net-traces.c
+++ b/net/core/net-traces.c
@@ -28,6 +28,7 @@
 #include <trace/events/skb.h>
 #include <trace/events/net.h>
 #include <trace/events/napi.h>
+#include <trace/events/udp.h>
 
 EXPORT_TRACEPOINT_SYMBOL_GPL(kfree_skb);
 
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index abca870..37aa9bf 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -105,6 +105,7 @@
 #include <net/route.h>
 #include <net/checksum.h>
 #include <net/xfrm.h>
+#include <trace/events/udp.h>
 #include "udp_impl.h"
 
 struct udp_table udp_table __read_mostly;
@@ -1363,6 +1364,7 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 					 is_udplite);
 		UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
 		kfree_skb(skb);
+		trace_udp_fail_queue_rcv_skb(rc, sk);
 		return -1;
 	}
 
-- 
1.7.1

[Dle-develop] [PATCH 0/2] Tracepoints for queueing skb to rcvbuf

[Satoru M. <sat...@hd...>]

Hi,

Kernel may drops packets when it queues them to socket receive buffer. 
Currently We can detect packet drop events and know when and where it
happened via kfree_skb tracepoint. But it's difficult to know a detailed
reason because there are some possibilities. 

In UDP case, core function for queueing skb to socket rcvbuf is 
__udp_queue_rcv_skb and its call chain is following:

__udp_queue_rcv_skb
 ip_queue_rcv_skb
  sock_queue_rcv_skb
   sk_rmem_schedule
    __sk_mem_schedule

We can catch a packet drop event in __udp_queue_rcv_skb and it means
ip_queue_rcv_skb/sock_queue_rcv_skb returned negative value.
In sock_queue_rcv_skb there are 3 possibilities-(*) where it returns
negative value but we can't separate them. Moreover sock_queue_rcv_skb calls
__sk_mem_schedule and there are several if satetements to decide whether
kernel should drop the packet.

To separate these reasons, this patchset adds 3 tracepoints.

1st one is added to __udp_queue_rcv_skb to get return value of
ip_queue_rcv_skb. Analyzing it we can separate above (*) (3 possibilities).

2nd and 3rd one are to get more detailed information. We can collect status 
of socket receive queue and related parameters(some of them are sysctl knob
e.g. /proc/sys/net/ipv4/udp_mem, etc. for UDP) and then we can tune kernel
behavior easily.

Any comments and feedback are welcome.


Satoru Moriya (2):
  udp: add tracepoint for queueing skb to rcvbuf
  core: add tracepoints for queueing skb to rcvbuf

 include/trace/events/sock.h |   68 +++++++++++++++++++++++++++++++++++++++++++
 include/trace/events/udp.h  |   32 ++++++++++++++++++++
 net/core/net-traces.c       |    2 +
 net/core/sock.c             |    5 +++
 net/ipv4/udp.c              |    2 +
 5 files changed, 109 insertions(+), 0 deletions(-)
 create mode 100644 include/trace/events/sock.h
 create mode 100644 include/trace/events/udp.h

[Dle-develop] PATCH 0/2] Tracepoints for queueing skb to rcvbuf

[Satoru M. <sat...@hd...>]

Hi,

Kernel may drops packets when it queues them to socket receive buffer.
Currently We can detect packet drop events and know when and where it
happened via kfree_skb tracepoint. But it's difficult to know a detailed
reason because there are some possibilities.

In UDP case, core function for queueing skb to socket rcvbuf is
__udp_queue_rcv_skb and its call chain is following:

__udp_queue_rcv_skb
 ip_queue_rcv_skb
  sock_queue_rcv_skb
   sk_rmem_schedule
    __sk_mem_schedule

We can catch a packet drop event in __udp_queue_rcv_skb and it means
ip_queue_rcv_skb/sock_queue_rcv_skb returned negative value.
In sock_queue_rcv_skb there are 3 possibilities-(*) where it returns
negative value but we can't separate them. Moreover sock_queue_rcv_skb calls
__sk_mem_schedule and there are several if satetements to decide whether
kernel should drop the packet.

To separate these reasons, this patchset adds 3 tracepoints.

1st one is added to __udp_queue_rcv_skb to get return value of
ip_queue_rcv_skb. Analyzing it we can separate above (*) (3 possibilities).

2nd and 3rd one are to get more detailed information. We can collect status
of socket receive queue and related parameters(some of them are sysctl knob
e.g. /proc/sys/net/ipv4/udp_mem, etc. for UDP) and then we can tune kernel
behavior easily.

Any comments and feedback are welcome.


Satoru Moriya (2):
  udp: add tracepoint for queueing skb to rcvbuf
  core: add tracepoints for queueing skb to rcvbuf

 include/trace/events/sock.h |   68 +++++++++++++++++++++++++++++++++++++++++++
 include/trace/events/udp.h  |   32 ++++++++++++++++++++
 net/core/net-traces.c       |    2 +
 net/core/sock.c             |    5 +++
 net/ipv4/udp.c              |    2 +
 5 files changed, 109 insertions(+), 0 deletions(-)
 create mode 100644 include/trace/events/sock.h
 create mode 100644 include/trace/events/udp.h

Re: [Dle-develop] [RFC][PATCH] add tracepoint to __sk_mem_schedule

[Satoru M. <sat...@hd...>]

On 06/15/2011 04:04 PM, Neil Horman wrote:
> On Wed, Jun 15, 2011 at 03:18:09PM -0400, Satoru Moriya wrote:
>
>> Right. We can catch packet drop events via dropwatch/kfree_skb tracepoint.
>> OTOH, what I'd like to know is why kernel dropped packets. Basically,
>> we're able to know the reason because kfree_skb tracepoint records its
>> return address. But in this case it is difficult to know a detailed reason
>> because there are some possibilities. I'll try to explain UDP case.
> Ok, but you're patch only gets us incrmentally closer to that goal.  You can
> tell if theres too much memory pressue to accept another packet on a socket, but
> it doesn't tell you if for instance if sk_filter indicated an error, or
> something else failed.  In short it sounds to me like you're trying to debug a
> specific problem, rather than add something generally useful.

You're right.

>> As you said, we're able to catch the packet drop in __udp_queue_rcv_skb
>> and it means ip_queue_rcv_skb/sock_queue_rcv_skb returned negative value.
>> In sock_queue_rcv_skb there are 3 possibilities where it returns nagative
>> val but we can't separate them from the kfree_skb tracepoint. Moreover
> This is true, but you're patch doesn't do that either (not that either feature
> holds that as a specific goal).

Right.

> 
>> sock_queue_rcv_skb calls __sk_mem_schedule and there are several
>> if-statement to decide whether kernel should drop a packet in it. I'd like
>> to know the condition when it returned error because some of them are
>> related to sysctl knob e.g. /proc/sys/net/ipv4/udp_mem, udp_rmem_min,
>> udp_wmem_min for UDP case and we can tune kernel behavior easily.
>> Also they are needed to show root cause of packet drop to our customers.
>>
>> Does it make sense?
>>
> Yes, it makes sense, but I think the patch could be made generally more useful.

OK. I'll update my patch to make it more useful.

Thanks,
Satoru

Re: [Dle-develop] [RFC][PATCH] add tracepoint to __sk_mem_schedule

[Neil H. <nh...@tu...>]

On Wed, Jun 15, 2011 at 03:18:09PM -0400, Satoru Moriya wrote:
> Hi Neil,
> 
> Thank you for looking at it.
> I'm afraid that my explanation was not enough.
> 
> On 06/15/2011 07:07 AM, Neil Horman wrote:
> > On Tue, Jun 14, 2011 at 03:24:14PM -0400, Satoru Moriya wrote:
> >
> > There are several ways to do this already.  Every drop that occurs in the stack
> > should have a corresponding statistical counter exposed for it, and we also have
> > a tracepoint in kfree_skb that the dropwatch system monitors to inform us of
> > dropped packets in a certralized fashion.  Not saying this tracepoint isn't
> > worthwhile, only that it covers already covered ground.
> 
> Right. We can catch packet drop events via dropwatch/kfree_skb tracepoint.
> OTOH, what I'd like to know is why kernel dropped packets. Basically,
> we're able to know the reason because kfree_skb tracepoint records its
> return address. But in this case it is difficult to know a detailed reason
> because there are some possibilities. I'll try to explain UDP case.
Ok, but you're patch only gets us incrmentally closer to that goal.  You can
tell if theres too much memory pressue to accept another packet on a socket, but
it doesn't tell you if for instance if sk_filter indicated an error, or
something else failed.  In short it sounds to me like you're trying to debug a
specific problem, rather than add something generally useful.

> 
> > Again, this is why dropwatch exists.  UDP gets into this path from:
> > __udp_queue_rcv_skb
> >  ip_queue_rcv_skb
> >   sock_queue_rcv_skb
> >    sk_rmem_schedule
> >     __sk_mem_schedule
> > 
> > If ip_queue_rcv_skb fails we increment the UDP_MIB_RCVBUFERRORS counter as well
> > as the UDP_MIB_INERRORS counter, and on the kfree_skb call after those
> > increments, dropwatch will report the frame loss and the fact that it occured in
> > __udp_queue_rcv_skb
> 
> As you said, we're able to catch the packet drop in __udp_queue_rcv_skb
> and it means ip_queue_rcv_skb/sock_queue_rcv_skb returned negative value.
> In sock_queue_rcv_skb there are 3 possibilities where it returns nagative
> val but we can't separate them from the kfree_skb tracepoint. Moreover
This is true, but you're patch doesn't do that either (not that either feature
holds that as a specific goal).

> sock_queue_rcv_skb calls __sk_mem_schedule and there are several
> if-statement to decide whether kernel should drop a packet in it. I'd like
> to know the condition when it returned error because some of them are
> related to sysctl knob e.g. /proc/sys/net/ipv4/udp_mem, udp_rmem_min,
> udp_wmem_min for UDP case and we can tune kernel behavior easily.
> Also they are needed to show root cause of packet drop to our customers.
> 
> Does it make sense?
> 
Yes, it makes sense, but I think the patch could be made generally more useful.

> > I still think its an interesting tracepoint, just because it might be nice to
> > know which sockets are expanding their snd/rcv buffer space, but why not modify
> > the tracepoint so that it accepts the return code of __sk_mem_schedule and call
> > it from both sk_rmem_schedule and sk_wmem_schedule.   That way you can use the
> > tracepoint to record both successfull expansion and failed expansions.
> 
> It may be good but not enough for me as I mentioned above.
> 
> 
> Regards,
> Satoru--
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to maj...@vg...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [Dle-develop] [RFC][PATCH] add tracepoint to __sk_mem_schedule

[Satoru M. <sat...@hd...>]

Hi Neil,

Thank you for looking at it.
I'm afraid that my explanation was not enough.

On 06/15/2011 07:07 AM, Neil Horman wrote:
> On Tue, Jun 14, 2011 at 03:24:14PM -0400, Satoru Moriya wrote:
>
> There are several ways to do this already.  Every drop that occurs in the stack
> should have a corresponding statistical counter exposed for it, and we also have
> a tracepoint in kfree_skb that the dropwatch system monitors to inform us of
> dropped packets in a certralized fashion.  Not saying this tracepoint isn't
> worthwhile, only that it covers already covered ground.

Right. We can catch packet drop events via dropwatch/kfree_skb tracepoint.
OTOH, what I'd like to know is why kernel dropped packets. Basically,
we're able to know the reason because kfree_skb tracepoint records its
return address. But in this case it is difficult to know a detailed reason
because there are some possibilities. I'll try to explain UDP case.

> Again, this is why dropwatch exists.  UDP gets into this path from:
> __udp_queue_rcv_skb
>  ip_queue_rcv_skb
>   sock_queue_rcv_skb
>    sk_rmem_schedule
>     __sk_mem_schedule
> 
> If ip_queue_rcv_skb fails we increment the UDP_MIB_RCVBUFERRORS counter as well
> as the UDP_MIB_INERRORS counter, and on the kfree_skb call after those
> increments, dropwatch will report the frame loss and the fact that it occured in
> __udp_queue_rcv_skb

As you said, we're able to catch the packet drop in __udp_queue_rcv_skb
and it means ip_queue_rcv_skb/sock_queue_rcv_skb returned negative value.
In sock_queue_rcv_skb there are 3 possibilities where it returns nagative
val but we can't separate them from the kfree_skb tracepoint. Moreover
sock_queue_rcv_skb calls __sk_mem_schedule and there are several
if-statement to decide whether kernel should drop a packet in it. I'd like
to know the condition when it returned error because some of them are
related to sysctl knob e.g. /proc/sys/net/ipv4/udp_mem, udp_rmem_min,
udp_wmem_min for UDP case and we can tune kernel behavior easily.
Also they are needed to show root cause of packet drop to our customers.

Does it make sense?

> I still think its an interesting tracepoint, just because it might be nice to
> know which sockets are expanding their snd/rcv buffer space, but why not modify
> the tracepoint so that it accepts the return code of __sk_mem_schedule and call
> it from both sk_rmem_schedule and sk_wmem_schedule.   That way you can use the
> tracepoint to record both successfull expansion and failed expansions.

It may be good but not enough for me as I mentioned above.


Regards,
Satoru

Re: [Dle-develop] [RFC][PATCH] add tracepoint to __sk_mem_schedule

[Neil H. <nh...@tu...>]

On Tue, Jun 14, 2011 at 03:24:14PM -0400, Satoru Moriya wrote:
> Hi,
> 
> kernel drops packets when the amount of memory which is used for socket buffer
> exceeds limitations such as /proc/sys/net/ipv4/udp_mem. But currently we can't
> catch that event and know why packets are dropped. And also it is difficult to
> configure sysctl knob appropriately because we don't know when/why packets
> dropped.
> 
There are several ways to do this already.  Every drop that occurs in the stack
should have a corresponding statistical counter exposed for it, and we also have
a tracepoint in kfree_skb that the dropwatch system monitors to inform us of
dropped packets in a certralized fashion.  Not saying this tracepoint isn't
worthwhile, only that it covers already covered ground.

> This patch adds tracepoint to __sk_mem_schedule(), which is called each time
> the socket memory usage exceeds limitations and kernel drops a packet.
> It allows us to hook in and examine when and why it happens.
> 
> Note that this patch only collects information which is needed for udp
> because it's a RFC patch to show its concept and acutually we need it(*).
> If you guys need to get other parameters, please let me know. I'll add it.
> 
> (*) Reason why we need this tracepoint for UDP
> Transaction data is sent by UDP multicast in finance systems because of its
> low overhead characteristics. UDP itself does not guarantee reliability,
> ordering and data integrity, but the system is designed not to drop any packets
> even when it is high load situation. And in that system if kernel drops packets,
> we need to find a root cause to avoid it next time.
> 
Again, this is why dropwatch exists.  UDP gets into this path from:
__udp_queue_rcv_skb
 ip_queue_rcv_skb
  sock_queue_rcv_skb
   sk_rmem_schedule
    __sk_mem_schedule

If ip_queue_rcv_skb fails we increment the UDP_MIB_RCVBUFERRORS counter as well
as the UDP_MIB_INERRORS counter, and on the kfree_skb call after those
increments, dropwatch will report the frame loss and the fact that it occured in
__udp_queue_rcv_skb

I still think its an interesting tracepoint, just because it might be nice to
know which sockets are expanding their snd/rcv buffer space, but why not modify
the tracepoint so that it accepts the return code of __sk_mem_schedule and call
it from both sk_rmem_schedule and sk_wmem_schedule.   That way you can use the
tracepoint to record both successfull expansion and failed expansions.
Neil
 
> Any comments are welcome.
> 
> Signed-off-by: Satoru Moriya <sat...@hd...>
> ---
>  include/trace/events/sock.h |   46 +++++++++++++++++++++++++++++++++++++++++++
>  net/core/net-traces.c       |    1 +
>  net/core/sock.c             |    4 +++
>  3 files changed, 51 insertions(+), 0 deletions(-)
>  create mode 100644 include/trace/events/sock.h
> 
> diff --git a/include/trace/events/sock.h b/include/trace/events/sock.h
> new file mode 100644
> index 0000000..409735a
> --- /dev/null
> +++ b/include/trace/events/sock.h
> @@ -0,0 +1,46 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM sock
> +
> +#if !defined(_TRACE_SOCK_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_SOCK_H
> +
> +#include <net/sock.h>
> +#include <linux/tracepoint.h>
> +
> +TRACE_EVENT(sock_exceed_buf_limit,
> +
> +	TP_PROTO(struct sock *sk, struct proto *prot, long allocated),
> +
> +	TP_ARGS(sk, prot, allocated),
> +
> +	TP_STRUCT__entry(
> +		__array(char, name, 32)
> +		__field(long *, sysctl_mem)
> +		__field(long, allocated)
> +		__field(int, sysctl_rmem)
> +		__field(int, rmem_alloc)
> +	),
> +
> +	TP_fast_assign(
> +		strncpy(__entry->name, prot->name, 32);
> +		__entry->sysctl_mem = prot->sysctl_mem;
> +		__entry->allocated = allocated;
> +		__entry->sysctl_rmem = atomic_read(&sk->sk_rmem_alloc);
> +		__entry->rmem_alloc = prot->sysctl_rmem[0];
> +	),
> +
> +	TP_printk("proto:%s sysctl_mem=%ld,%ld,%ld allocated=%ld "
> +		"sysctl_rmem=%d rmem_alloc=%d",
> +		__entry->name,
> +		__entry->sysctl_mem[0],
> +		__entry->sysctl_mem[1],
> +		__entry->sysctl_mem[2],
> +		__entry->allocated,
> +		__entry->sysctl_rmem,
> +		__entry->rmem_alloc)
> +);
> +
> +#endif /* _TRACE_SOCK_H */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
> diff --git a/net/core/net-traces.c b/net/core/net-traces.c
> index 7f1bb2a..b9756f5 100644
> --- a/net/core/net-traces.c
> +++ b/net/core/net-traces.c
> @@ -28,6 +28,7 @@
>  #include <trace/events/skb.h>
>  #include <trace/events/net.h>
>  #include <trace/events/napi.h>
> +#include <trace/events/sock.h>
>  
>  EXPORT_TRACEPOINT_SYMBOL_GPL(kfree_skb);
>  
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 6e81978..8389032 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -128,6 +128,8 @@
>  
>  #include <linux/filter.h>
>  
> +#include <trace/events/sock.h>
> +
>  #ifdef CONFIG_INET
>  #include <net/tcp.h>
>  #endif
> @@ -1736,6 +1738,8 @@ suppress_allocation:
>  			return 1;
>  	}
>  
> +	trace_sock_exceed_buf_limit(sk, prot, allocated);
> +
>  	/* Alas. Undo changes. */
>  	sk->sk_forward_alloc -= amt * SK_MEM_QUANTUM;
>  	atomic_long_sub(amt, prot->memory_allocated);
> -- 
> 1.7.1
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to maj...@vg...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[Dle-develop] [RFC][PATCH] add tracepoint to __sk_mem_schedule

[Satoru M. <sat...@hd...>]

Hi,

kernel drops packets when the amount of memory which is used for socket buffer
exceeds limitations such as /proc/sys/net/ipv4/udp_mem. But currently we can't
catch that event and know why packets are dropped. And also it is difficult to
configure sysctl knob appropriately because we don't know when/why packets
dropped.

This patch adds tracepoint to __sk_mem_schedule(), which is called each time
the socket memory usage exceeds limitations and kernel drops a packet.
It allows us to hook in and examine when and why it happens.

Note that this patch only collects information which is needed for udp
because it's a RFC patch to show its concept and acutually we need it(*).
If you guys need to get other parameters, please let me know. I'll add it.

(*) Reason why we need this tracepoint for UDP
Transaction data is sent by UDP multicast in finance systems because of its
low overhead characteristics. UDP itself does not guarantee reliability,
ordering and data integrity, but the system is designed not to drop any packets
even when it is high load situation. And in that system if kernel drops packets,
we need to find a root cause to avoid it next time.

Any comments are welcome.

Signed-off-by: Satoru Moriya <sat...@hd...>
---
 include/trace/events/sock.h |   46 +++++++++++++++++++++++++++++++++++++++++++
 net/core/net-traces.c       |    1 +
 net/core/sock.c             |    4 +++
 3 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100644 include/trace/events/sock.h

diff --git a/include/trace/events/sock.h b/include/trace/events/sock.h
new file mode 100644
index 0000000..409735a
--- /dev/null
+++ b/include/trace/events/sock.h
@@ -0,0 +1,46 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM sock
+
+#if !defined(_TRACE_SOCK_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_SOCK_H
+
+#include <net/sock.h>
+#include <linux/tracepoint.h>
+
+TRACE_EVENT(sock_exceed_buf_limit,
+
+	TP_PROTO(struct sock *sk, struct proto *prot, long allocated),
+
+	TP_ARGS(sk, prot, allocated),
+
+	TP_STRUCT__entry(
+		__array(char, name, 32)
+		__field(long *, sysctl_mem)
+		__field(long, allocated)
+		__field(int, sysctl_rmem)
+		__field(int, rmem_alloc)
+	),
+
+	TP_fast_assign(
+		strncpy(__entry->name, prot->name, 32);
+		__entry->sysctl_mem = prot->sysctl_mem;
+		__entry->allocated = allocated;
+		__entry->sysctl_rmem = atomic_read(&sk->sk_rmem_alloc);
+		__entry->rmem_alloc = prot->sysctl_rmem[0];
+	),
+
+	TP_printk("proto:%s sysctl_mem=%ld,%ld,%ld allocated=%ld "
+		"sysctl_rmem=%d rmem_alloc=%d",
+		__entry->name,
+		__entry->sysctl_mem[0],
+		__entry->sysctl_mem[1],
+		__entry->sysctl_mem[2],
+		__entry->allocated,
+		__entry->sysctl_rmem,
+		__entry->rmem_alloc)
+);
+
+#endif /* _TRACE_SOCK_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
diff --git a/net/core/net-traces.c b/net/core/net-traces.c
index 7f1bb2a..b9756f5 100644
--- a/net/core/net-traces.c
+++ b/net/core/net-traces.c
@@ -28,6 +28,7 @@
 #include <trace/events/skb.h>
 #include <trace/events/net.h>
 #include <trace/events/napi.h>
+#include <trace/events/sock.h>
 
 EXPORT_TRACEPOINT_SYMBOL_GPL(kfree_skb);
 
diff --git a/net/core/sock.c b/net/core/sock.c
index 6e81978..8389032 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -128,6 +128,8 @@
 
 #include <linux/filter.h>
 
+#include <trace/events/sock.h>
+
 #ifdef CONFIG_INET
 #include <net/tcp.h>
 #endif
@@ -1736,6 +1738,8 @@ suppress_allocation:
 			return 1;
 	}
 
+	trace_sock_exceed_buf_limit(sk, prot, allocated);
+
 	/* Alas. Undo changes. */
 	sk->sk_forward_alloc -= amt * SK_MEM_QUANTUM;
 	atomic_long_sub(amt, prot->memory_allocated);
-- 
1.7.1

[Dle-develop] British Chambers of Commerce Email: Strike action in current economic climate misguided

[<ann...@gm...>]

Hello,

My name is Anna Desmond, I saw your profile today through the help of chamber of commerce in Bamako the capital of Mali) and became interested in you, I will also like to know you the more,and I want you to send an email to my email address so I can give you my picture for you to know whom i am. Please i am waiting for your mail reply urgently. Remember that distance or color does not matter but love matters a lot in life

Best regards

Anna Desmond

Miss Anna Desmond saw this article on British Chambers of Commerce and thought you should see it.

Strike action in current economic climate misguided
Commenting on the decision by Council workers to hold walkouts in a dispute over pay
http://www.britishchambers.org.uk/zones/policy/press-releases_1/strike-action-in-current-economic-climate-misguided.html

Re: [Dle-develop] [PATCH][BUGFIX] param: fix return value handling in param_set_*

[Rusty R. <ru...@ru...>]

On Thu, 26 May 2011 19:38:04 -0400, Satoru Moriya <sat...@hd...> wrote:
> In STANDARD_PARAM_DEF, param_set_* handles the case in which strtolfn
> returns -EINVAL but it may return -ERANGE. If it returns -ERANGE,
> param_set_* may set uninitialized value to the paramerter. We should handle
> both cases.
> 
> The one of the cases in which strtolfn() returns -ERANGE is following:
> 
>  *Type of module parameter is long
>  *Set the parameter more than LONG_MAX
> 
> Signed-off-by: Satoru Moriya <sat...@hd...>

Thanks, applied.

Cheers,
Rusty.

[Dle-develop] 地

[n. <neg...@to...>]

   358567842h下载最快？不回复我现；耽!棉的好?会送票。付强回本溪殂在沈站，永大三角框架纫专x业n快d速t操j作z真p实n上d网tj业z讠正，{学p信f网v可l查},  及c各si资y格o讠正e。硕u士kaqg位w讠正m和csi外yoeu讠正！永k久a有q效g可w查，联m系k人：李a老q师 QhQ:9722728299569723  Exmail: 553305993491972272829+qq.com N情D加TQJ了Z解！ 程德海?通辽市大全不够以后使用情况跟帖！本人身份印件、用写没有化李君看病我拟!记没有票你?些余额，工芦大.年薪有一无限；    

[Dle-develop] [PATCH][BUGFIX] param: fix return value handling in param_set_*

[Satoru M. <sat...@hd...>]

In STANDARD_PARAM_DEF, param_set_* handles the case in which strtolfn
returns -EINVAL but it may return -ERANGE. If it returns -ERANGE,
param_set_* may set uninitialized value to the paramerter. We should handle
both cases.

The one of the cases in which strtolfn() returns -ERANGE is following:

 *Type of module parameter is long
 *Set the parameter more than LONG_MAX

Signed-off-by: Satoru Moriya <sat...@hd...>
---
 kernel/params.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/params.c b/kernel/params.c
index ed72e13..2a4ba25 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -225,8 +225,8 @@ int parse_args(const char *name,
 		int ret;						\
 									\
 		ret = strtolfn(val, 0, &l);				\
-		if (ret == -EINVAL || ((type)l != l))			\
-			return -EINVAL;					\
+		if (ret < 0 || ((type)l != l))				\
+			return ret < 0 ? ret : -EINVAL;			\
 		*((type *)kp->arg) = l;					\
 		return 0;						\
 	}

[Dle-develop] Tunable watermark systemtap script version

[Satoru M. <sat...@hd...>]

Hi,

This script create the module which provides the same functions
as tunable watermark. We can set watermark_low and watermark_high
by using this module.

For more details, please see README in tarball.

Regards,
Satoru

[Dle-develop] Tunable watermark module version

[Satoru M. <sat...@hd...>]

Hi,

This module provides the same functions as tunable watermark.
We can set watermark_low and watermark_high separately
by using this module.

For more details, please see README in tarball.

Regards,
Satoru

Re: [Dle-develop] [RFC][PATCH] pstore: EFI Support

[Matthew G. <mj...@sr...>]

On Wed, May 11, 2011 at 07:27:46AM -0700, H. Peter Anvin wrote:
> On 05/11/2011 06:09 AM, Américo Wang wrote:
> >I agree. It seems that we should enable this by default when APEI and
> >EFI are both enabled, this could be done by Kconfig.
> >
> 
> No, it can't.  That would be a compile-time option, but the
> selection needs to be at runtime.
> 
> However, it is still unclear that this is actually a win at all...

It's a win in that not all EFI platforms are ACPI. I don't think we're 
yet in a position to say which is preferable when we have both.

(Are we really arguing over which broken Intel firmware spec is less 
broken than the other?)

-- 
Matthew Garrett | mj...@sr...

Re: [Dle-develop] [RFC][PATCH] pstore: EFI Support

[H. P. A. <hp...@zy...>]

On 05/11/2011 06:09 AM, Américo Wang wrote:
> On Wed, May 11, 2011 at 12:11 AM, Greg KH<gr...@kr...>  wrote:
>> On Tue, May 10, 2011 at 11:00:44AM -0400, Seiji Aguchi wrote:
>>> Description of boot paremeters is following.
>>>
>>>   - efi_pstore_enable
>>>     enable EFI support of pstore.
>>>
>>>   - efi_pstore_len
>>>     Sets the buffer size of EFI variable space used by pstore.
>>
>> Please don't add new boot parameters if at all possible.  Distros will
>> not know to enable them, and users don't know how to either.
>>
>> Use sane defaults, and provide ways to override them if needed, but
>> don't rely on them for new functionality if at all possible.
>
> I agree. It seems that we should enable this by default when APEI and
> EFI are both enabled, this could be done by Kconfig.
>

No, it can't.  That would be a compile-time option, but the selection 
needs to be at runtime.

However, it is still unclear that this is actually a win at all...

	-hpa

Re: [Dle-develop] [RFC][PATCH] pstore: EFI Support

[Américo W. <xiy...@gm...>]

On Wed, May 11, 2011 at 12:11 AM, Greg KH <gr...@kr...> wrote:
> On Tue, May 10, 2011 at 11:00:44AM -0400, Seiji Aguchi wrote:
>> Description of boot paremeters is following.
>>
>>  - efi_pstore_enable
>>    enable EFI support of pstore.
>>
>>  - efi_pstore_len
>>    Sets the buffer size of EFI variable space used by pstore.
>
> Please don't add new boot parameters if at all possible.  Distros will
> not know to enable them, and users don't know how to either.
>
> Use sane defaults, and provide ways to override them if needed, but
> don't rely on them for new functionality if at all possible.

I agree. It seems that we should enable this by default when APEI and
EFI are both enabled, this could be done by Kconfig.

Thanks.

Re: [Dle-develop] [RFC][PATCH] pstore: EFI Support

[Luck, T. <ton...@in...>]

> I would appreciate it if you could review usage of pstore on this patch.

There is an "in flight" set of patches to pstore posted by Chen Gong that
add "open" and "close" operations to the pstore interface (to fix issues with
remounting pstore - we need a way to let the underlying persistent store know
that we want to rescan all the entries).  So you should look at that and take
it into account.

-Tony