Re: 2.6.18 -mm merge plans -- GFS

[David Woodhouse <dwmw2@infradead.org>]

On Sun, 2006-06-04 at 13:50 -0700, Andrew Morton wrote:
> It's time to take a look at the -mm queue for 2.6.18.

You didn't mention GFS2 either -- is that ready to go upstream?
It contains this in its user<->kernel communication (whitespace sic)...

/* struct passed to the lock write */
struct dlm_lock_params {
       __u8 mode;
       __u16 flags;
       __u32 lkid;
       __u32 parent;
       __u8 namelen;
        void __user *castparam;
       void __user *castaddr;
       void __user *bastparam;
        void __user *bastaddr;
       struct dlm_lksb __user *lksb;
       char lvb[DLM_USER_LVB_LEN];
       char name[1];
};

struct dlm_lspace_params {
       __u32 flags;
       __u32 minor;
       char name[1];
};

struct dlm_write_request {
       __u32 version[3];
       __u8 cmd;

       union  {
               struct dlm_lock_params   lock;
               struct dlm_lspace_params lspace;
       } i;
};

/* struct read from the "device" fd,
   consists mainly of userspace pointers for the library to use */
struct dlm_lock_result {
       __u32 length;
       void __user * user_astaddr;
       void __user * user_astparam;
       struct dlm_lksb __user * user_lksb;
       struct dlm_lksb lksb;
       __u8 bast_mode;
       /* Offsets may be zero if no data is present */
       __u32 lvb_offset;
};

Now, the intention seems to be that instead of doing CONFIG_COMPAT stuff
in the kernel for backwards-compatibility with 32-bit userspace on
64-bit kernels, we _instead_ attempt to make the 32-bit userspace
_forward_ compatible with 64-bit kernels.

The userspace side of this is implemented (for sparc and s390 only) at
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/cluster/dlm/lib/dlm32.c?rev=1.3&content-type=text/plain&cvsroot=cluster

That approach looks broken when i386 binaries are run on x86_64, because
the offset of the 'qinfo' member in a struct which starts like this...

struct dlm_query_params64 {
	uint32_t query;
	uint64_t qinfo;
	...

... is going to be _different_ between the 32-bit userspace code and the
64-bit kernel anyway, despite the fact that this structure is supposed
to match the 64-bit kernel's idea of the structure.

The hdrcleanup and hdrinstall stuff helped to highlight this, because it
now stands out as being immediately obvious that we're adding pointers
to user-visible structures. I'm being asked to add the GFS2 headers to
Fedora's glibc-kernheaders package, but I _don't_ want to diverge from
upstream -- part of the reason for 'make headers_install' was that all
the distros will be able to ship a _consistent_ set of headers. So if
we're going to barf at the compat stuff above, can we do it ASAP and get
it fixed, or if we're going to accept the "userspace must be
forward-compatible" approach and send it to Linus as is, can we reach a
consensus on that instead?

-- 
dwmw2