From: Hans Verkuil <hverkuil@xs4all.nl>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Fix _IOC_TYPECHECK sparse error
Date: Mon, 12 May 2014 15:17:53 +0200 [thread overview]
Message-ID: <5370CA01.10802@xs4all.nl> (raw)
In-Reply-To: <20140509135949.feac79f3cb0ed9b13afbfeb4@linux-foundation.org>
On 05/09/2014 10:59 PM, Andrew Morton wrote:
> On Fri, 09 May 2014 09:43:58 +0200 Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
>> Andrew, can you merge this for 3.15 or 3.16 (you decide)? While it fixes a sparse error
>> for the media subsystem, it is not really appropriate to go through our media tree.
>>
>> Thanks,
>>
>> Hans
>>
>>
>> When running sparse over drivers/media/v4l2-core/v4l2-ioctl.c I get these
>> errors:
>>
>> drivers/media/v4l2-core/v4l2-ioctl.c:2043:9: error: bad integer constant expression
>> drivers/media/v4l2-core/v4l2-ioctl.c:2044:9: error: bad integer constant expression
>> drivers/media/v4l2-core/v4l2-ioctl.c:2045:9: error: bad integer constant expression
>> drivers/media/v4l2-core/v4l2-ioctl.c:2046:9: error: bad integer constant expression
>>
>> etc.
>>
>> The root cause of that turns out to be in include/asm-generic/ioctl.h:
>>
>> #include <uapi/asm-generic/ioctl.h>
>>
>> /* provoke compile error for invalid uses of size argument */
>> extern unsigned int __invalid_size_argument_for_IOC;
>> #define _IOC_TYPECHECK(t) \
>> ((sizeof(t) == sizeof(t[1]) && \
>> sizeof(t) < (1 << _IOC_SIZEBITS)) ? \
>> sizeof(t) : __invalid_size_argument_for_IOC)
>>
>> If it is defined as this (as is already done if __KERNEL__ is not defined):
>>
>> #define _IOC_TYPECHECK(t) (sizeof(t))
>>
>> then all is well with the world.
>>
>> This patch allows sparse to work correctly.
>>
>> --- a/include/asm-generic/ioctl.h
>> +++ b/include/asm-generic/ioctl.h
>> @@ -3,10 +3,15 @@
>>
>> #include <uapi/asm-generic/ioctl.h>
>>
>> +#ifdef __CHECKER__
>> +#define _IOC_TYPECHECK(t) (sizeof(t))
>> +#else
>> /* provoke compile error for invalid uses of size argument */
>> extern unsigned int __invalid_size_argument_for_IOC;
>> #define _IOC_TYPECHECK(t) \
>> ((sizeof(t) == sizeof(t[1]) && \
>> sizeof(t) < (1 << _IOC_SIZEBITS)) ? \
>> sizeof(t) : __invalid_size_argument_for_IOC)
>> +#endif
>> +
>> #endif /* _ASM_GENERIC_IOCTL_H */
>
> Can't we use BUILD_BUG_ON() here? That's neater, more standard and
> BUILD_BUG_ON() already has sparse handling.
I don't think so. BUILD_BUG_ON is not meant to be used in an expression, whereas
_IOC_TYPECHECK(t) is (it should return sizeof(t)).
This looked promising at first sight:
#define _IOC_TYPECHECK(t) \
({BUILD_BUG_ON(sizeof(t) == sizeof(t[1]) && sizeof(t) < (1 << _IOC_SIZEBITS)); \
sizeof(t);})
But it leads to 'case label does not reduce to an integer constant' compile errors.
And a typical ioctl define expands to this horror:
case (((2U) << (((0 +8)+8)+14)) | ((('M')) << (0 +8)) | (((1)) << 0) | (((({do { bool __cond = !(!(sizeof(int) == sizeof(int[1]) && sizeof(int) < (1 << 14))); extern void __compiletime_assert_1909(void) __attribute__((error("BUILD_BUG_ON failed: " "sizeof(int) == sizeof(int[1]) && sizeof(int) < (1 << _IOC_SIZEBITS)"))); if (__cond) __compiletime_assert_1909(); do { } while (0); } while (0); sizeof(int);}))) << ((0 +8)+8))):
which also explains the errors: case labels with function calls in them won't compile.
So I think my proposed patch is the best approach.
Regards,
Hans
next prev parent reply other threads:[~2014-05-12 13:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-09 7:43 [PATCH] Fix _IOC_TYPECHECK sparse error Hans Verkuil
2014-05-09 20:59 ` Andrew Morton
2014-05-12 13:17 ` Hans Verkuil [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-04-01 7:04 Hans Verkuil
2014-04-01 14:28 ` Josh Triplett
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=5370CA01.10802@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.