PATCH] firewire: add padding to some struct

JiSheng Zhang wrote:
> struct fw_cdev_event_response and struct fw_cdev_event_iso_interrupt need padding.
> Otherwise, offset of the zero length array is not equal to the struct size. It may
> cause some strange problems under some platforms such as sparc32. This
> patch(against 2.6.26) should fix it.

The best solution to this problem would be to use

offsetof(struct fw_cdev_event_XYZ, data)

instead of sizeof(struct fw_cdev_event_XYZ) in all the places where the
offset is required.

Your proposed solution to add padding...

> --- old/include/linux/firewire-cdev.h 2008-07-18 16:34:01.181794046 +0800
> +++ new/include/linux/firewire-cdev.h 2008-07-18 16:35:46.649294275 +0800
> @@ -92,6 +92,7 @@
> __u32 type;
> __u32 rcode;
> __u32 length;
> + __u32 pad;
> __u32 data[0];
> };
>
> @@ -143,6 +144,7 @@
> __u32 type;
> __u32 cycle;
> __u32 header_length;
> + __u32 pad;
> __u32 header[0];
> };
>

...can alas not be applied because it would break ABI compatibility.

Thanks for looking into it,
--
Stefan Richter
-=====-==--- -=== =--=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,
If p is a pointer to struct fw_cdev_event_response), p->data will point to the
padding data rather than the right place, it will cause problem under some
platforms. For example, in the function handle_device_event of libraw1394(ported
to juju stack):
.....
case FW_CDEV_EVENT_RESPONSE:
rc = u64_to_ptr(u->response.closure);
if (rc->data != NULL)
memcpy(rc->data, u->response.data, rc->length);//here it will lost the last four
bytes
errcode = juju_to_raw1394_errcode(u->response.rcode);
.....

Although this problem can be solved by add the offset to the pointer, but the
member:__u32 data[0] lost its original meaning.

Thanks in advance,
JiSheng
>From: Stefan Richter <[email protected]>
>Reply-To:
>To: JiSheng Zhang <[email protected]>
>Subject: Re: PATCH] firewire: add padding to some struct
>Date:Fri, 18 Jul 2008 12:49:11 +0200
>
>JiSheng Zhang wrote:
> > struct fw_cdev_event_response and struct fw_cdev_event_iso_interrupt need
padding.
> > Otherwise, offset of the zero length array is not equal to the struct size. It
may
> > cause some strange problems under some platforms such as sparc32. This
> > patch(against 2.6.26) should fix it.
>
> The best solution to this problem would be to use
>
> offsetof(struct fw_cdev_event_XYZ, data)
>
> instead of sizeof(struct fw_cdev_event_XYZ) in all the places where the
> offset is required.
>
> Your proposed solution to add padding...
>
> > --- old/include/linux/firewire-cdev.h 2008-07-18 16:34:01.181794046 +0800
> > +++ new/include/linux/firewire-cdev.h 2008-07-18 16:35:46.649294275 +0800
> > @@ -92,6 +92,7 @@
> > __u32 type;
> > __u32 rcode;
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

JiSheng Zhang wrote:
> If p is a pointer to struct fw_cdev_event_response), p->data will point to the
> padding data rather than the right place, it will cause problem under some
> platforms. For example, in the function handle_device_event of libraw1394(ported
> to juju stack):
> .....
> case FW_CDEV_EVENT_RESPONSE:
> rc = u64_to_ptr(u->response.closure);
> if (rc->data != NULL)
> memcpy(rc->data, u->response.data, rc->length);//here it will lost the last four
> bytes
> errcode = juju_to_raw1394_errcode(u->response.rcode);
> .....
>
> Although this problem can be solved by add the offset to the pointer, but the
> member:__u32 data[0] lost its original meaning.

I don't understand what the problem is. As long as both kernel and
library use "response.data" or "&response + offsetof(typeof(response),
data)", they will write and read at the correct location.

There would be a problem if one of the two used "&response +
sizeof(response)" instead. Does this happen anywhere? If so, then
these places need to be fixed, not the struct definition.
--
Stefan Richter
-=====-==--- -=== =--=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Stefan Richter wrote:
> I don't understand what the problem is. As long as both kernel and
> library use "response.data" or "&response + offsetof(typeof(response),
> data)", they will write and read at the correct location.

PS, of course the math of the latter should look more like
(char *)&response + offsetof(...)
--
Stefan Richter
-=====-==--- -=== =--=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

>From: Stefan Richter <[email protected]>
>Reply-To:
>To: JiSheng Zhang <[email protected]>
>Subject: Re: PATCH] firewire: add padding to some struct
>Date:Fri, 18 Jul 2008 13:38:25 +0200
>
>JiSheng Zhang wrote:
> > If p is a pointer to struct fw_cdev_event_response), p->data will point to
the
> > padding data rather than the right place, it will cause problem under some
> > platforms. For example, in the function handle_device_event of
libraw1394(ported
> > to juju stack):
> > .....
> > case FW_CDEV_EVENT_RESPONSE:
> > rc = u64_to_ptr(u->response.closure);
> > if (rc->data != NULL)
> > memcpy(rc->data, u->response.data, rc->length);//here it will lost the last
four
> > bytes
> > errcode = juju_to_raw1394_errcode(u->response.rcode);
> > .....
> >
> > Although this problem can be solved by add the offset to the pointer, but the
> > member:__u32 data[0] lost its original meaning.
>
> I don't understand what the problem is. As long as both kernel and
> library use "response.data" or "&response + offsetof(typeof(response),
> data)", they will write and read at the correct location.
>
> There would be a problem if one of the two used "&response +
> sizeof(response)" instead. Does this happen anywhere? If so, then
> these places need to be fixed, not the struct definition.
yes, complete_transaction in fw-cdev.c, it queues the response and data.

how about adding __attribute__((packed)) to the two struct definition? It will not
break abi compatibility.

Thanks in advance,
JiSheng


--- old/include/linux/firewire-cdev.h 2008-07-18 16:34:01.181794046 +0800
+++ new/include/linux/firewire-cdev.h 2008-07-18 19:39:16.389293987 +0800
@@ -93,7 +93,7 @@ struct fw_cdev_event_response {
__u32 rcode;
__u32 length;
__u32 data[0];
-};
+} __attribute__((packed));

/**
* struct fw_cdev_event_request - Sent on incoming request to an address region
@@ -144,7 +144,7 @@ struct fw_cdev_event_iso_interrupt {
__u32 cycle;
__u32 header_length;
__u32 header[0];
-};
+} __attribute__((packed));

/**
* union fw_cdev_event - Convenience union of fw_cdev_event_ types


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/