public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox