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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox