LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] doc: botching-up-ioctls: Make it clearer why structs must be padded
@ 2018-05-02  7:51 Daniel Vetter
  2018-05-02 16:56 ` Eric Anholt
  2018-05-08 14:53 ` Jonathan Corbet
  0 siblings, 2 replies; 3+ messages in thread
From: Daniel Vetter @ 2018-05-02  7:51 UTC (permalink / raw)
  To: LKML
  Cc: DRI Development, Daniel Vetter, Eric Anholt, linux-doc,
	Jonathan Corbet, Daniel Vetter

This came up in discussions when reviewing drm patches.

Cc: Eric Anholt <eric@anholt.net>
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

--

Aside: I wonder whether we shouldn't move this to some other place and
rst-ify it? Any good suggestions?
-Daniel
---
 Documentation/ioctl/botching-up-ioctls.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/ioctl/botching-up-ioctls.txt b/Documentation/ioctl/botching-up-ioctls.txt
index d02cfb48901c..883fb034bd04 100644
--- a/Documentation/ioctl/botching-up-ioctls.txt
+++ b/Documentation/ioctl/botching-up-ioctls.txt
@@ -73,7 +73,9 @@ will have a second iteration or at least an extension for any given interface.
    future extensions is going right down the gutters since someone will submit
    an ioctl struct with random stack garbage in the yet unused parts. Which
    then bakes in the ABI that those fields can never be used for anything else
-   but garbage.
+   but garbage. This is also the reason why you must explicitly pad all
+   structures, even if you never use them in an array - the padding the compiler
+   might insert could contain garbage.
 
  * Have simple testcases for all of the above.
 
-- 
2.17.0

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] doc: botching-up-ioctls: Make it clearer why structs must be padded
  2018-05-02  7:51 [PATCH] doc: botching-up-ioctls: Make it clearer why structs must be padded Daniel Vetter
@ 2018-05-02 16:56 ` Eric Anholt
  2018-05-08 14:53 ` Jonathan Corbet
  1 sibling, 0 replies; 3+ messages in thread
From: Eric Anholt @ 2018-05-02 16:56 UTC (permalink / raw)
  To: Daniel Vetter, LKML
  Cc: DRI Development, Daniel Vetter, linux-doc, Jonathan Corbet,
	Daniel Vetter

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

Daniel Vetter <daniel.vetter@ffwll.ch> writes:

> This came up in discussions when reviewing drm patches.
>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: linux-doc@vger.kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>
> --
>
> Aside: I wonder whether we shouldn't move this to some other place and
> rst-ify it? Any good suggestions?
> -Daniel
> ---
>  Documentation/ioctl/botching-up-ioctls.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ioctl/botching-up-ioctls.txt b/Documentation/ioctl/botching-up-ioctls.txt
> index d02cfb48901c..883fb034bd04 100644
> --- a/Documentation/ioctl/botching-up-ioctls.txt
> +++ b/Documentation/ioctl/botching-up-ioctls.txt
> @@ -73,7 +73,9 @@ will have a second iteration or at least an extension for any given interface.
>     future extensions is going right down the gutters since someone will submit
>     an ioctl struct with random stack garbage in the yet unused parts. Which
>     then bakes in the ABI that those fields can never be used for anything else
> -   but garbage.
> +   but garbage. This is also the reason why you must explicitly pad all
> +   structures, even if you never use them in an array - the padding the compiler
> +   might insert could contain garbage.

I hadn't realized that we had this document in git, or I probably would
have written this patch.  I think this makes it clear enough how I got
vc4 and v3d wrong.  Thanks!

Reviewed-by: Eric Anholt <eric@anholt.net>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] doc: botching-up-ioctls: Make it clearer why structs must be padded
  2018-05-02  7:51 [PATCH] doc: botching-up-ioctls: Make it clearer why structs must be padded Daniel Vetter
  2018-05-02 16:56 ` Eric Anholt
@ 2018-05-08 14:53 ` Jonathan Corbet
  1 sibling, 0 replies; 3+ messages in thread
From: Jonathan Corbet @ 2018-05-08 14:53 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: LKML, DRI Development, Eric Anholt, linux-doc, Daniel Vetter

On Wed,  2 May 2018 09:51:06 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> This came up in discussions when reviewing drm patches.

Applied, thanks.

> Aside: I wonder whether we shouldn't move this to some other place and
> rst-ify it? Any good suggestions?

For the moment, probably in Documentation/process, next to
volatile-considered-harmful.rst and such.  Even better, of course, would
be to have some nice document on designing user-space APIs in general...
one can always dream ... :)

Thanks,

jon

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-05-08 14:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-02  7:51 [PATCH] doc: botching-up-ioctls: Make it clearer why structs must be padded Daniel Vetter
2018-05-02 16:56 ` Eric Anholt
2018-05-08 14:53 ` Jonathan Corbet

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).