OK, I think I know what is going on here. The following kernel commit changed the sk_buff structure:

====
commit bffa72cf7f9df842f0016ba03586039296b4caaf
Author: Eric Dumazet <edumazet>
Date:   Tue Sep 19 05:14:24 2017 -0700

    net: sk_buff rbnode reorg
    
    skb->rbnode shares space with skb->next, skb->prev and skb->tstamp
====

The sk_buff structure now looks like this:

====
struct sk_buff {
	union {
		struct {
			/* These two members must be first. */
			struct sk_buff		*next;
			struct sk_buff		*prev;

			union {
				struct net_device	*dev;
				/* Some protocols might use this space to store information,
				 * while device pointer would be NULL.
				 * UDP receive path is one user.
				 */
				unsigned long		dev_scratch;
			};
		};
		struct rb_node	rbnode; /* used in netem & tcp stack */
	};
        ... stuff deleted ...
};
====

The systemtap read fault error is coming from the following tapset line:

	dev_name = kernel_string($skb->dev->name)

(Of course, I'll remind readers that a "read fault" error is really a good thing - that's systemtap realizing that this address isn't valid and giving an error instead of trying to read a bad address and potentially crashing the kernel.)

In this case, the problem I see in finding a solution is that I don't see a way of knowing which of the two different unions have valid values in them:

1) In this particular skb, is skb->rbnode valid or is the unnamed structure containing next/prev valid?

2) Assuming this particular skb's unnamed structure containing next/prev is valid, is dev or dev_scratch valid?

The s390x is probably seeing the read fault error more than other platforms because it has always been more "sensitive" to bad addresses.

The quickest solution would just be to surround that tapset code with 'try { ... } catch { ... }' and returning the dev_name field as something like "UNKNOWN", but that doesn't really follow the spirit of the following bug where we tried to eradicate strings like that:

<https://sourceware.org/bugzilla/show_bug.cgi?id=15044>

Fixed upstream in commit 2f6fcfc68. Accesses to sk_buff structures are now surrounded by try/catch in probes.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:3168