linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Steven Price <steven.price@arm.com>
Cc: arnd@arndb.de, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com
Subject: Re: [PATCH 2/3] firmware: arm_scmi: Remove unneeded __packed attribute
Date: Mon, 13 Jul 2020 14:07:49 +0100	[thread overview]
Message-ID: <20200713130749.GA31938@e119603-lin.cambridge.arm.com> (raw)
In-Reply-To: <751ee628-ff38-a383-5832-aab4905af32b@arm.com>

Hi Steven

thanks for the review.

On Mon, Jul 13, 2020 at 12:20:43PM +0100, Steven Price wrote:
> On 10/07/2020 14:39, Cristian Marussi wrote:
> >Remove __packed attribute from struct scmi_event_header.
> >
> >Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> 
> A drive-by review. But this doesn't look safe to me. sizeof(struct
> scmi_event_header) is used in several places and this change will modify
> that from 13 to 16, but leave the structure members at the same offset (as
> the members are naturally aligned). In particular the naïve header size is
> now bigger than the offset to payld.
> 
> What is the justification for __packed being 'unneeded'?
> 

Arnd pointed out at first that this structure in the original series had a mix of
fixed and non-fixed types in its fields and that the __packed rendered some fields
misaglined.

Removing that as it is, in fact left also some unexplained implicit padding which is
at odd for a struct containing fixed-sized types.

In a following fix in the series I have indeed moved this struct's fields  and others
to generic non fixed type fields and shuffled around the fields to avoid misalignment
and implicit internal padding (except for the trailing padding due to the variable
size array)

It was probably better to squash also this patch in that following patch.

This structure is used internally to push variable-sized (through the means of the payld[])
events descriptors through a fifo from the ISR to the deferred workqueus, so that's whhy I
originally thought to avoid to carry around unneeded padding into the fifos and use the
__packed.

On the correctness side, as you pointed out, the header with padding is now 16 so when
I push thorugh the kfifos this header and the payload there's a hole in the data as
represented in the fifo buffer as such

@end_of hdr+payld kfifo writes:
  kifo_in(fifo, h, sizeof(*h)) + kfifo_in(fifo, payld, h->payld_sz)

0       14   16
+-------+----+------------
|header - pad| payload...
-------------------------
        ^
	|
	.payld

(Note that header and payload comes from two distinct place so I have push it with two kfifo_in()
in order to avoid a redundant memcpy on an intermediate buffer to collate them...thing
that was pointed out as undesirable in a review)

and when I read it back from the fifo such hole is just transparently overwritten:

@header read:
 kfifo_out(fifo, h, sizeof(*h))

0       14   16
+-------+----+--------------
|header - pad| 
----------------------------

@payload_read:
 kfifo_out(fifo, h->payld, h->payld_sz)

0       14   
+-------+----+--------------
|header | payload....
----------------------------
        ^
	|
	.payld

So since anyway the drawback of packing is that the misaglined access potentially slows down the
reads, I was not sure anymore it was worth to pack and misalign, and, given that it seemed not
to be liked so much, I dropped it and moved to generic non-fixed types without packing.

A better (and shorter) explanation of all of the above is possibly needed (but I'd still prefer
the fixed sized typing and __packed 'holeless' approach...)

Thanks

Cristian


> Steve
> 
> >---
> >  drivers/firmware/arm_scmi/notify.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c
> >index c4d006cfde88..752415367305 100644
> >--- a/drivers/firmware/arm_scmi/notify.c
> >+++ b/drivers/firmware/arm_scmi/notify.c
> >@@ -258,7 +258,7 @@ struct scmi_event_header {
> >  	u8	evt_id;
> >  	size_t	payld_sz;
> >  	u8	payld[];
> >-} __packed;
> >+};
> >  struct scmi_registered_event;
> >
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-07-13 13:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10 13:39 [PATCH 1/3] firmware: arm_scmi: Remove zero-length array in SCMI Notifications Cristian Marussi
2020-07-10 13:39 ` [PATCH 2/3] firmware: arm_scmi: Remove unneeded __packed attribute Cristian Marussi
2020-07-13 11:18   ` Steven Price
2020-07-13 11:20   ` Steven Price
2020-07-13 13:07     ` Cristian Marussi [this message]
2020-07-15 10:56       ` Steven Price
2020-07-10 13:39 ` [PATCH 3/3] firmware: arm_scmi: Remove fixed size fields from reports/scmi_event_header Cristian Marussi
2020-07-13 13:00 ` [PATCH 1/3] firmware: arm_scmi: Remove zero-length array in SCMI Notifications Sudeep Holla

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=20200713130749.GA31938@e119603-lin.cambridge.arm.com \
    --to=cristian.marussi@arm.com \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steven.price@arm.com \
    --cc=sudeep.holla@arm.com \
    /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;
as well as URLs for NNTP newsgroup(s).