linux-kernel - Re: [PATCH 2.6.20-rc1] ib_verbs: Use explicit if-else statements to avoid errors with do-while macros

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:	Thu, 14 Dec 2006 01:08:48 -0800
From:	Andrew Morton <akpm@...l.org>
To:	Al Viro <viro@....linux.org.uk>
Cc:	Ben Collins <ben.collins@...ntu.com>,
	Linus Torvalds <torvalds@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.20-rc1] ib_verbs: Use explicit if-else statements to
 avoid errors with do-while macros

On Thu, 14 Dec 2006 06:56:24 +0000
Al Viro <viro@....linux.org.uk> wrote:

> On Thu, Dec 14, 2006 at 06:44:30AM +0000, Al Viro wrote:
> > On Wed, Dec 13, 2006 at 10:10:05PM -0500, Ben Collins wrote:
> > > At least on PPC, the "op ? op : dma" construct causes a compile failure
> > > because the dma_* is a do{}while(0) macro.
> > > 
> > > This turns all of them into proper if/else to avoid this problem.
> > 
> > NAK.
> > 
> > Proper fix is to kill stupid do { } while (0) mess.  It's supposed
> > to behave like a function returning void, so it should be ((void)0).
> 
> BTW, even though the original patch is already merged, I think that
> we ought to get rid of do-while in such stubs, exactly to avoid such
> problems in the future.  Probably even add to CodingStyle - it's not
> the first time such crap happens.
> 
> IOW, do ; while(0) / do { } while (0)  is not a proper way to do a macro
> that imitates a function returning void.
> 
> Objections?

Would prefer static inline void foo(args){} when possible - for the arg
typechecking and arg existence checking and unused variable warnings.

I end up having to do rather a lot of things like this:

--- a/mm/vmalloc.c~virtual-memmap-on-sparsemem-v3-map-and-unmap-fix-2
+++ a/mm/vmalloc.c
@@ -929,6 +929,6 @@ int unmap_generic_kernel(unsigned long a
 		if (err)
 			break;
 	} while (pgd++, addr = next, addr != end);
-	flush_tlb_kernel_range((unsigned long)start_addr, end_addr);
+	flush_tlb_kernel_range(addr, addr);
 	return err;
 }


and this:


@@ -85,12 +84,24 @@ extern void vm_events_fold_cpu(int cpu);
 #else
 
 /* Disable counters */
-#define get_cpu_vm_events(e)	0L
-#define count_vm_event(e)	do { } while (0)
-#define count_vm_events(e,d)	do { } while (0)
-#define __count_vm_event(e)	do { } while (0)
-#define __count_vm_events(e,d)	do { } while (0)
-#define vm_events_fold_cpu(x)	do { } while (0)
+static inline void count_vm_event(enum vm_event_item item)
+{
+}
+static inline void count_vm_events(enum vm_event_item item, long delta)
+{
+}
+static inline void __count_vm_event(enum vm_event_item item)
+{
+}
+static inline void __count_vm_events(enum vm_event_item item, long delta)
+{
+}
+static inline void all_vm_events(unsigned long *ret)
+{
+}
+static inline void vm_events_fold_cpu(int cpu)
+{
+}

because of these problems.

Plus macros are putrid.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/