linux-kernel - Re: [PATCH 06/10] staging/android: turn fence_info into a _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 30 Jan 2016 20:04:57 +0200
From:	Emil Velikov <emil.l.velikov@...il.com>
To:	Gustavo Padovan <gustavo@...ovan.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	devel@...verdev.osuosl.org, Daniel Stone <daniels@...labora.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Riley Andrews <riandrews@...roid.com>,
	ML dri-devel <dri-devel@...ts.freedesktop.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	John Harrison <John.C.Harrison@...el.com>
Subject: Re: [PATCH 06/10] staging/android: turn fence_info into a __64 pointer

Hi Gustavo,

s/__64/__u64/ in the commit message.

On 29 January 2016 at 23:20, Gustavo Padovan <gustavo@...ovan.org> wrote:
> From: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
>
> Making fence_info a pointer enables us to extend the struct in the future
> without breaking the ABI.
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@...labora.co.uk>

> diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
> index ed281fc..9f07aa7 100644
> --- a/drivers/staging/android/uapi/sync.h
> +++ b/drivers/staging/android/uapi/sync.h
> @@ -54,7 +54,7 @@ struct sync_file_info {
>         char    name[32];
>         __s32   status;
>
> -       __u8    fence_info[0];
> +       __u64   *fence_info;
I believe you misinterpreted what was meant with "_u64 pointer". As
the storage use for of a pointer varies across 32/64 bit arch, we
explicitly use a variable type that is large enough (and consistent)
for both cases. Thus the above should be

+       __u64   fence_info;

Hope this clarifies things.

-Emil