All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Helsley <matthltc@us.ibm.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	Guillaume Thouvenin <guillaume.thouvenin@bull.net>
Subject: [RFC][PATCH 2/3] Process events biarch bug: Process events  timestamp bug
Date: Tue, 27 Jun 2006 04:48:46 -0700	[thread overview]
Message-ID: <1151408926.21787.1812.camel@stark> (raw)
In-Reply-To: 20060627112644.804066367@localhost.localdomain

The event sent by Process Events from a 64-bit kernel is not compatible with
what a 32-bit userspace program would expect to recieve because the timespec
struct (used to send a timestamp) is not the same. This means that fields stored
after the timestamp are offset and programs that don't take this into account
break under these circumstances.

This is a problem on ppc64, s390, x86-64.. any "biarch" system where it's
possible for a 64-bit kernel to run 32-bit userspace programs.

This patch adds a comment highlighting the problem and a Documentation file
showing a userspace workaround.

Signed-off-by: Matt Helsley <matthltc@us.ibm.com>
---
 Documentation/connector/process_events.txt |   75 +++++++++++++++++++++++++++++
 drivers/connector/Kconfig                  |    3 +
 include/linux/cn_proc.h                    |    7 ++
 3 files changed, 85 insertions(+)

Index: linux-2.6.17-mm3-biarch/include/linux/cn_proc.h
===================================================================
--- linux-2.6.17-mm3-biarch.orig/include/linux/cn_proc.h
+++ linux-2.6.17-mm3-biarch/include/linux/cn_proc.h
@@ -55,11 +55,18 @@ struct proc_event {
 		/* "next" should be 0x00000400 */
 		/* "last" is the last process event: exit */
 		PROC_EVENT_EXIT = 0x80000000
 	} what;
 	__u32 cpu;
+
+ 	/*
+ 	 * UGH! timespec is biarch incompatible. See
+ 	 * Documentation/connector/process_events.txt if you're going to listen
+ 	 * for process events in userspace.
+ 	 */
 	struct timespec timestamp;
+
 	union process_event_data { /* must be last field of proc_event struct */
 		struct {
 			__u32 err;
 		} ack;
 
Index: linux-2.6.17-mm3-biarch/Documentation/connector/process_events.txt
===================================================================
--- /dev/null
+++ linux-2.6.17-mm3-biarch/Documentation/connector/process_events.txt
@@ -0,0 +1,75 @@
+NOTES:
+
+To safely use process events on biarch systems it's necessary to account for
+the difference in size of the events returned by 64-bit kernels to 32-bit
+applications. This size difference is caused by use of a struct timespec for
+the timestamp field.
+
+There are multiple ways of doing this. However, few of them account for the
+fact that the size of the process event structure may change in the future.
+
+#include "linux/cn_proc.h"
+
+{
+	...
+	struct process_event *ev;
+	union process_event_data *evdata;
+	struct timespec ts;
+
+	ev = cn_msg->data;
+	if ((cn_msg->len - sizeof(struct process_event)) == sizeof(__u64)) {
+		__u64 *v;
+
+		/* kernel is sending 64-bit timestamps to 32-bit userspace */
+
+		v = (*__u64)&ev->timestamp;
+		ts.tv_sec = *v;
+		v++;
+		ts.tv_nsec = *v;
+		v++;
+		evdata = (union process_event_data*)v;
+	} else {
+		evdata = &ev->event_data;
+		ts = ev->timestamp;
+	}
+
+	switch(ev->what) {
+	case PROCESS_EVENT_EXIT:
+		... evdata->exit.exit_code ...
+		break;
+	}
+}
+
+Alternately, you can compare the size of the message length to the known
+size of the two structure variations and thus determine which structure to
+use to access the data:
+
+struct pev32 {
+	enum what what;
+	__u32 cpu;
+	__u32 timestamp[2];
+	union process_event_data event_data;
+};
+
+struct pev64 {
+	enum what what;
+	__u32 cpu;
+	__u64 timestamp[2];
+	union process_event_data event_data;
+};
+
+...
+if (cn_msg->len == sizeof(struct pev64)) {
+	...
+} else if (cn_msg->len == sizeof(struct pev32)) {
+	...
+}
+
+Both approaches assume that the process events structure will never change
+size.
+
+To limit the number of times you need to test which format is being sent use
+the acknowledgement message returned by the kernel after sending
+PROC_CN_MCAST_LISTEN. Use any of the techniques described above on the
+acknowledgement message and then set function pointers, flags, etc. to avoid
+the test in the future.
Index: linux-2.6.17-mm3-biarch/drivers/connector/Kconfig
===================================================================
--- linux-2.6.17-mm3-biarch.orig/drivers/connector/Kconfig
+++ linux-2.6.17-mm3-biarch/drivers/connector/Kconfig
@@ -16,6 +16,9 @@ config PROC_EVENTS
 	depends on CONNECTOR
 	help
 	  Provide a connector that reports process events to userspace. Send
 	  events such as fork, exec, id change (uid, gid, suid, etc), and exit.
 
+	  See Documentation/connector/process_events.txt if you're going to
+	  listen for process events in userspace.
+
 endmenu

--


  parent reply	other threads:[~2006-06-27 11:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060627112644.804066367@localhost.localdomain>
2006-06-27 11:47 ` [RFC][PATCH 1/3] Process events biarch bug: Name process event data union type and annotate for compatibility Matt Helsley
2006-06-27 11:48 ` Matt Helsley [this message]
2006-06-27 11:49 ` [RFC][PATCH 3/3] Process events biarch bug: New process events connector value Matt Helsley
2006-06-27 19:14   ` Chandra Seetharaman
2006-06-27 21:39     ` Matt Helsley
2006-06-27 23:54       ` Chandra Seetharaman
2006-06-28  1:29         ` Matt Helsley
2006-06-28  5:53       ` Evgeniy Polyakov
2006-06-30  8:46         ` Evgeniy Polyakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1151408926.21787.1812.camel@stark \
    --to=matthltc@us.ibm.com \
    --cc=guillaume.thouvenin@bull.net \
    --cc=johnpol@2ka.mipt.ru \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.