search for: __bitwise

This is just a reposting of the patch that enables endian checks, with addition of trivial patches that drop __bitwise__ and __CHECK_ENDIAN__ everywhere. I plan to include this in my pull request unless I hear otherwise. Michael S. Tsirkin (8): linux/types.h: enable endian checks for all sparse builds tools: enable endian checks for all sparse builds Documentation/sparse: drop __bitwise__ checkpatch: repl...

This is just a reposting of the patch that enables endian checks, with addition of trivial patches that drop __bitwise__ and __CHECK_ENDIAN__ everywhere. I plan to include this in my pull request unless I hear otherwise. Michael S. Tsirkin (8): linux/types.h: enable endian checks for all sparse builds tools: enable endian checks for all sparse builds Documentation/sparse: drop __bitwise__ checkpatch: repl...

__bitwise__ used to mean "yes, please enable sparse checks unconditionally", but now that we dropped __CHECK_ENDIAN__ __bitwise is exactly the same. There aren't many users, replace it by __bitwise everywhere. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- arch/arm/plat-samsu...

...cks for everyone produces about 200 new sparse warnings for me - less than 10% over the 2000 sparse warnings already there. Not a big deal, OTOH enabling this helps people notice they are introducing new bugs. So let's just drop __CHECK_ENDIAN__. Follow-up patches can drop distinction between __bitwise and __bitwise__. Cc: Linus Torvalds <torvalds at linux-foundation.org> Suggested-by: Christoph Hellwig <hch at infradead.org> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Linus, could you ack this for upstream? If yes I'll merge through my tree as a replacement...

...cks for everyone produces about 200 new sparse warnings for me - less than 10% over the 2000 sparse warnings already there. Not a big deal, OTOH enabling this helps people notice they are introducing new bugs. So let's just drop __CHECK_ENDIAN__. Follow-up patches can drop distinction between __bitwise and __bitwise__. Cc: Linus Torvalds <torvalds at linux-foundation.org> Suggested-by: Christoph Hellwig <hch at infradead.org> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Linus, could you ack this for upstream? If yes I'll merge through my tree as a replacement...

Hi, I?ve gone through the mailing list archives and hereby want to resubmit my pending patches. Most are independent of each other, except the m68k patch which will only be complete if sigsuspend is also fixed. (It can be applied before that, though.) http://www.zytor.com/pipermail/klibc/2012-January/003173.html [PATCH] fix m68k support Resubmitted here as 0005. While there was a question from

...a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h index a99f9b7..744cee1 100644 --- a/include/uapi/linux/virtio_ring.h +++ b/include/uapi/linux/virtio_ring.h @@ -33,6 +33,10 @@ * Copyright Rusty Russell IBM Corporation 2007. */ #include <linux/types.h> +typedef __u16 __bitwise __virtio16; +typedef __u32 __bitwise __virtio32; +typedef __u64 __bitwise __virtio64; + /* This marks a buffer as continuing via the next field. */ #define VRING_DESC_F_NEXT 1 /* This marks a buffer as write-only (otherwise read-only). */ @@ -61,32 +65,32 @@ /* Virtio ring descriptors: 16 bytes...

...a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h index a99f9b7..744cee1 100644 --- a/include/uapi/linux/virtio_ring.h +++ b/include/uapi/linux/virtio_ring.h @@ -33,6 +33,10 @@ * Copyright Rusty Russell IBM Corporation 2007. */ #include <linux/types.h> +typedef __u16 __bitwise __virtio16; +typedef __u32 __bitwise __virtio32; +typedef __u64 __bitwise __virtio64; + /* This marks a buffer as continuing via the next field. */ #define VRING_DESC_F_NEXT 1 /* This marks a buffer as write-only (otherwise read-only). */ @@ -61,32 +65,32 @@ /* Virtio ring descriptors: 16 bytes...

...random unsigned >> long feels very odd/broken... > > Agreed, an enum (mhp_flags) seems to give a better hint what can > actually be passed. Thanks! You probably know this but ... Just using a C enum doesn't get you any type safety. You can get some checking via sparse by using __bitwise, which is what gfp_t does. You don't actually have to use an enum for that, it works with #defines also. Or you can wrap the flag in a struct, the way atomic_t does, and then the compiler will prevent passing plain integers in place of your custom type. cheers

...random unsigned >> long feels very odd/broken... > > Agreed, an enum (mhp_flags) seems to give a better hint what can > actually be passed. Thanks! You probably know this but ... Just using a C enum doesn't get you any type safety. You can get some checking via sparse by using __bitwise, which is what gfp_t does. You don't actually have to use an enum for that, it works with #defines also. Or you can wrap the flag in a struct, the way atomic_t does, and then the compiler will prevent passing plain integers in place of your custom type. cheers

...nclude/uapi/linux/virtio_ring.h > index a99f9b7..744cee1 100644 > --- a/include/uapi/linux/virtio_ring.h > +++ b/include/uapi/linux/virtio_ring.h > @@ -33,6 +33,10 @@ > * Copyright Rusty Russell IBM Corporation 2007. */ > #include <linux/types.h> > > +typedef __u16 __bitwise __virtio16; > +typedef __u32 __bitwise __virtio32; > +typedef __u64 __bitwise __virtio64; > + > /* This marks a buffer as continuing via the next field. */ > #define VRING_DESC_F_NEXT 1 > /* This marks a buffer as write-only (otherwise read-only). */ > @@ -61,32 +65,32 @@ &g...

...from $LINUX/usr/include/asm/byteorder.h:5, from $KLIBC/usr/klibc/../include/klibc/endian.h:11, from $KLIBC/usr/klibc/../include/endian.h:8, from $KLIBC/usr/klibc/pread.c:7: $LINUX/usr/include/linux/types.h:22:0: warning: "__bitwise" redefined In file included from $KLIBC/usr/klibc/../include/klibc/endian.h:10:0, from $KLIBC/usr/klibc/../include/endian.h:8, from $KLIBC/usr/klibc/pread.c:7: $KLIBC/usr/klibc/../include/klibc/compiler.h:144:0: note: this is the location of the previ...

...uint64_t for every architecture + * so that we can print it with "%"PRIx64 without getting warnings. + * + * typedef __u64 u64; + * typedef __s64 s64; + */ +typedef uint64_t u64; +typedef int64_t s64; typedef __u32 u32; typedef __s32 s32; @@ -35,6 +48,10 @@ typedef __s8 s8; #define __bitwise #endif +#define __force +#define __user +#define __must_check +#define __cold typedef __u16 __bitwise __le16; typedef __u16 __bitwise __be16; @@ -55,4 +72,4 @@ struct hlist_node { struct hlist_node *next, **pprev; }; -#endif +#endif /* _TOOLS_LINUX_TYPES_H_ */ diff --git a/tools/perf/MA...

...uint64_t for every architecture + * so that we can print it with "%"PRIx64 without getting warnings. + * + * typedef __u64 u64; + * typedef __s64 s64; + */ +typedef uint64_t u64; +typedef int64_t s64; typedef __u32 u32; typedef __s32 s32; @@ -35,6 +48,10 @@ typedef __s8 s8; #define __bitwise #endif +#define __force +#define __user +#define __must_check +#define __cold typedef __u16 __bitwise __le16; typedef __u16 __bitwise __be16; @@ -55,4 +72,4 @@ struct hlist_node { struct hlist_node *next, **pprev; }; -#endif +#endif /* _TOOLS_LINUX_TYPES_H_ */ diff --git a/tools/perf/MA...

...from $LINUX/usr/include/asm/byteorder.h:5, from $KLIBC/usr/klibc/../include/klibc/endian.h:11, from $KLIBC/usr/klibc/../include/endian.h:8, from $KLIBC/usr/klibc/pread.c:7: $LINUX/usr/include/linux/types.h:22:0: warning: "__bitwise" redefined In file included from $KLIBC/usr/klibc/../include/klibc/endian.h:10:0, from $KLIBC/usr/klibc/../include/endian.h:8, from $KLIBC/usr/klibc/pread.c:7: $KLIBC/usr/klibc/../include/klibc/compiler.h:144:0: note: this is the location of the previ...

On Thu, Apr 10, 2014 at 07:38:05PM +0200, Borislav Petkov wrote: > Rebased onto current acme/perf/core: > > -- > From: Borislav Petkov <bp at suse.de> > Date: Sun, 23 Feb 2014 12:04:53 +0100 > Subject: [PATCH] tools: Unify export.h > > So tools/ has been growing three, at a different stage of their > development export.h headers and so we should unite into one.

On Thu, Apr 10, 2014 at 07:38:05PM +0200, Borislav Petkov wrote: > Rebased onto current acme/perf/core: > > -- > From: Borislav Petkov <bp at suse.de> > Date: Sun, 23 Feb 2014 12:04:53 +0100 > Subject: [PATCH] tools: Unify export.h > > So tools/ has been growing three, at a different stage of their > development export.h headers and so we should unite into one.

...; > less than 10% over the 2000 sparse warnings already there. > > > > Not a big deal, OTOH enabling this helps people notice > > they are introducing new bugs. > > > > So let's just drop __CHECK_ENDIAN__. Follow-up patches > > can drop distinction between __bitwise and __bitwise__. > > Hello Michael, > > This patch makes a whole bunch of ccflags-y += -D__CHECK_ENDIAN__ > statements obsolete. Have you considered to remove these statements? Absolutely. Just waiting for feedback on the idea. > Additionally, there are notable exceptions to...

On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: > We soon want to pass flags, e.g., to mark added System RAM resources. > mergeable. Prepare for that. What are these random "flags", and how do we know what should be passed to them? Why not make this an enumerated type so that we know it all works properly, like the GPF_* flags are? Passing around a random

...dd/broken... >> >> Agreed, an enum (mhp_flags) seems to give a better hint what can >> actually be passed. Thanks! > > You probably know this but ... > > Just using a C enum doesn't get you any type safety. > > You can get some checking via sparse by using __bitwise, which is what > gfp_t does. You don't actually have to use an enum for that, it works > with #defines also. Yeah, we seem to be using different approaches. And there is always a way to mess things up :) gfp_t is one (extreme) example, enum memblock_flags is another example. I tend to p...